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

Coherent 3.0

I don’t know why I was so dumb as a kid, but I remember thumbing through various magazines, and always seeing this ad:

Coherent Ad

And isn’t that sounding great?  Lex, Yacc, UUCP, and UNIX functionality on a AT compatible machine for $99!  And then you see reviews like this one from PC Mag:

Now even if you want to you can’t wind the clock back to the late 1970s, but Unix lovers can do the next best thing-pick up a copy of Mark William’s Coherent for $99.95.

Included in this time capsule are all of the utilities that you would have received in an AT&T Unix, Version 7, distribution circa 1978. The package includes a protected-mode multi-user multitasking operating system. over 150 utility programs, a C compiler, an assembler, software development tools, text formatting tools, system management tools, telecommunications utilities, and complete documentation in a very hefty, 1,000-page, perfect bound book. Most of the Unix classics-grep, ed, sed, awk, lex, sh, emacs-are there as well. The only favorites that are missing are vi (which is a text editor) and Dave Korn’s new shell.

Whether Coherent’s views on the Unix system match your own is a matter of taste. In the halcyon late 1970s, the Unix system was a relatively simple affair-lean and clean, and understandable to mere mortals. Since then, in an effort to make Unix the universal solution, countless features and versions have been grafted onto it by innumerable programmers, managers, committees, and boards of directors.

The result stands in stark contrast to the stated goals of Unix’s inventors. Coherent remains true to Unix’s roots and eschews local area networking, graphical user interfaces, menus, mice, and many of the other amenities that present-day DOS users and Unix users have come to expect of modem software.

Coherent’s installation is painless, but only after the agony of freeing up a 7MB or larger partition on an ordinary MFM or RLL disk, on a classic AT architecture machine. Since they are products of the modem era, ESDI and SCSI disks, as well as IBM’s Micro Channel architecture are not supported. Graphic display adapters are tolerated (used in text mode); mice are not supported. Coherent worked flawlessly, though, on my geriatric AT clone.

Coherent has a dual boot facility, so that you can choose to boot either DOS or Coherent during your startup procedures, but unfortunately you can’t run
DOS software from within the Coherent environment.

Mark Williams’president Robert Schwartz explained that the intended audience for Coherent are people who want to learn about or try the Unix system, without the hefty price tag and steep learning curve of the latest Unix versions. Part of Coherent’s advantage in both simplicity and price stems from its origins as a privately developed “clone” product-therefore no AT&T requirements need be met and no per-copy royalty is paid to AT&T. This gives Mark Williams the freedom to set prices as well as compatibility targets.

But learning Unix from Coherent would be a bumpy road. You could certainly master traditional system administration, learn the utilities. And experiment with Unix software development. But you couldn’t learn about networking or the increasingly important X Windows system. Nor could you realistically use Coherent to automate a small business.

Schwartz promises that future versions of Coherent will support 32-bit operation on the 386, and will likely support tighter integration with DOS, some form of window manager. And local area networking. When that occurs, Coherent will be much more like modem Unix systems and, like modem Unix systems, it will have strayed far from its roots.

List Price: Coherent Version 3.0, $99.95.
Requires: A free 7MB or larger hard disk partition, 640K RAM, highly disk drive, MFM or RLL controller.

Mark Williams Co., 601 N.
Skokie Hwy., Lake Bluff. IL
(Kaare Christian)

And then it seemed to my teenage eyes something pretty underwhelming.  So I dove into OS/2, and ignored the idea of having a UNIX like system.  I was still happy to finally move onto a 16-bit machine, and the thought of running stuff from the 1970’s wasn’t that appealing. Such missed opportunities.  But in the last few years, Coherent has been placed under a 3-clause BSD license.

Over at unix4fun, they did unearth some version 3.0 disks!  And yes, it’ll install on PCem/86Box using a 286/386/486 machine.  One issue I had was I first tried to install onto a massive 40Mb disk, and it never would reboot after the install correctly.  However it works great with a 32Mb or smaller disk.  As you can see from Kaare’s review it’ll fit into 7MB of disk space!  At least having to either re-partition or worry about dual booting is a thing of the past.  The disk images are 5.25 disk images, so re-configure your VM appropriately.

