OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: kerravon on March 02, 2024, 09:24:07 am

Title: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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);
}
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Wim Brul 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Rich Walsh 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() ).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Rich Walsh 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.)
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Lars 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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>
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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?
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Martin Iturbide 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
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon 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.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Roderick Klein 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
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Tom on March 07, 2024, 12:55:22 am
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. 

That plus the MZ at the start of the header suggests that maybe pdptest.exe is a DOS program. What happens when you run it in a DOS window?

Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 07, 2024, 01:01:33 am
In a DOS window,
Code: [Select]
H:\TMP>pdptest
SYS3011: The .EXE file that starts the program you specified contains
an error.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 07, 2024, 01:03:16 am
Tried lxlite, a program originally for compressing lx files, extended quite a bit. It reports error reading executable.
yum install lxlite
lxlite /?
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 07, 2024, 03:24:04 am
But I am skeptical at this moment if it will ever come off the ground.
Don't get me wrong. I'm skeptical too. These are all things beyond my control so I have no actual expectations. I can only tell you what I do that is within my control.

I basically have a similar opinion to this guy:

https://www.quora.com/Why-did-you-leave-software-engineering/answer/Jeff-Sturm-2

"The inmates are truly running the asylum, as the saying goes"

He chose to simply leave.

I'm not leaving. I'm some sort of "prepper".

I've been basically restricting myself to what is nominally universal (even on the mainframe) - C90 - for about 35 years.

But if I keep that approach religiously, I would have to use edlin as my editor.

I knew about ANSI X3.64, but I also knew the mainframe didn't support it (ie send EBCDIC ANSI escapes from MVS proper rather than running Unix basically as a subsystem).

It took decades to get that working to my satisfaction too, and even then only by creating a new version of PDOS (z/PDOS).

Ironically I only got Windows working to my satisfaction a couple of weeks ago or something. Something I thought couldn't be solved without cooperation from Microsoft was able to be solved in my C library. Ditto Linux. MSDOS I had working (albeit with repercussions) with a third party tool (ANSIPLUS) before I realized I could use a similar technique that I used on Windows.

OS/2 was only a couple of days ago, on top of the longer-standing issue of not being able to use VIO.

A fundamental problem was that when the user presses ESC, I expect two ESC (Wikipedia says that is a defined sequence) to get to the application rather than requiring the app to use a non-C90 timeout.

All these things were unknown to me when I started writing PDOS in 1994. And I had been asking the question longer than that. I was surprised that there wasn't a version (or at least, lookalike) of MSDOS I could use on the mainframe when I was a sysprog in 1987). Even now I haven't quite created that, but at least I now believe I have two designs (for CKD and FBA).

Quote
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.
What interests people isn't always obvious. Who would have believed that people would be willing to pay money for an absurd/useless calculation to be made (Bitcoin)? Babbage's machine was built a couple of decades ago. And the US government paid IBM to write MVS to track ICBMs I think. The US government has broken up monopolies before (Bell). Rather than breaking up Microsoft (likely difficult and pointless) they could choose to fund IBM and OS/2. Or some other government or consortium could do that. Or create an unencumbered Windows-compatible OS from scratch.

Or perhaps a new culture of making all software C90-compliant and building it for every 32-bit OS in existence.

Anyway, I have a strong interest in doing what I can with what is under my control regardless of what happens with what I can't control.

But I'm open to suggestions on what I should do with what I now have. I can potentially provide limited funding. I recently spent about US$20k mainly on old software (e.g. Microsoft C 6.0) to fill in some gaps in my knowledge with regards to PDOS (e.g. can the PDOS source base be built with 6.0? 5.1 wasn't good enough (bought that too and found out). 7.0 (bought that too) doesn't run on an 8086 (only found out after I bought it)).

I have previously hired (and largely trained) some programmers, e.g. from Vietnam and where I now live (Philippines). But I have found it almost impossible to find anyone willing to take my money. I can't afford full western contract rates currently. That may potentially change though (an investment waiting to make returns).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Rich Walsh on March 07, 2024, 05:56:27 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.

How did you link this thing? Its layout doesn't look anything like an OS/2 LX executable.
Using 'exehdr' (from the OS/2 Toolkit) I find this:

Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00400000 00005fcd 00000001 00000006 EXECUTABLE, READABLE, 32-bit
0002 00406000 000006d8 00000007 00000001 READABLE, WRITEABLE, 32-bit
0003 00407000 000067b0 00000008 00000007 READABLE, WRITEABLE, 32-bit

The virtual addresses (2nd column) for a small program like this should be:
0001 00010000
0002 00020000
0003 00030000

The "00400000" looks more like a 16-bit segmented address (i.e. 0040:0000).

Then too, we have:

Code: [Select]
Initial CS:EIP:                 object 1 offset 00000000
Initial SS:ESP:                 object 4 offset 00008000

Your stack is in a non-existent segment. Your entrypoint _could_ be at offset 0x00 but seldom is in most programs. I'm surprised that the program you wrote about originally ever ran if it had this kind of layout.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 07, 2024, 06:43:31 pm
How did you link this thing? Its layout doesn't look anything like an OS/2 LX executable.
Using pdld.

Quote
The virtual addresses (2nd column) for a small program like this should be:
0001 00010000
0002 00020000
0003 00030000

The "00400000" looks more like a 16-bit segmented address (i.e. 0040:0000).
It's probably a "leftover" from Windows PE. No reason to change it. But I'll pass your comments on to see if he would like to change it to be more OS2-ish.

Quote
Initial CS:EIP:                 object 1 offset 00000000
Initial SS:ESP:                 object 4 offset 00008000

Your stack is in a non-existent segment. Your entrypoint _could_ be at offset 0x00 but seldom is in most programs.
Both of those are exactly what I specified.

Quote
I'm surprised that the program you wrote about originally ever ran if it had this kind of layout.
The original program (almost same source code) was built with Watcom tools. What you see above is a new suite of tools.

Anyway, his most recent modification caused ArcaOS to crash. I reported the issue to Arca Noae and I'll give them overnight to comment without disturbing anything.

