BSD on Windows: Things I wish I knew existed

Posted on December 8, 2023 by neozeed

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

Don’t waste money on a math coprocessor they said;

Posted on November 12, 2023 by neozeed

You don’t need it they said!

Well it’s been no secret, but OS/2 6.123 on my PS/2 model 80, is insanely unstable running simple MS-DOS based games (large EXE’s)

And almost always I’d get this fun error:

SYS0037: The system cannot write to the write-protected c: drive.

Followed by a crash trying to execute code at the top of the memory MAP (ABIOS?)

Then ending the program will just crash OS/2. Very annoying!

My goto test of v86 mode environments is an old game that I enjoyed as a kid, 1988’s BattleTech the Crescent Hawks inception.

It’s a great game, that runs on many 8-bit/16-bit systems of the era, and is surprisingly a very well behaved MS-DOS game. I mean if Windows/386 VGA machines can run it in a window using the CGA version, surely a super early OS/2 2.0 beta (6.123) can run it, right? However I found 6.123 to be incredibly unstable, and sadly not up to the task.

I tried to launch BattleTech over and over and had zero success. I couldn’t figure out why it was struggling on my model 80 board, where it runs just great on 86Box. What is going on?

One thing I had stumbled upon was that if I launched an ancient Infocom game in a DOS box, and then launched BattleTech it had a much higher chance of running. But this did not always equate to it working. How is launching an old COM file from the early 80’s excise the ‘devil’ of some 1988 EXE from running?

I wasn’t sure but I had this weird suspicion that it was that my system was lacking a math coprocessor. When I had the model 60 286 board in the PS/2 case I did spring for an 80287, and one thing I found is that OS/2 1.0 & 1.21 ran great. As a matter of fact I think it ran better than when I used to have a 386sx-16 and then later a 486SX-20. Now it’s been closer to 30 years, so I could have an absolutely false memory of all this, but I wasn’t sure I was onto something. So while shopping around a subscriber offered me a math coprocessor as they seem to be insanely expensive in the UK. I have no idea why the 80287 was so cheap, and no idea how to make any kind of adapter, but pJok was able to score one for super cheap in his homeland and send it to the barren wastelands of Scotland. As I was wrapping up the SSD G5 fun, the coprocessor arrived, and it was time to install it!

Note the purple 80386! It’s what we might call foreshadowing

The PS/2 8580 motherboard is really oddly designed with chip orientation going in every which other direction, and the 80387 socket isn’t keyed by pin, so it’s vital to see the notches on the silkscreen. Otherwise I just used compressed air to blow out the socket, and run the reference disk to add the processor.

The processor was instantly picked up, although I had the crashing issue with the BocaRAM/2 memory card again, which meant I had to remove the RAM card, re-configure with the math coprocessor, then add the RAM card, reconfigure, then run the util to patch the CMOS so it’d boot up. I really dislike this RAM card, but 32bit cards cost far more than this entire endeavor cost so I’m pretty much stuck with it.

Now let’s compare the Landmark scores between the 286/287 and the 386/ITT387

Landmark System Speed Test with the PS/2 model 60 80286/80287

And now the 386:

Landmark System Speed Test with the PS/2 model 80 80386/ITT 80387

The ITT processor is significantly faster than the old 80287, which is pretty amazing. The system bus is running at 16Mhz, although being 32bit vs 16bit yielding a nearly 2x in performance, although the ITT co-processor is so much more efficient.

Booting back into OS/2 6.123, and yeah now it just works! No fussing around, everything is just great.

I’m kind of lost too, as none of this should require the maths coprocessor, but the results speak for themselves. I used to wonder once I got some disk images for this ancient version of OS/2, why didn’t they ship it? Sure that insane fight with Microsoft on refusing something like Windows on OS/2, or even WLO like Windows IN OS/2 from being part of the product killed any hope of running apps, but this version of OS/2 is already caught in the trap that it can run MS-DOS so well, despite DPMI not being a thing right now.

As I’d mentioned it does run just fine in 86Box, so what is the deal? Well that lead me to look back at when it did crash I noticed an odd string 038600b1

So what does this mean? Well looking back at the CPU let’s try to decode some of it

First, it’s an A80386-16, which really isn’t that hard to figure out it’s a 16Mhz rated 80386. Next is the revision level, S40344. Searching around we can find this table:

S40276 - A1 (but probably 12 MHz as S40277 is 12 MHz)
S40334 - A2
S40336 - B0
S40337 is B0 stepping
S40343 - B1
S40344 is B1 stepping
S40362 - B1 (20 MHz)

So this places it at at the tail end of the introductory line of 386 processors. Checking over at pcjs, we find that there were quite a few more revisions to the 386.

And further that the B1 Errata is actually quite substantial. Maybe this is why the 386 had such a poor reputation for Unix ports in the day, and why it was shunned by CSRG?

As mentioned in the infamous 32bit multiply bug, this processor had been tested and was given the ΣΣ mark of approval. There are numerous issues listed with the presence of a math coprocessor, I have to wonder if beyond issues for using the full 32bit datapath, if there were some electrical issues with utilizing the full datapath as well? Much like an improperly terminated SCSI bus, did the simple presence of the ITT 387 help with signaling and improve system stability? Or am I hitting some weird bug in 32bit math that is simulated due to the lack of a coprocessor, that once one is in the system, the operation is performed on hardware, sidestepping the entire issue? I’m neither an EE or any good at reversing code, so I really don’t know.

