Brendan wrote:
Except it doesn't work like that. Instead of being stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in real mode; people would just be stuck with "single tasking drivers that only support part of the hardware badly, where doing anything useful with the hardware breaks everything" in protected mode.
Picture the scene. Someone gets the idea in their head that they want to build an app on top of a simple operating system and they happen upon MikeOS. It's a monotasking OS, but that's okay as they aren't interested in running anything else on it at the same time. They develop a little game perhaps with text-mode "graphics", or maybe they switch to an 8-bit colour mode with blocky pixels (which might not be square) or a 4-bit colour mode with smaller pixels (which might not be square). This may have happened long ago, and they've tied themselves to this OS to the point where they'd rather not have to switch to using someone else's.
Having built their game, they then get excited when they hear about MikeOS32 and think it could potentially enable them to use a graphics mode with higher resolution and that better fits the screens of modern machines, but they run up against the ambition lock of the OS designers and find that they would have to try to fight their way round this barrier by reading the VBE3 spec and doing all the hard work themselves. They'd really rather just be able to ask the OS to set up the ideal screen mode for them and then work with the dimensions it returns to their app. They ask the OS developers for help and are informed that MikeOS is a simple OS intended for educational purposes, so it doesn't want to be cluttered up with anything that would unlock the slightly less modest ambitions of some of the app developers who have decided to use it. This is a shame, because it's much more fun playing with a high resolution graphics mode with the right shape of pixels and with 24 or 32-bit colour, and making that easy for the app to access is in no way adding clutter - it's transforming the potential look of the simple apps that run on it by adding a very modest amount of code.
Now, if we suppose that there are a number of simple real mode operating systems out there with a similar ambition lock in place, many of them could be unlocked by adding a binary blob with new functionality which an app can call to bypass that ambition lock. It would be a shame if aeBIOS had its potential killed off by the ambition lock of the OSes it is aimed at enhancing. What aeBIOS really is is an independent operating system component which can be bolted on to give it protected mode capability (although it does also require the OS code to be reassembled to run in 32-bit mode), but it provides only a small advantage (the app would have easier access to memory which may or may not exist and which may or may not be safe to use) while creating some disadvantages (slower interrupts and the need for someone to reassemble the OS to make a new 32-bit version of it every time the real mode version is updated). If the operating system itself isn't going to take full advantage of the new possibilities provided to it by aeBIOS, the way round that would be for other new operating system components to be provided independently in the same way to bypass that problem, and they could potentially be bundled in with or as part of aeBIOS. It isn't only VESA modes that could be made easy for apps to access, but code to set up high definition audio could be provided this way too, and code to load and save files using FAT32 storage, all bypassing any ambition lock of the OS designers.
Sure, it isn't going to turn a simple real-mode OS into a multitasking OS liberated from the BIOS (which will soon be extinct on new machines), but it could still make a substantial difference for a simple app trapped in a simple real-mode OS, at least it could do so until such time as the extinction of the BIOS kills it off. Even then if you get rid of all the ambition lock, there's no reason in principle why an EFI-booted version of the OS couldn't still run its existing 32-bit apps in a machine with no BIOS by using an enhanced version of aeBIOS which does all the work itself directly instead of calling the BIOS, while the OS itself could remain as simple as MikeOS. I'm not suggesting that this is the right way to take things forward, because extinction for all these real mode OSes may be a better future for them, but it does need to be made clear where MikeOS is going so that any app developers who might get sucked into it know if it's worth hanging on in there or if they should bail out. A 32-bit version may only serve to give them false hope of better things to come, while in reality it may be a dead end. This could go either way.