Back in the olden days of when Microsoft had pivoted out of OS/2 in a hurry, I’ve always felt that the common ‘OMF’ objects ought to link for OS/2. But for some reason I never tried. But for some reason I thought I’d try it today.
I first installed Microsoft C 6.0, and set it up for a native OS/2 to OS/2 1.2 setup. This way I get a pure OS/2 include/library directory set. In retrospect, I don’t know why I didn’t just use 2 include / library directory sets to far easier target stuff, without dealing with changing the default names, and making linking an all around living hell.
So the first thing to do is to tell QuickC for Windows to default to the OS/2 include directory (turns out it wont link anyways). Compiling is nothing special. When setting up the project you’ll need a DEF file, I use this simple one:
NAME QCO2 WINDOWAPI
Nothing to it!
I tried to fight the Windows linker, but it figures out what you are doing and won’t do it. But can you manually link? Well QuickC for Windows does include a DOS linker, and it’s oddly enough newer than the one for Microsoft C 6.0!
C:\proj\o2>msdos \WIN16APP\QCWIN\bin\link hi.obj
Microsoft (R) Segmented-Executable Linker Version 5.15
Copyright (C) Microsoft Corp 1984-1991. All rights reserved.
Run File [hi.exe]:
List File [NUL.MAP]:
Libraries [.LIB]: doscalls SLIBCE
Definitions File [NUL.DEF]: qco2.def
This program cannot be run in DOS mode.
Manually invoking the linker wasn’t all too hard, just answer the 30 questions. I did set the LIB environment variable so it picked up the libraries just fine. And yes, it created my OS/2 binary no problem!
And as you saw from above, yes it does run!
I do suppose the graphical editors would have been nice some 30 years ago, but in today’s era, sadly it doesn’t matter. QuickC for Windows won’t run under WLO, so this prevents it being a backdoor GUI/Protected mode compiler for OS/2. It’s a shame too as at least running under Windows 3.0, QuickC for Windows is WAY faster than using Microsoft C 6.00 in either read mode, protected mode with smartdrive.. I’m not sure what the deal is. Even with the advanced caching SCSI controller.
So I had gotten this Boca Ram/2 card with 2MB of RAM, with space for an additional 6MB. Unfortunately trying to find matching memory has been a lost cause. Since the existing memory is 9 chip modules, I take that to mean it’s parity RAM, so I went shopping for much more available 3 chip modules.
I picked up 2x 1MB modules for £10.
Slotting them carefully into the ram card, taking great care as the clips are plastic!
Now from what I can remember being told is to never ever ever mix memory types like this. But logically I have to think that 9×1 = 4+4+1, right? RIGHT?!
I copied the @7A7A.ADF onto the reference disk image, slotted the card and booted up to the config, and toggled the card to 4M
I didn’t trust the auto-config, plus I just wanted to see what was there. Also I’ve always wondered if the PS/2 model 60 (or 30? 50z?) can slot higher density than the 256kb SIMM’s that IBM had used. I guess one day I’ll give it a shot.
Anyways thinking that this is about done, I save the config and reboot and now It’s Bocaram/2 issues.
Immediately, on reboot I get error 164.
164 POST detected a base memory or extended memory size mismatch error.
1. Run F1 Setup. Check System Summary menu for memory size change. 2. Run the Extended Memory Diagnostic tests.
Booting from the reference disk just crashes the PC.
Pressing F1 however does let you boot, ignoring the issue.
After a bunch of digging I found this zip file with some utils. And just guessing br2pmems ‘fixes’ the CMOS settings allowing the machine to boot normally.
So now it’ll recognize the 5MB of RAM, and just boot normally. GREAT. But booting the reference disk still hangs the machine.
Which then brings me to the next upgrade:
The IBM SCSI with Cache aka the SPOCK. Since I ruined the one SCSI card, and ended up picking up a second card, but this time with the appropriate cable I’ve caused a massive market panic on Microchannel SCSI cards. Seriously check eBay, and you will see that the pricing has collapsed with many now selling in the £20-30 range. You’re welcome!
Not really wanting a 3rd SCSI card, but my eye saw this one with the cache RAM, and I figured if I wanted the ultimate PS/2 of course I’d want a caching controller. This looks to be the first rev of the PCB, but with the ‘hot fixes’ in place from the second rev. While the ROMs are stepping back to 1990, I don’t care much about the 1GB disk limit, as the BlueSCSI can emulate all the available devices in the chain, so I’m not losing anything in the way of capacity. This is a 286 after all.
Since the RAM card screws up the setup program, I have to remove it, and the old SCSI controller, re-configure the system with all the RAM and disks removed first. Then put in the new controller, and re-run setup.
I just accept the defaults, and reboot to check what happened. So far it looks good, slot 8 being near the middle of the PCB, and closer to the disk cage where the blue SCSI rests.
Remembering that the IBM controllers inventory the disks backwards, the 380MB disk image on SCSI ID 6, is the primary boot disk. I didn’t set it to the full 1GB as I want to later see how older versions of DOS/OS2 work with this, and I know they have issues with disks bigger than 512MB, but I figured matching a disk that did exist in 1988 would be more realistic.
With the SCSI setup, I could put the troublesome Boca board back with the RAM, and get my system booting up with the new “faster” SCSI controller, and all that new RAM.
Of course I did a few benchmarks on the old SCSI controller so I would know how much more awesome the new one is.
As you can see this is booted with my normal config.sys with a himem.sys and smartdrv from Windows 3.1 on a MS-DOS 5.1 install.
2,345.8 KB/sec With himem.sys & smartdrv
2,347.5 KB/sec with no himem.sys
2,316.6 KB/sec with runtime xmsmmgr & smartdrv
2,334.0 KB/sec with Windows 3.1 himem.sys no smartdrv
So, with these scores in hand, you can see that the penalty for various XMS memory access being turned on is there, but it’s nowhere near as massive as I’d have thought for performance. Even with it just being there, although again it’s so minimal.
Now for the real shocker:
That’s right, the advanced card is slower. A good 11% slower. Well, that was disappointing. I’m still keeping it in the machine, as having a hardware caching controller was all the rage, just like Mach microkernels. Maybe it’d make more of a difference in a 32bit system, but it’s performance is very underwhelming. For anyone wondering, the WDC AC2340, is an EIDE 340MB hard disk, with a 64kb cache. Im sure it was considered very fancy, and fast for the era, and it’s nice to know that no matter the SCSI controller, the BlueSCSI blows it out of the water. Also keeping in mind that MFM data transfers are usually sub 400KB/sec, so this is much more faster.
Okay you have all this XMS what are you going to do with it?
Well, after I did manage to get this original copy of Word for Windows 1.0, I thought that it would be a good test. One fun thing is that it includes the ‘runtime’ version of Windows 2.11, which can also upgrade an existing install of Windows 2 if detected. Running Windows 2 on MS-DOS 5, does involve loading the setver command in the config.sys, and rebooting. Windows 2 cannot use XMS (more on that) but instead uses the older LIM EMS standard that allows a 64kb page to be viewed from a far larger card. Since the 8086/80286 still use 64kb segments it’s not all that crazy to use.
And that brings me to this great program EMM286!
It allocates a 64kb page in low ROM, and backfills it from XMS. So I give it 3MB, and now I have 1.3MB of XMS left, and 3MB of LIM EMS ready for Windows!
So now I have EMS & XMS! And didn’t have to get some pesky EMS board either. I am pretty sure you need device drivers to use EMS, so how do you use LIM EMS under OS/2 1.x? I have no idea. Probably not I guess?
Anyways I run word, everything is great, it sees extra ram. I exit windows, and unload EMM286, and ..
3.4MB of XMS available? Somehow I lost a megabyte of RAM from Windows 2?! I’m not sure what is going on, or why or how Windows even touched it. Needless to say if you want it back, you need to reboot.
That’s right 494KB free! I thought MS-DOS under OS/2 just used some stubs in real mode, and called back to protected mode. No doubt this is totally wrong, there has to be some weird version of DOS+OS2 that actually runs in real mode going on here. I know that ‘bimodal drivers’ were a thing, but it sure seems like there really is a ‘real mode OS/2’ kernel with MS-DOS tacked onto the side.
It’s annoying OS/2 can’t tell you how much ram it sees and what is in use, but at least Windows 3.0 can. It’s more than enough to run Sim City, clearly making this one of the more expensive machines to run the game as intended. With the added RAM it doesn’t thrash as hard, but having emulated disks probably doesn’t matter as much as access time is always zero, and it’ll stream data as fast as it can. You can feel the difference moving between tasks, but things like the OS/2 file manager that loads a view into every directory is still incredibly slow. What were they thinking?!
Back in the day this would have been an incredibly expensive upgrade. And is it worth it? The machine is still locked at 10Mhz. The FPU is also locked at 10Mhz, and you can feel it. The lightening fast disk access, despite it being some 11% slower is really hard to tell. Does the caching help at all? Applications don’t have to page in/out like crazy before as there is enough RAM to actually run them, but that is where the 10Mhz processor just isn’t there.
Just like the caching SCSI controller, I’m sure we’ve all heard how having that magical EMS memory would help out games like Wing Commander.
Well, I had to put them side by side, as I couldn’t believe it, but adding EMS made it noticeably slower. I was *NOT* expecting that. I should add that I used Vegas & this quick tutorial, on how to pan & resize one video to get them side by side. No doubt it’s not perfect but it’s enough to see that once the ship explodes, the performance on the EMS configuration is greatly throttled. It’s moments like this that makes me wonder is this something the caching SCSI card would do better implicitly? Or is it snake oil as well?
3MB is enough to load OS/2, and one application, just as Word v1 or Excel v2/v3 load just fine, but swapping between them is basically unloading one from memory, and loading the other back out to disk. It’s a shame RAM cost so much 1987-1992 as people really could have benefited from it. It’s just utterly bizarre that on such an outrageously expensive system that you even need RAM upgrade cards, it really should have been baked into the main logic board.
Well like everything else, once you know what to do, its pretty self explanatory and easy. But until that point it’s a lot of trail and error.
The PS/2 model of computers went away from the PC/XT/AT design for something that would be more toolless and allow for more automation in the building & assembling of these machines. That means they removed loose wiring where possible to give not only great airflow, but an overall clean aesthetic to the PS/2 build. What this also means is that the old 34pin floppy ribbon will not do.
The PS/2 version uses and edge connection and integrates the 5v/12v power rails into the interface. You can try to add an old floppy to the mix, but there is 5 pins that need to be held high through a resistor pack to get an old floppy drive working. I didn’t want to fight it that much so instead I ordered an adapter from eBay, being sold by markgm.
After much trial and error I found
After a lot of trial and error I found jumpering it for S0 was what worked. While I had read that JC was also needed, it just didn’t work when I tried. S0 puts the gotek into the first floppy position, in the older PC/XT/AT’s they jumper every drive as S1, but have a twist in the cable to negate it on the primary position.
The other catch is that it absolutely required a FF.cfg file
interface = ibmpc-hdout
Even though so many other systems didn’t need it, mine sure did. And Obviously I flashed my drive to the latest version of flashfloppy (3.41 as of now.). That also meant checking the processor type, which, is simple enough to check by opening it up, and setting your camera to maximum zoom.
Or checking the gallery of microcontrollers in the various Gotek’s. The prices have shot up dramatically over the last few years for unknown reasons, so they switched to from the ST to the AT line or similar processors.
Can’t say I blame them.
So with the drive updated, and config file loaded, along with a disk image, it finally booted up!
And with that in place I was able to boot the reference disk, and setup the system. The inside is a bit ugly but, I wanted to get this thing fully loaded, so I picked up an 80287-10.
One interesting thing about the PS/2 line of machines is that the 286’s could run their math coprocessors in synch. The IBM-5170/AT ran it asynchronously at 2/3rds the clock value. I would have imagined they convinced someone somewhere how at big step up from a 6Mhz 80286 & 4mhz 80287 to get into a PS/2 model 50/60 with a blistering 10Mhz 80286/287.
Happily the 80287-10 I had gotten from fractal2015, worked just fine.
I’m waiting still for some cables to hook up the bluepill to the SCSI card, and the memory card, so I can run meaningful applications like SimCity for Windows, and OS/2.
In the meantime I can do simple stuff from floppy. I’m still trying to keep an eye out for either an ethernet card, or a Token Ring card & MAU, along with cisco cards to at least let me use NetBEUI.
But for anyone else needing a solid answer on how to get the Gotek working with an IBM PS/2 model 60, here you go!
With the pre-christmas release of the Microsoft OS/2 betas 1.00, 1.01, 1.02, 1.03 & 1.05 on archive.org, and helping Ncommander with an upcoming video, it seemed like a good place to start, not with OS/2 but rather with MS-DOS 4.0.
Microsoft started work on a multitasking version of MS-DOS in January 1983. At the time, it was internally called MS-DOS version 3.0. When a new version of the single-tasking MS-DOS was shipped under the name MS-DOS version 3.0, the multitasking version was renamed, internally, to MS-DOS version 4.0. A version of this product–a multitasking, real-mode only MS-DOS–was shipped as MS-DOS version 4.0. Because MS-DOS version 4.0 runs only in real mode, it can run on 8088 and 8086 machines as well as on 80286 machines. The limitations of the real mode environment make MS-DOS version 4.0 a specialized product. Although MS-DOS version 4.0 supports full preemptive multitasking, system memory is limited to the 640 KB available in real mode, with no swapping.2 This means that all processes have to fit into the single 640 KB memory area. Only one MS-DOS version 3.x compatible real mode application can be run; the other processes must be special MS-DOS version 4.0 processes that understand their environment and cooperate with the operating system to coexist peacefully with the single MS-DOS version 3.x real mode application.
Because of these restrictions, MS-DOS version 4.0 was not intended for general release, but as a platform for specific OEMs to support extended PC architectures. For example, a powerful telephone management system could be built into a PC by using special MS-DOS version 4.0 background processes to control the telephone equipment. The resulting machine could then be marketed as a “compatible MS-DOS 3 PC with a built-in superphone.” Although MS-DOS version 4.0 was released as a special OEM product, the project–now called MS-DOS version 5.0–continued. The goal was to take advantage of the protected mode of the 80286 to provide full general purpose multitasking without the limitations–as seen in MS-DOS version 4.0–of a real-mode only environment. Soon, Microsoft and IBM signed a Joint Development Agreement that provided for the design and development of MS-DOS version 5.0 (now called CP/DOS). The agreement is complex, but it basically provides for joint development and then subsequent joint ownership, with both companies holding full rights to the resulting product.
As the project neared completion, the marketing staffs looked at CP/DOS, nee DOS 5, nee DOS 4, nee DOS 3, and decided that it needed…you guessed it…a name change. As a result, the remainder of this book will discuss the design and function of an operating system called OS/2.
– Inside OS/2.
Although MS-DOS 4.00M disk images have been floating around for quite some time, either a 2 360k disk set, or a single 720k disk image, I don’t think anyone (including me) really tore into it that much. It does have the ability to freeze DOS 3 programs, giving the illusion of running more than one. The session manager is pretty sparse but hitting left alt twice will pop it up giving you the ability to toggle through programs with ease.
There is a FDISK, FORMAT & SYS command making it straight forward to setup a hard disk, and copy the files over, I didn’t see any installer.
there is a PS command to show running processes. Also there is a DOSSIZE to show the memory partitioning and how much is available. Although there is a SWAPPER program I’ve been unable to get it to actually fun.
Another interesting thing if you run the unix ‘strings’ command against all the EXE’s you’ll find the string:
C Library - (C)Copyright Microsoft Corp 1985
Implying that not only was DOS 4.00M a ‘new’ DOS, but it was also written in C. No doubt this contributed to a larger file size than DOS 3, however it would also give that holy grail of portability, at least to new CPU modes. Also many files have the name of the source files baked in such as:
Okay so far, so good. But we’ve all seen this before, and scratched this OS about this far, because what else can you do? It’s not like there is any dev tools to do anything fun!
Well the tool hidden in plain sight is LINK4, which in retrospect is specific for MS-DOS 4.00M.
Microsoft (R) 8086 Object Linker Version 4.01
Copyright (C) Microsoft Corp 1984, 1985. All rights reserved.
Object Modules [.OBJ]:
There is no SDK for MS-DOS 4.00M, but they were kind enough to leave the linker in place. A quick check of the Windows 1.01 SDK shows that it also includes LINK4:
Microsoft 8086 Object Linker
Version 4.00 (C) Copyright Microsoft Corp 1984, 1985
Object Modules [.OBJ]:
It appears that if the dates and versions are to be trusted they are of the same vintage, but the Windows linker is older, and that they both output to a NE or New Executable. So to start the experiment I created a simple hello world exe from a simple:
printf("Hello from MSC 3\n");
To compile this I used Microsoft C 3.0 (more on why later), and used LINK4 to create an EXE:
C:\dos\msc3>cl /c hello.c
Microsoft C Compiler Version 3.00
(C)Copyright Microsoft Corp 1984 1985
C:\dos\msc3>msdos dos4m\link4 hello.OBJ
Microsoft (R) 8086 Object Linker Version 4.01
Copyright (C) Microsoft Corp 1984, 1985. All rights reserved.
Run File [HELLO.EXE]:
List File [NUL.MAP]:
Definitions File [NUL.DEF]
Okay, everything looks fine so far. Attempting to run this under MS-DOS just results in the error:
Program too big to fit into memory
Well now that’s odd. Checking the EXE with the Linux ‘file’ command reveals:
HELLO.EXE: MS-DOS executable, NE (unknown OS 0) (EXE)
So obviously it’s a NE, but it is an older/unknown version to the file map database. There is no stub so I suppose that is why MS-DOS is getting confused.
Now let’s try MS-DOS 4.00M
Well now isn’t that interesting?!
Excited with the ability to create special MS-DOS 4.00M programs, I get my favorite vintage ’87 Infocom interpreter, InfoTaskForce 87, and get it building on MSC 3.0. However instead of using the MS-DOS 4.00M linker, I thought I should try to use the Windows 1.01 linker and libraries for the exe:
DESCRIPTION 'Infocom 87 interpreter for Planetfall(83)'
HEAPSIZE 1024 ; Must be non-zero to use Local memory manager
STACKSIZE 4096 ; Must be non-zero for SS == DS
; suggest 4k as minimum stacksize
_INIT PRELOAD MOVEABLE DISCARDABLE
One thing to save you the horror is that between MS-DOS 2 & 3 the way command line arguments changed. I forget the details but no matter what I tried I was unable to parse the CLI or the environment in this setup. I suppose if I had documentation of the product there would be some hint as to what tools or setup to use. Instead, I took the easy way and hard coded to load Planetfall.
Unfortunately, this success would prove to be the exception to the rule. I took trek, converted it to K&R C, as Microsoft C 3.00 from 1985 is well. old, and sadly it just won’t run. Likewise, I took Hack 1.03 and although it runs on MS-DOS it will not run on MS-DOS 4.00M. I am sure there is some fundamental reason why it’s not working, and probably tied to creating a proper DEF file. I’m sure it was all written down somewhere but I don’t know. And yes I tried specifying either floating point emulation via library or inline, and it made no difference.
Looking at OS/2 1.00
Loading up the infamous $3,000 OS/2 1.00 beta, and hitting ctrl+escape you are greeted with session manager!
Notice the R for real-mode. With the obvious implication that everything else is protected mode. Going one step further on the excellent site pcjs.org there is OS/2 betas SIZZLE and although there is no OS/2 development bits on there, the directory DOS3TOOL reveals that the C compiler for this era for at least MS-DOS is MSC 3.0. Also included is our friend LINK4.
I create a simple def file that contains the single word ‘PROTMODE’ which should give me my OS/2 binary.
So let’s run that through hello world:
msdos sizzle\DOS3TOOL\link4 hello.OBJ,hello,,,hello.def;
Microsoft (R) Segmented-Executable Linker Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986. All rights reserved.
However attempting to run this just crashes amazingly.
No doubt it’s because the real-mode libc is using interrupt 21 calls, which OS/2 sure wouldn’t like. I’m pretty sure it requires an OS/2 libc that uses DOSCALLS.DLL to function, which I just don’t have any pre-release versions, nor any libc source code to really make it possible. And attempting to port one to OS/2 pre-releases just doesn’t seem so worth the time.
So for the heck of it I point the LIB variable to the OS/2 1.00 SDK’s libs and re-run the link:
C:\dos\msc3>msdos sizzle\DOS3TOOL\link4 hello.OBJ,hello.exe,hello.map,C:\86box\100\x\MSC\LIB\slibc5.lib \86box\100\x\LIB\DOSCALLS.LIB,hello.def;
Microsoft (R) Segmented-Executable Linker Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986. All rights reserved.
By default it’s trying to link in EM.LIB, SLIBFP.LIB, SLIBC.LIB. Trying to add them all in the command line link just hangs LINK4 maybe a response file is better suited. Anyways:
It does run on OS/2 1.00, which I guess isn’t surprising as the LINK4 & libraries are from/for this version.
As an interesting note, OS/2 links against doscalls library/DLL to interface to the OS. While MS-DOS 4.00M doesn’t have a seperate DLL, rather it’s baked into IBMDOS.COM
Noticeably absent is file I/O, No doubt allowing programs to use the standard int21 interface to the kernel for file I/O. No doubt this is in its primordial state, as the OS was going to evolve a bit more until it became OS/2. Unfortunately I have no idea how to link or call into this. Without any SDK it’s impossible to say. And even then is developing for a real mode OS worth the effort?
So what have we learned? LINK4, aka the MS-DOS 4.00M Linker, probably should have been called LINKNE for the NE format. Also there is references to it having it’s own virtual memory paging system, and being able to link larger EXE’s than the traditional link command. Sadly I was unable to get any non trivial programs running. I don’t think it was a memory model thing, although the C compiler has issues with InfoTaskForce and the large memory model for some reason, but small & medium work fine. I’d like to think that DOS 4.00M could support massive EXE’s much like Windows 1.01, however despite being from the same company and using the same tools, the memory manager for DOS 4.00M & Windows is fundamentally different.
With all these exiting OS/2 betas now available I’ll have to take some more time to explore them in more detail.
But until then I thought this genesis of DOS 4.00M was worth the look.
One of the more interesting things about OS/2 1.x is how it had this interesting idea of how to strattle the bridge between old and new, and it was a very common bridge tactic where you can have a shipping program that can simply run in both the older operating system, and the new one. Naturally there is trade offs, you can’t fully take advantage of all kinds of features on the new side, you will be largely held back on the old side, but all is not lost, there is space for things that fit in the ‘same but bigger’ world where you have an overlap between old and new.
For OS X, this was the Carbon era, for Windows this was the famous Win32s extensions, and for OS/2 it’s the Family API.
As a quick example, allocating memory under MS-DOS may be limited to 640kb, but under OS/2 you have access to so much more memory, the entire capacity of an IBM AT class machine. And this also got OS/2 tools into a lot of MS-DOS developer’s hands as the early compilers and tools were built around the Family API and were able to run on so called legacy environments. Although it was far better to run on OS/2, the advantage 30+ years later is that MS-DOS emulation is more common and prevalent than OS/2, especially on non x86 processors.
As an added bonus you really don’t have to mess with the API at all, as the LIBC will use it no doubt.
At any rate, using Microsoft C 6.00 (I can’t get the syntax right for 5.1 to save my life, I suspect I need to run it UNDER OS/2 to build for OS/2 properly), you can compile a typical stdio compliant program, and get an OS/2 executable.
The real fun is from the bind program which will convert that OS/2 program to a full Family mode app with the bind program.
And now on MS-DOS (Under OS/2) you can see very quickly that the OS/2 app won’t run, however the family mode one does!
So this is what let’s me run the older SDK tools as I’d simply forgotten about this great mode, letting you run programs in either environment.
Of course the added fun is the 3rd party product Phar Lap’s 286|Dos-Extender that provides some OS/2 services under MS-DOS in addition to greater memory but DLL’s! But that’s for another story.
**EDIT Oh and another edit, here is how to make the OS/2 program ‘window’ compatible with a link time definition file:
and then on the console:
And there we go with some magical flags & def file it’s now marked as being compatible with window mode. So no full screen VIO tricks for you!
The new dynamic recompiler appears to be much more faster, although if you want maximum performance, make sure to set your video card to the fastest possible performance.
I was doing my typical DooM thing, and the performance was abysmal. But I did have an 8bit VGA card selected, so what would I really expect? Interestingly enough in ‘low resolution’ mode it performed quite well, but setting it to the artificial ‘fastest PCI/VLB’ speed it was performing just great.
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… 🙂
I don’t know why I was so dumb as a kid, but I remember thumbing through various magazines, and always seeing this 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.
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.
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.
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.
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
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.