The date code 751 does mean that this processor was manufactured in the 51st week of 1987.

Looking at how ancient this CPU is, I have opted to order one that was made in 1990, an SX218 or D1 stepping.

Although it hasn’t arrived yet, I have to wonder if it would make a really big difference in 32bit system stability? I have to wonder if there was such a massive delay in OS/2 2.0 because of the early 386 processors having so many defects that it just added an undue burden to the development, along with the fighting between IBM & Microsoft. While it would be interesting to see the difference between any of the Microsoft versions of OS/2 2.0, none have surfaced as of yet. Which is a shame.

Although it is nice to have this ‘mid’ IBM beta of OS/2, it does suffer from the ever so common issue of not being able to run any shipping 32bit executable, so unless you have source/object files to link, you are pretty much out of luck. The Microsoft Beta 2 tools are 16bit, so thankfully they run on pretty much any version of OS/2, and they ought to be able to run under Phar Lap 286 as well.

One thing that did recently surface on eBay, is a Microsoft tee shirt from their OS/2 2.0 group. With a minor bit of sleuthing, the Enterprise is from the 1989 ‘hit’ Star Trek V. Maybe I’m too much of a nerd to have recognized the GIF.

Back some 20+ years ago when I lived in Miami, I did have a loaded out PS/2 model 80 back then, and I ran AIX on it, as I thought it was really cool. But it was also incredibly unstable. I have to wonder now if it was a fault of the processor, or the system? Then again back then I had 6 registered IP’s and of course my PS/2 was on the internet! Although it was also the right height to double as a standing mouse pad.

So I guess this potentially leaves us with some painful lesson that you ought to get the math coprocessor for older systems if you plan on running anything other than DOS/Windows with a DOS extender. While I do have a PS/2 version of Xenix, I haven’t been able to dump them yet as my Power Mac doesn’t like NON FAT disks. One thing is for sure, it made a massive difference in OS/2. I don’t think 16Mhz/6MB of RAM is anywhere near enough to run OS/2 2.00 at any decent speed so I’ll stick with the much lighter 6.123.

32bits of disappointment, upgrading the IBM PS/2 model 60

Posted on October 27, 2023 by neozeed

While I had enjoyed this fully loaded 286, it was getting a bit annoying with all the 32bit limitations I was running into. Frontier Elite was a 32bit program, Obviously no WIndows/386 nor any DooM. It seems that most of the MS-DOS fun I had really was 32bit only. So with this PS/2 model 60, I did the only real thing I could do:

I swapped the motherboard with a PS/2 model 80 board. I had seen this on eBay for a bit of an excessive price, offered 40% of said price, and woke up to having shockingly won the bid. Of course it also means that I need special 32bit RAM to boot the board, because “IBM”.

I picked up 2 of these 1MB modules, they are 3 chip much like the SIMMS I had used on the PS/2 model 60 motherboard. So these are no doubt parity 256k in each row, and 2 cards giving it 2MB of RAM right off the bat. I got lucky to find these 2 cards in country and at a really reasonable rate, when compared to all the others. They did make 4MB & 8MB cards, but naturally they are incredibly expensive.

Luckily for me the board & RAM worked (the board was listed as working), and running setup from the gotek was painless. However for the heck of it, I put in the Boca RAM/2 board to see if it works. It does. It also does the same thing where once the Boca RAM/2 board is configured the setup program only crashes on running it, meaning I need to disconnect the battery backed RAM.

I thought I could avoid setting up the RAM card, but oddly enough until I did so it would not initialize the SCSI card. Oh, sure it showed up in the setup program, saw all my disks and everything, but it would not boot or show up from a boot disk.

So now let’s re-visit the painful world of SCSI disks. I had bought one SCSI controller, and tore some pads off for being impatient, bought another and had it working fine with the approved cable, crashed the PS/2 MCA SCSI market, and then bought the caching faster controller card, to only reveal that it is in fact slower than the stupid card.

But it’s a 32bit card!

And now I have 32bit slots and a 32bit processor! Surely it’s going to ROCK!!!!….?

It’s 0.3% faster.

What the actual FUCK. I mean ok BlueSCSI is great, and we’ve seen it perform faster with the ‘stupid’ card. I can’t imagine paying the $999 MSRP of this faster caching card to find out its slower. Nor the massive upgrade cost of going 32bit to find out its only slightly faster.

Wow.

Just Wow.

LANDMARK 6.00

That said, v86 mode is really cool!

My goto test for v86 is BattleTech the crescent hawk’s inception. I mean if Windows/386 can run this, everything else should be able to. And yeah, 16Mhz is almost enough to run this in a window. It screen tears like crazy and is just slow. But at least it runs!

Warning beeper music!

Although football was capable of doing this full screen in 1987, and Windows/386 could run it in a window in 1987 as well, it wasn’t until 1989/90 that OS/2 could with the much delayed 32bit version. Of course, the divorce happened after Windows 3.0 became such a massive seller, and OS/2 was delayed. again. While I had no issues under 86Box, I had plenty of weird issues on real hardware that seem to magically sort themselves out by running Infocom’s Planetfall first. I don’t know why either.

16Mhz Wing Commander

