OSDev.org

I find it extremely unlikely that 32-bit protected mode will be dropped any time soon. At least, the ability to run segmented code in compatibility mode under long mode will not be dropped any time soon, because many applications for Windows are still 32-bit. With an intact compatibility mode, it's no problem to run an 32-bit segmented OS using long-mode interrupt handlers only.

Besides, if Intel will need to keep segmentation support with compatibility mode, it makes little sense that they would drop protected mode, as then they already have the segmentation logic.

Also, the 16-bit segments in protected mode are supported in both compatibility mode and protected mode. It's only V86 mode that was dropped in x64, not 16-bit support.

~ wrote:It could be called i64 to make completely clear that it would only run in 64-bit mode, such as the i386 was the first to give access to full 32-bit mode.

Well, gee, they could call it "IA-64" instead... oh, wait, they did that once already... yeah, as I have said more than once before, what Intel (and pretty much everyone else) actually wants to do is throw the x86 in a hole and cover it up with cement. They have tried to do this three times already (the iAPX 432 - before the 8086 was even released! - the i860 RISC, and IA-64, aka Itanium, the failure of which came to be referred in the tech press as "The Sinking of the Itanic" even before it was released, and while it is still in production, it never made much headway even in the server market it was designed for) and ended up crawling back to it, because the PC software market was a mess and no one wanted to throw away all the existing code for what would be, to the end users, a negligible improvement if any.

And to preempt the obvious counter-claims:

• "oh, you just recompile" mindset many here seem to have, is not a simply task for most software that isn't limited to using a very narrow subset of POSIX, and does nothing hardware-specific or OS-specific - in other words, any non-trivial software that wasn't written with portability in mind from the outset.
• "cross-rebuild" - cross rebuilds are a fantasy, especially if you are talking about doing it from the executable rather than the source code. While it isn't impossible to disassemble/decompile a program, then do most of the translation of the code to a different platform and/or OS, and manually fix it for rebuilding, it isn't practical - the translation would need a tremendous amount of clean-up, efficiency would drop through the floor, and any hardware-specific parts would have to be rewritten to match the original - a re-write makes more sense.
• "use emulation" - Aside from the inevitable drop in efficiency (even when combined with cross-rebuilding), it runs into problems of inconsistent hardware implementations across the PC world, and the loose standards for software compliance under Windows and MS-DOS. Apple got away with it (twice, which is positively amazing) because they tightly controlled the Macintosh hardware and software, and even then about 15% of the software base had to be scrapped or re-written on each of the transitions. For Windows, that figure would probably be closer to 75%, including nearly all the games.
• "move to a pseudo-machine (JVM, CLR, whatever)" - that just re-frames the problem, replacing a hardware target with a software one, and while it would make sense for the next round of hardware changes, for this one you need to do the same things you would need for a change of hardware platform. The same applies to any kind of portable executable, regardless of how it is translated into working code - it only helps with new software, not existing programs.

