Pull to refresh

Comments 55

Странно, что на таком этапе есть ошибки в таких «core» вещах.
По результатам сотрудничества этих ошибок больше нет. А были они потому, что баг-репорты до этого случая никто не присылал.
Я с другой стороны предлагал посмотреть — столько ПО уже работает, но на эти вещи не натыкались.
Кстати, отвлеченный вопрос, я как-то изучал исходники NT и видел, что в некоторых местах кода ядра Windows есть заплатки под конкретное ПО, которое на какие-то особенности ОС рассчитывает, баги или фичи, и MS пришлось их поддержать, чтобы от версии к версии готовое ПО не падало. Есть такое в ReactOS?
Такого нет. Мы ориентируемся на то ПО, по которому к нам поступают баг-репорты. Большинство баг-репортов приходит на относительно свежие версии программ. Во всех случаях мы максимально стараемся писать универсальный код и избегать хаков, на сколько это возможно. Т.е. в идеале код должен хорошо работать с разными программами, а не с одной конкретной.

В будущем мы добавим систему обеспечения режима совместимости, но она насчитана в первую очередь будет не на хаки, фичи и баги, а на корректную эмуляцию поведения разных версий Windows (в случае, если ПО пиcалось под конкретную версию API)
Лучше делать как MS сделала — различные отдельные исправления как кирпичики, к каждому приложению можно подобрать нужные недостающие кирпичики. Просто потому что нередко эмулировать поведение всех особенности древней ОС для правильной работоспособности не нужно и даже вредно (для производительности).
А возможность построить цельный блок (шаблон конкретной версии API) тоже никуда не пропадает.
У МС была строгая необходимость. Потому что если у клиента после перехода с 95 на 98, например, перестанет работать фотошоп, «крайними» будут МС. И объяснять, что накосячили не они — долго. Ждать багфиксов — долго. А клиента потерять — на раз и репутации конец. Поэтому в win полно таких хаков, когда эмулируется неправильное поведение ради программы, которая опиралась на недокументированное нечто. При этом программа слишком популярна, чтобы это игнорировать.

Такие истории описаны в блоге Рэймонда Чена.
Я это прекрасно знаю, вопрос состоял в том, есть ли подобные вещи в реактос.
Пояснение, тем не менее, может быть полезным кому-то еще из читателей.
Для этого и написал. Кроме того, может кто-то еще не знает про Oldnewthings.
Они уже давно вынесли это из ядра и есть специальная база совместимости, можно свои подключать (SDB). То что в свойства exe/ярлыка это лишь верхушка айсберга и просто набор типичных исправлений для какой-то из версий ОС. Поставив Application Compatibility Toolkit можно самому создавать такие базы. Так уже заставил работать не одну игрушку.
Речь шла про совсем грязные хаки, которые присутствуют, например, в цикле обработки сообщений (GUI). Такие вещи не вынесешь никуда при всем желании :)
Почему это не вынесешь? По конкретнее можно? Пример?
Проверка имени процесса (грубый пример L«devenv.exe») в цикле обработки сообщений, для того чтобы слать или не слать какое-то специфичное оконное сообщение (WM_...).
А в чём проблема это вынести? Базу sysmain.sdb видели? Мы можем и свою sdb подключить к этому механизму.
Механизм совместимости проверяет наличие в базах нужного приложения и если оно там есть к нему применяются исправления. В том числе нет проблемы изменить поведение сообщений.
Там вообще более 400 самых разных исправлений, некоторые из них очень специфичные (всякая эмуляция некоторых механизмом Win95). В общем вперёд на Application Compatibility Toolkit смотреть.
Обманывать можно и иначе, через драйвер можно любое нужное поведение проэмулировать.
Спасибо за ссылку.
И не надо забывать что ReactOS на сегодняшний день 32 разрядная операционка, так использование её с серверами БД выглядит достаточно надуманно
ReactOS позиционируется как бесплатная ОС для клиентских машин. В своё время пытались заинтересовать ею одного из ведущего LIMS вендора для удешевления развертывания клиентов, но система оказалась слишком сырой.
… так использование её с серверами БД выглядит достаточно надуманно

