Pull to refresh

Comments 128

«Я просмотрел код ReactOS, и по моему мнению у разработчиков не было никакой возможности написать систему с нуля, используя лишь открытую документацию».

Ну это, строго говоря, разговоры в пользу бедных.

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

А вот это уже серьезнее. Но нужны примеры и доли совпадений, а то если там какой-нибудь макрос вида get_length в венгерской нотации, то было бы странно, если бы не совпадало.
Вы смотрели по ссылкам в статье?
Смотрел, а толку-то? Я же даже не WinAPI разработчик. Ну используется там макрос begin_ntddk, ну и что мне это даст? Ну вроде есть в доках аббревиатура ntddk, ну могли наверное что-то использовать. Но не будучи ни разработчиком ядра Windows, ни разработчиком ReactOS, я мог бы с тем же успехом сравнивать египетские иероглифы с китайскими и строить теории о происхождении письменности.
Вот в том-то и дело что вы «даже не WinAPI разработчик», поэтому рассуждаете как обыватель, ибо любой разработчик понимает что столько похожих названий макросов в коде системы, написанной с нуля, быть не может.
Вот сейчас посмотрел сюда, что тут происходит, и обнаружил что 31 пользователь потопил меня, а уважаемого DarthVictor-а возвели в плюсы.

Так вот, у меня аналогичный вопрос к DarthVictor-у, а какого лешего вы собираетесь сравнивать китайскую и египетскую письменности, если вы с этим так же близко, как какашка обезьяны и Юпитер? Извините, в статье приводится сведение, что код сравнивал один из людей, которые относятся к разработке Windows. если я правильно помню.

«Смотрел, а толку-то?» Вот этой фразой, наверное, вы и не заметили, как могли сказать о себе информацию, которую лучше бы в слух не произносить. Если нет толка в том, что вы смотрите, то стоит задуматься.

Всего хорошего вам.

P.S. Перечитал здесь всё и понял, что нефиг было даже начинать лезть сюда, потому что смысла в этом никакого с самого начала.
P.P.S. Просто если вы сами пишите, что не разбираетесь не в том не в этом, и такой же смысл, как изучать письменности без необходимой базы — так почему дали самый первый комментарий по поводу совпадений в коде сами?
Да, продолжайте, продолжайте, всем вашим собеседникам и случайным читателям так интересны ваши нравоучения, что аж поджилки трясутся.
Да в том-то и дело, что навряд-ли. А где я какими-то нравоучениями занимался, покажите?
уже судились(вроде SUN) на тему "#define TRUE 1" и подобного

Мне не сложно скинуть примеры ссылок с Hacker News. Действительно, в некоторых местах код подозрительно похож, вплоть до названий и порядка объявления локальных переменных.


Код файла balmgr.c: в репозитории Реактос, в Windows Research Kernel


Обратите внимание на функции KeBalanceSetManager и KiScanReadyQueues. Вот, что странно:


  • общая структура файловой системы, имена папок и файлов (ke/balmgr.c)
  • названия локальных переменных в KeBalanceSetManager: DueTime, ScanDpc, PeriodTimer, WaitObjects
  • закомментированный код внутри swicth в KeBalanceSetManager, аналогичный коду из винды. Если присмотреться, он ничего не делает. Зачем тогда его добавили в реактос? И откуда там закомментированный код?
  • хотя комментарии в KeBalanceSetManager и разные, но они находятся в одинаковых местах и одинаково разбивают код:

// Комментарий
 KeSetPriorityThread(...);
// Комментарий
KeInitializeTimerEx(...);
KeInitializeDpc(...);
...
// Комментарий
WaitObjects[..] = ...;
// Комментарий
do {
// Комментарий
Status = KeWaitForMultipleObjects...

  • имена локальных переменных в KiScanReadyQueues(): ScanIndex, ScanLast, Summary, OldIrql, Index, ListHead, Prcb, Thread, Count, Number.
  • последовательность присваиваний локальным переменным. В WRK:
    Count = 0
    Number = 0
    ScanLast =…
    ScanIndex =… (я беру ветку без try)
    Count =…
    Number =…
    Prcb =…
    Index =…
    WaitLimit =…
    Summary =…
    В реактосе:
    ScanLast =…
    ScanIndex =…
    Count =…
    Number =…
    Prcb =…
    Index =…
    WaitLimit =…
    OldIrql =…
    Summary = ....
  • посмотрите на большой цикл в KiScanReadyQueues() и поищите отличия. Там даже ассерты есть похожие вроде ASSERT(!IsListEmpty(&Prcb->DispatcherReadyListHead[Index]));

Этот файл был закоммичен в реактос 13 лет назад Alex Ionescu.


Другой пример — код функции KeInitThread() в Реактос и в Windows Research Kernel. Опять же, даже названия файлов почти одинаковы, как и содержимое функций.


Сравните функцию KiInitializeContextThread() в реактос и в Windows. Опять, одинаковое имя файла. Посмотрите на код после строки "if (KeI386FxsrPresent)". Структуры заполняются в одинаковом порядке. Числа 0x27F и 0x1F80 в обоих случаях написаны как числа, без констант, и в 16-чном виде.


Особо интересна строка TrFrame->DbgArgMark = 0xBADB0D00; в коде Реактос. В майкрософтовском коде она окружена условием #if DBG и по-видимому, должна отсутствовать в продакшен-версии.


Мне кажется, команде Реактос стоило бы бросить клич, найти добровольцев, которые сравнят код там и там, и удалить тот, что слишком одинаковый.

UFO just landed and posted this here
А это законно? То есть в чем принципиальное отличие получения информации о внутреннем устройстве через отладочную сборку и через, скажем, дизассемблирование.
Дизассемблирование с целью обеспечения совместимости законно.

Допустим, даже отладочная сборка содержит код целиком (хотя я сомневаюсь; в презентации говорилось лишь об ассертах, которые содержат код внутри макроса, и символах, содержащих имена локальных переменных). Но разве это дает право просто копировать код? Посмотреть, как он работает, и сделать свой код — это одно дело, но копировать его строчка-в-строчку с именами переменных?


По такой логике, можно взять чью-то программу, засунуть в Hex-Rays, и продавать восстановленный код?

Ещё раз: суд рассматривает не только фактически выполненные действия, но и намерения сторон.

Дизассемблирование законно во многих странах, и достаточно, чтобы его сделали за пределами той страны, где это незаконно, и опубликовали готовый результат в достаточно "завершенном" виде.

А доказательства, каковые ваши доказательства? То, что совпадают названия переменных ещё ничего не значит. Это выглядит как «ну я подумал, что невозможно это написать. Я сказал это другому разработчику и он согласился. А показывать, что эти участки были взяты из Windows Research Kernel я не буду, мне не хочется вот сидеть и искать, где будут похожие куски кода!»

А доказательства, каковые ваши доказательства?

Вот показали бы оригинальные исходники ядра, можно было бы сравнить, и вопросов больше бы не возникало)
В любом мало мальски крупном университете исходники доступны, во сяком случае в 2007 в Нижегородском Государственном Университете мы NT ядро компилили, да там были бинарники с чем-то совсем секретным, но много чего там было доступно для исследования.
Вы про тот же самый WRK, или про что-то большее?
Так это-то не проблема — WRK нет только у ленивого, как и утекших исходников NT4. Только они ж в статье не выдают конкретики — только общие слова.

