FreeDOS running Windows 3.1

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!

Installing SCO Unix 4.2, part 3: LBA disks

This is a guest post by Friggigatto

In the previous post we managed to install a Compaq-branded version of SCO Open Desktop. One of the recommendations was to use a small hard drive and avoid LBA, since SCO Unix does not recognize it.

It turns out, however, that SLS UOD429A, the bootdisk + patch that we used in the first post of this series to install ODT, also adds LBA support (as found out on A.P. Lawrence’s excellent website).

Apart from enabling you to fully use larger disks (you can install on a disk larger than 2048 cylinders, as long as you set its size to 2048 cyls during installation; you are of course going to “waste” a lot of space), LBA is more convenient if you want to have a large root partition, since the root partition has to be entirely in the first 1024 cyls.

So of course I tried repeating the installation of the Compaq version by booting off UOD429A, inserting the N2 from SCO ODT, and… I quickly found out that it would not recognize the CD as a valid installation media. Annoying.

Eventually I found out that the N1 disk from Compaq has a ramdrive compressed in the kernel, from where the initial installation script is run, while the rest of the files (mostly installscript) are on the CD itself.

The fix was, in the end, relatively simple. All I needed to do was mounting the N2 floppy in the VM I had created before, copying “N2.Z” on my harddrive. I then uncompress-ed it, extracted it (it’s a regular tar file), and replaced the installation script with the one provided on Compaq’s CD. Then, the reverse process can be done: recreate the “N2” tar file, compress it, and copy it in the mounted N2 disk. If you don’t want to go through the same process again, you can download the patched disk.

The installation process is then simple: boot off UOD429A, insert the updated N2 disk when requested, and proceed with the rest of the installation as usual.

This way I managed to install SCO Unix on a TI TravelMate 6050, alongside DOS and Windows 95. It took a bit of trial and error (reading SCO technical support documents was, again, very helpful), but in the end this is more or less what I did:

  1. install Unix as LBA with a ~20mb DOS partition
  2. hide DOS partition & create a new one as primary active partition
  3. install Win95 on that
  4. install boot manager (I used Paragon’s Boot Magic) on first DOS partition (the hidden one)

Steps 1 and 2 were done in 86box, after creating a disk with the same cylinders, heads and sectors found in the BIOS of my TravelMate (using the LBA setting in the BIOS of both laptop and emulated machine, of course). After installing DOS and SCO Unix (I’m not sure anymore in which order), I copied the Win95 installation files on the new partition and finished the installation process on the laptop, after dd-ing the image to the CF card I’m using as hard drive.

After configuring Boot Magic (and creating a custom background and icon), now I’m greeted with this every time I boot up the laptop:

Since Windows 95 is installed in a FAT16 partition, I can mount it or access it via dosls/doscp inside SCO Unix too, which is convenient for sharing files (I tried installing a 3Com 3C589 PCMCIA card directly in Unix, since according to the docs it’s supported; unfortunately, the provided drivers only work with IBM PCMCIA controllers).

SCO Unix software

A large collection of ports for SCO Unix can be found at ftp.celestial.com, but it’s faster to use the ISO with all the ports I uploaded on archive.org.
To mount the CD with lowercase filenames, run #mount -rf HS /dev/cd0 /mnt

It’s worth noting that, before using the CD, we need to install it with mkdev cdrom (yes, even if we did install the whole system from a CD). In the process we will be asked whether we want a CD-ROM/TAPE device, which can be used to install more components for the system (CD-ROM/TAPE is the format used by the setup CD), and if we want to add to the kernel ISO9660 support, which of course we need. As usual, SCO documentation has a lot of information about this.

Gzip is included in the Celestial ports, but I also managed to compile an early version of bzip2 (here is the binary). If you compile it yourself use gcc, the code will be faster. The provided Makefile undefines __STDC__; gcc sets the flag and this creates problems at linking time, resulting in a call to a missing “__unlink” function.

Bonus content: recovery disks

In the process of getting more familiar with the installation process of SCO Unix, I realized I could benefit from having a set of spare bootdisks that would allow me to mount the hard drive and modify files at will (including after the first part of the installation process). So, I created them, using a ramdrive + compressed disk (similar to what SCO’s install process does, but also the boot floppy of Windows 98) to pack as many utilities as possible on a single disk.While I was at it, I did the same for Xenix 386.

Installing SCO Unix 4.2, part 2: the devsys

This is a guest post by Friggigatto

In the previous post we saw how to install SCO Unix 4.2 and SCO ODT on a virtual machine. Sadly, both distributions lack the development system, making them a very limited toy.

At some point I noticed that the filesize of the ISO of SCO ODT 3.0 branded by Compaq (found again on the Internet Archive or WinWorld) is way larger than the other available distributions: could it be that it includes the Development System as well? I decided to find out.

Inside the ISO we can find a N1.IMG file, and we can start the installation by booting from that.