And luckily there is some difference in running at 16Mhz. Although I haven’t tried EMM386 on/off yet. The 286 had it’s excuse of copying pages in & out of protected mode, and the switch time being so horrific. But the 386 should be instant, only limited by it’s slow bus and I guess 4MB of slow RAM.

But what about DooM?

DooM v1.1 low resolution not quite postage stamp sized

Yes DooM v1.1 runs! I’ll have to try some Fast DooM later to see how much faster it can be! I’d like to think itll be faster but I am not holding out much hope.

Many of the bench stuff I had setup on the 286 to compare to the 386 sadly depend on a math processor. The problem of course is that 80287’s are very cheap for some reason. 80387’s however are not.

And the majority of them look like this. I don’t know how on earth people have hundreds of 80287’s to sell at super cheap prices, but 80387’s all seem to have been trampled, or had their inner core’s turned into slag. I will keep a lookout, although knowing my luck it may be cheaper to find another motherboard with a 386/387 paring.

Speaking of OS/2 and weird crashes, I got this fun one from OS/2 trying to run sysinfo:

While I’d seen plenty of trapcodes in my time, but I know less than nothing about reading them. Maybe it’s burred in there somewhere. The one odd thing was the 038600b1 part… Since the 386 is a 16Mhz part, maybe it’s a crazy old version? While it does have the ΣΣ mark, maybe there is other troublesome 386’s? I really don’t know. Or maybe OS/2 is just really more sensitive to having 2MB 32bit RAM + 4MB 16bit RAM.

Way back in the old times, I had upgraded from a 12Mhz 286 to a 16Mhz 286, and life was great, although I left out of all the 32bit personal computer revolution. After a lot of hard work, I managed to secure a 386sx 16Mhz board with 4MB of RAM. It was awesome although yeah SLOW. Clock for clock, task for task the 386sx was at best the same speed. Sometimes I’d swear the 286 was faster. A few months later though I made the insane trade of some complete in box Infocom games, along with cash and was able to score a 386DX 16Mhz, along with 4MB of 32bit RAM on some massive board. Surely this was going to be great right? I found pretty much the same thing there was no perceivable difference at all. At least back then it was 1992? and the capacitor plague was still decades away, and you could just call the BBS of the motherboard vendor and download the disks if needed (I didn’t need to). It was, frankly, a big letdown after so much ’32/32 is far superior to 32/16′ and here we are again in the future and the SCSI card bears it out, that id basically didn’t matter.

I guess it really comes as no surprise that the 386 does everything the 286 can just better.

So, what have we learned? The PS/2 model 60/80 chassis is the exact same thing. The low clocked 386 chips are super unimpressive, no doubt the magic in the intel family really didn’t hit until the DX2/66 and beyond. Beta versions of software act weird, oh, and that the backup program from MS-DOS 5.00 can actually backup a dual booted OS/2 install & restore it just fine. That was a bigger surprise for me, as the great thing about the BlueSCSI i that I can have so many drives, so I made a backup of the C: OS drive and trashed it quite a bit. Not expecting anything, but yes, a restore actually worked.

Patching Touhou 6 (Embodiment of Scarlet Devil) to run on a 3dfx Voodoo 2

Posted on October 3, 2023 by neozeed

This is a guest post from spaztron64

One thing that’s been bugging me for years at this point is the ability to run Touhou 6 on my PC-9821 V166. For a good few years I’ve been stuck with nothing more than a Matrox Mystique graphics card in that thing, which can’t create a D3D6 HAL context for rendering the game’s 3D elements. In 2021 I snatched a 12MB 3dfx Voodoo 2, in hopes of being able to play more 3D games on that machine. There were two major problems….

1) The USBHID.SYS driver for PC-98 Windows 9x conflicts haaaard with Voodoo drivers. Moving the cursor around corrupts memory and makes the system unstable or kills the driver in mere seconds of use

2) None of the Touhou games support secondary Direct3D devices

For those not in the know in regards to the second issue, DirectX allows you to use multiple DDraw and D3D capable GPUs on one system. By default it’ll set the video card outputting a signal on the primary monitor as the primary DirectX device, the secondary output as secondary, and so on. Most people only used one monitor on their Win9x PC back in the day, hooked up to their 2D capable card. The Voodoo 1 and 2 aren’t meant to act as 2D video cards, yet they had to support D3D initialization somehow, so they presented themselves as non-primary DirectX devices, usually secondary, in hopes that game developers would allow the end user to select their 3D accelerator of choice.

This was standard practice at the tail end of the 1990s, but it was falling out of use at the turn of the millenium with the demise of 3dfx and the general lack of need for multiple graphics cards in one system for 3D gaming. This presented a problem, as games that technically could be played on a Voodoo 2… didn’t, as they could never be told to use it through normal means. Hacky solutions existed, like 3dfx’s unfinished, buggy attempt at a Voodoo 2 driver for Windows 2000 that allowed it to behave like a primary display adapter for general 2D and 3D use, but it’s notoriously unstable and isn’t possible to use on 9x. I’ve used this method before to play Touhou 6, Max Payne 1, GZDoom, GTA 3 and Vice City on the Voodoo 2 through Windows XP with mixed results.

Once I got an NEC bus mouse for use on my PC-98, I could finally use the Voodoo 2 on it without constant crashing. This got me interested in trying to get Touhou 6 to work on it, which lead me to a path of pure pain.

