Hiking & Writing
Macros are fun. Having the right macro – especially one you’ve struggled to write yourself – is like a Get Out of Jail Free card. When the software you depend on doesn’t do what it claims to do, or what you need it to do, then sometimes a good macro will provide a way of escape.
Microsoft’s Visual Basic for Applications (VBA) is a good example.
When Silicon Image was still a small company, I worked directly for the VP of Sales. One day he came to me and asked if I could come up with a way to track upcoming design wins. Up to that point it had been done manually, through e-mails among the participants. There were few off-the-shelf tools back then, and no budget for a fancy database system, so he asked me – the only one adventurous enough to engage with Microsoft Office in serious terms!
I read and experimented, and ended up with some sophisticated Excel spreadsheets, with pivot tables, graphs and charts, and protected areas on worksheets.
The project expanded to include budget planning, equipment tracking, etc.
Eventually, when the company grew, a whole new set of real point tools came to us, along with a staff to do this tracking. I continued on with my Application Engineering job. But for the time when it was needed, I stepped up and learned a new tool set and delivered.
Silicon Image eventually came out with a chip which couldn’t be controlled by simple register reads and writes. The chip designers created a device which could accept a video input stream and scale the image to a new resolution. It could also superimpose a message or picture onto the stream: an on-screen display (OSD) message.
To define and modify these OSD messages (text or picture) one had to program a lot of registers for font, color, character strings and image. It was not practical to do this with peek-and-poke instructions.
I saw a problem waiting for a solution!
Go down to Home Depot for a fancy screwdriver-combination-wrenchifier-thingy? What? It’s only $29.99?
Just gimme my toolbox and leave me alone. I’ll make it work.
$29.99. It reminds me of how the Internet wants me to buy a new software tool for everything. Need a new web page? Buy my new editor; my new web language; my new UI designer library. Need a new program to control your streaming device? Buy this online, cloud-based, Web-oriented, futuristic language system! Buy before midnight tonight and we’ll throw in the manuals and a 29-session video course for free!
Gimme my toolbox.
Gimme a break!
A good text editor, a good C compiler/linker. A good command line based operating system. A decent I/O library. And I’m all set.
Actually, who needs a compiler and linker? Just give me an assembler and I’ll re-write part of the operating system to make it leaner, faster and so proprietary we’ll have a professional marriage made in heaven.
You laugh? I’ve done all of those things.
Yes, even the marriage made in heaven.
In the early 1980s (remember?), before personal computers replaced mainframes, and before we cycled back to the thin-client and server architecture (which, by the way, isn’t much different from the “smart terminals” and mainframes of the 1970s – sorry to disillusion you), there were times when the program wasn’t fast enough, or wouldn’t fit into memory. Imagine? In 64KBytes it wouldn’t fit? On a 20MByte hard drive it wouldn’t fit?
Well, yes, the title is a blatant attempt to squeeze a few keywords into one phrase. But, yes, there was word processing on mainframe computers, even before there were PCs.
This is the story of bending such a text processing system to do my will.
Back in the olden days, there were things called “mainframe computers”. They got that name because they were in mainly big – very big – frames, and computed, and were kept in air-conditioned rooms while human beings lived in the heat and humidity that had been their lot in life for generations. Ah, to be a mainframe technician! It meant staying cool in the weather of the East Coast. But anyway, these massive machines were connected to terminals, each providing typed input and showing the output of programs running on the computer in a time-shared environment. Sounds like client-server? Well, not so far off.
Well, the mainframes had programs which could format text into printed materials. These were text processors. The output was printed on equally massive line printers in the same air-conditioned room as the mainframe. One had to walk down the hall to get one’s “print-out’, and check it for errors. IBM had a very good example of this system with their IBM/370’s and their Script/VS text processing program.
This was the beast that had to be tamed.
Yes, indeed, I can write code with one hand and wire-wrap with the other. “Prove it,” you say. Well, I did in the late 80s.
After several years working on test equipment purchased by IBM, I decided it was time to take the plunge. A different department in IBM was developing a new tester in-house, and they needed help. So, an interview or two, and I transferred over there.
I arrived in time to get the assignment to design a “fail buffer” subsystem for the tester. This peripheral would collect fail information as the equipment ran patterns on the prototype memory cards. Software would be needed to count errors in that collected data, analyze patterns in the failures (row or column problems), and output reports. “I can do both – the hardware and the software!” I said. “It’s yours,” replied my new manager.
I see this pattern in the projects I tackle in my professional life:
I enter into a new field – whether a new computer type, a new programming language, a new technology; I learn it; then I write about it and explain it to others; then I find its limits and try to push through those limits.
It began early.