Coherent on PCem

As the advertisement says, the installation is a mere four diskettes!  And yes, it really does have a C compiler.  You will need a serial number for Coherent 3.0, which took a while to find, but Peter had one, and has been poking me for the last week+ to finally write this up.  Oh the number is 130500000.  305/Miami connection? Unlikely, but who knows.  Don’t forget to download the hefty manual, Coherent_Revision_8_1992, which is for a later version, but still suitable.

And yes, it feels just like Unix v7.  The kernel is tiny, 77kb!  It’s really cool for 16-bit era stuff, and really interesting to knock around.  I know there is a few more people out there that want fun things for their 286, and Coherent will certainly scratch that itch.

Additionally on the site are the 3.1 and 3.2 updates to give you thinks like Elvis so it doesn’t feel anywhere near as primitive.  Installing updates and 3rd party packages is covered on page 736 of the manual, or in short you need to know the magical ‘disk set name’ for everything you want to install.  I suppose back then it had stuff like this printed on them.

coh300-ddk.img Drv_110
coh300-rdb.img rdb
coh31update-1.img CohUpd310
coh320update-1.img
coh320update-2.img CohUpd320
coh320-ddk.img

While a ‘dump’ of the source code has been out there, I haven’t really gone through it, so I thought now would be as good as any to take a look at the kernel.  The layout is very similar to v6, so I based this on the file ‘sys1.c’ which appears quite a few times in the trees.  Using a MD5 checksum against the files there appears to be no less than 17 duplicated tress or 7 unique kernels, spread over three years.

cc3b2bef09be7d60d52a01ca908972f7 Jul,24,1991 gtz/relic/d/kernel/USRSRC/coh/sys1.c
cc3b2bef09be7d60d52a01ca908972f7 Jul,24,1991 romana/relic/d/kernel/USRSRC/coh/sys1.c

41797301f9d5771dd10161954df82a5d Jan,13,1992 gtz/relic/d/286_KERNEL/USRSRC/coh/sys1.c
41797301f9d5771dd10161954df82a5d Jan,13,1992 romana/relic/d/286_KERNEL/USRSRC/coh/sys1.c
6b888a45afb3476c5e482fa54fb4dd86 Jul,17,1992 gtz/relic/b/kernel/coh.286/sys1.c
6b888a45afb3476c5e482fa54fb4dd86 Jul,17,1992 romana/relic/b/kernel/coh.286/sys1.c
6b888a45afb3476c5e482fa54fb4dd86 Aug,11,1992 gtz/relic/d/PS2_KERNEL/coh.286/sys1.c
6b888a45afb3476c5e482fa54fb4dd86 Aug,11,1992 romana/relic/d/PS2_KERNEL/coh.286/sys1.c
b90f2659fdecfbfa576d39bc8e54ffa0 Aug,11,1992 romana/relic/d/PS2_KERNEL/coh.386/sys1.c
b90f2659fdecfbfa576d39bc8e54ffa0 Aug,11,1992 gtz/relic/d/PS2_KERNEL/coh.386/sys1.c

6503663ebb9a852007a46d66cd43ac1a Jun,14,1993 gtz/relic/b/kernel/coh.386/sys1.c
6503663ebb9a852007a46d66cd43ac1a Jun,14,1993 romana/relic/b/kernel/coh.386/sys1.c
35bc7569ab99ab340d2ca8bf66a47c46 Aug,9,1993 romana/relic/b/STREAMS/coh.386/sys1.c
35bc7569ab99ab340d2ca8bf66a47c46 Aug,9,1993 gtz/relic/b/STREAMS/coh.386/sys1.c
436f245293c88ceaecd99840c37dcbb4 Nov,15,1993 gtz/hal/r10/coh.386/sys1.c
436f245293c88ceaecd99840c37dcbb4 Nov,15,1993 gtz/src/sys.r12/coh.386/sys1.c
436f245293c88ceaecd99840c37dcbb4 Nov,15,1993 gtz/src/sys.r12/coh.386/r12/sys1.c

Phew!  Naturally the tree structure drifted, but I went ahead and just did a blind import into my CVS server to take a look. And there really does appear in the 1991 versions to be the remnants of either 2.3.37, 3.2.1.  It’s hard to say.

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/