avkudrin, вы не поясните, о какой ссылке идет речь — я просмотрел все ссылки из статьи, там нет деталей, есть только упоминание наличия «сложного hacky трюка». Но две разных ссылки ведут в одно место — может быть, в статью вкралась ошибка.

Кстати, говоря о документации: в пакете WRK есть не только исходники, но и некоторая документация еще от Катлера, из 89 года, где NT еще называется OS/2 NT. Включая, ЕМНИП, описания требований к форматированию кода, именованиям и пр.
У меня, к примеру, нет ни первого, ни второго. И не горю желанием качать и/или смотреть их.
И не горю желанием качать и/или смотреть их.

Спасибо за то, что вы поделились этой важной новостью.
Очевидно, что разговор о тех, кто в теме.
Дежавю. Это уже было хз когда, и был уже проведен аудит кода.
Как всегда в таких случаях, читать надо не сокращенный перевод на хабре, а оригинальный пост на хакерсньюс, ссылка на который приведена в статье. Там гораздо больше деталей и, в частности, приводится пример со сложным трюком в коде ядра, который был в точности воспроизведен в коде React OS. На самом деле, все это очень странно, учитывая неоднократные заявления разработчиков, что они специально избегают любых возможностей быть обвиненными в использовании утекших исходников.

В качестве теории заговора, могу предложить идею о том, что Microsoft специально добавила код из ReactOS в NT, чтобы иметь возможность обоснованно обвинить React OS в плагиате.

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

Рассматриваю. Просто это подразумевает способность разработчиков многократно и не краснея врать, много и публично. Моя вера в человечество мешает мне принять эту версию как основную.
странно само по себе то, что заведомо зная, что упрекнут в копировании даже не поменяли имена. ведь это проще всего, мне кажется. не верю в копирование, в общем.
Microsoft специально добавила код из ReactOS в NT, чтобы иметь возможность обоснованно обвинить React OS в плагиате.
Но для заговора нужен смысл, какая-то выгода для заговорщиков, а здесь она в чем? ReactOS не конкурирует с их текущими продуктами, а заменяет древние системы, от поддержки которых сама MS уже отказалась.
Логично же, что эксгумацией тоже разрешено заниматься не всем. Если что-то не умирает, так и новое не купят, не? Я не защищаю М$, а пытаюсь обосновать _логичность_.
Болезненно распухшее чувство собственности. Все корпорации этим грешат. например, игровые издатели активно сражаются с тем, что их старые игры восстанавливают. А ну как удастся продать эту игру еще раз? Или, что еще хуже, никто не буедт покупать новую, если есть старая, превосходящая новинку по всем фронтам?

Ложная аналогия. Старые игры — источник ностальгии; их регулярно перевыпускают под новые платформы или в виде ремастера, поэтому упущенная прибыль тут действительно может быть. О том, чтобы какая-то компания перевыпустила старую операционную систему/инструмент, я еще не слышал.


Ну и распухшее чувство собственности можно понять, но угроза от ReactOS для MS несоразмерна такому подковерному способу саботажа проекта.

Короче не смог найти это материал. Возможно был даже на Хабре. Мужик в Америке восстанавливал и продавал старые компьютеры. Никто из производителей не был умилен его деятельностью. Просто посчитали сколько они недопродали из-за него новых компьютеров повесили на него долг и заодно посадили на нормальный такой себе срок.
Странно звучит.
Недавно здесь была статья про то, как Apple давит ремонтников и продавцов старой техники.
По договору Amazon с Apple, все его продукты (и товары других продавцов) навсегда убрали с платформы. Теперь продавать восстановленные девайсы Apple на Amazon могли только крупные компании – сама Apple и некоторые авторизированные ею провайдеры.
Заключалось соглашение с Амазоном, Амазон убирал из выдачи товары мелких продавцов: и все это вместо того, чтобы повесить долг и посадить?
Какая-то в этом есть натяжка (с).
он восстанавливал старые компьютеры и лицензионное программное обеспечение
Болд мой.
В таком виде это выглядит гораздо правдоподобнее.
Википедия пишет на эту тему похожее: creating the ‘restore disks’ in 2012 to extend the life of computers but violated a Microsoft copyright.
«Недопродажа новых компьютеров», судя по всему, плод фантазии русскоязычного журналиста. В реальном мире пока что действуют более вменяемые законы, нежели в информационном. Приговор с вашей мотивировочной частью создал бы прецедент, убивающий вторичный рынок вообще.
А копирастам ничо так, нормально.

Если мы об одной и той же статье, то там на мужика повесили то что повесили из-за того, что он без спроса с recovery CD установкой ОС занимался. За факт восстановления железа на него никто не наезжал.

