It’s 1995 and I’ve been nearly two years in the professional workspace. OS/2 is the dominant workstation product, Netware servers rule the world, and the year of the Linux desktop is going to happen any moment now. If you weren’t running OS/2, you were probably running Windows 3.1, only very few people were using that Linux thing. What would have been the prefect OS at the time would have been NT with a competent POSIX subsystem, but since we were denied that, enter Hiroshi Oota with BSD on Windows.

It was a late night browsing yahoo auctions Japan as one does, laughing at the absurd Famicom/Super Famicom games, and I went ahead and looked for BSD CD-ROMS, where I first came across BSD on Windows. And then I’d forgotten about it and went to work on some Darwin projects.

Fast forward 3 weeks, and vic485 had bought it, had it shipped, and uploaded on archive.org. So a big super thanks to vic485 for making this all possible!

So what is it? It’s not quite BSD, its a bunch of 16bit DLL’s that broke the kernel down into subsystems, that each rely on winmem32.dll to give access to flat/32bit address space. BSD on Windows (BOW) being a hybrid 16/32bit app is originally for Windows 3.1, with the later 1.5 update for Windows 95, which includes support for long filenames. I’m not sure if it’ll run on Windows NT or OS/2, as I don’t think

So what do you get?

The key media contents are the install floppy and the CD-ROM. Yes the setup program IS only on the floppy. Hope you get that disk image. I’m unsure what the manual is like, other than of course it is in Japanese.

It’s very much a single user mode BSD like environment complete with vi/gcc/csh/perl just to name a few. I’ve been able to test job control, and building some simple programs like Hack 1.03. I found a few issues however.

I haven’t tested enough with FreeBSD 1/2 but I can verify that from my ‘Ancient Linux on Windows‘ packages, the object format is the same, which is that early era when everything was a.out, although all different the reliance on GNU GAS & LD did make the object format the same. And it was nice to compile a hello world from my Linux cross compiler, link it on BOW, and get a running executable.

The memory is weird, in that you can add hundreds of megabytes to Windows and BOW will always run exhausted. In the bow.ini file you can set the heap for each program, and I found out from some silly trial and error that the maximum heap you can effectively give is 13 megabytes. It seems that winmem32 has a single chunk of memory where all processes run out of, hence the sub 16mb ram zone. Maybe there is a way to allocate it, but I’m unsure, maybe it’s in the book. CC1 was frequently having issues, so setting it’s heap to 13M sure helped, the linker ‘ld’ of course was running out of memory as well so setting it to 8M got me linking.

Filenames, especially on Windows 3.1 are a huge problem. All the LFN TSR’s I tried to load just resulted in a full crash. I had to point the linker to the CD-ROM live filesystem, which maybe would be tedious on a real machine, but under emulation it’s fine.

BOW does NOT like Qemu. At all. It won’t under otvdm either. I suspect NT is a no go but I haven’t tried. Oddly enough it’s not a timing issue, as it does run under VMware. There is an advantage to running it under Windows 95, is that it supports long filenames. 86Box works as well, I even was using the Pentium II Xeon at 400Mhz and that ran fine.

Probably the most annoying and silly thing is that the GCC C compiler doesn’t have C++ style comments turned on. Not being able to use ‘//’ is quite annoying.

Hack ran fine on my 386, which was a pleasant surprise!. It was really cool to have Word+Excel and Hack running at the same time.

Had I known about this, it would have been an incredible bridge product. Not to mention cross compiling to even Win32, or Linux. Not to mention at the time being able to run BSD with no real pain, just install and go

There is generic TCP/IP Winsock support in BOW 1.5 as it simply calls winsock. This also includes the ability to run daemons, however limitations in BOW are quickly exposed, such as missing setuid/setgid sno there is no ability to impersonate lower privileged users. MMAP stuff also doesn’t seem to work, although I was able to build a super simple port of Apache 1.3.1 to BSD on Windows (BOW). 

While BOW may appear to be very BSD like, there is a lack of a the mmap Apache needs, along with user mapping & impersonation.  I ended up using the EMX – OS/2 system code, since it’s very POSIX like without relying on the Unix like OS actually working.

I’ve been able to serve pages to myself, however BOW crashing out many emulators and hypervisors kind of stops me from putting it on the internet. BOW enthusiasts can download it from archive.org

Today, there is really no point to BOW, it’s an interesting oddity, but back in the day, for a jr network administrator being able to run the Unix version of the snmp tools, even if it’s only client side would have been great. If tftpd could be built to run this would have been beyond amazing, as you not only get BSD, but full Windows apps at the same time, much like MachTen.

It’s a shame I never knew this was a thing, I certainly would have been evangelizing BOW! Who knows what other treasures are in the parallel societies of Japan/Asia/Europe?

**UPDATE

Ive been able to cross compile from Windows to BOW using an old 386BSD 0.1 cross tool chain. You can read about it here: Cross compiling to BSD on Windows (BOW) from Win32

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.

So yeah its a new binary release version 0.8.1. Download the zip here: otvdm-v0.8.1.zip

