Recent Posts

Pages: [1] 2 3 ... 10
1
Graphics and Window Design / Re: Icons For Your OS/2 Desktop No.8
« Last post by Jan-Erik Lärka on October 15, 2025, 09:44:26 pm »
Thanks for sharing this Jan-Erik.

I also want to upload it to hobbes.
Please do!
Is this your eight release? Does it replace 1 to 7 version?

Regards
Yes, but some icons have evolved, while others have been replaced and/or removed.
I've changed several names compared to prevoious releases.
2
Graphics and Window Design / Re: Icons For Your OS/2 Desktop No.8
« Last post by Martin Iturbide on October 15, 2025, 09:31:55 pm »
Thanks for sharing this Jan-Erik.

I also want to upload it to hobbes.
Is this your eight release? Does it replace 1 to 7 version?

Regards
3
Programming / Re: native mainframe mini-clone
« Last post by kerravon on October 15, 2025, 07:13:25 pm »
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.

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”).


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).

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.
4
Graphics and Window Design / Icons For Your OS/2 Desktop No.8
« Last post by Jan-Erik Lärka on October 15, 2025, 06:53:42 pm »
Hello,

Some OS/2 icons to look at, you'll notice that you don't need full color depth for such small images.
Available as 40x40, 32x32, 20x20 and 16x16.
5
General Discussion / Re: LEO mirror
« Last post by Ian B Manners on October 15, 2025, 03:41:56 pm »
6
Programming / Re: native mainframe mini-clone
« Last post by Rich Walsh on October 15, 2025, 08:11:42 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.

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”).


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).



7
Programming / Re: native mainframe mini-clone
« Last post by kerravon on October 13, 2025, 07:27:51 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.

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.
8
Programming / Re: native mainframe mini-clone
« Last post by Dave Yeo on October 13, 2025, 07:06:38 pm »
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: [Select]
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.

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.
9
General Discussion / Re: LEO mirror
« Last post by Martin Iturbide on October 13, 2025, 05:22:31 pm »
Thanks Dave

I had also created a wiki page for it to don't forget about it:
-- https://www.os2world.com/wiki/index.php?title=LEO_(Link_Everything_Online)

Regards
10
Programming / Re: native mainframe mini-clone
« Last post by kerravon on October 13, 2025, 03:08:25 pm »
You would need a device driver which operates at Ring 0.  In the UEFI version of ArcaOS, the bootloader stub which remains after the OS is running will switch to long-mode to read the machine's NVRAM variables, then will switch back. While doing so, all of OS/2 must stop because it is 100% *incompatible* with long-mode. Why? Because 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.

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”). What you cannot have is VM86 mode. I verified PM16 on my current Linux installations last week (from a 32-bit task). One significant piece of functionality is missing, although this is just a limitation of Linux, not the machine architecture: having your own SIGSEGV handler intercept general protection faults from that 16-bit code segment. Unfortunately, the kernel does not understand this kind of code and will kill the faulting process directly instead of invoking its signal handler.


Thanks. Paul.
Pages: [1] 2 3 ... 10