As requested, PCem v11 with networking

via SLiRP
via SLiRP

injecting networking was no more difficult than it was in version 10.  It’s only a few changes to pc.c, if you look at the USENETWORKING define you’ll see them.  The best notes are on the forum.

I haven’t changed or improved anything it still requires manual configuration.

Downloads are available on my site as pcem_v11_networking.7z.  You’ll have to defeat the password protection, as always.  I included the source, it ought to be trivial to rebuild.

*For anyone using an old version the ‘nvr’ directory is missing, so PC-em is unable to create new non volatile ram save files, meaning you always loose your BIOS settings.  Sorry I missed that one.

PCem v11 released

I haven’t had time to follow it, but great news!

PCem v11 released. Changes from v10.1 :

  • New machines added – Tandy 1000HX, Tandy 1000SL/2, Award 286 clone, IBM PS/1 model 2121
  • New graphics card – Hercules InColor
  • 3DFX recompiler – 2-4x speedup over previous emulation
  • Added Cyrix 6×86 emulation
  • Some optimisations to dynamic recompiler – typically around 10-15% improvement over v10, more when MMX used
  • Fixed broken 8088/8086 timing
  • Fixes to Mach64 and ViRGE 2D blitters
  • XT machines can now have less than 640kb RAM
  • Added IBM PS/1 audio card emulation
  • Added Adlib Gold surround module emulation
  • Fixes to PCjr/Tandy PSG emulation
  • GUS now in stereo
  • Numerous FDC changes – more drive types, FIFO emulation, better support of XDF images, better FDI support
  • CD-ROM changes – CD-ROM IDE channel now configurable, improved disc change handling, better volume control support
  • Now directly supports .ISO format for CD-ROM emulation
  • Fixed crash when using Direct3D output on Intel HD graphics
  • Various other fixes

Thanks to Battler, SA1988, leilei, Greatpsycho, John Elliott, RichardG867, ecksemmess and cooprocks123e for contributions towards this release.

Downloads are available for Windows & Linux.

FOOTBALL Design Document

Over at pcjs.org, this interesting prototype version of OS/2 has been unearthed.  What this means is that not only was there prototypes of a 386 aware version of OS/2 in 1986, but by 1987 the base of cruiser AKA OS/2 2.0 was already in place.  With this now somewhat made public, it really is clear that IBM’s meddling in OS/2 prevented it from being a success.

Check out the design document below:
The following text is from an email titled “3xBox Design Document” sent to the football alias on Saturday, February 28, 1987, at 5:02pm.

Overview

The goal for this research project was to demonstrate the feasability of supporting multiple virtual DOS 3.x machines on a 286DOS-based kernel running on an 386 personal computer. Each “3xBox” would have its own virtual screen, keyboard, interrupt vectors, and address space. Furthermore, well- behaved DOS 3.x applications that do text (as opposed to graphic) screen output would run in the background.

In order to acheive this goal in a reasonable amount of time, we started from the 286DOS “sizzle” kernel and made the minimum amount of changes necessary, both in code and fundamental design. The resulting DOS will be referred to as “386DOS” in this paper.

386DOS provides up to four 3xBoxes, depending upon the available RAM. More 3xBoxes could be supported if a slight change is made to the method of allocating page tables.

Well-behaved DOS 3.x applications (i.e., MS-Multiplan, MS-Word, Lotus 1-2-3) can run in the background, multi-tasking against one another and against the foreground screen group. Lotus 1-2-3 (version 2.01) passes its floppy-based copy protection when in the foreground.

It should be noted that 386DOS, while functional, is not an optimal design/implementation of multiple 3xBoxes. In particular, interrupt management, the device driver model, and the existence of V86-mode kernel code should be modified before 386DOS is made a commercial product.

Unless stated otherwise, most of the concepts extant in 286DOS apply to 386DOS.

V86 Mode and the 386

The 386 CPU has three distinct execution modes: REAL, PROT, and V86. REAL
and PROT modes are largely compatible with the corresponding modes of an 286.
V86 modes is exactly the same as RING 3 PROT mode, with the following
differences:

o Memory Address Hierarchy
A 386 has three levels of memory addresses:
– Virtual (Intel refers to this as Logical)
This is either the selector:offset or segment:offset address used by unprivledged machine language code.
– Linear
This is the 32-bit address arrived at either via a GDT/LDT
selector lookup, or via the 8086-compatible (seg << 4 + offset).
– Physical
This is the 32-bit address arrived at by pushing a linear address
through the paging mechanism. This is the address that the CPU
sends out on the bus to select physical memory.

When in V86 mode, the CPU performs the 8086-compatible computation.

o I/O instructions are NOT IOPL-sensitive
Trapping of I/O is done using the IO Permission Map.

o All instructions which modify or expose the Interrupt Flag ARE IOPL-
sensitive.
This allows the OS to simulate the Interrupt Flag, if desired.

V86 IRETD Frame

When any interrupt, trap, exception, or fault occurs in V86 mode, the CPU
switches to PROT mode and switches to the TSS Ring 0 Stack and builds the
following stack frame:

[[code]]czoyNDA6XCIKICAgICAgICAgICAgKDApIChvbGQgR1MpCiAgICAgICAgICAgICgwKSAob2xkIEZTKQogICAgICAgICAgICAoMCkgKG97WyYqJl19bGQgRFMpCiAgICAgICAgICAgICgwKSAob2xkIEVTKQogICAgICAgICAgICAoMCkgKG9sZCBTUykKICAgICAgICAgICAgICAgKG9sZHtbJiomXX0gRVNQKQogICAgICAgICAgICAob2xkIEVGTEFHUykKICAgICAgICAgICAgKDApIChvbGQgQ1MpCiAgICAgICAgICAgICAgIChvbGQge1smKiZdfUVJUCkgJmx0Oy0gKFNTOlNQKQpcIjt7WyYqJl19[[/code]]

CPU Mode Determination

A new implementation of the WHATMODE macro was written in order to distinguish
between the three CPU modes: REAL, PROT, and V86. REAL mode is indicated by
a 0 PE bit in CR0 (a.k.a. MSW on a 286). If the PE bit is 1, then the mode
may be either PROT or V86. These two modes may be distinguished by attempting
to change the IOPL bits in the FLAGS word. At Ring 0 in PROT mode (the only
place WHATMODE is used), the IOPL may be changed. In V86 mode, IOPL cannot
be changed. So, we change IOPL and then check to see if it changed. If so,
PROT mode, else V86 mode.

CPU Mode Switching

The 286DOS kernel relies extensively on switching inbetween REAL and PROT.
This functionality is provided by the RealMode and ProtMode routines.
In 386DOS, RealMode is no longer needed. As soon as we switch to PROT mode
during SysInit, the CPU only uses PROT and V86 modes.

Two new routines, ProtToV86 and V86ToProt, that are analogous to RealMode and
ProtMode. ProtToV86 is quite straightforward. We build a V86 IRETD frame
on the stack with the VM bit set in the EFLAGS image. We set the SS:SP
image to be equivalent to the stack just above the V86 IRETD frame, and
set the CS:IP image to instruction following an IRETD. Then, we issue the
IRETD and the CPU continues processing following the IRETD and in V86 mode.

V86ToProt is a bit trickier. The only way to get out of V86 mode is to
trap or fault or issue a software interrupt. We chose to use a software
interrupt, 30h, which we call the V86 Services interrupt. The INT 30h entry
in the IDT is a ring 3 interrupt gate, so issuing an INT 30 from V86 mode
causes a V86 IRETD frame to be built on the TSS Ring 0 stack and control
transfers to the INT 30h vector. The handler verifies that the INT 30h
was issued by the V86ToProt routine (checks CS:IP on the stack). If not,
the interrupt is reflected back to the requesting 3xBox (See Interrupt
Reflection). If it was V86ToProt, we clean off the stack frame and return to
the caller. NOTE: V86 Services is also used for completing the 386 LOADALL
used by PhysToVirt to map “high” memory in “REAL” mode.

Stack Switching

In order to maintain the 286DOS mode switch and stack switch semantics
when V86 mode is used, we have a new stack (the V86 Stack) in the 3xBox PTDA.

286DOS Modes and Stacks

