ReactOS now runs from the BTRFS partition

    Hi, Habr! In this series, we continue to make friends with WinBtrfs hard with ReactOS.


    And this your Windows so is able?

    Let's start in order. After the previous post, a mini-driver for the FreeLoader bootloader was implemented, which allows reading files from the BTRFS partition in read-only mode. Here the first problem was waiting for me - BTRFS is a case-sensitive file system. Here, to search for an inode structure (this structure contains basic information about the file) in the directory, the hash of the file name is used, this allows you to walk along the paths without pulling out all the files contained in the directory.

    However, in the Windows world, such a thing as registering a file name doesn’t bother anyone; therefore, the paths to the drivers required for booting the OS can be written in the registry in absolutely any register.

    At the moment, this problem is solved by good old crutches.- when a file search is requested, System32 and SYSTEM32 are replaced with system32, the same with the drivers folder. While I think how it would be possible to do it correctly. Most likely I will upload the full list of files in the directory every time and do a case-insensitive search - the loss of speed on the loader will not be particularly visible.



    The loader reads files, crutches are covered - we go further.

    I developed the bootloader code in the Bochs virtual machine, since it’s most convenient to do such things. But it (as it turned out) has problems with the launch of ReactOS, so I had to switch to the usual VirtualBox.

    And here I was waited by the next ambush - for some reason the boot sector did not work. As it turned out, there are some problems in the implementation of INT 13h AH = 42h (extended reading from disk), due to which this function cannot read more than 8 sectors at a time.

    And finally, the first error message (it is not even a BSOD!) The



    exception to STATUS_ACCESS_VIOLATION came from the WinSxS subsystem, which is mainly taken from Wine. A couple of days had to be spent on the cause of the occurrence, since WinSxS runs loading all the libraries, and there are a lot of them at startup. In the end, it turned out that the problem was not in WinSxS (fuh), but in the NtQueryDirectoryFile system call.

    WinSxS often uses this function to search for manifests by mask (making requests such as: "* _Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0. *. * _ * _ *. Manifest"), and in the WinBtrfs driver a bug related to processing has crept in masks starting with an asterisk. You can see a very simple pull-request here .

    Surprisingly, this was enough to go through the installation and boot into the desktop.


    Perhaps the world's first download from the WinBtrfs driver. The first implementation of my fix also had errors, because of something the graphics went somewhere and the pictures were not loaded.

    Actually, the system boots, and even works (although stability is not the same as in the latest release 0.4.9 ).

    But the problems are still full:

    • No paging file support. Generally speaking, linux swap files on btrfs disks are also not supported, and the patch has been hanging for several years. But WinBtrfs does support them. We have a slightly different implementation of the memory manager than in Windows, which requires another system call, which is not yet available in WinBtrfs.
    • Record and memory overflow errors. I managed to fix a couple of these, for example when installing a Git client. We will understand where the memory flows
    • BSODs at shutdown and reboot. The patch is already awaiting approval.

    Until the end of the GSoC there is already quite a bit left, in plans for further correction of bugs, and solving the problem with the paging file (but this is after the end of the program).

    Well, those who wish to support the development of this feature can join the testing and development of the WinBtrfs driver .

    Also popular now: