sua/sfu interix

оно же сдохло? а вообще да, интересно как в винде подсистемы реализованы. где-нибудь есть описание вот этого?

как сделаны OS/2 subsystem, WinNT subsystem, и тот костыль под названием interix/sua.

судя по сисколлам, это какой-то антропоморфный дендромутант — с кусками из POSIX (сигналы, семафоры, dlopen, и конечно, fork) + кусками из WinAPI, 2 в одном.

при этом тулчейн gcc (и/или, студия тоже) и генерирует в итоге PE .exe файлы (но с POSIX subsystem в свойствах EXE-шника).

плюс минималистичное юникс-окружение поверх всего этого.

вопросы:

1. а может, проще ELF-ы загружать в винде? написать для винды загрузчик эльфов, и загружать.

2. где-нибудь есть дока с описанием подробным, как устроенно и исходники этой подсистемы? open source и т.п.?

3. в идеале, ReactOS мог бы более правильно реализовать подсистему (с пунктом 1 про эльфы). и потом оттуда в любые другие винды перетянуть. насколько это сложно/трудоёмко вообще?

Почитай как в Cygwin реализуют fork в виндовсе и офигей

ссылку, сестра, ссылку

https://github.com/openunix/cygwin/blob/master/winsup/cygwin/fork.cc

По умолчанию он ищет именно SBCL. Нужно знать что его можно собрать и другими реализациями, и указывать нужный вариант

по истории проекта: SBCL это форк CMUCL, доработанный для портабельности, чтобы собирался не только CMUCL-ом, а и другими реализациями общелиспа.

то есть, бутстрап система сборки была переделана на поддержку других реализаций, портируемо. когда реализация стала самодостаточной, получился SBCL.

ещё для коллекции, собери Modula-3. это Modula-2 + исключения + шаблоны + более нормальный C FFI. практически почти что Oberon-2 - (или +-, вроде бы отключаем опционально) сборщик мусора.

mumpsc

какая это реализация? из командной строки, by Kevin O'Kane? ещё есть GT.M, тоже просто собирается под Linux (под винду есть какой-то порт под Cygwin, а в целом нужно портировать семафоры и сигналы под WinAPI).

я туда не смотрел, но угадаю пальцем в небо: фортран там понадобился для сборки какой-то системы компьютерной алгебры или чего-то подобного

ещё тут вот пытаются «модуляризовать» CommonLisp. посмотрим, что у них получится.

какая это реализация? из командной строки, by Kevin O'Kane?

Да.

Copyrights: (see individual modules for details)
  Copyright (c) 2000, 2001, 2002, 2003, 2013 by Kevin C. O'Kane
  Copyright (c) 2002 by Matthew J. Lockner
  Copyright (c) 2002 by Michael D. Janssen

раздутое ядро винды.

я тоже млею, когда рассказывают про «раздутую реализацию» языков программирования.

берём hello world, пишем на нескольких языках: C C++ go D Rust Nim Vala Oberon-2.

берём винду например, и mingw компилятор gcc из msys2. Oberon-2 консольный под Win32, реализацию OPCL (здесь или здесь. этот компилятор выдран из WinOberon).

собираем бинарники динамически; собираем статически; проверяем на зависимости.

собираем статически

C — 20 кб, зависимости только от системных DLL. C++ — 820кб, D — 200k (2Мб регрессия в какой-то версии), go — 2Мб, Rust — 20Кб, Nim — 20 Кб, Vala — 20 Кб, Oberon-2 — 100 Кб CLI (и 45 кб GUI, лол).

при этом учитываем, что у D, Go, Oberon-2, Nim, Vala — есть сборщик мусора. причём, у D, Nim, Vala — отключаемый.

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

у OPLC в эти 100 кб входит сборщик мусора и динамический загрузчик модулей, при этом получается самодостаточный бинарник.

20 Кб по-видимому, абсолютный минимум для более-менее высокоуровневых языков, если не гнаться сильно за экономией байт.

хотя ручками на ассемблере получается и меньше, понятно почему так: 5 страниц по 4 кб, Code .text .data .bss .stack .heap, с учётом выравнивания.