Судили да за ПО а не за железо. Фактически если бы reactos была бы классной не знаю какая она сейчас раньшея пробовал и не был в восторге то он мог бы поставить reactos. Мое замечание было отве ом не ту реплику что корпорациям не предоставляет угрозу reactos.
Только вот жаль, что студии забывают о своих проектах, как будто их и не было никогда. Майкрософтовский Freelancer имеет много фанатов и сервера для мультиплейера (с модификациями), но найти его можно только на торрентах, поскольку официально его купить нет возможности нигде. NFS MW Black Edition — та же история. Много таких -_-
Если ReactOS совершенно случайно заменит древние системы так, что аналоги NTVDM и SysWOW64 окажутся лучше таковых в этих древних системах, это будет заговор десятилетия, поскольку это главная проблема современных виндов — в новом обновлении очередные свистелки начали работать, а дедушкин софт перестал.
Впрочем, вендекапец прочили еще до моего рождения и с некоторой точки зрения до него еще далеко, так что не будем загадывать.
Если уж строить теорию заговора, то для Microsoft куда безопаснее было бы ввести в комьюнити ReactOS засланного казачка, который внес бы патчи в ROS с их настоящим кодом, чем наоборот. Потому что тянуть к себе чужой код — палка обоюдоострая. Расследование-то авторов кода найдет, и если ReactOS докажет, что Microsoft стащила её код (а это вполне реально сделать), скандал будет колоссальный.
Про теорию заговора это такая грустная шутка была.
Так было же уже нечто подобное…
Аксель Ритчин (Axel Rietschin), инженер ядра в Microsoft, обвинил создателей ReactOS, открытой операционной системы, совместимой с Windows, в копировании кода Windows Research Kernel.

По моим личным (субъективным) ощущениям ReactOS (если брать, например, его состояние на период середины 200x годов) был собран не из открытого WRK (вопрос в еще том, что WRK был открыт достаточно поздно), а из утечек исходников 2000 и NT. Это было видно по тем местам, которых не хватало в утечках, там у ReactOS были или заглушки (STATUS_NOT_IMPLEMENTED), или собственный код, который сильно контрастировал с остальным ядром. Потом был известный аудит, код причесали, после которого явного копирования замечено не было (опять же, субъективно).


Остаются вопросы восстановления логики, полученные reverse engineering'ом ядра ntoskrnl. Но известны случаи, когда ReactOS не принимал реально полезные патчи, которые явно (для людей из ReactOS) полученные reverse engineering'ом. Как они это понимают и что в этом плохого — вопрос другой, не относящийся к "копированию кода из Windows Research Kernel".

Я только процитирую дословно официальную информацию с сайта ReactOS

reactos.org/joining/faqs
Is ReactOS legal?

Yes we are. All the code that make up the ReactOS operating system has been written from scratch by our developers. We go to great lengths to ensure that the code our developers create is clean. And we make sure that the methods we use to understand Windows internals is also clean.

We use a variety of methods to achieve this, which include clean room reverse engineering, using existing documentation freely available both in books and on the web, using extensive tests (tens of millions) which apply black box engineering methods against both public and private APIs which are exposed by the operating system.

We believe commercial operating systems should be freely available, and we're pushing to mimic the success Linux had in making the Unix operating system freely available to the masses, except we're doing it with the Windows operating system.


www.reactos.org/wiki/ReactOS_FAQ#Is_ReactOS_legal.3F

Is ReactOS legal?

Yes. ReactOS is fully legal.

Developers (devs) have not looked at Microsoft Windows™ source code. They have used the public documentation of Microsoft Windows OSes. They have made several tests to understand how Microsoft Windows works. In fact, ReactOS does the same things Microsoft Windows does, but not exactly in the same way, because they haven't the same source code. All code in ReactOS is under the GNU GPL (General Public License).
Официальные заявления ведь не гарантируют, что никто из разработчиков не нарушит официальную позицию сообщества. Но с другой стороны, «заглянуть в код Microsoft и сделать по подобию» — это не нарушение авторских прав Майкрософт. Макрос, наименование и назначение которого совпадает с майкрософтовским аналогом, но реализация отличается — тоже не нарушение авторских прав Майкрософт.
Посмотрите это видео Алекса Ионеску, бывшего ведущего разработчика ReactOS



На 9 минуте он довольно подробно объясняет откуда совпадение имен (спойлер: не из-за подглядывания в исходники, этого никто никогда не делал) и почему он считает это легальным.
Этим дело не ограничивается. Есть патч, в нем объявлена константа HFILE_TYPE_ALTERNATE. В WRK названия этой константы нет, в отладочных символах и в отладочных сборках ядра этого названия тоже нет, в официальном плагине для WinDbg (reg) этого названия тоже нет. Единственное место, где эта константа была определена, – это утечки кода (еще до WRK). Поскольку в оригинале было перечисление (а не набор из define) и это значение убрали, то в последующих версиях Windows (речь про XP и выше) этой константы не было даже в виде [пропущенного] числа где-то в коде.
В репозитории этой константы нет.

А если б и была Вы хотите одним именем одной константы доказать что-то? Серьезно?

Имена это не код, не алгоритмы. Они не содержат логики и сами по себе ничего не делают :)
Как раз алгоритмы интеллектуальной собственностью не являются, так что воспроизводить алгоритмы, созданные MS, полностью законно.
Зависит от страны. В США являются, в РФ нет. В ЕС нечто промежуточное. Патенты на алгоритмы ПО там как бы есть, но сфера их применения весьма узкая, алгоритм должен предлагать какое-то нетривиальное решение задачи, а не штуки вроде «смарт-тэгов» или новой формы тулбара.
С патентами на алгоритмы в США всё сложно, и во многих случаях такие патенты отклонялись.
Общий принцип — что реализацию алгоритма можно запатентовать, и тогда аналогичные реализации нарушают патент, а другие реализации — не нарушают. При этом спор о том, что считать аналогичной реализацией, а что другой — может длиться в суде годами.

Всё это не имеет отношения ко спору по поводу WRK, потому что там речь о нарушении не патентов, а копирайта. Копирайт на алгоритмы не распространяется ни в каком случае.
В репозитории этой константы нет.


Потому что ее убрали. Потому что ее все равно не использовали.

А если б и была Вы хотите одним именем одной константы доказать что-то? Серьезно?


Таких мест, я думаю, достаточно. Во всяком случае, это доказывает, что по крайней мере один разработчик ReactOS смотрел в утечку кода. И брал оттуда, по крайней мере, одну константу. И ничего вы (как проект) с этим не сделали (посмотрите хотя бы описание коммита, которым убрали эту константу).

Могу еще сказать, что в заголовочных файлах Windows часто раскрываются детали использования конкретных констант или полей (иногда это описание не соответствует действительности), т. е. «просто посмотреть в заголовочный файл» уже достаточно для того, чтобы получить информацию о внутренних деталях реализации.