I agree that Intel will, eventually, move to a completely new instruction set architecture, and as far as I am concerned, it cannot happen soon enough. The chances are that they will indeed switch soon, especially now when ARM systems vastly outnumber x86-64 ones (albeit not on the desktop), but people have been looking for that switch to happen for over twenty years. The inertia, both in terms of users and in terms of companies, is enormous, and it probably will take some sort of crisis with the production of x86 processors (e.g., a design or performance roadblock that can't be overcome) to actually set it in motion.

rdos wrote:I find it extremely unlikely that 32-bit protected mode will be dropped any time soon. At least, the ability to run segmented code in compatibility mode under long mode will not be dropped any time soon, because many applications for Windows are still 32-bit. With an intact compatibility mode, it's no problem to run an 32-bit segmented OS using long-mode interrupt handlers only.

Besides, if Intel will need to keep segmentation support with compatibility mode, it makes little sense that they would drop protected mode, as then they already have the segmentation logic.

Also, the 16-bit segments in protected mode are supported in both compatibility mode and protected mode. It's only V86 mode that was dropped in x64, not 16-bit support.

My understanding is that booting into real mode is the main thing they are looking to drop; as I said, my understanding is that 32-bit code will still run, but you wouldn't be able to boot a 32-bit OS. I don't really know to what degree that holds for 16-bit code, or will in the future. I do know that they have already done this for the Quark chips, but those aren't exactly standard x86 chips anyway, and aren't meant to be backwardly compatible the want desktop CPUs are (they are 32 bit chips meant for SBCs and embedded systems, and I have seen some references to them running real-mode code, so it may only be that they default to booting into 32-bit protected mode).

Apple got away with it (twice, which is positively amazing)

You're speaking my language. I don't know much about the internals of Rosetta, which I'm sure is neat, but the 68k emulator in old-world power macs is just so friggin' cool.

Firstly, it resides entirely in ROM and is fired up when the boot sector is loaded so that, as far as any initial boot code is aware, it's running on a normal old-school 68k mac. Then they just overloaded one of the traps to serve as a mechanism for exiting the emulator so that your code can run directly on the PPC as an option. So basically equivalent to PC boot code being able to assume that it's running on an 8086, except that instead of adding extension modes to the new CPU they just shipped an emulator in the box.

So, what that meant was that all they needed to do was build a new toolbox ROM for the new PPC-based machines that contained the emulator, the core toolbox functions rewritten for PPC, and a simple interface to thunk any system traps encountered by the emulator into the new PPC-native ROM code, and they were able to ship a line of systems using a completely and radically different architecture without having to rewrite the existing OS at all. And the emulator was so well written (and 68k was by then so long in the tooth) that running all 68k-native system and user software on the things was still faster than on the old 68k boxes.

With that, Apple was able to push new, better, faster product to market while still having all the time in the world to slowly convert bits of System 7 to run PPC-native.

...whoof. This is not the place for that rant. I'm classic mac crazy this morning.

Yep, and that would be the way to do it when it happens - if the Windows world were anywhere near as well-behaved and consistent as 68K Macs were. There's the rub: IBM did something very similar to what Apple did with their line of PowerPC OS/2 systems circa 1991, but it was never as effective, because MS-DOS was the Wild West and trying to support even half of the programs available was nearly impossible.

It would be a lot easier today, with Windows giving some semblance of a standardized hardware management layer and PC manufacturers paying a lot more attention to standards than they did then (believe it or not, several of the early MS-DOS systems were not PCs, with the DEC Rainbow and the AT&T 6300 being the prime examples, and had version of MS-DOS that Microsoft made specifically for them; and IBM themselves made the PCjr only partially PC compatible, with a different version of PC-DOS than the one Big Blue shipped with XTs - though some versions of MS-DOS worked on it well enough later - and a one-off incompatible video system that made it flop), but it would still be a massive and ultimately futile undertaking compared to with Macs.

On the Macs, to be fair there was also the problem that 68k had reached a performance brick wall which is why Motorola stopped after the 68060. Emulating it through the PowerPC was actually Motorola's idea of the future of the 68k architecture.

Schol-R-LEA wrote:I agree that Intel will, eventually, move to a completely new instruction set architecture, and as far as I am concerned, it cannot happen soon enough. The chances are that they will indeed switch soon, especially now when ARM systems vastly outnumber x86-64 ones (albeit not on the desktop), but people have been looking for that switch to happen for over twenty years. The inertia, both in terms of users and in terms of companies, is enormous, and it probably will take some sort of crisis with the production of x86 processors (e.g., a design or performance roadblock that can't be overcome) to actually set it in motion.

To expand on the last sentence: there keep being attempts to have x86 and ARM cannibalize each other (so only one remains) but so far they both have opposite weaknesses which is preventing this so far. x86 can be very powerful in terms of speed but they can't find the way to make it consume little power, while ARM is great at power consumption but has trouble reaching the same speed performance as x86. This means that x86 keeps taking over for anything that's usually connected to mains while ARM tends to hog the market for anything that's normally used on battery only. Until either of those two limitations is broken both will remain around.

Schol-R-LEA wrote: My understanding is that booting into real mode is the main thing they are looking to drop; as I said, my understanding is that 32-bit code will still run, but you wouldn't be able to boot a 32-bit OS.

The real mode boot can go. I have no problem with that. I already can boot my 32-bit OS from both 64-bit and 32-bit EFI. What I do when EFI hands over control in long-mode is to create a new GDT, fill the GDT with a compatibility selector, and then jump to it. That takes me back to 32-bit segmented mode. From there I can then turn-off long mode (and long mode paging), and enter protected mode. So you don't really need a real mode boot path to run 32-bit OSes.

So my point is that as long as compatibility mode exists, I can still run my 32-bit OS. It works better if I can also turn off long mode and enter protected mode, but it is not really necessary. I certainly don't need real mode or V86 mode.

rdos wrote:

Schol-R-LEA wrote: My understanding is that booting into real mode is the main thing they are looking to drop; as I said, my understanding is that 32-bit code will still run, but you wouldn't be able to boot a 32-bit OS.

So my point is that as long as compatibility mode exists, I can still run my 32-bit OS. It works better if I can also turn off long mode and enter protected mode, but it is not really necessary. I certainly don't need real mode or V86 mode.

Fair enough. My main point originally was to ~, who seems to be fixated on having a system that starts with a DOS-like command-interpreter-cum-overriding-loader in real mode and uses a 32/64-bit extender to run, uhm, I guess anything actually practical, I suppose.

Schol-R-LEA wrote: Fair enough. My main point originally was to ~, who seems to be fixated on having a system that starts with a DOS-like command-interpreter-cum-overriding-loader in real mode and uses a 32/64-bit extender to run, uhm, I guess anything actually practical, I suppose.

I once had some interest in DOS emulation and also DOS extenders, but that is no longer active. I suppose I could get it to run again, but I see no reason why I would bother with it. Even back then, it was DOS emulation only, and I never modelled my API after DOS. In fact, I thought the design of DOS was truly horrible, and the main objective for starting my OS project was the lack of multitasking in DOS.

After that, I created emulators for Windows good enough for running console applications compiled with BCC. But then I found the Open Watcom project, and I adapted it for RDOS so I could build both native drivers and applications with it.

So, yes, I can boot RDOS so it looks like DOS command shell, but then I can also start with a graphical app. This is fully customizable with a configuration file.

I think that best idea would be to make BIOS go into 32-bit protected mode and enable A20 before it loads bootloader;
and to make memory map, size, video and disk interrupts accessible in bootloader while it's still running in 32-bit protected mode.
(All other interrupts expect debugging ones are plain trash)

But, "if it ain't broke don't fix it".

Lukand wrote:I think that best idea would be to make BIOS go into 32-bit protected mode and enable A20 before it loads bootloader;
and to make memory map, size, video and disk interrupts accessible in bootloader while it's still running in 32-bit protected mode.
(All other interrupts expect debugging ones are plain trash)

But, "if it ain't broke don't fix it".

Do you mean invent UEFI?