win86emu: the greatest thing for Windows RT that Microsoft should have made.

While I’m writing this, I’m listening to Neuromancer via WinAmp & the ancient Speex plugin I had updated about 8 years ago.

x86 node running on Windows RT

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.

I figured since this is kind of hard to find I’ll just mirror it on Source Forge… along with the source.

WineVDM is improving at a dramatic rate

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:

del windows\system\*.drv
del windows\system\*.exe
del windows\system\*.mod
del windows\system\WIN87EM.DLL

Since these files are most certainly going to be emulated by WineVDM.  After that it’s time to run stuff!

130 KLOC!

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.

And yes, it does in fact run SkiFree 1.0

SkiFree on WineVDM

So no need to wait for Win3mu, there is WineVDM which is being developed RIGHT NOW, and the source is already available.  You can see my notes on building it here.

WineVDM

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.

Excel 3.0a

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:

Really it’s no help at all

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.

c:\msys32\mingw64\bin\as.exe –version
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.

F2c Dungeon

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.

WinHelp 3.00

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

Write

You can download my binary build here: WineVDM_2018_07_30.7z.  It’s almost a given that you will need the Visual C++ 2017 runtime.

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!

Jet Set Radio Future now at 60fps on CXBX Reloaded

JSRF title

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.

Alienware 14 P39G

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:

https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/

I was able to find Jet Set Radio Future (JPN Demo).7z, which I think is a playable demo, although I don’t have any controllers to test it.  But it certainly loads up just fine!

Also here is a very poorly captured video of JSRF on CXBX, You can see the laptop struggle on the main power, then able to run at 60fps on battery power…

2ine updated to have preliminary 16-bit .exe support!

From icculus’s patreon

This is nothing short of amazing.  In the last update, 2ine was running simple 32bit programs on Linux, and providing a portable API set to allow strict OS/2 API based programs to run on Linux.

And now Ryan has turned his focus onto 16bit support for 2ine, which you can read about here:

https://www.patreon.com/posts/2ine-16-bit-exe-19337541

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… 🙂

2ine the OS/2 emulator

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:

./lx_loader CL.EXE
not an OS/2 LX module

But let’s try my crazy Win32 hosted EMX 0.8h cross compiler!

C:\emx\demo\dhry>gcc -v dhyrstone.c -o dhyrstone.exe
gcc version 2.5.8
cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=5 -D__32BIT__ -D__EMX__ -Di386 -D__32BIT__ -D__EMX__ -D__i386__ -D__32BIT__ -D__EMX__ -D__i386 -Asystem(unix) -Asystem(emx) -Acpu(i386) -Amachine(i386) dhyrstone.c C:\Temp/cca13032
GNU CPP version 2.5.8 (80386, BSD syntax)
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
D:/pcem/building/MinGW/msys/1.0/local/emx/include
/emx/include
/usr/include
End of search list.
cc1 C:\Temp/cca13032 -quiet -dumpbase dhyrstone.c -version -o C:\Temp/ccb13032
GNU C version 2.5.8 (80386, BSD syntax) compiled by GNU C version 5.1.0.
as -o C:\Temp/ccc13032 C:\Temp/ccb13032
ld -o dhyrstone.exe /emx/lib/crt0.o -L/emx/lib C:\Temp/ccc13032 -lgcc -lc -lgcc -lemxst -los2 -lemx2

And now running that on Linux…

[email protected]:/usr/src/2ine-4a8318f4056f# file dhyrstone.exe
dhyrstone.exe: MS-DOS executable, LX for OS/2 (console) i80386, emx 0.8c
[email protected]:/usr/src/2ine-4a8318f4056f# ./lx_loader dhyrstone.exe
Dhrystone(1.1) time for 5000000 passes = 3
This machine benchmarks at 1666666 dhrystones/second

You’d never know that this was an OS/2 program, if I didn’t tell you.

I tried the old 87 Infocom interpreter, and it’ll run great too!

[email protected]:/usr/src/2ine-4a8318f4056f# file infocom.exe
infocom.exe: MS-DOS executable, LX for OS/2 (console) i80386, emx 0.8c

[email protected]:/usr/src/2ine-4a8318f4056f# ./lx_loader infocom.exe advent.z3

At End Of Road Score: 36/0
Welcome to Adventure! Do you need instructions? (y/n) >n

ADVENTURE
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
others
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:

  • doscalls.dll
  • kbdcalls.dll
  • msg.dll
  • nls.dll
  • quecalls.dll
  • sesmgr.dll
  • tcpip32.dll
  • viocalls.dll

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. …..

MS-DOS player can now embed executables

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
hi.c:
Turbo Link Version 5.0 Copyright (c) 1992 Borland International

Available memory 4215648

D:\tcc>c:msdos\binary\i486_x64\msdos.exe hi
hi!

D:\tcc>c:msdos\binary\i486_x64\msdos.exe -c hi.exe
‘new_exec_file.exe’ is successfully created

D:\tcc>new_exec_file.exe
hi!

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.

As always you can find the project page here:

http://homepage3.nifty.com/takeda-toshiya/msdos/

Tracking down the InfoTaskForce from 1987.

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’s cross 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:

Infocom Adventure Executor Source Files (1987)(InfoTaskForce)[C].zip

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
TIMESEED option].

* 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

128K Apple
Macintosh Aztec C Version 1.06F 18/05/87

128K Apple
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
>restore
Filename: mz1.sav
Ok.

Living Room Score: 10/19
>inventory
You have:
A nasty knife
A rope
A sword
A brass lantern (providing light)
A brown sack
A glass bottle
The glass bottle contains:
A quantity of water
A leaflet

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.

Planetfall on a x68000
Planetfall on a x68000

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.

If anyone cares, here is my updated cross compiler + run68 source along with tweaked Info Task Force 1.0 source.  Or a disk image that XM6 can boot up, and run some demo programs from Infocom of ages ago.

Apout on Windows

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.

Hello from Unix v7
Hello

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.

So close!

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.

Hunt the wumpus on NT
Hunt the wumpus on NT

But yeah, you can play that thrilling game from 1979, hunt the wumpus!