Once you've created STRLIB.DLL and STRPROG.EXE, you're ready to run STRPROG. Before you do so, be sure that STRLIB.DLL is in the current directory or a directory that is listed in the PATH string of the MS-DOS environment. Windows must be able to load STRLIB.DLL when you execute STRPROG. If Windows can't find STRLIB.DLL, it will display a message box asking you to put the STRLIB.DLL disk in drive A.
When you execute STRPROG.EXE, Windows performs fixups to functions in external library modules. Many of these functions are in the normal KERNEL, USER, and GDI library modules. But Windows also sees that the program calls three functions from STRLIB, so Windows loads the STRLIB.DLL file into memory, creates reload thunks for the three functions, and calls STRLIB's initialization routine. The far calls within STRPROG to these three functions are dynamically linked with the reload thunks that branch to functions in STRLIB. You can then use STRPROG to add and delete strings from STRLIB's internal table. STRPROG's client area shows the strings currently in the table.
The calls from STRPROG to the AddString, DeleteString, and GetStrings functions in STRLIB are very efficient and have almost no overhead except for the reload thunk. In fact, the link between STRPROG and STRLIB is as efficient as if the three functions in STRLIB were simply in another moveable code segment in STRPROG. So what? you say. Why do I have to make this a dynamic link library? Can't I include these three routines in STRPROG.EXE?
Well, you could. In one sense, STRLIB is nothing more than an extension of STRPROG. However, you may be interested to see what happens when you execute a second instance of STRPROG. Because only one instance of STRLIB is loaded for both instances of the program, and because STRLIB uses its own local heap to store the character strings, all instances of STRPROG essentially share this data. (The EnumCallBack function in STRPROG serves to notify all STRPROG's instances that the contents of STRLIB's data segments have changed. EnumWindows causes Windows to call EnumCallBack with handles to all parent windows. EnumCallBack then checks to see if the class name of each window equals ”StrProg“—if it does, the function sends the window a privately defined WM_DATACHANGE message.) And you can easily imagine an enhanced version of STRLIB managing a database that is shared by several instances of the same program or by single instances of different programs.