• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Operatings Systems: reminiscences

Ah yes, the joys of installing CD-ROM drives in DOS. I remember back in '95 and there was a whole thing about the new Windows 95 operating system sending data to Microsoft, remember that? Well, I remember when I first got my hot little hands on a Windows 95 machine and had to install a CD-ROM drive. I was prepared for the worst, but I'd heard of this new concept called "Plug and Play", so I cracked the box, plugged in the drive, and switched it on. "New device found" said Windows. "Installing new device... Device ready." It. Just. Worked. It was like magic.

Ahh, those were the days, eh?
 
My early exposure to any sort of computing was in the late '70s, playing with a programmable calculator my BIL gave me when he moved on to a better one. That inspired me to take a few programming classes at the local community college, and by '83 I got my first desktop, an IBM PC clone. (Leading Edge Model "M". Half again the clock speed of an IBM PC and it was a good enough clone that it could run Flight Simulator, the acid test for clones.)

It ran on DOS 2.11, and one of the things that sticks in my memory was that one of the early things I had to do was hack the operating system.

DOS 2.11 had a hardwired (and tiny) environment space, which limited the number of flags you could create and set. I wanted to set up the (rather voluminous and complicated) batch files needed to run a smoothly operating Fidonet dialer and tosser, which required more flags than 2.11 could handle. (Flags were used to overcome the omission of batch files to be able to use recursion, among other things.)

There was a fix which required using debug to patch the OS, changing the space allocated for the environment.

Things have become simpler since then in many ways.
 
Last edited:
Several years ago I acquired a couple boxes of these. I use them as bookmarks for larger books. I've been leaving a few in the Little Free Libraries around the neighborhood.

