So, stop me if you’ve heard it before. You’re browsing eBay when you find a strange
item. You take a closer look at the photos, and
you find yourself having more questions than not. The mystery gnaws on your brain, and you realize
that the only way you're going to answer those newfound questions is if you click that mystical
“But It Now” button. *deep sigh* That’s the short version of how far too
much things have ended up in my collection. It’s also why I ended up with this weird
piece of strangeness: The IBM Personal Computer Graphical File System. The name alone made me curious, but what really
caught my eye was this little panel on the back, saying that what you needed was one
of a small list of compilers. It was at that point, I realized what I was
holding is a big-box software development library from 1984. For those not familiar with software development,
libraries are bundles of code that provide pre-built functionality. For example, a popular library in the current
day is the Simple DirectMedia Layer, or SDL library, which has been used to help develop
numerous games over the years. Given the name “Graphical File System”,
I had initially assumed that it had something to do with browsing files. Frankly though after reading the box’s descriptions,
I was at a loss. The little blurb on the front of the box was
especially useless in this regard: “[It is] an ANSI-Metafile standard for storage
and transfer of professional quality graphics on a file-oriented storage system. The Graphical File System provides highly
portable graphics information, and easy-to-use icon interface to enhance programming productivity.” To put it bluntly, that was a perfectly good
waste of an explanation. Grammatical issues aside, I legitimately have
no idea what this does aside from the fact that it has something to do with graphics
and files. As it turns out , I would end up falling
down a deep rabbit hole trying to solve this mystery. As usual, this is your host NCommander, and
today, we’re going to unbox something strange from 1984! With said, take it away past me! Let's crack the shrikwrap, it, uh already kinda going so ... It's the first time this has been opened since 1984. Inside, we have a binder, the hefty install manual, and the five 5.25 in disks. Let's see if these are readable ... With the unboxing complete, it was time to
break out the SuperCard Pro. Interestingly, only three of the disks were
labeled as part of the Graphical File System. The other two were labeled Professional Graphics
Series Device Drivers. As the disks were being dumped, I spent the
time flipping through the rather hefty manual trying to figure out just what I had unboxed. Now, I’ve worked with tech for a long time,
and the large slab of documentation was rather remarkable for one reason. Throughout the hundreds of pages in this binder,
I couldn’t find a single simple description of what the Graphical File System actually
is. Infact, I’ve read tax code documents clearer
than this! Instead, the vast majority of the manual talks
about the larger Professional Graphics Series, and something called “Metafiles”. From what I could piece together from the
manual and from the Internet, Metafiles were part of a larger specification known as the
Graphical Kernel System, meant to standardize how computer graphics were done as a whole. Historically, computer graphics were implemented
through proprietary systems with little to no standardization. For example, Apple had created QuickDraw for
their early GUI efforts on both the Lisa and the Macintosh. Meanwhile, Microsoft had standardized on their
own GDI interface for Windows 1.0 and later The same problem also extended to printing,
and specifically how graphics could be sent to a printer. Just like display and rendering, graphical
printing was dominated by multiple proprietary solutions, most prevalently by Adobe’s PostScript. The folks behind the Graphical Kernel System
specification had decided to solve this problem through a system of abstraction, and which
they called the Virtual Device Interface, or VDI. VDI defines a series of commands that define
how graphics should be displayed. These commands could be rendered on a monitor,
or they could be sent to a printer. The best way to imagine this is to think of
how you might draw this capital N. You might use a list of commands like the one on screen. If we step through each command step by step,
you can see how a computer might draw it. For instance, we may draw two rectangles,
and then the diagonal lines to connect them. Afterwards, we just need to fill in the connected
areas, and boom, a giant N. Of course, being able to send drawing commands
is one part of a larger challenge. For the purposes of interoperability, and
compatibility, it’s extremely important to have a defined format for loading and saving
a set of these drawing commands. That is where the Virtual Device Metafile
format comes into play. Metafiles provides a portable exchange of
graphics information to and from a disk. From what I can tell, the Metafile format
was at least partially adopted in industry. For example, the popular for the era drawing
program, Harvard Graphics, is able to both import and export to and from the Metafile
format. With this newly found information, would it
be safe to assume that that the Graphical File System is a way to create and work with
metafiles and embed them into a program? Well, if we want to know for sure, we’re
going to need to set up a development environment. After dumping the last disk, I used hxc to
check the validity of my dumps. To my relief, all five disks were in good
condition with valid bitstreams and no copy protection. All I had to do at that point is convert them
to raw images. Afterwards, we can get our first look at the
files contained within. The first three disks which were marked Graphical
File SYstem had what you might expect for a software library. There was a collection of test applications,
library files, and sample sources in C, Fortran, and BASIC. Meanwhile, the two driver disks have VDI drivers
for a variety of IBM graphics adapters, printers, and more. From the manual, these are meant to be loaded
from CONFIG.SYS to provide the virtual device interface as a system service. Surprisingly, there’s support for quite
a bit more than I expected: Beside EGA cards, there are various drivers for monochrome displays
as well as special support for the PCjr’s 16-color mode. This was something of a surprise because the
box itself said that only IBM's original Color Graphics Adapter and the very high end Professional
Graphics Controller were supported. Still, I’m not complaining since EGA cards
are easy to emulate. With the disks ready to go, I fired up a new
virtual machine with an EGA card and installed PC-DOS 3.3, and then copied the files over. Since I expected to do some programming, I
also installed Borland Brief as a good text editor. After fiddling with CONFIG.SYS and AUTOEXEC.BAT,
I think we’re good to go. At this point, I can run the GRID test application
which shows that everything is working properly. Infact, this is a good opportunity to demonstrate
the device independence of VDI. By changing the emulated graphics cards, we
can see how the GRID rendering changes. In each case, the image displays to the best
of its ability despite the differences in both hardware and capability. It’s also at this point you might notice
that the EGA versions of GRID don’t look quite right. Notably, the image’s resolution looks off. I’m not certain if this is a problem with
GRID, the VDI driver, or perhaps PCem’s EGA emulation. I don’t have a physical EGA card to test
with, so I can’t say for certain what’s going on. Rather notably, I did get a system hang with
the monochrome EGA driver. If you’ve got a physical EGA card and want
to try this, get in touch so we can definitively rule this out. Beyond that, I’m going to continue with
PCem’s emulated card for now, but I might come back to this subject if new information
comes to light. With VDI mostly working, we can now load what
the manual calls the “Interactive Interface”. After displaying it’s splash screen, we
have what appears to be a drawing program of some sort, but looks are deceptive. First off, there’s no mouse support, so
moving the cursor is done by pressing the arrow keys. Second, there isn’t any actual drawing b
be done here. There’s a set of buttons on the right, but
the main purpose of this program is to render stored Metafiles. We can do this by placing a rectangle representing
a given file on screen, then entering its filename and the picture ID number. Multiple images can be placed down and even
overlapped. That’s really all there is to say about
the so-called Interactive Interface. Using Harvard Graphics, I exported a few example
metafiles, so we can see all the fancy drawings. While it’s a neat demonstration, I couldn’t
help feel a little bit underwhelmed. As far as I can tell, the only thing you can
accomplish here is to send rendered metafiles to a supported printer or plotter. At this point, I assumed all the meat and
potatoes were hidden in the programming library itself. Of the three supported programming languages,
I was most comfortable in C, so I went to install Lattice C, and oh boy, I didn’t
expect the world of pain I was able to launch into. Lattice C is rather notable because it was
the origin for one of the most influential products of this era: Microsoft’s own C
compiler. Infact, early Microsoft C compilers were just
Lattice C with the serial numbers filed off. That being said, I quickly realized that actually
using Lattice C though was infact an experience, and not what I call a good one. To start off with, the archived documentation
seems to be incomplete. There’s absolutely no word on how to install
Lattice C. After considerable trial and error, I found
that installation is in fact handled by a batch file that has absolutely no error checking. If that makes you think I might have blown
up my file system, not once, but multiple times, you’d be *absolutely* right. The trick, for reference, is to run “A:MAKELC”
while in the root directory of the C drive. If done correctly, this creates the directory
structure properly, and then installs the files without doing something idiotic. It’s at this point that I ran into even
more problems, primary because it seems DOS 3.3 is too new for Lattice C. The first problem I ran into is that Lattice
C doesn’t ship with a linker. It instead expects the system to have one. Early versions of DOS up until 3.2 actually
shipped with LINK.EXE as part of DOS which is at least understandable. Rather conveniently, the Graphical File System
also contains an updated LINK executable on the driver disks. The fun doesn’t end here. Lattice C gives very terse and confusing error
messages, and I went around in circles trying to figure out why I couldn’t get Hello World
to compile. Eventually, I did realize that there are special
batch files that have the correct options and switches to get things working. After that, I did manage to compile Hello
World, but that wasn’t the end to my suffering. It all kinda goes downhill from here. The next step would be building the sample
code that shipped with the Graphical File System. Helpfully, the GFS manual does list the commands
necessary to do this. The only problem though is the commands in
the manual didn’t work. It's at this point that I realized that the
Graphical File System was written with Lattice C 2.0, and I was using 2.1. Still, I would think that this should be close enough, right? Well, the answer is yes, but it took a LOT
of fiddling to derive the correct settings. Even when I got things to build, I can’t
say for sure if it is working properly. For one, I had to make some changes to the
code because the program was running through a timing loop too fast. Secondly, the example code doesn’t seem
to render properly. This could be related to the EGA issues we
had earlier, but the showmetc example renders differently than the GRID example. Looking at the two side by side, the image
appears squished, and the font is different. Things get more confusing if I try a CGA card. Under CGA, the image is squished to the left
side of the screen, and the color palette has gone completely bonkers. However, as unlikely as it seems, both of
these behaviors may both be expected. There’s a specific function call in the
documentation to set rendering coordinates which is not used in the example code. Furthermore, the appendix for the CGA graphics
also has a section talking about setting the palette, although there’s no apparent function
to actually do so. I have to assume the GRID test application
does things that the example code does not. For the sake of comparison, I did actually
compile the Fortran version of the example code, and it shows the same behavior as the
C version. Still, glitches aside, I did get this all
working mostly, so maybe now is a good time to show some awesome demos showing Metafiles? Well, that was the plan, but it was at this
point I began to realize that something was missing. If I turn to the index of functions provided
by the Graphical File System, there’s a total of 15 functions which all relate to
displaying metafiles. There’s nothing here relating to creating
or manipulating graphics. Heck, aside from a special VDI driver that
can print to a file, there isn’t even a way to create a metafile. In fact, the vast majority of the manual beyond
this point is just a technical reference for the binary metafile format! For example, there’s no way that I could
create something like the Interactive Interpreter. I’ll remind everyone that the box itself
said that the Graphical File System “provides highly portable graphics information, and
easy-to-use icon interface to enhance programming productivity" While I can technically display graphics from
a “highly portable” format, there is no way I could make an icon interface with this
since I couldn’t implement something like a mouse cursor. I spent a lot of time researching this in
an attempt to understand what I was missing. Eventually, I did manage to put all the pieces
of this puzzle in context, but to do so, I need to go back to the “Professional Graphics
Series” the manual menthoned. IBM had fairly large plans for making the
PC a low cost system for doing computer-aided-design or CAD work. The pinnacle of this was the “Professional
Graphics Controller”, a monster of an ISA card with an integrated 8088 processor designed
to provide accelerated graphics rendering. Released in 1984, the PGC provided a 640x480
display with 256 colors in an era where 4-color CGA graphics were still common. From what I can tell from the surviving PGC
documentation, it essentially operated directly on VDI drawing commands on a 1:1 basis. It seems IBM’s Professional Graphics Series
was entirely intended to support the Professional Graphics Controller, and it may put things
in context if I read off the list of known software that was under this label. In short, there was IBM PC Graphical Kernel
System, the Plotting System Library, Graphics Terminal Emulator, and finally, the Graphical
File System. If you’re confused, well, that’s really
understandable since as it turns out, IBM had made their own implementation of the Graphics
Kernel System standard, and then sold it under the same name. As you might imagine, this made searching
for information a real joy. On top of that, it's the Kernel System that
has nearly all the drawing and interface functionality, what I have is actually an add-on library
for the IBM GKS. While the Graphical File System is technically
usable in and of itself, it’s obvious that it's one bit of a larger whole. More simply put, I have an programming library
add-on for another programming library ultimately intended for use with an obscure piece of
IBM hardware. I’m legitimately surprised that this ever
got sold in a box. The Professional Graphics Controller was not
what I’d call a mass market item, and I only knew of its existence due to a fluke. If you watch vintage tech videos, there’s
a good chance you’ve seen LGR’s video on unboxing and setting up his IBM PC AT. At one point, he flips through the manual,
and this, right here folks, is how I learned that the Professional Graphics Controller
exists! You really can’t make this up! With that little story aside, I will say that
it's not very surprising that the Professional Graphics Controller is so obscure even in
vintage tech circles. From what I can find, there was very little
software that supported it and I got the feeling that neither the Controller nor
the Professional Graphic Series as a whole were not what we could call successes for
IBM. Still, success or not, both the Controller
and the Professional Graphics Series are neat pieces of IBM history to say for sure. Maybe someday I’ll be able to demo the controller,
but for now, we’ll have to settle with EGA graphics. It’s at this point I’m pretty sure you’re
all expecting me to go install the Graphics Kernel System so I could use my obscure add-on
to do something fancy, and normally, you’d be completely right. The one problem is that the Graphics Kernel
System hadn’t been dumped by the time I started work on this video. I am going to draw emphasis to the word hadn’t
here. Originally, the script for this video contained
an entire section talking about how things like this never get preserved, but it appears
that fate intervened! In late November, a copy of all three volumes
of the Graphical Kernel System surfaced at the Computer Reset Warehouse. When I saw this, I was able to get in contact
with the finder, and make sure it got preserved! This alone is a major win in regards to software
preservation, and I’m grateful to those who made that possible. Anyway, with that, it’s time to close, but
before I do so, I need to ask for a bit of help from you all. While I currently have all the equipment to
save and preserve disk images, I’m somewhat less well equipped to deal with manuals. In the case of the Graphical File System,
and other similar products, the manuals are just as important as the disk dumps, and they’re
good to have regardless . I don’t have a flatbed scanner, and even if I did the GKS
manual was over 400 pages long. In the end, I ended up using this Neat Receipts
portable scanner to scan each page one by one but it was very slow and tedious. It did work, but wasn’t what I could call
ideal, and the colors ended a little washed out. I have quite a few manuals that need to be
scanned, so if you can help, please get in touch. I’m especially interested in hearing from
people who may be in the New York City/Northern New Jersey area. With that being said, I do hope you enjoyed
this video, and as usual, you can follow my adventures in real time on social media. As always, this is your host NCommander, signing
out, and hoping you all have a wonderful day.
Write-up is available here with extra details: https://casadevall.pro/articles/2020/12/exploring-the-ibm-graphical-filesystem/
Feedback of all sorts welcome