April 29, 2003
By Karen Kenworthy
IN THIS ISSUE
I really enjoyed our last get-together! Talking about the ways early computers, and early computer users, communicated brought back a flood of fond memories.
And, judging from my e-mail, a lot of you enjoyed the trip down memory lane too. I never dreamed so many of you spent your youth punching holes in punched cards and paper tape, or pecking out commands on a mechanical teletype keyboard.
Like me, you must have begun working with computers while still in diapers. And you've no doubt benefited from the well-known computer anti- aging effect. The longer you work with these amazing devices, the younger you get. :)
Talking To Computers II
When last we met, we saw lots of ways people communicated with computers over the years. But we didn't see what early computer users said. What did those ancient messages mean? What did they look like?
The first question is easy to answer. Humans have always given computers orders -- telling them what to do. Print this file. Erase that tape. Defrag a disk. Run this program. Start. Pause. Resume. Stop. You name it. If a computer can do it, some human, somewhere is ordering it to do so.
Before I answer the second question, you need to know one thing about early computers: They were slow.
And I mean slow; really, really slow. Today we expect a computer to produce instant results. If a task takes more than a few seconds we worry, afraid our computer has died. But in the early days of computing, even simple tasks like sorting data could take minutes, even hours. Complex jobs like computing a payroll could take hours, or even a whole day of a computer's valuable time.
Such long time spans make dialogs between computer and human impractical. Imagine telling a computer to prepare an inventory report. First, the computer asks how the report should be sorted -- by part number, location, etc. Then, two hours later, after the sort is done, the computer asks how many copies of the report should be printed. Finally, after four more hours, your computer wants to know if it should save, or purge, the temporary files created when preparing the report.
I don't know about you. But waiting hours to answer simple questions from a room-sized computer isn't my idea of a good time. Or a productive use of highly-trained, intelligent, extremely likeable, and good-looking personnel, either. :)
The solution is something that today we call a "command line." It's remarkably simple. Instead of waiting for a computer to ask each question, the user anticipates the questions and provides the answers all at once.
For example, when ordering a computer to print two copies of an inventory report, sorting by part number, purging the temporary files when done, a computer operator might have entered this command line at the computer's teletype keyboard:
PRTINV COPIES=2 SORT=PARTNUM PURGE
The beginning of each command line, in this case the word "PRTINV", is the name of the program to be run. The rest of the line depends on the program. But in almost all cases, it contains information needed by that program, answering in advance questions it would otherwise ask.
Command Lines Today
Now, you might think command lines are an historical curiosity. After all, today we have mice, icons, on-screen menus, and lots of other cool, high- speed ways to convey our wishes. Modern computers are much faster, too, able to complete tasks almost as fast as we can request them.
But command lines are just as common today as they were in the days of vacuum tubes circuits and magnetic core memories. Behind the scenes, command lines launch all Windows programs, and often pass additional information to them too.
Consider what happens when we double-click the on-screen icon of a text file. Windows first searches its Registry, finding which program is "associated" with text files. In most cases, that's a familiar Windows program called Notepad.
Windows then consults its Registry again, to see what type of command line the Notepad program expects. As it happens, Notepad command lines are simple: first the full name of the Notepad program, followed by the name of the text file to be opened.
Next, Windows builds the appropriate command line. For example, if Notepad resides in C:\Windows\System32, and the text file to be opened is C:\Readme.txt, the command line would look like this:
C:\Windows\System32\Notepad.exe C:\Readme.txt
Finally, Windows processes this command line, launching Notepad and passing the newly created command line to the program.
Double-clicking an on-screen shortcut icon runs a command line too. This time the shortcut isn't created on-the-fly by Windows. Instead, it's stored in the shortcut itself.
You can see a shortcut's command line by clicking the shortcut's icon with your right mouse button. Next, select "Properties" from the context menu that appears. When the Properties dialog is displayed, click its "Shortcut" tab. Among the information displayed, look for a bit of text called "Target" or "Command Line".
Think selecting programs from Windows' Start menu avoids command lines? Nope. The entries on the Start menu are just shortcuts stored in Windows' Start Menu folder. Making a selection from the Start menu causes the corresponding shortcut to be processed, executing the command line it contains.
Even when one Windows program launches another, it does so by preparing a command line. In fact, it's impossible to launch a Windows program without a command line becoming involved at one point or another. Without command lines, Windows (and any other personal computer operating system) would just be an expensive screensaver.
Command Line Detective
Does this mean the world of icons and mouse clicks is an illusion? No, it's real enough. Most Windows programs rely on these modern methods to obtain information. But understanding command lines can come in handy.
Several programs, such as Windows' Task Scheduler, and my Show Stopper, Countdown Timer II and Time Cop Power Tools, allow you to run other programs, by specifying the appropriate command line.
You can also store command lines in a "DOS Batch File", a text file whose name ends in ".BAT". Later, double-clicking this file's icon will cause each command to be automatically executed, one after the other.
So how do you discover the correct command line for each program? The answer is simple. You become a Command Line Detective. Here are a few tips that help you ferret out this often obscure information ...
Read your documentation. I hesitate to recommend things I haven't tried myself. But I have it on good authority that some programs come with extensive documentation. Sometimes those documents describe the available command line options.
Search the web. Microsoft's web site, http://www.microsoft.com, is a good source for information about Windows components and the command lines that can be used to launch them. Manufacturer's web sites, and search engines such as http://www.google.com, can be used to locate information about other vendors' programs. Try searching for the program's name, plus the words "command line" or "parameters".
Search Windows' Registry. You'll find several command line templates in the Registry. Your best bet is to search the HKEY_CLASSES_ROOT section for the name of the program (with the .exe filename extension). Windows' RegEdit program can do this job. Or you can use my Registry Ripper Power Tool. Just be sure not to ask either program to change or remove the entries it finds. :)
Examine Shortcuts. As we saw a moment ago, on-screen shortcuts contain command lines. Check a few, and see what command lines they contain.
Ask the program. Many programs will reveal their command line syntax when asked. Start by running Windows' "MS-DOS Prompt" or "Command Line" program. When the program starts, enter the full pathname of the program you want to contact, followed by " /?" (without the quotation marks).
For example, to ask Windows' Defrag.exe program how its command line should look, enter this:
C:\Windows\System32\Defrag.exe /?
Now you're a command line expert. :)
If you'd like to learn more about any of my Power Tools programs, visit the Power Tools home page at:
https://www.karenware.com/powertools
Or visit the home pages of any of the individual programs (such as Registry Ripper, Countdown Timer II and Time Cop) at their home pages listed at the end of this message.
As always, my programs are free (for personal use). Programmer-types can download the programs' free Visual Basic source code too.
Or if you prefer, get the latest version of every Power Tool on CD. The disc also includes three bonus Power Tools, not available anywhere else. You'll also find every back issue of my newsletter, and a few articles, in the CD's library. It even includes a special license that lets you use your Power Tools at work.
Best of all, buying a CD is the easiest way to support the web site and this newsletter. To find out more about the CD, visit:
https://www.karenware.com/licenseme
Until we meet again, don't grow any older. And if you see me on the 'net, or hunched over my computer keyboard, be sure to wave and say "Hi!"
More than 6000 downloads monthly
Received $184.68 this month* — Thanks!
License for Work
A license is required to use any or all of these tools for your work. You only need one per lifetime. If you make money with Karen's software, read her license agreement.
Power Tools Newsletter
- What is Karen's QR Code Talker?
- What is a QR code?
- What is a Code Talker?
24836 Verified Subscribers
Subscribe to receive new issues of the newsletter about Karen and her free Power Tools.
Click here to SubscribeNovember Revenue* $184.68
*Licenses + Donations - PayPal Fees
Oct $211 Sep $166 Aug $173 Jul $225 Jun $324 May $200 Apr $700 Mar $273 Feb $405 Jan $56 (2023) Dec $349 Nov $546 Oct $253 Sep $232 Aug $189 Jul $379 Jun $188 May $484 Apr $212 Mar $519 Feb $89 Jan $462 (2022) Dec $1088 Nov $151 Oct $133 USD — Thanks again!