Не стоит рассматривать эту публикацию с точки зрения «как построить сервер БД на ReactOS», я хотел показать то, как последовательная проверка готового продукта быстро и легко позволяет выявить ошибки (а значит и сделать первый шаг к исправлению) в ОС. Именно Линтер тут появляется по простой причине — это проект, в котором я принимаю непосредственное участие.
Это напоминает то, как Торвальдс писал ядро (по just for fun) — все нереализованные вызовы имели заглушки, выдавашие соотв. предупреждение. Потом он прогонял bash, и смотрел, что еще надо сделать.

На реальной задаче тестирование и быстрее, и интереснее.
Команда проекта ReactOS выражает свою признательность компании РЕЛЭКС за оказанную помощь.

Хотим отметить, что подобное сотрудничество с еще 5-10 компаниями позволило бы ReactOS перешагнуть порог бета-версии в кратчайшие сроки. Мы открыты для взаимодействия.

P.S. у нас через месяц выходит «эпохальный» релиз. 0.4. Поэтому предлагаем всем заинтересованным поспешить со своими баг-репортами и патчами, чтобы они попали в эту версию.
>ОС в приемлемые сроки можно довести «до ума» для работы на конкретном оборудовании с ограниченным набором программного обеспечения

Не проще ли этот ограниченный набор ПО переписать под Линукс?

Смысл в ReactOS только один — запускать все (или почти все) существующие и будущие программы для Windows. А оказывается, в приемлемые сроки с финансированием это не получается?
А оказывается, в приемлемые сроки с финансированием это не получается?

Это откуда следует?
«однако у меня сложилось впечатление, что в случае необходимости ОС в приемлемые сроки можно довести «до ума» для работы на конкретном оборудовании с ограниченным набором программного обеспечения.»

То есть в приемлемые сроки с финансированием не получается.
Не могу понять цепь Ваших логических рассуждений, которые приводят к такому выводу. Автор утверждает как раз обратное, что разумных денег и разумного времени должно хватить для подготовки ReactOS к работе в продакшене.
Он цепляется за слова «ограниченный набор программ». Парируя, что, мол, должно работать с неограниченным набором, ибо это смысл ReactOS.
Для продакшена как раз-таки не нужен неограниченный список программ, зато нужна очень хорошая работа программ из списка.
Так список-то у всех свой и таких списков много. Нет пробле запускать стандартные программы, есть проблема запускать самописные либо неподдерживаемые.
Не проще ли этот ограниченный набор ПО переписать под Линукс?

Проще, конечно же, но не всегда возможно или же разработчики не считают это необходимым. Косвенным подтверждением чего может служить тот факт, что wine и его побочные продукты вполне себе востребованы.

То есть в приемлемые сроки с финансированием не получается.

Я, возможно, как-то двусмысленно написал, но все описанное в этой публикации делалось бесплатно.
Мысль была следующая: я считаю, что если сообщество разработчиков ReactOS мотивировать (м.б. и финансово) сконцентрировать усилия на узкой задаче, то результат будет положительный. Не знаю, что об этом думают сами разработчики, но мне в качестве такой задачи, например, видится замена предустановленной FreeDOS на предустановленную ReactOS у какого-нибудь производителя ноутбуков.
Лично знаю контору, которая закупила разработку софта для обслуживания склада. Стоило это полмиллиона долларов. Случилось это во время расцвета Windows NT.
Софт на Win2k запустили с трудом, на 2003 сервер половина софта не запускается, исходников нет, за долгие годы потеряно много чего.
Платить сейчас полмиллиона долларов — невыгодно, поскольку софт работает. Что смогли виртуализировали (ту же NT виртуализировать сложнее чем 2к сервер).

А недавно была статья про то, что в аэропорту что-то под досом работает до сих пор.