For starters, Touhou 6 is one of those games that only use primary DirectX devices, like the unsupported Mystique, so I had to somehow coax it into initializing the secondary device instead. My first approach to handling this was through direct binary patching. I didn’t know where to look for the init routines, so I asked 32th System for some heads up, and he pointed me to a rough location in process memory where the appropriate CreateDevice calls reside:

I then searched for the appropriate opcodes in the game binary, and patched all 6A 00 (push 0, A.K.A D3DADAPTER_DEFAULT) opcodes to be 6A 01 (push 1), forcing the game to init the secondary D3D device.

While this initially did in fact work, the approach ultimately sucked for two reasons.

1) Static binary patching only works for that specific binary, and doesn’t carry across different versions.

2) This requires manually patching every CreateDevice call, of which there are many in Touhou 6

It is at this point that I started sharing my progress with friends. jbit was quick to hop in and say “Why the fuck are you doing it this way? Just make a d3d8.dll wrapper DLL”. This was absolutely the smarter approach, I just didn’t know how to do it since I don’t know jack about DirectX programming. Fortunately, he handed me a little VS project he worked on called d3dcutter that, among other things, wrapped the CreateDevice function, which I promptly modified to always push 1 instead of 0 to the stack for the device selection parameter.

This solved the two patching problems, and I had something to show for starters:

Now, I’m sure you can tell that the performance is absolutely atrocious. This came as no surprise to me, as while the Voodoo can absolutely render the game at a full 60FPS most of the time, the dinky little Pentium MMX 166 struggles hard at doing triangle setup for the backgrounds every 16 milliseconds. Remember, 3dfx cards had no Hardware T&L, so the game has to fall back to Software T&L. I think the following wireframe screenshot will help illustrate the amount of work the CPU has to do every frame:

“Well, I’m in luck!”, one might think as they remember that older Touhou games support framerate division by 1/2 (30FPS) and 1/3 (20FPS) as options in custom.exe… There’s just one problem.

The game just… fails to initialize the D3D HAL on the Voodoo 2 in the frame divided modes. Why? Beats me, I still haven’t figured it out and likely never will. Just more ZUNcode bullshit I suppose.

I then figured out that framerate division is handled by a variable (that can be set even lower than 1/3, by the way) which could be set at runtime, even when the normal 60FPS mode is used. I suspected that the game uses a different initialization path for the two modes, so I once again tracked down opcodes that expect the variable to be set to 0 in process memory, this time with Cheat Engine, and patched them in the binary. Well guess fucking what, the game fails to initialize even when the regular init routines are modified to expect 30FPS or 20FPS frame division to be set.

This approach simply wasn’t going to work. so I went with trying to set the variable at runtime. Unfortunately, I had to go back to version specific patching once more for this, since there’s no way to wrap this functionality through DLL means. Additionally, while this wasn’t hard to do with the game running in windowed mode with Cheat Engine on the side on a modern system, it was basically impossible on a Voodoo 2 equipped machine, as the game ran in fullscreen and it wasn’t possible to restore the window after an Alt+Tab.

My final solution was to generate a trainer in Cheat Engine for version 1.02d of the game, as it’s the last one with a working logic speed limiter, that would forcibly set the frame divider variable at runtime with a hotkey:

This finally allowed me to play the game in 1/3 framerate mode on the Voodoo 2.
This allows the game to run at full logic speed most of the time, as the CPU now has 40 miliseconds per frame for triangle setup, however there’s something wrong with how the card handles buffer swaps in this mode of operation, leading to a very back-and-forth stuttery image that’s very unpleasant to look at.

Can we do better? Well yes! The game uses so-called STD scripts for certain stage-specific data setup, but also handling camera movement and geometry generation. Using Touhou Toolkit, I was able to unpack the appropriate DAT file, decompile all the STD scripts, remove all geometry commands, and recompile them for in-game use. As there are no more backgrounds to draw, there’s a trail effect left behind every frame, but thankfully custom.exe has an option to forcibly clear the back buffer every frame.

The end result? A nearly tripled framerate in 60FPS mode, recovered just by not drawing any 3D backgrounds. The game still lags when lots of bullets are on screen, but this doesn’t really come as a surprise.

Re-visiting VM/386

Posted on June 13, 2023 by neozeed

So years ago I had won an eBay auction for 3 disks:

But pretty much everything I threw at it emulation wise came up with NOTHING but green bars when trying to enter a virtual machine. I’d always thought it was a video ROM thing but VGA type ROM I put in Qemu it’s always the same thing, green jail bars.

However, I tried it again on 86box, and YES it runs!

You can see VMs running, where they are in memory and all that other fun stuff.

And even better you can run graphical PC programs on your advanced 80386, and seamlessly multitask them all, using the hotkey ALT+PRINTSCREEN to toggle between them all. Surprisingly creating and terminating VMs didn’t really mess with overall system stability. I have to imagine that had this program had a 32bit API, it would have killed OS/2 before it ever got a chance. Considering that version 1.2 is from 1988 there very well could have been a larger possibility.

It does have the ability for individual profiles to specify RAM or even where or how to boot, it has disk drivers for sharing of files (think file locking). It also has the ability to boot from floppy, or even ROM!

Indeed there is a rather good review from PC Magazine: January 1988, that goes into many features, and compares it to other contemporary multitaskers of the era.

