We all know that one of the many reasons for Microsoft Windows being so big, requiring so much memory and disk space, and ever faster processors to be able to cope with each new version of the operating system in order to make it usable, is the fact that throughout its evolution it has always been possible to make old software run on the latest versions.
This backwards compatibility, the ability to run legacy code, is one of many important features of the operating system, but for those people who do actually need to run such code, for whatever reason, it must surely be one of the most important ones – and Microsoft is well aware of this.
Microsoft also knows that when releasing something as significant as an operating system for the first time, the more applications there are available to run on it from the outset, the better its chances of becoming a success – and, for all intents and purposes, a version of Windows running on ARM processors might as well be a completely new operating system. When Microsoft made the decision to begin development of Windows on ARM, it knew a good range of applications being available would be the key to its success – and also that, for obvious reasons, there would be no viable way to include support for legacy Windows applications.
According to a leaked document from within Microsoft, it seems early meetings were held to address this very issue, with the final outcome of those meetings being that the problem of having a good range of applications available from the start would be solved by implementing a way to run legacy applications. Except those legacy applications wouldn’t be Windows applications – they couldn’t be Windows applications.
They would be RISC OS applications.
Investigating further, I have been able to make contact with a Microsoft employee who is part of the team that was tasked with making this possible. For obvious reasons, he doesn’t want his name revealed, so I’ll just refer to him as Mike.
Mike explained to me that it was actually Bill Gates’ own idea:
The first meeting we held to discuss this was a complete failure. Nobody agreed on anything, and nothing was decided. We didn’t know how we were going to have any applications running in Windows on ARM. We were going to develop our own, but we needed to get the system developed to a certain point before we could even begin that process.
The second meeting started off with a lot of arguing about it – some people wanted to cancel the whole Windows on ARM project. It seemed like a non-starter. But while everyone was arguing, Bill quietly pulled out a laptop and booted it up, then launched an application and turned the laptop around so it was facing the rest of us at the table. He said nothing, didn’t do anything to attract our attention – he just sat there, waiting. Once one person had noticed and turned their attention to Bill and this laptop, it didn’t take long for everyone else to go quiet as one by one we each dropped out of our arguments to look at what everyone else was looking at – the laptop screen. The application he was running.
That Windows application, it seems, was VirtualRiscPC. Bill was showing his people RISC OS, running under emulation on a Windows 7 machine.
After we’d all fallen silent, just looking at this application, not really knowing what it was, or why he was showing it to us, Bill told us it was an emulation of something called a RiscPC, running an operating system called RISC OS. He said he’d actually been using it for some time – he particularly liked the RiscPC and said he still had a real one at home.
It was at this point Bill dropped the first of his bombshells.
“RISC OS,” he told us, “is a desktop operating system that runs on ARM processors. It’s been around for years, and there are actually a lot of neat applications out there, from word processors and spreadsheets, to graphics packages, website maintenance applications… and even some games.”
Even though we’d already gone silent, it felt at that moment that the silence had suddenly become… even more silent. Do you know what I mean? None of us had ever heard of RISC OS before – a desktop operating system running on ARM processors? Aren’t those things supposed to be for phones, and tablets, and stuff like that? Not desktop computers!
And then Bill dropped the second bombshell.
“Although this emulator is running something called RISC OS Select, which is an updated version of RISC OS 4,” he told us, “the source code for RISC OS 5 is available.”
Now, at this point, you’d be right to wonder if Windows on ARM is actually based on the RISC OS 5 source code, whether that was Microsoft’s starting point, and in our email exchanges I did clarify this with Mike, who told me that isn’t the case.
By this stage, work had already started on Windows on ARM. We already had a kernel up and running, and various other bits, enough to tell us that the operating system was feasible. It was only the lack of legacy support that we were looking at in those meetings, and therefore the lack of pre-existing applications to run on it.
What Bill wanted us to do was look at the RISC OS 5 sources, to see exactly how RISC OS worked, what its APIs were, and what the underlying code for it all did, so that we could introduce a compatibility layer in Windows on ARM. That was why he brought RISC OS to our attention. That was his idea: to make it possible to run RISC OS applications as though they were native Windows [on ARM] applications – and if it worked, we’d have an instant base of applications ready to run on it.
And did it work?
Definitely! It’s been an amazing success! I have to admit to having had doubts at the start, but they were misplaced – totally misplaced.
It’s not perfect, not by a long shot. We have a few bugs, a few things to put right before Windows on ARM ships, but nothing major. Obviously not everything runs – only stuff that’s native code, so stuff programmed in C or assembler; we haven’t implemented a BBC BASIC interpreter or anything like that. Yet! <vbg> So nothing written in that will run.
The technical side of it, from the point of view of getting any individual RISC OS application running, is that we’ve implemented a system that recognises an application as a RISC OS one by the folder name it’s stored in – i.e. using the exclamation point [that’s exclamation mark to us Brits] to start the folder name. When we see the app being launched has that, we look for the text script [he means Obey file] inside called !Run, and execute the commands from it that we need, setting the variables, that sort of thing.
Before carrying on with Mike’s explanation, in a subsequent email I clarified what he meant by that:
It’s not a full implementation of everything RISC OS – for example, we don’t have any need of RISC OS modules: All the RISC OS API calls for all the standard modules are recognised and dealt with via our compatibility layer, so stuff like RMEnsure and RMLoad we ignore. One of the things we haven’t done at all is RISC OS modules, so any app that needs one to do anything special is one that won’t be able to run under Windows on ARM. An equivalent to your SharedCLibrary is there, already, all that sort of stuff. It’s just apps themselves that we’re making run.
We’d like to expand it to cover other stuff, stuff that’s in third party modules, to make even more apps work, but not all third party stuff is open – and if it’s not open enough for us to see how it works, to get the most accurate picture of what the module’s API is all about, we can’t do that.
So, back to his previous email:
The last comment we take from that text script is the one that launches the actual application – so we run the executable, and there we have it: a RISC OS application running in our OS.
It doesn’t look like a RISC OS application, though – because, as things are, it would look wrong, not like other Windows on ARM stuff. Our compatibility layer sort of translates the RISC OS stuff to what makes sense on our system and passes it to deeper calls into our own stuff, so when a RISC OS app thinks it’s asking RISC OS to do ‘this’ what’s really happening is it’s asking Windows [on ARM] to do something slightly different – so they look native, like other Windows on ARM apps. That’s the beauty of it all.
RISC OS, like Windows, has an API, or application programmer interface. The RISC OS stuff is calling the RISC OS API, which is really just our compatibility layer – it’s a chunk of code that works out how to do the RISC OS stuff using our stuff. It’s pretty neat, really – there’s two levels. It’s only a sort of API implementation – not a direct one – because we use an engine to do it, so it doesn’t take much code. The ‘sort of’ RISC OS API in our own API, reforming the arguments of each call to how we want them, we refer to that internally as the Application Programmer Reformation Interface Layer. But the clever part is that it uses a new technique we’ve come up with that sort of ‘works out’ what’s needed. That’s called the Foreign Operator [re]Organizing Logic; that’s what it does. A call from the executable into RISC OS, to us, is a foreign operation; we apply some logic which reorganizes what’s being asked for, and it gets passed through the interface layer into our own stuff, and we do whatever’s necessary; draw icons, text on screen, all that stuff.
It’s really clever.
I’m sure it must be – it’s way beyond me. But what are Microsoft going to do with it? Surely, Windows on ARM is far enough along now, and out with developers and testers, etc, so there’s going to be native apps written – there’s no real need for RISC OS applications now, is there?
Well, that’s the thing. There are developers writing stuff for it now, yes, but there are actually some great RISC OS applications we could use – so although we don’t need to, we are negotiating licenses with some companies so that we can have those apps at launch on Windows [on ARM]. I don’t really want to name any names in case it damages negotiations, after all I’m not supposed to be telling you any of this anyway, but what I will say is that I really like the vector drawing app you have on RISC OS – that’s an example of something I’d love to see on our system. We’ve never had anything as good as that free with a Windows operating system before, so that would be a really cool thing to have. I’m pretty sure we will.
The other thing is, we know that some people are complaining about the Metro interface. We’re hoping that once people get used to it, they’ll just stick with it and forget the traditional desktop – but if they do, we don’t have to go to much effort to bring ours across from Intel to ARM; because we started on the Application Programmer Reformation Interface Layer and Foreign Operator [re]Organizing Logic to run RISC OS stuff quite early, we did actually implement a desktop based on the RISC OS one because that seemed the easiest way to do it at first. That’s hidden now, it’s in the sources still, but switched out at build – you can’t call it up at all without a recompile. So if we’re wrong, and people do go off Windows on ARM because of there’s no desktop, we’ll just build the RISC OS desktop back in and use that as the basis for any desktop stuff we do on the ARM version in future. It’ll appear when we do a Service Pack or something – but only if people cry out for it.
We’ve decided to go that way because, quite honestly, the RISC OS desktop is clever – I’ve actually become a bit of a fan of it. I’m loving how the active window doesn’t have to be the one at the front. Why didn’t we ever do that in Windows before?
Thanks for that, Mike. That’s been a really useful and informative exchange.
So there you have it. Windows on ARM includes something called the Application Programmer Reformation Interface Layer and Foreign Operator [re]Organizing Logic, which allows some RISC OS applications to be run as though they’re native apps for Windows on ARM.
While not necessarily a boost for RISC OS itself, at least not directly, this could certainly prove beneficial to some application developers, because once they’ve tested their apps to see if they work on Windows on ARM, they’ll have a new, bigger market to sell the apps into – and not ports or different versions of their apps, so they don’t even need to learn a different API or development system; the very same versions that they’re selling into the RISC OS market.
The future, for those RISC OS developers, could be very bright indeed.