Аналог winapi для linux

Аналог WinAPI в Linux

Возник вопрос, где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.

Qt & GTK это GUI, а если вас интересует System Calls, то google.com -> LInux system calls

>Qt & GTK это GUI

Насчет Qt — это как минимум фейл, а в комплекте с GTK+ идет Glib и Gdk, так чта по этому поводу тоже фейл.

Какой такой фейл ещё ? Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls, а уж точне не QT и не GTK.

> а уж точне не QT

>Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls

1) Аналога Win32 Api в линуксе нет. 2) NT Kernel API — это не Win32 API 3) Qt это не только GUI, но еще и ввод-вывод, сеть, БД, контейнеры, IPC итд, итп. все те возможности которые предоставляет Win32 API.

Пожалуй, тоже ввяжусь в спор. Человек спрашивает:»где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.» oistalker отвечает — «Qt & GTK» (ну, утрирую, конечно). Теперь вопрос — где в Qt можно прочитать про функции WinAPI, не говоря уже о функциях API Linux (или как их там, чёрт их возьми)?
Ну признайте, oistalker, вы были неправы. Ваш 1-й пост не по адресу, так?

>Ну признайте, oistalker, вы были неправы.

С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.

oistalker
>В самом Linux нет никакого API, — то что подразумевается
>по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc,
>GTK/GLib/Qt/etc.
Да-да-да-да. Кажется, начинаю понимать. Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow, и эти вещи для Linux реализуются на низком уровне в Qt? Надо же, как интересно. А ведь даже у такой маленькой системы, как KolibryOS, есть свой набор API-функций.
Ну, а скажем, поток создать в Linux сложно?

Видимо я не совсем корректно сформулировал вопрос. Реально мне нужны след функции: Работа с потоками, работа с файлами (создать, удалить, прочитать, записать, установить указатель), работа с памятью (если там есть аналоги VirtualAlloc, VirtualFree — получать память выравненную на границу 4кб), ну и работа с сокетами (только UDP и без всяких там WSA). Т.е. самый минимум. Приложение консольное так что никакое GUI не требуется.
ProGrAMmER256
Спасибо, посмотрю.

Файлы, потоки — есть в Qt. Сокеты — входят в состав стандартной библиотеки Си (glibc), также как и функции выделения памяти, файлы, потоки. А использовать системные вызовы для вызова этой фукциональности — моветон. Программа мгновенно становится системозависимой. и скажем, если потребуется запустить её на FreeBSD, получится много — много геморроя.

>Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow,

Упёртый чёрт. посмотри отладчиком, что дальше по цепочке дергает этот самый CreateFile, — увидишь там ZwCreateFile из DDK.

Я немного фигею с предложения использовать Qt там, где вполне можно ограничиться позиксом.

>С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. >Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.
Весьма и весьма спорное утверждение. DDK вобще не в тему — мы ведь говорим про то что снаружи ядра находится.
Под системным вызовом можно подразумевать разное.
Например — интерфейс между user space и ядром.
Тот самый механизм, который включает в себя упаковку номера системного вызова и параметров особым образом, переключение в привилегированный режим и вызов функции из таблицы системных вызовов. Номер системного вызова == смещение в таблице.

А можно называть системными вызовами обертки, которые находятся в libc.
Функции open(), read(), write() и далее по списку.
Этот интерфейс стандартизован и поддерживается и на Линуксе, и на Солярисе и на МакОс.
Такого четкого разделения как на винде нет (к вопросу NativeAPI vs WinAPI), поэтому например на Линуксе в том же libc находятся специфические функции типа clone() и futex() для реализации многопоточности.
Поверх платформозависимых функций построены стандартизованные интерфейсы.
Например clone() и futex() обернуты стандартизованной библиотекой pthreads.

Поинт в том, что для того, чтобы добиться переносимости, нужно использовать стиандартизованные интерфейсы.
Это может быть posix, а может быть qt, а может быть apr или даже boost.
продвигать qt как единственное решение — по меньшей мере странно.

работа с потоками — pthread
с файлами — posix
сокеты — собственно сокеты ( )
если нужны окошки (аналоги CreateWindow и прочее) — XWindow

Источник

Аналог WinAPI в Linux

Возник вопрос, где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.

Qt & GTK это GUI, а если вас интересует System Calls, то google.com -> LInux system calls

