Starting Up

The best kind of software is software that starts up as quickly as possible. But sometimes an instant startup isn’t possible. Your software might be linking to dozens of dynamically linked (or shared) libraries, which could take many seconds to load. Or it might need to scan a database or look up some data on the Web…or whatever. In this section I talk about ways you can minimize your startup time, as well as ways to make your startup as useable as possible. (Yes, usability even affects the starting of your application! You cannot escape!)

Minimizing Startup Time

Minimizing your startup time involves a fine line between keeping startup time as short as possible and not making the user wait for libraries to load periodically while using the program. The way most people minimize their startup time is by simply waiting until later into the program’s running to do certain tasks, such as loading dynamic or shared libraries.

But on the other hand, you don’t want to make your users sit and wait every time they try to do something while your program goes about its business, loading libraries, downloading data, and so on.

Your goal here should be to get the best of both worlds:

RULE

Try to keep the startup time within two seconds, and set other startup tasks to happen later on but without making the user wait at various times while using your program.

I would say that a pretty good limit for startup time is two seconds; anything beyond this is likely to frustrate the users. (And please don’t say I’m being overly picky here. How long do you want to wait to start up that wonderful IDE that you use for developing your software?) In the world of computers, two seconds isn’t bad. You can accomplish a lot in those 2000 milliseconds. You should be able to load plenty of libraries in that amount of time.

But you probably won’t be able to check for an Internet connection. You might be able to connect to a database and briefly verify some data. But maybe not. And what do you do if you can’t accomplish these tasks in two seconds? Then you don’t do them during startup.

I don’t like to pick on software programs in this book, but I will say that one particular web browser takes a very long time to load. (I won’t say which one, but it’s one of the “big two.”) If you are a programmer who worked on this particular browser, you might like to know that that is the single reason I do not use the browser. It’s true! Surely some of those tasks it’s doing at startup could wait until later, right?

Note

Although I’m raving about the importance of software that starts up quickly, I’d also like to point out that exceptions do exist. For example, a large-scale software system that runs on an enormous computer with many users might need rapid response time once the software is running. In such cases, you might see a need to let the software take as long as necessary to boot up. Use your best judgment, and base such judgment on the needs of the users.

Reading the Command-Line Arguments Even in a Windowing System

Yes, you’re using a windowing system. But you really do need to make sure your software reads command-line arguments. Sound crazy? No! Whether you’re using Linux or Windows or any of the others, if your program opens files, then it must read the command-line arguments.

The reason is that even on Windows you can launch a program from the DOS shell, specifying a filename. Try this from a DOS prompt on Windows:

 notepad abc.txt 

(You might want to substitute a real filename, but you don’t have to.) Notepad will try to open the file called abc.txt, and if the file doesn’t exist, Notepad will ask if it should create the file.

But don’t ask this question like Notepad does. Come on, that’s ridiculous. Here are some of possibilities that would result in the file not existing:

• You were in the wrong directory.

• You typed the filename wrong.

• You’re creating a new file.

As programmers with a great understanding of usability, you and I now know that one of these is going to be the most common situation, and therefore the program should make an assumption. Yes, creating a new file is the most common reason why the file doesn’t exist. Therefore, don’t ask, “Do you want to create a new file?” Just do it! Make the file. (And besides, you don’t have to actually save the file until the user saves it.)

Yes, on rare occasions you might be in the wrong directory or you might type the wrong filename. But these occur a lot less often than when you want to create a new file, and you can handle closing the program and trying again.

Back to the issue at hand: Notepad is smart; it reads the command-line arguments. Typically a command-line argument will be a filename. But not always; you might want to also accept command-line options.

This feature is useful, however, not only when running the program from the command line. In Windows, you can create a shortcut to the program on your desktop (or in any folder, or on the taskbar, or wherever) and include command-line arguments right in the shortcut.

Of course, when you’re dealing with shortcut icons, you don’t even need the program name; you can simply specify the document name, and Windows will open the correct program. But you can include command-line parameters if you wish.

But do users even know this? Some do; some don’t. But enough power users are out there that chances are good that many people are going to expect you to accept command-line parameters. When I run a program from the command line, I expect the program to accept a filename as a parameter (if the program is one that opens files).

