Writing Software – Part 2

As a teenager I studied a little bit of the Logo programming language, then some Pascal and later made a failed attempt to study C++ from a really bad book, which insisted that I have to know how numbers are represented in bits inside the computer first. Most of the time I played computer games and explored (as much as it was possible before the Internet) the operating system and the computer hardware. I even worked as a computer technician for a little while.

After that I programmed for a while in the RPG programming language for the IBM AS/400 computer. That was actually my first real programming experience. RPG is like database-oriented assembly language and along with the green screens of the AS/400 terminal you can imagine that this combo offers little excitement. However, thanks to my brother, who was also my boss, I learned important rules like Don’t Repeat Yourself (DRY) and many other things.

Then I went on to study math and computer science. I enjoyed investing time in doing C and C++ home assignments, constantly trying to improve my code. After RPG, C++ seemed like a much nicer language to mess around with (also, I could do it at home). By the end of second year I was after OS course and with some OO knowledge, which I thought would be enough for me to look for a job (also I was in need of an income and it was before the bubble burst).

And so came my first C++ job. I worked for KLA-Tencor programming for Windows. At first I was amazed to see how little my knowledge of the standard C and C++ libraries had to do with the job. The Windows API contains so many functions, not to mention MFC and COM. Naturally, I had a trainer assigned to me, who was truly a guru when it came to Windows Internals. I learned a lot form him, but only a few months later, when he left, I was left to cope with Windows entirely by myself.

Programming for Windows is… it’s many things. Most of all it can be very confusing, especially with the plethora of macros and big structures that have to be transferred to functions with a lot of arguments. Looking for CreateProcess() in Google brings up two links: The first is Microsoft’s MSDN documentation for CreateProcess(), and the other is titled “Calling CreateProcess() the easy way”. I think that says a lot.

You really have to work closely with the MSDN reference when you program for Windows. One of the problems, however, is that first you have to know what the Windows API lets you do and only then you can start looking for it. Even then, it doesn’t mean that you’ll find the best and most correct way to do something. The good thing is that there are many resources online to help with Windows programming, so unless you’re looking for something rare, you’ll find your way. In that sense Windows programming requires you to be resourceful. It requires you to know how to read MSDN entries and it requires you to know how to find what you’re looking for.

With Microsoft constantly inventing new APIs while keeping the old ones, programming for Windows is a race between Microsoft and the programmers trying to keep up. A good Windows programmer is usually one that follows Microsoft’s publications like MSDN blogs, MSDN magazine and so on. The fact that MSDN blogs like Raymond Chen’s The Old New Thing have become so popular shows how much it’s needed to have people answer questions regarding Windows APIs.

Next time I think I’ll talk a little more about Windows programming (maybe a mention of .NET) and say what I know so far about Linux programming.

UPDATE: Here’s why Windows programming can be confusing – check out this latest post from Raymond Chen about “Waiting until the dialog box is displayed before doing something”. After my few years of Windows programming experience, I wouldn’t have gotten it right myself.