DOSBox… in a box!
I don’t know why I never tried it before, but it actually works! And it’ll even spawn out to a window two. Although without share/record locking it’ll end up being a world of pain, I suspect. Maybe vDOS/vDosPlus will work? I know it’ll work fine if you boot MS-DOS inside of DOSBox, but for some reason I never actually tried to stress the v86 mode of DOSBox from within Windows.
It’s that awkward time of the year when those of us that still have to work feel as if we really should be on vacation…Â But here we are flipping your burgers and keeping the lights on.
Oh and I thought it’d be fun to do one last giveaway for the year. And a good one too, DooM 3 BFG!
As always, I have 5 keys. So to the first 5 people!
And people think this last star wars movie was flawed!
HA!
(This is a guest blog post by Antoni Sawicki aka Tenox)
A Christmas gift for those who run Windows NT on Alpha AXP, MIPS or PowerPC. These ports of Windows are really lacking some good applications. Yes, there are utilities and games, Alpha even has Microsoft Word, Excel and Oracle DB, but apart from that there just are no serious apps available.
Calamus is a professional DTP (Desktop Publishing) software. It was actively developed and sold by a German company Invers up until 2018. If you want to play around with the latest version you can download a 30 day trial and (at the time this article was written) even purchase the Lite version for 99 Euro on calamus.net. There are versions for Windows, Mac and Atari ST.
Atari ST ?! Well yes, the original Calamus was born some 30 years ago on Atari ST:
I had pleasure of using Calamus professionally on Atari for several years in early 90s. At the time when 486 could have max 64MB RAM and 640×480 VGA, a high-end Atari TT packed 256MB Magnum card and 1280×1024 framebuffer. The memory and high resolution displays were really needed to process large images and complex page layouts. You can read more about my Atari TT restoration efforts.
In the mid ’90s DMC decided to port Calamus to Windows NT to take advantage of emerging high end PCs and RISC platforms. An interesting fact is that the port wasn’t really a full source code rewrite, which was impossible due a large codebase size. Even that Calamus has 100% native Windows GUI and a lot of functionality has been rewritten, inside the software lives a small embedded Atari ST emulator that does on fly translation of some of the Atari/m68k ABI. You can read a bit about it here.
Calamus on Windows NT Alpha AXP
At the time of the port, Windows NT was still being actively developed on RISC platforms, so thankfully Calamus has been compiled on all of the available NT CPUs. Alpha version was probably the most popular choice because of performance. High end Alphas were the fastest machines capable of running Windows among all hardware. When publishing firms were thinking about upgrades they naturally looked at DEC as a first choice as regular PCs weren’t powerful enough.
I finally found a copy Calamus NT with support for all the RISC CPUs. It took me quite a lot of time and resources to track down and obtain copy of a surviving media from an owner of a publishing studio. This is how it looks when you first install it:
Calamus NT Install Wizard
Interestingly there were separate builds for 386/486 and Pentium CPUs.Â
If you don’t have one of these machines you can still run Windows NT MIPS on Qemu:
Calamus on Windows NT MIPS under QEMU
And finally to the goods! You can get them in my my archive. If you just want to play with small demo without installing the whole app look in the demo folder.
While looking for nothing in particular, I came across Glenn Holmer’s excellent site which has an excellent collection of languages for the Commodore 8bit computers.
And among them was the first C compiler I’d ever owned, SUPER-C!
SUPER-C
Towards the end of the effective life of the Commodore 64, people started to dump expensive software on the cheap. It was a great time to go to the World of Commodore, and see all the great vendors and wares. And of course feel that ever pervasive shift to the Amiga. It was where I picked up this fun little binder:
And what about programming in C?
Super-C CCP
It boots up into a CP/M like environment, complete with drive letters. You can write programs to either be loaded up from the BASIC ROM environment, or the CCP environment. On the one hand it’s pretty cool, it includes a simple text editor, and the compiler and linker. But one thing is for sure, using this with a single 1541 is incredibly slow. The touted Commodore 128 version with REU support would have made it’s insanely slow speeds a little more tolerable. That and having multiple machines would have been a must.
As interesting as it was to look at, if you really wanted to do anything with C on the Commodore 64, seriously use cc65. There is something to be said for using a cross compiler when you are running at GHZ vs the 6502’s 1Mhz.
I don’t know why I did it, as honestly I didn’t like it on CGA back when it was a thing. Also, thankfully the hard disk speed on PCem is way faster than the real thing. And I’m not complaining.
Installing
Text mode is all the same setup wise, but on reboot the installer goes forward in glorious CGA ‘high res’ mode. Which is pretty terrible.
Welcome to OS/2!
Yuck. I guess at the time I just felt lucky that I could at least run it. Although once I got lucky enough to score an EGA card + monitor. Anyways let’s continue the horror!
Command prompt
Yep, there is the desktop! .. barely. The desktop constantly want’s to jump around which is annoying, just as command prompt’s cant decide if they should be black or white. And the font’s get truncated. It’s almost as if nobody cared about actually supporting CGA. Which honestly I’m more surprised that it even made the cut.
Word and the fox
Sure, I could have changed the default font, but why should I? I know Word 1.1 is very primitive but wow.
To be fair, Windows in CGA is pretty terrible as well.
Could they make the title bar any larger?
Not to mention solitaire on both is nearly impossible between the lack of colour, and the lack of any high resolution. I suppose the Wyse 700 display ought to be much nicer, if only they had gone through the hell of making OS/2 device drivers.
One neat ‘feature’ of PCem is that it’s CGA emulates the single ported memory, so that the card & host cannot properly share the video memory so for programs not watching the retrace line you get the snow effect. (here is a demo, GP-01 by Genesis Project with snow, and here without snow).
but of course in this day & age all of this really is moot.
(This is a guest post by xorhash.)
I’ve been on a trip on the memory lane lately, digging around old manuals of UNIX® operating system before BSD.†In doing so, I’ve come across the sources for the 7th Edition manuals. I wanted to show one part of volume 2A to other people, but didn’t want to make them download the entire 336 pages of volume 2A for the part in question. The part I wanted to extract was “LEARN — Computer-Aided Instruction on UNIXâ€, starting at p. 107 in the volume 2A PDF file).
A normal person would, I presume, try to split the PDF file. That is straightforward and produces the expected results. I believe I needn’t state that you wouldn’t be reading this if I solved this problem like any sane person would. Instead, I opted to rebuild the PDF from the troff sources provided at the link above.
I am not a very clever man, and thus I completely disregarded the generation procedure that was already spelled out. However, it wasn’t exactly specific anyway, so I didn’t miss out on much.
So I knew what I needed to do: Get the troff sources. I asked that the Heavens have mercy on my poor soul if this requires a lot of adjustment for 2017 text processing tools. However, a man must do what a man must do. The file in question was called “vol2/learn.bunâ€. I had no idea what a bun file is, hoped it wasn’t related to steamed buns and clicked it. As it turns out, it’s just what we would call a self-extracting archive today. The shell commands are not very weird, so the extraction process actually worked out just fine. Now I had files “p0†through “p7â€. Except what happened to “p1â€, the world will never know.
I’ve dabbled in man pages before, but that was mostly mandoc, not actual troff.
Accordingly, the first attempt at getting something going was as naive as it could get:
$ groff -Tpdf p* | zathura -
It led to, shall we say, varying results.
really butchered rendering attempt
Clearly, I was doing something very fundamentally wrong. Conveniently, volume 2A also had a lot of troff documentation. Apparently I was supposed to pass -ms and first run tbl(1) over the troff source before actually giving it to groff. That sounded like a good idea, but the results were still somewhat off:
not very butchered rendering attempt
Allow me to express my doubts that this text was written in 2017. If you compare the output with the known-good PDF, you’ll also notice that, somehow, “Bell Laboratories, Murray Hill, New Jersey 07974†turned into “CAIâ€. Unfortunate.
Continuing to read the page I got the learn.bun from, I also spied a section called “Macros and Referencesâ€. That sounds relevant to my interests. tmac.s, which after studying groff(1) seems to be what would get used with -ms references some files in /usr/lib/tmac. I was not in the mood to let this flood over into my system, so I had to make minor adjustments and turn it into relative paths. I also renamed tmac.s to tmac.os to avoid colliding with the one provided by groff, making the new invocation:
$ tbl p* | groff -M./macros -mos -Tpdf | zathura -
Now we’re getting somewhere:
almost not butchered rendering attempt
It’s better than the previous attempts. But there are also some warnings and problems that need cleaning up:
tmac.os:806: warning: numeric expression expected (got `\').UX macro was requested, I got:warning: macro `ev1' not defined (possibly missing space after `ev')
environment stack underflowPoint 1 was easy to address, it’s a simple text change. Point 2 was caused by spurious dots in front of a call to .ND. However, the actual volume 2A PDF said a different date than in the file, so I adjusted that to match (June 18, 1976 to January 30, 1979).
As for points 3 and 4… Let’s just say groff/troff macros are definitely not meant to be written or read by humans and it’s a feat comparable to magic that someone wrote this set of troff macros. Line 806 is .ch FO \\n(YYu. Supposedly, that changes the location of a page trap when the given macro is invoked. The second argument is meant to be a distance, which explains why groff is complaining. I tried to checked what groff does and left none the wiser. FO seems related to the page footer, I seemed to get away with just deleting that line, though.
Finally, point 4. Apparently, .ev1 was used multiple times in the tmac.os. This looked like it should’ve been .ev 1 instead. Changing those, lo and behold, .UX stopped behaving funky for the most part. Yet for some reason, I’d still get multiple footnotes about the trademark ownership of the UNIX® trademark.† tmac.os sets a troff register (GA) when the .UX macro is first encountered so that the footnote is only made once. The footnote is being made twice. Something does not add up here..AI (author’s institution) resets GA, but the first .UX comes after .AI, so that’s not the problem. Removing the .AB/.AE macros from page 1 caused only one footnote to be made. Thus, I infer it’s actually intended behavior that the footnote is made once for the abstract and once for the main body. Checking with the volume 2A PDF again, I realized that point 4 was, in fact, fixed just by the ev1 changes and I was just chasing a bug that does not exist. I really should’ve checked the PDF twice.
The abstract finally looks okay.
good rendering attempt
Okay, we’re done, we can go home, right? Almost, one last thing to do: On the last page, there’s something really important missing: the bibliography. Instead, there’s just “$LIST$†there. We can’t just turn Brian W. Kernighan and Michael E. Lesk into plagiarists!
Back to the troff documentation in volume 2A, there’s a match for “$LIST$†on p. 183. Apparently I need a reference file and preprocess the file with refer(1). That sounds simple enough. Fortunately, I got the reference file along with the macros above, so I didn’t have to look for that separately.
$ refer -pRv7man -e p* | tbl | groff -M./macros -mos -Tpdf | zathura -
half of the references are blank
Of course. Why would it work? That’d have been too much to ask for.
At least I get some nice hints:
refer:p2:148: no matches for `skinner teaching 1961'
refer:p3:114: no matches for `kernighan editor tutorial 1974'
The troff documentation conveniently explains the format for the reference file, so I could just add these two entries to Rv7man and be done with it. Thankfully, the pre-compiled PDF of the volume 2A manual had the information necessary to compile the bibliography entries with.
%T Why We Need Teaching Machines %A B. F. Skinner %J Harvard Educational Review %V 31 %P 377-398 %D 1961 %T A Tutorial Introduction to the Unix Editor ed %A B. W. Kernighan %D 1974
now that’s what I call a bibliography
And of course, here is the product of this whole ordeal.
The Heavens were feeling somewhat merciful, but only just enough that I could waste no more than a day on this project. They really wanted me to spend that day on it, though.
On a side note, “the missing learn references†aren’t available from the link that was
provided. http://cm.bell-labs.com/cm/cs/who/bwk/learn.tar.gz is now down, though the web archive still has it. Needless to say, I didn’t read that.
I will never, ever touch troff/groff again. mandoc is good at what it does and I’ll stick to mandoc for writing man pages. But if I ever need to get something typeset nicely from plain text?
LaTeX is the answer.
Not troff.
Never troff.
Not even once.
†UNIX® is a registered trademark of The Open Group.
booting
I was pretty amazed to see it even get this far. Credit to Steve Troughton Smith for his patched BootX, which gets the boot process this far. It’ll actually start the NeXTSTEP style install, but the keyboard won’t work either USB or ADB. Oh well.
..\qemu-system-ppc.exe -L .. -m 256 -drive file=MacOSXServer10.iso,index=0,format=raw,media=cdrom -drive file=BootX_custom.dmg,index=2,format=raw,media=disk -drive file=bla.disk,index=1,format=qcow2,media=disk -prom-env “boot-device=ide2:2,\BootX” -prom-env “boot-args=-v rd=sd0 debug=0xffe kdp=2” -prom-env “boot-file=ide0:11,\mach_kernel” -g 800x600x8 -device adb-keyboard -device adb-mouse -cpu G3 -M g3beige
Nothing says Merry Christmas, like shotguns, demons, and a free trip to hell!
I’ve got 5 extra steam keys, so leave a comment with some way to reach you, and the first five people get a copy of Ultimate Doom! Sorry all five have been claimed!
Feel free to play with GCC 1.27, or the x68000, or don’t forget vintage DooM shovelware of the era to go along for the ride!
And for those who like the vintage, don’t for get that you can revert Ultimate DooM back to version 1.1
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.