Адекватный и рабочий ReactOS для таких проектов — весьма интересен. Причем то, что он в первую очередь виртуализируется, а уже потом работает на реальном железе, даже полезнее с точки зрения апгрейда железа.
Что за склад такой, что софт для него пол-миллиона стоит? Склад ядерного оружия?
вы считаете, что полмиллиона это много?
10-20 человек с средней зп в 2-3 килобаксов, да плюс налоги — за полгода и нет полмиллиона. Склад для крупной оптово-розничной компании, с автоматическим конвейером. Я даже не могу сказать что это крупная фирма. Так, чуть выше середнячка.
И таких компаний много. В общем просто стоит помнить, что есть огромное количество софта, который переписать — слишком дорого, чем просто заставить его работать на современном железе при помощи виртуализации. А reactOS дает надежду на его использование в будущем, ведь win 3.x, 9x, NT, 2k, xp — вдобавок официально никак нельзя купить, если нужно чуток расшириться.
По идее, более новые лицензии покрывают старые, нет? Например, ПК с предустановленной 8/7 можно downgrade'ить до XP — лицензия покрывает.
предустановленных серверов я что-то не припомню, и даунгрейд без поддержки драйверов — как вы себе это представите? Windows NT сейчас можно поставить только в виртуалку, на реальном современном железе она уже не пойдет. Но в виртуалке она себя ведет хуже чем 2k
Полно железа на котором пойдёт. У народа море Xeon'ов осталось. В моей досягаемости ещё недавно были ненадёванные процессоры. Они без охлаждения кулерного, поэтому вечные.
А что делать с отсутствием SATA в WinNT?
Есть ненадеванные IDE?

В общем виртуализация пока что сильно выручила, позволив апгрейднуть железо. Но опять таки, компаний, у которых полно древнего проприетарного софта, и в которых этот софт работает НАДЕЖНО, и денег на его адаптацию нет — для них реактос был бы реальный выход.
Вроде бы есть контроллеры, которые работают в режиме legacy-совместимости?
Он был бы, если бы его было реально довести до уровня windows NT. Но для этого компания должна дорости до уровня Microsoft.

С периферией правда беда. Насчёт виртуализации согласен.
При чем здесь драйвера? Вы сказали
вдобавок официально никак нельзя купить

При этом, я не уверен, что так можно только с предустановленной. Вполне допускаю, что вы можете купить лицензию на, скажем, 8ку и покрыть ею более старую NT, надо посмотреть лицензию.
Я считаю, что если это софт уникальный в одном экземпляре — то немного. Но тогда никуда его запустить кроме того на чём он был написан не удастся за разумные деньги.
Например, «склад» нефтепродуктов. Пол-миллиона — это немного.
Не знаю, уместно ли давать Вам свои советы, но можно попробовать обкатать ReactOS на некоторых Embedded-решениях. Например, на ПО терминалов Qiwi и им подобным, которые работают поверх Windows. Если последнюю удаётся заменить ReactOS, то удаётся сэкономить: у производителей/владельцев терминалов есть денежный интерес. С другой стороны, набор ПО и «железа» ограничены какими-то рамками, поэтому видится возможность доработать ReactOS до необходимого уровня. В форс-мажорном случае производители/владельцы терминалов могут просто возвратиться на Windows, т.е. они застрахованы от рисков. Можно так же вспомнить о различных кассовых системах. Например, ПО RKeeper для ресторанов. Или кассовые терминалы в магазинах. Там так же минимальный набор ПО и небольшой разброс в «железе».
Более дорогое портирование, если оно вообще возможно, к примеру.
Хотите сказать, что из болота тащить бегемота довести до ума реактос будет дешевле, чем портировать кривульку платежного терминала под linux? Это Вы серьезно?
За оформление тикетов фонд ReactOS вроде денег пока не берет.
А время? Время — деньги. Linux готов к использованию уже сегодня.
Кто сказал, что нужно быстро? Комментарий в корне этой ветки ничего не говорил про время. В добавок, скорее всего, поправить пару багов в операционке будет явно быстрее, чем писать с нуля софт, исходники которого или потеряны или уж слишком в low level winnt/win32. К примеру софт, который требует еще и свои специфичные драйвера.
Кто сказал, что нужно быстро?