The one big drawback is there is no data exchange facilities. The one thing that Windows/386 had bridging the gap between MS-DOS & Windows applications.

So many products like VM/386 ended up finding their niche’s in attaching dumb terminals, and turning 386 classed machines into ‘micro mini’s’ witthout the power of Unix. It’s even out of this environment Citrix was born.

But there was so much potential here to be something so much larger, but sadly that was not to come. Perhaps 1988 was just a little too early in the sense of GNU GCC/GAS/LD and some Xenix COFF help. The world would have been a lot more stranger had Microsoft lost that second vital platform war.

Anyone crazy enough to want to try it in 86box, I uploaded my images on archive.org.

Citrix South Beach: aka the missing link from text to graphics

Posted on August 5, 2021 by neozeed

A long long time ago, in a distant continent I once interviewed at this small company called Citrix. It was some QA position, they didn’t need programmers. I’d passed the interviews easily as I’d been programming serial TSR’s so I was hip to the 8250/16450. Citrix was an interesting but troubled company. They had incredible contacts and more importantly a deal from Microsoft that gave them access to OS/2. Sadly OS/2 1.0 had been a dud, and by the time OS/2 2.00 saw even a limited release, Microsoft had pulled out of OS/2. Citrix was a company that had lost twice in what should be a big market. -Multi user commodity systems.

Citrix Multiuser 1.0 was based on OS/2 1.21, and was limited to 16bit protected mode apps. Citrix Multiuser 2.0 was based on the Limited Availability version which means that it cannot run “GA” or General Availability programs. So no 32bit programs here. Instead it can run the same 16bit protected mode applications, however it can also run MS-DOS based programs. DOS4/GW programs run so oddly enough the only real commercial stuff that can be run is MS-DOS.

So here we were 1994. Citrix had struck out twice, but this time it was going to be different, but the deal had to be re-struck again. I have no idea how they managed to secure this lucrative deal again, but Citrix was able to get access to the source access Windows NT, after the 3.1 release to 3rd parties (when they got DEC involved). By now the world had gone Windows, Office 4.2 was a thing, and on the high end side, NT had SQL & SNA, and there was most defiantly a market for multiuser systems as there had been from the old days of Unix, with the old mix of ASCII and network graphical terminals.

The CD looks like a normal-ish NT 3.5 Server CD although there is no MIPS or Alpha builds, as expected everyone at Citrix would be working and targeting the larger established i386 market.

As you can see this is Beta build 101.

In the text mode setup it looks like a normal setup program. No doubt they had better things to do than skins, wallpapers and themes. HOWEVER there is a silent IDE bug that many people will no doubt run into:

Although it works okay in short bursts, the IDE driver will send a command 28 zero byte and then shut down the controller. From this point it hangs. So that means we either need to generate all the floppy disk images (not going to happen!) or do the MS-DOS cross install. Yeah I’m doing that instead.

When setting up under Qemu, use the AMD PCNET card. It’s much easier. I set it to Twisted Pair, and PCI bus. I’m not sure if those matter all that much, but it works for me!

If you are going to use Hyper-V, you’ll need the GF100 NIC driver, but use the Windows NT 3.1 driver, as this is technically a beta of NT 3.5 and the production 3.5 driver will blue screen.

I set the driver to autosense.

I also had both Qemu and Hyper-V bluescreen when doing DHCP. I don’t know what the issue is, and I’m too old to care as I don’t have source code to South Beach, and even if I did I’d probably regret posting fixes. So static IP address it is!

Ready to login

Honestly again the air in the office when I was there is that everyone was running around like crazy to QA the product, and get ready to expand client support. While I was too much of an OS/2 fan boy, they certainly knew that from now on everything was going to be about Windows NT.

Logging into the Citrix the first fun thing to do is to define some remote terminals, using the WinStation app.

The first interesting thing is that async terminals are supported. Along with using either NetBIOS or Winsock protocols for connecting clients. Isn’t that great! TCP/IP built in!

Now for the crazy part. The only client that works is MS-DOS based. Yes there is no Win16, no Win32, no Java, no protected mode DOS, no Linux, SunOS, Solaris, DG/UX, AIX, HPUX, Xenix, UnixWare or SYSV i386ABI. ONLY Real Mode MS-DOS. Despite the connections being able to be ICA version 2 or 3, they are incompatible with newer Windows based clients from Win Frame.

This it the following list of supported protocols. Although I had Novell Lan WorkPlace and used it before for Desqview X, I can’t find it at the moment. good luck finding FTP TCP/IP, in retrospect it’s a terrible name, and for all intents and purposes it’s disappeared from the earth. So that leaves Microsoft TCP/IP. Now all the LANMAN clients have it, although this isn’t what it wants. It wants the MSCLIENT found in the “\CLIENTS\MSCLIENT\NETSETUP” path from a retail version of NT Server 3.5

The DOS client is.. very touchy. Deleting profiles can lead to a corrupted profile. Altering existing profiles well yeah can lead to a corrupted profile. I thought it was EMM386 causing issues but it locks up on it’s own.

Revenge of text mode UI

One interesting thing I found is that the text mode UI didn’t die. It’s still very much alive. As mentioned above you can connect async terminals, or even connect over the network!

Text mode does bring up a Program Manage analogue, but all my programs are graphical so it’s kind of moot. But rest assured text mode stuff works great.

So 32bit Fortran stuff works great, what about MS-DOS?

