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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Igor Vaskov
To : Юрий Пронякин
Subj : Тут надо определиться :)
> > Кстати, как такая идея? Сделать эмулятор для выполнения 16-и битного кода. Т.е. такую хитрую пробирку, но только не для системы в целом, а только для кода? Да, будет не сильно быстро, но проблему решит. В принципе же можно написать 32-х битный интерпретатор бинарного 16-и ричного кода.
>
> У процессоров x86 своеобразная система команд. Одни и те же коды команд могут обозначать разные команды в зависимости от контекста. Одним из элементов контекста является разрядность того сегмента кода, в котором находится данная команда.
> Когда процессор работает в 32-разрядном режиме, у него могут быть только 16- и 32-разрядные сегменты кода. А когда он работает в 64-разрядном режиме, сегменты кода могут быть только 32- и 64-разрядные (разрядность сегмента определяется одним битиком в его дескрипторе). Поэтому как бы мы ни извращались, но _правильно_ проинтерпретировать последовательность кодов, предназначенную для помещения в 16-разрядный сегмент, процессор не сможет.
> Но это не означает, что выхода нет. Возможных решений даже несколько. Например:
> 1. Уже названный интерпретатор (эмулятор).

Пока из всего вышесказанного мне кажется этот способ наиболее универсальным.

> 2. Загрузчик LX-файлов может иметь встроенный декомпилятор и в процессе загрузки переводить 16-разрядные объекты в соответствующий 32-разрядный код.

В общем случае, 16-и разрядный сегмент есть не только в загрузчике.

> 3. Упомянутые объекты никто ведь руками не писал, это thunk-и, вставленные компилятором для вызова 16-разрядных функций OS/2 из 32-разрядного кода. У каждого компилятора thunk-и свои, типовые, и компиляторов у нас совсем не много, поэтому загрузчик может иметь встроенную систему опознавания, которая будет подменять в программе call, направленный на thunk, call-ом на заранее заготовленный 32-разрядный аналог (или вообще сразу на соответствующую 32-разрядную функцию нового ядра).

Хорошо, а если я в программе пишу ассемблерную вставку на 16-и битном ассемблере? Да и все компиляторы, хоть их и не много не охватишь. Кто то да останется незамеченным.

> 4. Можно написать конвертор LX-файлов в полностью 32-разрядные (по аналогии с Одиновским конвертором).

Это можно. Тоже вполне возможный вариант. Достоинства - однократное преобразование и последующая быстрая работа программы.
В принципе можно пункты 1 и 4 сложить.

>
> > Одно несоменно - новое ядро обязано поддерживать весь старый софт включая 16-и битный. Иначе это будет не ядро OS/2, а ядро какой-то другой системы.
>
> Написанное выше - о том, как можно исполнять 32-разрядные программы OS/2 в 64-разрядном режиме. Что же до совместимости с OS/2... Безусловным является одно: должны работать 32-разрядные программы, PM и WPS. Остальное зависит от поставленной цели и выбранного направления развития. Если окажется, что это направление несовместимо с 16-разрядным кодом или включение такой поддержки требует чрезмерно больших усилий, то от старого лучше отказаться. Мне, например, сейчас очень не нравится, что у программ память разорвана на куски: отдельно нижняя область памяти, отдельно - верхняя.
> А если в такой ситуации кому-то очень нужно будет запускать 16-разрядные программы - виртуальные машины американские правоблюстители пока не запретили.

Не очень хочется выбрасывать на помойку истории большое количество, как правило, хорошо отлаженных 16-и разрядных программ.


Thu 07 Jun 2007 14:36 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET



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.