Mike Schaeffer's Blog

Articles with tag: history
December 21, 2018

I've lately run across several interesting small computer history sites. If you have any interest in small computing's emergence from 1980 to 1990 or so, these are worth a look.

In no particular order:

  • OS/2 Museum - Covers OS/2, but also gets into detail around PC architecture. Among other interesting bits, this is just one of several articles on A20 gate handling, and here's something on the IBM 8514/A.
  • DTACK Grounded - A newsletter written to promote Hal Hardbergh's side business of attached Motorola 68000 processor boards. Mostly interesting for his commentary on then-crurent events leading up to the emergence and use of 32-bit microprocessors. Notably, this was written at the time of Intel's pivot from the iAPX 432 to the 80386. The commentary on the relative unreliability of DRAM is amusing too.
  • CRPG Addict - Not sure how he has the time, but the author of this blog has set himself the challenge of playing through and documenting every early CRPG game from the late 70's and well into the 90's.
  • The Digital Antiquarian - Critical commentary on early small computer gaming. Lots of details about how games came to be made and their content.
  • Retrocomputing Stack Exchange site - This is currently more like Netflix than anything else. Coverage is spotty, but that doesn't mean you can't find something interesting to read.
November 6, 2008

In an era in which customers are almost begging Microsoft not to discontinue Windows XP, I was suprised to see a recent news story on the end of life of Windows for Workgroups 3.11 (WfWG). If you're not completely up on the early history of Windows, WfWG 3.11 was released in August of 1993, and was the last of the major US-market versions of Windows without native Win32 support out of the box. It was also one of a series of Windows releases in the early 90's that turned Windows from 'the library you need to run Excel' into a legitimate platform for general purpose computing.

From it's introduction in 1985 until the release of Windows 3.0 in 1990, Windows was almost entirely composed of the same basic core: DOS for file access and system startup, and a collection of three DLL's (KERNEL, GDI, and USER) for memory management, device independant graphics, and the GUI widget library and window manager. Atop the core sat programs written to the Windows API. All of this ran sharing the one 20-bit segmented address space provided by x86 real mode: with 640K usable memory. If you were lucky, you might have had a LIM/EMS board that allowed a few MB of extra memory to be addressed through a 64KB window at the top of the addres space. If you were really lucky, you might have had a 80386 computer with a special program that let it pretend its extra memory worked like a LIM/EMS board. Needless to say, memory was tight, difficult to use, and dangerous to share it between multiple programs.

The solution to this memory problem was initially to be OS/2. OS/2 was the operating system part of IBM's vast (and doomed) PS/2 program to recapture the PC space back from clone vendors. Like DOS, it was done in partnership with Microsoft, but IBM took a much more active role in the design and development of OS/2 than they did with DOS. OS/2's most noteworthy feature was the fact that it was designed to run in 80286 'protected mode' rather than the 'real mode' of DOS and Windows. Protected mode, like its name implies, added memory protection between processes that made multi-tasking more reliable. Protected mode also widened the physical address space of the CPU from 20-bits to 24-bits, making it possible to directly address 16MB of memory without resorting to tricks like LIM/EMS paging. This was all good, but it was tempered by the fact that OS/2 was expensive to run and didn't run DOS programs very well, thanks to its choice of 80286 protected mode over 80386. The only programs that could actually use the benefits of protected mode under OS/2 were OS/2-specific software that nobody had.

By the time 1988 rolled around, PC's with the capability of addressing more than 1MB of memory had been around since 1984, and there still wasn't a viable mainstream operating system that took advantage of this capability. This is when Windows got its big break: David Weise at Microsoft figured out how to run Windows itself in Protected Mode, along with unmodified Windows programs. Running existing software in protected mode was something of a holy grail, and Dr. Weise's idea ultimately resulted in Windows 3.0, released in 1990 to heady acclaim. Windows 3.0 also included the V86 multitasker from the older Windows/386 product. This meant Windows 3.0 could do things OS/2 could not do, like run multiple DOS programs at the same time and run them in graphical windows on the desktop.

Windows 3.0 ended up being a runaway sales success, and after its release, the rest of the dominos fell fairly quickly. Microsoft's partnership with IBM effectively ended, with IBM getting a source licence to Microsoft products through the early 1990's. IBM ultimately used this license to develop a special version of Windows they bundled with OS/2 2.0 to let Windows programs run under OS/2 ("a better Windows than Windows" went the ad). Microsoft's own 32-bit OS/2 2.0 got dropped, and the work done on OS/2 NT (3.0) ultimately formed the basis for 1993's Windows NT and the Win32 API. The next version of 16-bit Windows, Windows 3.1, dropped support for real mode entirely, and as it evolved into Windows 95, more and more system services were moved into 32-bit code. This 16/32-bit hybrid version of Windows lasted until Windows Me. It was definately barouque, and ended up notoriously unreliable, but its evolution from 256K 8088's to 128MB Pentiums is to my eye one of the more impressive examples of evolutionary software engineering. I don't miss using these versions of Windows, but it's easy to miss the 'brave new world' spirit they embodied.

