Building OS/2 apps from QuickC for Windows

Hello from QuickC for Windows

Back in the olden days of when Microsoft had pivoted out of OS/2 in a hurry, I’ve always felt that the common ‘OMF’ objects ought to link for OS/2. But for some reason I never tried. But for some reason I thought I’d try it today.

I first installed Microsoft C 6.0, and set it up for a native OS/2 to OS/2 1.2 setup. This way I get a pure OS/2 include/library directory set. In retrospect, I don’t know why I didn’t just use 2 include / library directory sets to far easier target stuff, without dealing with changing the default names, and making linking an all around living hell.

So the first thing to do is to tell QuickC for Windows to default to the OS/2 include directory (turns out it wont link anyways). Compiling is nothing special. When setting up the project you’ll need a DEF file, I use this simple one:

NAME        QCO2 WINDOWAPI
PROTMODE
CODE        PRELOAD

Nothing to it!

I tried to fight the Windows linker, but it figures out what you are doing and won’t do it. But can you manually link? Well QuickC for Windows does include a DOS linker, and it’s oddly enough newer than the one for Microsoft C 6.0!

C:\proj\o2>msdos \WIN16APP\QCWIN\bin\link hi.obj

Microsoft (R) Segmented-Executable Linker  Version 5.15
Copyright (C) Microsoft Corp 1984-1991.  All rights reserved.

Run File [hi.exe]:
List File [NUL.MAP]:
Libraries [.LIB]: doscalls SLIBCE
Definitions File [NUL.DEF]: qco2.def

C:\proj\o2>msdos hi.exe
This program cannot be run in DOS mode.

Manually invoking the linker wasn’t all too hard, just answer the 30 questions. I did set the LIB environment variable so it picked up the libraries just fine. And yes, it created my OS/2 binary no problem!

And as you saw from above, yes it does run!

I do suppose the graphical editors would have been nice some 30 years ago, but in today’s era, sadly it doesn’t matter. QuickC for Windows won’t run under WLO, so this prevents it being a backdoor GUI/Protected mode compiler for OS/2. It’s a shame too as at least running under Windows 3.0, QuickC for Windows is WAY faster than using Microsoft C 6.00 in either read mode, protected mode with smartdrive.. I’m not sure what the deal is. Even with the advanced caching SCSI controller.

Not sure if anyone cares, but I think it’s cool.

Inside Windows 2000

part 1

A talk from Dave Probert on the design of the NTOS kernel. Shame Microsoft didn’t put this anywhere people could have found this 20+ years ago, just as a shame they never opened up NTOS like they did that even tepid Windows Research Kernel. It goes without saying this is the ‘Linux is a cancer’ generation, with the crazed idea that looking at Linux would contaminate Windows.

PART 2: https://www.youtube.com/watch?v=OrohgqgzhgM

PART 3: https://www.youtube.com/watch?v=SUK_OfEMQos

PART 4: https://www.youtube.com/watch?v=JqnvmedwkYc

Too little, too late I guess. It would have been an interesting foundation a long time ago.

And of course the ongoing work behind the scenes making Windows fully 64bit compatible on the Alpha at the time.

Bill Nye, the Microsoft C 6 guy

So, a while back I had found this up on eBay. As much as I’m trying not to buy old stuff I just couldn’t resist. And the price was just too good, I’d just have to forego going out to dinner for a week.

While looking around for something on Microsoft C, I stumbled upon this promo video for Microsoft C 6. Naturally I had to share it!

I had been using it to mess around with a poorly ported Hack 1.03, although I haven’t done much with that in a while.

One thing is for sure, that the old MS-DOS memory limits were becoming more and more of an issue. Sadly, they didn’t include the QuickC for Windows product which had the benefit of building in protected mode for access to far more memory, nor did they include any DOS Extender to even allow larger runtime access. Obviously you were expected to run this under MSOS/2 1.2 in this era. Although targeting OS/2 protected mode allowed easier integration with PharLap’s 286 based DOS Extender.

Since this was the OS/2 era, the Windows 3.0 SDK was a separate product.