But I have already been sent a fix (from Slovakia - noting that today I did my own debugging to a point where I asked him to explain a result) that should hopefully fix the issue I reported in this thread, and I'll commit (and then test) that in 8 hours or whatever depending on if Arca Noae gives me a reason to pause longer. I'm keen to get on with the development, but I'm also keen to bulletproof ArcaOS. I don't like bugs in anything.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Rich Walsh on March 07, 2024, 07:19:01 pm
Quote
I'm surprised that the program you wrote about originally ever ran if it had this kind of layout.
The original program (almost same source code) was built with Watcom tools. What you see above is a new suite of tools.

If you expect these programs to run on OS/2 - even if only to prove that (some) OS/2 programs run on your OS - then fix your tools to create bona-fide OS/2 executables. It's not optional.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 07, 2024, 11:46:33 pm
Quote
I'm surprised that the program you wrote about originally ever ran if it had this kind of layout.
The original program (almost same source code) was built with Watcom tools. What you see above is a new suite of tools.

If you expect these programs to run on OS/2 - even if only to prove that (some) OS/2 programs run on your OS - then fix your tools to create bona-fide OS/2 executables. It's not optional.

Using what definition of "bona-fide"? It wasn't my design choice, but having different addresses doesn't change the status of being "some OS/2 executables" as far as I can see. Anyway, I received this reply overnight:


LX in PDLD has the same base address and section alignment as PE/COFF which should be fine for 32-bit (I do not plan to support 16-bit) but if needed, it can be changed using "--image-base" (just like for PE/COFF).

If it turns out that OS/2 cannot handle the PE/COFF defaults, I can add separate LX defaults.


I personally don't see a problem with that attitude. I'm trying to get working executables to prove a concept, not win Miss America.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 08:39:50 am
But I have already been sent a fix (from Slovakia - noting that today I did my own debugging to a point where I asked him to explain a result) that should hopefully fix the issue I reported in this thread, and I'll commit (and then test) that in 8 hours or whatever depending on if Arca Noae gives me a reason to pause longer. I'm keen to get on with the development, but I'm also keen to bulletproof ArcaOS. I don't like bugs in anything.

After fixing unrelated (to pdld) bugs, the pdld fix worked, and PDOS/386 (available at http://pdos.org) is able to produce OS/2 executables (cd \devel\pdos\pdpclib then pdmake -f makefile.sos then pdptest abc def) that appear to work. However, the executable is still crashing ArcaOS, likely because of the default virtual addresses, and I currently can't try the suggested workaround because of a different bug in pdld which I have reported and is likely to be fixed in the coming hours (likely under 16 hours, likely much less).

After that is working I will construct an OS/2 makefile for microemacs 3.6 and try that.

And then I have no idea what I will do. A bit like people don't do anything in particular when they reach the top of Mt Everest (after all that effort). There are still gaps in 16-bit and 8-bit that I would like to fill in, but those are just example activities. There is nothing pressing.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Flashback on March 08, 2024, 10:27:28 am
Quote
... is able to produce OS/2 executables (cd \devel\pdos\pdpclib then pdmake -f makefile.sos then pdptest abc def) that appear to work. However, the executable is still crashing ArcaOS ...
That somehow contradicts itself. If it was working, it would not crash AcraOS. BTW, The fact that any version of OS/2 can be crashed by invalid EXE headers is known for many years (Someone remembers this 'Smallest Hello World Program' contest?) and it is very unlikely that this is going change.

BTW, there are more 'fishy' things than Rich already pointed out. The DOS stub is complete bogus (Load image size, memory requirement, initial SS:SP, CS:IP). Better remove it completely instead of using invalid values.

In the LX header:
Also strange:

Code: [Select]
Turbo Dump  Version 4.1 Copyright (c) 1988, 1994 Borland International
                Display of File F:\XX\PDPTEST.EXE

Old Executable Header

DOS File Size                                       71ADh  ( 29101. )
Load Image Size                                   FFFFFFC0h  (4294967232. )
Relocation Table entry count                        0000h  (     0. )
Relocation Table address                            0040h  (    64. )
Size of header record      (in paragraphs)          0004h  (     4. )
Minimum Memory Requirement (in paragraphs)          0000h  (     0. )
Maximum Memory Requirement (in paragraphs)          0000h  (     0. )
File load checksum                                  0000h  (     0. )
Overlay Number                                      0000h  (     0. )

Initial Stack Segment  (SS:SP)   0000:0000
Program Entry Point    (CS:IP)   0000:0000


Linear Executable (LX) File

Header base: 00000040

Byte Order                                        Little endian
Word Order                                        Little endian
Format level                                      00000000
CPU type                                          80386
Operating system                                  OS/2
Module version                                    00000000
Module flags                                      00000010
         Instance init                 : No
         Internal fixups removed       : Yes
         External fixups removed       : No
         API                           : Unknown
         Errors in module              : No
         Module type                   : EXE
         Instance termination          : No
Page count                                        0000000Eh
Starting EIP object number                        00000001h
Starting EIP                                      00000000h
Starting ESP object number                        00000004h
Starting ESP                                      00008000h
Page size                                         00001000h
Page offset shift                                 00000000h
Fixup size                                        00000960h
Page checksum                                     00000000h
Loader section size                               00000000h
Loader section checksum                           00000000h
Object table offset                               00006795h
Object count                                      00000003h
Object page map table offset                      000067DDh
Object iterate data map offset                    00000040h
Resource table offset                             00000040h
Resource count                                    00000000h
Resident names table offset                       00000040h
Entry table offset                                00000040h
Module directives offset                          00000040h
Module directives count                           00000000h
Fixup page table offset                           0000684Dh
Fixup record table offset                         00006889h
Import module table offset                        000071A4h
Import module entry count                         00000002h
Import procedure names table offset               000071ADh
Per-page checksum table offset                    00000040h
Data pages offset                                 000000F0h
Preload page count                                00000000h
Non-resident names table offset                   00000000h
Non-resident names table length                   00000000h
Non-resident names table checksum                 00000000h
Auto DS object                                    00000000h
Debug info offset                                 00000040h
Debug info length                                 00000000h
Instance preload pages                            00000000h
Instance demand pages                             00000000h
Heap size                                         00000000h


Object Table                          3 Entries (00000003) File Base:06795h

Object 1
  Virtual size  : 00005FCDh  Relocation Base Address: 00400000h
  Page map index: 00000001h  Page map entries       : 00000006h
  Object flags  : 00002005h ( READABLE EXECUTABLE BIG )
    ====
    Page: 01  Offset: 000000F0  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 02  Offset: 000010F0  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 03  Offset: 000020F0  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 04  Offset: 000030F0  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 05  Offset: 000040F0  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 06  Offset: 000050F0  Size: 0FCD  Flags 0000 (PHYSICAL)

Object 2
  Virtual size  : 000006D8h  Relocation Base Address: 00406000h
  Page map index: 00000007h  Page map entries       : 00000001h
  Object flags  : 00002003h ( READABLE WRITEABLE BIG )
    ====
    Page: 07  Offset: 000060BD  Size: 06D8  Flags 0000 (PHYSICAL)

Object 3
  Virtual size  : 000067B0h  Relocation Base Address: 00407000h
  Page map index: 00000008h  Page map entries       : 00000007h
  Object flags  : 00002003h ( READABLE WRITEABLE BIG )
    ====
    Page: 08  Offset: 00006795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 09  Offset: 00007795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 0A  Offset: 00008795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 0B  Offset: 00009795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 0C  Offset: 0000A795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 0D  Offset: 0000B795  Size: 1000  Flags 0000 (PHYSICAL)
    Page: 0E  Offset: 0000C795  Size: 07B0  Flags 0000 (PHYSICAL)


    No Resident names table present

    No Non-resident names table present


Entry Table                           1 Entries (00000001) File Base:040h

Unknown entry bundle type!!!


ERROR: Unable to create procedure names table

Fixup Table                           1 Entries (00000001) File Base:06889h

Object 1
01284  01:000A0       offset32
01295  01:000B3       offset32
0129C  01:000B5       offset32
012AF  01:00274       offset32
012B4  01:000B7       offset32
012C0  01:000CF       offset32
012DB  01:000E3       offset32
012FB  01:000ED       offset32
01316  01:00101       offset32
01338  01:0010B       offset32
01358  01:0011F       offset32
01365  01:00132       offset32
0138D  01:0013D       offset32
013CD  01:0014D       offset32
01404  01:0014D       offset32
01437  01:0014F       offset32
0143E  01:00154       offset32
01447  01:00160       offset32
01464  01:0014F       offset32
0146B  01:00154       offset32
01474  01:0017F       offset32
0148B  03:00000       offset32
014A3  03:00000       offset32
014CE  01:00194       offset32
014E8  01:0019E       offset32
0150E  01:001C0       offset32
01538  01:001E0       offset32
0157E  01:001FF       offset32
01587  01:00202       offset32
01591  01:00220       offset32
0159D  01:00254       offset32
015AC  02:00000       offset32
015B8  02:00004       offset32
015C4  02:00008       offset32
0164A  03:01DA4       offset32
01652  03:01DB4       offset32
01657  02:0000C       offset32
0165F  03:01D94       offset32
0166E  03:01C24       offset32
0167D  03:01D94       offset32
0168A  02:0000C       offset32
01694  03:01C24       offset32
0169D  03:01C24       offset32
016A6  02:0000C       offset32
016BB  03:01D84       offset32
016C0  03:01D94       offset32
016CA  02:0000C       offset32
016D7  03:01C24       offset32
016E4  03:01D94       offset32
016F2  03:01D94       offset32
01717  03:01C24       offset32
01730  03:01D94       offset32
01741  03:01DB4       offset32
01746  03:01C24       offset32
01759  03:01D94       offset32
01766  03:01C24       offset32
0177C  03:01D84       offset32
01783  03:01800       offset32
0179A  03:01C24       offset32
017A8  03:01C24       offset32
017B8  03:01D94       offset32
017DD  03:01C24       offset32
017EB  03:01C24       offset32
01819  03:01C24       offset32
0183B  02:0003C       offset32
01881  03:01DC4       offset32
018C8  03:01DC4       offset32
0191E  03:01DC4       offset32
0193E  03:01800       offset32
0195B  03:01D84       offset32
01963  03:01D94       offset32
019A9  01:0096D       offset32
019AF  03:01DB4       offset32
019C1  03:01DC4       offset32
019CB  03:01DC4       offset32
019E7  03:01C24       offset32
019F5  03:01C24       offset32
01A08  01:00971       offset32
01A0E  03:01DB4       offset32
01A22  01:00975       offset32
01A28  03:01DB4       offset32
01A3A  03:01DC4       offset32
01A48  01:00979       offset32
01A4E  03:01DB4       offset32
01A62  01:0097D       offset32
01A68  03:01DB4       offset32
01A7A  03:01DC4       offset32
01A8B  01:00981       offset32
01A91  03:01DB4       offset32
01AA5  01:00985       offset32
01AAB  03:01DB4       offset32
01ABD  03:01DC4       offset32
01ACE  01:00988       offset32
01AD4  03:01DB4       offset32
01AE6  03:01DC4       offset32
01AF7  01:0098B       offset32
01AFD  03:01DB4       offset32
01B0F  03:01DC4       offset32
01B20  01:0098E       offset32
01B26  03:01DB4       offset32
01B38  03:01DC4       offset32
01B49  01:00991       offset32
01B4F  03:01DB4       offset32
01B61  03:01DC4       offset32
01B72  01:00994       offset32
01B78  03:01DB4       offset32
01B8A  03:01DC4       offset32
01B9B  01:00997       offset32
01BA1  03:01DB4       offset32
01BB3  03:01DC4       offset32
01BC4  01:00999       offset32
01BCA  03:01DB4       offset32
01BDC  03:01DC4       offset32
01BED  01:0099B       offset32
01BF3  03:01DB4       offset32
01C05  03:01DC4       offset32
01C14  03:01D94       offset32
01C2F  03:01DC4       offset32
01CD2  03:01DA4       offset32
01CF5  03:01C24       offset32
01CFB  03:01DA4       offset32
01D00  DOSCALLS.273   self-relative32
01D1A  03:01D94       offset32
01DA1  DOSCALLS.257   self-relative32
01DE7  02:0000C       offset32
01E00  03:01800       offset32
01E16  01:00D6A       offset32
01E47  DOSCALLS.281   self-relative32
01E9E  02:00010       offset32
01EA9  03:01BF4       offset32
01EB4  02:00010       offset32
01EBC  03:01BF5       offset32
01EC1  03:01BF4       offset32
01EC6  02:00010       offset32
01ED0  02:00010       offset32
01F29  DOSCALLS.284   self-relative32
01F6C  02:00010       offset32
01F77  03:01BF4       offset32
01F8E  02:00010       offset32
01F99  03:01BF4       offset32
01FA3  02:00010       offset32
01FAE  03:01BF4       offset32
01FB8  02:00010       offset32
01FC3  03:01BF4       offset32
01FFA  02:00010       offset32
--
02004  03:01BF4       offset32
02400  DOSCALLS.282   self-relative32
0296E  01:01898       offset32
02B18  01:0189F       offset32
02CD8  01:01CDC       offset32
02CDC  01:0264A       offset32
02CE0  01:02698       offset32
02CE4  01:02698       offset32
02CE8  01:02656       offset32
02CEC  01:02698       offset32
02CF0  01:02698       offset32
02CF4  01:02698       offset32
02CF8  01:02698       offset32
02CFC  01:02698       offset32
02D00  01:02698       offset32
02D04  01:02662       offset32
02D08  01:0268A       offset32
02D0C  01:02698       offset32
02D10  01:01D20       offset32
02D14  01:02698       offset32
02D18  01:02698       offset32
02D1C  01:026A2       offset32
02D47  02:006C4       offset32
02DC5  01:01C5E       offset32
02EEB  02:006CC       offset32
--
0327E  01:01898       offset32
03770  DOSCALLS.259   self-relative32
037A7  DOSCALLS.271   self-relative32
03C11  DOSCALLS.256   self-relative32
03D9C  01:02D46       offset32
03DAB  01:02D5D       offset32
03DB9  01:02D74       offset32
03EC8  03:01C14       offset32
03EE2  DOSCALLS.284   self-relative32
03EED  DOSCALLS.257   self-relative32
03F18  02:0001C       offset32
03F1E  02:00020       offset32
03F25  02:00014       offset32
03F2C  02:00018       offset32
03F39  01:02DC7       offset32
03F3E  DOSCALLS.273   self-relative32
03F5D  03:01C14       offset32
03F7F  DOSCALLS.284   self-relative32
03FAC  DOSCALLS.284   self-relative32
03FF1  02:0000C       offset32
--
04008  03:01C24       offset32
04012  03:01D94       offset32
04033  02:0000C       offset32
0404A  03:01800       offset32
0405B  03:01D94       offset32
040BE  02:0002B       offset32
040C5  02:00024       offset32
040CF  02:00024       offset32
040E7  01:00979       offset32
040EC  01:00D6A       offset32
04234  02:006C4       offset32
0437F  02:006C4       offset32
043B1  02:006C4       offset32
0448A  01:03168       offset32
04542  01:03168       offset32
0456B  01:03168       offset32
04771  02:006C4       offset32
047BA  02:006C4       offset32
04863  02:006CC       offset32
04C09  02:006C4       offset32
04C29  02:006C4       offset32
04D11  02:006C4       offset32
04D5B  02:006C4       offset32
04FD6  01:03F78       offset32
--
0511A  01:03F6B       offset32
05151  01:03F78       offset32
0529C  01:03F6D       offset32
05401  01:03F78       offset32
05478  01:03F6B       offset32
05549  01:03F78       offset32
055C4  01:03F6F       offset32
05605  01:03F80       offset32
05612  01:03F78       offset32
05642  01:03F78       offset32
0566D  01:03F88       offset32
0567A  01:03F78       offset32
056C9  01:03F78       offset32
056E5  01:03F80       offset32
056F1  01:03F78       offset32
05791  01:03F78       offset32
05BBC  02:00034       offset32
05BC2  02:00034       offset32
05C00  02:00034       offset32
05C35  02:00034       offset32
05C4D  02:00034       offset32
05CAF  01:04C75       offset32
05CB9  01:04C8C       offset32
05D5D  DOSCALLS.299   self-relative32
05E3E  DOSCALLS.304   self-relative32
--
Object 2
00003  02:00038       offset32
0000D  02:00038       offset32
0002D  02:00038       offset32
00077  02:006C4       offset32
000C0  01:05060       offset32
0013C  01:05060       offset32
00158  01:05060       offset32
0019E  01:05058       offset32
001AE  01:05060       offset32
00202  01:05058       offset32
00254  02:006C4       offset32
002B4  02:006CC       offset32
00343  02:006C4       offset32
004EA  03:01DE0       offset32
0050A  03:01DE0       offset32
00522  DOSCALLS.227   self-relative32
0055F  DOSCALLS.283   self-relative32
005DA  02:00050       offset32
005E2  03:01F38       offset32
005F5  02:0003C       offset32
0061C  02:0003C       offset32
00630  03:01800       offset32
00657  DOSCALLS.382   self-relative32
0066F  02:0003C       offset32
00685  03:01E68       offset32
006C0  03:01E6C       offset32
006D0  02:00054       offset32
006DC  03:01F38       offset32
006F1  02:00050       offset32
006F6  02:00050       offset32
006FE  03:01F38       offset32
0070C  02:0003C       offset32
00717  02:0003C       offset32
00737  03:01E68       offset32
0074C  03:01F38       offset32
00760  03:01E68       offset32
00769  02:00058       offset32
00795  03:01E68       offset32
007C7  03:01E68       offset32
007FF  01:055CC       offset32
00812  DOSCALLS.312   self-relative32
0081E  01:055CD       offset32
00831  03:01E68       offset32
0085B  DOSCALLS.382   self-relative32
008D3  03:01F78       offset32
00A15  03:03788       offset32
00B4C  03:04F98       offset32
00C57  02:0003C       offset32
00C69  02:0003C       offset32
00C77  03:01F38       offset32
00C7D  02:00050       offset32
00CB7  03:01800       offset32
00CC0  02:0003C       offset32
00D3E  02:00044       offset32
00D4C  02:00040       offset32
00D56  02:00044       offset32
00D5F  02:00040       offset32
00D73  02:00044       offset32
00D79  01:05D26       offset32
00D91  01:05D2A       offset32
00DB3  01:05D30       offset32
00DC8  02:0005C       offset32
00DDC  02:00060       offset32
00DF1  02:00060       offset32
00E08  02:00060       offset32
00E0C  01:05DFC       offset32
00E35  02:006C4       offset32
00E4D  02:006C4       offset32
00E65  02:006C4       offset32
00E7D  02:006C4       offset32
00E95  02:006C4       offset32
00EAD  02:006C4       offset32
00EC5  02:006C4       offset32
00EDD  02:006C4       offset32
00EF9  02:006C4       offset32
00F15  02:006C4       offset32
00F31  02:006C4       offset32
00F4C  02:006C8       offset32
00F60  02:006CC       offset32
00FC9  DOSCALLS.234   self-relative32
01000  03:01C34       offset32
00004  03:01CA0       offset32
00008  03:01D0C       offset32
00058  01:00274       offset32
00060  01:05DFC       offset32
00064  01:05DFC       offset32
00068  01:05DFC       offset32
0006C  01:05DFC       offset32
00070  01:05DFC       offset32
00074  01:05DFC       offset32
00078  01:05DFC       offset32
006C4  02:00082       offset32
006C8  02:002A2       offset32
006CC  02:004C2       offset32
--
Object 3
--
ERROR: Attempt to free import module namew when not allocated




What also appears strange is the large number of 'offset32' fixups. Maybe I'm wrong, but IMHO these could/should be resolved by the linker so that they won't end up in the executable image at all.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 11:55:05 am
Quote
... is able to produce OS/2 executables (cd \devel\pdos\pdpclib then pdmake -f makefile.sos then pdptest abc def) that appear to work. However, the executable is still crashing ArcaOS ...
That somehow contradicts itself. If it was working, it would not crash AcraOS.
It's working as in -  you can run it under PDOS/386. PDOS/386 is able to run (certain) OS/2 executables created by the Watcom toolchain (and those executables run under ArcaOS too). And PDOS/386 is *also* able to run LX executables created by pdld. It is only *those* that are currently crashing ArcaOS.

Quote
BTW, The fact that any version of OS/2 can be crashed by invalid EXE headers is known for many years (Someone remembers this 'Smallest Hello World Program' contest?) and it is very unlikely that this is going change.
Thanks for that info.

Quote
BTW, there are more 'fishy' things than Rich already pointed out. The DOS stub is complete bogus (Load image size, memory requirement, initial SS:SP, CS:IP). Better remove it completely instead of using invalid values.
I'll take a look at that, thanks, but note that there is no real stub in the above makefile.sos.

And thanks for the detailed analysis of the flaws in the LX portion. I'll pass that on and see what happens!

Quote
What also appears strange is the large number of 'offset32' fixups. Maybe I'm wrong, but IMHO these could/should be resolved by the linker so that they won't end up in the executable image at all.
Note that PDOS/386 requires fixups, even though OS/2 doesn't. And fixups are allowed in the executable format, so that alone doesn't make it invalid - just unusual.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Lars on March 08, 2024, 01:49:06 pm
As to fixups: I would think that if you specify the /BASE: keyword to the IBM OS/2 linker that then, fixups can be avoided.
I would also think that the IBM OS/2 linker has the default behaviour that when it creates an EXE, it will always assume a base of 0x10000 for the first memory object (and a fixed scheme of additional bases for the following memory objects) and will then be able to avoid fixups.

If you create a DLL, you would typically not define a base when linking because that is not desirable in general and in that case, you cannot avoid the fixups (but that is what fixups are for: to allow code/data to be relocated in memory).

When I say "IBM OS/2 linker" I assume that the Watcom linker and also the Borland linker would behave the same.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 03:49:37 pm
As to fixups: I would think that if you specify the /BASE: keyword to the IBM OS/2 linker that then, fixups can be avoided.
PDOS/386 cannot load an executable at an arbitrary user-specified virtual address. It doesn't use virtual memory. It is inspired by MSDOS. Fixups are mandatory. As they are for MSDOS in large code memory model. Quibbling aside.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 09:42:52 pm
BTW, there are more 'fishy' things than Rich already pointed out. The DOS stub is complete bogus (Load image size, memory requirement, initial SS:SP, CS:IP). Better remove it completely instead of using invalid values.

In the LX header:

I have received a new version of pdld and produced a new pdptest.exe that should have addressed all issues except:

"The Auto DS object is only for 16-bit compatibility and is not used by 32-bit modules according to the LX specification, so I do not think it has to be set."


And ArcaOS no longer crashes.

However, even with the addresses set normally:

D:\devel\pdos\pdpclib>cvs diff
cvs diff: Diffing .
Index: makefile.sos
===================================================================
RCS file: \cvsroot/pdos/pdpclib/makefile.sos,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 makefile.sos
10,11c10,11
< #  wasm -zcm -q -DOS220 ..\src\needpdos.asm
< #  wlink File needpdos.obj Name needpdos.exe Form dos Option quiet,dosseg
---
>   wasm -zcm -q -DOS220 ..\src\needpdos.asm
>   wlink File needpdos.obj Name needpdos.exe Form dos Option quiet,dosseg
23c23
<   pdld -s --oformat lx -o pdptest.exe os2strt.obj pdptest.obj pdpos2.lib os2.lib
---
>   pdld --stub=needpdos.exe --image-base 0x10000 --section-alignment 0x10000 -Map map.txt -s --o
format lx -o pdptest.exe os2strt.obj pdptest.obj pdpos2.lib os2.lib

D:\devel\pdos\pdpclib>

0001 00010000 00005fad 00000001 00000006 EXECUTABLE, READABLE, 32-bit
0002 00020000 000006d8 00000007 00000001 READABLE, WRITEABLE, 32-bit
0003 00030000 000067b0 00000007 00000000 READABLE, WRITEABLE, 32-bit
0004 00040000 00008000 00000008 00000000 READABLE, WRITEABLE, 32-bit


I get:

[Z:\]pdptest
SYS0188: The operating system cannot run Z:\PDPTEST.EXE.

[Z:\]


Are you (or anyone else) able to see what still remains?

I'll produce and upload a new pdos.zip in the coming hours with the latest pdld.exe, but I don't think it is useful to anyone until it actually works (on ArcaOS - it still works on PDOS/386).

Thanks. Paul.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Martin Iturbide on March 08, 2024, 09:59:03 pm
Hello

In DOS Window Session (ArcaOS 5.1.0) gives me:
Quote
C:\DESKTOP>pdptest
This program needs OS/2 2.0 or equivalent

Under OS/2 command line:
Quote
[C:\DESKTOP]pdptest
SYS0188: The operating system cannot run C:\DESKTOP\PDPTEST.EXE.

No OS hangs here.
Regards
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 10:05:44 pm
No OS hangs here.
Sure. I uploaded the executable than hung ArcaOS to the ArcaOS site, not here. I can upload it here if someone is interested, but I've moved on, and apparently it is nothing new.

I've moved on and now need to know why (non-crashing) OS/2 doesn't like the latest executable.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 08, 2024, 10:50:19 pm
Try help 188,
Code: [Select]
[H:\tmp]pdptest
SYS0188: The operating system cannot run H:\TMP\PDPTEST.EXE.

[H:\tmp]help 188

SYS0188: The operating system cannot run ***.

EXPLANATION: The application program does not have a correct
END <label> directive.

ACTION: Contact the supplier of the application.

Not sure what an END directive is.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 11:19:12 pm
Try help 188,
Thanks! Never occurred to me that there would be help for this error message.

Quote
EXPLANATION: The application program does not have a correct
END <label> directive.

Not sure what an END directive is.

I believe I know what that is. It is an assembler directive to specify the entry point.

I have just updated my assembler code to make that better:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/os2strt.asm

And the end statement:

end __top

is there, and on pdld I added -e ___top to ensure that was the entry point.

I don't think that OS/2 can know things at this level. I suspect the error message should really be "entry point invalid".

Which is this:

Initial CS:EIP:                 object 7 offset 00000000

And I didn't see an object 7, so let me see if I can confirm that this is the problem.

Thanks. Paul.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 08, 2024, 11:43:50 pm
Initial CS:EIP:                 object 7 offset 00000000

And I didn't see an object 7, so let me see if I can confirm that this is the problem.

I modified pdld to always put object 1 (as a kludge), and now my program seems to actually be run! It crashes though:

[Z:\]pdptest
SYS1808:
The process has stopped.  The software diagnostic
code (exception code) is  0005.

[Z:\]

Not sure how to debug that at the assembler level.

But the problem is unlikely to be in the code anyway. One of those relocations may be wrong instead, and that is zapping the code.

I changed my application to just loop:


public __top
__top:


; We don't use the registers or stack at entry

public __intstart
__intstart proc
        nop
        nop
        nop
        nop
ploop:  jmp ploop
        mov eax, 0
        ret
        push eax


And you can see those NOPs in the executable:

D:\devel\pdos\pdpclib>hexdump pdptest.exe 0 400
000000  4D5A6000 01000000 04004000 FFFF0400  MZ`.......@.....
000010  00040000 00000000 40000000 00000000  ........@.......
000020  00000000 00000000 00000000 00000000  ................
000030  00000000 00000000 00000000 80000000  ................
000040  0E1FB409 BA1400CD 21B001B4 4CCD21EB  ........!...L.!.
000050  FE000000 54686973 2070726F 6772616D  ....This program
000060  206E6565 6473204F 532F3220 322E3020   needs OS/2 2.0
000070  6F722065 71756976 616C656E 740D0A24  or equivalent..$
000080  4C580000 00000000 02000100 00000000  LX..............
000090  00020000 07000000 01000000 00000000  ................
0000A0  04000000 F07F0000 00100000 00000000  ................
0000B0  44090000 00000000 A8000000 00000000  D...............
0000C0  35670000 04000000 95670000 00000000  5g.......g......
0000D0  00000000 00000000 CD670000 DB670000  .........g...g..
0000E0  00000000 00000000 DD670000 FD670000  .........g...g..
0000F0  18710000 01000000 21710000 00000000  .q......!q......
000100  30010000 00000000 00000000 00000000  0...............
000110  00000000 00000000 00000000 00000000  ................
000120  00000000 00000000 00000000 00000000  ................
000130  90909090 EBFEB800 000000C3 50E89E55  ............P..U


But it doesn't loop, so it is unlikely to be reaching this (intact) code.

I'm attaching the latest executable.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 12:10:06 am
I am getting some diagnostics in populog.os2 (thanks to Dave on the Usenet group for the pointer some days ago).

I suspected that the EIP wasn't being set correctly, so I tried setting it to negative 0x10000 in pdld:

D:\devel\pdos\pdld\src>cvs diff
cvs diff: Diffing .
Index: lx.c
===================================================================
RCS file: \cvsroot/pdos/pdld/src/lx.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 lx.c
392,393c392,393
<                 lx_hdr.EipObjectIndex = object_page_table_entries + 1;
<                 lx_hdr.Eip = ld_state->entry_point - section->rva;
---
>                 lx_hdr.EipObjectIndex = 1;
>                 lx_hdr.Eip = -0x10000; /* ld_state->entry_point - section->rva; */
cvs diff: Diffing bytearray
cvs diff: Diffing hashtab

D:\devel\pdos\pdld\src>


in order to get it to resolve to 0 instead of 0x10000 or 0x20000

but it's still not hitting my loop ...

03-09-2024  07:04:00  SYS3175  PID 005d  TID 0001  Slot 009b
Z:\PDPTEST.EXE
c0000005
00000000
P1=00000001  P2=00000000  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=00000000  ECX=00000000  EDX=00000000
ESI=00000000  EDI=00000000 
DS=0053  DSACC=d0f3  DSLIM=5fffffff 
ES=0053  ESACC=d0f3  ESLIM=5fffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00000000  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:00047fdc  SSACC=d0f3  SSLIM=5fffffff
EBP=00000000  FLG=00010202

Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 11:03:43 am
I received this fix:

https://sourceforge.net/p/pdos/gitcode/ci/2f1b13eae9c4da1bbb556a4bf64c644ccf01f3b6/

and it now works!

Turns out the virtual addresses weren't important, and nor was the deficient MZ stub.

But I'll provide a proper stub anyway.

Thanks everyone for your assistance!

I'll do a new build soon.

And prove microemacs too.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 02:49:27 pm
microemacs is working under OS/2 - see attached.

However, the executable isn't running properly under PDOS/386, but that's a problem with exeload.c in PDOS/386 not initializing BSS properly.

That will be dealt with in the coming hours hopefully.

There is a new pdos.zip at pdos.org which has a makefile.sos that produces executables that work on both OS/2 and PDOS/386 - but it is random whether you hit a BSS issue.


EDIT: the editor uemacs.exe needs to be run in a fullscreen window, even though it is marked as pmcompatible (we don't yet have a link option to change that).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Flashback on March 09, 2024, 03:31:29 pm
The resident name table entry (i.e. module name) is still incorrect. Please refer to:

http://www.edm2.com/index.php/LX_-_Linear_eXecutable_Module_Format_Description#Resident_or_Non-resident_Name_Table_Entry

Also, the file extension (i.e. '.exe') should be removed.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 09, 2024, 04:07:35 pm
For now perhaps best to use exehdr to mark it to force full screen mode, especially if it still breaks the keyboard if run in a window.
Code: [Select]
exehdr /PMTYPE:NOTWINDOWCOMPAT uemacs.exeSeems to run fine here, though I don't know emacs enough to really test. Good work.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Martin Iturbide on March 09, 2024, 04:38:51 pm
Hi
EDIT: the editor uemacs.exe needs to be run in a fullscreen window, even though it is marked as pmcompatible (we don't yet have a link option to change that).

Here (ArcaOS 5.1.0) it also runs in OS/2 cmd windowed mode. No problems with the keyboard there.

But when I run it in full screen, I made an Alt+Enter to kill the session, since I don't know how to exist uemacs, and after I killed the session I lost they keyboard input in the OS.

Regards
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 05:39:40 pm
Here (ArcaOS 5.1.0) it also runs in OS/2 cmd windowed mode. No problems with the keyboard there.

That's the irony of it all. It works fine. But watch what happens when you exit. Try doing "dir".

To exit, do ctrl-x, ctrl-c

If you are in the middle of a command and you've stuffed something up, ctrl-g to cancel

ctrl-x, ctrl-s saves
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 05:41:52 pm
For now perhaps best to use exehdr to mark it to force full screen mode, especially if it still breaks the keyboard if run in a window.
Code: [Select]
exehdr /PMTYPE:NOTWINDOWCOMPAT uemacs.exe
Thanks for the command. Note that I'm building on Windows 2000, so I don't have exehdr available to do that automatically, and pdld is likely to be changed before I start distributing LX executables for real.

Quote
Seems to run fine here, though I don't know emacs enough to really test. Good work.
Thanks!
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 11:01:42 pm
The resident name table entry (i.e. module name) is still incorrect. Please refer to:

http://www.edm2.com/index.php/LX_-_Linear_eXecutable_Module_Format_Description#Resident_or_Non-resident_Name_Table_Entry

Also, the file extension (i.e. '.exe') should be removed.

The attached executable should fix that problem. Please let me know if you see anything else that is technically invalid.

Note that I still can't run this executable under PDOS/386, and I'm still debugging why. First problem was BSS wasn't initialized. But then there was a second problem. I suspect the fixups are slightly incorrect, so it will be a hairy problem to solve (adding printfs to uemacs changes the behavior).
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Martin Iturbide on March 09, 2024, 11:26:40 pm
The attached executable should fix that problem. Please let me know if you see anything else that is technically invalid.
Hello

After exiting uemacs.exe (run in windowed mode) it keeps breaking the keyboard on the rest of the OS.

Regards
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 09, 2024, 11:42:25 pm
The attached executable should fix that problem. Please let me know if you see anything else that is technically invalid.
Hello

After exiting uemacs.exe (run in windowed mode) it keeps breaking the keyboard on the rest of the OS.

Regards

Oh, sure - I already know that one - that's what the thread was originally about, and hasn't really been resolved other than to always run in fullscreen mode.

So my question can be refined as - this is a fullscreen application. Is there anything technically invalid (headers, fixups, whatever) about this fullscreen application other than the fact that it is currently marked as windowcompat and exehdr needs to be run to mark it as fullscreen?
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 10, 2024, 01:02:15 am
Running lxlite on the exe gives,
Code: [Select]
H:\tmp>lxlite uemacs.exe
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software       ├    All rights   ┤
├ Copyright 2001,03 by Max Alekseyev          ├     reserved    ┤
├ Copyright 2008-10 by OS/4 team              ├                 ┤
├ Copyright 2011    by Steven H. Levine       ├                 ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ The file uemacs.exe contains 1 bytes out of module structure
├                  uemacs.exe initial: 72863 final: 42821 gain: 41.3%
├┤Total gain: 30042 bytes

After lxliting with the defaults, the exe will only run on Warp v3 or later. The IBM linkers can also pack the data, code etc.
Hmm, your exe won't run after lxliting,
Code: [Select]
03-09-2024  15:59:13  SYS3175  PID 0085  TID 0001  Slot 00b7
H:\TMP\UEMACS.EXE
c0000005
0001d6a1
P1=00000001  P2=0040fd6c  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000000  EBX=00000000  ECX=00000000  EDX=00000000
ESI=00000000  EDI=00000000
DS=0053  DSACC=d0f3  DSLIM=bfffffff
ES=0053  ESACC=d0f3  ESLIM=bfffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:0001d6a1  CSACC=d0df  CSLIM=bfffffff
SS:ESP=0053:00047f58  SSACC=d0f3  SSLIM=bfffffff
EBP=00047fd0  FLG=00010212

UEMACS.EXE 0001:0000d6a1

If you can find an old enough exehdr, perhaps the OS/2 v1.3 toolkit, it should run under Win2k as Win2k does support 16 bit OS/2 code
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 10, 2024, 02:46:39 am
Running lxlite on the exe gives,
Code: [Select]
H:\tmp>lxlite uemacs.exe
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software       ├    All rights   ┤
├ Copyright 2001,03 by Max Alekseyev          ├     reserved    ┤
├ Copyright 2008-10 by OS/4 team              ├                 ┤
├ Copyright 2011    by Steven H. Levine       ├                 ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ The file uemacs.exe contains 1 bytes out of module structure
├                  uemacs.exe initial: 72863 final: 42821 gain: 41.3%
├┤Total gain: 30042 bytes
Am I interpreting that correctly that there is 1 rogue byte somewhere?

Quote
Hmm, your exe won't run after lxliting,
Maybe it doesn't like the non-standard virtual addresses. I am attaching one with the normal 0x10000 - can you see if that is ok?

Quote
If you can find an old enough exehdr, perhaps the OS/2 v1.3 toolkit, it should run under Win2k as Win2k does support 16 bit OS/2 code
That would only operate on 16-bit NE executables, not 32-bit LX executables introduced with OS/2 2.0, right?
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 10, 2024, 02:53:05 am
PDOS/386 now runs the microemacs OS/2 executable. The problem was that I was translating DosWrite into fwrite but had failed to do a fflush. Plus the BSS clearing code wasn't doing a sufficient job. New version of PDOS available at pdos.org
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Martin Iturbide on March 10, 2024, 03:23:58 am
Hello.

I may be talking nonsense here, since I'm not a developer, but maybe in general terms these projects can help for some code inspiration for your PDOS efforts with OS/2:
- https://github.com/OS2World/LINUX-SYSTEM-OS2Linux
- https://github.com/icculus/2ine
- https://github.com/osfree-project/osfree/tree/ac53235a7bc2a2f91de23e9bf7fdaa9c2c3dc976/OS2/CPI/doscalls

Regards
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 10, 2024, 04:11:49 am
I may be talking nonsense here, since I'm not a developer, but maybe in general terms these projects can help for some code inspiration for your PDOS efforts with OS/2:
My 32-bit OS/2 work is nearly done. ie I support C90 and ANSI X3.64 sufficiently well to use native OS/2 tools under PDOS/386 to build a better version of OS/2 or anything else that someone may wish to do. I don't personally wish to write millions of lines of code to replicate OS/2 or Windows or whatever. I just want the basic functionality to exist. Perhaps different universities would like to build their own OS, and may choose to clone OS/2, and they can start from a public domain source base.

After some more technical cleanup of the 32-bit OS/2, I'm probably more interested in replicating (to the same limited extent) 16-bit OS/2, for PM32 with D-bit set to 16-bit, PM16 and RM16 - with a single NE binary app able to run on all 3 environments and without separate code paths. I have a Book 8088 to try it on.

BTW, I just checked, and PDOS/386 is about 330k (for everything required to bring up a prompt). ie it would fit on a 360k floppy.

I'm also interested in a public domain C compiler - which may involve bringing SubC up to C90 standard - or at least, close enough to compile the PDOS source. I don't currently have the skills to do that, so would need to learn that. That's the only thing still missing from the essential PDOS/386 suite - I use (a fork of) the copyrighted gcc 3.2.3 because we don't have a 32-bit public domain C compiler that can handle C90 syntax.

There is also an interesting "Sector C" C compiler which inspired me to write "Multi-sector C" using the same algorithm.

Or I may switch back to the mainframe, with z/PDOS.

A lot of the time direction is governed by others who are interested in public domain code and contributing something. So supporting others in their own goals is very productive.

Anyway, we'll see what happens. :-)
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 10, 2024, 04:15:27 am
Running lxlite on the exe gives,
Code: [Select]
H:\tmp>lxlite uemacs.exe
┌[ lxLite ]───────────────────────────────────┬[ Version 1.3.9 ]┐
├ Copyright 1996,97 by FRIENDS software       ├    All rights   ┤
├ Copyright 2001,03 by Max Alekseyev          ├     reserved    ┤
├ Copyright 2008-10 by OS/4 team              ├                 ┤
├ Copyright 2011    by Steven H. Levine       ├                 ┤
├ Copyright 2017-23 by bww bitwise works GmbH └─────────────────┘
├ The file uemacs.exe contains 1 bytes out of module structure
├                  uemacs.exe initial: 72863 final: 42821 gain: 41.3%
├┤Total gain: 30042 bytes
Am I interpreting that correctly that there is 1 rogue byte somewhere?

That's my interpretation.

Quote

Quote
Hmm, your exe won't run after lxliting,
Maybe it doesn't like the non-standard virtual addresses. I am attaching one with the normal 0x10000 - can you see if that is ok?

Yes, this one worked after lxliting.

Quote
Quote
If you can find an old enough exehdr, perhaps the OS/2 v1.3 toolkit, it should run under Win2k as Win2k does support 16 bit OS/2 code
That would only operate on 16-bit NE executables, not 32-bit LX executables introduced with OS/2 2.0, right?

Yes, OS/2 1.x text code runs out of the box. Used to be a Presentation Manager kit to run 1.x graphics as well.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 10, 2024, 05:24:24 am
That's my interpretation.
Ok, I'll pass the observation on, thanks.

Quote
Yes, this one worked after lxliting.
Ok, great.

Quote
Quote
Quote
If you can find an old enough exehdr, perhaps the OS/2 v1.3 toolkit, it should run under Win2k as Win2k does support 16 bit OS/2 code
That would only operate on 16-bit NE executables, not 32-bit LX executables introduced with OS/2 2.0, right?

Yes, OS/2 1.x text code runs out of the box. Used to be a Presentation Manager kit to run 1.x graphics as well.
Right. But the executable I wish to switch from pmcompat to fullscreen is LX, not NE.

So an old exehdr is unlikely to work on it.

Even though an old exehdr should indeed run on Windows 2000.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: Dave Yeo on March 10, 2024, 07:43:17 am
Good point about NE vs LX. Wonder when LX was first used on OS/2. Actually I think it was LE before LX.
Title: Re: DosDevIOCtl disabling keyboard in VIO mode
Post by: kerravon on March 10, 2024, 08:44:03 am

Quote
Am I interpreting that correctly that there is 1 rogue byte somewhere?

That's my interpretation.

pdld was changed to hopefully fix this problem. Could you please confirm that message is gone with the attached executable?

Thanks. Paul.