Here then are some suggestions for dealing with command-line parameters to make your software more useable:

• If your program opens files, then accept a command-line parameter of a filename, and open the file when the program starts.

• If your program can have multiple files open simultaneously, then accept multiple filenames from the command line.

• Decide how to handle the situation of the user specifying a filename when that file is already open in another instance of your program. Do you simply activate that other instance, or do you start a new instance that also has that file open?

• Consider using wildcards; if the user opens *.cpp, then open all the files matching *.cpp in the working directory.

• Consider including some command-line options if you think the users will have a need for them. If you have different views in which you can display a file, then maybe the user can specify the view in a command-line parameter, such as -v fullscreen.

Note

The debate is still going on as to whether you should use -v or /v for your command-line options (that is, a hyphen or a slash). Most Windows programs use a slash, although a lot more are starting to use a hyphen. Unix programs almost always use a hyphen.

Regarding the item about the user choosing a filename while the file is already open in another instance, you will want to give this some serious thought. Should you just switch to the instance already running? Or would it make more sense to open the document again? A lot of text editors open a document again, but frankly, you can run into some serious problems here. I take on this issue in the next section, “Allowing Multiple Instances of Your Program (or Not).”

Allowing Multiple Instances of Your Program (or Not)

You’ve seen how some programs won’t let you run multiple instances. On Windows, I can think of dozens of programs that do this; Microsoft Word is one of the best examples.

Think very carefully about whether or not you want your program to allow multiple instances. On one hand, this can be handy. Microsoft Outlook, for example, lets you run multiple instances. You can then have one instance showing your Inbox and another instance showing your Calendar. This makes sense, since Outlook doesn’t let you open up two separate windows like Microsoft Word does. (However, Microsoft Word has an option where the documents can either all be in a single main window or they can occupy separate windows. When the documents are in separate windows, the screen looks like the windows are separate Word instances, but they’re not; only one instance of the WINWORD.EXE process is running.)

The developers of Outlook went to great lengths to make sure that you can run two or more instances of Outlook. For example, if you use one instance to send an e-mail message, and that window shows a message in the lower-right corner saying that Outlook is sending your e-mail, the other instances will also show this message. And then when you’ve finished, your Sent folder will update in all instances. Clearly there’s some interprocess communication of sorts going on here. (Showing you how to do such interprocess communication would be beyond the scope of this book; however, you can find plenty of information in the various SDK documentation.)

Different operating systems have different ways of allowing you to detect whether an application is already running. On Windows, you used to be able to check the hPrevInstance passed into your WinMain. But in the more recent versions (Windows 2000, XP, and so on), this parameter is always 0. The official way on Windows now is to create a named mutex (make sure it’s unique, like the name of your program followed by a bunch of numbers). If you get back an error that the mutex already exists, then you’ll know that somewhere out there on the same computer another instance of your program is running. That’s easy. Then you can just call FindWindow to locate the main window of the other instance and call ShowWindow. Then shut down, leaving the original instance running.

But what about a command-line argument? As I mentioned, Word allows only one instance. Suppose I’m running Word and I type this into the command prompt:

 winword c:\letter.doc 

