RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > 
> > > Имхо, на первом этапе надо сделать 32-битные API, причем на самом первом этапе -- подмножество API, необходимое хотя бы для запуска шелла, а дальше -- постепенно его наращивать. И уже потом 16-битные API.
> > 
> > О каком шелле речь? CMD.EXE? Самописном? Напоминаю: сейчас в OS/2 полно функций, которые имеют только 16-рязрядные точки входа (в частности - консольный ввод/вывод), поэтому в практически любой 32-разрядной программе есть 16-битные фрагменты. Вот _их_ проблему нужно решать на первом этапе. А запуск самостоятельно откомпилированного полностью 32-разрядного аналога CMD.EXE - это этап 0.
> 
> Ответ я написал, отвечая на предыдущую мессагу -- шелл (4os2) должен быть сначала перекомпилирован в 32-bit only режиме, на основе API VIO32/KBD32. Затем реализовать 16-бит API -- на основе эмуляции. При этом функции VIO16/KBD16 реализуются как врапперы VIO32/KBD32. Можно пойти не по пути эмуляции, а сделать конвертер LX-файлов в чистые 32-бит файлы -- будут юзать вместо 16-битных API из 32-битные аналоги.
> 
> > 
> > > Но для них сначала надо сделать пробирку, а это очень трудоемкая задача.
> > 
> > Варианты решения без пробирки уже упоминались.
> > 
> > > Имхо, очевидно, что в _первых_ версиях ядра нельзя сделать все сразу, и поэтому разумно в 0....01 (куча знаков после запятой) версии делать только sourcelevel совместимость.
> > 
> > Ни в коем случае! Такие вопросы, как распределение памяти приложения, методы распихивания DLL и прочие аспекты совместимости с OS/2 нужно решать ещё до написания первой строчки.
> > 
> 
> Если вопросы распределения памяти решим раньше -- тем лучше. А если не решим, то вначале можно вообще никак не закладываться на определенную раскладку адресного пространства приложения.
> 
> > > Потом реализовать пробирку, потом 16-битные API, потом thunking
> > 
> > Ну вот, а здесь thunking (вызов из 32-разрядного кода 16-разрядных функций ядра) на последнем месте почему-то. А до того как существующие LX-файлы запускать?
> > 
> 
> Я уже говорил -- существующие LX-файлы -- это уже следующий этап (вы osFree roadmap читали? -- там все подробно написано), а на самом первом этапе -- только 32-бит. API и формат ELF. (ну, сейчас меня наверное, зафлеймят...)
> 
> ...
> 
> > > > Все-таки будем реалистами и не будем пытаться переплюнуть Линукс. Наша задача взять новые _технологии_ (и пока только технологии). А именно:
> > > > 1. Микроядро.
> > > > 2. Загружаемые/выгружаемые/перезапускаемые драйвера (только для 32-х битных)
> > > 
> > > 100% agree.
> > 
> > "А Баба Яга - против!" Точнее, хочет обратить внимание, что "перезапустить драйвер = остановить драйвер, запустить драйвер". А в моём проекте предусмотрена ещё одна операция - замена драйвера. И это совсем не то же, что его перезапуск, потому что при замене старый драйвер передаёт новому текущее состояние тех структур, которыми он управляет или владеет. О важности этой операции можете, например, спросить Пашу.
> 
> Против чего? Замену драйверов также можно реализовать при помощи перерегистрации службы на Name Server'е. Кроме того, можно реализовать протокол для передачи текущего состояния одного драйвера другому. Это может быть сделано на любом микроядре, в том числе L4.
>

__, _,_ _, __, ___, \|_) \| \| \| \|_ ` / \| \ \| \| \| , \| / ~ ~ `~' ~~~ ~~~ ~~~