There was another release, the 6.00ax version which included a DOS Extender, allowing the compiler to access 16MB of ram, as reported in this leaflet in a combined Microsoft C & Windows 3.0 SDK package.

The followup Microsoft C/C++ 7.0 addressed many of these shortcomings, but of course famously removed targeting OS/2. There was a later update that at least provided OS/2 compiled version of the binaries allowing you to run it under OS/2. I never tried to see if it could be paired with the OS/2 SDK, and manually made to generate OS/2 executables. I suspect not.

The larger thing is that Microsoft C 386 remained a ‘hidden’ product on Xenix, and the 32bit OS/2 and NTOS/2 betas.

Fun with Windows ePDK NT 3.1 build 196 & Some Xenix fun!

I’m not sure if I covered the Windows NT 3.1 build 196 before. First the most obvious is that as of this moment it’s the earliest version of Windows NT available.

So let’s do some obligatory scratch of the surface. Like all the other 1991 pre-releases there really is just a text mode setup install script. Choosing the lesser amount of pain, I went with a MS-DOS hosted install. However, using MS-DOS 6.22 resulted in a broken dual boot system. But we live in the era of virtual machines, so it really doesn’t matter. I’m using Qemu 0.14-rc2, something that is ‘era correct’ for when the first avalanche broke on early Windows NT pre-releases. I’ve had issues with more modern versions of Qemu, and I felt that if we’re using vintage software may as well go in all the way.

The boot loader identifies itself as being 1990 vintage. Pretty sure it doesn’t mean anything, but we haven’t been blessed with the “blue screen” of ARC yet.

The login screen and desktop have a very strong Windows 3.1 beta feel to them. And that would land this where it was, Windows was such a big seller that Maritz had been trying to convince Gates & Balmer to ‘switch to the Windows horse’ in the spring/summer of 1990, culminating in Gate’s July decision to walk away from NT/OS2 and rebrand the new OS as Windows NT. Oddly enough it was Balmer who was in favour of OS/2 & IBM. (Showstopper 89-90)

At first glance the opening window isn’t all that interesting. It’s just very. Windows.

Rest assured Reversi, of course made the this Win32 cut. And it’s full of weird easter eggs, oddly enough in the OS/2 surviving bits.

type OS2LDR.DOS
OS2LDR 01.00.01
by KeithMo 01/08/91

On the Discord there had been a big discussion about early NT executable formats, and the whole COFF vs ECOFF vs PE/PEI. I had tried to hunt down the specific version of GCC I used ages to to build a so called Dec Alpha GCC cross compiler, but the short version is that it didn’t work as we don’t have any assembler/linker for anything GNU targets. There had been a cygwin port and an OpenNT on Alpha, but all that is lost to the winds, minus what few scraps I had saved. I did try building some cross tools to elf hoping to just objcopy out the data and get linkable objects, but that didn’t work either.

So I though this was a perfect opportunity to take a look at this early pre-release version of NT, and although I do know that you have to convert your objects into something the ‘COFF’ linker will accept:

And I never really paid that much attention to the object files. I do know that you can link them with Link386 for OS/2, but the NT object files themselves report:

wsl file SIMPLE.OBJ
SIMPLE.OBJ: Intel 80386 COFF object file, not stripped, 4 sections, symbol offset=0x102, 20 symbols, created Thu Jun  1 14:13:50 2023, 1st section name ".text"

Well, now that is interesting. And of course the COFF thing reminded me of Xenix! And sure enough ages ago I had found the source to a modified version of GNU GAS that outputs COFF. Once more again this is an indication that all 386 roads in Microsoft really did originate with Xenix. It’s too bad there never was a Windows/386 on Xenix/386. What an incredible OS that would have been! There must be some incredible stories from the tool teams that worked on Microsoft C/386 along with other projects. Oddly enough they never get anywhere near as much exposure as Office or OS.

Now this is fun, but nothing takes in these ancient COFF objects, do they? I tried to run LINK 1.0 from Win32s SDK and surprisingly it didn’t complain about the object, rather, it auto converted it in memory:

Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.