Имена это не код, не алгоритмы. Они не содержат логики и сами по себе ничего не делают :)


Тем не менее, действие исключительного права распространяется и на заголовочные файлы. И еще раз: «Developers (devs) have not looked at Microsoft Windows™ source code».
Во всяком случае, это доказывает, что по крайней мере один разработчик ReactOS смотрел в утечку кода.


Это доказывает только то, что Вы так считаете. Лучше перед этим у самого разработчика и автора патча спросить? Может он Вам укажет на другие возможные источники.
Я еще раз напомню, что перечислил источники, в которых имени этой константы нет (я сам их изучал, т. к. вопрос происхождения константы стоял остро). В Интернете можно найти код с таким же названием константы, но этот код появился после обсуждаемого коммита.

Собственно, на этом все.
Поскольку в оригинале было перечисление (а не набор из define) и это значение убрали, то в последующих версиях Windows (речь про XP и выше) этой константы не было даже в виде [пропущенного] числа где-то в коде.


Прошу прощения, процитированная фраза ошибочна: в оригинале не было перечислений, там все такие же наборы из define (и с выходом новой версии они были «сдвинуты», чтобы учесть убранную константу).

В остальном же все верно.

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


но почему подход внутренней реализации критических секций реализовано один в один с описанием, доступным (на странице Displaying a Critical Section § Interpreting Critical Section Fields in Windows XP and Windows 2000)?


так, функция RtlInitializeCriticalSectionAndSpinCount инициализирует LockCount равным значению -1.
https://github.com/reactos/reactos/blob/master/sdk/lib/rtl/critical.c#L576
В других функциях так же используется формула для проверки взята ли блокировка или нет.


во-первых, это весьма специфическая вещь не играющая большой роли.
во-вторых, само API не предоставляет никаких контрактов по поводу изначальных значений полей структуры. тем более, что MS поменяла поведение в Vista+.


сам очевидный способ инициализировать значение LockCount — используя значение 0.
почему -1? это же совсем неочевидно.


Raymond Chen дает объяснение этому хаку: все из-за поведения функций InterlockedIncrement/Decrement и совместимости c кодом аж Windows 3.1 и Windows 95.


последний коммит в файл critical.c отвечающий за строку #576 был сделан в 2005 году. сам заголовок файла указывает


* PROGRAMMERS:     Alex Ionescu (alex@relsoft.net)
*                  Gunnar Dalsnes