So far things seem good, the torture test is usually compiling with QuickC for Windows, and SimCity for Windows 1.0. Excel & Word are as always bonus material.

Follow the project over on github here: winevdm

This will be the perfect follow up to the aptly named previous post FreeDOS running Windows 3.1.

I’ve haven’t built the FreeDOS kernel in a while and I have to say it’s pretty easy. I’m taking the easy way out here, so I’m using OpenWatcom v2, because I figured the tools should be both at least Win32/Win64 and halfway up to date. Don’t get me wrong, MS-DOS Player is a fantastic app but I don’t want to lean on it for 100% of the build.

I configured it for something in my mind generic with the following flags:

build fat16 wc 86 win

Naturally it had issues with 3 executables, two of which are generated as the project builds, and I just did some silliness to have MS-DOS player make ‘native’ versions:

patchobj.com: patchobj.c
        $(CLT) $(CFLAGS) patchobj.c
        msdos -cobj.exe patchobj.com
        -rm -f patchobj.com
        -ren obj.exe patchobj.exe

exeflat.exe: exeflat.c ../hdr/exe.h
        $(CLC) $(CFLAGS) exeflat.c
        msdos -cxeflat.exe exeflat.exe
        -rm -f exeflat.exe
        -ren xeflat.exe exeflat.exe

The same went for sys\bin2c.exe but it’s not rebuilt every time so it doesn’t matter.

And with that in hand it boots. YAY

And now for some absolutely unfair testing. Before anyone complains, yes this is absolutely unfair I mean hell if you bought Windows 3.1 in 2021, I guess get OS/2 or just keep digging at the yard sale and get MS-DOS. Anyways here we go:

Turning off InDOSPolling gives this lovely crash. Naturally then it’s still required.

My go-to test, Running Infocom/FASA BattleTech Crescent Hawk’s Inception in CGA mode in a Window hard locks the VM before anything is drawn to screen. Bummer. And that is pretty much the story of FreeDOS under Windows on this build. Again it’s 2021 who even needs Microsoft VDMs?

That said there must be some weird hook in MS-DOS that Win32s relies on. Just like before Win32s fails to run.

The holy trinity of ‘bad’ Windows 3.0 games, Sim City, Sim Earth and Sim Life work just as they did in the prior version, with Sim Earth instantly quitting. Not sure what is going on there. It does launch with virtual memory enabled, but then proceeds to corrupt all the file handles and Program Manager loses it’s mind. In the productivity front Excel v3, and Microsoft Word v2 run fine. Yay!

So in conclusion doing Win16 things in Windows 3.1 is seemingly fine.

I ran across this, and thought it was cool. These CD’s are getting harder and harder to find, and unless you want the old physical disks, getting ISO images is, of course the next best thing.

• Pre-Release Disk 1 – September 1992
• Pre-Release Disk 2 – January 1993
• Disk 3 – April 1993
• Disk 4 – Summer 1993
• Disk 5 – Fall 1993
• Disk 6 – Winter 1994
• Disk 7 – April 1994
• Disk 8 – July 1994
• Disk 9 – October 1994
• Disk 10 – January 1995
• Disk 11 – April 1995
• Disk 12 – August 1995
• Disk 13 – October 1995

• Microsoft Programmers Library 1.1a
• Microsoft Programmers Library 1.3

Granted these disks replaced the much older Microsoft Programmer’s Library. The new CD’s use a Windows based search & interface program removing the clunky old MS-DOS program that made it feel like trying to view the world through a straw. (Although the up side of the MS-DOS version is that you could easily dump the video RAM and save the contents to plain text).

And in this brave new post Windows 3.0 centric world of Microsoft just about everything regarding OS/2 was dumped, and the seeding of Win32 via Windows NT had started.

Naturally after winning this war, Microsoft withdrew many low end products and just couldn’t compete with the tidalwave that was GNU/Linux.

At any rate for the curious kids down the road that want to see what all the fuss was with Win16, and how Windows 3.0 had changed the landscape removing the force of IBM it’s worth a look.

People were excited, but then kind of dismayed as they couldn’t really do much with it.  Oddly enough the source code release really didn’t have any notes on how to build it, although everything needed is included.  I went looking for information on how to build Word to see why it keeps doing weird things on WineVDM, and I came across this thread on betaarchive: 

https://www.betaarchive.com/forum/viewtopic.php?t=31096

Special props to yksoft1 for getting it to build in the first place, and Ringding for noticing that the OS/2 supplied compiler binaries can be re-bound to run under MS-DOS using a MS-DOS Extender.

So I went ahead and fired up Qemu and within an hour I had done it!

Well this is great fun, and all, but there isn’t a heck of a lof of people with Windows 2.x around anymore.  And of course Word 1.1a really wanted to have 2.11 or higher.  It has some hooks for what would be Windows 3.0 although I think it was much more.  Although it certainly doesn’t want to run (unmodified) under debug release 1.14.

So now that the world has gone beyond Win16 OS’s what can you do?

Well the tip of  WineVDM will run it!

