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

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

Тема:

> > Потому что поддержка каждой архитектуры требует от MS отдельных денег. А надо сделать ОС 1) по настоящему переносимой 2) открытой. (посмотрите на Linux. он конечно, многим не нравится, но поддержка Linux на куче архитектур не требует вливания кучи денег, в отличие от windows -- да его само собой добровольно переносят на кучу платформ (были бы желающие))
> 
> Отдельных денег требует в основном не программная сторона вопроса (винда весьма просто портируется), а продвижение, маркетинг, саппорт пользователей. С драйверами геморрой, с прикладным софтом. Пример многоплатформенной NT4 все вполне показал - OS была, а софта и драйверов для нее (кроме как от самой MS) - шиш да маленько. Соответственно продажи мизерные, так нафига париться?
> 
> > 
> > M$ тут как раз нам не указ. 1) У M$ ОС не микроядерная (или по крайней мере, не совсем микроядерная). Поэтому не так тривиально ее перенести на другую платформу.  несмотря на то что теоретически, HAL.DLL вроде бы абстрагирует оборудование 2) 32-разрядный API архитектурно зависим (вроде бы, сильно отличается от того же win64) API Поэтому надо поддерживать каждую архитектуру отдельно.
> 
> 32-разрядный API у MS гораздо менее архитектурно зависим, чем OS/2 API.
> 
> > 
> > Вопрос вроде упирается в наличие программ под экзотическую платформу. Но вопрос только в их перекомпиляции. Больших телодвижений от разработчика это не требует, портировать не надо, достаточно просто перекомпилировать под другую платформу. -- Если сделать по-настоящему переносимый API, то действительно -- достаточно простой перекомпиляции. Микроядро скроет все особенности оборудования. Потом, никто не отминяет x86-пробирку для бинарной совместимости с интел-версией.
> 
> Да, дело именно в наличии программ. Точнее - в наличии правильно (портируемо) написанных программ. 
>  
> > Да, это все хорошо. возможности конечно, действительно открываются потрясающие. Но, уже говорили 1) как быть с компилятором, такое умеет по-моему только Watcom, а завязываться на специфические фичи одного компилятора не хочется 2) проблемы при портировании существующих opensource исходников. -- Не окажемся ли мы в изоляции без софта? 3) это непереносимо на другие платформы. Если даже оставить экзотические, типа APM, то даже на AMD64 не совсем переносимо (что-то Лайтэльф говорил, что там для совместимости оставили только регистр SS, а остальные выкинули, если я правильно понял)
> 
> В AMD64-режиме сегменты данных и стека всегда имеют базу 0 и предел равный размеру адресного пространства (этот размер может быть разным на разных процессорах, изначально это 52 бита).
> Сегменты кода тоже имеют фиксированные размеры. Смысл имеют только некоторые поля дескриптора - режим (long/compatible), DPL, присутствие. Сегментные регистры FS и GS могут использоваться как базовые - то есть дескрипторы селекторов, загруженных в эти регистры могут иметь ненулевую базу, но предел в любом случае фиксирован.
> 
>

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