согласно вики ReactOS (https://reactos.org/wiki/User:Alex_Ionescu) Ионеску родился в 86 году. Инфы про Gunnar Dalsnes нет.


если допустить, что человек возраста 19 и менее лет на момент коммита знал всю страшную историю совместимости винды (и соотвественно имена страшных людей, из-за которых MS сохраняла совместимость) и даже сталкивался с этим, что смог сам по себе реализовать не совсем очевидную вещь рады отладки… то выглядит это нереалистично.


очевидно, что это не тот случай clean-room reimplementation в данном конкретном месте.

is also clean
are also clean
Лично от себя отмечу, что следующее утверждение является ложным
Дело в том, что большая часть информации о ядре закрыта, ее нет в общем доступе.

На самом деле существует достаточно подробная публичная информация о ядре в виде книги Windows Internals Book, которая выдержала аж 7 редакций и переизданий.
На что Ритчин заявляет что в книге есть далеко не все и присутствуют неточности.
major aspects are entirely missing, and not all of what is written is accurate. In any case this definitely is not documentation, and certainly not enough information to write not only a compatible implementation, but a compatible implementation with very similar-looking source code.
Алекс Ионеску справедливо возражает, что эти книги далеко не единственный источник знаний для программистов.
Вот смотрите. Допустим, человек случайно находит исходники Windows Research Kernel, учит их наизусть. Заходит в «чистую комнату» и по памяти воссоздает ядро. Как можно доказать, что он их украл?
Я не знаю, можно ли считать его вором и можно ли это доказать в суде. Но проект ReactOS (по информации с сайта проекта) на всякий случай запрещает любым разработчикам присылать патчи или писать код, если они видели исходные коды WRK или утекшие исходники Windows.
Это не означает, что там не будет патчей от разработчиков, которые видели исходные коды. Это означает, что если не дай боже произойдет ситуация с копированием кода, у проекта ReactOS будет нормальная позиция для защиты в суде, а ответственность перенесётся на разработчика, который нарушил условия проекта.
Часть кода ReactOS синхронизируется с кодом из других открытых проектов, в частности Wine, как в этом случае могут быть предъявлены претензии по аудиту кода взятого из этих проектов?

P.S. И т.к. Windows код не открыт, то какая вероятность наличия в нём заимствования из тоже открытых проектов и какие могут быть претензии к Microsoft в таком варианте?

И какая вероятность получения логики близкого оригинальному макросу при повторении логики поведения и использования в названии открытых названий переменных?
Думаю достаточно большая, если нет очень витиеватой оригинальной логики.
Стандартный способ — человек А случайно находит исходники Windows Research Kernel, читает их, пересказывает по памяти человеку Б, тот заходит в комнату и по рассказам воссоздаёт код. В этом случае получающийся код юридически чист, и это даже не derived work, потому что человек Б не видел оригинал.

Человек А прочитал стих и рассказал его человеку Б, человек Б восстанавливает стих и выдаёт за свой. ?

Если человек А пересказал стих своими словами, а человек Б смог восстановить оригинал, то да, это не плагиат.
Нет, такой способ нелегален. Легально — это когда первый человек ревер-инжинирит код Windows, пересказывает второму человеку алгоритмы, и второй реализует эти алгоритмы по своему разумению.
UFO just landed and posted this here

На HackerNews этому инженеру ядра уже натолкали указали, где и сколько раз он был неправ.

Даже тупой diff показывет, что в ряде мест Реактос явно не плагиатил у МС.
Один файл — balmgr.c
Например тут проще у мс:

ASSERT((Prcb->ReadySummary & PRIORITY_MASK(Index)) != 0);	
                         if (RemoveEntryList(Entry->Flink) != FALSE) {
                            Prcb->ReadySummary ^= PRIORITY_MASK(Index);
                        }

у Реакта:
                     if (WaitLimit >= Thread->WaitTime)
                    {
                        /* Remove the thread from the queue */
                        NextEntry = NextEntry->Blink;
                        ASSERT((Prcb->ReadySummary & PRIORITY_MASK(Index)));
                        if (RemoveEntryList(NextEntry->Flink))
                        {
                            /* The list is empty now */
                            Prcb->ReadySummary ^= PRIORITY_MASK(Index);		                            Prcb->ReadySummary ^= PRIORITY_MASK(Index);
                        }

www.diffchecker.com/yBDTlQQf
Никто и не утверждал, будто весь код ReactOS сплагиачен.
Это фрагмент кода ядра (WRK), конкретно — балансировщик. Как раз о Windows Research Kernel в основном и идет речь
Это фрагмент кода ядра (WRK)
Вы бы хоть под спойлер, а то:
Но проект ReactOS (по информации с сайта проекта) на всякий случай запрещает любым разработчикам присылать патчи или писать код, если они видели исходные коды WRK
(С)

p.s. шутка, конечно, но как известно, в каждой шутке только доля шутки.

Хм, по крайней мере 10 лет назад разработчикам Microsoft запрещали читать любой open source код, за исключением кода собственного производства.
Не знаю изменилось ли это, но GPL-код другой операционки был бы самым критичным нарушением этого правила.
Так что есть вероятность, что своими постами человек очень сильно подставил свою карьеру в MS. Он же там ещё работает?

А почему бы Майкрософту попросту не сходить нахер?
UFO just landed and posted this here
Кровавый Microsoft обижает и так замученных из ReactOS.

По-моему это хитрый пиар ход. Когда бы еще сотрудники MS публично говорили о ReactOS?

Думаю было бы там что то серьезное, давно бы в суд подали
Думаю было бы там что то серьезное, давно бы в суд подали

Вряд ли, судебное разбирательство стоит денег, больших денег.
Имеет смысл подавать в суд только когда существование ReactOS
начнет приводить к серьезным проблемам для MS.

Когда существование ReactOS начнет приводить к серьезным проблемам для MS, это будет стоить куда бОльших денег, нежели любые судебные разбирательства. Появление конкурента для одного из ключевых продуктов — одна из тех проблем, которые значительно дешевле не допустить любой ценой, нежели пытаться побороть в будущем, когда он уже есть.
Поэтому тут математика простая: либо они пришли к выводу, что этот проект им никакой угрозы не представляет, либо там просто не к чему придраться.
вообще конечно сам проект спорный с точки зрения полезности. в прод его не выпустишь, а для остального он нафиг не нужон. автор технарь, но похоже не сразу понял как в мире развиваются технологии (а сейчас бросать жалко), а именно что никому не нужна просто копия венды если есть венда (тем более когда её можно крякнуть за бесплатно), людям нужно или лучше или другое (как поступили другие айти гиганты вложившись в linux), а так он в позиции вечного догоняющего.
UFO just landed and posted this here
Гораздо важнее сейчас уменьшать количество ОС, а не увеличивать. в современном зоопарке ОС лишние «рты» не нужны — слишком много жрут «поддержки» разработчиков.
Сейчас у компьютеров такой зоопарк железа, что без драйверов твоя новая ОС будет нужна чуть более, чем полтора человекам. Написать драйвера под всё ты не сможешь, а в комьюнити новой ОС без финансов и рекламы будет три с половиной разработчика.
Опять же ОС — это только прослойка между железкой и софтом пользователя. Чтобы получить под новую ОС хоть какой то пакет программ — надо проводить кучу конференций, создавать среду разработки (как делал Гугл для Андроида) или обеспечивать совместимость с существующей ОС.
Всё это делает разработку новой ОС одним человеком невозможной или близкой к невозможному
Сейчас у компьютеров такой зоопарк железа, что без драйверов твоя новая ОС будет нужна чуть более, чем полтора человекам.

С учётом мега-популярности виртуализации, QEMU/KVM в частности (а также гипервизоров), достаточно всего нескольких драйверов — и ОС готова для запуска у почти любого облачного провайдера.

Если это будет ОС заточенная под серверные задачи, плюс будет супер-пупер безопасной и всё такое — то шанс однозначно будет.

Чтобы получить под новую ОС хоть какой то пакет программ...

… нужно всего лишь предоставить toolchain для компиляции всего того что уже написано под линух/бсд/etc — что не так уж и сложно, если, конечно, не делать ОС кардинально необычной архитектуры.

Нет, это всё не совсем уж просто, конечно, но всё же реализуемо даже одним человеком (если он посвятит себя этому full-time). В конце концов, Linux начинался примерно так же, и драйверов под всё у него не было изначально.
достаточно всего нескольких драйверов — и ОС готова для запуска у почти любого облачного провайдера.

Да нетушки, всего нескольких драйверов недостаточно. Нужен ещё как минимум пул заинтересованных корпоративных клиентов, которым этот облачный провайдер будет её продавать. Они никогда в жизни не станет выводить из оборота серверы, которые могли бы приносить деньги, устанавливая на них виртуальные машины, которые он не сможет продать здесь и сейчас.

… нужно всего лишь предоставить toolchain для компиляции всего того что уже написано под линух/бсд/etc

Чтобы можно было предоставить toolchain для компиляции всего того что уже написано под линух/бсд/etc, ваша новая ОС должна быть совместима с ними на уровне API. И соответственно, в ней не будет ничего принципиально нового, только ещё одна реализация той же архитектуры.
Нужен ещё как минимум пул заинтересованных корпоративных клиентов, которым этот облачный провайдер будет её продавать.

Это если продавать VM вместе с ОС — в то время как некоторые корпоративные клиенты покупают чисто VM и ставят на них свою ОС. Хотя безусловно, интерес нужен, но это зависит от того что будет внутри ОС.

Если же некий провайдер продает виртуалки для приложений на nodejs, java etc (типа Google App Engine), то клиенту вообще неважно какая там внутри ОС — он её не видит в принципе, так что это может быть что угодно.

ваша новая ОС должна быть совместима с ними на уровне API

Windows совсем не совместим с Linux на уровне API, но это не помешало появится mingw и cygwin, где работает довольно солидная часть ПО писанного под Linux. Большинство open source софта работает на большинстве (современных) POSIX-соместимых систем, хотя у них разные ядра и ещё много чего разного внутри.

в ней не будет ничего принципиально нового

Речь не о том чтобы было что-то принципиально новое с точки зрения API, это новое может быть чем-то другим. К примеру, ОС которая гарантирует изоляцию приложений (до уровня «прощайте вирусы, malware и эксплойты») будет очень востребована — даже если это будет эмуляция API любой другой ОС.

Либо же сверхвысокая производительность существующего API — тоже хороший вау-фактор, не требующий ничего принципиально нового.

В общем, есть много причин по которым можно и нужно делать другие ОС, при этом не выводя в видимость что-то принципиально новое с точки зрения разработчиков софта.

Windows совсем не совместим с Linux на уровне API, но это не помешало появится mingw и cygwin, где работает довольно солидная часть ПО писанного под Linux.

Это совсем другой случай. Он для тех случаев, когда у вас есть в инфраструктуре одна ОС, и вам из-под неё надо запустить софт, который есть только под другую ось. Но порт чужого API — это всегда костыль, замедляющий производительность и имеющий ограничения. Поэтому никто в здравом уме не будет запускать ПО через порт просто так, без необходимости.
К примеру, ОС которая гарантирует изоляцию приложений

Либо же сверхвысокая производительность существующего API

Понимаете, недостатки существующих ОС, они вызваны не криворукостью их разработчиков, а в значительной мере технологической необходимостью. Вы не можете гарантировать изоляцию приложений. Ну просто потому, что когда вашей программе надо, например, прочитать клавиатурный ввод, она все равно обратится к функции API пользовательского режима, которая так или иначе сделает системный вызов в ядро и получит содержимое клавиатурного буфера. И во всём этом процессе есть миллион мест, где есть потенциальная возможность сделать уязвимость, повысить привилегии, заставить выполнить внедренный код в режиме ядра и т.д… В существующих ОС уже потрачены мильёны человеко-часов на поиск и устранение этих уязвимостей. А написанная с нуля новая ОС будет только в самом начале пути, и будет иметь все эти же болячки.
То же самое касается и сверхвысокой производительности существующего API. Чтобы он был сколь-нибудь заметно быстрее, нужно как минимум что-то из него удалить.
UFO just landed and posted this here
Если это будет ОС заточенная под серверные задачи, плюс будет супер-пупер безопасной и всё такое — то шанс однозначно будет.

Чем же она должна отличаться от OpenBSD, чтобы получить на пару порядков большую популярность? Которая имеет долю в районе 0.1% серверов.

UFO just landed and posted this here
В то время были намного более медленные процессоры, на порядки меньше объемы памяти, очень медленные диски.

Вы зря огорчаетесь, современные ОС прекрасно справляются с возросшей производительностью железа.
UFO just landed and posted this here
И почему-то раньше было много экспериментов в области. Троичная логика, зоопарк самого разного железа, вплоть до Lisp-машин, поверх этого был зоопарк ОС с более-менее различными подходами.

Все это было во времена, когда компьютеры (в широком смысле слова, включая планшеты, смартфоны, «умные часы» и т.п.) не производились миллиардными тиражами и не приносили многомиллиардные прибыли.
Это был сарказм. Что касается экспериментов, то просто мы наблюдаем период стабилизации отрасли. Это как эволюция, было много проб и ветвей, в итоге остались похожие, но наиболее жизнеспособные формы.
Болезнь «тяп-ляп и в продакшен» имеет форму эпидемии, ей сейчас заражено всё — как приложения, так и код ОС. Но прогноз благоприятный. Рано или поздно рынок софта все равно придет к насыщению, как и любые другие рынки. И тогда все эти Электроны сами собой сдохнут.
мы наблюдаем период стабилизации отрасли.
Это верно. Основные фреймворки и языки стабилизируются, по крайней мере меняя "шкуры свои" они не меняют названия.

Это как эволюция, было много проб и ветвей, в итоге остались похожие, но наиболее жизнеспособные формы.
Неверно. Эволюция никогда НЕ останавливалась и продолжается и сейчас.

Болезнь «тяп-ляп и в продакшен» имеет форму эпидемии, ей сейчас заражено всё — как приложения, так и код ОС.
Это НЕ болезнь — это стратегия получение максимальной прибыльности при минимальных затратах и при минимальных рисках. — Не думайте что все кругом идиоты (хотя история человечества — история войн — особенно в 20 веке — и позволяет так думать. — Хотя дуст, ядерные бомбы и их испытание в атмосфере, строительство АЭС без технологий хранения отходов, использование пластика без широкого распространения утилизации его — глобальное потепление(?) — всё это, конечно, может быть признаком идиотизма человечества, если под идиотизмом понимать неспособность предвидеть последствия своих поступков).

То что сейчас НЕ возникает новых ОС — это странно — учитывая, к примеру, с какой скоростью Гугл создал (скомпоновал) Андройд (я в курсе что это Linux c JVM) и выкинул его на рынок в противовес iOS — и у него на этот(!) раз получилось создать что-то не поисковое!

То есть и интеллектуальной и железной и денежной мощи СЕЙЧАС вполне хватает и в изобилии — всего этого есть навалом чтобы создать НОВУЮ ОС и выкинуть MS и Linux на свалку истории. — Но… пока мы не видим этого. И это странно. Этот застой в разработке новых OC — странен.

Только не надо про то, что столько УЖЕ написано и надо тогда всё переписывать… и кому это надо и т.п. — в мире JavaScript мы наблюдаем что вся тройка фреймворков стремительно меняет себя ЗАНОВО — наплевав ( но утешая брошенных с легаси кодом) и на совместимость и на новый фактический синтаксис свой.

А вот в мире OC мы этого НЕ наблюдаем вовсе. — Стабильность или застой? — странно всё этот — и… революции (бунта?) в ОС на горизонте не видно вовсе, хотя… Флексия?
Это НЕ болезнь — это стратегия получение максимальной прибыльности при минимальных затратах и при минимальных рисках

Это именно болезнь, естественно, в фигуральном выражении. Структура общества имеет свойство «болеть», когда некоторые механизмы начинают делать существенный перекос в какую-то сторону. Например, монополии в 19 веке (да и сейчас, скажем, в фармацевтике) пользуясь отсутствием ограничений начинали выкачивать деньги из своих клиентов. Потом общество создало регулятор для этого механизма и он заработал корректно. То же самое сейчас и в ПО. Это рынок, который позволяет выкачивать из клиентов денег значительно больше, чем позволяла бы реальная ценность предоставленных им услуг. И пока этот процесс раскручивается и раскручивается. Но рано или поздно появится регулятор, это всего лишь вопрос времени.
Потом общество создало регулятор для этого механизма и он заработал корректно. То же самое сейчас и в ПО. Это рынок, который позволяет выкачивать из клиентов денег значительно больше, чем позволяла бы реальная ценность предоставленных им услуг. И пока этот процесс раскручивается и раскручивается. Но рано или поздно появится регулятор, это всего лишь вопрос времени.

Регулятор vs свободный рынок.

Я вас правильно понял — вы ставите на те же грабли, то есть на социализм?
Простите, но социализм — это не про регулятор, это про право собственности на средства производства и распределение прибыли…
Я вас правильно понял — вы ставите на те же грабли, то есть на социализм?

Нет. А свободный рынок — такая же непригодная для общества крайность, как и коммунизм. Истина посередине, называется «рынок с государственным регулированием». Все эти антимонопольные комитеты, защита прав потребителей, стандарты качества, это всё не рыночные механизмы регулирования, но без них никак.
MacIn
Простите, но социализм — это не про регулятор, это про право собственности на средства производства и распределение прибыли…
Да, это верно. Хотя я не видел социализм без регулятора вовсе.
Вот сейчас Китай — партия там довольно сильно регулирует всё в Китае.
Или Ленин — который регулировал НЭП.
Или Трамп — который регулирует пошлины с такой страстью и силой, что Политбюро (в СССР) позавидовало бы.

DrPass
А свободный рынок — такая же непригодная для общества крайность, как и коммунизм. Истина посередине, называется «рынок с государственным регулированием». Все эти антимонопольные комитеты, защита прав потребителей, стандарты качества, это всё не рыночные механизмы регулирования, но без них никак.


Регулятор vs Невидимая рука свободного рынка.

Тут главное идея. Убери «невидимую руку» и регулятор начнёт «срывать резьбу». — Хотя попытка по «новой» зарегулировать всё и всюду, она не угасает в некоторых умах.

Но что можно регулировать в развитии ПО?

P.S.
Я помню Комитет Кодасил. Он регулировал развитие баз сетевых данных. И… канул в лету.

«CODASYL (англ. COnference on DAta SYstems Language — «Конференция по языкам систем обработки данных») — организация, принимавшая активное участие в эволюции информационных технологий в 60-80-е годы XX века. Основана в 1959 для разработки стандартного языка программирования для коммерческих систем[1]. Этот язык получил название COBOL. Помимо разработки языка в рамках консорциума была сформирована группа Data Base Task Group, которой было поручено разработать универсальный язык для баз данных, встроенный в COBOL. В 1969 году группа опубликовала спецификацию языка для сетевой модели данных, которая получила название «CODASYL Data Model».

В настоящее время конференция CODASYL расформирована, архив был передан Институту имени Чарльза Бэббиджа. „

Но что можно регулировать в развитии ПО?

Да много чего. Например, допустимые наценки на тендерах. Требования к доступности кода при осуществлении госзакупок. Порядок хранения и раскрытия приватных данных. Доступность критичных сервисов (допустим, медицинских) для всех слоёв населения.
Поставщик ПО, как и любой другой продавец на рынке, имеет одну основную цель: получить больше прибыли. И без регулирования для этого все методы хороши. Например, договориться с конкурентами и согласованно повысить стоимость продукта/услуг. Или построить монополию в какой-то сфере.
UFO just landed and posted this here
UFO just landed and posted this here
Сейчас все свелось к дуополии Windows-Linux

Тогда уж к NT, Linux, Darwin(XNU), BSD, QNX, если по популярным ядрам пройтись.


Да и на тему совершенно другого, оно ж есть, просто не заходит… А так за предыдущие 20 лет написали кучу новых ядер и ОС, просто вы не в курсе )))
Взять хоть тот же MS c его Singularity. Или вот российская разработка: Phantom OS
Ну и ещё несколько интересных проектов: Genode, HelenOS, Cosmos.

