Author Topic: DosDevIOCtl disabling keyboard in VIO mode  (Read 11178 times)

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
DosDevIOCtl disabling keyboard in VIO mode
« on: March 02, 2024, 09:24:07 am »
Running this program in fullscreen mode works fine.

Running it in a VIO window causes the keyboard to be disabled and I need to use the mouse to reboot (CAD also works to initiate a reboot).

Can someone tell me:

1. Are the results (that I noted as strange) correct operation of the OS/2 functions?

2. Is there a way of getting these functions to work as intended (ie switch to binary mode, then switch back to text mode, as the Physical Device Driver Reference documents as supported functionality)?

Note that the switch to binary mode IS successful - even in the VIO windows - and my real (larger) app does work fine (that app doesn't switch back to text mode until termination time though, so I don't see a problem). It's only after it terminates that I have an issue, which is ironic.

Also note that I am aware of the Kbd* functions that could be used instead, but I don't wish to do thunking (including automated compiler thunking) *in my executable*.

If I use the DosDevIOCtl function, my executable is pure 32-bit. What happens in the doscalls.dll I don't care about. At least nominally I have no insight into that, as it is OS/2 internals, and those internals could change overnight. Also I am not interested in using high memory. This isn't a question about high memory. I will be using standard 32-bit DosOpen and standard 32-bit DosDevIOCtl (ordinal 284 in doscalls.dll or equivalent).

Note that I am using ArcaOS 5.0.8.

Code below.

Thanks. Paul.


wcl386 -bt=os2 -l=os2v2 pdptest.c os2386.lib -"option map"

Code: [Select]
#include <stdio.h>

#define INCL_DOS
#include <os2.h>

int main(void)
{
    ULONG kbdfile;
    static USHORT fileAttr = 0;
    static ULONG newsize = 0;
    ULONG action;
    static ULONG openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
    static ULONG openAction = OPEN_ACTION_OPEN_IF_EXISTS;
    ULONG datalen;
    ULONG parmlen;
    USHORT rc;
    BYTE bb;
    static BYTE oldbb;

    rc = DosOpen((PSZ)"KBD$",
                 &kbdfile,
                 &action,
                 newsize,
                 fileAttr,
                 openAction,
                 openMode,
                 0);
    if (rc != 0)
    {
        return (-1);
    }

    parmlen = 0;
    datalen = sizeof oldbb;
    /* get old input mode */
    rc = DosDevIOCtl(kbdfile,
                4,
                0x71,
                NULL,
                0,
                &parmlen,
                &oldbb,
                sizeof oldbb,
                &datalen);

    printf("rc is %d\n", rc);
    printf("surprisingly, oldmode is already binary %x\n", (int)oldbb);
   
    printf("surprisingly, we need to set binary mode, even though it is already set\n");
    /* set binary mode */
    bb = 0x80;
    parmlen = sizeof bb;
    datalen = 0;
    rc = DosDevIOCtl(kbdfile,
                4,
                0x51,
                &bb,
                sizeof bb,
                &parmlen,
                NULL,
                0,
                &datalen);

    printf("rc is %d\n", rc);
    printf("restoring old (binary) mode is identical and useless and behavior is same\n");
    printf("so setting text mode instead\n");
    oldbb = 0;
    parmlen = sizeof oldbb;
    datalen = 0;
    rc = DosDevIOCtl(kbdfile,
                     4,
                     0x51,
                     &oldbb,
                     sizeof oldbb,
                     &parmlen,
                     NULL,
                     0,
                     &datalen);
    printf("rc is %d\n", rc);
    rc = DosClose(kbdfile);
    printf("rc is %d\n", rc);
    printf("surprisingly, keyboard is now inoperative and you need to use mouse to reboot\n");
    return (0);
}
« Last Edit: March 02, 2024, 02:08:22 pm by Martin Iturbide »

Wim Brul

  • Sr. Member
  • ****
  • Posts: 295
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #1 on: March 02, 2024, 10:22:10 am »
Your call to DosDevIOCtl to get old input mode has been coded incorrectly. Should use the parameter packet rather than the data packet.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #2 on: March 02, 2024, 11:00:12 am »
Your call to DosDevIOCtl to get old input mode has been coded incorrectly. Should use the parameter packet rather than the data packet.