Here is MS-DOS / Qbasic editor. Running on Citrix South Beach! Great, what about OS/2?

And here we go running the f2c translator through Dungeon to get an OS/2 text mode app. As you can see forcedos reveals that this isn’t a bound executable, instead it only runs on the OS/2 subsystem.

As you can see the os2.exe/os2srv components of the OS/2 subsystem

And of course it looks better on the graphical client to mix and match them all.

Indeed Word & Excel for NT work great alongside everything else.

Obviously somewhere post South Beach the text mode stuff dropped off. I’ll have have to dig for more, but it’s kind of neat the idea of a real text mode NT. Sadly South Beach doesn’t seem to like VMware. I haven’t dug too far, as I like WSLv2 so I’m stuck with Hyper-V. It may work fine on ESX I haven’t tested. Obviously you need the appropriate drivers, ill try to update links later, if anyone cares.

No doubt that finally Citrix was no positioned to realize the dream of multiuser commodity based hardware along with commodity applications. Of course it wouldn’t be all sunshine and rainbows, and no doubt there was a toll needing to be paid between Windows NT 4.0 and on the way to Windows 2000. But back in 1994, things were looking good!

Conventional RAM aka that old foe

Posted on August 3, 2021 by neozeed

640K ought to be enough for anyone. Well I’ve been poking around with an old beta that I had a long long time ago, lost, found, lost again, recovered, lost and found while looking for something entirely different again. I’ll spoil it later but anyways while messing around I needed a MS-DOS client, and it needs the MSNET TCP/IP stack, not to be confused with the LANMAN TCP/IP stack, and it doesn’t work with the Windows for Workgroups stack either. So yes I setup all 3, and of course found out that it really was the worst of the 3, the MSNET one.

Anyways convential memory is below 1MB. Back when the PC was new, it seemed that going from an Intel 8080 processor that could addresses a mere 64kb of RAM to the IBM PC that could address a whopping 1MB it seemed unlimited. A decision was made to segment the machine into 640kb for user programs reserving 384kb of RAM for hardware.

And then something happened where drivers became user programs, and suddenly loading a mouse driver, CD-ROM driver, audio driver, networking stack and you have not enough memory available. Welcome to the living hell that was 1988-1995. In this virtual machine although it has 64MB of RAM in MS-DOS the largest free space with everything loaded is 366KB.

Microsoft Windows and DOS (among other products) started to include this fun tool MSD, Microsoft Diagnostics that would let you explore your memory, to see what was actually in use.

Imagine the absolute frustration here. 64MB of RAM, and yet there isn’t enough free to run a simple program. HOW ANNOYING!!!

Looking back at the MSD memory map, you may noticed from the map there is memory available, and possibly available. What does that mean? It means that there is no ROMS, or device RAM in use currently using that hardware reserved memory. Sadly for the 8088/80286 users they either don’t have a MMU, or one that only really works for protected mode segmentation. The 80386 however had a MMU sophisticated enough to let you map whatever you wanted where by booting MS-DOS into a protected mode environment and using v86 mode to map whatever you wanted where, by using the included program emm386.exe I’m sure plenty of others have touched on this program, and I’m going to just make a quick glance at it.

If you look at a typical PC memory map you’ll find that location A000-AFFF is actually reserved for graphics memory. Since we are using VGA that also means B000-B7FF is also available. that means for text mode programs we can open up all this RAM for smaller program & driver use, along with the memory after the VGA BIOS, until the ROM BIOS of the computer that’s CC00-CFFF in my case, with D000-DFFF and E000-EFFF also being open. Obviously the fun comes in that not every PC has the same peripherals ROMS installed so this isn’t guaranteed to work in every instance.

In my case I don’t need EMS emulation at all I want to map it all to UMB or upper memory blocks for drivers and TSR’s. So I load emm386.exe into the config.sys like this:

DEVICE=C:\DOS\EMM386.EXE NOEMS I=B000-B7FF I=D000-DFFF I=CC00-CFFF I=D000-DFFF I=E000-EFFF

I didn’t put in any exclusionary ranges as EMM386 figured it out all on it’s own in MSD, but you may need to specify ranges to leave alone.

This gives me 519KB of free conventional RAM. Oddly enough a lot of the networking stack moved itself into UMB without me having to do anything. It’s probably more so a function of the MSNET I used from a Windows NT 3.5 Server CD-ROM being dated 1994, so I didn’t have to play with the load high command.

Back when the PCem forum was up I had this config, although keeping in mind that although it was far more aggressive!

DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE 4096 frame=d000 x=a000-afff i=b000-b7ff x=b800-bbff x=c000-c7ff i=c800-cfff i=e000-efff ram
DEVICEHIGH=C:\DOS\CD1.SYS /D:CDROM01
DEVICEHIGH=C:\DOS\SETVER.EXE
DEVICEHIGH=C:\DOS\ANSI.SYS
DOS=HIGH,UMB
FILES=40

@ECHO OFF
PROMPT $p$g
PATH C:\DOS;c:\windows
SET TEMP=C:\TEMP
LH MSCDEX /D:CDROM01
LH SMARTDRV
LH IDLE
LH DOSKEY
LH SHARE

This got me a whopping 619Kb free in MS-DOS, along with 4MB of EMS, and 12MB XMS (on a 16MB config).

