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
It’s 1995 and OS/2 is *not* the dominant workstation. No one then, or ever, considered OS/2 a workstation at all, let alone the dominant one. We all knew then knew OS/2 was nothing other than the last gasp and hope of a dying dynasty – (IBM) The “dominant” workstation of the time was probably a Sun, SGI, HP, Tektronics or maybe a DEC workstation. Ironically that within 10 years all those actual workstations were gone, replaced by Linux.
And by then, no one even remembered OS/2.
Well where I worked it was the dominant one. Well over 15,000 seats in my region alone.
I’m sure world wide we had at least 50k seats in the call centres alone.
Agreed. Many places ran OS/2 that were IBM shops. Big insurance companies etc. Heck quite a few banks had ATMs that ran OS/2
I moved a OS/2 Lanman system over to WinNT in the early 90s, and upgrading win 3.11 clients over to Win95 when required.
ATMs were running Warp up until at least the mid-aughts, going by my experience in banking at the time. Most are probably decomissioned by now but I know smaller banks still had them in service to the early 201xs.
In Spain, Caixa bank and other entities uses os/2 Warp in all country until early 2000s
Nice article! The memory limit you describe for WINMEM32 does appear to be an inherent limitation that never got updated; see old KB article Q73677.
https://jeffpar.github.io/kbarchive/kb/073/Q73677/
Perfect that makes total sense! I thought it was funny the more RAM I gave it the quicker it failed, like it didn’t even try.
I guess the next experiment is to see if each console has it’s own address space, or if it’s a system shared pool.
If it’s not hard to reproduce it, I will give it a shot on QEMU and try to fix it. Were you using KVM or dynamic recompilation
dynamic recompilation quite a few versions I tried from 0.8 to 8.something.. and lots inbetween.
dosbox-bow.7z, this is the files from dosbox (which does run it), you can just unzip this into a bootable dos disk and pretty much run & gun.
cute logo for an interesting product, didn’t now the bsd lil devil was already around in the 95
BOW’s limitations, especially in memory allocation and GCC compiler quirks, reflect the fundamental constraints and ingenuity in early Unix-Windows integrations. It’s restricted to a maximum of 16 MB memory due to WINMEM32, and its GCC C compiler can’t handle C++ style comments. These challenges highlight the resourcefulness in early cross-platform development. I’m wondering how BOW would handle more complex memory-intensive applications, given these limitations?
GCC can always be rebuilt to include C++ comment styles in the C compiler, so that’s not so bad. The 16MB barrier however is something that cant be immediately fixed. I did like how they tagged the system note that they MAY address it in the future, which they obviously didnt. Although if it’d been marketed in the west, and found an audience, maybe the services could have been migrated to win32.