More cross compiler assertion fun

undefined reference to `___eprintf'

Got this fun one in dwarf.c (and probably many others) while building an ELF toolchain from Linux to run on Windows to target.. Linux.  Anyways I think this is a symptom of Canadian Cross compilers.

So a little digging and ___eprintf turns out to be from the assert.h as macros for assert depend on this being in libgcc.a .. And yeah, MinGW uses something else.  So just copy the assert.h from MinGW, and re-build and away it works.

D:\elfgcc\bin>cc1
int main(){printf("hi!\n");return 0;}
        .file   "stdin"
        .version        "01.01"
gcc2_compiled.:
main.section   .rodata
.LC0:
        .string "hi!\n"
.text
        .align 4
.globl main
        .type    main,@function
main:
        pushl %ebp
        movl %esp,%ebp
        pushl $.LC0
        call printf
        addl $4,%esp
        xorl %eax,%eax
        jmp .L1
        .align 4
.L1:
        leave
        ret
.Lfe1:
        .size    main,.Lfe1-main
^Z
        .ident  "GCC: (GNU) 2.7.2.3"

time in parse: 1.155000
time in integration: 0.000000
time in jump: 0.000000
time in cse: 0.000000
time in loop: 0.000000
time in cse2: 0.000000
time in flow: 0.000000
time in combine: 0.000000
time in sched: 0.000000
time in local-alloc: 0.000000
time in global-alloc: 0.000000
time in sched2: 0.000000
time in dbranch: 0.000000
time in shorten-branch: 0.000000
time in stack-reg: 0.000000
time in final: 0.000000
time in varconst: 0.000000
time in symout: 0.000000
time in dump: 0.000000

Well, wasn’t that fun?

BBSs and early Internet access in the 1990ies

This talk explains how individuals were able to communicate globally in the 1990ies using self-organized networks of BBSsin networks like FIDO and Z-Netz, before individual access to the Internet was possible. It also covers the efforts of non-profit organizations to provide individual access to Internet Mail+News via UUCP and later via IP during that period.

This talk covers how individuals could participate in local, regional and global message-based data communications in the 1990ies. It covers the technologies used to access such networks, both on the infrastructure (BBS) side, as well as on the user/client side.

At the same time, the talk is a bit of a personal journey from

  • accessing dial-up BBSs using accoustinc coupler and modem
  • becoming CoSysop of a BBS and learning about how to operatie BBSs
  • being a Node/Point in message based communications networks like Z-Netz and FIDO
  • using UUCP to participate in Internet mail/news (Usenet)
  • working in the technical team of Kommunikationsnetz Franken e.V. to set up a community-based ISP with modem and ISDN dial-up banks, satellite based Usenet feeds, analog leased lines ISDN-SPV.
  • helping getting Germany’s alleged first Internet Cafe (we then called it an Online Bistro) connected

I never was able to know anyone close enough to do fun stuff like back to back DSL modems, or even in this day & age run fiber optics, do ATM or anything fun like that.  As they say telecoms always break down at the last mile, or in my case the first mile.

Cross Compiling 386BSD 0.1pl23 from Windows 10

I bumped the version to *current year*

Oh yes, this will be a thing!

Sure I can cross compile Linux, but what about 386BSD?  This had long been a thorn in my side, as the GCC/Binutil toolchain that is used in this early era is not GNU pure, they had been modified in all kinds of ways.  One of which was a builtin memcpy that doesn’t work the same as a normal memcpy, and the other being that the C compiler & pre-processor rely in YACC to build the tokens.  I had been using bison before, however even though bison didn’t generate any errors it build the compiler wrong enough that the majority of the kernel wouldn’t compile.

As it stands right now, the only things that do not compile is locore

to post process the kernel, symorder is used along with dbsym, although neither do any processing to the kernel file itself, so they aren’t needed to get a working system.

386BSD Release 0.1 by William and Lynne Jolitz.
Copyright (c) 1989,1990,1991,1992 William F. Jolitz. All rights reserved.
Based in part on work by the 386BSD User Community and the
BSD Networking Software, Release 2 by UCB EECS Department.
386BSD 0.1.2018 (GENERICISA) 02/02/18 15:01

Other than that, yeah it’s great, compile a kernel in under 15 seconds.

Anyone that cares, the initial release is here: 386bsd01.7z

 

Revisiting a UnixWare 7.1.1 install on Qemu/KVM

So after nearly 8 years ago from messing around with UnixWare, I wanted to confirm something from a SYSV Unix that has a C compiler that isn’t GCC, and I remembered I have UnixWare 7.1.1 from a long time ago.  Anyways I have long since lost the virtual machine I had installed onto, but I still have media and of course the more important licenses.

unixware certificate of license and authenticity

UnixWare licenses. the dread of fixing things 20+ years later

Yep it’s the real thing.  So with my certs in hand I do an initial install in Qemu and on reboot the system basically has bricked itself.

WARNING: System is in an unreliable state.

And then looking at the licenses it turns out that my license has expired.  What?

Somehow I got lucky before, but it turns out that the installation process for ancient UnixWare is NOT Y2K compliant!  And this actually turned out to be a known issue.  I can’t find the original article, but a mirror is here: ischo.net

So basically install using an eval license, which will of course expire on install, and then use your actual license after the installation, remove the eval, reboot and all will be well.

License Number: UW711EVAL
License Code: airhorpx
License Data: d60;m7hjbtt

Now isn’t that great.

The OS install license immediately expires.

Although you can’t boot up in any real useful state, the networking will kick people off, and it’ll constantly complain that you are in license violation, you can at least bring up the SCO Admin tool, and add in your actual licenses, and then delete the evals.

And now we’re good!

Ok, now for the real fun part, flags and how to run with kvm/qemu.  Since I was loading this onto a server for remote access something like this works fine for me as I’m using the VNC remote console.

qemu-system-x86_64 -enable-kvm -m 1024 -smp 4 -hda UnixWare.vmdk -cpu pentium -net none -monitor telnet::444,server,nowait -curses -vnc 10.12.0.1:11 -cdrom iso/SCO_UnixWare711.iso

So the key things are to restrict the CPU level, and I’ve deferred the network configuration so I can update network drivers, and the OS.  I’ve found that by doing the networking during the install resulted in an OS that crashed with an integer divide by zero after installing the fixpack 5.

Once you have UnixWare 7.1.1 installed, be sure to install Maintenance Pack 5, which is thankfully still online over at sco.com  I’d also recommend to do this in single user mode, you can enter single user mode by hitting a key during the boot logo and typing in:

INITSTATE=S
boot

And you’ll boot in single user mode, and can install the Maintenance pack with ease.  Until the maintenance pack is installed, expect poor stability, and the system won’t actually listen to the real time clock device, and it’ll accelerate the clock like crazy where I was passing an hour every minute or two.

Adding the AMD PCnet on UnixWare

Once the install and update is done, I just added a PCI network card (So older versions of Qemu work well with the ne2k_isa, but newer work much better with the AMD PCNet card.), which is a popular choice for both machines and VM’s of the era.  Although you can use SLiRP the built in NAT for Qemu/KVM alternatively you can also use tun/tap.  I tried to enable SMP, however it has issues binding to the other processors, although it does see them.  And this is better to give full access to the network stack for fun things like FTP, NFS and whatnot.

qemu-system-x86_64 -enable-kvm -m 1024 -smp 4 -hda UnixWare.vmdk -cpu pentium -monitor telnet::444,server,nowait -curses -vnc 10.12.0.1:11 -device pcnet,netdev=net0 -netdev tap,id=net0,ifname=tap10,script=/etc/qemu-ifup

Telnet access

And just like that I can now access the VM.

And for fun…

# uname -a
UnixWare kvm711 5 7.1.1 i386 x86at SCO UNIX_SVR5
# uname -f
architecture=IA32
bus_types=PCI2.10,ISA,PnP1.0
hostname=kvm711.joes.local
hw_provider=Generic AT
hw_serial=DEM076116
kernel_stamp=04/11/11
machine=Pentium
num_cg=1
num_cpu=1
os_base=UNIX_SVR5
os_provider=SCO
release=5
srpc_domain=
sysname=UnixWare
user_limit=5
version=7.1.1

Oh yeah so I don’t forget years from now I’m using the following OS & Qemu version:

# qemu-system-x86_64 -version
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u3)

# cat /etc/issue
Debian GNU/Linux 9 \n \l

Also I found an eval serial for SMP, but it doesn’t recognize the second processor after the boot.

# psrinfo -v
Status of processor 0 as of 01/31/18 16:40:07
Processor has been on-line since 01/31/18 16:13:57.
The Pentium processor has a i387 floating point processor.
The following conditions exist:
Device drivers are bound to this processor.

I’ll try apparently this as for some reason it doesn’t detect the MP in Qemu/KVM so it never installed the osmp driver.

pkgadd -d cdrom1 osmp

Add the following line to the file /stand/boot:
ACPI=Y

Date and Time on UNIX V7

(This is a guest post by xorhash.)

Introduction

I’ve recently defeated one of my bigger inconveniences, broken DEL as backspace on the UNIX®† operating system, Seventh Edition (commonly known as UNIX V7 or just V7). However, I’ve had another pet peeve for a while: How much manual labor is involved in booting the system. Reader DOS found out that SIMH recently added support for SEND/EXPECT pairs to react to output from the simulator. Think of them like UUCP chat scripts, effectively. This can be used to automate the bootup procedure.

Yet DOS’s script skips over a part of the bootup procedure that can be fully automated with some additional tooling. Namely, setting the date/time to the current time as defined by the host system. As per boot(8), the operator is meant to set the date/time every time the system is brought up. This should be possible to automate, right?

Setting the Date Automatically

date(1) itself does not support setting years past 2000, so we need custom code in any case. SIMH, fortunately, also provides a way to get the current timestamp in the form of %UTIME%, which is interpreted in any argument to any command. I’ve thus written a utility called tsdate that takes a timestamp as argument and sets the current time to be that timestamp. I put the executable in /etc/tsdate, but there’s really no reason to do so other than not wanting to accidentally call it. Once tsdate is in place, changing DOS’s script slightly will already do the trick:

expect "\n\r# " send "/etc/tsdate %UTIME%\r\004"; c

This approach already has a minor amount of time drift ab initio, namely the difference between the actual time on the host system and the UNIX timestamp. In the worst case, this may be very close to 1. If for some reason you need higher accuracy than this, you’ll probably have a fairly hard time. I could imagine some kind of NTP-over-serial, but you’d need support for chat scripts to get past the authentication due to getty(8) spawning login(1).

The system is not suitable for usage past the year 2038. However, you can at least push it back until around 2100 by changing the internal representation of time to be an unsigned long instead of simply a long. time_t was not used systematically. Instead, everything assumed long as the type for times. This assumption is in a lot of places in userspace and even the man pages use long instead of time_t.

If you overflow tsdate’s timestamp, you’ll just get whatever happens when atol(3) overflows. There’s nothing in the standard library for parsing strings into unsigned long and the year 2038 is far enough away that I didn’t want to bother. stime(2) would presumably also need to be adjusted.

Year 2000 Compatibility in the System

V7 is surprisingly good at handling years past 2000. Most utilities can print years up to and including 2099 properly. Macros for nroff(1)/troff(1), however, are blissfully unaware that years past 1999 may exist. This causes man pages to be supposedly printed in the year 19118. The root cause for this is that the number register yr only holds the current year minus 1900. Patches to the -ms and -man macros are required. Similarly, refer(1) only considers years until 2000 to be actual years, though I did not bother patching that since it should only affect keyword matching.

Leap year handling is broken in two different places due to wrong leap year handling: at(1) and the undocumented dysize() function, used by date(1) as well as inside /usr/src/libc/gen/ctime.c for various purposes. This affects the standard library, so recompiling the entire userland is recommended. Because the calculation is just a naïve division by four, it actually works on the year 2000 itself. A year is a leap year, i.e. has February 29, if a year is:

  1. a multiple of 4, and
    1. not a multiple of 100, or
    2. a multiple of 400.

Leap seconds are also not accounted for, but that comes to nobody’s surprise. Leap seconds just add a second 60 to the usual 00-59, so they don’t hurt doing date calculations on timestamps unless precisely on a leap second. For my purposes, they can be ignored.

Note that I haven’t gone through the system with a fine-toothed comb. There can always be more subtle time/date issues remaining in the system. For my purposes, this works well enough. If other things crop up, you’re welcome to put them in the comments for future generations.

The Good Stuff

There’s really not much to it. Applying diff and recompilation of the affected parts is left as an exercise for the reader.

Files:

  1. tsdate.c
  2. tsdate.1m
  3. y2kpatches.diff

† UNIX is a trademark of The Open Group.

Updated my DooM port


x68000 still won’t build on this, lots more to either separate out or just fork out.  No biggie.

The big plus is for GCC 2.x and higher that use DJGPP v2 runtimes is that the allegro music and sound work.  It tests faster than Watcom 10/11 or Open Watcom ..  probably DMX vs Allegro I suspect …

Things to do..

  • Upload my GCC 2.7.2.1 cross toolchain
  • Upload the Freedoom build chain (again)
  • Test on real machines, the 486 and the P3

So yeah.  Limited progress.

Also it’s nice being able to cross build Allegro 3.12 in 10-15 seconds vs the hour+++ in emulation.

Project is in the djgppv1 cross thing

https://sourceforge.net/p/crossdjgppv1/DooM/ci/master/tree/

git access to clone

git clone git://git.code.sf.net/p/crossdjgppv1/DooM crossdjgppv1-DooM

make with:

make -f makefile.djgpp_v2

and you should be good to go

MinGW and missing DLL’s

UGH

Stuff like this drives me crazy.  Once upon a time everything was statically linked, there were no DLL’s, and all exe’s had a lot of the same code in them, and people realized that the majority of a hard disk could literally contain the same thing over and over.  Not to mention that if you were to fix some bug in say, LIBC you would have to re-compile everything.  So we entered the brave new world of dynamic linking where we now live in the proverbial DLL hell, that although we did save space, we have things where slight variations in the same DLL can break things in unforeseen ways.  People have tried various things such as weak linking, Side by side assemblies, Frameworks, and all kinds of things to try to keep things together.

Honestly it’s just easier to go back, and statically link things, and just re-build as needed.

common culprits of MinGW based stuff always include:

  • libwinpthread-1.dll
  • libgcc_s_dw2-1.dll
  • libstdc++-6.dll

ugh.

The hard one is the pthread library.  If you try to link it statically it’ll try to link everything else statically and not every DLL can link statically (SDL* keep reading).  But GCC / Binutils does have the option to turn various features on and off through the link string

-static-libstdc++ -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic

As you can see, everything after “-Wl,-Bstatic” will be linked statically, while everything after “-Wl,-Bdynamic” will go back to being dynamically linked.

Ok, that is great but what about SDL, you may ask.  Well sure it’s a DLL, but even DLL’s come from somewhere.  Download the source, build it yourself and you can directly link the objects that make up the DLL.  In version 1.2.15 they live in the .libs directory.

SDL-1.2.15\build\.libs\*.o

And on Windows, if you get weird errors like:

SDL_dx5events.o: In function `DX5_DInputInit’:
SDL-1.2.15/./src/video/windx5/SDL_dx5events.c:183: undefined reference to `IID_IDirectInputDevice2A’

Just add the -ldxguid library and you can link this too.  I’m sure once upon a time people may not have had DirectX 5 or higher, but this isn’t 1997.

And please at least test your programs with no path, so that way you are aware of what is needed for re-distribution.

set path=.
D:\dosbox-code-0-4068\dosbox\trunk\src>dosbox.exe

DOSBox SVN

It gets so old when people never test.  And people freak out trying to download DLL’s from weird sites, and you know that never ends well.

Oh yeah, and a static version of DOSBox is 4MB.

4,033,550 dosbox.exe

I know that was massive a long long time ago, but today?

Teaching an old IRC dog some new tricks

I don’t know why, but I’ve always liked the ancient Microsoft Comic Chat IRC client.  Even though it has well deserved a really poor reputation for not strictly adhering to any standard, and being very ‘noisy’ and … poorly behaved.  But I find it works pretty well.  Or at least it did.

crash

Somewhere in the mists of time a lot of IRC servers slightly changed how they work, and lots of ancient IRC clients were left broken.  I’d fixed IRC II on Xenix, but without source, fixing Comic Chat was out of the question.

But naturally the real solution was a proxy.  And here is richardg867’s proxy.py.  And it offers three great features, namely it’ll fix the way Comic Chat joins a channel, and how users are displayed so everyone isn’t a channel op.  The best part is that it also includes the ability to connect to servers via SSL, meaning you can encrypt your connection to the IRC network

It’s a tiny Python server, and the Linux Subsystem for Windows can happily run it with zero modifications.

python proxy.py -p 6667 chat.freenode.net +6697

Running it like this will listen on port 6667 aka the default IRC port, and then connect to chat.freenode.net using SSL on port 6697.  And it works great!

Comic Chat Connected!

One thing to keep in mind is that initially the client is set to BOLD for some reason.  Just as you have to tell it to not spam channels with Comic Chat info, hitting control+b will end the bold and now you can message the NickServ, and unless someone hits up your info nobody will be the wiser.

It’s vital to NOT send Comic Chat specific information

People get really annoyed at the whole OMG it’s a Microsoft IRC client from 1996-1998 but yeah established protocols only slightly drift, with a little bit of help you too can keep using ancient software in a dangerous and scary modern world!

 

Teaching an Almost 40-year Old UNIX about Backspace

(This is a guest post by xorhash.)

Introduction

I have been messing with the UNIX®† operating system, Seventh Edition (commonly known as UNIX V7 or just V7) for a while now. V7 dates from 1979, so it’s about 40 years old at this point. The last post was on V7/x86, but since I’ve run into various issues with it, I moved on to a proper installation of V7 on SIMH. The Internet has some really good resources on installing V7 in SIMH. Thus, I set out on my own journey on installing and using V7 a while ago, but that was remarkably uneventful.

One convenience that I have been dearly missing since the switch from V7/x86 is a functioning backspace key. There seem to be multiple different definitions of backspace:

  1. BS, as in ASCII character 8 (010, 0x08, also represented as ^H), and
  2. DEL, as in ASCII character 127 (0177, 0x7F, also represented as ^?).

V7 does not accept either for input by default. Instead, # is used as the erase character and @ is used as the kill character. These defaults have been there since UNIX V1. In fact, they have been “there” since Multics, where they got chosen seemingly arbitrarily. The erase character erases the character before it. The kill character kills (deletes) the whole line. For example, “ba##gooo#d” would be interpreted as “good” and “bad line@good line” would be interpreted as “good line”.

There is some debate on whether BS or DEL is the correct character for terminals to send when the user presses the backspace key. However, most programs have settled on DEL today. tmux forces DEL, even if the terminal emulator sends BS, so simply changing my terminal to send BS was not an option. The change from the defaults outlined here to today’s modern-day defaults occurred between 4.1BSD and 4.2BSD. enf on Hacker News has written a nice overview of the various conventions.

Changing the Defaults

These defaults can be overridden, however. Any character can be set as erase or kill character using stty(1). It accepts the caret notation, so that ^U stands for ctrl-u. Today’s defaults (and my goal) are:

Function Character
erase DEL (^?)
kill ^U

I wanted to change the defaults. Fortunately, stty(1) allows changing them. The caret notation represents ctrl as ^. The effect of holding ctrl and typing a character is bitwise-ANDing it with 037 (0x1F) as implemented in /usr/src/cmd/stty.c and mentioned in the stty(1) man page, so the notation as understood by stty(1) for ^? is broken for DEL: ASCII ? bitwise-AND 037 is US (unit separator), so ^? requires special handling. stty(1) in V7 does not know about this special case. Because of this, a separate program – or a change to stty(1) – is required to call stty(2) and change the erase character to DEL. Changing the kill character was easy enough, however:
$ stty kill '^U'

So I wrote that program and found out that DEL still didn’t work as expected, though ^U did. # stopped working as erase character, so something certainly did change. This is because in V7, DEL is the interrupt character. Today, the interrupt character is ^C.

Clearly, I needed to change the interrupt character. But how? Given that stty(1) nor the underlying syscall stty(2) seemed to let me change it, I looked at the code for tty(4) in /usr/sys/dev/tty.c and /usr/sys/h/tty.h. And in the header file, lo and behold:

#define  CERASE  '#'    /* default special characters */
#define  CEOT  004
#define  CKILL  '@'
#define  CQUIT  034    /* FS, cntl shift L */
#define  CINTR  0177    /* DEL */
#define  CSTOP  023    /* Stop output: ctl-s */
#define  CSTART  021    /* Start output: ctl-q */
#define  CBRK  0377

I assumed just changing these defaults would fix the defaults system-wide, which I found preferable to a solution in .profile anyway. Changed the header, one cycle of make all, make unix, cp unix /unix and a reboot later, the system exhibited the same behavior. No change to the default erase, kill or interrupt characters. I double-checked /usr/sys/dev/tty.c, and it indeed copied the characters from the header. Something, somewhere must be overwriting my new defaults.

Studying the man pages in vol. 1 of the manual, I found that on multi-user boot init calls /etc/rc, then calls getty(8), which then calls login(1), which ultimately spawns the shell. /etc/rc didn’t do anything interesting related to the console or ttys, so the culprit must be either getty(8) or login(1). As it turns out, both of them are the culprits!

getty(8) changes the erase character to #, the kill character to @ and the struct tchars to { '\177', '\034', '\021', '\023', '\004', '\377' }. At this point, I realized that:

  1. there’s a struct tchars,
  2. it can be changed from userland.

The first member of struct tchars is char t_intrc, the interrupt character. So I could’ve had a much easier solution by writing some code to change the struct tchars, if only I’d actually read the manual. I’m too far in to just settle with a .profile solution and a custom executable, though. Besides, I still couldn’t actually fix my typos at the login prompt unless I make a broader change. I’d have noticed the first point if only I’d actually read the man page for tty(4). Oops.

login(1) changes the erase character to # and the kill character to @. At least the shell leaves them alone. Seriously, three places to set these defaults is crazy.

Fixing the Characters

The plan was simple, namely, perform the following substitution:

Function Old Character Old Character
ASCII (Octal)
New Character New Character
ASCII (Octal)
erase # 043 DEL 0177
kill @ 0100 ^U 025
interrupt DEL 0177 ^C 003

So I changed the characters in tty(4), getty(8) and login(1). It worked! Almost. Now DEL did indeed erase. However, there was no feedback for it. When I typed DEL, the cursor would stay where it is.

Pondering the code for tty(4) again, I found that there is a variable called partab, which determines delays and what kind of special handling to apply if any. In particular, BS has an entry whose handler looks like this:

  /* backspace */
  case 2:
    if (*colp)
      (*colp)--;
    break;

Naïve as I was, I just changed the entry for DEL from “non-printing” to “backspace”, hoping that would help. Another recompilation cycle and reboot later, nothing changed. DEL still only silently erased. So I changed the handler for another character, recompiled, rebooted. Nothing changed. Again. At that point, I noticed something else must have been up.

I found out that the tty is in so-called echo mode. That means that all characters typed get echoed back to the tty. It just so happens that the representation of DEL is actually none at all. Thus it only looked like nothing changed, while the character was actually properly echoed back. However, when temporarily changing the erase character to BS (^H) and typing ^H manually, I would get the erase effect and the cursor moved back by one character on screen. When changing the erase character to something else like # and typing ^H manually, I would get no erasure, but the cursor moved back by one character on screen anyway. I now properly got the separation of character effect and representation on screen. Because of this unprintable-ness of DEL, I needed to add a special case for it in ttyoutput():

  if (c==0177) {
    ttyoutput(010, tp);
    ttyoutput(' ', tp);
    ttyoutput(010, tp);
    return;
  }

What this does is first send a BS to move the cursor back by one, then send a space to rub out the previous character on screen and then send another BS to get to the previous cursor position. Fortunately, my terminal lives in a world where doing this is instantaneous.

Getting the Diff

For future generations as well as myself when I inevitably majorly break this installation of V7, I wanted to make a diff. However, my V7 is installed in SIMH. I am not a very intelligent man, I didn’t keep backup copies of the files I’d changed. Getting data out of this emulated machine is an exercise in frustration.

Transmission over ethernet is out by virtue of there being no ethernet in V7. I could simulate a tape drive and write a tar file to it, but neither did I find any tools to convert from simulated tape drive to raw data, nor did I feel like writing my own. I could simulate a line printer, but neither did V7 ship with the LP11 driver (apparently by mistake), nor did I feel like copy/pasting a long lpr program in – a simple cat(1) to /dev/lp would just generate fairly garbled output. I could simulate another hard drive, but even if I format it, nothing could read the ancient file system anyway, except maybe mount_v7fs(8) on NetBSD. Though setting up NetBSD for the sole purpose of mounting another virtual machine’s hard drive sounds silly enough that I might do it in the future.

While V7 does ship with uucp(1), it requires a device to communicate through. It seems that communication over a tty is possible V7-side, but in my case, quite difficult. I use the version of SIMH as packaged on Debian because I’m a lazy person. For some reason, the DZ11 terminal emulator was removed from that package. The DUP11 bit synchronous interface, which I hope is the same as the DU-11 mentioned /usr/sys/du.c, was not part of SIMH at the time of packaging. V7 only speaks the g protocol (see Ptbl in /usr/src/cmd/uucp/cntrl.c), which requires the connection to be 8-bit clean. Even if the simulator for a DZ11 were packaged, it would most likely be unsuitable because telnet isn’t 8-bit clean by default and I’m not sure if the DZ11 driver can negotiate 8-bit clean Telnet. That aside, I’m not sure if Taylor UUCP for Linux would be able to handle “impure” TCP communications over the simulated interface, rather than a direct connection to another instance of Taylor UUCP. Then there is the issue of general compatibility between the two systems. As reader DOS pointed out, there seem to be quite some difficulties. Those difficulties were experienced on V7/x86, however. I’m not ruling out that the issues encountered are specific to V7/x86. In any case, UUCP is an adventure for another time. I expect it’ll be such a mess that it’ll deserve its own post.

In the end, I printed everything on screen using cat(1) and copied that out. Then I performed a manual diff against the original source code tree because tabs got converted to spaces in the process. Then I applied the changes to clean copies that did have the tabs. And finally, I actually invoked diff(1).

Closing Thoughts

Figuring all this out took me a few days. Penetrating how the system is put together was surprisingly fairly hard at first, but then the difficulty curve eased up. It was an interesting exercise in some kind of “reverse engineering” and I definitely learned something about tty handling. I was, however, not pleased with using ed(1), even if I do know the basics. vi(1) is a blessing that I did not appreciate enough until recently. Had I also been unable to access recursive grep(1) on my host and scroll through the code, I would’ve probably given up. Writing UNIX under those kinds of editing conditions is an amazing feat. I have nothing but the greatest respect for software developers of those days.

Here’s the diff, but V7 predates patch(1), so you’ll be stuck manually applying it: backspace.diff

† UNIX is a trademark of The Open Group.

 

Converting a Physical disk to a Virtual disk with Qemu’s qemu-img on Windows

Just because even I forget from time to time.

You need to do this as administrator, even better if the disk doesn’t have a drive letter or mounted in any way under Windows.

Fujitsu MPB3021AT

In my case I picked up a 486SX with an aging Fujitsu disk.

qemu-img.exe convert -f raw -O qcow2 \\.\PhysicalDrive2 fujitsu_MPB3021AT.qcow2

And as fast as your machine can read the disk, you’ll have your Qcow2 disk image. As of Qemu 2.9.0 the formats include:

  • blkdebug
  • blkreplay
  • blkverify
  • bochs
  • cloop
  • dmg
  • luks
  • nbd
  • null-aio
  • null-co
  • parallels
  • qcow
  • qcow2
  • qed
  • quorum
  • raw
  • replication
  • sheepdog
  • vdi
  • vhdx
  • vmdk
  • vpc
  • vvfat

Which is quite a list.  Obviously since I’m reading a physical disk, the format is RAW.  I just output it to Qemu for my personal ease.

Also once the image was created I could quickly run it under Qemu, and discover that yes this was a machine running Windows 95.

qemu-system-i386.exe -hda fujitsu_MPB3021AT.qcow2 -soundhw es1370 -vga cirrus

So there you go from a “dead system” to at least fully recovered data in minutes.  KVM may get all the pres excited but it’s nothing without the awesome support of Qemu!