SIMPLE.OBJ : warning LNK4016: unresolved external symbol "__chkstk"
LINK : warning LNK4016: unresolved external symbol "_mainCRTStartup"
SIMPLE.OBJ : warning LNK4016: unresolved external symbol "_printf"
SIMPLE.exe : error LNK1120: 3 unresolved externals

Does this mean that if I give it some libraries it will actually link?

LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.


C:\temp\nt196\x\dec\x>simple
Win32, it's happenin'!

This was. VERY unexpected.

So I had this crazy idea, what if the Xenix assembler could in fact build objects that are also compaible in this manner? I used the a.out GCC / Linux porting tools I had built so I could compile Linux on Windows NT using the vintage tools as a starting point. I guess I should also add that when people always say ‘use newer version of THING’ this is how you miss out on old stuff like this. If I had been obsessed with using modern tools and modern operating systems, I’d have missed out on this Xenix filled window.

I took the gcc driver & the cc1 compiler from 1.40 and the c pre-processor from 2.5.8 as it can understand C++ comments. First I manually compiled the ‘simple’ example to assembly:

gcc -v -nostdinc -I/xenixnt/h -S SIMPLE.c -O simple.S
gcc version 1.40
 cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ SIMPLE.c C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /xenixnt/h
End of search list.
 cc1 C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp -quiet -dumpbase SIMPLE.c -O -version -o SIMPLE.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387
 cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -$ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ simple.S C:/Users/jsteve/AppData/Local/Temp/cca2_048.s
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /xenixnt/h
End of search list.

Which gave me the following assembly:

        .file   "SIMPLE.c"
gcc_compiled.:
.text
LC0:
        .ascii "Win32, it's happenin'!\0"
        .align 2
.globl _main
_main:
        pushl %ebp
        movl %esp,%ebp
        pushl $LC0
        call _printf
        leave
        ret

Now to assemble with the GAS Xenix assembler

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>ax386 SIMPLE.s -o SIMPLE.obj

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>wsl file SIMPLE.obj
SIMPLE.obj: 8086 relocatable (Microsoft), "SIMPLE.c", 1st record data length 10, 2nd record type 0x88, 2nd record data length 11

Not quite the same. But it does closer resemble the output from the OS/2 bound versions of the Pre-Rease compilers:

file EMPTY.OBJ
EMPTY.OBJ: 8086 relocatable (Microsoft), "empty.c", 1st record data length 9, 2nd record type 0x88, 2nd record data length 7

So will it link?!

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

SIMPLE.OBJ : warning LNK4033: converting object format from OMF to COFF

C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>simple
Win32, it's happenin'!

Well now this is interesting! LONG before MinGW, or the GCC port to Windows NT, it turns out that in fact GCC could target Windows NT the entire time!

So the next thing to do is something not as trivial, like phoon.

I setup some quick script to pre-process, compile, assemble and then try to link, but as this one uses floating point, disaster struck:

phoon.obj : error LNK2001: unresolved external symbol "___fixdfsi"
astro.obj : error LNK2001: unresolved external symbol "___fixdfsi"
phoon.exe : error LNK1120: 1 unresolved externals

Now ages ago while messgin with old GCC & DooM I also had weird math calls not working. In the end I ended up extracting them from libgcc builds, so I thought I’d try the libgcc built during the GCC 2.6.3 on NT adventure.

link /NODEFAULTLIB:libc.lib /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup libgcc1.lib LIBC.LIB KERNEL32.LIB
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

And of course:

To try to make the steps make a little more sense, and to allow for some higher level of automation I made a Makefile:

CC=gcc
AS=ax386
CPP=cpp


CFLAGS= -O
CPPFLAGS= -lang-c-c++-comments -nostdinc -I/xenixnt/h

OBJ =   astro.obj \
date_p.obj \
phoon.obj

LIBS = libgcc1.lib LIBC.LIB KERNEL32.LIB

phoon.exe: $(OBJ)
        link -out:phoon.exe $(OBJ) -entry:mainCRTStartup $(LIBS)

%.obj: %.c
        $(CPP) $(CPPFLAGS) $< $*.i
        $(CC) $(CFLAGS) $(INCLUDE) -S -o $*.S $*.i
        $(AS) $*.S -o $*.obj


