Как стать автором
Обновить

Комментарии 63

Ну вот, а то всё «Windows Phone», «Windows Phone»… ;-)
>Теперь эта операционная система способна запускаться и на ARM-архитектуре.
все таки скорее — «Теперь загрузчик способен запуститься на ARM»
Работы по портированию ведутся уже очень давно, очень скоро и сама ОС будет сколько-нибудь работоспособной на АРМ.
Ну да, ОС будет работать, а приложения — нет.
.NET
Не дотнетом единым…
У разработчиков порта ARM стоит цель сделать ReactOS как можно более платформенно независимым, поэтому много asm кода переписывается на си, ядро улучшают в целом, где необходимо. Так что большинство приложений думаю будут работать на нетбуках с ARM процессорами
Простите, большинство каких приложений? Если с открытым кодом и без привязки к x86 в том или ином виде, то да, скорее всего всё прекрасно будет работать. А пока обычный-то вариант ReactOS не способен запускать большинство приложений под Windows.
Ну альфа же :)
Незнаю какие программы привязаны к х86…
ВСЕ Windows only приложения!!!! ВСЕ!!!! Даже opensource! К примеру пустите мне Миранду на win mobile.
А не windows only приложениям React OS не нужна.
Не нужно брызгать слюной, заляпаете все вокруг. Если подать миранде аналог винапи с нужными вызовами для построения интерфейса, то она будет прекрасно работать, как и любое другое приложение «windows only»
Вы глубоко неправы — ассемблер arm и x86 сильно отличаются.
Не спорю, но миранда написана не на асемблере
Но тем не менее она не портабельна на другие аппаратные платформы. Её даже проблема endian'а зарубит на корню. И таких приложений в винде большинство.
Портабельными могут быть разве, что .NET аппликухи, да изначально кроссплатформенные, но кроссплатформенным прогам инвалидная коляска в виде ReactOS не нужна.
Хорошо, давайте пример:
form = new Form('title', params);
button = new Buttom( 'label', params, callback );
form.addElement( button, 100, 100 );
form.show();

Допустим это мое гипотетическое приложение (я не помню какие там функции в винапи, поэтому вот так будет). Я переношу проект на другую платформу где есть класс Form и Button, которые принимают те же параметры и возвращают такие же классы/структуры.
Вопрос: Почему мое приложение не должно работать?
Такое то будет кроссплатформенным. Но Вин софт то не такой в основном. У любителей паковать указатели в инты могут проблемы возникнуть, на armeb вообще дофига софта сразу отвалится внезапно. Все любители asmа сразу в лес пойдут.
Плюс платформы не только размерами типов отличаются, из-за union'ов могут сразу баги полезть, reinterpret_cast или c-style каст может отличаться.
Писать приложения нужно правильно, проблем не будет :)
О чем и речь, что вин онли софт редко когда правильно пишут.
Там нету проблемы endian'а. Ибо все нормальные люди уже давным давно BE, и ARM тоже. LE используется для всякого Legacy-кода, которого всё меньше.

В общем, Mirinda всяко перекомпилируется. И какой-нибудь Firefox тоже.

Может быть, конечно, ребята из ReactOS расчитывают, что какой-нибудь Adobe перекомпилирует Photoshop?
>>Там нету проблемы endian'а. Ибо все нормальные люди уже давным давно BE, и ARM тоже. LE используется для всякого Legacy-кода, которого всё меньше.

Windows NT was designed around Little Endian architecture.
Больше не пишите этого бреда… windows как и linux как и вообще x86 это little endian.

Firefox это кроссплатформенное приложение, в отличии от Миранды, которая большими болтами прибита к win32 ;)
ЗЫ
armel тоже куда чаще armeb'а встречается ;)
Ой. Точно, спасибо за поправку. Little конечно же. Я имел в виду именно то, что младший байт идёт первым. Но суть от этого не меняется, все давным давно уже перешли на один вариант раскладки, а второй остаётся в сложных процессорах для совместимости со всяким насладением.

Кстати, зачем кто-то заминусовал? Непорядок.
Значит, её надо будет минимум перекомпилировать.

А там уже возможны другие проблемы — другие размеры указателя/int, баги в reactos, etc.
Да, это уже больше похоже на проблему чем: «ВСЕ Windows only приложения!!! ВСЕ!!! Даже opensource!».
Но в 80% случаев стандартные пользовательские приложения делают нечто такое:

int i = 4;
int q = 0;
for( q = 0; q < i; q++ )
{
    // do something;
}

