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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : Вернемся с небес на землю (всё целиком).

> > Соответсвенно.
> > 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.

"А Баба Яга - против!" Точнее, хочет обратить внимание, что "перезапустить драйвер = остановить драйвер, запустить драйвер". А в моём проекте предусмотрена ещё одна операция - замена драйвера. И это совсем не то же, что его перезапуск, потому что при замене старый драйвер передаёт новому текущее состояние тех структур, которыми он управляет или владеет. О важности этой операции можете, например, спросить Пашу.

Wed 13 Jun 2007 21:04 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.8) Gecko/20050




Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.