The RealMode and ProtMode procedures in 286DOS are the only ways to switch
the CPU execution mode. These routines both maintain SS:SP, allowing
RealMode and ProtMode to be reentrant. The TSS Ring 0 stack is always the
current TCB stack in the current PTDA. The only other stacks in the system
are the Interrupt Stack and user stack(s).

386DOS Modes and Stacks

In 386DOS, any interrupt or exception while in V86 mode causes a switch to
PROT mode and the TSS Ring 0 Stack. So we have a new way to mode switch with
an incompatible stack semantic. We had to fix this mode switch to make it
compatible with 286DOS.

Observation

In V86 mode, the current stack must not be the TSS Ring 0 Stack. The CPU
only leaves V86 mode via an interrupt/exception, which causes a stack switch
to the TSS Ring 0 Stack. If the current stack was the same as the TSS Ring 0
Stack, then the stack might get corrupted. In 286DOS, the Ring 0 Stack is
the PTDA. Since we run on this stack in V86 mode, we need a new Ring 0 stack
when a 3xBox is running.

Approach

1) When a PMBox is running, the TSS Ring 0 Stack is a PTDA TCB stack.
+ This is consistent with the 286DOS model.

2) When a 3xBox is running, the TSS Ring 0 Stack is the “V86 Stack”.
+ The V86 Stack is allocated in the 3xBox PTDA.
+ If the cause of the mode switch can be handled without enabling
interrupts (e.g., interrupt reflection, IN/OUT trapping), we stay
on the V86 stack.
+ Otherwise, copy the V86 IRETD frame to the previous stack and
switch back to the previous stack.

Details

1) Leaving V86 mode
a. V86ToProt (analog of ProtMode)
+ Issue special V86ToProt software interrupt. If the interrupt
gate is DPL=3 (and it must be a 386 Interrupt Gate), then the 386
switches to Ring 0 (and the TSS Ring 0 stack) and transfers
control to the handler.
+ To ensure that 3xBox apps don’t use this feature, the interrupt
handler checks that CS=DosGroup and IP is in the correct range.
If not, then the interrupt is reflected (see below).
+ To make V86ToProt compatible with ProtMode, the interrupt handler
switches to the old stack (we get SS:ESP from TSS Ring 0 stack,
which is where we are running).
+ Finally, V86ToProt restores saved registers and flags from the
stack and returns to caller.

b. Software interrupt
+ GP-Fault handler reflects to 3xBox IVT handler in V86 mode.
o Add IRET frame on old stack, taking IP, CS, FLAGS from
TSS Ring 0 Stack.
o Look up handler in 3xBox IVT.
o Edit TSS Ring 0 Stack EIP and CS to point to IVT handler.
o IRETD
+ IVT interrupt handler IRET uses IRET frame we built on old stack.

c. Hardware interrupt
+ To make this operation compatible with 286Dos, the interrupt
handler copies the V86 stack from the TSS Ring 0 stack to
the old stack, then switches stacks to the newly modified old
stack. This allows the Interupt Manager to do an IRETD to
get back to the correct mode.

d. Exception
+ Remain on V86 stack, process exception, and IRETD.

2) Entering V86 mode
a. ProtToV86
+ Build V86 IRETD frame on current stack and IRETD.
b. LinToVirtDM_HANDLE
+ Execute 386 LOADALL with VM bit set in EFLAGS image in loadall
buffer.

Interrupt Management

All software interrupts, hardware interrupts, and CPU traps and exceptions
are vectored through a common IDT, regardless of whether the CPU is in PROT
or V86 mode.

NOTE: Background 3xBoxes get no hardware interrupts. In the commercial 386DOS,
this restriction can be relaxed so that interrupts, other than for the
keyboard and mouse (since those are implicitly for the foreground box),
can be given to background 3xBoxes.

Passing Hardware Interrupts to the Foreground 3xBox

In the interrupt manager:

IF a 3xBox is foreground -AND-
the current mapped 3xBox is background
THEN
MapIn foreground 3xBox;
Dispatch interrupt;

And to make things more interesting, from the later version of FOOTBALL, oddly enough version 4:

OS/2 FOOTBALL Boot Disk (v4.41.00)

