Gods, it's already December, isn't it. Time to talk about myself again, and this year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

There will be a lot of talking about computer touching, but also, likely, art outside of computer applications. Shall we begin?

01: Beginnings

I've told this story before. Several times, in fact. It's appeared in 2024, 2023, 2021, and 2019. This is less a worry about dementia and repeating myself (although I have now discovered there's a family history of this), and more because this story is the launch point for a lot of things involving my technology journey. It's not the earliest computer memory I have. That's Ladders and Hunt the Wumpus on the Kaypro. This memory, however, is the earliest one that I have of taking a piece of technology, and trying to figure out how to make it work for me, rather than accepting that the limitations placed in front of me are the sum total of what is possible.

I'd like to believe that I am at least telling the story with different details each time, so that the composite picture you get, layering each version of the story over each other, in the same way that you might layer up a CYMK printing process, means that more and more of the full truth of the story comes into being. Some parts are always going to be mentioned, are always going to be core, but the things that are relevant to the specific context might change. Or some other piece of the picture gets touched and now adds to the details of the story, refining, highlighting, adding shadows and depth.

As a tiny, I was not permitted to have my own machine. As a teenager, I was not permitted my own Internet access. This was in good parenting practice at the time, which was about monitoring and making sure that the children were not spending all their time on brain rot, and then to make sure that the children were not getting into age-restricted material.

This is the time of the Sierra adventure game, and where games could offer a wide palette of possibilities, between CGA, EGA, and the relatively newfangled VGA offerings, with games designed to be understandable with any of those color combinations in mind. It's also the time of Math Blaster, which I remember playing significant amount of, an EGA colored suite of Jeopardy! games, Avoid the Noid, with its chiptune public domain soundtrack played through the computer speaker, the various Carmen Sandiego games and their associated book where you looked up answers in, a fiendishly difficult Monty Python game that look some significant time to figure out a core component of the game, and of various game packages sold together. It's DOS, and if three's Windows, it's 3.0 or 3.1 at the most.

One of the first things I tried to do while playing a Jeopardy! game was to hit that pause button on the keyboard, which seemed to stop the operation, and then I went to the encyclopedias to look up the answer to a question. Once I had that, I hit pause again to resume, only to find that the pause key did not actually stop the operation of the computer and the timer ticking down to zero. Nuts. This is the first time where I find out that I don't fully understand the thing in front of me.

This was also the era where we made me a name tag for entering school with by designing it in Print Shop Pro and printing it off, rather than hand-lettering it, and that was apparently the thing that distinguished my name tag from everyone else's. There were a lot of things created on Paint Shop Pro in that era.

This was also an era where games often tied their execution to how fast the computer was running, because, in those days, a heady 8 MHz of clock speed was available, and in the family computer case, it could be bumped up to 16 MHz through a "turbo" key combination, and then brought back down again, similarly. This made some games a lot easier to run, or that they could be sped up if necessary or for additional challenge.

Engineer that my dad is, he had installed a program so that when the computer booted up, instead of an unfriendly prompt, we had a friendly menu that we could choose options from. He created pages for the kids so that we could access games and the things we were most interested in, without needing to use the command line for such a situation. This worked, for the most part, because this is also the era where people snark about Bill Gates talking about how 640k of RAM is good enough for everyone, and most programs didn't actually grab a lot of RAM. So the Automenu program and the game could coexist side-by-side without there being any issues of memory work. When there were issues, in the VGA era, we'd have to dispense with Automenu and instead work with boot disks to ensure there was enough RAM available to run the games we wanted to, which usually had helpful utilities for creating such things and ensuring that the bare minimum of useful things were loaded into memory, so as to have enough left over for gaming.

At this particular point in time, however, I was interested in a game called Sharkey's 3D Pool, a billiards simulator. It was fun to watch balls fly around and possibly play a couple of games against various opponents. (Sharkey himself, of course, as befitting a pool shark, was a perfect-play opponent.) However, Sharkey's 3D Pool was one of those games that needed more memory than was available to it with Automenu enabled. I didn't know this at the time, but I would discover it soon enough.

So, in DOS, much like in Linux today, (and UNIX before it, I'm sure), you have what's known as a PATH. PATH is a way of telling a computer "When you receive an input from the command line that you don't understand, search these locations to see if it matches something there. If it does, run that program." So you can make programs callable from anywhere in the file structure of the directory including the program is part of your PATH. Games being installed usually added themselves to the PATH so they could be invoked from anywhere, including by small children who just needed to remember to type the command.

Automenu was, essentially, a graphical representation of batch files, which contained commands to be run in sequence. Batch files and shell scripts are essentially the same thing, it just depends on which environment you're in. Anyway. The point was that the creation of menu entries was essentially putting together a batch file, so that when you selected the menu entry, it would run the commands in sequence. Because it was a relatively sophisticated program, it was also possible to edit and create new menu entries from inside the program itself, and this is where me, an enterprising youngling, starts upon their career of computer touching in earnest.

How much of being a computer toucher is running someone else's software because it's correct for the purpose, how much of it is in poking around in things and changing them to suit your purposes, and how much of it is designing and executing your own software is an exercise to the reader. And also a primary source of conflict with me about how much of the title of computer toucher fits me, and whether I should claim any part of it.

Back to the youngling, who wants to add Sharkey's to the list of possibilities available to them, and therefore goes poking about in the menu editor to see if there's any knowledge to be gleaned from studying the structure of menu entries. This memory is hazy, so the exact details have escaped me, but I do remember that I was able to pick up the syntax of how to create a new entry, and how to indicate what commands should be run when that entry is selected. I put together what I thought would work as a command and tested it. And I think it needed to be tweaked a time or two before I had it pointed in the right direction and getting the right command to run. But I did, at least, get it to the place I was looking for.

However, when trying to run it, Sharkey's kicked back a message to me saying that there wasn't enough memory available to it to run in EGA/VGA mode, and it suggested a command-line parameter to use to lower the graphical quality down a step or two and try it again. Which I did, and I think at CGA, it did run, because there was just enough memory available at that graphical level. However, if you've ever worked with the CGA palette before, "eye-searing" is often a useful descriptor of it, and I didn't want to play the game in that limited color array. I tried everything I could think of to get the program to run through Automenu, and nothing I did worked. (Also, I'm a small child in the pre-Internet era, so exhausting all of my available knowledge is much easier at this point.) Having exhausted my reserves, I turned to the knowledgeable expert (Dad) and showed him what I was doing and what error message I was getting, and asked for help in fixing the problem. So there's my first opportunity to get mentorship and learning.

Dad understood what was going on immediately, and explained to me that if I wanted to play pool, I would have to leave the confines of Automenu and run it directly from the command line. I remember being confused about this, too, because all of my Automenu fiddling was copy and modify, without understanding the principles behind what I was doing, or how I was going about what I was getting to. I think I was doing the equivalent of "C:\Sharkey\shark3d.exe" or that I had copied over a sequence that was "cd jeopardy ; jeopardy" and changing it to "sharkey" or something like that. Accomplishing the thing because the directories and executables were sensibly named (as much as could be in the 8.3 era, anyway), but without understanding what I was doing. So, I fumbled about a bit on the command line, trying to replicate what I had done in Automenu and failing pretty solidly and getting frustrated at my own lack of understanding. Dad helped me one more time with a key piece of information - what the "cd" command actually did. At which point, I understood the file, folder, and directory structure better, and that "cd" was short for "change directory". Once I could use the cd command to get where I wanted to (and "dir" to list what was available), I had the entire directory structure at my fingertips to traverse. And mostly used it to play games after leaving Automenu, because Automenu took up memory that I needed to play games.

That was my first experience with interacting with operating systems and understanding one of the core elements to file organization in a DOS system. I didn't go poking around in things that weren't the games section, because I wasn't interested in poking around in those things. You'll find that a lot of my advancement of knowledge regarding computers is directly or indirectly related to being able to play games on them. It's not a bad motivation, but it's certainly not the kinds where people are looking at a system and getting curious about how it works, or seeing what else is available on a system, or other such things. So that's another reason why "computer toucher" doesn't always sit well with me, because I'm not coming at it from the same place as some of the other people are.

That said, that underlying file, folder, and directory structure is exceedingly helpful to me when it comes to my current work, either because machines still use that structure (Windows does, and so do Android phones), or because I'm about to rain imprecations down on the Apple Corporation for making design decision to obscure that underlying paradigm in favor of saving everything to iCloud, or in not exposing folders, but instead making them links to cloud storage, or only making them accessible through apps. I get the idea. Abstracting away the underlying structure and presenting a user only with "locations" to save to, or something like that is supposed to make things easier to find later, and the abstraction still allows for folders to exist, and the like, but I often have to explain to people that the thing that's attached to the e-mail has to be stored somewhere before it can be uploaded to our print servers. I'm a practiced hand at making this work on all kinds of devices, but there are times where I wish Apple would make "save to local device" much less buried, and also, I want to rain a thousand curses upon whichever engineer decided that the "share" button should also serve as the way of accessing how to save a copy to either a cloud storage account or local storage. At that point, I pretty well believe that their abstractions are making things harder, and are designed to get people to pay for extra iCloud storage, rather than to be able to use the devices that they have in their hands. That's a business decision, but it also makes me strongly dislike iProducts and not want to give them my money.

From these, my beginnings, we go forward in time, but also to situations of different complexity, skill, and problem-solving. Mostly in the service of playing games, or in trying to do things that will keep me from being idle and therefore prone to the difficulties that come from being idle or hyperfocused.