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

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

Тема:

> > > Кстати, как такая идея? Сделать эмулятор для выполнения 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-и разрядных программ.
>

_, __, _, __, /_\ \|_) /_\ \|_) \| \| \| \| \| \| \ ~ ~ ~ ~ ~ ~ ~