This disk contained an updated version of OS/2 FOOTBALL Boot Disk (v4.41.00). It was built in December 1987, using final OS/2 1.0 sources merged with assorted FOOTBALL changes, and although it was originally assigned version number 1.3, this version of OS/2 would ultimately become 2.0.

It crashes on an 80286, jumping to invalid code immediately after performing a processor check. On an 80386, the following version banner is displayed:

[[code]]czoxNzU6XCJPcGVyYXRpbmcgU3lzdGVtLzIgIFZlcnNpb24gMS4zMAooQykgQ29weXJpZ2h0IE1pY3Jvc29mdCBDb3JwLiAxOTgxLCB7WyYqJl19MTk4NywgMTk4OC4KKEMpIENvcHlyaWdodCBJQk0gQ29ycC4gMTk4MSwgMTk4Ny4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KCkludGVybntbJiomXX1hbCByZXZpc2lvbiA0LjQxLjAwLCAxMi8wMi84NwpcIjt7WyYqJl19[[/code]]

The numbering of revisions must have been, um, revised, because despite the lower revision (4.41.00 vs. 7.68.17), it is newer than the 7.68.17 prototype. This is confirmed by the boot message (12/02/87), the file dates (12-23-87) and the higher version number (1.3).

Windows 3.0 Debug Release 1.14

Well from popular request I finally got around to loading this up.  I went ahead with my favourite retro emulator, PCem for this, as it can nicely emulate an EGA display, unlike most emulators which do VGA, however when it comes to older versions of Microsoft products they really can detect the difference between EGA and VGA.

So to start off, I downloaded from the project page, this version of PCem, compiled it, and installed MS-DOS 4.01 , from April of 1989.  The Windows 3.0 Debug Release 1.14 itself is dated from February 22nd, 1989.  Which I figured is close enough to the time period.  I’m using the 486SX2/50 because I’m too impatient for the 386 speeds, but it does work fine on 386 or higher emulators.  It does NOT work with any 286 emulation. I’m also using the HIMEM.SYS from MS-DOS 4.01 vs the one with the Windows 3.0 (Alpha? Beta? Technical Preview?) since it is slightly newer.

There is no setup program per say, rather it just xcopies all the files to a directory, and from there you run ‘d.bat’ and away you go.  This version is hard coded to an EGA display, which again is the reason I went with PCem.  Once you start it up, you are greeted with:

Win
Windows v3.0 Debug Release 1.14

And it identifies itself as Windows Version 2.1

w
Look at all the memory!

And first thing to notice is that on my setup with 8MB of ram, I have over 6MB of RAM free.  Compare this to regular Windows 2.1 which gives me 399Kb of ram in my current setup.

Windows 2.1 running in real mode
Windows 2.1 running in real mode

And with Windows/386 Version 2.1 it provides 383Kb of real memory, along with 6.7MB of EMS memory, as the Windows/386 Hypervisor includes EMS emulation.

Windows/386 memory
Windows/386 memory

Of course the major limitation of Windows 2 is that it runs in real mode, or in the case of Windows/386 an 8086VM.  As I mentioned a while back in a post about Windows 3.0,  This was game changing.

As now with Windows running in protected mode, all the memory in my PC is available to Windows, and I am using MS-DOS, with nothing special.

Besides the limitation of being EGA only, the Debug version of 3.0 is that there is no support for MS-DOS applications, as WINOLDAP.MOD is missing.

NO MS-DOS for you!
NO MS-DOS for you!

This is clearly an interim build of Windows 3.0 as mentioned in Murray Sargent’s MSDN blog Saving Windows from the OS/2 Bulldozer.  As mentioned from the article they began their work in the summer of 1988, so considering this is early 1989 it shows just how much progress they had made in getting Windows 2 to run in protected mode.  Along with Larry Osterman’s MSDN blog post Farewell to one of the great ones, which details how the Windows 3.0 skunkworks project was writing the new improved 386 hypervisor, and how Windows 3.0 got the green light, and changed the direction of not only Microsoft but the entire software industry.

I’ve been able to run most of the Windows 2.1 applets, however I’ve not been able to run Excel 2, or Word 1.  I suspect at this point that  only small memory model stuff from Windows 1 or 2 is capable of running.  Although at the same time, when 3.0 did ship, you really needed updated versions of Word 2 and Excel 3 to operate correctly.

