bocke
Experienced Member
People claim WIN32s doesn't support WIN32 console applications. This is partially true. As Windows 3.1 doesn't have appropriate subsystem, they are only stubbed in WIN32s. The main effect of this is that console applications don't have any output (no stdout or stderr). But that doesn't mean they can't "run".
I came to this conclusion after seeing nconvert (a win32 console application) in the list of WIN32s compatible software from Stephan Großklaß (nowadays maintained by Gabby Chaudry) and then trying a few older WIN32 command line tools. An older version of gzip compiled for NT 3.1 worked, Zip 5.31 for WIN95 worked, Rar 2.00 worked. 7za (7-zip) didn't work. Rar 2.90-4.20 didn't work.
7za didn't work because relocations were stripped from the binary. WIN32s supports only WIN32 binaries with .reloc section. Rar (for WIN32) after 2.90 didn't work as some kernel function was not implemented in WIN32s.
The way this works... Windows apps can't be started from DOS prompt, but they can be started from Windows apps. The most convenient would be a command line program like TakeCommand/16 (formerly shareware, now freeware):
The first image shows compressing files with rar. The second image shows decompressing files from a zip archive. While the programs don't output anything, they do what they are supposed to.
Another example: Using Digital Mars compiler to compile a simple C program.
Funnily enough, by default, the generated program is WIN32 console app. So, you can't actually see "Hello World!". But it seems to run. This needs further testing, but it seems Digital Mars C compiler output (at least in WIN32 console mode) is by default WIN32s compatible.
I ran the binary on a more complete WIN32 platform (in this case WINE 10.0RC3) and "Hello World!" is there.
Of course, the biggest problem with using WIN32 console apps here is the missing output which makes debugging really awkward.
For open source applications that might not be such a big problem as you can easily hack most programs to output stderr and stdin into a file on disk. Or you can solve it in a way contemporary compilers for WIN16 solved the problem of porting command line programs to WIN16 - by using a stdio wrapper that redirects all output into a window. Both Microsoft and Borland had their own solutions that came with their respective compilers. There were also 3rd party implementations.
For compiling WIN32s programs you can use Open Watcom or Digital Mars C/C++. Or one of contemporary development environments. LCC-WIN32 did, at some time, unofficially support generating WIN32s apps. MinGW32 was used to compile some WIN32s ports at the time, although this is largely undocumented. Borland's free command line tools (BCC 5.5) released in early 2000 are also WIN32s compatible.
Anyway, after this short exploration I can conclude that WIN32 console apps work on WIN32s, but don't have any output. Those that don't work either don't have .reloc section or use something that is not available in WIN32s. The tools from 90s are more likely to work than modern WIN32 tools as in example of Rar WIN32 command line utility.
I have seen claims to otherwise so I decided to document this somewhere where people could find it when searching for information on this.
How to see if WIN32 console app might be supported under WIN32s? You can use an EXE exploring or dumping program. I use Semblance Disassembler as it lets me easily see the basic file and platform data. But you can use any tool you like or suits you. Semblance might have advantage only in that it also show information on relocations inside the executable which some other tools might not show (at least by default).
This is the output of dump -f Rar.exe on Rar 2.60:
Here we don't get any information on stripped relocations. This means this binary might work on WIN32s.
This is the output of dump ran on 7z.exe from 7zip 4.60:
We can clearly see that the relocations are stripped. This binary won't work on WIN32s.
I came to this conclusion after seeing nconvert (a win32 console application) in the list of WIN32s compatible software from Stephan Großklaß (nowadays maintained by Gabby Chaudry) and then trying a few older WIN32 command line tools. An older version of gzip compiled for NT 3.1 worked, Zip 5.31 for WIN95 worked, Rar 2.00 worked. 7za (7-zip) didn't work. Rar 2.90-4.20 didn't work.
7za didn't work because relocations were stripped from the binary. WIN32s supports only WIN32 binaries with .reloc section. Rar (for WIN32) after 2.90 didn't work as some kernel function was not implemented in WIN32s.
The way this works... Windows apps can't be started from DOS prompt, but they can be started from Windows apps. The most convenient would be a command line program like TakeCommand/16 (formerly shareware, now freeware):
The first image shows compressing files with rar. The second image shows decompressing files from a zip archive. While the programs don't output anything, they do what they are supposed to.
Another example: Using Digital Mars compiler to compile a simple C program.
Funnily enough, by default, the generated program is WIN32 console app. So, you can't actually see "Hello World!". But it seems to run. This needs further testing, but it seems Digital Mars C compiler output (at least in WIN32 console mode) is by default WIN32s compatible.
I ran the binary on a more complete WIN32 platform (in this case WINE 10.0RC3) and "Hello World!" is there.
Of course, the biggest problem with using WIN32 console apps here is the missing output which makes debugging really awkward.
For open source applications that might not be such a big problem as you can easily hack most programs to output stderr and stdin into a file on disk. Or you can solve it in a way contemporary compilers for WIN16 solved the problem of porting command line programs to WIN16 - by using a stdio wrapper that redirects all output into a window. Both Microsoft and Borland had their own solutions that came with their respective compilers. There were also 3rd party implementations.
For compiling WIN32s programs you can use Open Watcom or Digital Mars C/C++. Or one of contemporary development environments. LCC-WIN32 did, at some time, unofficially support generating WIN32s apps. MinGW32 was used to compile some WIN32s ports at the time, although this is largely undocumented. Borland's free command line tools (BCC 5.5) released in early 2000 are also WIN32s compatible.
Anyway, after this short exploration I can conclude that WIN32 console apps work on WIN32s, but don't have any output. Those that don't work either don't have .reloc section or use something that is not available in WIN32s. The tools from 90s are more likely to work than modern WIN32 tools as in example of Rar WIN32 command line utility.
I have seen claims to otherwise so I decided to document this somewhere where people could find it when searching for information on this.
How to see if WIN32 console app might be supported under WIN32s? You can use an EXE exploring or dumping program. I use Semblance Disassembler as it lets me easily see the basic file and platform data. But you can use any tool you like or suits you. Semblance might have advantage only in that it also show information on relocations inside the executable which some other tools might not show (at least by default).
This is the output of dump -f Rar.exe on Rar 2.60:
Code:
File: Rar.exe
Module type: PE (Portable Executable)
Module name: rar.exe
Flags: 0x818e (executable, line numbers stripped, local symbols stripped, little-endian, 32-bit, big-endian)
Image type: 32-bit
File version: 0.0
Linker version: 2.25
Program entry point: 0x401000
Base of code section: 0x1000
Base of data section: 0x27000
Preferred base address: 0x400000
Required OS version: 1.0
Subsystem: CUI
Subsystem version: 3.10
DLL flags: 0x0000 ()
Stack size (reserve): 1048576 bytes
Stack size (commit): 8192 bytes
Heap size (reserve): 1048576 bytes
Heap size (commit): 4096 bytesHere we don't get any information on stripped relocations. This means this binary might work on WIN32s.
This is the output of dump ran on 7z.exe from 7zip 4.60:
Code:
File: 7z.exe
Module type: PE (Portable Executable)
Flags: 0x010f (relocations stripped, executable, line numbers stripped, local symbols stripped, 32-bit)
Image type: 32-bit
File version: 0.0
Linker version: 6.0
Program entry point: 0x41a6f6
Base of code section: 0x1000
Base of data section: 0x1e000
Preferred base address: 0x400000
Required OS version: 4.0
Subsystem: CUI
Subsystem version: 4.0
DLL flags: 0x0000 ()
Stack size (reserve): 1048576 bytes
Stack size (commit): 4096 bytes
Heap size (reserve): 1048576 bytes
Heap size (commit): 4096 bytesWe can clearly see that the relocations are stripped. This binary won't work on WIN32s.