In the spirit of the old ‘Linking the linker‘ (I’m not certain that this is the actual article but it does certainly read the same way, didn’t Tim have 2 blogs?), I went ahead and claimed the video memory for the heck of it.

Using range A000-AFFF (64KB EGA/VGA Graphics RAM)

Obviously you cannot run graphical programs, but 605kb of conventional RAM, wish some 206Kb worth of network drivers! Not bad. I could probably squeeze a 32kb EMS frame in there, and get what would be an incredible 1-2-3 machine for the era. But I’m not such a big Lotus 1-2-3 fan anymore.

As always it’s 2021, and normal people will glance and WTF, you have 64MB of ram how can you be fighting for kilobytes. Anyone that used MS-DOS based networking will cringe and look the other way. These were not happy times.

In other news the client ran, sadly it’s too new for the server.

FreeDOS running Windows 3.1

Posted on July 27, 2021 by neozeed

Yes, really it’s FreeDOS running Windows 386 Enhanced mode. For real.

perditionc posted this over on the freedos list:

Hello everyone,

So it took me a bit longer than I planned, but below is the
information needed to reproduce and links to sources.  (Be kind, I
know that the code needs more work.)

To see it in action, from installing FreeDOS & Windows to running I
posted an updated the video (about 4 minutes, sped up some stuff and
cut some scenes down but its originally a single recording from first
boot until the end)

Steps:
download boot disk - http://server2.fdos.org/tests/fdos2043w.img
contains:
    kernel *** requires patches, see below for source
    command.com (FreeCOM)
    fdisk
    format
    sys
    share
    edit

have available Windows 3.1 install media (*** not provided ***)

create a virtual machine (or have a compatible real computer)
example has a 200MB hard drive with 32MB of memory and otherwise
virtual box's Win 3.1 default settings.

boot FreeDOS floppy
fdisk
    create a primary partition, don't use FAT32, use all available
space, ensure active
reboot so kernel see new partition
format
    format the C: drive and set label as desired
fdisk /MBR
    install master boot record so hard drive is bootable
sys C:
    install system boot record and files to C: partition
    copies kernel.sys and command.com to C:
copy share.com c:
copy EDIT.* C:
    so have available after install Windows
Optional: take out (disconnect virtual) floppy from drive and reboot,
ensure hard drive boots
Optional: create a CONFIG.SYS and AUTOEXEC.BAT so not prompted with
date and time
Install Windows
    put in first Windows floppy and run SETUP
    follow prompts until complete, allow it to modify CONFIG.SYS and
AUTOEXEC.BAT
Optional: edit AUTOEXEC.BAT to load SHARE.COM
    (if you do not do this step, you must remember to do so before
starting Windows)
Edit C:\WINDOWS\SYSTEM.INI   (adjust based on actual installation and
editor of choice)
    find [386Enh] section, at bottom add line:
    InDOSPolling=TRUE
    save file
win
    start Windows, will be in Enhanced mode if supported

Source:
Kernel patches - http://server2.fdos.org/tests/kernel-win3-patch.diff
rest of sources (kernel, FreeCOM, format, fdisk, sys, share, edit) -
https://github.com/fdos

