Разработка СУБД ЛИНТЕР и ПО на заказ
31,29
рейтинг
18 ноября 2015 в 13:25

Разработка → СУБД ЛИНТЕР и ReactOS, технические детали recovery mode

Во многом благодаря активности фонда ReactOS не будет большой ошибкой предположить, что любой постоянный читатель Хабра слышал о весьма амбициозном проекте «свободного Виндоуcа». Я не стал исключением, и еще в ходе работ по созданию системы сборки для СУБД ЛИНТЕР идея включить поддержку этой операционной системы меня посещала не раз. Совсем недавно ее удалось воплотить в жизнь.



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

Первые эксперименты: ошибка блокирующего чтения из mailslot


Начало было обнадеживающим — инсталляция Windows дистрибутива ЛИНТЕР на ReactOS проходила успешно: службы корректно регистрировались, базы создавались, сервер на первый взгляд работал исправно. Однако, первый же функциональный тест не дал ни какого результата. Никакого в прямом смысле этого слова — клиент находил локальное ядро СУБД, пытался установить соединение, однако сервер никак не реагировал на эти попытки. Было очевидно, что проблема связана с IPC. ЛИНТЕР поддерживает несколько механизмов межпроцессного взаимодействия: локальные сокеты, разделяемую память, mailslot, но именно последние как раз и были способом коммуникации тестов с ядром по умолчанию. После повторной конфигурации и пересборки тестов с использованием разделяемой памяти удалось подтвердить свое предположение — проблема заключалась в реализации mailslot под ReactOS, а при детальном исследовании удалось найти и причину: вызов функции CreateMailslot с параметром lReadTimeout = MAILSLOT_WAIT_FOREVER приводил к немедленному возврату с кодом ошибки ERROR_SEM_TIMEOUT:

hMailslotClient = CreateMailslot(LMS, 0L, MAILSLOT_WAIT_FOREVER, (LPSECURITY_ATTRIBUTES) NULL);
if (hMailslotClient == INVALID_HANDLE_VALUE)
{
    dbgError(GetLastError(),__LINE__);
    return 1;
}
Полный пример доступен по ссылке.

Был заведен соответствующий багрепорт, исправили который достаточно оперативно. Как оказалось, значение MAILSLOT_WAIT_FOREVER (-1LL) передавалось без проверки в качестве параметра timeout в функцию KeWaitForSingleObject, что являлось ошибкой, поскольку последняя оперирует не милисекундами, а сотнями наносекунд, отрицательные значения интерпретируются как относительный таймаут, а положительные — как абсолютный, т. е. до исправления этой ошибки MAILSLOT_WAIT_FOREVER для ReactOS равнялся 100 наносекундам.
Отчет работы патчбота доступен по ссылке.

Ошибка асинхронного чтения из слота


Проблема с таймаутами оказалась не единственной проблемой в реализации mailslot – практически сразу после начала коммуникации клиентского приложения с ядром поисходили deadlock-и слота. Начав искать причину я обнаружил, что драйвер mailslot file system (msfs.sys) в реализации ReactOS не поддерживает асинхронное чтение из слота:

 if (!ReadFile(hMailslotClient, lpszBuffer, LENMSG, &cbRead, &stOverlapped))
    {
        //ERROR_IO_PENDING (997) is not a failure!!
        dbgError(GetLastError(),__LINE__);

        _tprintf(TEXT("starting writer...\n"));
        startWriter();

        if (!GetOverlappedResult( hMailslotClient, &stOverlapped, &cbTr, TRUE))
        {
            dbgError(GetLastError(),__LINE__);
            return 1;
        }
    }
Полный пример доступен по ссылке.

Новый багрепорт уже не был так стремительно закрыт, что и понятно, учитывая объем исправлений. Поэтому я решил посодействовать доработке драйвера, хотя, признаюсь, последний раз драйвер для Windows писал в студенческие времена.
Мои доработки msfs.sys сводились к обработке IRP пакетов с помощью Cancel-Safe IRP очередей, что позволило организовать асинхронное чтение из слота. Не самый изящный вариант, однако достаточно простой и надежный. Правки были добавлены в коммите 69475, после чего удалось успешно «прогнать» все функциональные тесты ядра ЛИНТЕР.
Отчет работы патчбота доступен по ссылке.

