Largely due to the activity of the ReactOS foundation, it would not be a big mistake to assume that any regular reader Habra heard about the rather ambitious project of the “free Windous”. I was not an exception, and even during the work on creating the build system for DBMS Linter, the idea to include support for this operating system came to me more than once. Most recently, she was able to realize.



Under the cut you are waiting for the technical details of the work, including the experience of deploying ReactOS on real hardware, and a bit of my subjective opinion about this project.

First experiments: blocking read error from mailslot

The start was encouraging - the installation of the Linter distribution kit on ReactOS was successful: the services were registered correctly, the databases were created, the server at first glance worked properly. However, the first functional test did not give any result. No one in the literal sense of the word - the client found the local database engine, tried to establish a connection, but the server did not respond to these attempts. It was obvious that the problem was with IPC . Linter supports several interprocess communication mechanisms: local sockets, shared memory, mailslot, but it was the latter that were the way to communicate tests with the default kernel. After reconfiguring and rebuilding tests using shared memory, we were able to confirm our assumption - the problem was the implementation of mailslot under ReactOS, and a detailed study was able to find the reason: calling the CreateMailslot function with the parameter lReadTimeout = MAILSLOT_WAIT_FOREVER led to an immediate return with the ERROR_SEM_TIMEOEOUTE code
')

hMailslotClient = CreateMailslot(LMS, 0L, MAILSLOT_WAIT_FOREVER, (LPSECURITY_ATTRIBUTES) NULL); if (hMailslotClient == INVALID_HANDLE_VALUE) { dbgError(GetLastError(),__LINE__); return 1; } 

The full example is available here .

The corresponding bug report was introduced , which was corrected quickly enough. As it turned out, the MAILSLOT_WAIT_FOREVER (-1LL) value was passed without checking as a parameter timeout to the KeWaitForSingleObject function, which was an error, since the latter operates not in milliseconds but in hundreds of nanoseconds, negative values ​​are interpreted as a relative timeout, and positive values ​​are interpreted as absolute, that is Before fixing this error, MAILSLOT_WAIT_FOREVER for ReactOS was 100 nanoseconds.
The patchboot report is available here .

Asynchronous slot read error

The problem with timeouts was not the only problem in the implementation of mailslot - almost immediately after the start of communication, the client application with the kernel looked for a deadlock and slot. Starting to look for the cause, I discovered that the mailslot file system (msfs.sys) driver in the ReactOS implementation does not support asynchronous reading from the slot:

  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; } } 

The full example is available here .

The new bug report was not so rapidly closed, which is understandable, given the volume of corrections. Therefore, I decided to help improve the driver, although, I confess, the last time the driver for Windows was written in student times.
My improvements to msfs.sys were reduced to processing IRP packets using Cancel-Safe IRP queues , which made it possible to organize asynchronous reading from the slot. Not the most elegant option, but quite simple and reliable. Edits were added in commit 69475 , after which we managed to successfully “drive out” all the functional tests of the Linter kernel.
The patchboot report is available here .

Errors in mbstowcs and wcstombs

The last errors I found in ReactOS initially “surfaced” in the form of artifacts in the lines of the graphical interfaces of the Linter administration tools. All these applications are built on the basis of our cross-platform UI library - RelAPI. As it turned out, the most innocuous bugs turned out to be a manifestation of the most serious errors in ReactOS: the mbstowcs and wcstombs functions did not properly handle the situation when the first parameter was 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); 

The full example is available here .

The corresponding bug report was quickly closed, which made it possible to complete the tests of our product under the control of ReactOS.
The patchboot report is available here .

Iron test

In a discussion, ReactOS often skips questions in the spirit of “Does this OS work on real modern hardware?” - in my case, the answer is yes: it works, but not without problems. The first of these was the inability of the ehci controller, usb keyboard and mouse, was successfully emulated by the BIOS as legacy and worked, but until the usbehci.sys driver rejected the controller, so we had to refuse it (driver), with all the consequences consequences in the form of non-working USB devices. The second problem was the unstable operation of the OS, which periodically "fell" in the BSOD in hdaudbus.sys (bus driver for High Definition Audio). This problem was solved by disabling the corresponding controller in the BIOS settings.
After all the manipulations made, the system running ReactOS (build 20151025-r69700) worked stably and allowed to “run out” all the necessary tests and performance measurements.

The result of the TPC-B test on ReactOS for fat32, the Linter pool size is 390 MB .:

 Mode = PESSIMISTIC Accounts = 1000 .... Transactions: 817600 Working time: 299 seconds Speed = 2727.333 tps 

The result of the TPC-B test on Windows 7, fat32, Linter pool size is 390 MB .:

 Mode = PESSIMISTIC Accounts = 1000 .... Transactions: 688400 Working time: 299 seconds Speed = 2298.881 tps 

Slightly subjective

ReactOS is now in alpha state, which the project’s official website honestly reports and is not suitable for use in production, but I got the impression that if necessary, the OS can be brought to the “mind” in a reasonable time to work on specific equipment with a limited set software. In addition, I think that for those who like to “get” iron or dig into the guts of the OS, this project will undoubtedly be interesting. Separately, it is worth noting the goodwill of the ReactOS community and its focus on achieving results.