clean:
        del $(OBJ) *.i *.S phoon.exe

I’m sure there is better ways to do this, but it breaks the compile up to it’s individual parts:

Run the pre-processor to allow // in the comments, C++ hadn’t been the default thing back when GCC 1.40 was a thing. Also path it to the headers, in this case I’m using the ones from NT 196. Trying to link with the 196 libraries gave me this:

C:\xenixnt\demos\phoon>link /NODEFAULTLIB:LIBC.LIB /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup base.lib wincrt.lib ntdll.lib \xenixnt\lib\libgcc1.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

wincrt.lib(maincrt0.obj) : warning LNK4078: multiple ".data" sections found with different attributes (40000040)
astro.obj : error LNK2001: unresolved external symbol "_asin"
astro.obj : error LNK2001: unresolved external symbol "_atan"
astro.obj : error LNK2001: unresolved external symbol "_atan2"
phoon.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_floor"
astro.obj : error LNK2001: unresolved external symbol "_sin"
phoon.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_tan"
phoon.exe : error LNK1120: 8 unresolved externals

Which is not surprising as there is no FPU/Floating point math support in 196. I tried the December 1991 Pre-Release, but it failed for other reasons:

I did copy over BASE.DLL BASERTL.DLL CSR.DLL DBGDLL.DLL as it wanted, but despite the symbol being in the DLL it didn’t load.

So that’s why I’m using the libraries from the Win32s SDK.

Okay, so far now we have GCC 1.40 compiling to an old Xenix GAS assembler, and linking with Microsoft link from Visual C++ 1.0/2.0 era. The next step is to see if we can just link the objects under 196, and get a running EXE!

I have this tiny fibonacci example program, so with it compiled & assembled by GCC & GAS, I did the final link under 196, and YES it runs!

I then built the ’87 InfoTaskForce, Infocom interpreter, and it was just a simple link, and it’s running!

Possible things to do? GCC should be able to build itself, so it should be possible to build GCC and link that on 196 or December 1991, and get a native version of GCC on NT. The other possibility is to get newer versions of GCC (cc1 drop in replacements) to build for Xenix and / or OS/2. Obviously this Xenix linker is the gateway to older 386 Microsoft based products!

For those interested in such things, I’ve uploaded all of this to archive.org here: windows-nt-196-linking-and-running-gcc

Everyone seems to be losing their minds over the Windows XP Professional Key

algorithm being cracked.

But of course, how does that help me?

Unironically, I had purchased this for a whopping £4.68

No, really here’s the receipt. What a bargain!

Of course this is a legit copy with a legit key. But the online activation servers are all gone, and it looks like I’d have to call someone asking about my 22 year old copy of Windows, that I’ll load up and quickly forget.

Since I’m going to use QEMU, 0.90 with pcap support I thought I’d share the startup options:

set loopback=\Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473}
set vmnet1=\Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323}
qemu -m 512 -L pc-bios ^
-hda xphome.vmdk ^
-soundhw es1370 ^
-net nic,model=pcnet,macaddr=52:24:00:33:00:01 ^
-net pcap,devicename=%loopback% ^
%1 %2 %3 %4 %5 %6

I had high hopes for this thing. Clearly misplaced ambitions.

First up, it’s an upgrade version. So that means instead of installing XP I had to waste my time installing NT Workstation 3.51, then installing XP. Yuck. And of course it just want small FAT disks of the 2/4 gigabyte boundary type as it’s 1994. Not the bright future of 2002’s Windows XP.

I don’t know why Qemu 0.90 has issues with XP detecting the CD-ROM drive, but yeah that sucked. I wanted to load up some more insane SNA experiments, but there is no DLC / 802.2 driver for XP Home. wow.

At least once it’s satisfied, we can format the disk as one big happy partition, and we can get on with our lives.

Installation is rather uneventful, however we are instantly reminded that we have only 30 days to go. Since we have that nasty CD-ROM issue that means shutting down, and booting back up, but with this fun program on an ISO image, xp_activate.

I did try to make a call, to activate my Windows, but the connection was terrible and I’m not even sure if these numbers were right. No I mean I know they didn’t work.