So now there is some new life for this old word processor.

Another fun thing in Word 1.1a is that it has an early implementation of MDI letting you view and work with several documents at once.  Naturally you would need a massive monitor, which we all have today.  Although people tend to just launch more than one copy of Word to accomplish this.

So now on my 64bit machine I can not only play with the source to Word, but I can run it at unimaginable resolutions on my modern machine!

One of the more exciting things is that as long as I do a print setup first, I can actually print on a new printer from MS Word 2.0c!

You can download it from the releases page here:

STUDS from Microsoft .
(Video in MPEG-1/Audio MPEG-2 care of JSMpeg).

I had this ages ago, although I couldn't remember if the NT 3.5 SDK/DDK had shown up at this point, but it's only the Japanese version in this set.  Since I'm having such a PITA in tracking down a 3.5 set, and I'm not sitting on this, I may as well archive it.

So you too can find the early Video for Windows, and all kinds of other things from the mid '90's on archive.org.

Or Wallpapers like this 'puppy' from the Japanese version of Windows 3.1

https://archive.org/details/MSDNOctober1994

At this time in history the big spreadsheet that defined the PC was 1-2-3 which took the spreadsheet mantle away from the CP/M spreadsheet who in turn took it away from the progenitor VisiCalc on the Apple II.  And this was the chance to define the new spreadsheet for a whole new platform.  

Excel started out on the Macintosh, but with version 2 it was time to come to the PC for the new and exciting Windows 2 platoform.  And to get people to try it out the key was free working demos.

I thought it was interesting that it comes with a demo showing off the ability to take data from several spreadsheets and make a 3rd with data.  Oh what an exciting world 1989 was!

Oddly enough I couldn’t directly import text (csv) data into XL, but I could use Excel 3 to create a version 2 xls with my current top blog stats and then create some graphs.

So first, here is from the blog stats package wp-statistics:

And there we go in Excel 2.  Since I have Excel 3, here is it running under WineVDM on Windows 10:

Obviously the higer resolution helps for moving stuff around.  And the legend doesn’t resize in either, but in Excel 3’s larger display it and move stuff around.

Needless to say this stuff is down right primative in 2018, but it’s always fun to check out ‘professional’ tools from 30 years ago.

Unknown disk on Ebay…

I stumbled onto these three disks, seemingly out of place in history.  Windows/386 version 2.0 is a strange one in that it shipped to OEM’s in late 1987, making it & Xenix part of the initial 386 wave of Operating Systems/Environments and beating out not only the OS/2 launch in 1988, but taking advantage of the 80386’s v86 mode, something that OS/2 wouldn’t be able to do in a shipping product until 1992. 

This version itself appears to be a retail version of Windows/386 lacking any clear OEM identification that was so prevalent for the era.  Indeed setting it up it offers a few interesting platforms:

Getting this to run was a little bit of a challenge as much as I prefer Qemu, these older 2.0x versions of Windows/386 have a BIOS/disk incompatibility with the hypervisor resulting in errors reading the hard disk.  Although PCem/86Box have no such issues.  I think it’ll run off floppy/CD-ROM/Network without any issue though.

Once installed it reveals itself to be version 2.03 of all things.  While I was hoping for some kind of retail version of 2.00/2.01 this appears as close as it may get as it has more in common with the PCjs version of 2.01 (which you can try live on his site!)

The PCjs version of 2.03 has 138 setup files (not counting the PIFs), compared to the eBay’s 141, while the PCjs 2.01 has 59 files.

That said, well it’s Windows/386 mostly from 1987 with slightly updated EGA/CGA VMM drivers from early 1988 that just didn’t quite make the cut.  To me what is confusing, is that it identifies as 2.03 while it’s closer to 2.01 in file count and functionality, unlike 2.03 it really ought to have been a 2.02, if there even was such a thing.

Otherwise it’s really not all that interesting short of the timestamp.  It’ll run on CGA/EGA *IF* you have the proper adapter in place, although VGA is compatible, the environment will detect that it’s not actually the proper card and refuse to run.  I tried to put in the 2.01 CGA/EGA drivers, but that resulted in an OS version mismatch (I didn’t check if 2.01 was locked to the Compaq OEM of MS-DOS)

I installed the infamous pair Word & Excel.  Despite Word 1.1a demanding at least Windows 2.11, it appears to run okay.  Excel 2.1d loaded without complaining.  There isn’t very much conventional memory for either, but they both can use expanded memory, which the hypervisor can create and share out without any emm386 or any equivalent driver.  I can only imagine the incompatibles of trying to balance these drivers at the time, and how much the coming DPMI specification was needed.

And as the old saying goes the three top problems in Windows version 2 is memory, memory and memory.  Trying to run anything graphical will exhaust conventional RAM, forcing you to single task anything graphical which kind of defeats the whole point of Windows.  You go from this:

To this:

Oh well it’s 1987, and users were kind of used to being disappointed as such.  It’s really no wonder why Windows 3.0 became the smash it it was.

And of course you can't talk about Windows/386 without this gem. (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).