Насколько я помню, проект начался в эпоху бума «не эмуляции» всего и вся. Середина 1990х, полный успех Wabi, ошеломительный Wine… Счастье казалось таким близким, только руку протяни.

А тут еще микрософт выпустила WinNT 4, и огромная гора драйверов внезапно полетела в легаси. Фанатам за hpfs.sys было обидно.

И вот тут-то начался ReactOS. А давайте сделаем свой кернель с поэтессами, поддержим дрова под ЭнТю (блеск же идея! вообще дров не надо делать). Userland есть и так, использовать его легко — отрисовка инкапсулирована в драйверах, делаем свой заменитель x11drv (причем примитивный — просто рисуем по канвасу, аппаратные битблиты и курсоры опционально).

Ну и еще там по мелочи — файловая система и прочие компорты (ага, ага). Но тут можно по минимуму, чего мудрить! Io*, Ob*, Ke*, Mm*, Zw*… ой, что-то много этого Native API, но ничего — запилим! И у нас — будет своя опенсорцная винда с маджонгом и гейшами. А дальше — только улучшаем.

Прошло четверть века.

Сам Wine вытащили игры, желание «в линуксе» позарубиться в культовые игры было велико, а за-ради «вечерком расписать партию в старика» винду что-ли запускать? Лучше мы полноценно, в гамаке и на лыжах (С). Ну и еще «немножко бизнес» — ибо winelib.

