ReactOS Hook up version idea, Super Grub2 Disk and Rescatux

Introduction

I happen to have seen a Reactos talk video recently. In the following video:

which was recorded at Google Montreal on October 2013, Alex Ionescu explains what ReactOS is and what they have achieved with it.

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

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.

Anuncio publicitario

Rescapp 2008 Draft

I’ve been checking my old backup files on the nowadays old CDROMs from 2008 and I’ve found an scanned Rescapp draft. It’s not handkerchief based 🙂 but paper based. It’s interesting because Rescatux 0.01 came around June 2010, that’s two years later. Sometimes old thought projects come back to life. I wish that the Nowin project was alive again but it seems that the desktop systems are quite dead nowadays with all the cloud stuff. So I will leave it there as a a vaporware.

Rescapp is the main program included in Rescatux. It makes possible that the final user just uses a wizard to perform his rescue tasks. What you are seeing attached to this post is one of the first rescapp drafts. If you see the current Rescapp layout you might be astonished because it’s very different. The first draft, as you see, is very cluttered. I still like the idea of the first draft although I would be probably wrong if I wanted to switch current layout to draft one 🙂 . One thing is what you would like to do, another thing is what you can do, and another thing is what you should do.

Initial idea about a rescue application named Rescapp

The attached draft is written in Spanish but as it has letters in red for each one of the sections it’s going to be very easy for me to explain it. If you see it with a quick glance you will see that it’s quite technical. There are three sections about the source code: [H]: Technical Help (Source Code Explanation), [I]: Source code Edit and [K]: Original source code View. The idea is that if the Rescapp scripts needed to be edited you could do it in the same Rescapp window. You can check original source code to compare it to your edited code. And, if you are not sure about what you have typed you can always click on the [J] Obtain difference button so that you see the diff output.

Another improvement can be found at the bottom. [L] Console Output let’s you see what Rescapp script is doing in the background while performing its rescue tasks. You don’t need to open any log file, it’s all there and you can scroll it too. Currently Rescapp saves all the logs associated with your rescue tasks, in this Rescapp draft you need to save the log specifically thanks to the [M] Save Log button.

Another big difference that you can see is what we could call the status awareness. I mean, you always know what’s the current status of Rescapp. [B] Menu status shows you which option from the [C] MENU you are in. Just above it you can find [A] Steps status which tells you in which one of the [D] Steps from the current option you are. That way you can know if you are about to end your rescue tasks or if you have just begun to use it. I suppose that in the final implementation of this design both [C] MENU and [D] Steps would be hidden when running an option. Alternatively when you are not running an option you wouldn’t see: [A] Steps status or [B] Menu status.

So, what’s left? There’s [F] TIP where you are given tips when selecting an option or when being in an specific step and [G] Classic help which would have something as a manual.

Finally there is the [E] Action widget where the user is being asked some questions and at the same he’s being informed about what is happening.

So that’s it. Some of these ideas might come back to Rescapp in the future? Probably the [C] MENU one if there are so many options in the future. I don’t like tree menues at all because they seem to me as impersonal and complex. We will have to make out a workaround 🙂 .

I’m attaching other Rescapp screenshots so that you can compare how Rescapp has changed in time.

Enjoy!

Rescapp in 0.2x Rescatux series was based in Zenity

Rescapp in 0.3x Rescatux series was based mainly in PyQT (Python + QT). Some Zenity code persisted though.