Credits:
Bart, Tom, and others who have improved the FreeDOS kernel to where it is today
All the other FreeDOS developers, especially for FreeCOM, FDISK,
FORMAT, and EDIT
And Eric who's original research helped with the initial
implementation of the necessary patches a decade ago
(https://web.archive.org/web/20061001224249/http://www.coli.uni-saarland.de/~eric/stuff/soft/specials/win3.x-dosext-freedos-notes.txt)

I will be working on improving the code, specifically the critical
section handling and hopefully remove the need for the InDOSPolling
flag being set as well.

Enjoy,
Jeremy

And sure enough I was able to reproduce Windows 3.1 from the binary. I haven’t looked at patching/building yet.

Turning off virtual memory let’s FreeDos run in a Window!

Even more amazing to me BattleTech 3025 can run CGA mode in a Window too!

I should add that VMWare player didn’t work, nor did later versions of Qemu either. I had much better luck with my mutated Qemu 0.90 fork thing. ISA Cirrus card for sure!

Being able to run Windows 3.1 in 386 Enhanced mode has been one of those holy grails of compatibility. It’s great to see this in action!

I should add that Windows/386 and Windows 3.0 don’t work. 386 needs some versioning set, and 3.0 is convinced that the memory is too fragmented or that C: is really A:. Also Win32s doesn’t work either, but still Sim City, Excel and Word run fine!

As a follow up, 3.11 for workgroups or not doesn’t work either.

UnixWare 1.0 on 86Box

Posted on December 6, 2020 by tenox

(This is a guest post by Antoni Sawicki aka Tenox)

I certainly can’t claim to be the first as this has already been done by our friends at OS/2 Museum. However with low vanilla VGA resolution and no networking the results were unsatisfactory. Having so much success with 86Box I decided to try to do a little better.

I bought my UnixWare 1.0 media kit years ago on eBay. Unlike the tape set owned by OS/2 Museum mine had CDROM as install media. Unfortunately despite many many tries with different types of cdrom/bus/ide/scsi card I could never get the OS to see it. The cdrom/iso image is just a typical set of sysv packages. As such I wanted to see if it would be possible to convert it to a set of floppy disk images and install this way. Attached the iso image in UnixWare 7.1.4 VM and did a pkgtrans like so:

pkgtrans -s cdrom1 diskette1

From there I created a bunch of floppy disk images, which I later used for installation. Thanks to Plamen I was also able to get TCP/IP disks which I added to the install set.

Update: thanks to ArtiomWin I also got a BusLogic HBA driver disk, which allowed me to see the cdrom attached over SCSI. As such I decided to remaster the original iso image with added TCP/IP set, Update package and bash+gzip. The iso image is here.

Upon first boot after install from CDROM you get prompted to choose a NIC driver:

Unfortunately none of them really worked in 86Box for some reason. They get detected and you can see the MAC Address but not much after that. 3C503 and NE2K freeze the system, WD works bit better but you can’t really communicate with anything. Maybe it’s just my PCap configuration.

After installation I mounted the cdrom again and added TCP/IP set:

mount -r -F cdfs /dev/cd0 /mnt pkgadd -d /mnt tcpnfs pkgadd -d /mnt update
cp bash gzip /bin

One of main issues bugging me was lack of proper resolution. UnixWare 1.0 has a high resolution mode for Tseng ET4000 card which is supported in 86Box. You can change the resolution using /usr/X/adm/setvgamode as root. It worked perfectly, except for fonts, which required some surgery in /usr/X/defaults/Xwinfont (remove everything after 75dpi font path). This is how it looks like fixed up:

UnixWare comes with Merge DOS emulator. It can even run graphical applications in windowed mode for CGA and HGC. VGA is only possible in full screen mode.

All this cool stuff before Linux was even born!

DOS Menu is invoked by Scroll Lock. You can switch consoles between text and X11 by pressing CTRL+ALT+SYSRQ and ‘p’. I have also added bash and gzip binaries.

The ready to run 86Box image is here. Virtual Box OVA here. Install media here. Login with user/user, root/root.

Have fun with Virtualization !

Dell Unix on 86Box

Posted on December 1, 2020 by tenox

(This is a guest post by Antoni Sawicki aka Tenox)

In a recent few virtualization projects, such as QNX 1.2 (and demo disk), Interactive Unix (also older post) and Caldera (and older post), I have tried the 86Box emulator. Unlike typical hypervisors, 86Box emulates a wide variety of video and network cards. Everything I tried simply worked out of the box, so instantly fell in love. 86Box is now my daily drive for running old PC operating systems. I have decided to revisit some of previously half assed virtualization attempts with the awesome new emulator.

I have virtualized Dell Unix back in 2012 using Bochs and QEMU. Even with the community support, we have struggled to get a decent video resolution and had to resort to use of SLIP for networking. Today let me reintroduce Dell Unix more properly! With 1024×768, 256 colors video and proper networking using emula NIC.

The journey started with allsoft.img which is an image of the OS and all packages installed from a tape on Bochs. I have disabled a few services in /etc/rc2.d namely mouse daemon (mse), sendmail, uucp, lp, etc.

For X Window I have edited /usr/lib/X11/Xconfig, enabled serial mouse (Microsoft) and 1024×768 mode. I have used Tseng ET4000AX VGA which is recognized by Xmach server. This allowed X / xinit to run correctly. However for startx to work you also need to edit /usr/lib/X11/xinit/xserverrc, as it seems to be using slightly different configuration. For graphical login you can add something like x:3:respawn:/usr/bin/X11/xdm -nodaemon to /etc/inittab. However I have noticed that when ran from init, xdm seem not to pick up the Dell customized config files. Perhaps rc startup script should be created instead.

As a final note on X, the system has virtual consoles. Like other SVR4 you access them by pressing SYSRQ and F keys. F1 is a text mode console, F2 is Xserver. This is my Dell Unix hero shot:

Networking was even easier. Dell Unix supports WD8003 and 3C503 NICs. Firstly I wanted to try the WD. In /etc/conf/pack.d/wdn/space.c you can find the predefined hardware probes. I have picked one of supported modes and the card was detected on subsequent reboot. That’s it. No need for kernel rebuild or any configuration. I have not tried 3C503 yet, but if you want the driver for it is named ie6. For TCP/IP configuration you set your IP address in /etc/hosts and gateway in /etc/inet/rc.inet file.

I was able to quickly compile Mosaic, which curiously had Makefile settings for Dell Unix. Took it for a spin on the web with help of WRP:

One could probably want to compile more recent version of Mosaic with PNG support or maybe some more recent browser all together.

The system comes with a bunch of open source software in /usr/dell, however suprisingly there is no bash or even gzip. I have compiled some essentials. They are available here and as a /usr/local tarball.

For the lazy, as usual you can get a complete os image for 86Box here. Make sure to attach pcap to your local network interface and set IP address / gateway / dns server accordingly.

If you port some cool software or find any interesting gems in Dell Unix please comment!

Have fun with virtualization!

Update: I been looking at contents of various distribution media for Dell Unix that have surfaced here and there. On a DAT tape I bought on eBay a few years back I found this file:

Whoa! Of course I want to install all of it! This is how FrameMaker 3.0 looks on Dell Unix:

I have updated the disk image for 86Box to have this included. You can run demo mode of FrameMaker by executing /usr/frame/bin/demomaker. I also imagine that this can be installed on pretty much any x86 SVR4 and above, maybe even Linux. If anyone has a license code / serial number please let me know!

Virtually Fun

Fun with Virtualization

Category Archives: 80386