то есть, всё равно: страница целиком используется или не полностью, и разница 20 байт или 4 килобайт — не существенна для ос и mmap.

с Nimrod/Nim интересно получается: если собрать последним Nim 0.12.0 x:\nim\examples\hallo.nim как

nim c --run hallo.nim

nim c --deadCodeElim:on --opt:size --checks:off  --threads:off --verbosity:3 --gc:none -d:release --run hallo.nim

понятное дело, что --gc:none --check:off это немного не то, что хотелось бы от высокоуровневого языка программирования.

однако же, 20 кб, Карл! в языке с AST макросами, Карл!

(в vala тоже не всё так однозначно: если совсем простой хелловорд, то можно получить 0 зависимостей. чуть сложнее, хоть одну фичу языка задействовать — и уже нужны динамические зависимости от /mingw64/bin/libglib-2.0-0.dll /mingw64/bin/libiconv-2.dll /mingw64/bin/libintl-8.dll /mingw64/bin/libwinpthread-1.dll /mingw64/bin/libgobject-2.0-0.dll /mingw64/bin/libffi-6.dll, в сумме 2,7 Мб, стоит задействовать GTK — и привет, ещё 18 Мб.)

ВЫВОДы
1: считать надо вкруговую, для статической сборки.
2: старый компилятор оберона из 2000 года таки ещё ого-го: минималистиченее С++, например (учитывая что там есть GC и динамическая загрузка модулей). компилятор опять же, зело быстр — там просто нечему тормозить
3: «не платишь, за то, что не используешь» — таки миф, ибо балласт в рантайме. да и потом, разве ж это жизнь, без фич языка?
4: явно выделяются раст и си, а также компилируемые в си языки: Nim, vala — если аккуратно им обрезать рантайм и используемые фичи языка
5: ну и чего добились таким вот упражнением в минимализме ? всё равно динамические библиотеки реализованы почти везде, какая в конце концов разница, сколько там занимает бинарник хелловорда (всё равно практически полезный пример будет совсем не хелловорд)?

Интересно. И в каком состоянии находится этот проект? Насколько далёк от готовности?

https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process

In summary, current Windows implementations make it impossible to implement a perfectly reliable fork, and occasional fork failures are inevitable.

ядро венды хоть и раздутое, но раскидано по куче DLL-ек, в виде врапперов к Native API.

ядро линакса — толстый блоб, завязанный на конкретный тулчейн и libc (gcc и glibc, например; хотя и на clang и его портировали, это потребовало ввести в шланг gcc-измы).

в итоге, «раздуто» не столько само по себе ядро, сколько тулчейн — зачем-то зависимости от libgcc.so в динамических бинарниках, плюс вкомпилированные в ядро модули (которые не [M]), плюс отмазки типа «stable API nonsense», значит не стоит и пытаться стабилизировать :))

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

в духе «компилятор лиспа можно собрать только предыдущей версией компилятора лиспа» — ядро+тулчейн линукса тоже можно собрать только предыдущей версией его самого, во всевозможных комбинациях .config

в этом смысле Оберон-систему можно рассматривать как виртуальную машину, модель программной системы модульной, расширяемой. можно сказать, что это интерпретатор метаязыка, который умеет а) загружать модули б) выгружать модули в) вызывать «команды» из модулей по имени call-by-name, который дальше можно развить и в call-by-need с мемоизацией и в call-by-macroexpansion в стиле фекспров. минималистичного такого метаязыка. при этом сами модули и команды — уже откомпилированы (в духе шитого кода из фортов).

теоретически, такая система может жить вечно: расширямо, эволюционируемо, сменяясь модуль за модулем новой версии, без рестарта всей системы (сохранили состояние модуля, перегрузили один модуль, восстановили состояние персистентных объектов модуля).

при этом от самой ОС нужно реализовать только минималистичные 2-3 модуля управление памятью со сборкой мусора и динамический загрузчик. сами бинарники модулей — можно писать под одной ос, запускать под другой. для этого запускающие бинарники всей системы должны быть в нескольких экземплярах (под каждую ос отдельно), с этим минимумом системных модулей. остальные бинарники — общие под все ОС.

опять чем-то венду напоминает с DLL-ками, только без DLL hell-а : модули здесь компоненты с fingerprint-ами и нормальным контролем целостности (контрольная сумма или хеш-функция от метаданных, в духе структуры git object tree; при этом «совместимые по полиморфизму» модули имеют совместимые контрольные суммы)

да, там всё через C++ компилируется (что нетривиально, ибо в MUMPS есть косвенность; если не получается — интерпретируется). MUMPS там реализован библиотекой на C++.

в GT.M есть полноценный компилятор (и более правильная поддержка многопоточности, блокировок, версий БД, миграции и т.п. )

в целом, у O'Kane интересная реализация (хотя на Rust было бы перспективнее :))

её надо смотреть параллельно с его книжкой и примерами по биоинформатике.

но в SUA/Interix вроде ж осилили его сделать по-нормальному? на первый взгляд, это обычная BSD (правда, довольно кривая; Haiku и та менее костыльная BSD по сравнению с этим вот)

сложно вот так прям сразу судить, скорее пока что исследовательский на тему «Common Lisp + first class environments».

из более-менее готовых результатов этого проекта — что-то было в Clasp, который LLVM lisp + Clang AST matcher на лиспе

ссылка:

Work on CClasp (Clasp using Robert Strandh’s Cleavir compiler)

что-то пилят. нужно читать papers и roadmap какой-то.

ядро линакса — толстый блоб, завязанный на конкретный тулчейн и libc

libc завязываются на ядро, а не наоборот. Ядро — вещь в себе, и за небольшими исключениями (например, цифровая подпись модулей ядра) предоставляет интерфейсы наружу, а не обращается к сторонним программным интерфейсам.

зачем-то зависимости от libgcc.so в динамических бинарниках

libgcc — не часть компилятора как такового, а вспомогательная библиотека. Разные аппаратные архитектуры предоставляют разную, неравноценную функциональность, которую на программном уровне необходимо уравнивать, если мы хотим получать переносимые программы малой кровью. Microsoft за годы существования Windows NT упразднила возможность её работы на большей части изначально поддерживавшихся архитектур, поэтому им проще.

опять чем-то венду напоминает с DLL-ками, только без DLL hell-а : модули здесь компоненты с fingerprint-ами и нормальным контролем целостности (контрольная сумма или хеш-функция от метаданных, в духе структуры git object tree; при этом «совместимые по полиморфизму» модули имеют совместимые контрольные суммы)

C:\Windows\system32\winsxs?

Ты серъезно или нажрался?

Спасибо. Но тут дурдом ведь. Как я прийду к серъезным дядям с этим

Как я прийду к серъезным дядям с этим

Боишься, что засмеют из-за названия?

когда линуксоиды рассказывают про раздутое ядро винды.

Ок, сколько весит минимальная инсталляция Win?

кстати да.

кстати да.

И чем тут какой-нибудь GCC принципиально лучше? Тем более, что не обязательно расшифровывать аббревиатуру. Хотя я не верю, что ты это серьёзно.

libc завязываются на ядро,

в том смысле, что функции libc это сисколлы (внешнее API) это врапперы внутреннего API ядра.

а не наоборот.

ну наоборот тоже в каком-то смысле. иначе почему сложно собрать ядро с dietlibc musl прочими недоlibc минималистичными (или там msvcrt.dll, tinyc) и т.п.?

почему ядро линукса так завязано вот именно на glibc? там gcc-измы не только в ядре, но и в glibc.

вывод: ядро завязано на gcc, в какой-то мере.

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

и зачем мне дополнительная зависимость в конечном бинарнике от libgcc.so, если более другие чем gcc компиляторы могут обойтись без неё?

если рассматривать ядро как виртуальную машину, то можно выполнить его не на голом железе, а как подсистему другой виртуальной машины, с прозрачной динамической трансляцией intrsinc-ам, например (llva-emu, pdf)

