|Peter Foldesi wrote:|
Since, the MorphOS maintains the API compatbility with 3.1 this definitely no surprise at all. :D
+PowerUp and wOS commpatibility
+Native and improved MUI and AHI
+Improved GL etc. with Warp3D wrapper on selected cards
+Fastests PPC268k JIT
Very well done, while always blazingly fast and well designed in look and feel.
Too bad they have their own Mantra MOS4 should reach:QBox!
When MorphOS was introduced a good ten years ago, it was designed to use a box system. What we see and experience today as MorphOS is only one box of MorpOS - the ABox. De facto this is currently the only box of MorphOS and hence the following rule of thumb is valid for now: MorphOS = ABox.
But under the hood there is a little more. At least there is the microkernel "Quark" that sets up the machine, starts a few services and then launches a single user task - the ABox. Initially the idea was that MorphOS should get another box, the QBox. But that box was never specified in detail. And while the QBox didn't materialize, it was probably thought to be very similar to the ABox, but updated with a few modern features.
If we now look to the current state of MorphOS we see a few things:
1st: We all know that the current situation of ppc for desktop machines is a bit difficult to say the least. And the desktop cpu marked is dominated by x86 processors.
2nd: MorphOS (i.e. the ABox) is pretty stable and advanced now, but has its inherent limitations like no resource tracking, no symmetrical multiprocessing (SMP) and no up to date/new hardware
3rd: And we further know that the main obstacle in migrating to x86 is the wrong endianess.
4th: We know that the QBox in the form once roughly anounced (or thought of) is rather dead, but the focus is the brilliant ABox. But still Quark is sitting below.
Since Apple switched from PowerPC to x86, the market for PowerPC desktop machines is de facto dead. PowerPC producers like IBM and Freescale put their focus for PowerPC elsewhere (SoCs, consoles, supercomputers). A few PowerPC machines pop up from time to time, but usually they are expensive and underpowered and produced in homeopathic quantities.
The desktop (+ notebook, + netbook) computer market is very dominated by x86. Recently ARM processors are much in discussion to join that market, but yet x86 is by far the dominant architecture.
MorphOS runs on PowerPC only. Hardware supply is warranted through the 2nd hand market of Apple PowerPC computers. For the current situation, this is okay - the hardware is cheap, proven and powerful enough for many tasks. But it is also clear that this hardware doesn't get younger and may break or put to the bin instead of to ebay... While of course it can be that the PowerPC may return to the desktop market, one can hardly rely on this option. Hence, on the long run there must be something else to warrant a future for MorphOS.
MorphOS is really nice and stable now. On a well cared setup there are only seldomly crashes. If a program fails most of the time the system doesn't lock up completely. A failing program can most of the times be removed, but not all resources can be freed again. Also the system is pretty safe, but this is rather a safety by obscurity than a safety by design. And while most target hardware is single cored anyway, there is no way to make use of additional cpu cores yet.
The limitations which are inherent to MorphOS current design are: no SMP, not a full resource tracking, no user management, the netto address space is limited to 31 bit and there is no memory protection.
One design goal of MorphOS is to warrant a high backward compability to old Amiga programs that run on a 68k processor. This is achieved by a build in 68k emulation, but also by providing an according compatible environment. One key issue in this regard is the byte ordering. The 68k processor used by the original Commodore Amiga used the big endian byte ordering. And because the operating system shares structures with the applications, the OS and the applications must use the same data format. In the case of MorphOS that is big endian. The PowerPC provides big endian byte ordering, x86 does not, for ARM the story is not that easy (see below).
Development of the QBox never took off, instead the ABox was improved and advanced and still holds the drivers and most of that hardware hitting stuff. But the foundation for a box system is there.
Using the box system for an ISA switch
Taken all this together, it may be wise to think about an ISA switch to x86 (or maybe ARM, see below). The x86 has one big obstacle though: it has the little endian byte ordering, unfortunately that is the "wrong" one. The question is how to cope with this issue? There is of course the option to run everything with flipped code, but this would lead to some unwanted overhead which would also result in a speed penalty (everything must be flipped by the cpu at run time). But an approach like that seems rather odd for a fast and lightweight OS like MorphOS.
The proposal made here: A relaunch of the QBox as a kind of ABox x86. MorphOS for x86 processors should consist of two boxes: One little endian box for full speed x86 apps (QBox). And another box (ABox) either running in full ppc emulation or (even better) maybe "just" operated in a completely flipped x86 code environment. That box would provide compability to today (ppc) and yesterday (68k). All the IPC stuff and so on would work like on PowerPC and 68k processors within that box. Due to flipping all data (or emulating PPC or 68k) structures there would be some spedd penalty though. The little endian box (QBox) would be for all new compiles and developments. To reduce developement time and to keep MorphOS as much as it is, the QBox should operate maximally as we know it from the current ABox. But while that box wouldn't be binary compatible to the current ABox anyway, the unique chance should not be missed to implement some critical yet not implementable features like full resource tracking, SMP or useage of a bigger addressspace (more than 1.5 GB RAM). Kind of really modernized ABox. Addition of full memory protection is of course debateable, too. It surely offers some benefit for improved security, but comes at a cost (and personally I rather tend to say the cost doesn't cover the benefit, a good resource tracking is enough and MorphOS doesn't need to become the übersafe OS which qualifies for operation of a nuclear power plant).
The big endian programs reside in the big endian box (ABox) and cannot access resources outside of this box. For the little endian box this is not a must be, but probably much easier to keep it rather capsulated, too. Nevertheeless a shared clipboard between both boxes and the ability to launch Abox programs from from the QBox should be warranted to avoid two instances of Ambient. And while old applications will never be able to communicate with the QBox, the ABox itself may get some new functions to communicate with the QBox.
Of course Quark and the QBox would need a lot of virtualization functions and the ABox would require drivers for the virtual devices, but since the ABox and QBox should be very similar, a lot of already existing code should be reusable. It may be a good starting point that current MorphOS supports a virtual gfx driver already.