OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started 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"
#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);
}
-
Your call to DosDevIOCtl to get old input mode has been coded incorrectly. Should use the parameter packet rather than the data packet.
-
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.
-
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() ).
-
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.
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.
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.
-
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:
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.)
-
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.
-
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).
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>
-
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).
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).
-
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?
-
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.
-
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).
[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
-
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.
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).
[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.
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.
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).
-
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.
-
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).
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
-
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).
[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?
-
In a DOS window,
H:\TMP>pdptest
SYS3011: The .EXE file that starts the program you specified contains
an error.
-
Tried lxlite, a program originally for compressing lx files, extended quite a bit. It reports error reading executable.
yum install lxlite
lxlite /?
-
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).
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).
-
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:
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:
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.
-
How did you link this thing? Its layout doesn't look anything like an OS/2 LX executable.
Using pdld.
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.
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.
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.
-
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.
-
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.
-
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.
-
... 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:
- 'Auto DS object' is not set.
- The 'Module flags' don't define an API type (PM, Windowcompat, NotWindowCompat)
- Assuming that the entry table is empty, the 'Entry table offset' should point to the same address as 'Fixup page table offset'
- The 'Resident names table offset' is invalid. Thus the kernel cannot determine the internal module name of the image
- The 'Import module entry count' is set to two even though the 'Import module table' only contains one entry (DOSCALLS)
- The 'Import procedure names table offset' points beyond the end of the file
Also strange:
- OS/2 executables normally use a base address of 0x10000. That's the lowest possible virtual address.
- 'Object 3' is usually the stack. It's pages are not present in the executable. Instead they are flagged as 'ZERO FILLED'.
- Given 'Object 3' ist the stack, 'Starting ESP' should point a few bytes before the end (i.e. virtual size - some_space) of this object.
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.
-
... 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.
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.
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!
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.
-
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.
-
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.
-
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.
-
Hello
In DOS Window Session (ArcaOS 5.1.0) gives me:
C:\DESKTOP>pdptest
This program needs OS/2 2.0 or equivalent
Under OS/2 command line:
[C:\DESKTOP]pdptest
SYS0188: The operating system cannot run C:\DESKTOP\PDPTEST.EXE.
No OS hangs here.
Regards
-
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.
-
Try help 188,
[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.
-
Try help 188,
Thanks! Never occurred to me that there would be help for this error message.
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.
-
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.
-
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
-
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.
-
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).
-
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.
-
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.
exehdr /PMTYPE:NOTWINDOWCOMPAT uemacs.exe
Seems to run fine here, though I don't know emacs enough to really test. Good work.
-
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
-
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
-
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.
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.
Seems to run fine here, though I don't know emacs enough to really test. Good work.
Thanks!
-
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).
-
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
-
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?
-
Running lxlite on the exe gives,
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,
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
-
Running lxlite on the exe gives,
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?
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?
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?
-
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
-
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
-
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. :-)
-
Running lxlite on the exe gives,
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.
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.
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.
-
That's my interpretation.
Ok, I'll pass the observation on, thanks.
Yes, this one worked after lxliting.
Ok, great.
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.
-
Good point about NE vs LX. Wonder when LX was first used on OS/2. Actually I think it was LE before LX.
-
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.