Thanks for that - you had me excited that there was finally hope.

Unfortunately, with this code:

parmlen = sizeof oldbb;
datalen = 0;
/* get old input mode */
rc = DosDevIOCtl(kbdfile,
            4,
            0x71,
            &oldbb,
            sizeof oldbb,
            &parmlen,
            NULL,
            0,
            &datalen);

printf("rc is %d\n", rc);


I get rc of 87 which is apparently:

bseerr.h: #define ERROR_INVALID_PARAMETER         87


Also note that the original code, when run in fullscreen mode, returns a sensible 0, indicating text mode.

Did I make a second mistake in the above code?

Thanks. Paul.

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 339
  • Karma: +23/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #3 on: March 02, 2024, 08:40:26 pm »
Did I make a second mistake in the above code?

Yes: your code fails to accommodate the environment it finds itself in.

In fullscreen mode it works because it assumes ASCII (correctly), switches to binary (to capture special key-combos?), then restores ASCII. IOW, it all works exactly as you'd expect a primitive terminal would when accessing real hardware.

However, iIn VIO mode that isn't the case: this is an _emulation_ provided by Presentation Manager. PM has its own good reasons for switching to binary mode before giving you an emulated console. Since it appears to get unhappy when you mess with it ..umm.. don't.

What are you trying to do? Capture Ctrl-C and the like? If so, there are probably higher-level 32-bit functions to handle this (e.g. DosSetSignalExceptionFocus() ).

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #4 on: March 03, 2024, 01:24:29 am »
Did I make a second mistake in the above code?

Yes: your code fails to accommodate the environment it finds itself in.
Hi Rich. Thanks for your reply.

Quote
In fullscreen mode it works because it assumes ASCII (correctly), switches to binary (to capture special key-combos?), then restores ASCII. IOW, it all works exactly as you'd expect a primitive terminal would when accessing real hardware.

However, iIn VIO mode that isn't the case: this is an _emulation_ provided by Presentation Manager. PM has its own good reasons for switching to binary mode before giving you an emulated console. Since it appears to get unhappy when you mess with it ..umm.. don't.
Ok, thanks. Do you know if this is documented anywhere? That I can't manipulate the keyboard in a VIO environment.

Quote
What are you trying to do? Capture Ctrl-C and the like? If so, there are probably higher-level 32-bit functions to handle this (e.g. DosSetSignalExceptionFocus() ).
I am trying to switch off echo and line buffering so that I can write a fullscreen text application, like microemacs 3.6. As a pure 32-bit app (no thunking within my executable). As such - OS/2 should not do keyboard character echoing. The application will deal with that.

I looked up DosSetSignalExceptionFocus and it seemed to be purely related to exception processing, not switching the terminal to raw mode.

Any other ideas? Worst case scenario I simply mark the application as fullscreen only. But it does irk me that thunking either within my own executable or using a non-doscalls DLL could get VIO working as well. I only want to use 32-bit functions from doscalls. And it comes so close to working - even in VIO. This is the only holdout.

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 339
  • Karma: +23/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #5 on: March 04, 2024, 06:46:11 am »
Quote
What are you trying to do?
I am trying to switch off echo and line buffering so that I can write a fullscreen text application, like microemacs 3.6. As a pure 32-bit app (no thunking within my executable). As such - OS/2 should not do keyboard character echoing. The application will deal with that.

I've never had the slightest interest in writing a true text-mode app, so I have no hand-on experience. However, perusing the 'Control Program Reference', I found KbdSetStatus(pkbdinfo, hkbd). The description of the KBDINFO structure's "fsMask" member lists these flags:

Code: [Select]
fsMask (USHORT)
State mask.

  Bits 15-9 Reserved.
  Bit 8 Shift return is on.
  Bit 7 Length of the turn-around character (meaningful only if bit 6 is on).
  Bit 6 Turn-around character is modified.
  Bit 5 Interim character flags are modified.
  Bit 4 Shift state is modified.
  Bit 3 ASCII mode is on.
  Bit 2 Binary mode is on.
  Bit 1 Echo off.
  Bit 0 Echo on.