при правильном компиляторе длины, размеры указателей и т.д должны минимизировать проблемы до полного искоренения оных… нет?
Почему же тогда столько проблем при переходе на x64 из-за sizeof(int) != sizeof(size_t) && sizeof(int) != sizeof(void*)?
Я не знаю =) я веб, меня просто интересовал нормальный ответ на вопрос в чем причина а не фраза «winonly == onlywin»
Вот десктоп софт, особенно старый, писался на странной смеси высокоуровнего и низкоуровневого программирования без должной квалификации программистов. Для примера полазайте по сырцам Миранды.
Там даже не С++, а непонятное месиво, которое окрестили «Си с классами».
code.google.com/p/miranda/source/browse/trunk/miranda/protocols/IcqOscarJ/oscar_filetransfer.cpp
И вот подобного кода в вин онли приложениях over 9000.
Щас… over9000 вин софта делает еще вот так
a = (A*)(b);
любят штуки сравнивать знаковые и беззнаковые, любят делать портянки макросов. А еще любят юзать union'ы. Особенно уродцы типа MFC этому способствуют. Ну и конечно можно отстрелить себе ноги еще over 9000 способами, которые на некоторых платформах случайно будут стрелять мимо ноги.
Win Mobile не является прямымпортом Windows на ARM, в отличие от ReactOS
Была бы Миранда правильно написана, то была бы легко портабельной.
Ну собственно миранду запускали на WM. Не без геморроя, мягко говоря, но она запускалась.
Ну её и на amd64 даже запускают и вроде даже порт спустя 7 лет! после появления этой архитектуры на рынке уже вполне рабочий.
При желании разработчиков приложений есть winelib. Впрочем, это больше для запуска на arm-линуксах.
Впрочем, всегда можно будет перекомпилировать.
Интересно, а на фига оно? Виндовые приложения под ББ все равно пересобирать придется, а приложения с WM тоже скорее всего без допиливания операционки не пойдут.
ну, в общем, да
вин32 вне х86 — бессмысленно.
Вот если бы они реализовали WM api и сделали достойную замену глючной WM, да и несколько лет назад (когда WM была на пике), пока не было Андроида, я бы им лично памятник поставил. Но это по сути дела другую ось писать надо с названием типа ReactMobile :)
Надо запилить coredll.dll, и, если они не пинают ядро, то вполне себе спокойно запустятся.
А куча длл этих апликух с x86 кодом как на арме гонять?
Тормоз страшный и как видно из видео ReactOS для такого не нужен
Поздравляем команду ReactOS) И ждем, ждем, ждем)
Ну и зачем запускать эмулятор винды, когда для арма есть полнценный линукс? Все равно виндовой софт не пойдет.
Что такое «эмулятор винды»? O_o
Он так назвал ReactOS.
и кому оно нужно?
ReactOS вообще пишется Just for fun, если кто не в курсе.
чуваки поражают своим упорством — 15 лет уже пилят проект на стадии альфа-версии
Вы, в свободное от работы время, быстрее напишите?
Активная разработка, если я правильно помню, ведётся последние 2 или 3 года. До этого времени у них был продолжительный застой.
интересно, откуда у людей хватает ума минусовать факты? вы еще наверное и на письма со спамом отвечаете?
кстати, как там у вас с дотнетом?
Будет использоваться mono как открытый аналог, но в будующем и сам дотнет будет устанавливаться без проблем, как вариант
НЛО прилетело и опубликовало эту надпись здесь
> Загрузчик отрабатывает полностью и без ошибок, после чего корректно обращается к ядру и передает ему управление.
>

После чего система зависает? Из видео, к сожалению, непонятно загрузилось ли ядро…
А вообще если дело за пересборкой приложений под архитектуру и дальше все будет работать — то это отлично :-)
Ага размечтались… вин софт настолько испещрен x86-only костылями, что придется пол софта переписывать.
Ну да. А раз уж переписывать, так уж сразу на кроссплатформенный тулкит. Любой. И зачем тогда ReactOS?
Похвально конечно, только вот нафига оно нужно — не понятно. Ну разве что just for fun, для опыта девелопмента под ARM, да долгими зимними вечерами в черви поиграть с рабочим столом ReactOS. Никаких реальных win32 приложений без эмулятора x86 все равно запустить не получится, то есть тот-же Wine, только с еще большими костылями (архитектуры-то разные). Странно это все… Лучше бы все-таки допилили x86 версию хотя-бы до беты, сейчас даже голая ReactOS сразу после установки — это же тушите свет. Один только GUI чего стоит — шрифты сикось-накось, баги с отрисовкой окон, иногда наложение кнопок на чекбоксы, глюки с перерисовкой окон и меню, да что я рассказываю, сами все наверняка видели. Вообщем не знаю, не знаю…
НЛО прилетело и опубликовало эту надпись здесь
выше писали — just for fun )
ReactOS on ARM преследует несколько другие цели, чем, перефразируя некоторые вышесказанные комментарии, «запуск Adobe Photoshop на ARM-нетбуке». Истина как всегда где-то там, и когда придёт время — увидим.

Также, для прояснения ситуации: конечно же WinAPI программы, скомпилированные под x86/x64 не смогут запускаться на ReactOS on ARM по очевидным причинам. Перекомпилированные — да, смогут. Кроссплатформенные, исходя из названия — тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий