Monday, March 19, 2018

Funny Support Stories

Through the course of my years in software, we had many encounters with technical support issues or bugs that were funny, either at the time, or looking back at them later.  Here are a few of them.

Close The Door

In the early days of personal computers, it seemed that no matter how well you documented instructions for installation of your software, a significant number of very non-technical users needed you to hold their hands through installation.  I remember at Synex, one of the support technicians almost falling out of her chair with laughter. When she finally finished the call, she told us what had happened.

She had helped the customer find the floppy drive on their PC, and told them to take the floppy out of it's paper sleeve, then slide it in with the logo on top and the open part in first.  Then she told the customer, over the phone, close the door. This of course meant the floppy door.

The customer said "just a second" and she could hear his office door closing in the background.  She almost died!

Where's The Any Key?

This is one of the old cliches of tech support, but I can assure you that it happened more than once. It was not uncommon for PC software to tell you to do something, then "press any key to continue".  More than one customer called us in a panic as no key on their keyboard was labelled "Any".

Corrupted 9-Track Tapes

Back in the day, telephones didn't have ring-tones, they actually rang. They rang by oscillating a magnetic field that made a little hammer wack two sides of a little semi-spherical metal bell on the underside of the telephone.  On occasion, someone would place an office phone on top of a stack of 9-track tapes. The phone would ring, and the top tape would be very effectively erased. Depending on how effective the little magnet was, you might partially erase the next tape down, too.

Putting one of these phones on top of floppies had the same effect, as floppies, like tapes, were magnetic media.

Fridge Magnets and Floppy Drives Don't Mix

On a similar vein, if a user had a bad time reading a floppy drive and it appeared to have been erased, it was often helpful to ask where the floppy was before getting to the computer. On occasion someone would stick it to a fridge with a fridge magnet ("I've never lost the fridge!").  This always worked as they were very thin and the magnet would hold it to the fridge quite nicely.  Needless to say, the magnetic data was nicely erased in the process!

The Wrong Floppy Type