Isn't this what you're looking for? (I _assume_ this is a 32-bit entry point to a 16-bit function.)

Lars

  • Hero Member
  • *****
  • Posts: 1277
  • Karma: +65/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #6 on: March 04, 2024, 08:56:24 am »
The "Kbd", "Mou" and "Vio" functions have no 32-bit thunking function, the compiler will need to provide the thunk (as the VAC compiler and Watcom compilers will do if the 16-bit function is properly declared as such).
But I also do not understand why you would be dogmatic about using 32-bit only. OS/2 has a strong 16-bit heritage, that's just the way it is.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #7 on: March 04, 2024, 10:11:55 am »
I've never had the slightest interest in writing a true text-mode app, so I have no hand-on experience.

Whereas I am *only* interested in text mode programs - either line mode thus can conform to ANSI X3.159-1989 or fullscreen mode (need ANSI X3.64 also).

As opposed to using APIs that haven't been standardized for whatever reason.

I'm also interested in catering for what I see as the "lowest common denominator" - blind people - who can only "see" text.

I spent some effort trying to cater for deafblind too, in the third world too where Braille readers are prohibitively expensive, but there are other reasons to stop at just blind (ie 95% or something of deafblind people have other issues that made them deafblind in the first place).

Also I am mainly interested in catering to fellow programmers - including budding third world programmers who can only afford a smartphone (I have a native ARM equivalent of Bochs running MSDOS using an external keyboard for US$2).

Quote
However, perusing the 'Control Program Reference', I found KbdSetStatus(pkbdinfo, hkbd)

Isn't this what you're looking for? (I _assume_ this is a 32-bit entry point to a 16-bit function.)

No, the APIENTRY16 shows that it is 16-bit and being auto-thunked:

D:\watcom\h\os2>grep KbdSetStatus *
bsesub.h: #define KbdSetStatus     KBD16SETSTATUS
bsesub.h: USHORT APIENTRY16 KbdSetStatus(PKBDINFO,HKBD);

D:\watcom\h\os2>

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #8 on: March 04, 2024, 10:58:06 am »
But I also do not understand why you would be dogmatic about using 32-bit only.
Firstly from a technical cleanliness perspective. I thought that OS/2 2.0 was about upgrading to 32-bit. 30 years later and I'm still required to deal with 16-bit? Not what I want to do. Especially not for one problematic function (DosDevIOCtl) that would force me into 16-bit. I'd rather be forced into fullscreen.

Secondly, the pure 32-bit allows me to write a mini-clone of OS/2 either as an app that runs under another OS (e.g. UC386L that runs under Linux) or as a standalone OS (PDOS/386). Both available from http://pdos.org - new version that implements DosDevIOCtl uploaded a couple of minutes ago.

Note that "mini clone" means that it runs *certain* OS/2 executables - basically just the ones that were built with PDPCLIB (see makefile.wat). So anything that is C90-compliant, or uses ANSI x3.64 "extensions" and has been built with PDPCLIB or equivalent (I doubt that there is anything equivalent currently, but there is no barrier to that).

Quote
OS/2 has a strong 16-bit heritage, that's just the way it is.
And it doesn't need to be. With proper funding, OS/2 could be stripped internally of any 16-bit vestiges that affect a pure 32-bit application. As well as being a commercial competitor to Windows (note that I am similarly able to convert OS/2 into a mini Win32 clone with the use of win32os2 at pdos.org using the same technique). And yes, I know that Odin for OS/2 and Linux WINE are nominally superior (but neither are what I want).

So anyway, I want to be able to build a 32-bit OS/2 binary today, that runs on all those environments. And even if I lose the source code, the binary remains pure as better OS/2 clones come online.

And I don't consider 64-bit to be necessary either. Meaning OS/2 is perfectly viable. When I was doing some work on the mainframe, I was being chided for "my" program (a fork of gcc 3.2.3) requiring more than 16 MiB of memory, thus breaking the S/370 architectural limit). Personally I disagree that using more than 16 MiB is illegitimate and that I need to "fix" "my" "broken" program. But requiring 2 GiB or even more is beyond ridiculous. And yes, I know the mainframe has been updated (z/OS) to allow programmers to be ridiculous with 64-bit. But it's not a wagon I want to be on.