>Qt & GTK это GUI

Насчет Qt — это как минимум фейл, а в комплекте с GTK+ идет Glib и Gdk, так чта по этому поводу тоже фейл.

Какой такой фейл ещё ? Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls, а уж точне не QT и не GTK.

> а уж точне не QT

>Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls

1) Аналога Win32 Api в линуксе нет. 2) NT Kernel API — это не Win32 API 3) Qt это не только GUI, но еще и ввод-вывод, сеть, БД, контейнеры, IPC итд, итп. все те возможности которые предоставляет Win32 API.

Пожалуй, тоже ввяжусь в спор. Человек спрашивает:»где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.» oistalker отвечает — «Qt & GTK» (ну, утрирую, конечно). Теперь вопрос — где в Qt можно прочитать про функции WinAPI, не говоря уже о функциях API Linux (или как их там, чёрт их возьми)?
Ну признайте, oistalker, вы были неправы. Ваш 1-й пост не по адресу, так?

>Ну признайте, oistalker, вы были неправы.

С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.

oistalker
>В самом Linux нет никакого API, — то что подразумевается
>по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc,
>GTK/GLib/Qt/etc.
Да-да-да-да. Кажется, начинаю понимать. Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow, и эти вещи для Linux реализуются на низком уровне в Qt? Надо же, как интересно. А ведь даже у такой маленькой системы, как KolibryOS, есть свой набор API-функций.
Ну, а скажем, поток создать в Linux сложно?

Видимо я не совсем корректно сформулировал вопрос. Реально мне нужны след функции: Работа с потоками, работа с файлами (создать, удалить, прочитать, записать, установить указатель), работа с памятью (если там есть аналоги VirtualAlloc, VirtualFree — получать память выравненную на границу 4кб), ну и работа с сокетами (только UDP и без всяких там WSA). Т.е. самый минимум. Приложение консольное так что никакое GUI не требуется.
ProGrAMmER256
Спасибо, посмотрю.

Файлы, потоки — есть в Qt. Сокеты — входят в состав стандартной библиотеки Си (glibc), также как и функции выделения памяти, файлы, потоки. А использовать системные вызовы для вызова этой фукциональности — моветон. Программа мгновенно становится системозависимой. и скажем, если потребуется запустить её на FreeBSD, получится много — много геморроя.

>Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow,

Упёртый чёрт. посмотри отладчиком, что дальше по цепочке дергает этот самый CreateFile, — увидишь там ZwCreateFile из DDK.

Я немного фигею с предложения использовать Qt там, где вполне можно ограничиться позиксом.

>С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. >Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.
Весьма и весьма спорное утверждение. DDK вобще не в тему — мы ведь говорим про то что снаружи ядра находится.
Под системным вызовом можно подразумевать разное.
Например — интерфейс между user space и ядром.
Тот самый механизм, который включает в себя упаковку номера системного вызова и параметров особым образом, переключение в привилегированный режим и вызов функции из таблицы системных вызовов. Номер системного вызова == смещение в таблице.

А можно называть системными вызовами обертки, которые находятся в libc.
Функции open(), read(), write() и далее по списку.
Этот интерфейс стандартизован и поддерживается и на Линуксе, и на Солярисе и на МакОс.
Такого четкого разделения как на винде нет (к вопросу NativeAPI vs WinAPI), поэтому например на Линуксе в том же libc находятся специфические функции типа clone() и futex() для реализации многопоточности.
Поверх платформозависимых функций построены стандартизованные интерфейсы.
Например clone() и futex() обернуты стандартизованной библиотекой pthreads.

Поинт в том, что для того, чтобы добиться переносимости, нужно использовать стиандартизованные интерфейсы.
Это может быть posix, а может быть qt, а может быть apr или даже boost.
продвигать qt как единственное решение — по меньшей мере странно.

работа с потоками — pthread
с файлами — posix
сокеты — собственно сокеты ( )
если нужны окошки (аналоги CreateWindow и прочее) — XWindow

Источник

Аналог WinAPI в Linux

Возник вопрос, где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.

Qt & GTK это GUI, а если вас интересует System Calls, то google.com -> LInux system calls

>Qt & GTK это GUI

Насчет Qt — это как минимум фейл, а в комплекте с GTK+ идет Glib и Gdk, так чта по этому поводу тоже фейл.

