The last nail in OS/2's coffin

[Eugene Tucker]

I started with OS/2 2.0 in 1992. And have heard of it's demise pretty much since then. Yet I am still running it on two computer and I do have a third license for Arca OS 5.1. If I listened to the negative I would have been out of using it years ago. but here I stiil am I guess an old stubborn man. Nothing lasts forever. but this operating system has really beaten the odds. I used to do everything in Arca OS but now it is rather limited, but I still like using it. Intel will go where fiances and the market carry it along with AMD. Quantum computers are on the way and the old CPU designs are going to fade out too. Until then since my path is not a whole lot longer I will use and support Arca OS. signed Old Stubborn Coot

[Martin Iturbide]

The crazy/drunk idea will be to grab a 64bits open source multi-kernel and make OS/2 run interpreted (not emulated) from it.

http://osfree.org/ - The beginning has already been made. As I understand it, most of the Dos* functions have already been implemented.

Hello Digi.

My only issue with OSFree is that they had done a great job, but I don't have the technical skill to see it's progress to promote it. My idea would be that OSFree should make some binary releases to replace close source source components of OS/2.

What I would want for OSFree it is for some of his open source code to became streamline inside ArcaOS to replace IBM binaries. It can be little by little, it can be only start by replacing "ver.exe", whatever. We need to replace IBM binaries for open source alternatives, and mainstream that binaries (with the source code).

Digi, if OSFree has already open sourced all Dos* functions, I think we need a way to have some DLLs compiled and try to replace the IBM's DLLs on ArcaOS to test how they work. If you want to write me, or create a new thread, we can do some testing of what OSFree has and with some brave users try those binaries to replace old close source ones.

Regards

[Lars]

If you want to delve into the details:

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

Currently, this is only a proposal. But it gives a very good idea of what Intel thinks is no longer needed.

Its expected this will indeed be long term thing to happen. I understand the legacy bit takes up 12% of the space in CPU.
I read an article (I do not the have link handy) of one of the main AMD tech engineers and he said the proposal was every interesting.
However the engineer indicated the changes proposed are "very, very, very, very complex to make".

The other thing that this would imply is (the way I understand it) is that NO current VM would work anymore
to run legacy OS. Its the CPU that provides the virtualization support to hypervisor.

Roderick

Correct. Virtualization of OS/2 (and likewise: DOS and Windows 16-bit) will not be possible once x86-S is introduced. Only emulation will be possible (with a huge performance impact, of course).

[Dave Yeo]

Correct. Virtualization of OS/2 (and likewise: DOS and Windows 16-bit) will not be possible once x86-S is introduced. Only emulation will be possible (with a huge performance impact, of course).

This raises the question of how virtualization works currently with a 64 bit system running 16 bit code. My understanding is that in 64 bit mode, 16 bit software doesn't work.
As for emulation, with JIT compiler, performance can be pretty good. The PowerPC OS/2 was supposed to run DOS/WinOS2 well, as well as some versions of NT such as the Alpha port.
I doubt that anyone will actually do it but possible.

[Roderick Klein]

Correct. Virtualization of OS/2 (and likewise: DOS and Windows 16-bit) will not be possible once x86-S is introduced. Only emulation will be possible (with a huge performance impact, of course).

This raises the question of how virtualization works currently with a 64 bit system running 16 bit code. My understanding is that in 64 bit mode, 16 bit software doesn't work.
As for emulation, with JIT compiler, performance can be pretty good. The PowerPC OS/2 was supposed to run DOS/WinOS2 well, as well as some versions of NT such as the Alpha port.
I doubt that anyone will actually do it but possible.

I do not know how this works, but the CPU does not swtch to legacy mode. You will have to ask a CPU expert.

Roderick

[Lars]

Correct. Virtualization of OS/2 (and likewise: DOS and Windows 16-bit) will not be possible once x86-S is introduced. Only emulation will be possible (with a huge performance impact, of course).

