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

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

А как у вас обстоят дела с поддержкой игровых серверов?
Т.к некоторые компании не считают нужным серверную часть делать для nix платформ а ограничиваются windows, что не удобно.
Несколько лет назад именно с таким предложением обращалась одна крупная entertainment-компания, которая хотела бы сократить расходы на лицензии Windows. Но мы тогда были не готовы к этому, слишком низкая стабильность. Сейчас с этим гораздо лучше, но всё-равно есть некоторый план, который нужно обязательно сделать как-можно быстрее, чтобы переходить к реальному использованию.
И что в итоге? планируете реализовывать данный функционал? или только по принципу Bounty?
Там особенного функционала и не нужно. Сетевой стек, дисковый стек, файловая система, кэширование — чтобы всё работало как надо, и это-то мы сейчас и делаем. Игровые сервера, в принципе, можно запускать хоть сейчас, принципиально ничего не мешает.
Дополню даже тем, что есть ещё несколько частных инвесторов, готовых платить за реализацию конкретных фич. Поэтому, если у кого есть желание поработать над открытым проектом, получить хороший референс и ещё и получить за это оплату — пожалуйста обращайтесь.

Два проекта, по которым я бы мог взять людей прямо сейчас:
— Win32-подсистема на основе Wine (кодовое имя arwinss): там есть много интересных задач, она уже реализована, но есть много возможностей её доработать, сделать быстрее и лучше. Привлекательно это направление ещё и тем, что по-факту есть возможность сделать что-то по-другому (и, в идеале, лучше!), чем сделано в оригинале, в тоже время сохранив совместимость.
— C++ ядро (кодовое имя monstera): на данный момент это больше исследовательский, чем прикладной проект, но в кратце смысл состоит в том, что можно спроектировать новое, минималистичное ядро на основе тех же архитектурных основ, что и NT, но сделав это по-современному, и сохранив Native API compatibility layer. Преимущество подхода в том, что можно реализовывать не всё сразу, а модульно. Я начал с менеджера памяти, о чём не так давно сообщалось.

Есть ещё множество задачек по-проще, но не менее интересных. Пишите мне, или заходите на #reactos и спрашивайте там.
Win32-подсистема на основе Wine

Вроде как ходили слухи, что вы принципиально не используете наработки Wine…
Два момента:
1. У нас есть пара разработчиков, для которых день проходит зря, если не не скажут, что Wine — фигня.
2. Wine был действительно полной фигнёй лет 5-7 назад. Но преобразования всегда шли к лучшему (благодаря Alexandre Julliard), и сейчас он довольно неплох местами. По-крайней мере, модуляризация и различные улучшения сделали своё дело. А в те ужасные места (типа ntdll), которые остались ужасными, можно просто игнорить, они нам ненужны.

Ну и ещё немаловажный апдейт. Мы общались с командой Wine на проходившем буквально недавно FOSDEM'е, и надо сказать, что отношения налаживаются! Взаимной неприязни на «религиозной почве» больше нет (с их стороны, с нашей как-бы и не было).
Wine был действительно полной фигнёй лет 5-7 назад.

Великолепное заявление. А чем же был ReactOS 5-7 лет назад?

Вообще я за: больше систем, хороших и разных. Но это меня очень удивило.
«полной фигнёй» с точки зрения исходного кода. Там мешанина и неразбериха. Потом привели в порядок.
разве? Вроде же было время когда они использовали наработки друг друга, разве нет?
Ну это как отношения между США и Россией :-)
Нельзя же сказать, что они всегда были хорошие, или всегда плохие. Но периоды потепления и охлаждения происходили.
Как то упустил React OS из виду и узрев сейчас демки был поражен до глубины души — колоссальная работа, просто молодцы.
>>>Просим откликнутся заинтересованных в таком сотрудничестве профессионалов в области C\C++.

Я так понимаю усилия аматоров/энтузиастов уже не в кассу? Решили что нужно работать профессионалам, а не просто готовым примкнуть?
Главное, чтобы голова не плечах была.
Джаст-фор-фаны не готовы браться за некоторые важные компоненты. Их усилия тоже идут в кассу. Просто есть смысл дополнительно нанять человека за деньги, который, не распыляясь, разработает компонент согласно поставленной задаче.
НЛО прилетело и опубликовало эту надпись здесь
Нормальные оси в синий экран практически не сваливаются, поэтому его информативность некритична. Вон, винда тоже на смайлики перешла. А реактос — это реактос, да…
В оригинале после синего экрана остается [мини]дамп памяти, по которому можно разобраться в проблеме.
del (прошу прощения, не туда написал) :(

Вам хотел написать, что это было бы не плохо, к примеру на маленьком, отдельном, разделе положить утилиту (хоть с досом в комплекте), и после сброса дампа памяти на диск его проанализировать кратенько, правда без инета такой анализ всё равно окажется затруднительным.
В оригинале (Microsoft Windows) дамп можно проанализировать через WinDbg. Эта утилита есть и в виде онлайн-сервиса. Не знаю, правда, насколько у ReactOS краш-дампы совместимы с windows-утилитами.
Было бы классно, если бы вы запилили бы в одной машине все браузеры MS, от фронтендеров вам бы была большая благодарность.
И пришлось бы тогда анализировать особенности работы этих браузеров в ReactOS, а не в Windows :) В общем сомнительные тесты получились бы для веб разработчиков.
Ни фига себе, у вас работает VS 2013?

Зная, сколько там всего понаверчено внутри, и как — это очень круто, поздравляю.

А как дела с дотнетом и WPF в целом?
НЛО прилетело и опубликовало эту надпись здесь
Что тоже очень круто. Восьмёрка с лицом франкенштейна, похожим на человеческое больше, чем её родное лицо.
а есть возможно отключать UI? remoute console?
какие планы по поддержке ускорения 3д графики? ждете привлекательности для вендров или шаги в сторону работы с Linux/Windows драйверами? (все же имхо много специфики)
В 2014 году радоваться тому, что у вас в системе работает TeamSpeak 2 это даже как-то странно. Им вообще кто-то ещё пользуется?
Доброго времени суток, прошу прощения, что так поздно (относительно публикации), задаю вопрос:
а у ReactOS есть тесты, сравнивающие разницу между ответами от одних и тех же API в ReactOS, и в оригинальной Windows, ибо, как мне видится, с точки зрения совместимости, это один из наилучших способов проверки корректности реализации.

Мне реализация подобных диагностик видится в виде реализации проксирования вызовов API в обоих ОС для одного и того же приложения (разумеется при выполнении одних и тех же действий в приложении и (или) обработке одних и тех же данных), а после отработки приложения получение полного интеллектуального* диффа между логами и его анализа.

* интеллектуального в данном случае значит компенсацию очевидной разницы между логами: разные ID объектов ОС, разные адреса памяти, и т.д.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.