If I open up my handy-dandy system spy tool called Process Explorer (available from SysInternals at http://www.sysinternals.com), I can see a second instance of Word start up. That’s cool; it’s doing what I just described. But then I see the second instance stop, and then the first instance loads the c:\letter.doc document. How did that happen? I talk about this in the next section, “Accepting Files and Opening Them While Your Program Is Running.”

Note

Since Windows 95, you have been able to launch a program based on a document. If I create a shortcut, I can point the “command” to a document such as c:\letter.doc. Now really, c:\letter.doc isn’t a command, but the Windows Shell system doesn’t care; it will locate the correct program based on the filename extension and run the program.

One major issue about running multiple instances is whether you want to allow users to have two instances of the program modifying the same file. Although Microsoft Word does not actually run multiple instances, if you do try to run another instance while specifying a command-line argument of a filename that is already open in Word, Word doesn’t try to open the file again. Instead, Word activates the window containing the document.

Most text editors do allow two separate instances of the program to run, each modifying the same file. This is dangerous for the user. I’ve allowed myself to open up one code file in multiple instances of my favorite text editor on Windows, and then I’ll forget that I have two open and go my merry way modifying the code in one of them. I’ll save that code, test, change it, save it, test some more, and so on. Then later I’ll accidentally switch to the other instance, type something in, save…and kablooey, all my earlier changes are lost. Fortunately, if the instance where I made all the changes is still running, I can go back and rescue my code. Otherwise, I’m toast. (And yes, I’m speaking from experience.)

For this reason, I usually encourage programmers to follow this rule:

RULE

Do not allow multiple instances of your program to open the same file if the users can make changes to the file.

This, of course, doesn’t include a read-only program such as a web browser, where you don’t use the software to save files, only open them.

Accepting Files and Opening Them While Your Program Is Running

Suppose you allow only one instance of your program, and the user types the name of your program followed by a filename, expecting your program to open. Then what? The answer is that the running instance should open the file.

If I have Microsoft Word open and I open the command prompt and type

 winword myfile.doc 

then the currently running instance of Microsoft Word will open the document. Really, however, I can do any of the following to see this behavior:

• Type winword myfile.doc.

• Type just type the document name without the program name: myfile.doc.

• Double-click the document in Windows Explorer (or a shortcut to the document).

All three of these options work the same way; however, Microsoft apparently used two different methods to make these work. If Word is already running and you type just the filename, myfile.doc, without the program name, or you double-click an icon for the file, the Windows Shell system initiates a DDE (Dynamic Data Exchange) conversation with Microsoft Word and tells Word to open the file. DDE is a method of interprocess communication that has existed since before Windows 95, all the way back to the 16-bit days of Windows.

If you type winword myfile.doc, on the other hand, a second instance of Word momentarily starts up. This instance then communicates with the existing instance, telling that instance to load the file. Then the new instance shuts down. For this process communication, Word uses COM (Common Object Model, formerly called Object Linking and Embedding, or OLE).

REAL WORLD SCENARIO: Don’t Open Two Drawers at Once (Severe Bodily Injury Could Result).

Now who in their right mind would design a huge object like a file cabinet that goes in every office on the planet and create it in such a way that if you use it wrong you could be seriously injured or killed! (For some reason, the word automobile just popped into my head. I’m not sure why. But back to our scheduled program….)

A file cabinet, by itself, seems rather benign. Unlike a car, you don’t actually get inside it and project yourself down an interstate at 70 miles per hour. But, if you fill the file cabinet with so many books and papers that it weighs hundreds of pounds, and then you open two drawers at once, it could become front-heavy and fall forward right onto you (or your unsuspecting help from the local temp agency).

For some time, these file cabinets just came with instructions, apparently (in some minds) absolving the manufacturers from all liability claims. But since then, I admit, they have designed better file cabinets. Most just have a contraption inside that prevents more than one drawer from being opened at once. I imagine some engineer won an award for that one (perhaps saving millions in lawsuits?).

But I can think of some other options; maybe somebody else did too. For one, a file cabinet could be bolted to the floor. (This, of course, has the added benefit that some seriously determined robbers couldn’t just haul off the entire file cabinet, waiting to pick the little lock in the comfort of their own living room. Don’t laugh. I’ve heard that automated teller machines used to have this problem.) Another option is to include a counterweight. Of course, this might make delivering the thing kind of difficult.

Regardless, we, as software engineers, can learn from this example. Don’t let your software suffer from bugs that are easy for the users to accidentally run into, with catastrophic results. Cover all your bases. For example, suppose a user happens to type a strange set of keystrokes that inadvertently causes your program to run a macro that in turn shuts down the program without saving the files. Wouldn’t your support people like to take that phone call?

The topics of DDE and COM/OLE are big enough to fill an entire book. Thus, I’m not going to give you the whole rundown on how to use these to add interprocess communication to your application. (Besides, you’re an advanced programmer; you don’t need step-by-step handholding.) Instead, I’ll point you in the right direction. If you want to implement DDE and COM/OLE, hop over to the MSDN website at

http://msdn.microsoft.com/default.asp

and type DDE or OLE or COM into the search box. I recommend that you find some of the technical articles, download the sample code, play with it, and then work it into your own application. (That’s the way I learned this stuff, after all.)