This raises the question of how virtualization works currently with a 64 bit system running 16 bit code. My understanding is that in 64 bit mode, 16 bit software doesn't work.
As for emulation, with JIT compiler, performance can be pretty good. The PowerPC OS/2 was supposed to run DOS/WinOS2 well, as well as some versions of NT such as the Alpha port.
I doubt that anyone will actually do it but possible.

Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode permits most legacy 16-bit and
32-bit applications to run without re-compilation under a 64-bit operating system. For brevity, the compatibility
sub-mode is referred to as compatibility mode in IA-32 architecture. The execution environment of compatibility
mode is the same as described in Section 3.2. Compatibility mode also supports all of the privilege levels
that are supported in 64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or use
hardware task management will not work in this mode.
Compatibility mode is enabled by the operating system (OS) on a code segment basis. This means that a single
64-bit OS can support 64-bit applications running in 64-bit mode and support legacy 32-bit applications (not
recompiled for 64-bits) running in compatibility mode.
Compatibility mode is similar to 32-bit protected mode. Applications access only the first 4 GByte of linearaddress
space. Compatibility mode uses 16-bit and 32-bit address and operand sizes. Like protected mode, this
mode allows applications to access physical memory greater than 4 GByte using PAE (Physical Address Extensions).

So, with the existing "IA-32e" architecture, your OS can be running all in 64-bit mode while it can still execute applications containing 32-bit and 16-bit code (and data) segments. Obviously, Virtualbox uses this support to run 16-bit and 32-bit OSes like DOS, Windows 3.x and OS/2.

Once x86-S is introduced, Intel CPUs will no longer support this "compatibility mode".

[JTA]

Poked around on other forums, mentioning the X86-S spec, and folks there pointed out some VirtualBox tidbits:

  - old versions of VirtualBox emulated enough of a CPU such that they could run OS/2 when other virtualization products couldn't.
  - newer versions of VirtualBox no longer needed that emulation layer, as they could pass things thru to the CPU directly. But, to this day, VirtualBox still has pieces of QEMU in it.

Most likely, both VirtualBox and QEMU will be able to run OS/2 long after a particular x64-only CPU can't. I'd guess that Intel needs a new line of x64-only CPU's to carry them further into the server ecosystem. But I'd also guess that they'll continue CPU's that support legacy business apps for a long time (lots of money there).

If DOS, an OS that is older than OS/2, can be emulated and survive & thrive to this day, there shouldn't be any reason why OS/2 (all variants) can't be emulated as well, and prosper long into an x64 world. VirtualBox (virtualization) and QEMU (emulation) will get us there.

CPU's might take away a needed "layer of compatibility" on the one hand, but they almost always give back with "speed" on the other hand. Emulation developers do the rest ...

[Roderick Klein]

Poked around on other forums, mentioning the X86-S spec, and folks there pointed out some VirtualBox tidbits:

  - old versions of VirtualBox emulated enough of a CPU such that they could run OS/2 when other virtualization products couldn't.
  - newer versions of VirtualBox no longer needed that emulation layer, as they could pass things thru to the CPU directly. But, to this day, VirtualBox still has pieces of QEMU in it.

Most likely, both VirtualBox and QEMU will be able to run OS/2 long after a particular x64-only CPU can't. I'd guess that Intel needs a new line of x64-only CPU's to carry them further into the server ecosystem. But I'd also guess that they'll continue CPU's that support legacy business apps for a long time (lots of money there).

If DOS, an OS that is older than OS/2, can be emulated and survive & thrive to this day, there shouldn't be any reason why OS/2 (all variants) can't be emulated as well, and prosper long into an x64 world. VirtualBox (virtualization) and QEMU (emulation) will get us there.

CPU's might take away a needed "layer of compatibility" on the one hand, but they almost always give back with "speed" on the other hand. Emulation developers do the rest ...

Its not that easy virtualization will full x86 emulation.  It has an impact on perfomance.

