Комментарии 63
Ну вот, а то всё «Windows Phone», «Windows Phone»… ;-)
+20
>Теперь эта операционная система способна запускаться и на ARM-архитектуре.
все таки скорее — «Теперь загрузчик способен запуститься на ARM»
все таки скорее — «Теперь загрузчик способен запуститься на ARM»
+13
Работы по портированию ведутся уже очень давно, очень скоро и сама ОС будет сколько-нибудь работоспособной на АРМ.
+3
Ну да, ОС будет работать, а приложения — нет.
+5
.NET
-1
У разработчиков порта ARM стоит цель сделать ReactOS как можно более платформенно независимым, поэтому много asm кода переписывается на си, ядро улучшают в целом, где необходимо. Так что большинство приложений думаю будут работать на нетбуках с ARM процессорами
+1
Простите, большинство каких приложений? Если с открытым кодом и без привязки к x86 в том или ином виде, то да, скорее всего всё прекрасно будет работать. А пока обычный-то вариант ReactOS не способен запускать большинство приложений под Windows.
0
Ну альфа же :)
Незнаю какие программы привязаны к х86…
Незнаю какие программы привязаны к х86…
0
ВСЕ Windows only приложения!!!! ВСЕ!!!! Даже opensource! К примеру пустите мне Миранду на win mobile.
А не windows only приложениям React OS не нужна.
А не windows only приложениям React OS не нужна.
-2
Не нужно брызгать слюной, заляпаете все вокруг. Если подать миранде аналог винапи с нужными вызовами для построения интерфейса, то она будет прекрасно работать, как и любое другое приложение «windows only»
+1
Вы глубоко неправы — ассемблер arm и x86 сильно отличаются.
+1
Не спорю, но миранда написана не на асемблере
0
Но тем не менее она не портабельна на другие аппаратные платформы. Её даже проблема endian'а зарубит на корню. И таких приложений в винде большинство.
Портабельными могут быть разве, что .NET аппликухи, да изначально кроссплатформенные, но кроссплатформенным прогам инвалидная коляска в виде ReactOS не нужна.
Портабельными могут быть разве, что .NET аппликухи, да изначально кроссплатформенные, но кроссплатформенным прогам инвалидная коляска в виде ReactOS не нужна.
+1
Хорошо, давайте пример:
form = new Form('title', params);
button = new Buttom( 'label', params, callback );
form.addElement( button, 100, 100 );
form.show();
Допустим это мое гипотетическое приложение (я не помню какие там функции в винапи, поэтому вот так будет). Я переношу проект на другую платформу где есть класс Form и Button, которые принимают те же параметры и возвращают такие же классы/структуры.
Вопрос: Почему мое приложение не должно работать?
form = new Form('title', params);
button = new Buttom( 'label', params, callback );
form.addElement( button, 100, 100 );
form.show();
Допустим это мое гипотетическое приложение (я не помню какие там функции в винапи, поэтому вот так будет). Я переношу проект на другую платформу где есть класс Form и Button, которые принимают те же параметры и возвращают такие же классы/структуры.
Вопрос: Почему мое приложение не должно работать?
0
Такое то будет кроссплатформенным. Но Вин софт то не такой в основном. У любителей паковать указатели в инты могут проблемы возникнуть, на armeb вообще дофига софта сразу отвалится внезапно. Все любители asmа сразу в лес пойдут.
Плюс платформы не только размерами типов отличаются, из-за union'ов могут сразу баги полезть, reinterpret_cast или c-style каст может отличаться.
Плюс платформы не только размерами типов отличаются, из-за union'ов могут сразу баги полезть, reinterpret_cast или c-style каст может отличаться.
0
Там нету проблемы endian'а. Ибо все нормальные люди уже давным давно BE, и ARM тоже. LE используется для всякого Legacy-кода, которого всё меньше.
В общем, Mirinda всяко перекомпилируется. И какой-нибудь Firefox тоже.
Может быть, конечно, ребята из ReactOS расчитывают, что какой-нибудь Adobe перекомпилирует Photoshop?
В общем, Mirinda всяко перекомпилируется. И какой-нибудь Firefox тоже.
Может быть, конечно, ребята из ReactOS расчитывают, что какой-нибудь Adobe перекомпилирует Photoshop?
0
>>Там нету проблемы endian'а. Ибо все нормальные люди уже давным давно BE, и ARM тоже. LE используется для всякого Legacy-кода, которого всё меньше.
Windows NT was designed around Little Endian architecture.
Больше не пишите этого бреда… windows как и linux как и вообще x86 это little endian.
Firefox это кроссплатформенное приложение, в отличии от Миранды, которая большими болтами прибита к win32 ;)
Windows NT was designed around Little Endian architecture.
Больше не пишите этого бреда… windows как и linux как и вообще x86 это little endian.
Firefox это кроссплатформенное приложение, в отличии от Миранды, которая большими болтами прибита к win32 ;)
0
ЗЫ
armel тоже куда чаще armeb'а встречается ;)
armel тоже куда чаще armeb'а встречается ;)
0
Ой. Точно, спасибо за поправку. Little конечно же. Я имел в виду именно то, что младший байт идёт первым. Но суть от этого не меняется, все давным давно уже перешли на один вариант раскладки, а второй остаётся в сложных процессорах для совместимости со всяким насладением.
Кстати, зачем кто-то заминусовал? Непорядок.
Кстати, зачем кто-то заминусовал? Непорядок.
0
Значит, её надо будет минимум перекомпилировать.
А там уже возможны другие проблемы — другие размеры указателя/int, баги в reactos, etc.
А там уже возможны другие проблемы — другие размеры указателя/int, баги в reactos, etc.
0
Да, это уже больше похоже на проблему чем: «ВСЕ Windows only приложения!!! ВСЕ!!! Даже opensource!».
Но в 80% случаев стандартные пользовательские приложения делают нечто такое:
при правильном компиляторе длины, размеры указателей и т.д должны минимизировать проблемы до полного искоренения оных… нет?
Но в 80% случаев стандартные пользовательские приложения делают нечто такое:
int i = 4; int q = 0; for( q = 0; q < i; q++ ) { // do something; }
при правильном компиляторе длины, размеры указателей и т.д должны минимизировать проблемы до полного искоренения оных… нет?
0
Почему же тогда столько проблем при переходе на x64 из-за sizeof(int) != sizeof(size_t) && sizeof(int) != sizeof(void*)?
0
Я не знаю =) я веб, меня просто интересовал нормальный ответ на вопрос в чем причина а не фраза «winonly == onlywin»
0
Вот десктоп софт, особенно старый, писался на странной смеси высокоуровнего и низкоуровневого программирования без должной квалификации программистов. Для примера полазайте по сырцам Миранды.
Там даже не С++, а непонятное месиво, которое окрестили «Си с классами».
code.google.com/p/miranda/source/browse/trunk/miranda/protocols/IcqOscarJ/oscar_filetransfer.cpp
И вот подобного кода в вин онли приложениях over 9000.
Там даже не С++, а непонятное месиво, которое окрестили «Си с классами».
code.google.com/p/miranda/source/browse/trunk/miranda/protocols/IcqOscarJ/oscar_filetransfer.cpp
И вот подобного кода в вин онли приложениях over 9000.
0
Щас… over9000 вин софта делает еще вот так
a = (A*)(b);
любят штуки сравнивать знаковые и беззнаковые, любят делать портянки макросов. А еще любят юзать union'ы. Особенно уродцы типа MFC этому способствуют. Ну и конечно можно отстрелить себе ноги еще over 9000 способами, которые на некоторых платформах случайно будут стрелять мимо ноги.
a = (A*)(b);
любят штуки сравнивать знаковые и беззнаковые, любят делать портянки макросов. А еще любят юзать union'ы. Особенно уродцы типа MFC этому способствуют. Ну и конечно можно отстрелить себе ноги еще over 9000 способами, которые на некоторых платформах случайно будут стрелять мимо ноги.
0
Win Mobile не является прямымпортом Windows на ARM, в отличие от ReactOS
+2
Ну собственно миранду запускали на WM. Не без геморроя, мягко говоря, но она запускалась.
0
При желании разработчиков приложений есть winelib. Впрочем, это больше для запуска на arm-линуксах.
Впрочем, всегда можно будет перекомпилировать.
Впрочем, всегда можно будет перекомпилировать.
0
Интересно, а на фига оно? Виндовые приложения под ББ все равно пересобирать придется, а приложения с WM тоже скорее всего без допиливания операционки не пойдут.
0
ну, в общем, да
вин32 вне х86 — бессмысленно.
вин32 вне х86 — бессмысленно.
+2
Надо запилить coredll.dll, и, если они не пинают ядро, то вполне себе спокойно запустятся.
+1
А куча длл этих апликух с x86 кодом как на арме гонять?
0
Как-то так:
www.youtube.com/watch?v=n3v4YC9RT-g
www.youtube.com/watch?v=n3v4YC9RT-g
0
Поздравляем команду ReactOS) И ждем, ждем, ждем)
+5
Ну и зачем запускать эмулятор винды, когда для арма есть полнценный линукс? Все равно виндовой софт не пойдет.
-5
и кому оно нужно?
-5
чуваки поражают своим упорством — 15 лет уже пилят проект на стадии альфа-версии
-7
кстати, как там у вас с дотнетом?
0
НЛО прилетело и опубликовало эту надпись здесь
это дорогущий девайс, овер 1000 долларов, от TI
focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=53575&DCMP=wtbu_zoom&HQS=Other+PR+zoom2_technical
focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=53575&DCMP=wtbu_zoom&HQS=Other+PR+zoom2_technical
+1
> Загрузчик отрабатывает полностью и без ошибок, после чего корректно обращается к ядру и передает ему управление.
>
После чего система зависает? Из видео, к сожалению, непонятно загрузилось ли ядро…
>
После чего система зависает? Из видео, к сожалению, непонятно загрузилось ли ядро…
+2
А вообще если дело за пересборкой приложений под архитектуру и дальше все будет работать — то это отлично :-)
+1
Похвально конечно, только вот нафига оно нужно — не понятно. Ну разве что just for fun, для опыта девелопмента под ARM, да долгими зимними вечерами в черви поиграть с рабочим столом ReactOS. Никаких реальных win32 приложений без эмулятора x86 все равно запустить не получится, то есть тот-же Wine, только с еще большими костылями (архитектуры-то разные). Странно это все… Лучше бы все-таки допилили x86 версию хотя-бы до беты, сейчас даже голая ReactOS сразу после установки — это же тушите свет. Один только GUI чего стоит — шрифты сикось-накось, баги с отрисовкой окон, иногда наложение кнопок на чекбоксы, глюки с перерисовкой окон и меню, да что я рассказываю, сами все наверняка видели. Вообщем не знаю, не знаю…
+1
НЛО прилетело и опубликовало эту надпись здесь
ReactOS on ARM преследует несколько другие цели, чем, перефразируя некоторые вышесказанные комментарии, «запуск Adobe Photoshop на ARM-нетбуке». Истина как всегда где-то там, и когда придёт время — увидим.
Также, для прояснения ситуации: конечно же WinAPI программы, скомпилированные под x86/x64 не смогут запускаться на ReactOS on ARM по очевидным причинам. Перекомпилированные — да, смогут. Кроссплатформенные, исходя из названия — тоже.
Также, для прояснения ситуации: конечно же WinAPI программы, скомпилированные под x86/x64 не смогут запускаться на ReactOS on ARM по очевидным причинам. Перекомпилированные — да, смогут. Кроссплатформенные, исходя из названия — тоже.
+4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ReactOS: загрузка на ARM