любую программу можно рассматривать также и как виртуальную машину (с инструкциями = API программы). или как систему виртуальных машин: например, C-шный хелловорд с printf — это виртуальная C-POSIX машина, с трансляцией printf в puts и в сисколл write(stdout_is_1,...)  — виртуальную сисколл-машину для юниксов; понятно, что если транслировать в puts в WinAPI WriteConsole, например это будет трансляция C-POSIX машины в вендоапи-машину (которая также будет транслировать этот WriteConsoleA в NativeAPI функции, NtWriteFile, например) — это будет другая виртуальная машина, другой способ трансляции.

но все эти виртуальные машины — представляют одну и ту же программу (хотя и в разных API). они изоморфны, да.

libgcc — не часть компилятора как такового, а вспомогательная библиотека

нужная для gcc внутренняя кухня. но ненужная для clang или openwatcom например. и там, и там — компилятор был реализован как библиотека, без других зависимостей.

почему например для cl.exe эта libgcc.so не требуется?

C:\Windows\system32\winsxs?

ага, на нескольких уровнях:

1. ntdll.dll, 64-битные dll-ки в system32(почему 64-битные в system32? это ж винда, там всё через жопу. там и 32-битные почему-то в SysWow64, лолъ): kernel32.dll (32, Карл! опять), KERNELBASE.dll, msvcrt.dll

2. 32-битные dll-ки в c:\windows\SysWow64

3. если взять какой-нибудь .NET CLR, там всё то же самое: сборки и манифесты в виде XML с контрольными суммами, application domain, вот это оно всё.

я так понимаю, контрольными суммами пытались имитировать fingerprint-ы из модулей оберонов: кодовый и символьный файл, с метаданными. но опять ниасилили сделать это по компактному (или просто модель памяти application domain и однопроцессной оберон-системы сильно разная).

(например, цифровая подпись модулей ядра)

опять же fingerprint-ы модулей? только тоже неполноценные

ну сделай форк, с GNU и скрепами, тебе кто-то мешает?

Не знаю насколько эти дяди по твоим меркам серьёзные, но http://www.320-8080.ru/ Он на SBCL. Вот сорцы: https://bitbucket.org/f-team/cl-restas-eshop

ViaWeb 2.0? Автор Пол Грэм?

Не не. Я про то, что если я начальнику скажу Софт Банк Коммон Лисп. Тот спросит, что за банк такой?

С ГЦЦ там нет упоминания никого. Вот в чем вопрос. С ГЦЦ все просто.

ядро линакса — толстый блоб, завязанный на конкретный тулчейн и libc

ты наркоман

при этом от самой ОС нужно реализовать только минималистичные 2-3 модуля управление памятью со сборкой мусора и динамический загрузчик

это вообще не ОС а экзоядро

Я для чего сорцы дал?

С ГЦЦ все просто.

Да ну? А если «начальник» спросит что такое ГНУ и почему какой-то козёл на логотипе?

Не не. Я про то, что если я начальнику скажу Софт Банк Коммон Лисп. Тот спросит, что за банк такой?

Ты сам то из какого дурдома?

Да не будет никто про ГЦЦ спрашивать. Я к тому, что если в наименовании есть некий банк хочется понять чем он знаменит и почему именно этот банк пилит Лисп.

Bank — это берег, лол.

Я к тому, что если в наименовании есть некий банк...

Ну так я и спрашиваю «зачем какой-то гну в названии»?

Как Ривербанк в PyQT? Ну собственно тогда вопрос исчерпан.

Гну в Русском ничего не ассоциирует кроме Бендера Родригеса.

Крута же, чиста конкретна на пальцах: Пальцы Гну.

Скажите, пожалуйста, почему когда вся IT-индустрия выстроена на базе языка программирования C, нужен язык программирования Common Lisp? Спасибо.

den73 с другого компьютера

У меня на офтопике законфликтовал с авастом. Откатился обратно на предыдущий. Баг здесь:

https://bugs.launchpad.net/sbcl/ bug/1514386

можно голосовать :)

Если я ничего не путаю, то Steel bank (Стальной Банк) то ли основал, то ли крупно проспонсировал CMU.