The Windows Command Line and JP Software - A Brief History

I was writing a new blog entry about the command dialogs in Take Command v13, when it occurred to me that most readers wouldn’t know the history of our previous command line and GUI products, and how we decided on the current UI.

In the late 1980’s, I was writing BIOSes and networking software for DOS. I had written a number of utilities to make development simpler, and I eventually combined them into the predecessor to 4DOS (a command shell for DOS). Microsoft had made it possible in DOS 2.0 to replace the command processor (COMMAND.COM), though it wasn’t until DOS 3.0 that it became practical. JP Software eventually released the first commercial version of 4DOS in 1989. This was followed by 4OS2 (a replacement for CMD in OS/2), and 4NT (a replacement for CMD in NT 3.1).

In the early 90’s, both Microsoft and IBM were making noises about eliminating the command line in the next version of OS/2 / Windows NT. I had a number of users pressuring me to do a GUI version of the command line, so they wouldn’t be forced to switch to a point-and-click GUI. This turned into the first version of Take Command. It looked just like the command line version, but had a minimal GUI wrapper (with a menu, toolbar, and status bar). Take Command/16 (for Windows 3.x) was followed by Take Command/OS2 and Take Command/32 (for Windows NT 3.x). Functionally, the command line versions (4DOS, 4NT, 4OS2) and the GUI versions were basically identical. The command line versions outsold Take Command by about 2-1 in the USA and Germany, and Take Command outsold the command line versions by 2-1 in the rest of the world. (I still haven’t figured that one out!)

The problem with the GUI versions was when you wanted to run a command line app. Nobody wanted to have a character-mode window pop up, run the program, and disappear. The first approach to solve this was dubbed “Caveman”, and worked by starting the character-mode window hidden, running the app, reading the contents of the hidden window, and displaying the output on the GUI window. Keyboard input was intercepted in the GUI window and redirected to the hidden window. This mostly worked, though there were various problems with apps that buffered their output or which wrote randomly to various parts of the display. (There was even one well-known command line application that would write its output to the beginning of the line, then the end of the line, and then insert the middle.)

By this time, we were being squeezed on both ends. Command line users wanted a better command line UI, and Take Command users wanted better command line functionality. The first attempt at addressing the better command line UI was called TCI (Tabbed Console Interface). TCI looked like Take Command but behaved like 4NT. TCI had a menu and toolbar, but most importantly it had tabbed windows that ran Windows console applications (4NT, CMD, etc.). It used a (much updated) version of Caveman (which was a lot easier with 32-bit Windows than 16-bit Windows — no VxD required!), and could run almost all command line apps. It wasn’t especially pretty, but it did the job. (TCI was roughly comparable to Console2, an open source tabbed console windows application that has been in beta for several years, though TCI used radically different methods for reading & displaying the hidden console window contents than Console2 uses.)

So at this point we had 4NT, TCI, and Take Command/32 (Windows 3.x and OS/2 having expired, and 4DOS barely alive on life support). There was considerable overlap, considerable extra development effort, and considerable end-user confusion. It was time to rethink and retool the command line paradigm.