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

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

Тема:

> > > > Попробуй посчитать, сколько процентов из тех программ, которыми ты пользуешься,
> > > > 16-битные, и действительно ли у них нет 32-битной замены.
> > > link386, один из вариантов rc, unpack, hiew, итп
> > 
> > Я лично использую 32-разрядный XLink, RC давно уже 32-разрядный (16-разрядный RC16 оставлен для любителей 16-разрядных программ), у Hiew (OS/2 ветка которого давно заброшена) есть функциональный аналог Biew, и т.д.
> 
> Пользую как biew, так и hiew. Последний мне нравится больше.
> 
> > 
> > > Не факт, что link386 на 100% заменяем, кстати.
> > 
> > Я, например, умудрился ни разу им не пользоваться. Но возможно и сам формат LX имеет смысл оставить только как legacy, а переходить на что-то более распространённое. ELF, например. Сама IBM в OS/2 для PowerPC именно так и сделала.
> > 
> 
> Да, подтверждаю -- в OS/2 PPC использовался ELF. Мы можем тоже так сделать. Или не сделать -- как решим. Во всяком, случае, поддержка LX и 16-разрядных сегментов нужна.
> 
> > > Впрочем - не в этом дело. Скажи честно, что единственная причина, по которой ты борешься с 16-bit - желание сделать 32/64.
> > 
> > Где ты видел хоть один мой призыв к переходу на 64 бита? Но изрядная часть кривизны нынешней архитектуры системы связана именно с наличием поддержки 16-разрядного кода. И это сейчас уже реально иногда мешает. Нужно же когда-то сделать решительный шаг. Так почему бы не сейчас? Apple, вон, сколько раз революцию устраивала, к тому же в критические дни - и ничего, поклонники не разбежались, все довольны остались.
> > 
> 
> > > Имхо, всё таки - если надо получить своё ядро - и быстро, то нафиг все эти пиаровские штучки - надо просто повторять существующее ядро, с улучшениями, конечно (но, даже, и с переписыванием известного кода своими словами). А остальные извращения уже потом.
> >
> 
> не пиаровские. Ядро OS/2 (так же как и Linux)-- это устаревшая технология 20-летней давности, как правильно сказал Юрий. Почему бы не использовать более новые технологии? Которые позволяют драйверы вне ядра, динамическую заменяемость компонентов, stop/start driver и прочее?
>   
> > По этому пути один раз уже шли. osFree его назвали. Если даже начисто отбросить вопросы юридической чистоты и технической сложности, то всё равно это тупик. Ибо на выходе получится ОС с архитектурой 20-летней давности, добавить в которую что-либо интересное будет очень сложно, (а намеченное мной - невыозможно в принципе).
> 
> Только пожалуйста отметим, что osFree о котором вы говорите, это osFree TPE -- это разработка на основе нелегальных исходников -- путь, от которого современная osFree отказалась.
>

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