Roderick

[ivan]

Has anyone considered that AMD might not blindly follow Intel down this road?  I see this as an attempt by Intel to gain relevance.

[Mentore]

Has anyone considered that AMD might not blindly follow Intel down this road?  I see this as an attempt by Intel to gain relevance.

This may indeed be a possible scenario, also due to the technical challenges a complete 64 bit transition will create.

That said, I'm fairly sure that the actual x86 architecture will survive for long, before it can be considered a dead horse. Too many installed machines and too much software written for it.
I feel confident OS/2 will survive this generation 

Mentore

[Martin Iturbide]

Hello

Sorry to keep philosophizing here:

Has anyone considered that AMD might not blindly follow Intel down this road?  I see this as an attempt by Intel to gain relevance.

If Intel does it (which we don't know if he is going to do it) and succeed reducing costs without any major technical/market impact, AMD will follow.

I guess it will be similar to the UEFI transition. How got impacted with that UEFI only transition in some machines? A little part of the Intel market (us), that they just don't care. The only worry for Intel was that Windows and Linux supported UEFI, and that's it.

This may indeed be a possible scenario, also due to the technical challenges a complete 64 bit transition will create.

I'm not sure of the technical challenge, if Windows and Linux works fine under a 64bit-Only processor, Intel will not care much about the rest (us).

That said, I'm fairly sure that the actual x86 architecture will survive for long, before it can be considered a dead horse. Too many installed machines and too much software written for it.
I feel confident OS/2 will survive this generation 

I hope for that. But I still have the itchiness that we should try what the Linux community accomplished. By being open source they are vendor free, they do not longer need IBM, Microsoft or anyone else to keep updating their OS. Distributions comes and goes for them, but the source code is always there to create, modify and expand their OS. Being more open source will allow us to reduce our issues with hardware changes, we will have something to reuse and update.

Regards

[Dave Yeo]

I hope for that. But I still have the itchiness that we should try what the Linux community accomplished. By being open source they are vendor free, they do not longer need IBM, Microsoft or anyone else to keep updating their OS. Distributions comes and goes for them, but the source code is always there to create, modify and expand their OS. Being more open source will allow us to reduce our issues with hardware changes, we will have something to reuse and update.

Well, Microsoft and IBM are the top committers to the Linux kernel. Then there's systemd.

[Roderick Klein]

Has anyone considered that AMD might not blindly follow Intel down this road?  I see this as an attempt by Intel to gain relevance.

This may indeed be a possible scenario, also due to the technical challenges a complete 64 bit transition will create.

That said, I'm fairly sure that the actual x86 architecture will survive for long, before it can be considered a dead horse. Too many installed machines and too much software written for it.
I feel confident OS/2 will survive this generation 

Mentore

I share that viewpoint.

Roderick

[Martin Iturbide]

I hope for that. But I still have the itchiness that we should try what the Linux community accomplished. By being open source they are vendor free, they do not longer need IBM, Microsoft or anyone else to keep updating their OS. Distributions comes and goes for them, but the source code is always there to create, modify and expand their OS. Being more open source will allow us to reduce our issues with hardware changes, we will have something to reuse and update.

Well, Microsoft and IBM are the top committers to the Linux kernel. Then there's systemd.

Yes, they are the top "Contributors", but they giving the changes under GNU GPL V2, which means they can not block access to the source code. If any of those companies cease to contribute, since it's open source, the Linux community has the option to take the source code and continue with other developers. The case differs from close source software, which depends on the author that has the source code.

Regards

[Dave Yeo]

That's why I mentioned systemd. Consider my phone and the majority in the world. Sure I can download the source code for the Linux kernel in my phone, what can I do with it? It's not like I have root and while my particular phone has instructions for rooting, unlike many, the kernel is still locked down by being signed and interacts with binary blobs.
Also consider IBM owned RedHat, you have to sign a contract to get access to the source, including the kernel which is likely patched.