Windows 3.0 Debug Release 1.14
Windows 3.0 Debug Release 1.14 on a 12MB system

The applets from Windows 2.1 seem to work a LOT better than the one from Windows/386 2.1 if that helps any.

This is an interesting peek at an exceptionally early build of Microsoft Windows.

PCem

PCem v9
PCem v9

From the main page:

PCem v9 released. Changes from v8.1 :

  • New machines – IBM PCjr
  • New graphics cards – Diamond Stealth 3D 2000 (S3 ViRGE/325), S3 ViRGE/DX
  • New sound cards – Innovation SSI-2001 (using ReSID-FP)
  • CPU fixes – Windows NT now works, OS/2 2.0+ works better
  • Fixed issue with port 3DA when in blanking, DOS 6.2/V now works
  • Re-written PIT emulation
  • IRQs 8-15 now handled correctly, Civilization no longer hangs
  • Fixed vertical axis on Amstrad mouse
  • Serial fixes – fixes mouse issues on Win 3.x and OS/2
  • New Windows keyboard code – should work better with international keyboards
  • Changes to keyboard emulation – should fix stuck keys
  • Some CD-ROM fixes
  • Joystick emulation
  • Preliminary Linux port

Thanks to HalfMinute, SA1988 and Battler for contributions towards this release.

Very excellent!

OpenWatcom v2

I know what you are thinking, wouldn’t it be great if you could create MS-DOS executables directly from a Win64 desktop with no MS-DOS needed?

Well, I just found out about this unofficial Open Watcom v2 project that targets the usual suspects, allows you to compile from Win64!

Hello World!
Hello World!

Some of the features of this fork include:

  • New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
  • Code generator properly initialize pointers by DLL symbol addresses
  • DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
  • OW is ported to 64-bit hosts (WIN64, Linux X64)
  • Librarian support X64 CPU object modules and libraries
  • RDOS 32-bit C run-time compact memory model libraries are fixed
  • Resource compiler and Resource editors support WIN64 executables
  • OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or configuration
  • Broken C++ compiler pre-compiled header template support is fixed
  • Many C++ compiler crashes are fixed
  • Debugger has no length limit for any used environment variable

Binaries are available on sourceforge.

So how does it fare?  I thought I’d take the old Wolf4GW, and compile it with this toolset.  The first hurdle I hit was this fun feature:

  • The C++ compiler now treats warning W737, implicit conversion of pointers to integral types of same size, as an error.

Which is an integral part of wl_menu.cpp .  So this was somewhat problematic, until I just commented out that block, and while I was expecting no working keyboard, I’m able to play, and load/save games…. Even the boss key works.

Wolf4GW
Wolf4GW

So with the W737 taken care of, I have to say this thing compiles FAST.  Incredibly FAST.  If for some reason you have to build 16bit or 32bit anything, you should look at a 64bit tool chain, well assuming you have a 64bit computer by now.

If anyone want’s to build their own Wolf4GW with the newer OpenWatcom, my source drop is here.

PCem v8 released!

New features include:

  • New machines – SiS496/497, 430VX
  • WinChip emulation (including MMX emulation)
  • New graphics cards – S3 Trio64, Trident TGUI9440AGi, ATI VGA Edge-16, ATI VGA Charger, OAK OTI-067, ATI Mach64
  • New sound cards – Adlib Gold, Windows Sound System, SB AWE32
  • Improved GUS emulation
  • MPU-401 emulation (UART mode only) on SB16 and AWE32
  • Fixed DMA bug, floppy drives work properly in Windows 3.x
  • Fixed bug in FXAM – fixes Wolf 3D, Dogz, some other stuff as well
  • Other FPU fixes
  • Fixed serial bugs, mouse no longer disappears in Windows 9x hardware detection
  • Major reorganisation of CPU emulation
  • Direct3D output mode
  • Fullscreen mode
  • Various internal changes

pretty cool!

You can find the source code, binaries, and some ROMs on Tom’s Page.  I’ve got to say I really like PCem, it gives the full (slow and painful, like the real thing) retro PC experience!