Какой такой фейл ещё ? Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls, а уж точне не QT и не GTK.

> а уж точне не QT

>Вы вопрос видите ? Аналог WINAPI для LInux называется System Calls

1) Аналога Win32 Api в линуксе нет. 2) NT Kernel API — это не Win32 API 3) Qt это не только GUI, но еще и ввод-вывод, сеть, БД, контейнеры, IPC итд, итп. все те возможности которые предоставляет Win32 API.

Пожалуй, тоже ввяжусь в спор. Человек спрашивает:»где можно прочитать про функции операционной системы для Linux. Т.е. аналог описание WinAPI в Platform SDK.» oistalker отвечает — «Qt & GTK» (ну, утрирую, конечно). Теперь вопрос — где в Qt можно прочитать про функции WinAPI, не говоря уже о функциях API Linux (или как их там, чёрт их возьми)?
Ну признайте, oistalker, вы были неправы. Ваш 1-й пост не по адресу, так?

>Ну признайте, oistalker, вы были неправы.

С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.

oistalker
>В самом Linux нет никакого API, — то что подразумевается
>по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc,
>GTK/GLib/Qt/etc.
Да-да-да-да. Кажется, начинаю понимать. Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow, и эти вещи для Linux реализуются на низком уровне в Qt? Надо же, как интересно. А ведь даже у такой маленькой системы, как KolibryOS, есть свой набор API-функций.
Ну, а скажем, поток создать в Linux сложно?

Видимо я не совсем корректно сформулировал вопрос. Реально мне нужны след функции: Работа с потоками, работа с файлами (создать, удалить, прочитать, записать, установить указатель), работа с памятью (если там есть аналоги VirtualAlloc, VirtualFree — получать память выравненную на границу 4кб), ну и работа с сокетами (только UDP и без всяких там WSA). Т.е. самый минимум. Приложение консольное так что никакое GUI не требуется.
ProGrAMmER256
Спасибо, посмотрю.

Файлы, потоки — есть в Qt. Сокеты — входят в состав стандартной библиотеки Си (glibc), также как и функции выделения памяти, файлы, потоки. А использовать системные вызовы для вызова этой фукциональности — моветон. Программа мгновенно становится системозависимой. и скажем, если потребуется запустить её на FreeBSD, получится много — много геморроя.

>Т.е., к примеру, там нет даже аналога CreateFile, не говоря уже о CreateWindow,

Упёртый чёрт. посмотри отладчиком, что дальше по цепочке дергает этот самый CreateFile, — увидишь там ZwCreateFile из DDK.

Я немного фигею с предложения использовать Qt там, где вполне можно ограничиться позиксом.

>С чего это я не прав? В самом Linux нет никакого API, — то что подразумевается по WinAPI реализуется с помощью библиотек уровня пользователя, XLib,glibc, GTK/GLib/Qt/etc. >Набор же системных вызовов ядра назвать API — это немножко лишка хватить, — оно фактически соответствует DDK и NT Kernel API.
Весьма и весьма спорное утверждение. DDK вобще не в тему — мы ведь говорим про то что снаружи ядра находится.
Под системным вызовом можно подразумевать разное.
Например — интерфейс между user space и ядром.
Тот самый механизм, который включает в себя упаковку номера системного вызова и параметров особым образом, переключение в привилегированный режим и вызов функции из таблицы системных вызовов. Номер системного вызова == смещение в таблице.

А можно называть системными вызовами обертки, которые находятся в libc.
Функции open(), read(), write() и далее по списку.
Этот интерфейс стандартизован и поддерживается и на Линуксе, и на Солярисе и на МакОс.
Такого четкого разделения как на винде нет (к вопросу NativeAPI vs WinAPI), поэтому например на Линуксе в том же libc находятся специфические функции типа clone() и futex() для реализации многопоточности.
Поверх платформозависимых функций построены стандартизованные интерфейсы.
Например clone() и futex() обернуты стандартизованной библиотекой pthreads.

Поинт в том, что для того, чтобы добиться переносимости, нужно использовать стиандартизованные интерфейсы.
Это может быть posix, а может быть qt, а может быть apr или даже boost.
продвигать qt как единственное решение — по меньшей мере странно.

работа с потоками — pthread
с файлами — posix
сокеты — собственно сокеты ( )
если нужны окошки (аналоги CreateWindow и прочее) — XWindow

Источник