Showing posts with label os/2. Show all posts
Showing posts with label os/2. Show all posts

Thursday, January 21, 2016

DOOM and the raiders of the lost hours

My first PC compatible computer ran DOS and Windows, and OS/2 and... DOOM.

In between rounds of development work on Liberty BASIC I would take breaks playing DOOM.  By today's standards this is a crude looking game, but back then it was really groundbreaking.  Playing it in a dark room was a good way to scare yourself half to death.  Today I would surely consider it rather tame.  The only thing that really compared to it was a game called Ultima Underworld which was actually a smoother and more detailed real-time 3D game.

In the world of PC gaming it really was all DOS.  Running Windows or OS/2 sucked up too many resources from what was typically a 33MHz 80486 computer.  The game would not play well.  Even when running DOS you needed to use HIMEM and play all the tricks in the book for there to be enough memory.

Other games that wasted my time included Falcon 3.0 which is probably the perfect air combat simulator and a cool game called Theatre of War which was sort of a real time version of Chess, kinda.

Sunday, January 3, 2016

Bugs Bunny and Raytheon

When we were well along in our project for the Defense Nuclear Agency, a couple of developers from our team were chosen to go to Albuquerque, New Mexico to field test the system.  Part of the system was designed to help provide security by means of motion detection in the desert.

To make this happen we needed to build a custom computer that ran OS/2..  This PC included hardware which could interface with motion detection cameras in order to log motion detection events which included video frames showing what the motion was.  So we were all excited to know that our system was going to take pictures of tumbleweeds and Bugs Bunny in the desert wasteland.  ;-)

Most of the assembly of this custom hardware was done at the Wyman Street, Waltham IBM office where we worked, but Raytheon in Burlington, Mass was responsible for the final integration and shipment to the test grounds in Albuquerque.

So, off to Burlington we went with server in tow.  When you visit Raytheon you have to go in the front door and sign in, and you have to have an appointment with someone who will meet you at the door.  So one of my colleagues and I followed this procedure and found one of our other teammates working on the machine, trying to get OS/2 to start up and load all the drivers properly, but he was having some trouble.

Then a couple other members of our team showed up, but they were unescorted.  So they were asked how they got into the building.  They said rather innocently that they parked in back and as they approached the back door someone came out.  That person held the door for them and they got in without signing in at the front desk!  Uh, oh!  Who was it that let them in?  They didn't know this person, and presumably he went for a walk for took off in his car, so it wasn't going to be easy to figure this out.  They didn't know they were breaking security protocol.  Okay so they went to sign in.

Now we turned out attention to the server again.  We were trying to figure out how to get all the drivers working and we were having some trouble.  This fellow with a clipboard came to us and said that he needed to pack up the computer and put it on the truck to ship it to Albuquerque.  We told him that it wasn't ready, and he walked off.  Some time later he came back again and we told him it still wasn't ready.  Finally he returned and said, "Okay let's ship this thing.  I've got to check this off my list!"  We game him a sharp look and told him firmly "Look buddy, this machine isn't going anywhere until it works.  We will tell you when it's ready."  He did not like this at all, but we really couldn't have cared less.

I guess he thought a non-working computer was good enough for government work.


Friday, January 1, 2016

How to make a RAID array failsafe

The computer that we used to manage the source code for our Defense Nuclear Agency prototype was an IBM System 95 server.  One of the nice features of this system was a three hard drive RAID array.  The special property of this system was that if one of the drives failed, the contents of that drive are recomputed on the fly based on the other two good hard drives.  The drives were hot-swappable, so it was possible to eject the bad drive and replace it with a new one while the system was running.  That drive would then be formatted and it contents rebuilt from the other two drives while the system was in use.  Very cool technology!

One day we decided to reboot the server.  When we did the OS/2 operating system produced an error message on startup saying that one of the drives in the RAID array had failed.  We were shocked.  We should have received an indication of this when the drive actually failed.

So what happened?  These special hot swappable hard drives have an error light that turns on, and also a piezo buzzer that sounds when the drive fails.  The trouble is that the drive failed so completely that the piezo buzzer also failed.  We never heard the audible error sound that we were supposed to hear.  This was a vulnerable moment for us.  If one more of the hard drives were to suffer failure we would have lost work.  We did back up our code periodically to an external cartridge, but it had not been done for weeks.

So clearly IBM had some work to do perfecting their RAID products.  For example, if the piezo buzzers on the other hard disks were designed to sound when any of the other drives failed, this might have proven much more effective.

Thursday, December 31, 2015

Liberty BASIC at IBM!

While working on our prototype for the Defense Nuclear Agency I discovered that we needed to reset some files repeatedly whenever we tested and demonstrated the functionality of our system.

I was eager to put Liberty BASIC to good use, and since we were running on OS/2 this gave me an opportunity to create a utility that would make things easy.  Liberty BASIC to the rescue!

It was actually easier to create this utility in BASIC than it would have been in Smalltalk.  Smalltalk is very powerful and really is one of the best languages, but BASIC is stronger for banging out small and simple programs.

I took great pride that when were were demonstrating our system to the customer that they also got a demo of Liberty BASIC in action!

Wednesday, December 30, 2015

IBM Smalltalk and team development

One really great thing about getting the job at Gem Consulting was that we were developing in IBM Smalltalk for OS/2, on IBM computers at IBM.  So we had access to quality support.

My experience using Smalltalk up to this point was using Smalltalk/V which was a popular and very good Smalltalk product.  The IBM Smalltalk was fancier and included GUI drawing tools and source code management, and working with a team of developers (there were four of us) gave me important experience that I never had before.  I learned so much by developing software with others and it taught me to break software down into modules even more effectively than I ever had.

The working space was an audio visual presentation room with an LCD projector that dropped down from the ceiling.  Around the outside of the room were tables where we worked.  We were able to communicate effortlessly because we were in the same space, and when we needed to design or make plans we would all turn our chairs around and use tables in the middle of the room.

Our development of this project went swiftly and smoothly.  I really enjoyed this style of work.

Tuesday, December 29, 2015

Onward and upward!

In my time at CFC Incorporated I had several interviews for work in Smalltalk.  One of them was in Cambridge, Massachusetts.  They focused a lot on Unix in the interview, or at least that's the way I remember it.  I never got a call back from them.

Another interview was with a company in Waltham called Marble Associates where my friend Laird Popkin worked.  This job seemed fantastic, and the interview was going great.  But when they told me that it was a traveling job which required that I fly to the client every Monday through Thursday I regretfully declined because I was unwilling to be away from my wife and children and also my church community in that fashion.

One day in 1995 I was contacted by one Peter Statterman, and he told me that his company GEM Consulting was looking for an experienced Smalltalk developer for a joint IBM and Raytheon project for the Defense Nuclear Agency of the US military.

We met at a coffee shop in Natick, Massachusetts and he interviewed me.  I must have said something right because he hired me!  It was exciting to be working on a project for IBM on the OS/2 operating system platform.  I was already working on Liberty BASIC for OS/2 and so this gave me the experience I needed to jump right into the project.

GEM Consulting hired me as a subcontractor.  The money was really good, but it was only a three month contract to create a prototype.  If that went well they would extend that to another six month phase.

My intention was to focus on Liberty BASIC when the contract ended and try to launch a full time business.

This was the start of a new chapter in my software development career!