BTW, we're expecting the PDOS toolchain to be able to target OS/2 soon. It's down to just the linker (pdld) now, and it is being actively worked on. It can produce LX executables already, but not yet resolve DLL references. Likely day(s) away from working. Windows is already done. ie a self-hosting mini Win32 clone. You could potentially call it a self-hosting mini OS/2 clone already, but it's not doing that with OS/2 executables (it could though), or the ability to reproduce those OS/2 executables (that's what's missing currently).

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #9 on: March 05, 2024, 10:09:24 am »
Secondly, the pure 32-bit allows me to write a mini-clone of OS/2 either as an app that runs under another OS (e.g. UC386L that runs under Linux) or as a standalone OS (PDOS/386). Both available from http://pdos.org - new version that implements DosDevIOCtl uploaded a couple of minutes ago.

I forgot to mention - OS/2 is not the only supported API. As of a few minutes I added another, so the total is:

1. 32-bit MSDOS (sort of - since the original didn't exist)
2. Win32
3. Linux
4. OS/2
5. PDOS-generic

The last one is my own format - programs receive a single struct parameter basically containing pointers to all the C90 functions.

And pretty much all of them were implemented via different techniques (1 and 3 via full interrupts, OS/2 by intercepting doscalls, Win32 by intercepting the C library msvcrt and PDOS-generic via stack, so that a DLL is not required).

PDOS/386 fits on a 360k floppy. And the bios.exe in UC386L that is my answer to both WINE (Win32) and 2wine (OS/2), plus PDOS-generic is a single 53k executable with no dependencies on anything - not even libc.

And it took just 30 years to create.

Also note that I weaned my OS/2 apps off the stack (using DosGetInfoBlocks) and my Linux executables off the stack also (using /proc/<pid>/command), so that neither registers nor stack were used by any executables, clearing the way for a very simple unconditional parameter for use by PDOS-generic (any executable format is fine for any API).

All C90 source code (except for minimal masm-compatible assembler). And the tools (including a sufficiently masm-compatible assembler) are all included.

And all public domain so you are free to create a commercial product without restrictions (ie you can close-source it if you wish). It's not meant to be commercial-quality as-is. That's the value that can be added. As is, it is a starter system.

That uses legacy boot BTW. If you want 64-bit UEFI I have a mini-Win64 system (including toolchain).

I do have plans to have a EFI\BOOT\BOOTX64.EFI that doesn't exit boot services and provides a 16-bit BIOS and disables interrupts before switching to PM32 then RM16 then LM64 then returning to RM16 then returning to PM32, but it hasn't been priority to create that given that I can simply treat Linux as a glorified BIOS (ie UC386L approach) instead of requiring my own BOOTX64.EFI and a (large) glorified BIOS (UEFI) in firmware instead of disk. The apps (OS/2 etc) are unchanged regardless of which of those things are done.

So now I'm still waiting on the pdld author in Slovakia (I didn't receive an update overnight) and I will complete the proof of concept on OS/2 by building microemacs 3.6 (ie fullscreen text) with gccwin 3.2.3 which now supports the _System keyword (probably not required though, especially since we need to import by ordinal anyway - but the option now at least exists).

I'm not sure if there is a barrier to OS/2 being updated so that it supports in VIO the executables that I currently have to run fullscreen. ie I don't know if I have painted myself into a corner on that one as I don't know what the underlying issue is.

Note that PDOS/386 is meant to be a simple (like MSDOS), understandable OS that can be used as an environment to then create a better OS or whatever else you may want. So nominally it doesn't do multitasking and VM. I say nominally, because a different person from Slovakia (female this time) added multitasking code, but I haven't activated it, don't use it, and she disappeared, so it is no longer supported.

But I'm starting afresh with PDOS-generic (in a different directory - generic, not src), and still in the process of restructuring and defining that if anyone can see any actual use for any of this and would like to assist with "strategic direction". :-) Up until now it has been more proof of concept than anything else. Like - can I wean OS/2 off the stack? Can I wean Linux off the stack? Can I recurse into the C library? Can I make the C library deal with different APIs in a single executable without separate compilation and separate paths?

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #10 on: March 06, 2024, 06:56:04 pm »
So now I'm still waiting on the pdld author in Slovakia (I didn't receive an update overnight)
The design has now been completed (by him). However, it is still to be debugged.