At the serial request I discovered that this version is not the same as regular ODT, and thus the serials I had did not work. I tried extracting a to-be-serialized file from inside the CD.IMG file found on the ISO by opening it with a hex editor (the file is not in ISO9660 format; it’s specific to SCO and somewhat emulates a tape drive, with multiple tar files in it. Opening it with a hex editor, it’s easy to see where one of these tar files starts and ends), extracting it with tar, and running it through brandy to generate a new serial.

Brandy, however, generated the same serials/activation I had already, indicating that the validation mechanism used by the installer in this release is different. I was afraid it would be a Compaq-specific addition, thus almost unrecoverable, but after searching Usenet I found this post (mirror) which suggests that different versions of ODT have different generation mechanisms; in any case, the keys provided in the “OSE” (Open Server Enterprise) column work.

Anyway, after inserting the serial the installation proceeds smoothly, and we can even select to install the Development System:

The DevSys also requires a serial, and for that I used one found on the archive of Tenox. The installation started with the incredibly slow process of badtracking the hard disk (and I had selected the “quick” check!) and proceeded smoothly, until it tried to install the “Compaq EFS for SCO Unix”:

The error interrupts the installation scripts and leaves the system in a half-baked state: we can reboot from the HD and load the kernel, but instead of getting to a terminal or login prompt we are dropped in a broken installation script that won’t proceed.

To fix the issue, I opened up again the ISO with a hex editor and looked at the install script (/inst5/customize). The fix is easy: search for the string “cleanup $FAIL” inside the CD (line 238 of the customize script), and replace the initial “c” with a “#” to comment out the line entirely (a neater solution would be to change the script so that it won’t install the Compaq EFS in the first place; I tried to do that as well, but it didn’t work).
Since we are at it, we can also modify the params.stz file in the ISO and disable badtracking completely (search for badtrk_none) and speed up the next installation considerably.

Restarting the installation once again with the same settings will still give the error, but this time it won’t kill the installation script and it should now complete successfully (with some warning messages since it’s not an EISA machine).

After the reboot, we should be finally welcomed into “SCO Open Server (From Compaq) Enterprise System Release 3.0”.

