While I’m writing this, I’m listening to Neuromancer via WinAmp & the ancient Speex plugin I had updated about 8 years ago.
I took my Surface, and downgraded it to the North American 8.0 version without updates, added my MS ID, and from there ran the jailbreak and win86emu (sometimes called x86node) and from there I was able to run some simple Win32 exe’s.
Even though I had done a simple cut down QuakeWorld port with the GDI only display, using win86emu it’ll run the 80386 build as well. while I haven’t thrown much at it, I’m just amazed that so far things are working.
When you think that between the jail-break to unlock the ability to run programs combined with a CPU translator, and Win32 to Win32 thunk / translation program, why on earth did this thing ship without it? It’s amazing that between trying to launch a platform with no inertial for applications after Android & Apple were selling millions of hardware units, and billions of software units, and cutting the past applications. It’s just crazy.
And then Microsoft did their normal thing when something goes wrong, which is basically end it, and destroy all evidence it existed. There is no Windows 10 upgrade for the Surface, even though Windows 10 IOT has been hacked to run from a USB stick on the Surface, but it’s insanely slow.
It’s incredible how much it’s improved since I last touched on WineVDM, the port of Wine to run on Windows using the MS-DOS Player (and Mame 80386 emulation) at it’s heart.
The latest source build WineVDM_2018_07_30b.7z is now capable of loading and running Sim City for Windows 1.0.
I found it best to install Windows 3.0 into DOSBox, and then your application. After the install I copy the application so the physical drive of the hosts matches where it was installed, and then unpack the 7z build archive into that directory. There is a ‘WINDOWS’ directory and I xcopy the installed Windows directory into there so it has all the INI files, fonts and all that jazz. To make sure it doesn’t conflict I delete the following from Windows 3.0:
Since these files are most certainly going to be emulated by WineVDM. After that it’s time to run stuff!
I should also add that I’ve been able to use QuickC for Windows, and build a ‘non trivial’ program, the Fortran f2c compiler weighing in at 104,245 lines , and use that to compile 16,182 lines of Fortran 77 into C, and then compile the resulting C + the Fortran runtime library a staggering 130,405 lines of code, and the resulting binary works, just like it did on Windows 3.0!
I’ve also been able to print a text file using Microsoft Word 2.0 much to my amazement, although anything involving fonts just locks or crashes. I can’t say I’m all that surprised.
This is super cool, building on Takeda Toshiya’s excellent MS-DOS Player, is a fusion of the MS-DOS emulation with portions of Wine to run Win16 applications on Win32 capable OS’s.
Yes, it really can run Excel 3.0a. I don’t know how much people will want a 27 year old spreadsheet, but here we go! It’s incredibly buggy, and many Microsoft programs don’t like their accelerators, or menus, more things don’t run than do, but when they do it’s great.
The releases on the github page are quite old, and you’ll really want to bulid this from source. You will need Visual Studio 2017 to build this, and I used the Community Edition. While trying to compiling I got this error:
Performing Custom Build Tools
The system cannot find the path specified.
Well that doesn’t help us at all!
Setting the Tools -> Options -> Build and Run, MSBuild sections to both detailed verbosity revealed:
“C:\Users\neozeed\source\repos\winevdm-master\Release\convspec” “krnl386.exe16.spec” KERNEL > “krnl386.exe16.asm” && “C:\msys32\mingw64\bin\as” –32 -o “krnl386.exe16.obj” “krnl386.exe16.asm”
Performing Custom Build Tools
The system cannot find the path specified.
So it turns out it is using GNU GAS to assemble itself. So I just copied in an ‘as.exe’ from another MinGW install I have lying around.
GNU assembler 2.17.50 20060824
So it doesn’t even have to be a hyper modern version, as you can see with the –32 we are building 32bit based stuff anyways.
And with that all done we have a release build.
I had no luck with Sim City, but Sim Life & Sim Earth load at least, but not being able to use the menus means you can’t really use them. Microsoft Word 1.1 won’t load at all, while Word 2.0 will load but again no menus, and it’s unable to register enough OLE to open documents so it’s not very useful again. Although my ancient QuickC for Windows F2c port of Dungeon, works okay, although QuickC for Windows itself does not currently run.
Another great thing is that you can run WinHelp for all your ancient documenation fixes! Also MS Write from the ancient days of Windows 3.0/3.1 works as well
The latest version allows the menus to work properly so you can actually use Word for Windows 2.0 and SimEarth & SimLife now! Further updates let you actually select and open files in Word for Windows 2.0!
The laptop I’m using at the moment is old, Alienware 14 P39G that is 5 years old. The power is convinced that it can’t run over 700Mhz unless it’s on battery for some reason, then it’ll jump to 2.3Ghz just fine. Oh well It’s otherwise not bad, just getting old.
Also it’s only using the Intel GPU. I think I need to do a fresh install of the 2018 version of Windows 10 on this thing.
Anyways so CXBX Reloaded can run many xbe’s directly so you don’t need a ROM or dashboard, but it’ll run the dashboard if you have it. It’s really cool though as JSRF did come to Android but it won’t run on any modern versions of Android. As far as I know it never came to PC, but being able to run the X Box version is certainly cool.
Sourcecode & nightly binary builds are currently on github:
As you can read right now It’s running a simple OpenWatcom 16bit hello world based program. The 16bit OS/2 and 32bit OS/2 API’s ended up having different calling sizes, among other issues which had complicated the bridge program. However Ryan’s newer use of scripts to generate the required glue for the API’s at least mean that adding the 16bit/32bit calling conventions & required bridges/glue is at least now automated.
This is super cool, as this will eventually open the door to Watcom C/Fortran, Zortec C, Microsoft Basic/C/Cobol/Fortran and of course many other languages that burst out into the initial OS/2 scene before the eventual weight of the SDK & associated costs doomed OS/2 to failure.
Seriously, for those among us who love OS/2 and have like $5 to spare, send some encouragement to Ryan… 🙂
So this is really super cool! Ryan C. Gordon has written a Wine like program to run OS/2 programs!
Using 32bit Linux, and some native libraries, 2ine can load up an LX (32bit) executable and try to run it under Linux, much in the same way that Wine can run Windows programs. And yes it’ll run EMX built stuff. Although keep in mind the original Microsoft based languages, programs and tools is all 16bit. After the whole Windows 3.0 thing and the split of Microsoft from the OS/2 project all their tools are either 16 bit, or 32bit LE format, which IBM had dumped for the LX format once OS/2 2.0 had shipped.
You can read about his incredible progress, and all the trials and tribulations of running OS/2 programs, along with the craziness that is thunking back and forth to the 16bit space for the old VIO calls that had never were updated to 32bit in that transition phase where a good chunk of OS/2 never was updated from 16bit, over on his patreon page here.
Attempting to run anything 16bit or LE will give you:
At End Of Road Score: 36/0
Welcome to Adventure! Do you need instructions? (y/n) >n
A Modern Classic
Based on Adventure by Willie Crowther and Don Woods (1977)
And prior adaptations by David M. Baggett (1993), Graham Nelson (1994), and
Adapted once more by Jesse McGrew (2015)
Release 1 / Serial number 151001 / ZILF 0.7 lib J3
At End Of Road
You are standing at the end of a road before a small brick building. Around you
is a forest. A small stream flows out of the building and down a gully.
At End Of Road Score: 36/0
Again it’s works so well it’s amazing!
You can find the 2ine source over on icculus.org here. I had to tweek the heck out of the CmakeList.txt to get it to build, and since I was interested in the command line, I ended up disabling all the SDL / PM stuff, and make sure I had the ‘wide/unicode’ version of ncurses installed.
I don’t think there really was any killer 32 bit OS/2 applications, but with clean room versions of:
Not to mention being able to call into Linux DLL’s and using ‘clean’ OS/2 DLL’s would let you embrace and extend OS/2.. Or maybe even let you build the proverbial fantasy of both RISC & 64 bit OS/2. …..
So what this means is that now you can make fully standalone Win32/Win64 executables out of CLI based MS-DOS applications.
D:\tcc>msdos\binary\i486_x64\msdos.exe tcc -Iinclude -Llib hi.c
Turbo C++ Version 3.00 Copyright (c) 1992 Borland International
Turbo Link Version 5.0 Copyright (c) 1992 Borland International
Available memory 4215648
D:\tcc>c:msdos\binary\i486_x64\msdos.exe -c hi.exe
‘new_exec_file.exe’ is successfully created
Isn’t that great?
I’ve had one issue with Turbo C++ 3.00 and that is the embedded executable will run out of memory while linking, but invoking it by calling msdos.exe let’s it run fine. If you compile and link separately it’ll run just fine.
So like all zork obsessed people (I really should get help or something), I was trying to build a z-machine interpreter for the x68000, using Lydux’scross GCC compiler. And it was honestly looking like a LOT of work in the IO department. Thinking that the older versions were more simpler, I went looking for the oldest open Z-machine, called the “The InfoTaskForce Infocom interpreter”, released by the InfoTaskForce. Unfortunately I can only find version 4.01 searching for the source code. Which still looks too complicated. But looking the history file, the project started back in 1987. So with that to go on a new google search got me this:
From an TRS-80 dump of all things. I don’t know what version this is other than the brief copyright mention:
/* (C)opyright 1987 InfoTaskforce. */
All of the files are dated 4/12/2001 so they obviously aren’t original. And the version string is:
echo ( “Interpreter: C Version 1.0\n” ) ;
So assuming this is correct, from the 4.01 history file:
REV_E – June 25, 1987.
REV_E is the first major overhaul to the interpreter.
* The source is now significantly lint free.
* TERMCAP support has now been added [#define TERMCAP option].
* Screen paging and word wrap has been added, along with a new
command line option which disables screen paging (-p).
* Random number generator seeding using time () added [#define
* Attributes in the object list are listed as bits.
* A debuging version can now be produced as an inbuilt options
[#define DEBUG option].
* The coded requirement that 25k is always free in the system can
now be removed [#define ALLOCALL option].
* A new command line option was added to print the object/room list
as a tree (-r).
* interp.c has been re-written to improve efficiency [large
switches have been replaced with arrays of pointers to funcions].
There are now 14 machines on the porting list:
Machine C Compiler Operational Porting details
Macintosh Aztec C Version 1.06F 18/05/87
Macintosh Lightspeed C 2.01 29/05/87 Use “rb” & “wb” in all fopen()s
IBM PC/AT Microsoft C 4 30/05/87 Link with binmode.obj
DEC VAX 11/780 UNIX V7 cc 01/06/87
HP-9000 HP-UX cc 02/06/87
gould cc 03/06/87
Amiga Aztec C 04/06/87
Pyramid 9810 cc 04/06/87
Pyramid 90x cc 04/06/87
Osiris cc 05/06/87
DEC PDP-11/? UNIX V? cc 07/06/87 EXTENSIVE
mods to fix problems with signed chars.
VAX VMS cc 16/06/87 Add #define
times ttmes to fix multiply defined symbol problem. [infocom.h]
Version 1.00 – August 17, 1987.
The REV_C interpreter of June 2, 1987 was officially archived as
Version 1.00 on August 17, 1987.
So this means it’s very 16bit & 32bit friendly, especially on BIG endian machines like the 68000 processor.
Luckily this older version is pretty trivial to compile, and get running. But I was over thinking the build process and decided to strip the executable as GCC would kick out a 500kb file, which objcopy would extract a 81kb executable. Stripping it brought the size down to a 50kb executable but it wouldn’t run in either xm6 or run68. I ended up going in circles for a while trying to find fault in what is broken where until I manually compiled the interpreter, and omitted the strip step and suddenly had a working interpreter.
Now there is one issue, saving doesn’t work. Something in the libc is having issues using fopen with a file to write. Reading works perfectly fine though. So to fix it, I went ahead and redid the save feature to use the HumanOS native _open/_write/_close functions and I’m able to now save & restore a game.
D:\proj\run68\test>run68.exe infocom.X minizork.z3
MINI-ZORK I: The Great Underground Empire
Copyright (c) 1988 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Release 34 / Serial number 871124
West of House
You are standing in an open field west of a white house, with a boarded front
door. You could circle the house to the north or south.
There is a small mailbox here.
West of House Score: 0/0
Living Room Score: 10/19
A nasty knife
A brass lantern (providing light)
A brown sack
A glass bottle
The glass bottle contains:
A quantity of water
Living Room Score: 10/20
In this process I’ve also managed to build run68, and verified that it’s operating correctly, as both run68 and XM6 both failed to write to a file with fopen, and both work using the native calls.
I’m sure most people won’t care but I think it’s great having the ability to run a GCC generated C program in a relatively small interpreter.
I read somewhere that kids these days are interested in games where you can modify how the game operates with sub programs written in their own languages etc.
So while this does sound interesting, it does remind me of that good old fashioned syscall emulation, where you emulate the CPU, load an executable, but any system calls that are made, are handled by the simulator, little if any hardware is actually emulated. Yes Basilisk II is an example of this, but so is Wine, WOW, NTVDM, i386 code on x64 platforms, and various others. The major advantage is that they typically can access your native file system so you don’t have to mess with virtual disks. Of course it all depends on the implementation.
I did remember this old simulator, Apout, which could run UNIX v6, 7 along with BSD 2.9 stuff on modern Unix. The emulation layer here being LIBC, and how pretty much the basics of how UNIX operates hasn’t changed since those ancient days in the 1970’s.
So I thought I’d try to see how much of this works on Win32 using Microsoft Visual C++ 5. And surprisingly I didn’t have to glue in that much, the biggest thing I had to do was trying to detect if a file about to be opened was ASCII or BINARY as the UNIX platform doesn’t distinguish these two but Win32 with it’s MS-DOS legacy does. As you can see I did get the banner program running, some of the games work ok, although I had to comment out the sgtty functions as there is no immediate equivalent on Windows, and I didn’t think there would be that much of a demand for such a thing anyways. I can even run the login program. Which brings me to the issue which is that it’ll spawn new programs fine, but when an exit is called Apout just exits. Even on Linux it’ll just do this. I tried doing something with setjmp/longjmp but it crashes shortly afterwards… No doubt some stack unwinding fun. As such trying to compile things just bomb out. I went ahead and took the source code to cc and made a native Win32 version that then calls apout for the various parts and that almost worked except I then found out that the assembler on the PDP-11 is a 2 pass assembler, written in assembly. And yes, when as calls as2, and unwinds all hell breaks loose. Which is another problem that UNIX likes to share file descriptors among itself and children, but children like to close things when they die. I guess the solution is to give each child it’s own descriptor table as everyone likes to close stdin/stdout/stderr and even #4, which the simulator uses for logging. it’s very annoying so I just prevented it from closing handles under 4.
But running each of the phases manually does get me an executable but it doesn’t seem to do anything, the only syscalls are closing all the file handles and exiting.
I don’t think anyone will care, but here is my source/binary along with Unix v7. It’s hard coded to dump stuff into c:\temp for temporary files, the Unix v7 must be in c:\v7 … ugh.
But yeah, you can play that thrilling game from 1979, hunt the wumpus!