The first problem I encountered is that the executable produced (by a new makefile.sos), caused ArcaOS to hang.

Does anyone have any idea what the philosophy here is? Is someone (ie Arca NOAE) trying to bullet-proof ArcaOS from rogue executables, or are there not enough resources such that it is only OS/2 bugs found when running technically correct programs that are fixed?

I'll attempt to attach the executable that caused the hang. I have a supported, commercial license for ArcaOS (even though I don't do anything commercial - I may wish to in the future), so I can report a bug, but I won't bother wasting their time on a development issue if that is the situation. Thanks.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4757
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #11 on: March 06, 2024, 08:44:48 pm »
Hello kerravon

Does anyone have any idea what the philosophy here is? Is someone (ie Arca NOAE) trying to bullet-proof ArcaOS from rogue executables, or are there not enough resources such that it is only OS/2 bugs found when running technically correct programs that are fixed?
I don't think so, for what I know the way ArcaOS runs binaries is the same as OS/2 Warp 4.52. There is no way to sign binaries and have any other extra security.

Not that I understand much of your conversation, but I tried the executable on my ArcaOS 5.1.0 VM.
I have this message when I try to run it (Full screen and Windowed version).
Quote
[C:\HOME\MARTIN\Downloads\TEMP]pdptest
SYS0193: C:\HOME\MARTIN\DOWNLOADS\TEMP\PDPTEST.EXE cannot be run in a OS/2
session.

It looks to me that is not a OS/2 binary and it does not hang my system. 

Secondly, the pure 32-bit allows me to write a mini-clone of OS/2 either as an app that runs under another OS (e.g. UC386L that runs under Linux) or as a standalone OS (PDOS/386). Both available from http://pdos.org - new version that implements DosDevIOCtl uploaded a couple of minutes ago.

Note that "mini clone" means that it runs *certain* OS/2 executables - basically just the ones that were built with PDPCLIB (see makefile.wat). So anything that is C90-compliant, or uses ANSI x3.64 "extensions" and has been built with PDPCLIB or equivalent (I doubt that there is anything equivalent currently, but there is no barrier to that).
I have interest to know what are you doing there. I don't know if you can share in a different forum thread what are you doing and what are your goals with your project.

Regards
« Last Edit: March 06, 2024, 08:49:10 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #12 on: March 06, 2024, 09:34:55 pm »
Does anyone have any idea what the philosophy here is? Is someone (ie Arca NOAE) trying to bullet-proof ArcaOS from rogue executables, or are there not enough resources such that it is only OS/2 bugs found when running technically correct programs that are fixed?
I don't think so, for what I know the way ArcaOS runs binaries is the same as OS/2 Warp 4.52. There is no way to sign binaries and have any other extra security.
I'm not after signed binaries/security. Just the system shouldn't crash/hang because of a rogue executable.

Quote
Not that I understand much of your conversation, but I tried the executable on my ArcaOS 5.1.0 VM.
I have this message when I try to run it (Full screen and Windowed version).
Quote
[C:\HOME\MARTIN\Downloads\TEMP]pdptest
SYS0193: C:\HOME\MARTIN\DOWNLOADS\TEMP\PDPTEST.EXE cannot be run in a OS/2
session.

It looks to me that is not a OS/2 binary and it does not hang my system. 
Thanks for that. I went to run the executable for a 3rd time, and to my surprise, I got the same error you got. So it turns out I don't have a reproducible problem of hanging after all, and OS/2 is likely unhappy about the small MZ header. I have given that result back to the pdld author for comment.

Quote
Quote
Note that "mini clone" means that it runs *certain* OS/2 executables - basically just the ones that were built with PDPCLIB (see makefile.wat). So anything that is C90-compliant, or uses ANSI x3.64 "extensions" and has been built with PDPCLIB or equivalent (I doubt that there is anything equivalent currently, but there is no barrier to that).
I have interest to know what are you doing there. I don't know if you can share in a different forum thread what are you doing
I can create a new thread once I have proven that we can create executables and run fullscreen applications.