А вот реактось увы — сгубил один неучтенный фактор. Микрософт была на пике своих возможностей, и догнать ее в конце 90х / начале 2000х было нереально не то что группе энтузиастов, но и даже консорциуму крупных корпораций. После выхода WinXP и MS Office 2003 — в особенности.

В принципе, можно было побороться за специализированную пароварку, нацелившись на «игровую приставку для игр под окошки для бедных», например. Но увы — это послезнание, в 1996м — 2001м ничего и близко в тренде не просматривалось.

А после 2001 года, с выходом WinXP, .NET, с восстановлением линейки VisualStudio, с WoW64 и новым офисом — догнать стало совсем трудно.

Да и одна из мотиваций тоже как-то поулетучилась, какой такой HPFS386 в XXI веке? :-)
ну просто как по мне затею можно было смело кидать уже лет 10 как назад, а может и 15 даже. не совсем понимаю какие критерии успеха используют авторы и какую выгоду они пытаются получить со всего этого сегодня
А фан?

У меня за-ради фана тоже есть некоторый ностальгический набор, который я все никак не выброшу в мусорку. Интересно же…

Ну а то что вот прямо сейчас смысла нету — так в эпоху победившего Internet Explorer 6.0 тоже особого смысла пилить свой движок у Mozilla'ы не было, ан нет — вот он, прямо из него и пишу.

