The Legacy of getch()

Many software engineers of my age (including me) started C programming using the Turbo C/C++ IDE. Most of us had no idea of computer usage in the school time and therefore no one really understood deeply what Turbo C/C++ (shortened as TC in what follows) was. It was just more or less equivalent to C programming. So we will go back in history and write our first C program in TC:

#include <stdio.h>
int main()
{
   printf("Hello World!\n");
   return 0;
}

When we run the program in TC the screen gets black (from the all blue TC background) just for a moment and we don't see the output of the program. The lab instructor / professor (or maybe Yashawant Kanetkar's Let Us C) tells us to modify the program as follows:

#include <stdio.h>
#include <conio.h>
int main()
{
   printf("Hello World!\n");
   getch();
   return 0;
}

And Wow! This time the program does give an output "Hello World!" nicely written on a black background. Press Enter and we are back to the Blue Screen of TC (not Death).

And thus we meet the beast getch() and admire its purpose of holding the screen to show the program output. No further use is made of this function in our entire software career. From here on there are two paths people follow:

1. People learn UNIX/Linux.
They are badly hurt by the absence of getch() and finally realize that getch() is not really an essential part of C programming. In fact its not even part of the standard C library. A reasonable job could equally have been done by the the getchar() function provided by standard C library.

In fact UNIX users actually learn much more. They realize that a C program could be written using any text editor and it needs to be compiled using the "cc" command, following which an executable "a.out" is generated. This executable can then be run on the command prompt and then there is no need to hold the screen to see the output. The screen just displays the program output and prints the command prompt again.

Some of the UNIX users go back to TC world and repeat the same experiment now with the "tcc.exe" command (Turbo C command line Compiler) and understand that TC is actually an IDE which manages the job of creating/compiling/running programs in one place.

2. Or they don't.
These kind of people remember the getch() for their life and use it for any test program in their entire software career and we are then stuck with the legacy of getch().

Let us now ponder why this legacy is being carried to this day (when Microsoft Visual Studio , to be referred as VC in what follows, has completely wiped out the Borland TC). Also is it really worthwhile to carry on with getch()?

Why does getch() persist?
Software engineers who are exclusively trained on Windows machines almost never get the hang of command line. For them GUI is everything and they just cannot do without GUI. But strangely when they need to test any C feature (to clear some confusion) they will write a console based C program. Mind you they almost never write an MFC app to test a C feature (which could be done in a minute or two in VC). When you run a console based program in VC it opens a console window, prints the output on console and the console window is destroyed.

To hold the console window we again ask help from our old friend getch() and because of Microsoft's extreme obsession with backward compatibility VC retains the getch() function, thereby doing our job of seeing program output.

The most ironical thing about the whole episode is that most users are unaware that both TC and VC provide a keyboard shortcut to show the contents of the output window so that they see the program output or that a simple getchar() from C library could also perform the job. Why they are unable to comprehend this is completely beyond my comprehension. I believe they never really came out of the TC paradigm of programming.

This is not to belittle the quality of TC as a software. Before VC it was the only reliable software available on Windows/DOS systems to develop/debug C/C++ programs. It had a nice user interface (apart from that blue background which was not that eye-soothing to some of my friends). In fact TC also had a TurboVision library (TV.LIB) using which you could make a program with menus and buttons similar to TC itself.

But somehow TC sent a wrong message to most of the not so talented programmers that "TC == C programming" and not that "TC == C programming IDE." This is definitely the case in India as is evident from many C programming books written by Indian authors. In fact one of our colleagues used to keep a copy of TC only to clarify some C language confusion. TC was handy for him compared to VC.

Do we need to carry on the legacy?
No!! Absolutely not! Run away from those who are still stuck in the TC era. They will never have a clear understanding of what computer programming is all about. Many TC users don't even have the faintest idea of the steps involved in generating an executable from a C source code because TC makes it all transparent.

In contrast anyone who is working with UNIX systems is sure to face the all too well known problem related with <math.h>. If one writes a C program which uses any function from <math.h>, say cos(), and tries to compile the program using "cc f.c" command, he gets an "unresolved external" error. He is then forced to do some research and come up with "cc f.c -lm" which actually works. One then realizes concepts of compiling and linking and sometime later the "cc -v" command gives it all: preprocessing, compiling, assembling and linking.

For a beginner TC works greats, but to be a software developer it is very essential to come out of that transparent mode. One must know what goes behind the scenes and work with some command line compiler tools like "cc" (nowadays "gcc") (TC also provides "tcc.exe").