Procedure Libraries

[BagelBob]

This is a NASM/DOS newbie question about PROCEDURES (NOT
macros). It seems to me that the problem with creating
utility procedures to be placed in libraries and utilized
in various mainline programs, is that it would appear to be
impossible to have any transparancy. Every time you utilize
a label (offset) in a proc, it would appear that you have to
define it exactly the same in the main program. So every time you write a
proc (with a bunch of EXTERN label difinitions)and put it in an assebled library you seem to create
the necessity of defining a bunch of GLOBAL labels in the
main program (indeed, for all the labels, even in procedures
in the library you don't use). And, every time you define
such a label in a library proc, you remove that label from
the universe of possible label names available to the main
program. Now, through the use of COMMON and EQUIVLENCE, this "problem" does not exist in higher level languages -
which means it must have a solution in assembler. What am
I missing? How do I "pass" a label transparently to a proc?

 

[AmkG]

You DON'T need to define variables for each and every procedure in a library; unless you use the routine, it won't be linked in and it won't look for external variables.

Also, you can define such variables in the library itself. Just make another source file and place any variables there. Or better yet, define it with the proc which uses it the most. In fact, if only one proc or module/file uses a particular variable, you can make it a "LOCAL" label, local only to that module/file. After all, transparency says "you don't need to know everything" so your main module doesn't really need to EXTRN those variables, only the library modules. ANYWAY it allows a good programmer to be able to twiddle a bit with the library's operation.

Also, if you've ever had a library manager list the labels in an HLL's library, you'll notice that it gives names like @@EX_!3 or something. A good way to "hide" any variable you need to share among different modules is to give it such weird names, which most programmers won't use anyway.

A good programmer can then be able to access variables in a library, while a newbie won't be able to hurt anything.

In fact HLL Libraries use just these techniques, and they "work" quite well without the problems you cited. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."