Кто знает, кто знает — в погоне за ушедшим поездом мобильных устройств микрософт может ненароком и вендекапец устроить, знаете ли. Таких случаев в истории была тьма. От внезапных конвульсий DEC (и Alpha c VMS) до поминок Sun Microsystems (тут длинный ряд продуктов).

Так что пусть цветут сто цветов (С) ;-)
вы напутали, после выхода шестого ie MS забила на браузер, сократило команду разработчиков и ничего толком не делала, благодаря чему смысл пилить движок в эти времена был. да и браузер это не os, тем более никакого реверс инжиниринга и проприетарных технологий, простая установка, большая потенциальная база пользователей и т.д. браузер самодостаточный продукт, голая ос не нужна никому.
+ до этого был нетскейп который очень удачно продали, были разные наработки, была потребность в хорошем браузере для linux и макоси (дела у apple начинали идти в гору), майкрософт начали жать в судах. так что с точки зрения бизнеса имело смысл впрячься
ну и если что-то делается ради удовольствия то обычно не больше двух трёх лет) люди бросают и куда более успешные, понятные опенсорс продукты
после выхода шестого ie MS забила на браузер, сократило команду разработчиков

А почему мелкомягкие этот странный шаг сделали, как вы думаете? Правильно, потому что победа была полной, с разгромным счетом. «Аргентина: Ямайка — 5: 0».

Microsoft Internet Explorer 1.0 made its debut on August 16, 1995. Спасибо микрософту — они добавили в виндоус 95 штатную скачивалку нетскейпа (С). Было смешно.

Но прошло немного времени, и…

Microsoft Internet Explorer 4, released in September 1997 разорвал в клочки Netscape Communicator.

Microsoft Internet Explorer 5, launched on March 18, 1999, похоронил то что от «нетшкафа» осталось.

Microsoft Internet Explorer 6 was released on August 27, 2001, a few months before Windows XP. This version included DHTML enhancements, content restricted inline frames, and partial support of CSS level 1, DOM level 1. Это и определило будущее веба на долгие годы вперед.

И вот тут и забросили, (немного сарказма) наверное потому что — «браузер это не os». Доля рынка 90%, можно расслабиться и по пивасику (С).

И потом много лет весь мир скрипел зубами и поддерживал, поддерживал, поддерживал это древнее шило. Именно потому что «нетшкаф» не просто проиграл рынок, а проиграл всухую. Flawless victory.

Да, чисто для протокола, поддержка аж 23 платформ одновременно никак не помогла Netscape в битве с микрософтом. Ибо современный веб с всем известными div и CSS — придумали (вот сюрприз) — в микрософт, а не в Netscape.

ничего толком не делала, благодаря чему смысл пилить движок в эти времена был

Какой? И если был, то почему мозиловцы потратили пятилетку только на то чтобы довести движок до состояния «можно пользоваться»?

The Mozilla project was created in 1998 with the release of the Netscape browser suite source code.… Firefox 1.0 was released in 2004.

А случилось это вовсе не потому, что
браузер самодостаточный продукт

а внезапно — потому что задачей браузера было показывать веб странички. Причем не просто показывать — а так же или лучше чем в IE. Вот на это и понадобилось столько лет.

Параллельно с Gecko, рукопожатные немцы тихо пилили свой Konqueror. Именно эту наработку взял за основу легендарный Стив, когда в далеком 2003 году анонсировал Safari.

The KDE community licenses and distributes Konqueror… Konqueror first appeared with version 2 of KDE on October 23, 2000. Да-да, это тот самый KHTML.

On January 7, 2003, at Macworld San Francisco, Steve Jobs announced that Apple had developed its own web browser, called Safari. It was based on Apple's internal fork of the KHTML rendering engine, called WebKit.

И только десять лет после разгрома — в дело вступает корпорация бобра. Chromium 1.0 was released in December 2008.

И только напрочь провалив мобильную революцию, микрософт получила долю IE менее 50% аж в 2011 году.

С 1997 по 2015 годы, пока не определился новый «король горы», веб сначала продвигал, а затем отравлял наш любимый инторнет иксплойтер.

Так-то вот.
Добавьте в заголовок: «Microsoft наконец-то обвинил проект ReactOS в копировании кода».

(на протяжении последних лет ни одна статья не обходилась без вопроса в комментариях: когда же? Вот этот день настал)
Почему не " Microsoft популизирует ReactOS" :)
Вот на что тратят программисты рабочее время, которое оплачивается им корпорацией Microsoft. Лучше бы тратили его на улучшение своего же говнокода, вместо того, чтобы ковыряться в чужих проектах в поисках совпадений.
UFO just landed and posted this here
Говно есть везде. Достаточно вспомнить баги и уязвимости.

А ещё часть исходников же утекала, правда старых винд, но большинство этого кода скорее всего осталось.

Судя по комментариям и эмоциям разработчиков, говна там спрятано предостаточно:
http://govnokod.ru/11319#comment427926
http://web.archive.org/web/20040401115821/www.kuro5hin.org/story/2004/2/15/71552/7795
http://www.hulver.com/scoop/story/2004/2/14/54256/0849

К сожалению, когда они утекли, меня это не интересовало, а сейчас я нагуглить чойто не могу :(
Я видел.

image

"… раньше я сохранял картинку в файл, чтобы узнать её размеры. Это работало в XP, но под семёркой Longhorn почему-то всегда выходит ноль… в общем, пришлось написать этот костыль."

Из библиотек Windows Media Player.
Обычный трюк-середнячок, если нет прямого API для получения размера.

Команда ядра — это совсем иное. Исходники самой системы, на мой взгляд, очень даже хороши.
Корпорация зла делает нападки на потенциальных конкурентов. Это же опять разработку прикроют на неопределённый срок, опять аудит кода. Мы так даже бету ещё не скоро увидим.
Sign up to leave a comment.

Other news