I happen to have seen a Reactos talk video recently. In the following video:
One of the interesting ideas is that they are developing the entire OS. Not only the kernel but the entire operating system. They say the are probably the ones to do that in the open source world. Somebody at Youtube complained about BSDs systems doing the same. I’m not sure if he is right. What Alex explains is that in Gnu/Linux systems the programs are adapted or taken from upstream releases but that they do all their programs and libraries from scratch instead. Probably the only thing that they borrow from upstream is wine.
That means that once you have the entire OS you will be able to use a whole set of well defined libraries. That is one of the reasons why Windows has suceeded. Giving binary compatibility for many years. Compare that to the fragmentation in Gnu/Linux ecosystem.
Don’t get me wrong, I love Gnu/Linux fragmentation because of the innovation that it draws. But if our objetive was to draw people to Gnu/Linux systems and not only its freedom you will need to do it the Microsoft way: Make it easier for developers.
Ubuntu is trying to do so with QT QML if I’m not mistaken. You write once an application and it will work in the desktop, your tablet and your smartphone.
I’m not sure what’s the Red Hat strategy towards developers but its many years of support operating system releases help a lot.
SuSE has taken a workaround by making a system that lets you build your application for several type of distributions and so on.
Well, I’m going to stop because this seem to be an article inside another article. 🙂
So many have ideas have arisen after seeing that video related to my own projects.
Freeldr is the open source loader for ReactOS. It is meant to replace ntldr. Although it’s main wiki page does not say much about its features you can go to its discussion page where its changelog is shown and this thread about having the idea of having Grub by default in ReactOS to learn that:
FreeLDR can just boot Windows NT, ReactOS, Linux and multiboot.
And that is compared to GRUB:
GRUB can boot almost everything from NTLDR to Linux, to XNU, to BSD, to self-withstanding utilities.
Freeldr and Super Grub2 Disk
I’m not sure but I think that Super Grub Disk once had ReactOS support. You could boot a ReactOS system with it. Regarding ReactOS support in Super Grub2 Disk just cloning the option that tries to load ntldr but multibooting freeldr.sys (as indicated in its wiki) should do it. That would make Super Grub2 Disk capable of booting ReactOS.
The other option is to incorporate freeldr.sys in Super Grub2 Disk so that it can boot the Freeldr boot menu to boot Windows installation with a broken ntldr file. I think that Grub2 can also bypass ntldr but I’m not sure that we have already implemented that in Super Grub2 Disk, I don’t see it in the sources, but I remember we had a similar option. I will have to check with Jordan.
Freeldr and Rescatux
Once you have seen what you can do with Super Grub2 Disk then Rescatux is just a matter of fixing things.
- Add an option to Rescatux to reinstall a generic MBR code to chainload partition where freeldr is. And fix freeldr load in the partition itself. That means adding an option to recover ReactOS boot. I guess I will have to decrypt what these lines from the wiki mean. Probably saving some information with dd and then putting it back with dd.
You can install the official FreeLoader’s boot sector in that partition’s first sector. However, take care, because this can break the file system’s “superblock”, that usually resides in it’s first sector. In particular, you can’t simply copy the FAT boot sector to the first sector of a FAT partition, because this would overwrite the Bios Parameter Block (which is the name of the FAT superblock). There are some programs that can do this for you, so Google for them.
- Add an option to replace freeldr with a good one (found in Rescatux itself). That is reinstall ReactOS boot.
- Add an option to add freeldr next to ntldr and reinstall freeldr so that Window systems boots again but by means of freeldr only.
Rescue Unit tests
Alex explains that he automates some tests to check if ReactOS functionality is changed by any change or another. It’s interesting because they not only use two different compilers: GCC and Mingw but they also use different machines: Virtualbox machine, KVM machine and actual machines. That is RosBuild, the ReactOS BuildBot.
The funny thing is that they have contributed to find bugs in all of these projects. Might be GCC or Mingw that do not produce the expected binary results. Might be the different virtual systems that do not virtualise the real hardware as fair as they could.
The first idea is to do Rescue unit tests. Probably I will only use KVM or Virtualbox as the main system but I will define some unit tests for Rescue. The idea is to have broken systems (Windows not booting, Windows with a password set, etc). Then, somehow Rescatux is being run unattented just like if the user had selected some options in the wizard.
The great thing would be to do it like Microsoft seems to check its help messages (graphically) but I suppose I will have to add some switches to the wizard scripts so that they read input not from zenity or python scripts but from a file.
So, if Windows is not booting, Rescatux fixes it, and then if Windows is still not booting that means that a recent commit has broken the Fix Windows option code.
I suppose that my tools will have to be improved because of my complex use cases. What I mean is that while ReactOS probably has a set of unit tests that tries in a freshly installed system (if you see the video you will learn that they also test automatically the installer) in the Rescatux case I will have several input virtual machines (One or two hard disks with more or less broken Operating systems) and several unit tests. But not every virtual machine match a given unit test. E.g. I cannot try to clear Windows password in a Gnu/Linux only system.
The second idea is to borrow the tools that they use for perfoming these tests in that hardware being real or virtual. I can do it because their tools are open source tools. I will also check if other big Gnu/Linux systems or Live systems have similar Quality Assurance systems. I probably check GRML site.
Everything will imply having to borrow or hire a powerful virtual server. bTactic will probably help me on that.
Nowin project and ReactOS Hook-up version
ReactOS has recalled me my (vaporware) NoWin project. The idea behind Nowin could be applied in ReactOS: Share your documents. Try to work in ReactOS as normal, however if something does not work as expected just reboot into Windows. The thing is that in Windows you have both the same configuration for your programs and, of course, your same data (My documents, etc.).
I remember having headaches in Nowin (although the idea was to use wine libraries) about thinking on how to translate Windows letter drives to unix directories. That would make easier that recent opened files would work in either Firefox, Thunderbird or similar apps when booted into Gnu/Linux (these were the applications that at the time had a version both Operating System: Gnu/Linux and Windows).
Now that I think of it I could try to do the same nowadays with another operating system (virtualised) that shows the shared data and configuration via a network. And that could be improved. No need to reboot into one or another OS, just use it as a virtualised one, and get a visual connection to the program. Well, that seems pretty similar to Ulteo and somehow to QubesOS so nothing invented here. Well, the sharing data and configurations part. I will have to study this sudden idea to see if it’s worth implementing it.
Back to the main article translate Windows letter drives to unix directories would not be needed in ReactOS.
So if you have a working Windows installation and you install the Hook-up version of ReactOS you get what I describe above:
You still can boot into Windows and use all of its functionality but at the same time you can boot into ReactOS and help debugging it but using the same configurations, data and files that you have in your original Windows. There’s the little thing about being afraid of loosing data because ReactOS NTFS driver not being as good as the original one, that’s something I have to ask for. Humm… I need to learn how Registry is handled in a per user basis in Windows. If the registry user file is system-specific and not home-specific (talking here from a UNIX point of view (/) versus (/home)) then things complicate too much.
This hook-up idea seems very similar to their recent idea (explained in the video above) to either replace an original windows library in a windows system with a ReactOS one and check if the system behaves in the same way. Or the other way round, put a windows library in ReactOS and check if there is anything difference in behaviour compared to when ReactOS system had its own library.
Making sure that both the Windows system and the ReactOS system share the same configuration, data and files should improve testing quality.
Well, I think I’m going to subscribe to some ReactOS mailing lists to see if some of the ideas described here make sense.