[kernel] Add capability to load and execute OS/2 binary executables

[ghaerr]

Work in progress... will be several commits before complete. Discussion encouraged.

Adds major new capability to load 16-bit OS/2 v1.x binary images easily produced by the OpenWatcom C compiler and toolchain.

After studying the native OS/2 binary format produced by Watcom as well as ELKS' a.out format, having ELKS load and execute OS/2 binaries directly is thought to be the best way forward to enable using Watcom C, which will allow for all memory models produced by Watcom (small, medium, compact and large) to be executed directly by ELKS without any conversion.

Note: OS/2 binary images produced for OS/2 itself won't run on ELKS, as the OS/2 system calls are different. However, the current ewcc and ewlink scripts allow for easy compilation and linking using Watcom C, which for the moment still require conversion from OS/2 to ELKS binary format using os2toelks, and are limited to a single code and data segment. After this PR, the OS/2 -> ELKS executable format conversion step will no longer be required, which should enhance correctness and permit large applications with multiple code and data segments to be runnable on ELKS.

This optional capability will be controlled via CONFIG_EXEC_OS2.

[ghaerr]

ELKS support for running unmodified OS/2 binaries created using the Open Watcom C toolchain is pretty much complete.

The ewlink script has been updated to produce just a name.os2 executable (from name.c) and no longer runs os2toelks to convert the executable to ELKS a.out format. After some user testing, the .os2 extension will be removed and ELKS will seamlessly run executables in ether the original (MINIX) or OS/2 (Watcom) format and just work.

At this point, all memory models are supported, including those such as large and compact that may produce multiple data and/or code segments, allowing for pretty large programs. For kernel space reasons, there is a currently limit of five 64k segments allowing programs of 320K+ size to run. This can easily be changed by editing limits.h, and the loader will produce an error should your program be too large.

This is pretty exciting as the multiple segment load/execution capability added to the kernel allows for much larger programs to be ported to ELKS. Currently, the user must manually install and/or compile the Open Watcom toolchain, this could change in the future and have it automatically done just as is done for the IA16 GCC compiler.

Both IBM and PC-98 automatic builds have the OS/2 binary execution capability (CONFIG_EXEC_OS2) enabled by default.

[tyama501]

Fantastic! Thank you.

[toncho11]

Thank you @ghaerr ! That is a big contribution to ELKS! Awesome!

[tyama501]

Hello @ghaerr ,

I am trying the latest environment.
After modifying the owc header PATH and building libc as before,
I tried compiling the sjis_to_utf8 and I got the following error exceeding data segment.

Do I need some extra option?

[ghaerr]

Hello @tyama501,

It seems that OWC is telling you that your default data segment is 2514 bytes greater than 64K. In large or compact models, OWC allows for multiple data segments, but declarations including the stack, heap and data declared of size less than 32K or so gets put in the default data segment. That is, it seems that the programmer must break up data segments into various pieces in order to keep any given segment from becoming >= 64K.

In my testing, I used wdis on the .obj file and observed which variables ended up being in the _DATA versus other segments such as basic13_DATA, etc, and this worked OK.

I haven't looked at your source, are there array declarations that are large, or is this just tons of smaller constant strings?

We may need to take a look at the OWC C Reference Manual or Programmers Reference Manual in order to decide how to handle this.

[ghaerr]

@tyama501:

See page 48 of the Watcom C/C++ Users Guide (https://openwatcom.org/ftp/archive/11.0c/docs/cuserguide.pdf):

This describes using the -ztN option to allocate data into a far segment based on its size. To add this open to ewcc, add something like the following line to CCFLAGS:

-Wc,-zt1024   \

I will play around a bit with this as well. I need to know more information about how your program defines data in order to best solve this. That is, is it array declarations or just static strings that is causing this issue.

[tyama501]

https://github.com/tyama501/sjis-to-utf8_elks/blob/main/sjis_to_utf8.c

There are big table.h.

It could link with the previous environment.
(Although it didn't worked)

I will try the option later.

I may play with other codes since this code works well with gcc ia16 and it does not need to use owc.

Thanks.

[ghaerr]

It could link with the previous environment.

Which previous environment, do you mean something to do with ELKS? The error you are getting is from Open Watcom Linker, not an ELKS tool. It could be another option in ewlink that was changed, or are talking about something else?

There are big table.h.

If those tables are declared __far, perhaps this will solve the problem.

[tyama501]

The previous ELKS ewcc, ewlink, libc I have been using here.
#1912 (comment)

I updated to the latest ELKS but the owc is same as before.
Maybe option changed?

[ghaerr]

I updated to the latest ELKS but the owc is same as before.

Maybe option changed?

Oh, I see. Yes, I think I added the following two lines to ewlink that hardcode the stack and heap to 4096 bytes. If you edit ewlink you can change them to your previous or required values. This was done because the OS/2 binary format does not accept 0 as a default heap or stack value, so now it is explicitly specified. I hope to add options to ewlink that allow this to be specified in the command line, but haven't had time to do that yet.

    -Wl,option -Wl,stack=0x1000     \
    -Wl,option -Wl,heapsize=0x1000  \

[ghaerr]

I also just noticed the -zc option which allows for putting all constant strings into the code segment. This should work well if you have lots of strings that exceed the default data segment size (page 45):

[tyama501]

Hello @ghaerr ,

OK. By -zt1024 option, the tables moved to far data segment. (Confirmed with wdis)

And it finally worked!

I confirmed the converted 165KB file is the same as the file I got by gcc ia16 version.

Thank you.

[ghaerr]

Hello @tyama501,

Thank you for getting your large-model program working and tested with our new multi-far-segment loader program execution capability. This is really great knowing all this actually works and is useful!! Over time, the rest of the system calls can be fleshed out as needed for other new programs.