Ошибки в mbstowcs и wcstombs


Последние найденные мной ошибки в ReactOS изначально «всплыли» в виде артефактов в строках графических интерфейсов средств администрирования ЛИНТЕР. Все эти приложения построены на базе нашей кросплатформенной UI библиотеки — RelAPI. Как выяснилось, самые безобидные баги оказались проявлением самых серьезных ошибок в ReactOS: функций mbstowcs и wcstombs не обрабатывали должным образом ситуации, когда первые параметом был NULL:

char rosStr[BUFFER_SIZE] = "Reactos";
cnt = mbstowcs(NULL,rosStr,BUFFER_SIZE);

wchar_t rosStr[BUFFER_SIZE] = L"Reactos";
cnt = wcstombs(NULL,rosStr,BUFFER_SIZE);
Полный пример доступен по ссылке.

Соответствующий багрепорт был достаточно оперативно закрыт, что позволило довести испытания работы нашего продукта под управлением ReactOS до конца.
Отчет работы патчбота доступен по ссылке.

Испытание железом


В обсуждении ReactOS часто проскакивают вопросы в духе «а работает ли эта ОС на реальном современном железе?» — в моем случае ответ утвердительный: да работает, но не без проблем. Первая из них заключалась в неработоспособности ehci контроллера, usb клавиатура и мышь, успешно эмулировались BIOS-ом как legacy и работали, но ровно до тех пор пока драйвер usbehci.sys не резетил контроллер, поэтому пришлось от него (драйвера) отказаться, со всеми вытекающими последствиями в виде неработающих USB устройств. Второй проблемой оказалась нестабильная работа ОС, которая периодически «падала» в BSOD в hdaudbus.sys (драйвер шины для High Definition Audio). Эту проблему удалось решить отключив соответствующий контроллер в настройках BIOS.
После всех произведенных манипуляций система под управлением ReactOS (билд 20151025-r69700) работала стабильно и позволяла «прогнать» все необходимые тесты и замеры производительности.
Все эксперименты проводились на оборудовании:
pechenkin@big:~$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0100] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b5)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev b5)
00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b5)
00:1c.5 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 [8086:1c1a] (rev b5)
00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
00:1f.0 ISA bridge [0601]: Intel Corporation Z68 Express Chipset Family LPC Controller [8086:1c44] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller [8086:1c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 05)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF104 [GeForce GTX 460] [10de:0e22] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GF104 High Definition Audio Controller [10de:0beb] (rev a1)
03:00.0 PCI bridge [0604]: Integrated Technology Express, Inc. Device [1283:8892] (rev 10)
05:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01)
06:00.0 USB controller [0c03]: Etron Technology, Inc. EJ168 USB 3.0 Host Controller [1b6f:7023] (rev 01)

Результат работы теста TPC-B на ReactOS для fat32, размер пула ЛИНТЕРа — 390 Мб.:
Mode     = PESSIMISTIC 
Accounts = 1000
....
Transactions:       817600 
Working time:       299 seconds 
Speed = 2727.333 tps


Результат работы теста TPC-B на Windows 7, fat32, размер пула ЛИНТЕРа — 390 Мб.:
Mode     = PESSIMISTIC 
Accounts = 1000
....
Transactions:       688400 
Working time:       299 seconds 
Speed = 2298.881 tps 


Немного субъективного


ReactOS находится сейчас в состоянии альфа, о чем честно сообщает официальный сайт проекта и не пригодна к использованию в продакшне, однако у меня сложилось впечатление, что в случае необходимости ОС в приемлемые сроки можно довести «до ума» для работы на конкретном оборудовании с ограниченным набором программного обеспечения. Коме того, считаю, что для любителей «завести» железо или покопаться во внутренностях ОС этот проект, вне всякого сомнения будет интересен. Отдельно стоит отметить доброжелательность сообщества ReactOS и его ориентированность на достижение результата.
Автор: @npechenkin
РЕЛЭКС
рейтинг 31,29
Разработка СУБД ЛИНТЕР и ПО на заказ

Комментарии (55)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка