28 Jan 2014



Todo list: ReactOS edition

So there is this tendency amongst the community to ask why the project doesn't do this or the project doesn't do that. A lot of the stuff people want done would tend to fall into my area of responsibility. I tend to frown upon people who make more work for me so I often push back, hard, requiring that others demonstrate their willingness to do some heavy lifting before I will consider a proposal. For some reason or another some people find this pushback hard to swallow, as if the hard work was done when they came up with the idea. As any programmer will tell you however, ideas are cheap. Implementation and execution is what counts. That said, there are others that don't quite grasp that I and the rest of the team are often very, very busy with existing work and thus pile on new suggestions because they think we have the time to take it on. A good portion of this is probably due to how much of the work we do is in the background, invisible until the work is actually ready. Hence this post, where I run down the projects I'm currently working on, want to work on, and plain just don't have time to work on.

  • 0.3.16 release.

Of immediate concern is the upcoming 0.3.16 release. This process is mostly routine now in terms of work, except this time we want to incorporate an updated theme. The Lautus theme originally developed by Pisarzk looks nice, but the files posted are very old at this point. Pisarzk claims to have updated versions, but until I get them, I can't commit them or add them to the release. Otherwise we would have had a formal 0.3.16 RC by now.

  • Kickstarter

I'd say about 80% to 90% of the text produced for the Kickstarter was written or edited or based off of stuff written by me. Then there's the fact that I need to keep tabs on incoming messages and the like. Amine has fortunately taken on pushing the Kickstarter on social media, a role traditionally taken on by Victor and which I left to Victor because I, on a personal level, do not "get" social media enough to effectively exploit it for PR purposes. I'm a traditionalist, which worked fine when Victor was well enough to help fill the other half of the PR related work.

  • Graphics

Quite a few people have been asking for ReactOS to set up some kind of online store to sell T-shirts, cups, etc. Well, to sell any of that, the team would need to have designs worth buying. Doing good design work is not trivial or cheap and finding a graphic artist has always been problematic. The rates for professional ones tends to be expensive enough that the project would need to take a hard, serious look at cost-benefit to see how long it would take to recoup the investment, much less pay for future tweaks. The attitude of volunteer ones tends to be, confrontational, as they often take on a "I'm doing this for free so stop making demands" tone when we want to direct the way a design goes. I suppose I am fortunate that I do know a graphic artist that I can contract out some simple work and I am currently working with him to get a few template designs done. He'll certainly be paid, but he won't be costing the project nearly as much as other sources. But the design work will take time, as there's little point in making a design to sell if we don't get the initial design right.

  • Website

The website migration, in hindsight and to be frank when it actually occurred, happened prematurely. Procedures had not been put into place for dealing with things like translations and the first few weeks was me making things up as I go to try to contain the damage from translators breaking the main English pages. There was a not insignificant amount of swearing on my part. The site has also suffered from some structural instability that we haven't been able to find the cause of. For a while, we could not replicate the failures on the test site so no one could figure out what was triggering the issues. Since then, I've slowly been working on another test site, prototyping finer grained permission controls and organizational tweaks as well as some backend infrastructure changes. The intent is to find enough fixes for the problems we currently suffer from that when we do another site migration, such as when Drupal 8 comes out, we do not repeat the same mess. If I can work out the logistics, I would prefer to actually do another migration to a clean Drupal 7 install. There are simply too many accumulated issues with the current install to bring about some of the new site features that Amine and zehnvor have been pushing for and that I fully support.

The above are the issues that currently occupy my attention, but they are by no means the only things. I have another list of things that I want to get to, but cannot due to time constraints.

  • PCI driver

The ARM team left behind quite a few bits of code, some ready and some almost ready. The PCI driver is one of the latter and its importance is hard to overstate. If ReactOS is to have any shot at being used in embedded configurations, it needs to have a robust PCI driver that can handle atypical hardware configurations. From a previous job, I have seen firsthand just how much grief a crappy PCI implementation can cause. It was almost amazing how the licensed code got systematically more insane with every iteration. At one point I heard the senior developers jokingly contemplate just writing an inhouse version. I'm pretty sure the only reason they didn't was due to lack of manpower. That said, the PCI driver is mostly there but not actually used. What I want to do is to swap it out for the current PCI driver, see if it breaks anything, and finish off anything that is currently missing. From there, we might see some better success on real hardware if ReactOS runs into strange configurations.

  • UEFI support

Ah, UEFI. Where do I even start. First and foremost, UEFI has got to be the most overly complicated monstrosity/abomination that I have ever witnessed as a programmer. That said, it is proliferating and is the present/future so we need to live with it. Implementing UEFI support is a multi-stage process. First, ReactOS' storage stack must be able to handle GPT based partitions. Thanks to some work from Pierre Schweitzer, that is actually partially if not completely done. Second, freeldr basically needs to be rewritten to use UEFI functions to perform things like querying the hardware configuration. Third, the installer needs to be reworked to put the new bootloader in the correct location for a UEFI boot. So for full UEFI support, a non-trivial amount of work is required.

  • Intel ME

One of the things Intel built on top of UEFI is something they call the Management Engine. This feature is mostly for server and workstation configurations and allows for remote management of systems without needing an operating system. The project actually has a machine with the ME and there has been talk of using it for automation of testing on real hardware much as how tests are automated for VM installations. The tricky part is Intel's SDK for controlling such systems is something of a mess. This is something of a recurring pattern, to be frank, when it comes to the software libraries Intel releases.

  • Buildbot

ReactOS makes use of an automated build system written in Python to do the builds for reach revision. I promised Olaf a couple of months ago I'd look into extending it to make certain things easier to do. Yeah.....

  • ARM

So people will likely recall that I have pushed back, hard, whenever anyone suggests the project should focus on ARM. This is not because I don't see the point, but it's because getting ARM working is not trivial. For that matter, getting back support for developing for ARM at all would require a bit of work. CMake has made it much easier and the first step needed would be to test generating Visual Studio solutions for ARM builds. Putting together a GCC based build environment for ARM on Windows would be, time consuming to say the least. But verifying that Visual Studio can be used to generate workable ARM binaries and seeing if the instructions left behind by the ARM team for how to test said binaries are still valid would be an important step to at least making it possible for someone else (not me) to pick up where they left off.

The above pretty much sum up the work that I am doing or want to do for ReactOS. The problem, of course, is that these are the work FOR ReactOS. I have an entirely different set of priorities involving real life, many of which override the ReactOS specific priorities. Those I will talk about in another post, just to illustrate the balancing act needed to get anything done at all.

Comments (5)

  • anon

    Is the dev team aware of these people "https://code.google.com/p/reactos/". The link was posted in the forum in the last few months. I do not know if they are still active!

    Jan 29, 2014
  • anon

    "Their" work is pretty much non-applicable to us due to their insistence that CMake is somehow incapable of generating "true" Visual Studio solutions. They want to create basically a mirror copy of the build system that is only Visual Studio, which the project regards as a couple of steps backward. They also created that page using the ReactOS name without our permission. Unfortunately, Google Code doesn't allow changing a page name after the fact, so besides a stern warning and an acknowledgment from them, we've let them be. That and they haven't seemed to make any actual progress on the hard parts.

    Jan 29, 2014
  • anon

    regarding ARM you could contact this guys: https://code.google.com/p/reactos/
    They already started to get the visual studio stuff done but the last commits were just syncs.

    Jan 29, 2014
  • anon

    You wasn't crystal clear, but does UEFI support mean you're dropping BIOS support or will ReactOS do the most sane thing and support both?

    Jan 29, 2014
  • anon

    If we ever drop BIOS support, it'll be because we dropped support for 32bit outright. Other than that, we have no reason to do so.

    Jan 29, 2014
This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.