OS/2, eCS & ArcaOS - Technical > Programming
native mainframe mini-clone
Dave Yeo:
Couple of things. There is a 64 bit LX format that NASM supports. Bird came up with the patch for VirtualBox.
Currently OS/2 can use PAE to a limited degree, mostly used as a ram disk. Things are setup by os2ldr before the kernel launches. Current os2ldr is based on QSINIT, from the latest blurb,
--- Code: --- QSINIT - 2025-08-10
QSINIT had been updated (2025-08-10):
Binary: ftp://212.12.30.18/public/QS/QS_LDR.ZIP
Source Code and SDK: ftp://212.12.30.18/public/QS/QS_SDK.ZIP
QSINIT is a small 32-bit something (you may call it an operating system, or a "small DOS"), that you can write applications for, and that may act as an OS/2 kernel bootloader.
The author of this software, Dmitry Zavalskov, has reserved the copyright to himself. The binary is released as freeware, the source code as freeware for non-commercial use.
--- End code ---
Much of the kernel is actually 16 bit, with 16 bit code limited to 1 GB address space. OS/2 2.x before Warp V4 FP13 (Warp Server also supported high memory earlier) only supported 1 GB of address space with the kernel getting the upper half, so you'd have to work from the lower 512MBs (less as much is used by DLL's) and there are still API's that underneath are 16 bit and have to reside in low memory.
kerravon:
--- Quote from: Dave Yeo on October 13, 2025, 07:06:38 pm ---Much of the kernel is actually 16 bit, with 16 bit code limited to 1 GB address space. OS/2 2.x before Warp V4 FP13 (Warp Server also supported high memory earlier) only supported 1 GB of address space with the kernel getting the upper half, so you'd have to work from the lower 512MBs (less as much is used by DLL's) and there are still API's that underneath are 16 bit and have to reside in low memory.
--- End quote ---
I'm not sure if we're talking cross-purposes. In a DOS extender, the entire DOS nominally resides in the lower 640k too. That doesn't prevent you from getting access to 4 GiB of memory for your 32-bit program.
Ditto any 64-bit OS/2 extender I created would simply reside above 4 GiB to keep things simple. And the rest would reside wherever OS/2 loaded my executable - lower 512 MiB or whatever.
Note that there is work afoot to stand up a (better) public domain x64 compiler over here:
https://github.com/sal55/langs
(mcc.asm mainly, but also older mcc.c)
There is no public domain notice on either at the moment though. Still fixing bugs that affect my toolchain.
Rich Walsh:
--- Quote from: kerravon on October 13, 2025, 03:08:25 pm ---
--- Quote from: Rich Walsh on September 13, 2025, 01:15:54 am ---the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled. You can have 16/32 code or 32/64 code but not 16/32/64.
--- End quote ---
I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?
https://bttr-software.de/forum/board_entry.php?id=22728
That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”).
--- End quote ---
The author of that posting missed an important point: to have code run in AMD64 compatibilty mode, the host OS must be 64-bit. Given that OS/2 is 32-bit, the CPU can only run in one of the legacy modes (i.e. 16 or 32-bit).
kerravon:
--- Quote from: Rich Walsh on October 15, 2025, 08:11:42 am ---
--- Quote from: kerravon on October 13, 2025, 03:08:25 pm ---
--- Quote from: Rich Walsh on September 13, 2025, 01:15:54 am ---the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled. You can have 16/32 code or 32/64 code but not 16/32/64.
--- End quote ---
I think you might have been misinterpreted, and you are in fact correct, but could you please answer the below?
https://bttr-software.de/forum/board_entry.php?id=22728
That’s what I thought, but it is incorrect. Long mode can deal with all three code segment sizes at the same time, as indicated by the very first table in the system programming volume of AMD’s architecture manual (“Operating Modes”).
--- End quote ---
The author of that posting missed an important point: to have code run in AMD64 compatibilty mode, the host OS must be 64-bit. Given that OS/2 is 32-bit, the CPU can only run in one of the legacy modes (i.e. 16 or 32-bit).
--- End quote ---
Hi Rich. But in what situation is 32/64 allowed (as per your original post), but not 16/32/64?
Perhaps you were considering Windows 10, where you need to choose between 16/32 or 32/64?
I think Windows 10 could have supported 16-bit PM programs (CM16), and CM32 and LM64 all at the same time, but since V8086 wasn't available, they just abandoned 16-bit completely.
But they didn't necessarily have to do that - they could have spent the effort to support Win16 PM16 programs.
Presumably that is not cost-justified though. But I'm just interested in the technical possibility.
Lars:
I think Rich said it all and I am quoting the Intel Spec (where Intel Term "IA-32e mode" = "AMD64 compatiblity mode"):
Chapter 6.2.1 "Code-Segment Descriptor in 64-bit Mode"
IA-32e mode uses a previously unused bit in the CS descriptor. Bit 53 is defined as the 64-bit (L) flag and is
used to select between 64-bit mode and compatibility mode when IA-32e mode is active (IA32_EFER.LMA = 1).
See Figure 6-2.
— If CS.L = 0 and IA-32e mode is active, the processor is running in compatibility mode. In this case, CS.D
selects the default size for data and addresses. If CS.D = 0, the default data and address size is 16 bits. If
CS.D = 1, the default data and address size is 32 bits.
— If CS.L = 1 and IA-32e mode is active, the only valid setting is CS.D = 0. This setting indicates a default
operand size of 32 bits and a default address size of 64 bits. The CS.L = 1 and CS.D = 1 bit combination is
reserved for future use and a #GP fault will be generated on an attempt to use a code segment with these
bits set in IA-32e mode.
That said, the Processor will only recognize the "CS.L" flag and treat it as such when it has already been placed into the "IA-32e mode".
Only then will "CS.L" make the difference (CS.L = 0 -> CS.D selects between 16-bit or 32-bit as the default data/address size, CS.L = 1 -> CS.D is ignored and even expected to be 0 and default data size of 32-bit and default address size is 64-bit)
As far as I understand, if you run the Processor in IA-32e mode you will have a code segment descriptor with "CS.L = 1" (in the global descriptor table). This descriptor is used for 64-bit protected mode programs by loading it into CS, it will never change, implicitely cover all of the address range and effectively disables segment protection (which is never used in IA-32e "native" mode).
In order to run 32-bit or 16-bit protected mode programs, you will add additional code segment descriptor with "CS.L = 0" (in the global descriptor table) which when CS is loaded with this segment selector will allow the distinction between 16-bit and 32-bit default data/address size with the Processor looking at the "CS.D" bit.
You should be able to verify this under "64-bit" Windows: if you run a 64-bit program under a debugger, it should have a different CS selector then if you run a 32-bit program under that debugger.
Navigation
[0] Message Index
[*] Previous page
Go to full version