|GUI ScreenIO for Windows|
The output from most compilers is an object module.
The object module is, loosely speaking, your COBOL program rendered to machine instructions. As a rule, if you compile a program, the resulting output module has the same name, but with the extension .OBJ
Now: Suppose that you are building an application that consists of several hundred COBOL programs. When you compile 'em, you'll have several hundred object modules to deal with in addition to the source files.
This gets to be a pain.
Furthermore, when you link your executable modules, you need to list all of the subroutines it uses in your LINK statement. So, let's say that you have a main program A, that calls subroutines B and C, and that it uses GUI ScreenIO, so it also calls GS.
The hard way is to list the names of all of the object modules that need to be included in the executable module, like this:
link /out:a.exe a.obj b.obj c.obj gs.obj ...
Seems easy enough, right? But what if your application calls a couple of hundred subroutines? Or, what if you have a dozen different executables that all call different subroutines? Then what? Every one will need a different LINK statement, which gets to be a pain.
You could use a response file to list all of the object files needed, but you'd still need a different response file for each executable module.
There's a better way. It's time to look into object libraries...
An object library is simply a specially formatted file that contains a collection of object modules.
Object libraries are great because, first, they eliminate the clutter of a zillion .OBJ files on your disk, and second, because they make linking a breeze.
If you store all of your object files in an object library (say, my.lib), you don't need to mention them individually in your link statement. Instead, when the linker finds a call to other programs in your module, it will search for it in the object libraries you've listed.
Your new, simpler link statement will look something like this:
link /out:a.exe a.obj my.lib ...
This LINK statement says:
"Link my object module a.obj as an executable named a.exe, and search the library my.lib for any subroutines it uses."
Now, this might not look that much simpler, but my.lib could easily contain hundreds of object modules, so this same link statement will work for all of your executables. You only need to change the name of "a" to the module you want to link.
Of course, the other nice thing about storing your .obj files in an object library is that you can delete the .obj file once it's been merged into the library. Now you don't have all of those .obj files cluttering your disk, either!
|© 2000-2019 Norcom, all rights reserved|