Quote
and what are your goals with your project.
I don't have a set goal. In the Fidonet days I had endless entertainment for free and I thought that was great. And I had a look at all the software that was involved in that, and decided - not necessarily for any good reason - to replace it all with public domain C90-compliant code - if that was even technically possible.

The binaries for MSDOS itself looked quite small, so I expected even the OS to be achievable.

Reality was a bit more complex than that, but simply persevering for long enough got a result.

You can suggest a goal if you like. I managed to make contact with a random blind programmer yesterday. He had written about the difficulties he faced. But he hasn't yet responded to my question about whether he has a goal that I can assist with.

I stopped using OS/2 in 1999 when my laptop was stolen when I was in the UK. I returned to Australia shortly after and I think I bought a new computer and it came with Windows and I believe my interest at the time was IBM mainframes, and there was no reason to be on OS/2. But 25 years later and a long series of events have brought me back - sort of. I'm currently using Windows 2000 as my main development environment (under Virtualbox, allowing me to switch from Windows 10 host to Linux host easily), but I could switch from Windows 2000 to Arca OS (still protected by Virtualbox).

kerravon

  • Jr. Member
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #13 on: March 06, 2024, 10:20:30 pm »
pdld has been updated to fix a couple of errors, but result is still the same (OS/2 says it can't run it).

I have suggested that the MZ header is too small for OS/2 to cope with, but he thought it was one of the other reasons.

Latest executable attached.

Roderick Klein

  • Hero Member
  • *****
  • Posts: 659
  • Karma: +14/-0
    • View Profile
Re: DosDevIOCtl disabling keyboard in VIO mode
« Reply #14 on: March 07, 2024, 12:23:01 am »
But I also do not understand why you would be dogmatic about using 32-bit only.
Firstly from a technical cleanliness perspective. I thought that OS/2 2.0 was about upgrading to 32-bit. 30 years later and I'm still required to deal with 16-bit? Not what I want to do. Especially not for one problematic function (DosDevIOCtl) that would force me into 16-bit. I'd rather be forced into fullscreen.

Secondly, the pure 32-bit allows me to write a mini-clone of OS/2 either as an app that runs under another OS (e.g. UC386L that runs under Linux) or as a standalone OS (PDOS/386). Both available from http://pdos.org - new version that implements DosDevIOCtl uploaded a couple of minutes ago.

Note that "mini clone" means that it runs *certain* OS/2 executables - basically just the ones that were built with PDPCLIB (see makefile.wat). So anything that is C90-compliant, or uses ANSI x3.64 "extensions" and has been built with PDPCLIB or equivalent (I doubt that there is anything equivalent currently, but there is no barrier to that).

Quote
OS/2 has a strong 16-bit heritage, that's just the way it is.
And it doesn't need to be. With proper funding, OS/2 could be stripped internally of any 16-bit vestiges that affect a pure 32-bit application. As well as being a commercial competitor to Windows (note that I am similarly able to convert OS/2 into a mini Win32 clone with the use of win32os2 at pdos.org using the same technique). And yes, I know that Odin for OS/2 and Linux WINE are nominally superior (but neither are what I want).

So anyway, I want to be able to build a 32-bit OS/2 binary today, that runs on all those environments. And even if I lose the source code, the binary remains pure as better OS/2 clones come online.

Having worked on OS/2 for 25 years and more then 10 years on eComStation project I have somewhat experience in this. The issue is that it seems the funding that would be needed never arrived. It seemed nobody was interested in this approach.  Could it be done, I guess so. OS/2 also had ODIN on it, so in the other direction that might work.  However it seems that in most cases it was cheaper and faster to create a VM. Take Virtual PC with OS/2, Svista done by Serenity Systems. I seem to under years ago a France OS/2 customer wanted to move froim OS/2 to Linux. The problem was they had lost the sources of the OS/2 app. I seem to understand IBM tried to create an API layer on Linux. The project was never finished.

Anyway I am not saying it can not be done. I have no clue how much such a project would cost.  But I am skeptical at this moment if it will ever come off the ground.

Roderick