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

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

Тема:

> > > Соответсвенно.
> > > 1. Для первых версий ядра должен быть сохранен 16-и битный режим или написан полноценный эмулятор.
> 
> Что имеется в виду под 16-битным режимом? Коды процессора, драйверы, приложения?
> Напоминаю: одна из целей отказа от 16-битных приложений - улучшение карты распределения памяти программ (устранение противотанковых заграждений на 512-м километре).
> Что же касается "для первых версий"... Если в последующем всё-таки планируется совершить этот решительный шаг и отказаться от "16-битного режима", то зачем мучиться над его поддержкой сейчас? Зачем тратить усилия на создание того, что будет выброшено, вместо того, чтобы сразу совершить этот шаг? А если уж поддержка будет, то зачем от неё отказываться? И как тогда объяснять пользователям, почему из уже сделанного ядра вдруг выбросили вполне рабочую поддержку их 16-битных программ?
> 
> > Имхо, на первом этапе надо сделать 32-битные API, причем на самом первом этапе -- подмножество API, необходимое хотя бы для запуска шелла, а дальше -- постепенно его наращивать. И уже потом 16-битные API.
> 
> О каком шелле речь? CMD.EXE? Самописном? Напоминаю: сейчас в OS/2 полно функций, которые имеют только 16-рязрядные точки входа (в частности - консольный ввод/вывод), поэтому в практически любой 32-разрядной программе есть 16-битные фрагменты. Вот _их_ проблему нужно решать на первом этапе. А запуск самостоятельно откомпилированного полностью 32-разрядного аналога CMD.EXE - это этап 0.
> 
> > Но для них сначала надо сделать пробирку, а это очень трудоемкая задача.
> 
> Варианты решения без пробирки уже упоминались.
> 
> > Имхо, очевидно, что в _первых_ версиях ядра нельзя сделать все сразу, и поэтому разумно в 0....01 (куча знаков после запятой) версии делать только sourcelevel совместимость.
> 
> Ни в коем случае! Такие вопросы, как распределение памяти приложения, методы распихивания DLL и прочие аспекты совместимости с OS/2 нужно решать ещё до написания первой строчки.
> 
> > Потом реализовать пробирку, потом 16-битные API, потом thunking
> 
> Ну вот, а здесь thunking (вызов из 32-разрядного кода 16-разрядных функций ядра) на последнем месте почему-то. А до того как существующие LX-файлы запускать?
> 
> > > Я понимаю, что в стратегической перспективе мы придем к 32-х битным драйверам и это замечательно.
> > > Однако на переходном периоде мы обязаны сохранить совместимость со старыми драйверами и железом.
> 
> Зачем? Да, сейчас в OS/2 сотни 16-битных драйверов для разных железяк. Но где эти железяки? Где та шина ISA, в которую они втыкались? На ныне продающихся материнках уже и разъёмов PCI-то почти не осталось... Используемых IBM-овских драйверов осталось штуки три: клавиатура, мышь, COM-порт. Их, вкупе с абстрактными драйверами, переписать легче, чем городить поддержку старых.
>  
> > Имхо, на переходном этапе можно юзать eComStation и текущее ядро. А новое ядро -- это долгосрочная перспектива, и тут торопиться или делать лишние телодвижения типа поддержки 16-бит драйверов не стоит.
> 
> Поддерживаю.
>  
> > > Все-таки будем реалистами и не будем пытаться переплюнуть Линукс. Наша задача взять новые _технологии_ (и пока только технологии). А именно:
> > > 1. Микроядро.
> > > 2. Загружаемые/выгружаемые/перезапускаемые драйвера (только для 32-х битных)
> > 
> > 100% agree.
> 
> "А Баба Яга - против!" Точнее, хочет обратить внимание, что "перезапустить драйвер = остановить драйвер, запустить драйвер". А в моём проекте предусмотрена ещё одна операция - замена драйвера. И это совсем не то же, что его перезапуск, потому что при замене старый драйвер передаёт новому текущее состояние тех структур, которыми он управляет или владеет. О важности этой операции можете, например, спросить Пашу.

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~