Бизнесу всегда нужно быстро. Смысл что-то там обкатывать, когда есть готовые решения.
Очевидно, что правкой пары багов дело не ограничится. Тут такое гигантское количество человеко-часов, что даже думать страшно. Как забава для гиков — да, а так — не серьезно все это.
Тот же RKeeper не будет работать под Wine и его будет реально дольше и дороже портировать, чем в бэкграунде тестировать с ReactOS и отправлять багрепорты сообществу.
Во-первых, Вы точно не знаете, что в итоге окажется дороже.
Во-вторых, из любого правила есть исключения, и я не отрицаю, что в каких-то случаях (думаю, что их будет довольно мало) адаптация существующего ПО под реакт может оказаться более выгодной, чем переписывание.
Как адаптация в стиле «взял и запустил» (либо заработало сразу, либо пара тикетов и заработало) будет дороже переписывания софта, исходников которого уже скорее всего нет, на другую ОС?
Вы упомянули время, но в условиях тех же терминалов, которые пока что могут поработать еще пару месяцев на винде, по моему деньги важнее времени.
Я уже на трех-четырех ярких примерах прикинул. Вы будете правы только касательно какого нибудь .Net. И я замечательно знаю насколько «быстро и легко» портировать pure winapi/mfc/winnt на другие платформы. А еще веселее работать с кодом, написанном в каком-нибудь Borland C++ Bulder первой версии с использованием Active-x и прочей пакости. Причем миграция проекта с первой на шестую версию занимает около четырех недель. И это еще не гарантирует работоспособного приложения. Оно просто соберется. А такого внутреннего софта в корпорациях мегатонны.
Причем миграция проекта с первой на шестую версию занимает около четырех недель. И это еще не гарантирует работоспособного приложения.

Это ещё не значит, что переписывание того же с нуля обошлось бы дороже.



Если Вы читали Брукса и помните такой график, то, должно быть, согласитесь, что по мере возрастания функции вероятность того, что переписывание проекта окажется дешевле внесения изменений увеличивается. Это знают крупные разработчики. Восьмая версия 1С не совместима с седьмой, думаете просто так? Разработчики браузеров меняют движки как перчатки, да и ms периодически обновляет внутрянку Windows, а эти ребята умеют считать деньги.
Я всего лишь заметил, что правка пары багов в ОС будет быстрее чем полный цикл разработки. А вообще мы говорили про портирование, а не прикручивание новых фич.

Разработчики браузеров держатся за свои творения до последнего. Mozilla только разрабатывает Servo, Microsoft только недавно выпустил Edge. Blink, на сколько я помню, является форком WebKit.

Я вам расскажу по секрету, что ядро nt за эти годы не сильно изменилось. Окружение меняется, да и то не так радикально.
А зачем вообще запускать Линтер (это же тот же Линтер, что и Линтер-ВС? ), который есть просто старый PostgreSQL на ReactOS, когда Линтер вполне успешно работает на том на чем он предназначен — на Linux, в том числе в его российской вариации — МСВС\Astra Linux (это только то, под что я ставил Линтер лично). Последний из которых доступен бесплатно, с исходниками и намного менее альфа, чем ReactOS?
это же тот же Линтер, что и Линтер-ВС

Нет, Линтер-ВС не наш продукт. Тут такая история: давным-давно нами (компанией РЕЛЭКС) была разработана для МО РФ система Линтер-ВС на базе актуальной тогда коммерческой версии ЛИНТЕР 5.7, которая никогда ничего общего не имела с каким бы то ни было сторонним продуктом. Но в последующих релизах ОС МСВС наша Линтер-ВС была заменена на форк PostgreSQL с названием Линтер-ВС 6.0.1, которую уже разрабатывает и поддерживает ВНИИНС.
Sign up to leave a comment.