> Трава у автора несомненно хорошая и он точно умеет в ABI, но...
> 1. ONTL это не "стандартная библиотека С++11", а некий набор утилитарных обвязок
> облегчающих кодирование для NativeAPI. Причем там всегда чего-то не хватало, а
> реальный функциональный код был в ntdll и т.д. Нужно сильно постараться
> чтобы найти мотивировку для вытаскивания этой стюардессы из гроба mustie.Часть ONTL соответствует требованиям ISO/IEC 14882 соответствующего года к _conforming_ freestanding implementation. Другая часть - это специфичные для Windows структуры, в том числе и не открытые Микрософт. Естественно, это переносить не нужно.
> 2. Нет сложностей проставить ручками номера пары десятков системных вызовов для одной
> архитектуры текущей/удобной версии ядра, но дальше это тупик без машинерии.
Не улавливаю смысл предложения. Есть золотое правило ядерщиков: "don't break userland". Которое эксперты почему-то подменяют на "stable API nonsense", относящееся к внутреннему устройству самого ядра.
> Есть подозрение, что автор не в курсе масштаба бедствия (в том числе
> не понимает причинно-следственные связи требований LSB, см https://github.com/STrusov/Ussury/blob/draft2/runtime/link.h).
Автору не интересны ни Hurd, ни поддержка руткитов, подгружаемых LD_PRELOAD, или вообще собираемых из модифицированных исходников glibc после успешной атаки xz-трояном машин "автономных разработчиков".
> 3. Показанное пока является только минималистической заготовкой. С таким-же успехом можно
> было опубликовать новость по поводу успешного основания проекта после выполнения mkdir
> и git init ;)
Странно, что форк Redis не выбран как пример. А вообще, stlx часть ntl когда-то планировали запускать поверх glibc, но не нашлось повода.
