 |
 |
|
Hungarian notation was suggested by Charles Simonyi, the third employee at Microsoft. He was hired (among other reasons) to modify the source code to the Magic Wand, the word processor that I sold to Bill Gates in September of 2000, to become what is today Microsoft Word. I agree with Les that Hungarian notation isn't the silver bullet that many development shops thought it was. I've seen plenty of variables declared with long, carefully composed Hungarian prefixes and meaningless names. It's better to spend more effort time on creating meaningful names that make it clear what the variable is for rather than on complex notation. However, I don't agree if Microsoft think .NET has enough type-safe features to let you safely handle variable type mismatches. While it has some type checking, there are still many cases where you can mix and match variable types without really realizing it. You still need to be careful. I've seen applications where implicit type conversions completely trashed performance.
Well, I won't bore you, so I'll leave out the background details. But here's the main plot: get an 8 MB WAVE file from Computer A to Computer B. Now, they were both laptops, but the one ran Win 95, while the other was running XP. Of course, the first thing you would want to do is stick a USB drive in and transfer the file, but there was no USB slot. So, I decided to send it over the internet, but the computer wasn't meant to connect. The only logical thing to do is see if I can use Infrared to send it, but I didn't want to hassle. So, I did the illogical: send it in a Floppy. Being new to old stuff, I first tried to drag-and-drop it onto ol' A:\ drive. But then a message box comes up saying there's not enough room to fit it into a floppy. Now (obviously) there's no WinZip on the computer, so that means I'll have to parse it into about 8 files. With that in mind, I opened the most advanced sound editing tool on the computer (that would be......Sound Recorder) and went to work (after getting some more floppies). As you know, any computer manufactured in the 21st century doesn't have a Floppy drive, so I had to use Computer C, a desktop with Win 98 installed, as a mediator. All things reassembled, I decided to send it to the XP. No internet. BUT it did have a USB drive. Not wanting to waste time, I grabbed a flash-based MP3 player and stuck it in the slot. But it's WINDOWS 98, which means you need a DRIVER to install anything remotely foreign. Not wanting to hassle (any more), I decided to go grab a REAL flash drive, transfer it, and end my days in peace. 10 months later, the XP's hard drive crashed, losing the file (at least I didn't need it then)
Back in the old days, I was a field engineer for a company that manufactured large-scale OCR (Optical Character Recognition) equipment. This wasn't anything like the desktop scanners on PC's like we have now. This was the big iron - the biggest and fastest OCR systems ever built. The basic design stuff was done in the late 60's. But the technology was updated in the mid-80's, and served well into the 90's - in some places, it's still in use today. The company itself is gone - they had some dynamite technology that was worth quite a bit of money, so the company was the victim of a hostile takeover. It was broken up and sold off in pieces. They, for example, used (and basically invented) the first viable ink-jet printer. They had that going in the early 70's. They were doing OCR on checks and credit card invoices at the rate of 1200 documents per minutes in the first generation machines, later 2400 documents per minute. They has a page reader that could read entire 8 1/2 by 11 inch double-spaced pages at the rate of one per second, and could handle documents as small as index cards. Keep in mind that they were doing the OCR in real-time. None of this "buffer-the-image-and-analyze-it-later" nonsense. My experience with desktop systems is they can't read anywhere near as accurately even at the slow rates at which they run. The transports that physically handled the documents were massive mechanical beasts. The full-blown version was 62 feet long. The CPU was a mainframe (a small mainframe, but a mainframe nonetheless), and the second-generation systems had two mainframes. We got to be so good at transports that one of our most profitable systems was used by the Federal Reserve banks to handle money. It would count the money, check for counterfeit, check each bill for proper denomination, and also check each bill for "fitness for service" (is it worn out yet?). If it was worn out, it was shredded on the spot (there were a couple of other tests that I'm still not allowed to talk about). Last, but not least, they were stacked in stacks of 50, wrapped in bundles, and the bundles were dumped into a basket. All at the rate of 1200 bills per minute, with dollar bills traveling down the length of that machine at 300 inches per second. Just YOU try to get paper moving that fast. Another machine moved paper even faster than that - 400 inches per second. These customers had to have a team of technicians on site 24/7. These systems had the old 9-track tape drives, no hard drives, and the first generation machines even had the old memory drum and paper tape readers and punches, and all of 16K - that's right Kilobytes - of magnetic core memory. The beast was programmed in assembler. You could wreck a field engineer's whole day by telling him you were going to crank up the page reader - all two tons of it. It was a nightmare of a Rube Goldberg bastard, but when it worked, it was magnificent. All this stuff sounds extremely low-tech by todays standards, but by the standards of the day, it was the absolute cutting, bleeding edge. The tape drives were those that had vacuum loop boxes on them and selector dials at the top to select the unit number. Now - here's the first story: One of the tape drives at the site of a major oil company was having problems handling tape, so one of the guys (I'll call him Mike) was going to fix it. Now Mike was a competent guy, but he'd partied just a little too hard the night before and wasn't at his best this day. To check the vacuum we had a manometer. That's a U-shaped plastic tube calibrated in inches with fluid in the tube. You'd apply pressure or vacuum to one side of the tube, and the pressure differential would move the fluid a certain number of inches. The fluid is the story here. If you were measuring lower pressures, you'd use a water manometer. The specs would call for - an example here - for 25 inches of WATER. Water was one of the fluids used. The other fluid was mercury, used for higher pressures. The specs might say 25 inches Hg (Hg is the scientific symbol for mercury). There's a heck of a lot of difference between 25 inches of H2O and 25 inches of Hg. The tape drive wanted something like 32 inches of Hg at the vacuum chamber. Mike got a WATER manometer. The manometers were identical - the only difference was the fluid in them. Little problem - we didn't use water in our water manometers. We used a very aromatic red-colored oil called "Unity Fluid" which was made for just for this purpose. It had the same specific gravity as water. To this day Mike can't say exactly what went wrong - whether he thought he needed a water manometer, or whether he grabbed the wrong manometer. Anyway, he hooked up the manometer inside the drive, then went around front and powered up the drive, watching the manometer the whole time. As soon as the drive powered up, all the oil disappeared from the manometer - the vacuum was powerful enough to suck all the oil out of the manometer and into the drive. In just a couple of seconds we could hear the clicking of relays and circuit breakers as all the myriad power supplies shorted out from having this red oil sprayed in them, because as the vacuum motor sucked this oil out of the manometer, the oil went through the motor and sprayed out the back. Mike and I both went running full speed the the back of the tape drive to kill the master circuit breaker, and we both got there at the same time. Next problem - we were both tall skinny geeks, well over six feet tall, and we collided. Another problem - that oil was now all over the floor behind the drive. Mike hit the oil and went sliding into the wall and broke through the sheetrock of the wall and was stuck there. I dove for the breaker, slipped on the oil also, fell, and went sliding past. Mike is painting the air blue with his vocabulary because he's still stuck in the sheetrock. I struggled to get my feet under me, but I wore nothing but cowboy boots in those days, and those boots didn't get good traction at all in that oil. I went down again, but this time I landed right behind the drive and killed the breaker. We didn't want a fire. This was before the days of halon dump systems. This place had a carbon dioxide dump system. If you were in the room when the Co2 dumped, that was all for you. You died. You had a 60 second countdown before the Co2 went, and you had that long to clear the room. The worst parts of this were these - we had to explain to both our boss and the customer why one of their four tape drives with a minor malfunction turned into all tape drives down (the tape drive involved was the master tape drive, which contained the control electronics for the entire tape drive array), why the customer now had a big hole in their wall, and the fact that this was second shift on a Friday, which meant that there was no third shift to fix the drive for us. We had to spend the whole weekend cleaning that oil out of the drive. The Environmental Protection Agency would have stood us in front of a firing squad if they'd ever found out how we cleaned the oil off the circuit boards - we took all the circuit boards and power supplies out of the drive, took them outside and rinsed them off with Freon TF (which is a magnificent degreaser). We went through a LOT of Freon. I think we were responsible for at least part of that hole in the ozone layer. The customer's maintainance guys never said anything to us about having to patch the hole in the wall. It was a pretty big hole - but come Monday morning, the patch in the wall was covered by a big, thick sheet of foam rubber. Another day, same place. In doing this OCR, the OCR read station required a LOT of light. Specifically, we had two 1000-watt quartz halogen lamps maybe a quarter-inch from the documents. They were moving too fast to ever catch fire, but if you had a document jam at the read station, that changed. I mentioned the ink jet printers. The ink those things used was acetone based. Acetone, as you may or may not know is HIGHLY flammable. Much more flammable than gasoline. Nail polish remover is nothing but acetone and lanoline. If the IJP screwed up, it would befoul itself with ink. Then it really wouldn't work again until you'd cleaned it up. For that purpose, we had handy a squeeze bottle full of acetone. One of the operators was a slow-talking, slow-walking Southern boy. If you didn't know him, you'd think he was dense, but he wasn't at all. Just in perpetual slow motion. He was also very handsome - always had a string of girls. Anyway, he'd had a jam at the read station, and a small fire. No big deal. Nothing I couldn't fix in a couple of minutes. But he panicked, and looked around for something to squirt on it to put it out. He saw the bottle of acetone, grabbed it, and looking down at the fire, squirted. What happened wasn't an explosion, not exactly. It was more like a tremendoudly loud WHOOMPF! Operator jumped back with his hands over his face. He wasn't injured, but he had no hair on the front half of his head. No eyebrows or eyelashes, and his hairline had been moved to the top of his head, and what was left was severely singed. But that's not all. Another operator saw this, thought his friend has managed to blow his face off and panicked also. He saw a fire extinguisher nearby, grabbed it, and used it to "put out the fire" (which was already out). But this wasn't a Co2 fire extinguisher, nossir. Of all places to put a dry chemical fire extinguisher, a computer room was the worst. Co2 will put out the fire, and will leave no residue. But that fire extinguisher powder was everywhere Worst place for it to be was the power supply that provided the 100 volts DC for those read station lamps. For whatever reason, that was the heaviest power supply in the whole system (over 200 pounds), and I had to drag it out, put it in the trunk of my car, carry it into the office, order a replacement supply, drive out to the airport, pick up the replacement supply, put THAT in the trunk of my car, drive that one out to the site - and did mention that this anvil wasn't mounted at floor level? Nossirree Bob, I had to put on old clothes, crawl up into the machine, lay on my back in fire extinguisher powder without breathing any of it while two guys laid the supply on my chest. I about gave myself a heart attack bench-pressing it into position, and HELD that S.O.B. in place while they bolted it in. And the operator is panicking again - this time because one of the women had held up a mirror, he saw what his hair looked like, and he had a date with one of the hottest girls in the place that night.... Hey baldy, pardon me if I don't feel sorry for you not nailing Linda tonight. I know this is running long, but I gotta give you one more... We had a guy who was the world's most intelligent idiot. He was great in "book smarts", could read logic prints like nobody's business, but didn't have the first lick of sense. That was compounded by the fact you couldn't tell him anything. He didn't have a hearing problem - he had a listening problem that I think was caused by a short attention span. Anyway, the machine I mentioned above, the one that the Federal Reserve Bank used, had one big problem - paper dust. That was a problem with all our machines, it's just that money is made out of a really tough grade of paper, and paper dust from money is a pretty good abrasive. That dust gets into motors, and..... This guy, whom I'll call Bob, was working second shift at the Fed, and the stepper motor that drove one of the strappers had died. This particular motor had a high failure rate and none of the Feds could keep enough motors in stock. The first-shift guy who was in charge of the site had somehow managed to acquire six of these motors that our inventory geeks didn't know about. Officially he didn't have any. These motors were his ace in the hole. Anyhow, Bob was on second shift and had gotten a call that a strapper had died. Here's what you do: Remove the belt from the pulley. Four capscrews hold the motor in. Remove those and slide out the motor (which is about the size of your fist). Unplug the two wires from the motor, then remove the pulley (one setscrew). Take the new motor, put the pulley on it, put the motor in place, reinstall the four capscrews, plug the two wired back in, and put the belt back on the pulley. Total elapsed time: Five minutes, three if I did it. Keep in mind that these motors are really hard to come by. Bob had six available. First problem: Reassembly - he can't find the screws that had held the motor in. No problem, he'll just get four more from the parts bin. Now, he's done. But the strapper still doesn't work. Why not? Oh, the four screws from the parts bin are too long, and they've crushed the windings on the motor. He gets another motor. No strapper... Oh, darn, he forgot and used the same screws and has crushed the windings on this one, too. Oh well, there are still four motors left, and the first shift guy is really going to be P.O.ed over this.... Then three, then two, then one, then none. Now he has to call in and report to the boss that a strapper motor had died, he's managed to destroy all six of the spares the exact same way, and now one of this particular Federal Reserve Bank's six machines is still down, and will be until we can get another motor flown in. Guess who got a phone call and had to drive out to the airport to pick up the replacement motor? Let me rephrase that question: Guess was having fun in bed with his wife and had no better sense than to stop what he was doing and answer the phone and had to drive out to the airport to pick up the replacement motor? And then later embarrassed his boss by publicly telling him exactly what he'd been doing when the phone rang? Little inside joke here: Bob was famous for pulling these dumb stunts. But his bad reputation had splattered on another one of our tech guys, who had the misfortune of having the same name - first and last. But this other Bob was one of the company's two top tech support guys - those two were in international tech support. The other half of the joke - what would you expect a top tech support guy to look like? A short, skinny nerd with coke-bottle glasses and the pocket protector from hell, right? This guy was a Viet Nam vet, 6' 2", and was 240 pounds of solid beef. He looked like a Hell's Angel, complete with ponytail, and rode a Harley Hog everywhere he went. He also had an artificial leg (which creaked badly) from a motorcycle wreck, and was not the sort of guy to cross. He very badly wanted to meet Bob the Idiot, and Bob the Idiot most emphatically did not want to meet Biker/tech nerd Bob. Idiot Bob would pull one of his stunts, and Biker Bob would get teased about it. Whenever Biker Bob was P.O.ed, he'd slap his left thigh (which was fiberglass). When Idiot Bob pulled a stunt, you could hear Biker Bob walking around in the plant: CREAK , WHACK, CREAK, WHACK, CREAK, WHACK.....
While MS has turned into a virtually upgrade machine with new versions of software and operating systems coming out every few months and software lifecycles decreasing, it’s still the same old adage: the more things change, the more they stay the same! Witness some still active user groups in my town:
I’m retro in a lot of ways too (it’s cool to be retro!): I still have a 386 PC at home with Win3x, VB3, and an old version of Office; I still have a 486 with Win95, VB4, and Office 95. And I still use these machines! Why? I hate to throw something out just because it’s old (I’m a packrat!). Yes, these machine still work and are adequate for the tasks at hand. But mainly, I still enjoy using them! By adding some cheap RAM, these machines perform almost as well as the new ones. I’m not totally retro: I dumped the 286, the IBM PC Jr., and the 14K (or slower!) modems a long time ago. Okay, I still have an old dot-matrix printer (serial), and some dumb terminals lying around, but I use these mainly for testing. In fact, most of this old stuff is just for testing. I guess I could sell all this old junk, but I don’t think anybody would want to buy it. If so, the whole mess would net me maybe $100 – if I’m lucky! If you think I’m retro, you should see most of my customers: many have old clunky mainframes with VT100 or Wyse50 terminals or IBM3270 monitors. Most aren’t hooked up to the Internet, so access (if any) is through dial-up software with terminal emulation. Some have Internet connections but the end is still the same: access a secure web page to get at... a Telnet connection! Another government customer is still using Win3x (their contract hasn’t approved a 32bit OS yet). One customer still has Lotus123 (the DOS version), and he loves and swears by it. Do I resist change? No, I welcome it! Change is good. I am kind of slow to jump on the bandwagon of new technology – either hardware of software. It’s not because I don’t want to - it’s because I don’t have the time or money to invest in this new technology. But eventually Win2K, VB.Net, or "XP" will cross my path – intentionally or unavoidingly. I’m not worried. I’m ready for it! I’ve been using computers for almost 25 years, and I’m sure I’ll figure it out and adapt quickly. So will I use the new "DotNet" technologies? Maybe. After they have matured and been debugged and reworked, and have gained popularity and acceptance, I might jump on board. But in the meantime, I have better things to do than learn technology that “might” be popular in the future. Besides, I’m too busy learning already popular technologies, like ASP and Perl and Java and Flash. :^) P.S. Update: I just got a new machine with Win2K and love it! Did I have any problems adapting? No way! And VB6 screams on it! I did have to re-write some of my animation routines to slow them down – they ran so fast I couldn’t even see the graphics!
Click here for the brief story. Click here for some interesting (and hilarious) UNIVAC trivia.
This system is roughly 1/1000th the speed of the desktop system I just bought for 2000 times as much money making my $/Hz ratio 2 million times better than UNIVAC's. Also note that modern processors do a LOT more than UNIVAC's vacuum tubes so each MHz now can mean more than it did then.
These days computers are basically boxes full of circuit boards, cables, cabinets, power supplies, memory modules, disks, modems, and other peripherals whose sole purpose is shoveling data in and out of the tiny chip at the center of it all.
Chips contain specialized circuits that do things like add numbers
and store a value in a memory address. Commands stored in memory determine
which circuits are used and how. The computer feeds the instructions to the
chip to make it do its magic.
You can see these men at their best in a great scene in the movie Apollo Thirteen.
When a slightly dizzy Tom Hanks asks Mission Control to verify one of his calculations,
a row of engineers with thick glasses, short haircuts, and white shirts whip out their
slide rules and spring into action. Their slide rules were more accurrate than the expensive
and feeble calculators available the time. My father knew how to use a slide rule.
He showed me how to do some simple multiplication and take square roots once, but of course
I've forgotten how.
Back in the early days, there were no programmers, software engineers, user interface designers,
or Web designers. There were only electrical engineers. You couldn't get a degree in programming
(actually that's a relatively new innovation--even after my time), you could only get a degree in
electrical engineering. You not only had to understand how the hardware worked, you had to build it.
At times the hardware and software specialists had heated debates (pun intended) over
temperature issues. The software people claimed that the hardware started generating faults
when it got too warm. The hardware experts insisted the problem was buggy software.
Eventually it turned out that the programmers were right. When a semi-conductor gets hot enough,
it becomes a full-conductor and the computer doesn't work right.
That's why your computer has a fan.
If you have a reasonably new computer, the chip has a huge heat sink glued to it to keep it cool.
If your chip gets too warm, it won't work and may even suffer permanent damage.
These arguments also remind me of some of the battles I've been through where a developer or software vendor blamed
their bugs on the hardware, operating system, or another vendor's product.
Early memory systems were cumbersome affairs of wire woven into a rug holding tiny metal cylinders. The components
were so large you could easily see them with the naked eye.
Today's memory chips store millions of bits of information in the space of a postage
stamp using components so small you need an electron microscope to see them.
Long term storage was even stranger. Some systems used huge magnetic platters, kind
of like CDs only more than a foot in diameter. Others stored data on rotating drums.
Still others used paper tape, punched cards, and even stranger media. I remember one time, probably
in the 70's, when my father showed me a removable disk pack. It was a big plastic disk about
4 inches tall and 14 inches in diameter. Inside was a single magnetic platter similar to a modern
floppy disk only holding far less information.
All of these systems had one thing in common: they were huge.
If you could store more than a few kilobytes, you considered yourself lucky.
Amazingly, those early engineers managed to send rockets to the moon with these
systems. My father worked on a missle guidance system thath used rotating drum memory.
Space was so tight that at times they broke bytes into two pieces called nibbles
and stored a machine instruction in one nibble and a piece of data in the other!
I remember him telling me that at one test, a missle's gyroscope tumbled 180 degrees just before launch.
(You may know that gyroscopes tend to tumble in 90 degree increments if they tumble at all).
The missle executed a perfect flight, but in exactly the wrong direction. Instead of going south, it went north.
Fortunately they were holding the test in the middle of the Pacific Ocean so no one was hurt.
They never did find out what happened.
|
||||||||||||||||||||||||||||||||||||||||||||||
 |
Copyright © 1997-2010 Rocky Mountain Computer Consulting, Inc. All rights reserved. |  |
|
 |
Updated |  |
|