We can now remove the whole Compaq EFS using custom, or just the UPS drivers /etc/rc.0d/*ups and /etc/rc2.d/*ups, in addition to /usr/bin/compaq. We can also apply the patch to the disk driver to run on faster machines, as mentioned in the previous post. Finally, we can install SCO supplements from SCO’s FTP, and in particular:

  • uod426d – Y2k fix;
  • uod374a – better CD support (you can run programs from ISO-9660 CDs, for example from early SCO Skunkware releases; you can also mount CDs forcing each name to lowercase, instead of the annoying default where everything is in uppercase);
  • net382e – better TCP/IP support.

Now we have a working SCO Unix 4.2 system with the development system! The good thing about SCO Unix is that the C compiler is more modern than the one provided by SCO Xenix, but can still target Xenix (with the -l2.3 directive). This means we can compile slightly more recent software for both systems, for example bash 1.13.5 and bzip2 0.1pl2.

Continued in Part 3!

Installing SCO Unix, part 1

This is a guest post by Friggigatto

I’ve been messing around with SCO Xenix for about 10 years now, and in the process I have been playing with OpenServer 5/6 as well (mostly as a mean to copying big/many files to a Xenix VM: I’d just create an ISO file, mount that in OpenServer, then share the Xenix HD with OSR5 and copy the files over); however, I never got around to use SCO Unix.

A while ago I decided to change this, but it took many tries to get to install everything, especially the Development System; so, when I eventually managed, I decided to do a writeup of what I did (and part of what stumbling blocks I encountered along the way).This is the “first episode”, which should give you enough info to install SCO OpenDesktop 3.0 as found on WinWorld or on archive.org, and the ODT Server 3.0 version from BetaArchive. ODT is nothing else than SCO Unix 4.2 bundled with X11 and TCP/IP (while on Xenix these are separate products).

Installing SCO ODT, floppy version

The secret to installing the 4.2 floppy version was to use the updated N1 boot diskette (SLS uod429a from SCO). Once you have it, the installation process is quite straightforward and self-documenting, especially if you are used to the slightly more convoluted Xenix install. This version can even be installed in VMWare.

The serial/activation is included in the release files; create a VM with an hard drive <2gb, during the setup process select “Floppy” as the install media, a “quick” bad track scan type and then simply confirm every step. You will be asked to insert all the disks in order, and the only challenge should be surviving the mind-numbing boredom of handling more than 40 floppies.
Unfortunately, the network and graphics card are not supported on VMWare (I suggest to boot the first time in single-user mode and disable the GUI from starting automatically with “scologin disable”), so it’s a good idea to install on 86box instead.

While we are at it, we can even spare ourselves some of the boredom by using the CD version instead.

Installing SCO ODT, CD version

For the ODT CD version, I looked up at what SCSI devices are supported (mostly by running ‘strings’ on the kernel inside the boot floppy image, looking at the device driver names and comparing them with those of OpenServer 6), and created a machine on the latest unstable 86box build (3.0.0.2983) like this:

  • i486-socket 2 and 3: [i420EX] ASUS-PVI-486AP4 (many other boards work as well, but faster CPUs/machines would give me issues… more on this later)
  • Intel i486SX 33mhz + 487SX
  • 32 Mb RAM
  • Serial Logitech mouse, 3buttons
  • Video: ISA16 Orchid Farenheit 1280 [note for the setup: the emulated bios is 2.0 – supports 1024×[email protected] colors]
  • SCSI controller: aha-154xA
    Address 0x330, IRQ 11, DMA 5
    Host ID 0
    BIOS C800H
  • SCSI cdrom
    Controller 0, ID 5
  • IDE hard drive, <2Gb, non-LBA (check the BIOS settings)
  • If you want Ethernet, use WD8013EBT (drivers are included)
    IRQ3 address 240

The OpenServer release I found on BetaArchive was missing the N2 disk, but the one from the floppy release works fine. The process is simple: boot from N1, the SCSI adapter should be recognized by the kernel (a line that starts with “%adapter” and then the IRQ settings etc.), and so should be the disk drive (%disk):

You can use the same serial as for the floppy release, but this time indicate “SCSI CD-ROM” as the install media, and it should install fine. You should however deselect the DOS Services, as Unix will crash after the first reboot while trying to install them.

Once the installation is complete and the system restarted, it will greet you with this very dramatic login screen (and ironic too: SCO and Open Systems in the same logo) and its pastel-colored UI:

Running on faster machines

The 33 mhz CPU is surely not a beast by today’s standards, and the emulated system feels sluggish enough also under ODT; however, switching to a faster CPU would crash the system. Luckily, SCO’s former support website (I created a mirror of the tech articles on archive.org) has a solution for this: we can modify a driver to avoid kernel panics on quick systems. After booting into single-user mode, we can run

# cd /etc/conf/pack.d/pit
# cp Driver.o Driver.orig
# _fst -w Driver.o
* spinwait+2D?w F989 FEE2
* $q
# cd /etc/conf/cf.d
# ./link_unix -y

Finally we can safely reboot, this time with a better CPU. The fastest machine I could test is a Socket 5 (i430NX Gigabyte GA-586IP) Pentium MMX Overdrive 200Mhz. When a faster system is selected (e.g. those based on Socket 7), the mouse stops registering the vertical axis.

In the next post, we’ll see how to install ODT with the development system.

EA pulls Syndicate from GOG

No it’s true!

Before all the Summer stuff ended I had intended on picking up Syndicate on GOG. I don’t know why I hadn’t just bought it earlier last month but here we are. I was thinking back then there was no rush, after all the game is crazy old. But then I looked this morning, and poof it’s gone.

The killer is that on archive.org you can see it was even on sale 8th of August. So who knew this was the last chance?

I guess this means EA is doing a new Syndicate? Or they are going to start making their own retro store? Or perhaps it’s some kind of legacy divesture? I’m on the outside, but looking in something interesting happend to a much older EA published game, M.U.L.E.

Back when M.U.L.E. was published it came in this fancy almost ‘single’ vinyl sized folio. Very stylized and that 50’s into the 80’s vibe that was popular at the time.

And yes in the bottom right is the EA logo!

Now going to GOG M.U.L.E. has been released!

So what is going on with older EA titles? I didn’t see anything in the GOG forums.

I can’t possibly be the one to break this weird EA story.

IBM OS/2 J2.1 Beta Release (aka 90’s CD-ROM done right)

Frustration of the early 1990s

Something that used to annoy me to no end back in the early 90’s was nearly empty CD-ROM’s from big companies. Back then dialup was the norm and I was ‘lucky’ enough to have a 2400 baud modem back in 93. I wanted a 32bit processor and at least 4MB of ram to join that elite home based 32bit computing to finally feel like I’d upgraded well beyond the Commdore 64, but money was tight and that 2400 baud modem I got on sale from BrandsMart USA was ‘good enough’. I’ve had a 300 baud modem on the c64 so I knew the feeling of absolute painful downloads.

Heck internet access wasn’t so prevalent, and dialing up to BBS’s was super common. It’s a BBS where I stumbled across Linux on CCUG, which was both great for being local but also letting me download at night at 2400 baud as many BBS’s kicked me for being too slow. Thanks Doug!

But here we had this awesome era of CD-ROMs, I managed to snag a NEC Intersect single speed external from TigerDirect, who would have these annual sales to clearance all kinds of RMA’s. It was a great time to get stuff for pennies on the dollar as they say. It was amazing to have access to nearly 700MB of data per disc. But it was amazing how empty so many were.

One such opportunity to ship as much as possible to the users was absolutely missed in OS/2 2.1/3.0 Looking at the EN-US release you find the OS/2 2.1 for Windows CD-ROM contains just the OS, both extracted and disk images:

Volume in drive E is OS2_CD_ROM
  Volume Serial Number is 4384-1BD8
 Directory of E:\
 [DISKIMGS]    [MMPM2]       OS2SE20.SRC   [OS2SE21]
                1 File(s)             10 bytes
                3 Dir(s)               0 bytes free
 Total Files Listed:
          645 File(s)    292,279,546 bytes
          135 Dir(s)               0 bytes free

with 300MB on the disc that left space for another 300MB. What could they have put on there? Obviously the best answer is 3rd party drivers, any and all SDK (Although we are talking about IBM who famously priced the OS/2 1.0 SDK for $3,000), demos, utilities, free software?!

Enter OS/2 2.1J Beta of Japan

While on the Discord some cheap OS/2 CD-ROMS popped up and @plaman was nice to image them for me. I was more interested in Borland C++ 2 for OS/2 but there was also this Japanese beta of 2.1. Normally I wouldn’t be all that interested as I was thinking it was for PC-98 but but’s the ‘DOS/V’ variant which is mostly like a normal PC. But mounting the CD-ROM showed it was far more interesting:

Volume in drive F is V_MAG9310
  Volume Serial Number is DD59-9766
 Directory of F:\
 [DOS_WIN]     [OS2BETA]     [OS2DEMO]     [OS2FREE]     OS2SE20.SRC   [OS2SUPP]     [PCGAMES]     README.1ST
 [VMAG]
                2 File(s)          2,187 bytes
                7 Dir(s)               0 bytes free
 Total Files Listed:         2867 File(s)    501,115,944 bytes
          637 Dir(s)               0 bytes free

PC Games?! Demos?! What is this! And sure enough it has a tonne of game demos including a bunch of Sierra, LucasFilm and even an Electronic Arts Syndicate demo!

Leisure Suit Larry Demo
Indiana Jones and the Fate of Atlantis Demo

In the freeware directory its a selection from Hobbes, including EMX 0.8F, and the GCC/2 port. Also hidden in there is ‘S_O2OBJ.ZIP’ which is the source to a program to convert GAS i386 a.out object files to OMF for use by LINK386 (yes that adventure is ongoing), and all kinds of other fun things. What is nice is that the source code archives are included as well. Thanks IBM of Japan!

In addition there is of course one of those ‘OS/2 demo’ slide show apps

Very AmigaDOS 2.0

It’s just a simple slide show thing to go over how to use the new desktop

Transform your ‘old’ desktop to the new metaphors of the past:

Into the OS/2 future! Of course you have to understand it’s 1993 by now, and the vast majority of the world is using either Windows 3.0 or 3.1. The new OS/2 2.00 UI is so radically different that even Windows 10 doesn’t attempt the same level of object integration. Although leaving it like the above would be more of a ‘Bob’ type of move, the real world result was this:

Of course in the demos the backdrop per folder thing in OS/2 always looks great, but in real life it was never the same. Perhaps it was the limitation of editing tools of the time, or how OS/2 had a different bitmap format from Windows, which really limited the ability to interchange images.

Compare this to the clutter of the Windows 3.0/3.1 desktop:

Obviously the ‘winning move’ was the Windows 95 desktop which reduced icons to mere shortcuts to give the illusion of something like the OS/2 desktop, but without anywhere the level of complexity and integration made for something far more lightweight. Of course I don’t even want to talk about the binary ini files, their ability to corrupt and booting off diskette to rebuild the desktop by hand. When things failed on OS/2 they failed in the most amazing ways.

At the end of the day;

I still haven’t tracked down a release version of OS/2 2.1 for the Japanese market to see if the CD-ROM version shipped with anything beyond the OS. Perhaps it was simply a beta thing. But these shovelware discs always have a great accidental archives of the era. And it’s nice to see that some OS/2 stuff got preserved for once.

If you are interested you can download the ISO on archive.org here: OS2J21_Beta

Legally Buying Duke Nukem 3D in 2021

Well back in 2017 it turns out that Jordan Freeman was working a deal with 3D realms on some new series that didn’t pan out…

Jordan Freeman Group and ZOOM Platform Announce 3D Realms Partnership for Shadow Stalkers Episodic Computer and Video Game Series

However it appears that in addition to trying to get a game out, they also secured rights to resell the catalogue in some perpetual fashion. Neat

So for all the zoomer’s who’ve somehow never played the greatest boomer shooter of all time, you can score Duke Nukem 3D on the aptly named zoom-platform.com

The holy trinity!

It’s currently $4.99 USD, and it comes with all the DLC/Episodes!

Granted I’ve owned them all in some fashion over the years so I can’t even keep track of how many times I’ve bought Duke Nukem 3D, but here we go.

Apparently Randy can’t do anything about it, as he’s pulled the Duke from everything else.

A mildly annoying 32bit adventure, also happy 30th PGP!

It’s been 30 years since the initial launch of PGP! Hard to believe what a firestorm it ignited i the 1990’s and the real pity of how the crypto field is just as baffling and confusing to people today as it was back then.

It’s crazy how crypto went from being an obtuse tool, to suddenly being in the hands of normal people with a public web of trust, and widely available source. And of course it was that widely available source that led to the first real people of trying to geofence on the internet, and it was naturally impossible to contain, even in the era before VPN’s people were able to circumvent any and all “protections” and download away. Strong cryptography went from being something considered ‘weapons grade’ and thusly requiring a munitions license to produce and distribute to suddenly being available to the world at large.

Investigations were launched, agencies contacted, and in spite of it all people had signing parities to exchange public keys, and sign the trust building the web. Try as some people may have demanded ‘back door access’ or black box crypto chips, the cat was out of the bag, and all you needed was a C compiler and a zip file small enough to easily fit on a low density 5 1/4″ diskette. It is 1991 after all, and there is still a sizable amount of XT/AT class machines out there, along with the 68000 Amiga/Atari/Macintosh (upgraded QL’s? 128kb really isn’t enough).

PGP 1.0 is from another era, originally written in the late 80’s cleaned up and released in 1991 where mass produced 64bit machines were still a bit off, and thusly PGP 1.0 really supports 16bit & 32bit OS’s. For the purpose of this ‘revival’ I went with the Unix port, the aptly named unix_pgp10.tar.gz. And from the MS-DOS version I extracted the test data to make sure it works in the file pgp10-test-data.tar.gz

$ file pgp
 pgp: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cd9ecbf51fab24abbb7153a2cc04bb01bbf2ae91, not stripped
$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 288-bit key, Key ID A27A1F, created Sat Oct 19 23:56:24 3006391
 You need a pass phrase to unlock your RSA secret key.
 Enter pass phrase:

While it was simple enough to build, sadly on x64 WSL instance it doesn’t work. There is no pass phrase for the test data.

Normally I have one of usual two choices a) try to fix PGP to be 64bit friendly or b) run it under a 32bit environment. Normally I would do b, but I went digging into some porting strategies for the a choice and ran into this totally underused tech x32.

Long story short you keep your 32bit integers, you run like it’s a 32bit process but you are mapped into a 64bit address space. Even better -static works!

On Debian 10 the environment can be installed with the following:

apt-get install gcc-7 lib32gcc-7-dev libgcc-7-dev libx32gcc-7-dev gcc-7-multilib

Then to invoke it, use gcc-7 -mx32 . It’s that easy.

WSLv1 vs WSLv2

$ ./pgp
 -bash: ./pgp: cannot execute binary file: Exec format error
$ file pgp
 pgp: ELF 32-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2aa5f030603018ca1dc6c5c10aa979751b006aca, for GNU/Linux 3.4.0, not stripped

Notice it is now a 32-bit LSB executable, but also in the x86-64 address space! However under the WSLv1 environment it won’t work. Time to update to v2

   wsl --set-version Ubuntu-20.04 2
   Conversion in progress, this may take a few minutes…
   For information on key differences with WSL 2 please visit https://aka.ms/wsl2
   WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel 

And now with the instance converted:

$ ./pgp
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 For details on free licensing and distribution, see the PGP User's Guide.
 For other cryptography products and custom development services, contact:
 Philip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone (303)444-4541
 Usage summary:
 To encrypt a plaintext file with recipent's public key, type:
    pgp -e textfile her_userid      (produces textfile.ctx)
 To sign a plaintext file with your secret key, type:
    pgp -s textfile your_userid     (produces textfile.ctx)
 To sign a plaintext file with your secret key, and then encrypt it
    with recipent's public key, producing a .ctx file:
    pgp -es textfile her_userid your_userid
 To encrypt with conventional encryption only:  pgp -c textfile
 To decrypt or check a signature for a ciphertext (.ctx) file:
    pgp ciphertextfile [plaintextfile]
 To generate your own unique public/secret key pair, type:  pgp -k
 To add a public or secret key file's contents to your public
    or secret key ring:   pgp -a keyfile [keyring]
 To remove a key from your public key ring:     pgp -r userid [keyring]
 To view the contents of your public key ring:  pgp -v [userid] [keyring]
$

And we are in business! Now we can run the example crypto test:

$ ./pgp testfile.ctx
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 File is encrypted.  Secret key is required to read it.
 Key for user ID: Bond, James (007)
 286-bit key, Key ID A27A1F, created (null)
 Advisory warning: This RSA secret key is not protected by a passphrase.
 Just a moment-- .
 File has signature.  Public key is required to check signature. .
 Good signature from user "Smart, Maxwell (86)".
 Signature made Thu Jun  6 05:28:52 1991
 Plaintext filename: testfile

And there we are!

PGP 1.0 suffers from 2 real defects of the era the first being the home brew bassomatic that is apparently full of all kinds of flaws, and the second lurking in rsalib.c

 The RSA public key cryptosystem is patented by the Massachusetts Institute of Technology (U.S. patent #4,405,829).  Public Key  Partners (PKP) holds the exclusive commercial license to sell and  sub-license the RSA public key cryptosystem.  The author of this  software implementation of the RSA algorithm is providing this  implementation for educational use only.  Licensing this algorithm  from PKP is the responsibility of you, the user, not Philip Zimmermann, the author of this implementation.  The author assumes no liability for any breach of patent law resulting from the unlicensed use of this software by the user. These routines implement all of the multiprecision arithmetic necessary for Rivest-Shamir-Adleman (RSA) public key cryptography.

And it ignited so much of a war about licensing the RSA cryptography base. It wasn’t until 1992/1993 that the RSA released their own aptly named rsaref that at least clarified and addressed their licensing restrictions. As we found out later it wasn’t the DOJ shutting down encryption, nor wild acts of congress instead it was US Patent 4,405,829 which finally expired in Sept 21, 2000, along with US patent 4,200,770 Hellman Diffie Merkle, public-key cryptography which expired in September of 1997. So in the end it was the lawyers who were to be feared, not the the US Government.

Another source of annoyance was the public/private key files are stored in a binary format (hence the 16/32/64 issues I’m sure!).

C:\temp>pgp -v jason.pub
 Pretty Good Privacy 1.0 - RSA public key cryptography for the masses.
 (c) Copyright 1990 Philip Zimmermann, Phil's Pretty Good Software.  5 Jun 91
 Key ring: 'jason.pub'
 Type bits/keyID   Date     User ID
 pub  990/F7CAD5 12-Jun-21  Jason Stevens
 1 key(s) examined.
 C:\temp>type jason.pub
 °ü½╟╓iº½t↕Hï╜Æ(↑ªα&E☼lKL$*⌠=└¥╒[╫ès,╔kår~▐MFBv≥≡╫E┴╟Tÿ║µó ╨6,♣◄Ermo▼æ▄;± ùî
 C:\temp>

So naturally you have to use uuencode which led to MIME collisions and other fun stuff down the road. yay!

begin 666 jason.pub
MF9,`$!C$8`U*87-O;B!3=&[email protected]/5RO>TFV)[email protected]%49RW3NYGD<8*H`3X1
MZ>D'/F/D7$)OKD9&K+>A<@4<,$RV.+M?9VR;17)M;Q^1W#OQ()>,#?B!J\?6
M::>K=!)(B[V2*!BFX"9%#VQ+3"0J]#W`!YW56]>*<RS):X9R?MY-1D)V\O#7
/1<''5)BZYJ+_T#8L!0`1
`
end

Even though today we have widespread SSL, and all kinds of apps that encrypt by default, but Operation Trojan Shield shows that that an app is simply not enough, and you cannot trust anything.

Though Enigma had some cryptographic weaknesses, in practice it was German procedural flaws, operator mistakes, failure to systematically introduce changes in encipherment procedures, and Allied capture of key tables and hardware that, during the war, enabled Allied cryptologists to succeed and “turned the tide” in the Allies’ favour.[15][16]

-Wikipedia

And just like the spy movies good crypto is tedious, bulky and rarely used properly*.

Yes please don’t seriously rely on pgp 1.0!

xMach

Back when I started blogging, I started with a few quick things on the top of my head, that being Netware, SIMH, CP/M Zork, Xenix and of course Mach. Back in the shiny new world of 1999 we may have survived the Y2K apocalypses but the valley was firmly set in the mind of start-up fever that would lead to the looming .com crash but the menatlity of IPO & dump would remain to this very day.

The Utah projects around Mach were wound down with the OSKit being the next wave for pistachio, but that set the scene of more than average users now having ‘fast’ machines at their disposal and the ability to rifle though published source and roll their own. It was this environment of trying to make it in the full force of the post ‘year of the desktop’ Linux where xMach appeared, had some interest and quickly died. For the longest time I had thought all evidence of it had been eradicated as the domain had been excluded from wayback, and searching went nowhere. But one bored night I tried exploring sourceforge, a veteran of the pre .com bubble crash to see if it had anything, and yes it did!

https://sourceforge.net/projects/xmach

Oh sure in retrospect it’s pretty obvious. All the cool kids had public repositories on the internet.. And then after the .com implosion so many took their CSV’s and went home. And so many of those just died in selfhosted, self imposed silence.

From what I remember one of the first goals was to time the source to make it easier to cross compile from either NetBSD or Linux, and utilize what was the double edged sword of Lites, the ability to run either 386BSD/NetBSD binaries or Linux binaries. And the Linux side was already incorporating shared libraries something that was desperately needed in 1993 for X11. But this was 2000! And of course the downfall of running Linux under xMach/Lites is that you will of course compare the performance, and Linux won hands down. Not to mention interest in improving and adding to Linux was in full mainstream support by 2000 so it made xMach feel all the more ancient.

But we didn’t come here for practicality!

Getting the source & tools

First off I’m going to use the cross tool chain for building OS Kit. i586-linux2.tar.gz (password and 404 apply) as I not only don’t feel like fighting why MIG doesn’t work in 64bit, and it’s just easier to enable 32bit usermode. Speaking of for Ubuntu 20.04.2:

dpkg --add-architecture i386
apt-get update
apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libc6-dev:i386 libfl-dev:i386
apt-get install sharutils gcc-multilib build-essential

And for people like me running on Windows 10, You absolutely MUST enable WSL v2. Without an actual kernel the multiarch simply doesn’t work. No doubt it has something to with actually running Linux vs emulating it. Probably mucking about with the LDT/GDT which you certainly cannot do as a process on Windows.

Next just add the old GCC 2.7.2.3 chain into your path:

PATH=/usr/local/i586-linux2/bin:/usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3:$PATH
export PATH

Next up you’ll need the source, and being all new and trendy I put it over on GitHub. Clone the repo, and you are ready to start compiling!

Building the xMach kernel

Make an object directory and run configure like this:

../kernel/configure --host=i586-linux --target=i586-linux --build=i586-linux --enable-elf --enable-libmach --enable-linuxdev --prefix=/usr/local/xmach;cp ../updated-conf/kernel/Makeconf .

For some reason configure never populates the compiler tools right, and I can either mess with autoconf (no thanks) or I can just include a known good file. It’s not hard to figure out, you can diff it if you want to, but it’s just set for a native 32bit build of MIG, and then using the cross tools to build the kernel.

type make, and wait 13 seconds, give or take…

i586-linux-ld -r  -L/home/jsteve/src/xMach/kernel-build/lib -nostdlib \
         -o bsdboot.o crt0.o about_to_die.o anno.o boot_info_dump.o boot_start.o cpu.o cpu_init.o cpu_tables_init.o cpu_tables_load.o crtn.o die.o do_boot.o exit.o gdt.o idt.o idt_inittab.o idt_irq_init.o main.o malloc.o panic.o phys_mem_add.o pic.o putchar.o puts.o real_tss.o real_tss_def.o rv86_real_int.o rv86_real_int_asm.o rv86_reflect_irq.o rv86_trap_handler.o serial.o trap_dump.o trap_dump_die.o trap_handler.o trap_return.o tss.o tss_dump.o -lmach_exec -lmach_c
 make[1]: Leaving directory '/home/jsteve/src/xMach/kernel-build/boot/bsd'
 MACHBOOTDIR=cd /home/jsteve/src/xMach/kernel-build/boot/bsd; pwd \
 /home/jsteve/src/xMach/kernel-build/boot/bsd/mkbsdimage -o /home/jsteve/src/xMach/kernel-build/Mach /home/jsteve/src/xMach/kernel-build/kernel/kernel /home/jsteve/src/xMach/kernel-build/bootstrap/bootstrap
 real    0m13.135s
 user    0m12.060s
 sys     0m1.383s

I cannot stress just how incredibly fast this is. I’m pretty sure it literally took hours for this to run, assuming nothing went wrong, which it almost always did. As part of the fun, next do a ‘make install’

Building Lites

This is somewhat similar to the kernel build, however it is far more touchy. You absolutely MUST copy / fix the Makeconf file otherwise the build will be corrupted and the only way to fix is to remove the build directory and try again.

../lites/configure --host=i586-linux --target=i586-linux --build=i586-linux --enable-mach4 --prefix=/usr/local/xmach --with-mach4=../kernel;cp ../updated-conf/lites/conf/Makeconf conf

And once more again make the project and just wait a few seconds. BSD without the hardware support is pretty tiny

i586-linux-ld -o emulator.Lites.1.1.u3.out ./emulator_base  -L/home/jsteve/src/xMach/lites-build/liblites -L/usr/local/xmach/lib -e __start ecrt0.o  e_mig_support.o emul_generic.o error_codes.o emul_init.o emul_mapped.o emul_misc_asm.o e_bsd.o e_43ux.o bsd_1_user.o emul_mach_interface_user.o e_mach_msg_server.o e_stat.o e_bnr.o emul_exec.o signal_server.o e_uname.o e_mapped_time.o e_sysvipc.o e_linux.o e_sysv.o e_exception.o e_signal.o e_machinedep.o e_linux_trampoline.o e_linux_sysent.o e_isc4_sysent.o e_cmu_43ux_sysent.o e_lite_sysent.o emul_vector.o e_trampoline.o e_linux_getcwd.o    -llites -lthreads -lmach_sa  /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.7.2.3/libgcc.a && \
 i586-linux-size emulator.Lites.1.1.u3.out && \
 mv emulator.Lites.1.1.u3.out emulator.Lites.1.1.u3
    text    data     bss     dec     hex filename
  130195   16904     160  147259   23f3b emulator.Lites.1.1.u3.out
 make[1]: Leaving directory '/home/jsteve/src/xMach/lites-build/emulator'
 make[1]: Entering directory '/home/jsteve/src/xMach/lites-build/bin'
 make[1]: Nothing to be done for 'all'.
 make[1]: Leaving directory '/home/jsteve/src/xMach/lites-build/bin'
 real    0m6.423s
 user    0m6.006s
 sys     0m0.551s

Yes that’s six seconds. do a ‘make install’ and now your /usr/local/xmach directory is fully populated and ready to transport somewhere to do the ‘install’ and boot.

Installation

One thing to take notice of xMach over the standard last Mach4 is that the Linux boot options have been removed. There is all kinds of changes in 16bit assembly handling that need to be rewritten or fixed. I’m sure someone at some point has, but apparently it’s easier to go with the bsdboot and use either the machboot or GRUB (v1!) to get it going. Although Linux knows how to mount loop ‘diskfiles’ I don’t remember how to deal with partitions and BSD slices. So I did my typical trick of booting up an existing image, and using telnet/uucp to transfer xMach into an existing disk.

Booting however was a bit more fun, as the kernel is now compiled as a BSD ELF image and Grub 1.x won’t boot it. I used a ‘Super Grub2 disk hybrid‘ ISO image, and was able to just hit escape and type in:

kfreebsd (hd0,msdos2,bsd1)/Mach
boot
Booting xMach kernel

Because of the massive drift in multiboot vs ‘BSD ELF’ the drive isn’t passed correctly so I have to manually tell it ‘/dev/hd0a/mach_servers’ and it’ll pick up Lites, and boot up!

And there we go, with my old Mach4/Lites image from 2009 with a ‘fresh’ cross compiled build from Windows 10 / Ubuntu 20.04

Where to go from here?

Realistically, nowhere. Seven years ago there was OpenMach, which seems to have done a few things, but even moving to a GAS from 2015 didn’t help me at all trying to build the 16bit stuff so the answer must lie in the past. Otherwise the fundamental problem as always is at best you will have a 4.4BSD system which again in 1992 would be awesome, but 2021? yeah it’s a curiosity at best.

Running VMWare ESXi on Raspberry PI

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

Just for fun with virtualization I wanted to try out VMWare ESXi for ARM64, most specifically Raspberry PI. ESXi for ARM has been around for a couple of years now. Since PI4 packs 8GB of RAM and has a reasonably fast CPU it can be a worthwhile experience. Also more OSes for Raspberry PI are now available in UEFI boot mode.

Not going to go through exact installation steps as these are all around the web and youtube. Just to summary you will need to download an image from VMWare website as well as bunch of UEFI firmware files from github and combine it all together on to a SD card. When you boot it you will go through an install process which is straightforward. You can overwrite install media and use it as the target so no need for multiple SD cards. Once it boots you will see familiar ESXi boot screen:

ESXi booting on Raspberry PI 4

In order to get it going you will obviously need to add some storage. You can use NFS, iSCSI or locally attached USB drive. For the latest you need to disable USB arbitrator.

# /etc/init.d/usbarbitrator stop
# chkconfig usbarbitrator off

What can it run?

ESXi ARM only officially supports only UEFI boot based OSes. Fortunately this is a default option for Ubuntu PI, Free/Net/OpenBSD also work and so does Windows. But what about OSes that use U-Boot? Since ESXi-ARM Fling 1.1 you can boot oses in a “direct” mode with no UEFI! This is a huge step, but unfortunately as of today it doesn’t support UEFI-less VGA, only a serial port. Hopefully this can be fixed in future. I would love to have a RISC OS and/or Plan 9 VM. On the other hand Plan 9 supports EFI boot so an image could be made.

Windows guest install was also much easier than I expected. Thanks to UUP dump you basically roll your own bootable ISO. I think it’s actually easier to get it going on ESXi than natively on RPI hardware or QEMU.

Windows 10 Guest VM on ESXi Fling Raspberry PI

NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:

VMXNET3 for Windows 10 ARM64 on ESXi Fling on Raspberry PI

What is it good for?

Right now probably just for fun. But I can easily see datacenters filled in with ARM servers running ESXi. Future is bright and free of Intel! Personally I will keep it around for development purposes if I need to make builds for ARM on various OSes.

Interestingly enough you can even run VMWare ESXi ARM on QEMU with nested virtualization!

Also this is the official VMWare ESXi ARM Blog worth checking for future updates.