Аналог 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
Источник
Linux аналог WinApi
Здарово всем. Я занимаюсь программингом но до этого я програмил только под виндой а сейчас думаю попробовать попрограммить под Linux так вот у меня возник такой вопрос: Например под винду есть WinAPI,а есть ли аналог под Linux?И где можно почитать про программинг под Linux?
Re: Linux аналог WinApi
Не принимай близко к сердцу, но прежде чем программить под линух, тебе надо напрочь забыть, что тебе сказал дядя билли, и начать заново изучать такие простые термины «операционная система»,»процессы», «межпроцессовые взаимодействия». Вобщем тебе надо пересмотреть в корне свое видение ОС. Сам все поймешь.
Re: Linux аналог WinApi
Re: Linux аналог WinApi
скажи info libc, да?
Re: Linux аналог WinApi
сли имеется ввиду графика, то для GNOME — http://gtk.org , KDE/QT — http://www.trolltech.com/products/qt/index.html , ну и много других — http://fltk.org , wxWidgets и т.д.
Re: Linux аналог WinApi
Если имеется в виду графика, то аналогом винАПИ будет только икслиб. Все остальное — аналог MFC, windows.forms и т.д.
Re: Linux аналог WinApi
Да, я в это верю =)
Re: Linux аналог WinApi
Вот тут можно найти много всякого стаффа для программирования под X и Motif (один из старейших графических тулкитов под X).
Источник
Аналог winapi CreateProcess под Linux
Виндовый CreateProcess работает следующим образом:
1) Запускается родительский процесс 2) Запускается дочерний процесс 3) Далее завершение процессов:
3-a) если родитель умирает , ребенок продолжает работать
3-b) если ребенок умирает , родитель получает код завершения работы ребенка
Что я смог нарыть под Linux:
fork + exec , то выполняется только пункт 3-b
fork + fork + exec , то выполняется только пункт 3-a
Можно ли сделать так , чтобы выполнялись оба пункта (3-a и 3-b)?
fork + exec , то выполняется только пункт 3-b
3-a должно выполняться, просто дочернему процессу может придти сигнал в обработчик по умолчанию и он завершится.
Спасибо за ответ! Из вашего сообщения я понял, что что-то сделать можно , но вот как.
Допустим я из своего приложения в отдельном потоке запустил стандартный калькулятор с помощью fork+exec . Я хочу чтобы калькулятор жил после завершения работы моей программы. Либо если завершался калькулятор , я хочу получить его код завершения.
Где можно почитать об этом или еще лучше пример кода на СИ ?
P.S. Я совсем недавно на Linux (15 лет на винде), поэтому прошу отнестись с пониманием.
Есть системный вызов sigaction, и соответствующая ему функция sigaction в libc, которая позволяет задавать действие при получении определенных сигналов.
ЕМНИП, в твоем случае дочерний процесс получает SIGHUP, и этот сигнал можно обработать.
Всех благодарю сердечно! И книгу посоветовали и пример дали и советы. Пойду разбираться.
3-a) если родитель умирает , ребенок продолжает работать
3-b) если ребенок умирает , родитель получает код завершения работы ребенка
fork + exec , то выполняется только пункт 3-b
нет же, man 2 exit:
Для меня стандратный калькулятор это bc, а какой у вас? Опишите подробнее, в GUI или в консоле? Есть завязки на терминал, на ввод/вывод. Если ваш калькулятор обменивается по pipe’ам с родителем, то он может получить SIGPIPE. В общем, между fork и exec можно замаскировать сигналы, но если после exec приложение их размаскирует.
В общем, можно написать своё приложение, которое будет прекрасно жить после смерти родителя, а можно найти такое чужое приложение, в котором автор упоролся и вобще засунул постоянную проверку pid’а родителя и без правки кода ничего не получится.
Может вам нужно будет делать fork + fork + exec, но первый дочерний процесс не выходит, а ждёт exec и возвращает его код завершения.
@mky калькулятор я взял для примера, это может быть любое приложение. Важна сама суть конечной функции , чтобы она выполняла такую же функциональность, что и ее виндовая сестра (CreateProcess). Чтобы было понятно для чего: это будет кросс.либа с минимально необходимым функционалом. Ну и конечно в первую очередь — это хороший опыт для меня. Программы упоротых разработчиков меня мало интересуют. В любом случае тут советы уже дали, надеюсь смогу осилить
Источник
