Turns out there is a pre-compiled kernel in the various ’86 mach/accent dumps. However login bombs with a setuid issue:
setuid: Invalid argument
While there is an updated compiler, linker and libs re-building login didn’t help. I may have to do all the userland as there is (at least!) source to libc among others kind of implying this. I haven’t seen any instructions either.
This is going to be one of those ‘ongoing’ things that I’ll update later.
Ever since I got my hands on the Mt Xinu disk images, I’ve been working to see if the old Mach kernels on the CSRG CD-ROM set are actually buildable and runnable. And the TL;DR is that yes, they are.
The CD has 3 Mach kernels, the MK35 kernel, a kernel that appears to be something called X147, and a release of Mach 3.0. While X147 has hardware support for the SUN-3 and most of the files for the VAX, only MK35 has hardware support for the i386. The MK35 kernel has incomplete Makefiles and other dependencies, while X147 lacks i386 support. The good news is that it’s possible to use portions of the missing config & Makefiles from X147 to fill in for MK35, as it’s possible to copy the platform code from MK35 along with the i386 specific config into X147, yielding 2 working kernels.
Now this leads to the next few issues. The hardware support appears to be code ‘donated’ from various OEMs from Intel, Olivetti, Toshiba, OSF, and the CSRG. Dates vary from 1987 to 1991.
I started with the MK35 kernel as it was smaller, and since it was tagged as an ‘Intel only release’ of Mach, I figured that this one had the best chance of actually working.
And this is as far as it got on it’s first attempted boot. The Qemu VM would immediately reboot. Since I had installed Mt Xinu on VMware I went ahead and tried it there, and it said that there was a critical CPU exception and that it was shutting down. Bochs did the same thing, as did PCem. Since nothing was being printed to the screen it must be failing in the locore.s which is split into several assembly modules. I put in a hlt at various points and kept rebuilding and rebooting to see if it would halt or if it’d reboot. Thankfully VM’s are cheap and plentiful, I can’t imagine how tedious this would be on actual hardware. Eventually I found out that right after the paging bit in CR0 was flipped the VM would reboot. Now I had something.
/ turn PG on
mov %cr0, %eax
or $PAGEBIT, %eax
mov %eax, %cr0
mov %edx, %cr3
I had tried not flipping the page bit, not flipping cr3, no matter what I tried it would triple fault and reboot.
I had to break down and beg for help, and as luck would have it, someone who knows a heck of lot more about the i386 than I could ever hope to know took a glace at the above code and immediately noted:
I looked at start.s. And it immediately jumped out at me as being very fishy. What they do is enable protected mode *and* paging, but only then load CR3. That’s something which may well work on some CPUs, but it’s against the rules. You could try just swapping the instructions around, first load CR3, then CR0. The next question is then if that code executes out of an identity-mapped page; if yes then just swapping the instructions should do the trick, if not then there is a bigger issue.
Background: Old CPUs, especially 386/486, will decode and pipeline several instructions past the protected mode switch (mov cr0, eax). The jmp instruction is there to flush that pipeline and make sure all further instructions are executed with the new addressing mode in effect. But old CPUs did not enforce that and it was possible to execute the jmp from a non-identity-mapped page, and I guess it was also possible to execute instructions between the move to cr0 and the jmp, at least most of the time. That tends to break on modern CPUs (probably P6 and later) and definitely in emulation/virtualization. The move to cr0 effectively flushes the pipeline and if the next instruction is not in the page tables, poof, there goes the OS.
Could it really be that simple?
mov %edx, %cr3
/ turn PG on
mov %cr0, %eax
or $PAGEBIT, %eax
mov %eax, %cr0
/ mov %edx, %cr3
I commented out the cr3 line and just pasted above the cr0 pagebit flip.
Amazingly the kernel booted. Behold the first boot of Mach/4.3 which very well could be the first boot independent of the CMU and I’d venture the first boot from the source on the CSRG CD-ROM set. I tried to tell Mach to use the disk as prepared by Mt Xinu, but naturally it’s incompatible.
The next thing to do was create a root diskette, which thankfully the CMU folks left the needed files in the standi386at directory. I was able to build the disk, and using VMware I could boot into single user mode. I went through the ‘unpublished’ documentation I was able to mirror, and was able to get lucky enough to have Mach prepare the hard disk, format the partitions, and I used tar to transfer the root diskette onto the hard disk. I thought it ought to be possible to boot from the boot disk, have it mount the hard disk, and re-mount the boot disk, and copy the kernel. Sounds reasonable right?
This is where the incredibly stale platform code showed it’s head once more again as the floppy driver in MK35 is amazingly useless. It seems that the emulated hardware is too fast? But all reads from the floppy using the hard disk as root failed. Instead I removed a bunch of files from the disk, and copied over gzip & a compressed copy of the kernel to disk, along with the boot.hd program, and was able to copy them to hard disk using that modified root diskette. Luckily Mach has support for a.out binaries, and this stuff being so old it’s all statically linked. My Mt Xinu build of gzip runs fine on the Mach kernel, so I could decompress the kernel and install the bootblocks.
This is where the next weird issue would happen, which is that Mach was quite insistent on mounting everything under this /RFS directory. It appears that RFS was CMU’s answer to NFS… Which needless to say didn’t ignite the world on fire. I was later able to find that I could disable the RFS code, re-configure, rebuild and re-transfer a kernel and with a bit of fighting with mount I was able to mount hd0d/hd0e. Sadly during the install process there was no visible option to specify slice sizes so I’m stuck with a 10MB root.
With this much luck in hand I thought it may be interesting to see if Mt Xinu could mount the Mach disk. Turns out that it can without any issues. So I went ahead and wiped the Mach disk, and transfered Mt Xinu over to the Mach disk, and rebooted with that. And it “works”! Although of course there is some caveats.
The first being the aforementioned floppy support is broken. The next one being that the serial support also suffers from basically losing interrupts and leaving the system waiting. The kernel debugger still works, and you can see it in the idle loop, along with the other threads waiting. This means my favorite method of using uuencode and pasting to the terminal won’t work, MK35 locks up after 35kb, and X147 made it as far as 150kb. Keep in mind that they are using the same i386/i386at platform directories.
So I’m quite sure that there is other issues hiding in the code, maybe obvious ones like the cr3/cr0 thing. On the other front I’ve been starting at looking at doing some porting of the Tahoe/Quasijarus userland with varying success. I have already started to rebuild some binaries with a substitute crt0.o as there is no source for anything included in the Mt Xinu distribution outside of the Mach 3.0 kernel.
For those who want to play along I have uploaded VMDK’s and the source tarballs.
For people using Qemu I find that a serial terminal is FAR nicer to use than the console. Also I’m unsure of how hard the 16MB ISA DMA window is being hit, but X147 seems okay with 64MB of ram, while M35 really needs to be 50MB or less..
I’ve been looking for this, since I first found out about it a few years ago. It’s a port of 4.3BSD Tahoe to the i386, utilizing the Mach kernel. This is the biggest gap of the era, which is bringing mini-computer BSD to an affordable platform, the AT386.
Sadly like many others after Mach386, it did not find widespread commercial success and MtXinu wound down operations of the product, and eventually the company itself. It’s a shame too that both Mt Xinu & BSDi eventually exited the BSD market, while the open 386 alternatives flourished and grew.
One thing is for sure, it wasn’t cheap! At least on the perpetually starving college student budget the base license was $995! And that included no source code at all. Although the Mach 3.0 Add-on does include source code, however because of the then new AT&T USL vs. BSDI/UCB lawsuit CMU got cold feet over it’s BSDSS/BNR2SS for Mach 3.0 and pulled it, leaving you with a micro kernel with no personality. Although years later the rights would flow from AT&T to Novel who then let Caldera acquire them, and then give the infamous 32v giveaway (pdf) essentially setting BSD free. Although I was one of the people who shelled out the $100 for the oldSCO SYSIII license back in the day.
Mach386 lived from around 1991 until 1993. Needless to say the Juggernaut called Linux appeared at the right time and the right place, when all of the BSD’s had faltered because of that lawsuit. Sometimes in life, timing is absolutely everything.
Anyways fast forward a few decades and I have been looking for a mythical 4.3BSD on i386 for far too long, and I came across a post on betaarchive mentioning retrosys.net, and all of Scott’s adventures with Mach386. So I was able to contact him, and get a copy of Mach386!
Well the disk set is from 1992, and going back to that era means you are going be locked into the old disk geometry where an IDE disk under 500MB is the best way to go. The floppy controller is programmed in a weird way that the only thing I could get it working with was VMWare. It wasn’t so bad going through the disks, and I quickly had a system up and running. Once the install is done it’ll run under QEMU for instance just fine.
Currently there is no ‘modern’ ish networking support, aka no NE2000. So I’ve been using serial terminals to use uuencode/uudecode to get files in & out of the VM.
So what’s in the box? Well I didn’t install the X11 stuff as I’m just not in the mood to fight it, but it’s a 4.3BSD system! Sadly adventure/zork is absent, however rogue and all the other BSD type fun is there. gcc version 1.37.1 & GNU assembler version 1.36 among others are also includes, although without any diff’s or source. Although the networking headers & tools are on separate disks, there is no nonsensical link kit type thing like Xenix, meaning that TCP/IP is fully integrated to the kernel. While there is SLIP support apparently I haven’t messed with it at all yet.
Being that this a Mach based system it builds the 3.0 kernel with ease. It even includes a 4.3BSD (sadly binary only) ported kernel to the 3.0 Mach which you can run. It’s defiantly not as fast as the default kernel, but seems to work well enough.
The kernel in question is what they term Mach 2.6 which is the 2.5 plus lots of enhancements. Among others is a different disk layout/partitioning scheme so you can dualboot. Although in the era of cheap VMs it’s kind of pointless.
So it may not look like much, but it’s a really fun thing to play around with. At the same time 386BSD had been pushed out into the world, and Linux was also a thing. It’s not surprising that Mt Xinu & BSDi would eventually fail in the marketplace, and Linux would go on to decimate the UNIX landscape. But it’s cool to run a direct VAX based OS on the PC.
text data bss dec hex
389088 45564 101364 536016 82dd0
ln vmunix.sys vmunix; ln vmunix vmunix.I386x.STD+WS-afs-nfs
However, as luck always has it, start.s in the i386 code does something weird at the 3GB mark causing a triple fault on any kind of modern emulation/virtualization setup.
/ Fix up the 1st, 3 giga and last entries in the page directory
mov $EXT(kpde), %ebx
and $MASK, %ebx
mov $EXT(kpte), %eax
and $0xffff000, %eax
or $0x1, %eax
mov %eax, (%ebx)
mov %eax, 3072(%ebx) / 3 giga -- C0000000
mov $EXT(kpde), %edx
and $MASK, %edx
Not all that sure why, but at least on Bochs, I can see the triple fault.
00036527018d[CPU0 ] page walk for address 0x0000000000101122
00036527018d[CPU0 ] page walk for address 0x00000000e0000011
00036527018d[CPU0 ] PDE: entry not present
00036527018d[CPU0 ] page fault for address 00000000e0000011 @ 0000000000101124
00036527018d[CPU0 ] exception(0x0e): error_code=0002
00036527018d[CPU0 ] interrupt(): vector = 0e, TYPE = 3, EXT = 1
00036527018d[CPU0 ] page walk for address 0x00000000c0161370
00036527018d[CPU0 ] PDE: entry not present
00036527018d[CPU0 ] page fault for address 00000000c0161370 @ 0000000000101122
00036527018d[CPU0 ] exception(0x0e): error_code=0000
00036527018d[CPU0 ] exception(0x08): error_code=0000
00036527018d[CPU0 ] interrupt(): vector = 08, TYPE = 3, EXT = 1
00036527018d[CPU0 ] page walk for address 0x00000000c0161340
00036527018d[CPU0 ] PDE: entry not present
00036527018d[CPU0 ] page fault for address 00000000c0161340 @ 0000000000101122
00036527018d[CPU0 ] exception(0x0e): error_code=0000
00036527018i[CPU0 ] CPU is in protected mode (active)
00036527018i[CPU0 ] CS.mode = 32 bit
00036527018i[CPU0 ] SS.mode = 32 bit
00036527018i[CPU0 ] EFER = 0x00000000
00036527018i[CPU0 ] | EAX=e0000011 EBX=0015f000 ECX=00161dc1 EDX=0015f000
00036527018i[CPU0 ] | ESP=0000efbc EBP=0000efbc ESI=00193fb8 EDI=00009d84
00036527018i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00036527018i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00036527018i[CPU0 ] | CS:0028( 0005| 0| 0) 00000000 ffffffff 1 1
00036527018i[CPU0 ] | DS:0020( 0004| 0| 0) 00000000 ffffffff 1 1
00036527018i[CPU0 ] | SS:0010( 0002| 0| 0) 00001000 0000ffff 0 1
00036527018i[CPU0 ] | ES:0020( 0004| 0| 0) 00000000 ffffffff 1 1
00036527018i[CPU0 ] | FS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00036527018i[CPU0 ] | GS:0000( 0005| 0| 0) 00000000 0000ffff 0 0
00036527018i[CPU0 ] | EIP=00101122 (00101122)
00036527018i[CPU0 ] | CR0=0xe0000011 CR2=0xc0161340
00036527018i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00036527018i[CPU0 ] 0x0000000000101122>> add byte ptr ds:[eax], al : 0000
00036527018d[SIM ] searching for component 'cpu' in list 'bochs'
00036527018d[SIM ] searching for component 'reset_on_triple_fault' in list 'cpu'
00036527018e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting
Mach 3.0 doesn’t do this, so I’ll have to dig far deeper into start.s which is kind of really beyond me.
Building a boot disk … is involved. 😐
rm -rf /usr/src/mach25-i386/obj
/home/user/mkfs /dev/rfloppy 2880 18 2 4096 512 32 1
dd if=/usr/src/mach25-i386/obj/standi386at/boot/boot.fd of=/dev/rfd0d
/home/user/fsck -y /dev/rfloppy
mount /dev/floppy /mnt
cp /usr/src/mach25-i386/obj/STD+WS-afs-nfs/vmunix /mnt
/home/user/fsck -y /dev/rfloppy
So, I’m not all that dead. For anyone super impatient, you can download my VMDK here, which runs on Qemu & VMware, it includes a serial terminal on COM1 so you can use a real terminal, and if you are like me, uuencode/uudecode files in & out of the system. As always read the 404 page for the current username/password.
Things are going well, and I’ve outgrown the old place. So time to move.
I’m super lucky, there is no denying that. So to push my luck I’m giving myself the corner office.
Unfortunately the prior tenant believes that masking tape X’s in the windows makes them stronger and will prevent them from breaking during a typhoon. I cannot believe how many people try to tell me that paper tape is somehow going to catch shards of glass being propelled upwards of 200km/hr.
It’s all exciting to me as the success is not only with my company, but its not an IT company either. It’s such an interesting thing being thrown into a different field although many of the challenges oddly enough remain the same.
Anyway all the hosted stuff is obviously offline. I think I’m getting a different public address, to further complicate things.
As someone who’s owned a few G5’s over the years, and 2 intel ‘cheese grater/Mac Pros’ this is like exciting news! Although I don’t see why this machine took YEARS to churn out after the trashcan fire, but here we go!
Somehow the aesthetic is even more cheese grater than the prior G5/Pro’s. Almost a desperate call back to pros saying you missed the grater, so here it is again! Now with more grating action, and like the iPhone now with rounded corners!
One thing I’ve heard time and time again is that XNU really struggles with multiprocessor setups. And I guess we’ve hit that peak as that 2013 Mac Pro was single processor, and the new Mac Pro continues in this trend with a single processor, a Xeon from the ‘W’ or workstation lineup. Which I guess isn’t all that surprising.
The real great thing is expandibility is back! SLOTS SLOTS SLOTS! Although there is no front 3.5mm RCA audio (lol remember that?!) there is 2 USB-C on the top of the case for somewhat accessible ports. Still not too bad.
Another quick to open and upgrade machine. Just like the good old days of the cheese grater!
Although many were hoping for an end to the NVIDIA embargo, bringing CUDA to the table, there was no such luck. Instead the whole ‘dual GPU’ thing was doubled down on.
Bundled is the Radeon Pro Vega II Duo card, featuring dual GPU’s on the same card. Although the case is now large enough for two of these cards giving you 4 GPUs in the box.
So far, so good right?!
And then there is the expected MSRP. $5,999 USD. For the cheapest ‘base’ model featuring a bare 8 core, 16 threaded processor clocking in at 3.5Ghz.
However this does mean for people who want to collect old Mac stuff, the trashcans are no doubt going to crash in price. If you enjoy having a stack of external peripherals, and wires and cables everywhere. Kind of like the old Power Mac G4 Cube.
So I bit the bullet and updated to Windows 10 build 1903. And then the fun started on my glorious 2006 MacPro. It finished the update, and on reboot I get the login screen, and then almost immediately a blue screen.
Naturally the QR code is useless as it doesn’t specify any stop codes, and the minidump… Well that requires gigabytes and gigabytes of crap to download to get a tool to read it. (I still haven’t finished that rabbit hole, like COME ON! why isn’t it included?!).
However after hitting F8 a million times, I found that safe mode & networking work just great. Searching online was basically useless as there was no specific stop code to go with this WDF_VIOLATION. Further looking around I did notice one thing, and that it was all Macintosh machines that crash out to this WDF_VIOLATION error. It must be something specific to the Apple hardware running Windows 10!?
Armed with this (dis)information, I went ahead and disabled all the Apple specific drivers & startup items.
From MSCONFIG.EXE I disabled the following services:
Apple OS Switch Manager
Apple Time Service
And in the task manager, I disabled the following startup items:
Realtek HD Audio Manager
Boot Camp Manager
I had the other VMWare serial & USB hook previously disabled, as I just don’t want them at all on my setup. The big upshot is that after rebooting out of safe mode, I’m now up and running on Windows build 1903.
Considering the BootCamp stuff was so woefully out of date, don’t expect Apple to fix this anytime soon. And since I’m on a MacPro 2006, I certainly won’t be getting any updates from Apple. But at least I can struggle to keep this thing up to date otherwise.
Now I can enjoy that ‘new command prompt’ everyone keeps telling me about.
I went through this on another Bootcamp Mac, and what I had to do was uninstall the “Boot Camp Services”. It’s startup component triggers the bluescreen as it’s doing some nonsensical inventory, banging around on the drivers in a not friendly way. I had version 4.0.4033 of the Boot Camp Services installed.
Removing this kept all the old drivers, which continue to work just fine.
Once more again I’m confronted with a situation where I needed a SQL, but I don’t have direct access to the data. The machine I’m able to run some stuff on is not only insanely out of date (yay!) but doesn’t have enough disk space for even something like SQL Server 2000.
Enter SQL 4.21a
I “installed” 4.21a on this 32bit 2003 server in much the same way I transplanted 4.21a onto Windows 10. However I did use the srvany utility to load up the SQL Server service, much like how I used it to run an instance of Qemu in the background elsewhere. Now I have my intermediary SQL Server running like a normal service, and set a password for the SA user.
Now for the fun.
First be sure to set your target database for ‘bulk/load’ and I’d also set it for ‘truncate log on checkpoint’. If you don’t set the bulk/load then you cannot BCP data into the database.
Using the SQL Explorer tool I could view the tables I wanted, and export them as ‘SQL CREATE’ giving me the table layout. I then quickly converted them into something acceptable for 4.21a. Now it’s a matter of establishing a connection to the old server from the new.
First I tested with the ISQL command. I needed to copy the DLLs DBMSSOCN.DLL & NTWDBLIB.DLL into the directory to get the command to fire up. Since my strategy here is to do a BCP dump/BCP load the first thing I need to do is purge the data.
This of course assumes that the server address is 192.168.1.42 and that in this case I’m deleting the firewall_mapping table from the network database. If you’ve made it this far that means we are 1/4th of the way there!
I found this ‘one trick’ to get the BCP command from the SQL 4.21a tools to connect to the 2016 server and dump the table as a trusted connection. I’m not sure how much longer this kind of thing will work, but I was pretty amazed it did. I didn’t even bother trying to see if the 4.21a BCP tool could read a 2016 BCP dump. Maybe it would if you keep the formatting the same, but I find ‘like to like’ much easier. I renamed the old BCP.EXE to BCP42.EXE so that they won’t collide in any way causing weirdness. At the same time I run them from a directory that is NOT in the system path.
bcp42 "[Network Database].[dbo].[firewall_rules]" out c:\temp\1.csv -t, -r= -P
The notation looks weird, as my source database name has a space in it. This initially caused endless frustration, but it was just a matter of using the fully qualified name, which is in quotes
I set the field delimiter as a comma, and the row terminator as an equal sign. I tried not setting it but I was getting ‘spiraling data’ as it was not picking up the end of row correctly at first.
The first time you run the BCP without a format file it’ll walk you through the specifics of the fields. I just blindly accepted the defaults, and saved the file as firewall_rules.fmt . Now on subsequent runs, I can run the export like this, which uses the saved formatting:
bcp42 "[Network Database].[dbo].[firewall_rules]" out c:\temp\1.csv -t, -r= -P -ffirewall_rules.fmt
Great so if everything is going well, we have no exported our data! Now the next step is to import the data into our old server. Since we have that format file, this “should” go pretty smoothly. Notice the server is an IP address which implicitly has it connecting by TCP sockets, not named pipes. As such there is no implicit ‘Trusted connection” as there was when talking to the local 2016 server.
bcp42 network.dbo.firewall_rules in c:\temp\1.csv -Usa -PPASSWORD -S192.168.1.42 -t, -r= -ffirewall_rules.fmt
Naturally change PASSWORD to whatever password you have for the SA user.
1000 rows sent to SQL Server.
1892 rows copied.
Network packet size (bytes): 512
Clock Time (ms.): total = 2216 Avg = 1 (853.79 rows per sec.)
And there you have it, all being well you’ll see the program update every 1,000 rows as it inserts data.
Originally I wanted to use the data transformation wizard thing (whatever they renamed DTS to) however the ODBC is limited to the newer .NET 4 stuff, which won’t use the old SQL Server 6.5 ODBC drivers. I really didn’t think the SQL Server 4.21a BCP command to work on a modern server against a new(ish) version of SQL Server, but it did!
I guess you could neaten it up with a command file to drop tables/re-create if you wanted, or at the least delete data/checkpoint and set the load options, dump/load data, and then turn off the load state for the database. I’m not doing reports or anything fancy, just visualizing data as they say.
Although things like ODBC have drifted out, it’s still kind of interesting that ancient BCP can still communicate over named pipes as an implicit trust.
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.
Something that is kind of annoying about NASA photos is that they end up so touched up, and so many liberties taken with them that they become creatures of their own.
Enter these old CD-ROMs
So I was happy to find this CD-ROM, NASA: Voyagers to the Outer Planets Volume 4: Saturn. It’s great that these are on archive.org, but like all old CD-ROM’s they are not quite ‘ISO CD9660’ enough so they don’t mount on Windows 10, or OS X. So once more again I used Qemu & a raw disk image, xcopying the CD to the disk and using 7zip to extract the disk onto the native filesystem.
Seeing that Voyager 2 was launched in 1977, and didn’t rendezvous with Saturn until 1981, it’s safe to say that the images are not in TIFF, GIF, or anything that modern machines will read. Instead they are compressed with Kris Becker’s implementation of Huffman encoding. Thankfully the source to the compression, and various manipulation tools are included in both C & Fortran. It was not to much work to get the C version to build, and have it detecting a 32bit LittleEndian machine. The program was meant to be run interactively however, so a few small changes had it running command line to let me script decompress the entire image set.
Which make it sound even less than useful. However ImageMagick does understand the FITS format, so running this at home on a 3Ghz 2006 MacPro took about 10 minutes to decompress and re-encode the images from the CD. Obviously doing this at work on 32cores will be much more faster than 8 cores, although I guess back in ’88 using a VAX-11/780 felt pretty awesome still.
As for the images, they are at surprisingly high resolution 800×800. What struck me about many of the images, is how they show a greater detail in things like the shadows of the rings on Saturn, or even an almost TV like quality to various moon flybys.
And the unexpected over exposures and flares.
But I thought it was an interesting glimpse into these images.
Also these CD-ROMs comprise a highlight selection. Which means for someone more intrepiding than me, there is far more of these raw vintage images out there.