I should probably look at selling some batches on eBay as they look to fetch a nice price.
At a recent computer museum working bee, we found several large cartons of these - tens of thousands. Alas, some were badly water-affected. :(
 
I have this expertise in programming terminate and stay resident programs that was of absolutely no use after Windows 6.

My first OS was TRS-DOS, developed by Microsoft. I learned C, COBOL and assembly language on that machine (Tandy Model 4P)
 
Several years ago I acquired a couple boxes of these. I use them as bookmarks for larger books. I've been leaving a few in the Little Free Libraries around the neighborhood.

I should probably look at selling some batches on eBay as they look to fetch a nice price.
My brother had to submit all his university programming assignments on these. I would never have been able to cope with that.
 
I have a copy of the original Bell and Ritchie source code book for UNIX 6 by John Lions, plus the commentary book.

https://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Lions_Commentary_Unix.jpeg/800px-Lions_Commentary_Unix.jpeg

All I had to work with were some photocopied articles from Bell Labs and the man pages. Then finally K&R's book came out for C.

Well, I had a guru in the other room as well. He had a martyred expression much of the time, and I'll take credit for that.
 
When reading a dump from IBM's MVS-z/OS OSes I know why you should often ignore the PSW on the dump summary and look at the RTM2WA OPSW due to the way addresses are loaded in the PSW and especially for address translation errors.
I have a lot of addresses stored in my head from writing so many routines (in assembler and rexx) that chain through storage. When people asked me to explain what "psa = 0x" or "cvt=storage(10,4)" meant it rarely went well. Apart from one time where I think I convinced someone that the 10,4 was stolen from CB radio.
Working as a java programmer on linux makes all that irrelevant. But I still have my System/370 XA Reference Summary from 1984 in my desk.
 
He visited my house in Heidelberg when we were being interviewed by a journalist/book author. It was around the time when The Cuckoo's EggWP by Clifford StollWP was published. I'll say no more on the subject (it's not difficult to discover my real name).


ETA: I feature in the book.

I remember the episode of a TV series covering the events. I think it was called Science Fiction and they took stories like the Cuckoo's Egg and the discovery of the hole in the ozone layer and semi-dramatized them. It's an absolute bugger to google though.

aha IMDB FTW link
 
Last edited:
More "interface" than OS if we're being technical, but if you go back and use any GUI before... I dunno probably about 1985, 1990 or so they always have a simple "Point" interface, rarely a "Point and Click" or "Click and Drag" style interface.

I remember because in my earliest days of computing as a kid it seems like the industry wasn't sure if "Light Pens / Touch Screen" or "Mouse" was going to become the primary pointing device.
 
Nobody else had the harrowing experience of trying to learn Commodore DOS? Eventually I gave it up and just used it as a games machine (for which it was excellent).

I also spent a whole lot of time making floppy book disks for each game that I wanted to play on my old 386-40 in the early-mid 1990s.
 
Nobody else had the harrowing experience of trying to learn Commodore DOS? Eventually I gave it up and just used it as a games machine (for which it was excellent).

In the early- to mid-80s I had an Apple II+ with CP/M on a Z80 card. I even had an 80-column card, but no shift key. I bought my first PC in the late 80s.

I know a lot of people had the C64, but I managed to miss it.
 
Nobody else had the harrowing experience of trying to learn Commodore DOS? Eventually I gave it up and just used it as a games machine (for which it was excellent).


DOS, then 6502 assembly (VIC 20). The 6502 instruction set was bare bones.
 
Back in the early 1980s in college the primary system used by the Computer Analyst/Programmer course was an HP 3000 running MPE. While I remember very little of it now, I recall that as a student it was a nice system to work with.

In my first job I was working with IBM Series/1 systems running EDX (Event Driven Executive.) Its primary programming language was EDL. The S/1 was a very different beast from the System/32 (and /34, /36 and /38.) It was a multi-tasking and multi-user system right down to the hardware, but had no memory protection. A careless programmer could overwrite the operating system's storage and crash the whole machine. The funny thing about EDL was when I started writing programs in C, a lot of things I learned writing EDL nicely transferred over to C, such as the ability to refer to the same memory locations as string data, words, or doublewords if that was needed.

I recall one program I was working that had an extremely tight memory constraint because other programs loaded above it in the memory space. The partition size was 64K and could not be altered. We already had programs that bumped up against that, so I couldn't add even 256 bytes to the program I was working on. The change required I read in a sector from disk—a calamity because the minimum size of a disk buffer was 256 bytes, and to now the program hadn't needed to do that. So I rearranged some of the storage to put needed variables lower in memory and initialization variables higher. When it came time to read the 256 bytes from disk, I put them into a short buffer that overwrote both the initialization variables and the program's initialization code, right up to (but not including) the read instruction that I was executing.

Kids these days don't know how easy they got it. :D

By the way, even though IBM withdrew the Series/1 from marketing in the early 1990s the US military is still using them. They're part of the nuclear missile launch authorization system. Sleep well, everyone!
 
This thread seems a good place to repost this for those who haven't seen it yet. I'm suspecting it will resonate with a few people.

The Story of Mel (originally posted to Usenet in 1983)

A recent article devoted to the macho side of programming
made the bald and unvarnished statement:

Real Programmers write in FORTRAN.​

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and “user-friendly” software
but back in the Good Old Days,
when the term “software” sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name...
Read on at the link.
 
Some years back there was a stink among geeks that MS had ripped off the BSD TP/IP stack for NT. Someone found some clear identification of BSD in a debug dump IIRC. This was never really contested, and of course this explains why the net on NT worked reasonably well.

It wouldn't surprise me if much of the working code in MS products has been stolen from Unix.

My understanding is that much of the original NT was derived from VMS, but I'm sure there was plenty of UNIX stuff in their also.
 
Compiling the core

On early versions of Linux (I don't remember which core version introduced modular kernels), an annoying task was recompiling the kernel. The early versions had a monolithic kernel (loading it into memory at boot was an all or nothing proposition), and at that time nearly all hardware drivers were contained in the kernel, so distros usually came with a kernel containing drivers for every bit of hardware the kernel supported. You could free up a lot of system resources (PC's didn't have nearly as much memory then), by recompiling, from source, a kernel configured only for the hardware you actually had. This involved a configure script for which you had to respond yes or no for a long list of hardware devices and other options, after which the compile process would run, taking maybe as long as half an hour. Then you had to reconfigure your boot loader to offer the option of booting the new kernel, reboot, and hope it actually worked. You could (as you can now, but with many fewer bells and whistles) set up the bootloader with a little menu where you could select the kernel you wanted to boot, so if the new kernel didn't work, you could revert to the original). IIRC, you had to go through this process with each kernel upgraed, too. Somewhere around the turn of the century (maybe earlier), the modular kernel was introduced, which allowed you (or the installer for the distro) to configure the kernel to load only the hardware drivers you actually needed.
 

Back
Top Bottom