The old 5 1/4 inch floppies held limited data, were big and a bit fragile.  So with the IBM PS/2 computer (not Play Station/2, Personal System/2), IBM came out with a new floppy, the 3 1/2 inch floppy. It held considerably more data than the 5 1/4 inch floppies, and a sturdier hard plastic case (it wasn't really "floppy" anymore) and was actually better technology.

We had a customer that we sent PK Harmony to on 5 1/4 inch floppy. When he couldn't fit it into his 3 1/2 inch drive, he tried folding it before calling us!

We sent him the right media and made a point of asking every customer what type of floppy drive they had before sending them media.

Providing Technical Support to GOD

At Liberty, we had bi-weekly support meetings to review how our tech support was doing in terms of meeting our SLAs for customers.  We had acronyms for most of our customers, and one of them was a company called Guaranteed Overnight Delivery.  Their acronym was GOD. This made for very interesting support meeting agendas and minutes!  It seems our technical support department was very helpful to the Almighty!

Mouse in the Agitator

I mentioned this story in a previous blog post from a few years ago, but I'll repeat it here.

At Liberty, we had a customer who had a D3 PICK system, and they were doing research for a cure for AIDS.  They did a lot of blood testing and had all the necessary equipment for doing it.

From the time that ODBC was first developed, Microsoft added a query tool called MSQuery to their Excel spreadsheet product.  This query tool is still there, largely unmodified. It does its job quite nicely! Unfortunately, MSQuery developed a bug that caused problems on just some computers. I believe that bug is long resolved but at the time it drove us nuts!  

This tool used the multi-threaded apartment model.  Even though you could have it pulling data back on a thread that was distinct from the thread that was updating the UI, every time you wanted to notify the UI that some number of rows had been pulled back, so it could update the running counter, you would have to call into the UI thread.  This meant that you put a blocking call onto the message pump for the UI.  This was not a big deal usually, but MSQuery would run into a situation where the message pump would get stuck unless you provided some user input to it.  This was not just a problem for us, but for any ODBC driver, it seemed.

This is how the bug manifested itself.  When you were doing a query, the little ODBC "World" icon would spin. When this problem happened, the world would stop spinning and nothing would happen until you moved the mouse or pressed a key on the keyboard.  Then it would start up again for a couple minutes before stalling once again.  Those stalls would stop both the UI updates and the query from retrieving data.

Our customer had run into this, and had a brilliant solution. He took his mouse, put it in a specimen agitator, and left it shaking until the query finished.  There was a constant stream of mouse movements that kept the query happening!  That was absolutely brilliant, out-of-the-box thinking on the part of our customer!

And that's one of the best things about my work over the years, getting to work with so many brilliant, kind, funny, good people!

Friday, March 16, 2018

Copy Protection Backfires

The Problem

Although there were lots of other personal computers, the IBM PC was the one that really took off for business use, and quickly surpassed all others, including Apple.  As the IBM PC and clones began to gain significant traction, software developers were faced with a dilemma.  The world of Software was a bit of a wild west. Was software subject to patent law? The Patent and Trademark Office of the United States initially said "NO!"  Software was like a mathematical algorithm, they said, and as such was not subject to patent law.  Was it subject to copyright? If so, did changing the variable names, and moving some subroutines around constitute a unique work?  Most software was delivered on 5 1/4 inch floppy drives. The YouTube clip below gives a demonstration of these floppies.

From day one developers of software were paranoid about someone stealing their software and reselling it.  Anyone with 2 floppy drives could make a full copy of one floppy to another.  It was easy to print out labels that would look like the original software. You could then resell potentially hundreds of copies of someone's software.  You'd get all the profit but the original authors got nothing. Because you didn't have the cost of developing or supporting the software, you could undercut them.

Copylock Protection

One solution to this was a product called Copylock.  They came up with a way to write to a track on the floppy, with special hardware, in such a way the the drives could read the track, but when copying the track, it defied the normal formatting and the drives would not copy the track.

Details of how Copylock worked are available here:

One of the most successful PC software companies, one that used Copylock protection, was Lotus. Lotus 1-2-3 came on 5 1/4 inch floppies with Copylock protection.  It was not uncommon for users to encounter a problem with their installation and would need to re-install Lotus. Copylock kept a count of how many times you had installed it, and it would only allow 3 installations before telling you that you had run out.  You could uninstall Lotus from a computer and it would increment its counter, but if your hard drive packed it in, or your 8 year old had discovered the "del" command, you had lost an installation.

Prior to my joining them, Synex had sent a software product that they had developed to an American software publishing company, in a bid to convince them to resell it. The company asked to see the source code, ostensibly to see its quality, and Synex sent it to them. That company told them shortly thereafter that they weren't interested in the software. A month later that company released it under their own name.  Remember that this was the wild west. There was no precedent of anyone being successfully sued for copyright over software, so Synex didn't pursue it.

As a result, they were very paranoid about piracy.  For their PC Harmony products for  Business BASIC and Wang BASIC they enlisted Copylock to protect their software.

When I joined Synex as their development manager, I noticed that we had a significant number of support incidents around people running out of installs on their floppy disks. In addition to taking a lot of support time, we had the cost of mailing them another floppy disk. Then one day, one of our Lotus 1-2-3 disks ran out of installs. I phoned Lotus support, who sent me another floppy, but instead of being another 1-2-3 diskette, it was software to disable the copy protection. They had figured out that the cost of supporting Copylock was higher than the risk of someone making a copy of the disk!

Removing Protectionism

I tracked for a time how much of our software support was due to Copylock issues and we quickly decided that we would stop using Copylock.  Our support costs dropped and our sales stayed steady!

One thing we had learned was that our product was complex enough that most users would want support, at least for installing the host software, so there was no real value in using the Copylock protection. The complexity of our product coupled with our excellent customer support was protection enough!  Lesson learned!

Friday, March 2, 2018

I Got Hired by Synex Systems

After working with Synex as a contractor from DataSense / Escom, I switched jobs to Synex Systems to become their Development Manager for PK Harmony and the PC Harmony products.

Synex was an interesting company.  One of the key people at Synex was Chris Graham.  In addition to terminal emulators, they were writing add-ins for Lotus 1-2-3.  They had a couple of Compaq luggable computers.  Below is a video clip of someone demonstrating one.

Murray my boss told me of going on a trip. Back in the day the airlines didn't let you take a computer as carry-on, so he had to check them in. He was telling the person beside him, in the window seat, about his concern that his computers would be OK, when the guy looked out the window and told him "I think your computers just fell 5 feet off the conveyor onto the tarmac!"  When he got them back to the office, he re-seated the boards in them, turned them on. One needed a new monitor and both cases were wrecked, but both ran just fine. Those Compaqs were truly rugged!

You could also get them with a built-in acoustic coupler, so you could put the phone receiver into it and dial up another computer.

Back to add-ins for Lotus 1-2-3.  You could only write them in Assembler, which was a pretty slow way to program.  There was a special piece of hardware call an Antron Probe, that would mount over the CPU chip. It would track all instructions going through the CPU and could back-trace these for you.  Chris took one of the luggables home for the weekend and reverse-engineered every entry point into DOS that Lotus 1-2-3 called, creating back-traces in assembler.  He then figured out how to hook a C program in.  Productivity for Lotus add-ins was immediately improved!

Chris later went on to be Director of Interoperability for Microsoft, and was a key contributor to Windows 3.0. The Easter Egg that listed Bill Gates and all the other key contributors listed Chris along with the others.

I also recall seeing a complete IBM BIOS assembler listing when I was still consulting there.  The draw was irresistible!  I had to work there!

It didn't take long for me to get my first Mark Williams C compiler. I poured through the Kernighan and Ritchie book, and went through the PC Harmony C and Assembler code.  I was hooked!

This was a time when it was possible to have a grasp of what was happening from your software right down to the hardware, before computers turned into onions with many layers.  You could order a set of Intel developer manuals and they'd ship them to you for free.  The first manuals were about 3 or 4 volumes, but over time they've grown. The last hard-copy ones I ordered were about 6 volumes and today you get them electronically. They are 10 volumes, but since they are electronic, they'll let you download them as 4 massive volumes instead.  I've always felt that the ability to visualize what is happening at different layers of a multi-layered, even distributed, application, is key to being able to architect, design and troubleshoot it.

At one point, I got to use a Compaq luggable that we called the "brick".

In addition to DOS, it had this cool new graphical Microsoft program called Windows 286.  It would do CGA graphics on the monochrome amber monitor.  It could also dual-boot into IBM's equivalent to DOS called OS/2 which had its own graphical component called Presentation Manager.

It was a really cool time to be working with computer software, and I was having a blast!

Saturday, February 24, 2018

PK Harmony - Terminal Emulation for PICK, and more

The Idea

In another blog post I talked about how Synex Systems had taken what we did for Terry Winter and turned it into a terminal emulator that could capture data from Business BASIC and Wang BASIC systems.  The owners of that company decided to pursue creating a version that worked with PICK systems.  A deal was offered to me that included me getting my own IBM PC computer in return for doing this little project.  I accepted the deal with great excitement!

The initial concept was to copy what the PC Harmony product did. The idea was that the terminal emulator software would respond to a special escape sequence, that was not used by any terminal we knew of, to shift into data capture mode.  It would then screen-scrape the data into an ASCII file, and another tool would allow you to define a ruler on the columns and capture the data.

This had some limitations. If you had summary lines, they often didn't line up, and created problems.  Also, when data wrapped in a column, it created interesting problems.

PICK had a query language called English on Reality systems, and Access on PICK systems (it actually had a bunch of names, but those two were the most common.)  It started with "LIST {filename}..." or "SORT {filename}..." and then you specified dictionaries for the columns you wanted on your report.  Dictionaries ranged from simple references to a field, to complex computed values. There were no joins, but you could reach into another file, if you could find its key, and pull out fields.  It was a pretty rich language and was very commonly used.

The Solution

So, I wrote a PICK/BASIC program that mimicked the LIST/SORT commands, but was called PICK-PC, and instead of padding and wrapping data for a columnar format, it delimited it.  Because both the PC and the PICK system had problems with high-speed transfers, and because hardware and software interrupts on the PC could cause it to lose data, we had to create an error correcting data transfer protocol for serial I/O.

The first version didn't handle some of the more complex computed dictionaries, but you could use raw data and could use "translates" to pull data out of other files.  In a pinch, you could stage the data you wanted into another file and then PICK-PC the data over.  I worked with the PC developers to come up with an architecture and design that would be practical on the PICK side, but still leverage the power of the PC.

More Horsepower Needed

It didn't take too long to realize that I had a little problem. I did much of this development (to earn my new PC) at home. But at home I could either boot into my 5 MB PICK partition, or my 5 MB DOS partition.  It was impossible to test PICK pushing data at the DOS side of the PC, as only one could be active at a time.  I also quickly ran out of room on my 10MB drive, so the company gave me a second hard drive. A 20 MB Seagate drive.

After a while, the company bought two AT&T 6300 computers. These were clones that were equivalent the the IBM AT class machine, which was the next generation after the XT. The video below shows one of these booting up.

Now I had a PICK system and a DOS system that I could run at the same time.  Both computers were quite a bit faster than my XT class machine, too, so that was another benefit.

Additional Features

In addition, I designed and the team developed a number of additional features:

  • A scripting language that the PICK system could use to drive PC activity. You could do a number of things like change your current directory, create a directory, check for existence of a file, run a DOS command, program or batch file.  
  • A scripting language that you could run on the PC to drive activity on the PICK application.  
  • We allowed you to take data out of several formats and upload it into a file on your PICK system.
The full feature list of the production version is listed in the product brochure below:

My First Spectrum Show

We went to a Spectrum show in Las Vegas to show off our prototype and get market feedback.  That Spectrum show had a special room called "PC Labs", and we had a booth there.  The first time I was doing the demo, I showed a LIST statement displaying some data on a screen.  Then I said "Now here's something you haven't seen in PICK." and showed them the PICK-PC command.

It was completely unrehearsed, but that line became our "hook". Everyone for 3 or 4 booths away trotted over to see this "new thing they'd never seen on PICK"!

We pulled up the same data in Lotus 1-2-3.  We did another set of data and pushed into a Wordstar mail merge.

Trivia Note: Wordstar was the first WYSIWYG word processor with mail merge capability.

We left that show with pre-orders for the product, and a list of interested beta customers!

What I Learned

For me, there were several things I learned:
  • I discovered PC programming and was intrigued at the possibilities.
  • I discovered the incredible rush of working with a brilliant team of creative geniuses to come up with something of value. Software is so much like magic. You start with an idea in your head and wind up with something valuable that people are willing to pay money for!
  • I discovered the excitement of working with sales and marketing teams to get something I helped author go to market!
  • I learned more about serial I/O and data communications.
Finally, although we were far from accomplishing our vision for the host scripting we had developed, that vision was in line with a recent trend called Robotic Process Automation.  Interesting to see it coming to fruition some 30 years later!

Note: For a long time, the computer systems used by most libraries in North America was PICK based system sold by Dynix. Synex had an annual contract to sell Dynix PK Harmony licenses in bulk to allow data transfers to other systems.  Our customers also included the largest McDonald's franchise in North America (in Florida), the London Underground system, and other companies, including  fortune 500 companies, that were using PICK systems in all industries and in countries around the world.  This was great exposure for me.

Sunday, February 18, 2018

Data Transfer from COBOL to REALITY and Back

First City Trust

While working for DataSense, one of the more active customers was First City Trust.  DataSense had software that was built for Canadian Trust companies, and First City was a big customer of theirs. I worked with a number of other Trust companies but First City was the one I spent the most time with.

First City had migrated their core deposit taking software to an IBM mainframe, but continued to run a number of business units on the Microdata Reality system.  This included mortgage banking (where they administered loans) and leasing. There may have been more but those two come to mind.

COBOL to Reality and Back

Because of Reality's convenient query and reporting language (called English on Reality, but other PICK systems called it Access), it was way faster to do reporting on the Reality system, so whenever management wanted a report from the mainframe, the quickest way was to get the data to the Reality system.

I wound up working with one of the First City IT people who knew COBOL to come up with a format that we could import into Reality. We had to do EBCDIC conversions and had to read the fixed width fields. This was a breeze compared with what I had had to do with the Terry Winter conversion, so I was always quick to create the imports for these. In some cases, I would create resulting data that would be EBCDIC converted and written to tape to go back to the IBM.

I wound up using the IBM terminals to track my time on the mainframe, and got used to using their messaging system.

Resetting Reports

First City had a printing system that was over 20 feet long.  They printed a ton of paper every day.  They also had to store a ton of reports. In an effort to reduce costs, they launched an initiative to figure out what reports were required, by whom, and were there other reports that would provide the information.

They managed to do some cleanup, but there were a large number of reports, some 100 or more pages long, that they were unsure if anyone needed them.

So they decided to take anything that they couldn't find an owner for and simply stop printing it, and see who complained.

Answer: No one...

I think they saved a few hundred acres of Amazon rain forest by that one initiative, reduced their storage and printing costs, and took an unnecessary load off of their computers!

Saturday, February 10, 2018

Pranks and Viruses

Over the years, at many places that I worked, the programmers I worked with were a fun bunch of people.  We'd have really intense discussions about technology and about how best to solve different problems, but ultimately, while we worked hard, we played hard, too.  Even the first viruses were more in the order of a prank compared with the ones we have today.

Changing User Prompt

One of the first pranks I encountered started out unintentionally when we were reverse engineering the Reality operating system.  We discovered a lot of interesting things, including that the very first byte (byte 0) of every frame (512 byte block of memory - that's how Reality organized memory) was not check-summed to ensure no corruption, but for one frame, it was actually used.  Both data and program space was organized by these 512 byte Frames. The first 12 bytes were used for linking and state information.  The rest was for data or machine code, for programs.

On PICK systems, the command line or shell mode was called Terminal Control Language (TCL).  The TCL prompt on Reality was a colon ":". For other PICK systems, they went with the greater than sign ">".

These first PICK systems, were what we called "Native" systems, where they provided the full operating system. Later versions ran as a shell on top of Windows, Unix, Linux and other platforms.  Prime Information was the first one to run as a shell, on PrimeOS, but it was the rare one. On these native versions, the first, lowest numbered frames were where the "operating system" and user assembly programs were typically loaded.  For most of them, frame 6 was the one that handled user terminal I/O.

On most PICK systems, byte 0 of frame 6 held the TCL prompt character.  If you had access to the system debugger, you could change that byte to any character that you wanted.

Be aware that while the TCL prompt character was ":", the BASIC debugger prompt was "$", and the system debugger prompt was "!".  These prompt characters would tell you that you were in different states.

When we discovered this, we changed it to another character to see what would happen. This was on a multi-user system, and we had other programmers doing work. As we changed it, we could hear swearing from the next room. We hadn't intended this as a prank, but it was too good to pass up! For fun, we changed it to the BASIC debugger prompt.  More swearing.  How about the system debugger prompt (this was getting too much fun!)  The swearing was sounding worried.  Then we changed it to the character that cleared the terminal screen.  This was too much!  The programmer in the next room came running over to say that the computer was having serious problems, only to find us laughing uncontrollably!  He realized he'd been had!


On all PICK systems, there was a file that controlled the error messages.  While you could mess with any of them, by convention this was frowned on, with the exception of ERRMSG 3.  This ERRMSG simply printed the words "VERB?" and returned to the TCL prompt.  It was the error message you got if you mistyped a TCL command or intentionally typed random garbage at TCL and pressed return.

001 E VERB?
EOI 001

[3] VERB?

It was generally considered OK to make changes to this ERRMSG.  For most customers, this would be a simple change to something like "WHAT???" or "SAY AGAIN?", but for a couple of our customers, they were always on the lookout for something really elaborate or different to put in it. I saw some that were like 12 lines of text, suggesting you present yourself for a Bozo award.  Finally, one customer changed it to "BUTTERFINGERS!". Unfortunately, there was a worker in a warehouse of theirs who had really big fingers, and was convinced that it was personal. That was the end of them changing that error message!

Water Detected in Drive A

In the early days of DOS, I remember finding this program called "Drain". It was actually an executable called "".  You'd run it, and it would create what looked like a DOS prompt "A:\>".  The moment you typed anything, it would send a beep to the system speaker, and display an error message:

"Water detected in drive A"

The cursor would flash for about 3 seconds, then it would display another message:

"Starting rinse cycle"

Now spinning a 5 1/4 inch floppy drive made a sound a bit like a washing machine on rinse or spin cycle. Enough that you got the idea. It ran the rinse cycle for about 5 seconds, then printed out:

"Starting spin cycle"

This ran for another 5 seconds.

It would end with a message saying something to the effect of "Drive A is now dry - you may resume work." and it would drop to the DOS prompt.

My wife was volunteering as secretary at our church and she ran it, then called the pastor over, telling him something was wrong with the computer.  Great fun!

Airplane Pilot Attempts to Outrun Electrons

One story a colleague of mine tells is of a software package that they had developed for airplane maintenance. The computer also had a word processor called JET and pilots would often use this to write letters.  They were at the Boundary Bay airport and a pilot was using the system as a word processor to write up a letter.  In typical style, still emulated by software programs today, if you typed the keystrokes that would delete your document, the program would ask if you really wanted to delete the document and you could type "Y"es or "N"o, followed by Return.  If you typed "Y" followed by Return, the program would tell you that document "xxxxx" has been deleted.

The pilot did the wrong keystrokes, and had typed "Y" + Return, and got the message saying his document was deleted, before he realized what it had asked him.  The quick-thinking pilot reached over his terminal (they were quite big affairs - see below) and yanked the serial cable out, then ran like mad to the computer room where he pulled the serial cables out of the back of the computer. Then he walked over to my colleague, Jan, who was watching all this in disbelief from another room, and asked her if she thought he was fast enough to stop his document from deleting!

The pilot reached over this and pulled out the serial cable on the back

Coffee Machine is Access Protected

One of the error messages that the computer would occasionally display was one that indicated that an operating system function had tried to access memory that they were not permitted to access or that was not properly initialized.  The message was to the effect that something "... IS ACCESS PROTECTED". It would then display the message "Abort @n.m". "n" was a frame number and the "m" part was the offset within that frame. This was the address of the program instruction that encountered the error.  It would then drop you into the system debugger, with the exclamation prompt "!".

Encouraged by the antics of other programmers that I knew, when working at First City Trust, I decided to create my own program for locking out my terminal while I went for coffee or lunch. I created a program that displayed what looked like a blank screen with a TCL prompt ":".  The first two times you typed anything into it, it would print the "VERB?" output, giving people the idea that they either mis-typed, or something else was going on.  On the third attempt, it would print the message:

ABORT @12:00 noon

The exclamation mark "!" made it look like the system debugger.  At any of these prompts you could type a special password and you'd drop out to real TCL.  If you typed anything else into that last "!", it would display messages to this effect:


Regardless what you typed, it then displayed


(SYSPROG was like the root account for these PICK systems.)

Finally the dots would stop displaying and it would log you off.

Note: No real SYSPROG accounts were ever hurt in the running of this program...

April Fools Day Endless Reboot

When I worked at Synex Systems, one April 1st, one of the programmers pulled a prank on all the other programmers.  The night before, he stayed late and changed every programmer's computer's autoexec.bat file to run a program that forced a coldboot just before finishing.

The effect of this was an endless reboot.  The first people arrived, started their computers and walked away. They'd come back with a coffee and the computer was still booting. OK, computers were slow at booting up (and many times still are), so they'd read a magazine for a few minutes. Finally, the realization dawned that this was taking too long, and that BIOS message they were looking at had already displayed twice...

You had to reboot off a floppy and edit that autoexec.bat file to fix it. That was a good April fools prank!

Stoned Virus

And then there was the stoned virus. It was one of the first real viruses, and very prevalent for a number of years.

When a computer boots up today, it looks for an operating system boot-loader in the "boot sector" of your hard drive. On the original IBM PCs and clones, the BIOS would start by checking drive A, then the fixed disk.  It was not uncommon for someone to load a program or data disk into drive A, forget it was there, and shut their machine down.  When they booted up the next time, they'd get an error message that the disk in drive A did not have an operating system on it.  You would remove the diskette and type Ctrl-Alt-Del to reboot.

The stoned virus was called a "boot sector virus". When you left an infected diskette in drive A, it would actually run a program that scanned your computer for diskettes and hard drives, and would add itself into the boot sector. Then it would display a message on your screen saying "This computer is now stoned." and it would print the standard error message saying that the diskette in drive A did not have an operating system.  You'd take the diskette out and reboot and all would look good. If you worked at Synex, you'd be convinced that one of those darned programmers put that "stoned" message on your computer as a prank.

Thereafter, every time you booted your computer, it would run this stub before running the operating system. Any diskettes you left in, it would attempt to write to the boot sector and infect it during boot-up. After boot-up, any diskette you put in, the now-infected operating system would attempt to infect with this virus.  Although I heard rumours that this virus would occasionally randomly delete files, to my knowledge, other than replicating itself, the only other thing I ever saw it do was occasionally it would display "This computer is stoned" message randomly during operating system boot-up.  These were the days of relatively benign viruses.

I knew of a company that published 6,000 diskettes to go out along with copies of Aldus Pagemaker, only to be told by Aldus that all of these diskettes were infected with the stoned virus!

We got in the habit of write-protecting all our floppy diskettes that we sent out to prevent our media from being infected.

This practice came in handy on multiple occasions. One such occasion was when I was at a large New York law firm, and someone came to me to say that there was something wrong with my diskette. I looked and he had an error message about not being able to write to the diskette. I pointed out that he should never write to our diskette, then got him the program that checked for the stoned virus.  He ran it and it turned out that every computer in the IT group had this virus!

Virtual Hand-Brake

And finally, in the same vein as the aforementioned airplane pilot, I leave you with an innovation that a number of us came up with, but no one ever figured out how to implement: The virtual hand-brake!

Have you ever had one of those times when you realized that the computer was causing havoc faster than you could undo it?  You need a virtual hand-brake!

I could probably go on for hours, but it's been long enough for today!  I hope you enjoyed this little trip down memory lane!

Saturday, February 3, 2018

My First Computer!

The company made an offer to some of their employees, including me. There were a number of opportunities available, and if you agreed, on your own time, to create one of the suggested products, the company would buy an IBM PC XT, and you would over time become the owner.  I'll talk about the project I was offered in another post.

So, I got my first computer. It was the IBM PC XT. It had dual floppy drives and a 10 MB Shugart hard drive.  Terry Winter had a 10 MB hard drive that was larger than most modern desktop systems, so I was impressed with how small it was, and convinced I wouldn't run out of space for a long time.  Was I ever wrong!

Partitioned half the hard drive and would boot into R83 from Pick Systems.  At that point, half my drive was unavailable for DOS stuff.

Then, I got hold of something called Revelation version G.2, and shortly thereafter, a bug-fix of G.2b.

This took up some of my space and I started creating applications with it. I had two applications that my church used for tracking finances and Sunday School attendance.

The Rev G.2b application I wrote for my church - still runs under DOSBOX!

The final blow was when I got a Mark Williams C compiler.  Suddenly, I had to manage my space, and back things onto floppy (never just one, it was always a series of floppys.)

The problem with backups on floppy was that the likelihood that one diskette having an error was fairly low, but when you multiplied that by 4 or 5 floppies, the likelihood went up. If you took one backup, you'd have a bad floppy. If you took two, you'd have a bad floppy in each. If you took three, all three would be fine!  Did I mention that floppies were slow? They were just slow enough to drive you crazy, and just fast enough that you couldn't really do anything else. And this was DOS. If you were copying to a floppy, you were not doing anything else!

Still, it was exciting times, and I loved the amazing new technology!

We changed the company name.  It was Toga Computer Services ("To"ny and "Ga"ry were the founders - hence "Toga".)  Occasionally we'd get calls from people who thought we were a laundromat.  The new name was Datasense.