Под катом вас ждут технические детали работ, включая опыт развертывания 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) работала стабильно и позволяла «прогнать» все необходимые тесты и замеры производительности.
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 и его ориентированность на достижение результата.
Комментарии (55)
Dworkin
18.11.2015 15:17И не надо забывать что ReactOS на сегодняшний день 32 разрядная операционка, так использование её с серверами БД выглядит достаточно надуманно
ReactOS позиционируется как бесплатная ОС для клиентских машин. В своё время пытались заинтересовать ею одного из ведущего LIMS вендора для удешевления развертывания клиентов, но система оказалась слишком сырой.
npechenkin
18.11.2015 15:36+3… так использование её с серверами БД выглядит достаточно надуманно
Не стоит рассматривать эту публикацию с точки зрения «как построить сервер БД на ReactOS», я хотел показать то, как последовательная проверка готового продукта быстро и легко позволяет выявить ошибки (а значит и сделать первый шаг к исправлению) в ОС. Именно Линтер тут появляется по простой причине — это проект, в котором я принимаю непосредственное участие.MacIn
18.11.2015 18:18+1Это напоминает то, как Торвальдс писал ядро (по just for fun) — все нереализованные вызовы имели заглушки, выдавашие соотв. предупреждение. Потом он прогонял bash, и смотрел, что еще надо сделать.
На реальной задаче тестирование и быстрее, и интереснее.
Jeditobe
18.11.2015 16:24+7Команда проекта ReactOS выражает свою признательность компании РЕЛЭКС за оказанную помощь.
Хотим отметить, что подобное сотрудничество с еще 5-10 компаниями позволило бы ReactOS перешагнуть порог бета-версии в кратчайшие сроки. Мы открыты для взаимодействия.
P.S. у нас через месяц выходит «эпохальный» релиз. 0.4. Поэтому предлагаем всем заинтересованным поспешить со своими баг-репортами и патчами, чтобы они попали в эту версию.
Pilat
18.11.2015 17:24>ОС в приемлемые сроки можно довести «до ума» для работы на конкретном оборудовании с ограниченным набором программного обеспечения
Не проще ли этот ограниченный набор ПО переписать под Линукс?
Смысл в ReactOS только один — запускать все (или почти все) существующие и будущие программы для Windows. А оказывается, в приемлемые сроки с финансированием это не получается?MacIn
18.11.2015 18:19А оказывается, в приемлемые сроки с финансированием это не получается?
Это откуда следует?Pilat
18.11.2015 18:50«однако у меня сложилось впечатление, что в случае необходимости ОС в приемлемые сроки можно довести «до ума» для работы на конкретном оборудовании с ограниченным набором программного обеспечения.»
То есть в приемлемые сроки с финансированием не получается.Jeditobe
18.11.2015 20:41Не могу понять цепь Ваших логических рассуждений, которые приводят к такому выводу. Автор утверждает как раз обратное, что разумных денег и разумного времени должно хватить для подготовки ReactOS к работе в продакшене.
MacIn
18.11.2015 23:55Он цепляется за слова «ограниченный набор программ». Парируя, что, мол, должно работать с неограниченным набором, ибо это смысл ReactOS.
Jeditobe
19.11.2015 01:21Для продакшена как раз-таки не нужен неограниченный список программ, зато нужна очень хорошая работа программ из списка.
Pilat
19.11.2015 15:26Так список-то у всех свой и таких списков много. Нет пробле запускать стандартные программы, есть проблема запускать самописные либо неподдерживаемые.
npechenkin
18.11.2015 20:52+1Не проще ли этот ограниченный набор ПО переписать под Линукс?
Проще, конечно же, но не всегда возможно или же разработчики не считают это необходимым. Косвенным подтверждением чего может служить тот факт, что wine и его побочные продукты вполне себе востребованы.
То есть в приемлемые сроки с финансированием не получается.
Я, возможно, как-то двусмысленно написал, но все описанное в этой публикации делалось бесплатно.
Мысль была следующая: я считаю, что если сообщество разработчиков ReactOS мотивировать (м.б. и финансово) сконцентрировать усилия на узкой задаче, то результат будет положительный. Не знаю, что об этом думают сами разработчики, но мне в качестве такой задачи, например, видится замена предустановленной FreeDOS на предустановленную ReactOS у какого-нибудь производителя ноутбуков.
saboteur_kiev
18.11.2015 19:51+1Лично знаю контору, которая закупила разработку софта для обслуживания склада. Стоило это полмиллиона долларов. Случилось это во время расцвета Windows NT.
Софт на Win2k запустили с трудом, на 2003 сервер половина софта не запускается, исходников нет, за долгие годы потеряно много чего.
Платить сейчас полмиллиона долларов — невыгодно, поскольку софт работает. Что смогли виртуализировали (ту же NT виртуализировать сложнее чем 2к сервер).
А недавно была статья про то, что в аэропорту что-то под досом работает до сих пор.
Адекватный и рабочий ReactOS для таких проектов — весьма интересен. Причем то, что он в первую очередь виртуализируется, а уже потом работает на реальном железе, даже полезнее с точки зрения апгрейда железа.Pilat
18.11.2015 20:07+1Что за склад такой, что софт для него пол-миллиона стоит? Склад ядерного оружия?
saboteur_kiev
18.11.2015 20:11+1вы считаете, что полмиллиона это много?
10-20 человек с средней зп в 2-3 килобаксов, да плюс налоги — за полгода и нет полмиллиона. Склад для крупной оптово-розничной компании, с автоматическим конвейером. Я даже не могу сказать что это крупная фирма. Так, чуть выше середнячка.
И таких компаний много. В общем просто стоит помнить, что есть огромное количество софта, который переписать — слишком дорого, чем просто заставить его работать на современном железе при помощи виртуализации. А reactOS дает надежду на его использование в будущем, ведь win 3.x, 9x, NT, 2k, xp — вдобавок официально никак нельзя купить, если нужно чуток расшириться.MacIn
18.11.2015 23:58По идее, более новые лицензии покрывают старые, нет? Например, ПК с предустановленной 8/7 можно downgrade'ить до XP — лицензия покрывает.
saboteur_kiev
19.11.2015 03:37предустановленных серверов я что-то не припомню, и даунгрейд без поддержки драйверов — как вы себе это представите? Windows NT сейчас можно поставить только в виртуалку, на реальном современном железе она уже не пойдет. Но в виртуалке она себя ведет хуже чем 2k
Pilat
19.11.2015 08:34Полно железа на котором пойдёт. У народа море Xeon'ов осталось. В моей досягаемости ещё недавно были ненадёванные процессоры. Они без охлаждения кулерного, поэтому вечные.
saboteur_kiev
19.11.2015 21:01А что делать с отсутствием SATA в WinNT?
Есть ненадеванные IDE?
В общем виртуализация пока что сильно выручила, позволив апгрейднуть железо. Но опять таки, компаний, у которых полно древнего проприетарного софта, и в которых этот софт работает НАДЕЖНО, и денег на его адаптацию нет — для них реактос был бы реальный выход.Pilat
20.11.2015 00:06Он был бы, если бы его было реально довести до уровня windows NT. Но для этого компания должна дорости до уровня Microsoft.
С периферией правда беда. Насчёт виртуализации согласен.
MacIn
19.11.2015 16:40При чем здесь драйвера? Вы сказали
вдобавок официально никак нельзя купить
При этом, я не уверен, что так можно только с предустановленной. Вполне допускаю, что вы можете купить лицензию на, скажем, 8ку и покрыть ею более старую NT, надо посмотреть лицензию.
Pilat
19.11.2015 10:57Я считаю, что если это софт уникальный в одном экземпляре — то немного. Но тогда никуда его запустить кроме того на чём он был написан не удастся за разумные деньги.
yomayo
18.11.2015 18:10Не знаю, уместно ли давать Вам свои советы, но можно попробовать обкатать ReactOS на некоторых Embedded-решениях. Например, на ПО терминалов Qiwi и им подобным, которые работают поверх Windows. Если последнюю удаётся заменить ReactOS, то удаётся сэкономить: у производителей/владельцев терминалов есть денежный интерес. С другой стороны, набор ПО и «железа» ограничены какими-то рамками, поэтому видится возможность доработать ReactOS до необходимого уровня. В форс-мажорном случае производители/владельцы терминалов могут просто возвратиться на Windows, т.е. они застрахованы от рисков. Можно так же вспомнить о различных кассовых системах. Например, ПО RKeeper для ресторанов. Или кассовые терминалы в магазинах. Там так же минимальный набор ПО и небольшой разброс в «железе».
AWE64
18.11.2015 19:18+2Что мешает во всех описанных случаях использовать linux?
Wedmer
18.11.2015 19:26Более дорогое портирование, если оно вообще возможно, к примеру.
AWE64
18.11.2015 19:29+2Хотите сказать, что
из болота тащить бегемотадовести до ума реактос будет дешевле, чем портировать кривульку платежного терминала под linux? Это Вы серьезно?Wedmer
18.11.2015 20:04За оформление тикетов фонд ReactOS вроде денег пока не берет.
AWE64
18.11.2015 20:05А время? Время — деньги. Linux готов к использованию уже сегодня.
Wedmer
18.11.2015 20:21+1Кто сказал, что нужно быстро? Комментарий в корне этой ветки ничего не говорил про время. В добавок, скорее всего, поправить пару багов в операционке будет явно быстрее, чем писать с нуля софт, исходники которого или потеряны или уж слишком в low level winnt/win32. К примеру софт, который требует еще и свои специфичные драйвера.
AWE64
18.11.2015 20:32+2Кто сказал, что нужно быстро?
Бизнесу всегда нужно быстро. Смысл что-то там обкатывать, когда есть готовые решения.
Очевидно, что правкой пары багов дело не ограничится. Тут такое гигантское количество человеко-часов, что даже думать страшно. Как забава для гиков — да, а так — не серьезно все это.Wedmer
18.11.2015 20:44Тот же RKeeper не будет работать под Wine и его будет реально дольше и дороже портировать, чем в бэкграунде тестировать с ReactOS и отправлять багрепорты сообществу.
AWE64
18.11.2015 20:48Во-первых, Вы точно не знаете, что в итоге окажется дороже.
Во-вторых, из любого правила есть исключения, и я не отрицаю, что в каких-то случаях (думаю, что их будет довольно мало) адаптация существующего ПО под реакт может оказаться более выгодной, чем переписывание.
Randl
18.11.2015 21:03Как адаптация в стиле «взял и запустил» (либо заработало сразу, либо пара тикетов и заработало) будет дороже переписывания софта, исходников которого уже скорее всего нет, на другую ОС?
Вы упомянули время, но в условиях тех же терминалов, которые пока что могут поработать еще пару месяцев на винде, по моему деньги важнее времени.
Wedmer
19.11.2015 01:51Я уже на трех-четырех ярких примерах прикинул. Вы будете правы только касательно какого нибудь .Net. И я замечательно знаю насколько «быстро и легко» портировать pure winapi/mfc/winnt на другие платформы. А еще веселее работать с кодом, написанном в каком-нибудь Borland C++ Bulder первой версии с использованием Active-x и прочей пакости. Причем миграция проекта с первой на шестую версию занимает около четырех недель. И это еще не гарантирует работоспособного приложения. Оно просто соберется. А такого внутреннего софта в корпорациях мегатонны.
AWE64
19.11.2015 09:48Причем миграция проекта с первой на шестую версию занимает около четырех недель. И это еще не гарантирует работоспособного приложения.
Это ещё не значит, что переписывание того же с нуля обошлось бы дороже.
Если Вы читали Брукса и помните такой график, то, должно быть, согласитесь, что по мере возрастания функции вероятность того, что переписывание проекта окажется дешевле внесения изменений увеличивается. Это знают крупные разработчики. Восьмая версия 1С не совместима с седьмой, думаете просто так? Разработчики браузеров меняют движки как перчатки, да и ms периодически обновляет внутрянку Windows, а эти ребята умеют считать деньги.Wedmer
19.11.2015 12:06Я всего лишь заметил, что правка пары багов в ОС будет быстрее чем полный цикл разработки. А вообще мы говорили про портирование, а не прикручивание новых фич.
Разработчики браузеров держатся за свои творения до последнего. Mozilla только разрабатывает Servo, Microsoft только недавно выпустил Edge. Blink, на сколько я помню, является форком WebKit.
Я вам расскажу по секрету, что ядро nt за эти годы не сильно изменилось. Окружение меняется, да и то не так радикально.
J_o_k_e_R
18.11.2015 23:34А зачем вообще запускать Линтер (это же тот же Линтер, что и Линтер-ВС? ), который есть просто старый PostgreSQL на ReactOS, когда Линтер вполне успешно работает на том на чем он предназначен — на Linux, в том числе в его российской вариации — МСВС\Astra Linux (это только то, под что я ставил Линтер лично). Последний из которых доступен бесплатно, с исходниками и намного менее альфа, чем ReactOS?
npechenkin
18.11.2015 23:51это же тот же Линтер, что и Линтер-ВС
Нет, Линтер-ВС не наш продукт. Тут такая история: давным-давно нами (компанией РЕЛЭКС) была разработана для МО РФ система Линтер-ВС на базе актуальной тогда коммерческой версии ЛИНТЕР 5.7, которая никогда ничего общего не имела с каким бы то ни было сторонним продуктом. Но в последующих релизах ОС МСВС наша Линтер-ВС была заменена на форк PostgreSQL с названием Линтер-ВС 6.0.1, которую уже разрабатывает и поддерживает ВНИИНС.
QtRoS
Странно, что на таком этапе есть ошибки в таких «core» вещах.
Jeditobe
По результатам сотрудничества этих ошибок больше нет. А были они потому, что баг-репорты до этого случая никто не присылал.
QtRoS
Я с другой стороны предлагал посмотреть — столько ПО уже работает, но на эти вещи не натыкались.
Кстати, отвлеченный вопрос,
я как-то изучал исходники NT и видел, чтов некоторых местах кода ядра Windows есть заплатки под конкретное ПО, которое на какие-то особенности ОС рассчитывает, баги или фичи, и MS пришлось их поддержать, чтобы от версии к версии готовое ПО не падало. Есть такое в ReactOS?Jeditobe
Такого нет. Мы ориентируемся на то ПО, по которому к нам поступают баг-репорты. Большинство баг-репортов приходит на относительно свежие версии программ. Во всех случаях мы максимально стараемся писать универсальный код и избегать хаков, на сколько это возможно. Т.е. в идеале код должен хорошо работать с разными программами, а не с одной конкретной.
В будущем мы добавим систему обеспечения режима совместимости, но она насчитана в первую очередь будет не на хаки, фичи и баги, а на корректную эмуляцию поведения разных версий Windows (в случае, если ПО пиcалось под конкретную версию API)
EvilFox
Лучше делать как MS сделала — различные отдельные исправления как кирпичики, к каждому приложению можно подобрать нужные недостающие кирпичики. Просто потому что нередко эмулировать поведение всех особенности древней ОС для правильной работоспособности не нужно и даже вредно (для производительности).
А возможность построить цельный блок (шаблон конкретной версии API) тоже никуда не пропадает.
MacIn
У МС была строгая необходимость. Потому что если у клиента после перехода с 95 на 98, например, перестанет работать фотошоп, «крайними» будут МС. И объяснять, что накосячили не они — долго. Ждать багфиксов — долго. А клиента потерять — на раз и репутации конец. Поэтому в win полно таких хаков, когда эмулируется неправильное поведение ради программы, которая опиралась на недокументированное нечто. При этом программа слишком популярна, чтобы это игнорировать.
Такие истории описаны в блоге Рэймонда Чена.
QtRoS
Я это прекрасно знаю, вопрос состоял в том, есть ли подобные вещи в реактос.
Пояснение, тем не менее, может быть полезным кому-то еще из читателей.
MacIn
Для этого и написал. Кроме того, может кто-то еще не знает про Oldnewthings.
EvilFox
Они уже давно вынесли это из ядра и есть специальная база совместимости, можно свои подключать (SDB). То что в свойства exe/ярлыка это лишь верхушка айсберга и просто набор типичных исправлений для какой-то из версий ОС. Поставив Application Compatibility Toolkit можно самому создавать такие базы. Так уже заставил работать не одну игрушку.
QtRoS
Речь шла про совсем грязные хаки, которые присутствуют, например, в цикле обработки сообщений (GUI). Такие вещи не вынесешь никуда при всем желании :)
EvilFox
Почему это не вынесешь? По конкретнее можно? Пример?
QtRoS
Проверка имени процесса (грубый пример L«devenv.exe») в цикле обработки сообщений, для того чтобы слать или не слать какое-то специфичное оконное сообщение (WM_...).
EvilFox
А в чём проблема это вынести? Базу sysmain.sdb видели? Мы можем и свою sdb подключить к этому механизму.
Механизм совместимости проверяет наличие в базах нужного приложения и если оно там есть к нему применяются исправления. В том числе нет проблемы изменить поведение сообщений.
Там вообще более 400 самых разных исправлений, некоторые из них очень специфичные (всякая эмуляция некоторых механизмом Win95). В общем вперёд на Application Compatibility Toolkit смотреть.
Обманывать можно и иначе, через драйвер можно любое нужное поведение проэмулировать.
EvilFox
www.alex-ionescu.com/?p=39 неплохой цикл статей на эту тему.
MacIn
Спасибо за ссылку.