Почему же нет, вот н-р для С++ есть boost, который имеет кучу хаков для каждого компилятора и ОС. Ну или java,python и т.п. в какой-то мере позволяет писать кроссплатформенный код. Другое дело, что чем более высокоуровневую обертку мы напишем, тем менее эффективно она будет работать на каждой конкретной платформе.

man posix

glib, Qt, APR

POSIX

Да, POSIX, но есть ещё и венда.

Ну там есть POFIX. А вроде POSIX и там как-то немного есть.

Венда сама виновата, что не POSIX-compatible.

венда настолько уродская, что к ней никакой libos не приделать.

Бредятина получится. Имя системы и пользователя как бы и так получается, а характеристики железа совсем другое. Железо может очень сильно отличаться, не нужно ограничиваться миром x86.

Одно дело, когда есть специализированная утилита типа dmidecode, а другое дело, когда в библиотку начнуть пихать код определения даты видеокарты для какого-нибудь Ultra Sparc'а. И с тестированием всего этого будет плоховато.

На фиг не надо. Ты приходишь к systemd, точнее, его пути.

Сегодня моя фамилия — Очевидность

POSIX

man Inferno OS.

При чем здесь инферно? Если то, что она может работать как гостевая, то тогда jvm тоже можно использовать как libos.

то тогда jvm тоже можно использовать как libos

Бинго! Собственно, независимость от ОС и архитектуры — их основная фича.
Библиотекой ты подобное всё равно не сделаешь.

Нужно создать библиотеку libos

Или осилить autotools

autotools

http://harmful.cat-v.org/software/GNU/auto-hell

http://<ссылка на тред о том как libos портировали на 42-ю платформу>

Почему до сих пор нет libos?

А почему ТЫ до сих пор не написал libos и не выложил на github/bitbucket/sf?

В какой-то теме недавно уже предлагали в подобных случаях SNMP.
Тред не читал.

Да, POSIX, но есть ещё и венда.

А венда не нужна

а другое дело, когда в библиотку начнуть пихать код определения даты видеокарты для какого-нибудь Ultra Sparc'а

Это всё будет окружено #ifdef ultrasparc и, если у тебя MIPS, то лишнего ты не соберёшь.

Согласен, я ей и не пользуюсь.

Чёй-та мне говорит, что там дело не только в такой библиотеке. Даже простой бинарник Hello, word будет разным у винды и *nix.

А если ты за исходники, то определить тип ОС в коде поможет boost: http://sourceforge.net/p/predef/wiki/OperatingSystems/

Есть же posix. Ну и бусты всякие тоже про это.

Ну так никто не портанул толком - технически, никаких ограничений нет. Те же pthreads, если с модулем ярда пускать практически 1 в 1 по функционалу.

Я не про объём бинарного кода в скомпилированной либе, а про объём исходного кода, который специфичен для определённой платформы. Если не найдётся желающего тестить такой код, то, либо его выкидывать, либо указывать, что не протестировано. И получится, что у libos всё хорошо с linux + x86, а чуть в сторону, у уже не так хорошо.

Ну, много разного специфического железа есть. Почему бы не протестировать на всём?

fork в винде полноценно не сделать. Будет медленный костлыль в любом случае.

Дык речь же не о скорости, а о портабельности :)

Я не в теме, но таки интересно, почему не сделать быстрый форк в винде? Можно пару ссылок потеме?

Угу, на AS/400 например каком нибудь :)

наверно по тому, что и нет единой теории всего, это очень не просто :) а еще в денег не хватает на исследования.

Ну, просто в линуксе fork — это «дешёвая» операция, а в венде дорогая. Или как-то так.

Называется Qt или Java

Енто понятно. Непонятны технические ограничения, в юзерспейсе с админскими правами, подобного поведения по идее можно добиться с помощью ReadProcess/WriteProcess, запилить сиё на уровне ядра и разрешить юзать пользователям с более низкими привеллегиями, тоже не выглядит сложной задачей хм.

Хотя возможно я не знаю каких то деталей, вот и спрашиваю - проводил ли кто то техническое исследование, или все удовлетворились тем, что cygwin'у было влом ?:)

Упоминают Qt, но это всё же языкозависимый специфичный код. А вот чтобы системный софт писать - оно не годится.

Так что ТС! Я одобряю твою задумку и пользовался бы такой библиотекой. Не слушай про systemd, потому что оно говно и контрпример, к тому же непортабельный вне-Linux.

Благословляю CYB3R-а на написание такой библиотеки. Без шуток, это очень умная мысль и идея вообще.

Сделай это модульным, типа libos-users и libos-что-то-еще, не будь таким как пердун поттерингю

У нас было такое. Тот еще гемморой. wine юзай лучше :D

У меня со словом «libos» ассоциируется понятие экзоядра. Но чтобы полная абстракци для ОС...

Например, нужно опросить систему по оборудованию, процессам, пользователям...

Так, и какие характеристики есть у процесса? А у пользователя? А у оборудования? Винда потому и не соответствует POSIX, что там базовые концепции, которыми оперирует ОС, не сводятся к тем, которые использует POSIX.

подобного поведения по идее можно добиться с помощью ReadProcess/WriteProcess

Так она потому и дорогая, что copy-on-write для памяти нативно не поддерживается. Форк, конечно, сделать можно, но только с полной копией памяти процесса, что занимает много времени.

Хотя я слышал, что в ядре NT есть или была возможность дёшево форкнуть процесс. Специально для Interix.

Хотя сейчас очень многие приложения используются архитектуру с многими тредами, а форк — только чтобы потом сделать exec. Поэтому fork не нужен.

Благословляю CYB3R-а на написание такой библиотеки.

Врял ли у меня хватит терпения на то, чтобы осилить хотя бы прочтение всей соответствующей документации.

Я решаю это при помощи qmake и #ifdef Q_OS_WIN и прочими - вполне просто и удобно.

А можно ссыль напочитать, как в онтопике реализуется дешёвый форк, без полной копии памяти процесса?

Если можно не на сорцы, а так что бы в 2ух словах?:)

Просто, по идее, ни что не мешает, на ядрёном уровне те же идиомы юзать, до определённых пределов конечно, но над памятью процесса у кода ядра есть ессно полный контроль.

Ты про vfork, что ли?

А, всё, осознал, т.е. загвоздка в cow, для форкнутого процесса?

Нее, просто не понимаю, что концептуально мешает имея полный контроль над памятью, сделать ту память copy on write, после вызова опеределённой ядерной функи.

Эх, жаль мои познания в области офтопикового ядра покрылись таким толстым слоем пыли :)

Единственная обьемная задача, по идее которая останется, это завести таблицу областей памяти форкнутых процессов и провести сплайсинг всех ядрёных колов, которые с этой памятью работают, дабы научить их работать с этим тэйблом.

Вот только составить списочек таковых, та ещё задачка :)

Как это fork не нужен? Да софта столько с ним. nginx, postgresql, redis и пр. и пр.

http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-h...

слава кэпу!

Ну дык это потому, что cygwin в юзерспейсе только живёт. Я и говорил тут, похоже что cygwin этого не сделали либо по политическим причинам(аля мы юзерспейсные, можем встать без админских привелегий), либо чисто из лени.

Я ж про ядрёный уровень, как это сделанно в pthreads(Pthreads-w32), например. Что бы cancelation points запилить.

Вот мне и интересно стало, может кто тут знает, всё таки какой то облом, в архитектуре ядра офтопика, который не позволяет это реализовать на том уровне.

Вообщем интересно, беседы для, но не запила ради :)

Ненужно. Это будет очень большая и убогая либа.