So I did what all legit users end up doing, using the crack for my 21 year old copy of Windows.

And just a few clicks later, it was done.

Windows XP Home is activated.

I don’t know if it’s even really going to last, I didn’t try anything else, actually I already deleted it. And the XP folio is back on the bookshelf.

Not only is there no DLC, did you know you can’t uninstall TCP/IP? At least you can unbind it from your NIC. While it does have IPX/SPX there is no built in Netware client. When they said HOME they meant it!

Looking back at MS-DOS 4.00M, or in the beginning before there was OS/2

With the pre-christmas release of the Microsoft OS/2 betas 1.00, 1.01, 1.02, 1.03 & 1.05 on archive.org, and helping Ncommander with an upcoming video, it seemed like a good place to start, not with OS/2 but rather with MS-DOS 4.0.

From the book INSIDE OS/2 ( ISBN 1-55615-117-9 )

Microsoft started work on a multitasking version of MS-DOS in January 1983.  At the time, it was internally called MS-DOS version 3.0. When a new version of the single-tasking MS-DOS was shipped under the name MS-DOS version 3.0, the multitasking version was renamed, internally, to MS-DOS version 4.0. A version of this product–a multitasking, real-mode only MS-DOS–was shipped as MS-DOS version 4.0. Because MS-DOS version 4.0 runs only in real mode, it can run on 8088 and 8086 machines as well as on 80286 machines. The limitations of the real mode environment make MS-DOS version 4.0 a specialized product. Although MS-DOS version 4.0 supports full preemptive multitasking, system memory is limited to the 640 KB available in real mode, with no swapping.2 This means that all processes have to fit into the single 640 KB memory area. Only one MS-DOS version 3.x compatible real mode application can be run; the other processes must be special MS-DOS version 4.0 processes that understand their environment and cooperate with the operating system to coexist peacefully with the single MS-DOS version 3.x real mode application.     

Because of these restrictions, MS-DOS version 4.0 was not intended for general release, but as a platform for specific OEMs to support extended PC architectures. For example, a powerful telephone management system could be built into a PC by using special MS-DOS version 4.0 background processes to control the telephone equipment. The resulting machine could then be marketed as a “compatible MS-DOS 3 PC with a built-in superphone.” Although MS-DOS version 4.0 was released as a special OEM product, the project–now called MS-DOS version 5.0–continued. The goal was to take advantage of the protected mode of the 80286 to provide full general purpose multitasking without the limitations–as seen in MS-DOS version 4.0–of a real-mode only environment. Soon, Microsoft and IBM signed a Joint Development Agreement that provided for the design and development of MS-DOS version 5.0 (now called CP/DOS). The agreement is complex, but it basically provides for joint development and then subsequent joint ownership, with both companies holding full rights to the resulting product.

As the project neared completion, the marketing staffs looked at CP/DOS, nee DOS 5, nee DOS 4, nee DOS 3, and decided that it needed…you guessed it…a name change. As a result, the remainder of this book will discuss the design and function of an operating system called OS/2.

– Inside OS/2.

Although MS-DOS 4.00M disk images have been floating around for quite some time, either a 2 360k disk set, or a single 720k disk image, I don’t think anyone (including me) really tore into it that much. It does have the ability to freeze DOS 3 programs, giving the illusion of running more than one. The session manager is pretty sparse but hitting left alt twice will pop it up giving you the ability to toggle through programs with ease.

MS-DOS 4.00M

There is a FDISK, FORMAT & SYS command making it straight forward to setup a hard disk, and copy the files over, I didn’t see any installer.

there is a PS command to show running processes. Also there is a DOSSIZE to show the memory partitioning and how much is available. Although there is a SWAPPER program I’ve been unable to get it to actually fun.

multitasking!

Another interesting thing if you run the unix ‘strings’ command against all the EXE’s you’ll find the string:

C Library - (C)Copyright Microsoft Corp 1985

Implying that not only was DOS 4.00M a ‘new’ DOS, but it was also written in C. No doubt this contributed to a larger file size than DOS 3, however it would also give that holy grail of portability, at least to new CPU modes. Also many files have the name of the source files baked in such as:

@(#)append.c    1.1 85/10/09
@(#)assign.c    6.1 85/10/23
@(#)attrib.c    6.1 85/10/24
@(#)fdisk.c     1.1 85/10/09
@(#)fddata.c    1.1 85/10/09
@(#)fdlow.c     1.1 85/10/09
@(#)fdsub.c     1.1 85/10/09
@(#)joinsbst.c  6.3 85/11/08
@(#)sysvar.c    6.2 85/11/08
@(#)cds.c       6.2 85/11/08
@(#)dpb.c       6.1 85/11/08
@(#)label.c     6.1 85/10/24
@(#)newdef.y    6.2 85/10/14
@(#)ms4bnr.c    1.1 85/10/15
@(#)mode.c      6.2 85/10/24
@(#)getkey.c    6.1 85/10/25
@(#)pifmes.c    6.1 85/10/25
@(#)advpscrn.c  6.1 85/10/25
@(#)advescrn.c  6.1 85/10/25
@(#)usrscrn.c   6.1 85/10/25
@(#)rangers.c   6.1 85/10/25

Okay so far, so good. But we’ve all seen this before, and scratched this OS about this far, because what else can you do? It’s not like there is any dev tools to do anything fun!

Well the tool hidden in plain sight is LINK4, which in retrospect is specific for MS-DOS 4.00M.

Microsoft (R) 8086 Object Linker  Version 4.01
Copyright (C) Microsoft Corp 1984, 1985.  All rights reserved.

Object Modules [.OBJ]:

There is no SDK for MS-DOS 4.00M, but they were kind enough to leave the linker in place. A quick check of the Windows 1.01 SDK shows that it also includes LINK4:

Microsoft 8086 Object Linker
Version 4.00  (C) Copyright Microsoft Corp 1984, 1985

Object Modules [.OBJ]:

It appears that if the dates and versions are to be trusted they are of the same vintage, but the Windows linker is older, and that they both output to a NE or New Executable. So to start the experiment I created a simple hello world exe from a simple:

void main(){
  printf("Hello from MSC 3\n");
}

To compile this I used Microsoft C 3.0 (more on why later), and used LINK4 to create an EXE:

C:\dos\msc3>cl /c hello.c
Microsoft C Compiler  Version 3.00
(C)Copyright Microsoft Corp 1984 1985
hello.c

C:\dos\msc3>msdos dos4m\link4 hello.OBJ

Microsoft (R) 8086 Object Linker  Version 4.01
Copyright (C) Microsoft Corp 1984, 1985.  All rights reserved.

Run File [HELLO.EXE]:
List File [NUL.MAP]:
Libraries [.LIB]:
Definitions File [NUL.DEF]

Okay, everything looks fine so far. Attempting to run this under MS-DOS just results in the error:

Program too big to fit into memory

Well now that’s odd. Checking the EXE with the Linux ‘file’ command reveals:

file HELLO.EXE
HELLO.EXE: MS-DOS executable, NE (unknown OS 0) (EXE)

So obviously it’s a NE, but it is an older/unknown version to the file map database. There is no stub so I suppose that is why MS-DOS is getting confused.

Now let’s try MS-DOS 4.00M

Hello!

Well now isn’t that interesting?!

Excited with the ability to create special MS-DOS 4.00M programs, I get my favorite vintage ’87 Infocom interpreter, InfoTaskForce 87, and get it building on MSC 3.0. However instead of using the MS-DOS 4.00M linker, I thought I should try to use the Windows 1.01 linker and libraries for the exe:

C:\dos\msc3\infocom>msdos ..\win101sdk\bin\LINK4.EXE @infocom.win.lnk

Microsoft 8086 Object Linker
Version 4.00  (C) Copyright Microsoft Corp 1984, 1985

Object Modules [.OBJ]: FILE.OBJ FUNCS.OBJ INFOCOM.OBJ INIT.OBJ INPUT.OBJ +
Object Modules [.OBJ]: INTERP.OBJ IO.OBJ JUMP.OBJ OBJECT.OBJ OPTIONS.OBJ PAGE.OBJ +
Object Modules [.OBJ]: PRINT.OBJ PROPERTY.OBJ SUPPORT.OBJ VARIABLE.OBJ TERM.OBJ
Run File [FILE.EXE]: INFOCOM.EXE/ALIGN:16
List File [NUL.MAP]: INFOCOM.MAP
Libraries [.LIB]: MWLIBFP MWLIBC/NOD
Definitions File [NUL.DEF] INFOW.DEF;

And for those interested this is my .DEF file:

NAME    Infocom

DESCRIPTION 'Infocom 87 interpreter for Planetfall(83)'

DATA    MULTIPLE


HEAPSIZE    1024        ; Must be non-zero to use Local memory manager
STACKSIZE   4096        ; Must be non-zero for SS == DS
                        ; suggest 4k as minimum stacksize

SEGMENTS
    _INIT   PRELOAD MOVEABLE DISCARDABLE

One thing to save you the horror is that between MS-DOS 2 & 3 the way command line arguments changed. I forget the details but no matter what I tried I was unable to parse the CLI or the environment in this setup. I suppose if I had documentation of the product there would be some hint as to what tools or setup to use. Instead, I took the easy way and hard coded to load Planetfall.

InfoTaskForce compiled with MSC 3.0, using Windows 1.01 libc / LINK4

Unfortunately, this success would prove to be the exception to the rule. I took trek, converted it to K&R C, as Microsoft C 3.00 from 1985 is well. old, and sadly it just won’t run. Likewise, I took Hack 1.03 and although it runs on MS-DOS it will not run on MS-DOS 4.00M. I am sure there is some fundamental reason why it’s not working, and probably tied to creating a proper DEF file. I’m sure it was all written down somewhere but I don’t know. And yes I tried specifying either floating point emulation via library or inline, and it made no difference.

Looking at OS/2 1.00

Loading up the infamous $3,000 OS/2 1.00 beta, and hitting ctrl+escape you are greeted with session manager!

Session Manager for OS/2

Notice the R for real-mode. With the obvious implication that everything else is protected mode. Going one step further on the excellent site pcjs.org there is OS/2 betas SIZZLE and although there is no OS/2 development bits on there, the directory DOS3TOOL reveals that the C compiler for this era for at least MS-DOS is MSC 3.0. Also included is our friend LINK4.

I create a simple def file that contains the single word ‘PROTMODE’ which should give me my OS/2 binary.

So let’s run that through hello world:

msdos sizzle\DOS3TOOL\link4  hello.OBJ,hello,,,hello.def;

Microsoft (R) Segmented-Executable Linker  Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986.  All rights reserved.


C:\dos\msc3>

However attempting to run this just crashes amazingly.

Real mode LIBC in Protected mode:

No doubt it’s because the real-mode libc is using interrupt 21 calls, which OS/2 sure wouldn’t like. I’m pretty sure it requires an OS/2 libc that uses DOSCALLS.DLL to function, which I just don’t have any pre-release versions, nor any libc source code to really make it possible. And attempting to port one to OS/2 pre-releases just doesn’t seem so worth the time.

So for the heck of it I point the LIB variable to the OS/2 1.00 SDK’s libs and re-run the link:

C:\dos\msc3>msdos sizzle\DOS3TOOL\link4  hello.OBJ,hello.exe,hello.map,C:\86box\100\x\MSC\LIB\slibc5.lib \86box\100\x\LIB\DOSCALLS.LIB,hello.def;

Microsoft (R) Segmented-Executable Linker  Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986.  All rights reserved.

By default it’s trying to link in EM.LIB, SLIBFP.LIB, SLIBC.LIB. Trying to add them all in the command line link just hangs LINK4 maybe a response file is better suited. Anyways:

Hello from MSC 3.0 in protected mode.

It does run on OS/2 1.00, which I guess isn’t surprising as the LINK4 & libraries are from/for this version.

As an interesting note, OS/2 links against doscalls library/DLL to interface to the OS. While MS-DOS 4.00M doesn’t have a seperate DLL, rather it’s baked into IBMDOS.COM

DOSCALLS
ALLOCSEG
REALLOCSEG
FREESEG
LOCKSEG
UNLOCKSEG
GETSEGSIZE
GETDSHANDLE
CRITENTER
CRITLEAVE
FCRITENTER
FCRITLEAVE
PBLOCK
PRUN
SUBSCREEN
GETPIDS
DOSDISCARDCODE
DOSGETHANDLE
DOSHANDLEJUMP

Noticeably absent is file I/O, No doubt allowing programs to use the standard int21 interface to the kernel for file I/O. No doubt this is in its primordial state, as the OS was going to evolve a bit more until it became OS/2. Unfortunately I have no idea how to link or call into this. Without any SDK it’s impossible to say. And even then is developing for a real mode OS worth the effort?

So what have we learned? LINK4, aka the MS-DOS 4.00M Linker, probably should have been called LINKNE for the NE format. Also there is references to it having it’s own virtual memory paging system, and being able to link larger EXE’s than the traditional link command. Sadly I was unable to get any non trivial programs running. I don’t think it was a memory model thing, although the C compiler has issues with InfoTaskForce and the large memory model for some reason, but small & medium work fine. I’d like to think that DOS 4.00M could support massive EXE’s much like Windows 1.01, however despite being from the same company and using the same tools, the memory manager for DOS 4.00M & Windows is fundamentally different.

With all these exiting OS/2 betas now available I’ll have to take some more time to explore them in more detail.

But until then I thought this genesis of DOS 4.00M was worth the look.

So I have a splitting headache.

You’re welcome.

So since Im going to share my pain, did you know that Windows 11 updated notepad?

YES.

And it’s BROKEN.

Here I have a simple file, It’s very MS-DOS like and I want to change it to Unix. Yes I could use SED but I have NOTEPAD so let’s change the backslash to a forward slash. Something notepad.exe could do going back to 1985.

And it’s become a bunch of spaces. Great. Check the search/replace and yeah it’s gone and done it’s own thing.

And you may think wow thats broken but come one it’s not *that* bad. And you’d be wrong. So very very wrong.

My next attempt got me this.

I don’t even know what the hell happened. I guess I should be happy the slashes changed, but at what cost? AT WHAT COST?!

My god Microsoft how could you fuck up notepad this badly?

And yes, I blame Canada!

Can you trust a man in a van with your virtual plan?

Once upon a time this was a legitimate ad. Tad from VM-limted.com. Sadly the domain has all but lapsed and finding any reference to this ad is pretty much impossible to search for. You’d think with the ‘glamp’ of vanlife and living in a van that people would love to take notes from the Microsoft VM-limited 70’s style conference van.

Nissan NV350

Instead I was getting crap like this Nissan NV350 which looks so 1960’s SciFi that it’s just unlivable and unusable. Compare that pod living thing to this incredible 1970’s themed van from VM-limited!

So comfortable!

From leather chairs, rolodexes, tube televisions to the mandatory ashtrays, wood paneling and shag carpet how could this not be a ‘work from the road’ thing today? While looking at other solutions for working on the road they seem to be so boring and unlived in that they feel about as legit as that new starwars hotel that looks like a telephone game of ‘space conflict’.

As far as I can tell it started as a print campaign in 2011 to be launched the same time as the big VMware convention (vmworld?!) back then.

2011 print ad

I do have to admire the very Atari-esque look of it. Apparently it was good enough to get some videos shot in the van:

And along with that was a TADTalk. I mirrored it on my site, and with a bit more searching I found some more and put them on archive.org.

It’s too bad the domain lapsed, and Microsoft didn’t hop onto the van-life trend with their future thinking retro 70’s conference van.

Anyways to help me google/bing it in the future Microsoft man in van selling virtualization.

Anyone else living the nomadic life? I guess with wife + kids it’s hard, but I’m sure someone is doing it.

Microsoft OneDrive & SharePoint Library dropdown menu insanity!

I don’t know what is so exciting about this feature but Microsoft has paged me about 2-300 times this morning about this exciting feature.

Microsoft OneDrive & SharePoint Library dropdown menu

As of 10:25 BST/HST it’s still going off. I had to mute the Office 365 Admin application. Talk about either over excited or just plain broken. Over on reddit yeah, it’s everyone else.

Do people even use sharepoint anymore?