June 12, 2007

I just saw this story on Oregon Trail over on Slashdot. I was born in 1975, which puts me in grade school in the early 1980's, the prime time for these early Apple ][ educational games. As much as I liked Oregon Trail, I liked Rocky's Boots even better. The basic premise of Rocky's Boots was that you had to use basic boolean logic circuits to build machines to solve particular tasks. You ran around a little maze using a very early 'point and click' style user interface to gather parts and put them together. Once you were done, you got to watch your creation do its thing. A fun little bit of trivia regarding Rocky's Boots is that it was developed by Warren Robinette, the creator of Atari 2600 Adventure, including the famous, ego-driven easter egg.

July 7, 2006

Kerry Nietz, author of FoxTales, dropped me a note regarding a comment I made about his book back in January. I thought it was worth repeating part of my response here:

"Like I said in January, the book brought back memories of the first few years of my career. Obviously the details are different, but if my kids ever ask about the beginning of my career I'll point them to your book first. You did an excellent job capturing the spirit of commercial software development."

I re-skimmed the book last night (setting aside a brand-new copy of C.J. Date's Database in Depth, ironically enough), and it still seems relevant, six months after the initial read. That's always a good sign.

January 10, 2006

I finished Pentium Chronicles on the train the other day. Given that the full title of the book is Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips, I have to say that I expected something entirely different than I got. What I had thought would be a narrative discussion of Intel's development of the P6 core is really something else entirely: a book on large scale project management techniques, using a few specific examples from the P6 project. While there's nothing wrong with that kind of book (it's basically what Fred Brooks did with The Mythical Man Month.), Dr. Colwell seems more tentatitve when he decided what kind of book to write.

Early on in the preface, he basically announces his tentativeness when he explicitly states that he won't be offering many of his opinions because it stretches his "plausibile deniability" safety net too far. To me, that's emblematic of the biggest shortcoming of the book as an engineering/project management reference. Engineers working with their own "Plausible deniability" in mind don't produce good results: they work to redirect blame rather than improve the product they're working on. Dr. Colwell knows this, he even wrote about it in the book. With all that in mind, I can't help but wonder what the book would have been like if it had been written less with plausible deniability in mind.

For people reading this blog who are wondering if they should actually read the book, my answer is yes. However, it's important to go into the book with the right expectations. If you go in expecting something like Soul of a New Machine, you'll be disappointed.

January 5, 2006

I was roaming through the computer section of the University of Pennsylvania bookstore and ran across Pentium Chronicles, a 2006 book talking about experiences designing the P6 processor core used in the Pentium Pro, II, III, and Centrino. The author, Robert P. Collwell, was basically made employee number 1 on the P6 program when he was hired into Intel and given the assignment to "double the performance of the P5 on the same process." Of course, now, 15 years after that fateful assignment, it's pretty clear how influential the design produced by that program has been: it gave Intel a presence in the server and workstation markets, and it's still overshadowing its immediate sucessor, the Pentium4. Even if the project hadn't been that successful, the first 20% of Dr. Collwell's book has me convinved that it'd have been an interesting read anyway.

At the opposite end of the spectrum is Kerry Nietz's book, FoxTales. As much as Pentium Chronicles was the view from the top, the perspective of a very senior architect at Intel on a huge, industry-wide project, FoxTales is the opposite: the perspective of a fresh out of school programmer working on his first niche market shrink wrapped software package. If anything, that means it's much more likely to be relevant to people with the time to read this blog: it certainly brought back memories of the first years of my career.

The best thing about both of these books is that they are both cheap and short. You can probably read them both for <$50 and 10-20 hours of time, all of which would be well spent.

October 7, 2005

I suspected as much, but Excel has a way to duplicate my UDF using Excel formulas.

=REPT("&#9608;",A1) & REPT("&#9612;",ROUND(FLOOR(A1,1),0))

That formula evaluates to a bar of length A1 units, rounded to the nearest 0.5. Rescaling can be done in another cell. If you're interested in a bar that can be right-justified, you can use this:

=REPT("&#9616;",ROUND(A1-FLOOR(A1,1),0)) & REPT("&#9608;",A1)

The trickiest part about this is getting the block characters into the formula. For that, I reccomend using the Windows Character Map.

Qualitatively compared to VBA, this method requires more logic to be represented in the spreadsheet: that adds compelxity for readers and makes it tricker to set up than the VBA. On the other hand, it avoids the performance hit of calling UDF and the requirement that the spreadsheet contain a macro. I honestly don't know which is better style, but can say that this would be a perfect time to use a paramaterized range name (if Excel had such a thing).

October 7, 2005

Microsoft has just announced a cool new feature on the Excel 12 blog: the databar. I think a picture (linked from Microsoft's Excel 12 Blog can explain it better than I can:

This will be a nice way to look for trends/outliers, but I can also see it being useful for tracking parallel completion percentages in status reports, etc. Of the Excel 12 features announced so far, this is the one that I'm the most excited about. Of course, it's also the one that's easiest to approximate in Excel <12. Andrew has an approach using Autoshapes on his blog, and I'm going to present a slightly different approach.

IMO, his approach looks a lot better, this approach has the benefit of updating automatically. Pick your poison. It all centers around this little UDF:

Option Explicit

Function GraphBar(x As Double, _
                  Low As Double, _
                  High As Double, _
                  ScaleTo As Double) As String

    x = ((x - Low) / (High - Low)) * ScaleTo
    
    Dim i As Integer
    
    Dim blockFull As String
    Dim blockHalf As String
    
    blockFull = ChrW(9608)
    blockHalf = ChrW(9612)
    
    GraphBar = ""
    
    For i = 1 To Fix(x)
        GraphBar = GraphBar + blockFull
    Next
    
    If x - Fix(x) > 0.5 Then
        GraphBar = GraphBar + blockHalf
    End If
End Function

This isn't rocket science: all it does is rescale x from the range [Low, High] to the range [0.0, ScaleTo]. Then, it strings together that many Chrw(9608)'s, followed by a Chrw(9612), if the scaled value's fractional part is >0.5. The trick in this is that Chrw(9608) and Chrw(9612) are VBA expressions that produce the the Unicode equivalent of the old line drawing characters IBM put in the original PC [1]. 9608 is a full box ("█"), 9612 is a half box on the left ("▌"). The result of this function ends up being a string that (when displayed as Arial) looks like a horizontal bar. ("████▌"). Put a few of those in adjacent cells, and you get this:

The formulat in C2 (and filled down) is =GraphBar(B2,MIN(B$2:B$8),MAX(B$2:B$8),5). The MIN and MAX set the scale, the 5 sets the maximum length of a bar. The maximum length, font size, column width can be tweaked to produce a reasonably attractive result, although I do reccomend using vertical centering.

If you want to get a little fancier, conditional formatting works on plot cells...

...whitespace can possibly improve the appearance...

...and this technique can scale.

1] (The original PC didn't have standard graphics, it was an option. If you bought the monochrome, non-graphics, video board, characters like this were as close as you could get to a bar chart.)

September 7, 2005

I've found a couple interesting websites related to computer history. The first is Dusty Decks, a blog related to some efforts to reconstruct Lisp and FORTRAN history. A highlight of this is a discussion on the Birth of the FORTRAN subroutine. Also via Dusty Decks is a website on the early history of the Lisp Programming Language.

That leads me to a couple books I've been reading lately. The first is Lisp in Small Pieces, by Christian Queinnec. I'm only a couple chapters in (stuck on continuations right now), but it's already been pretty profound. So far, the aspect of the book that's been the most useful is that it has gone through several core design choices Lisp implementors have to make ( Lisp-1 vs. Lisp-2, Lexical Scope vs. Dynamic Scope, types of continuations to support), and goes into depth regarding the implications and history of the choices involved. I think I'm finally starting to understand more of the significance of funcall and function in Common Lisp, not to mention throw/catch and block/return-from.

Book two is The First Computers–History and Architectures, edited by Raul Rojas. This book is a collection of papers discussing the architecture of significant early computers from the late 30's and 40's. The thing that's so unique about the book is that it focuses on the architectural issues surrounding these machines: the kinds of hardware they were built with, how they processed information, and how they were programmed. Just as an example, it has a detailed description of many of ENIAC's functional units, even going into descriptions of how problems were set up on the machine. Another highlight of the book for me (so far) has been a description of Konrad Zuse's relay-based Z3, down to the level of a system architectural diagram, schematics of a few key circuits, and coverage of its microprogramming (!).

August 17, 2005

Group 1127, the group at Bell Labs that originally developed Unix, has been disbanded in a reorganization. I'm not exactly sure why this matters since all the original staff are gone and the remnants of systems research are elsewhere, but it did make the front page of Slashdot.

Older Articles...