Re: Static Libraries and Assembly Language

My experience with asm is from about 14 yrs ago, and was not extensive
even then. worse yet, I haven't even been involved with computers, let
alone programming in ANY language in that time. So I'm going to enter
this thread, as a nearly complete rookie, as a way to clear up my own
thinking on such matters as static and dymanic libs so, all of you more
knowledgable and experienced readers ( and that includes both you Betov
and you Randy) please feel free to jump in and correct me if I'm
totally off the wall in what I have say.
And since Betov is the first to extensively deliniate his stance on the
issue, I'll start there:

Betov wrote:

Well, ... If so, my points, now... :)

Historically, Static Libs had two concerns:

1) Compilations Times.

In the old days, the usage of pre-compiled things
were significantly reducing the time. This point is,
nowadays, completely dead, given the speeds of the
actual Processors and Assemblers.
I don't that that at any time, whether historically or currently, the
PURPOSE of libs was to reduce compilation time. The material contained
within a lib STILL has to be compiled at some time whether at .exe
compile time or at .lib creation time. Doesn't matter. That code still
had to be compiled. (or assembled, if you prefer.) The only way that
compilation time was of CONCERN was secondarily, i.e. of course you'd
want that code to be as efficient and as optimized as possible. If at
some point you decided to chang that particularly .lib, and you hadn't
yet compiled the final .exe, you could just plug in the changed .lib,
whithout changing the main source file, which would tend to reduce
final assembly or compilation time. But that was not it's main purpose
then or now.

Another, purpose (historically and well as currently) was program
modularity. It's certainly easier to write a small, single purpose
routine and provide a well defined interface to that routine than it is
to code one huge, monolithic application. And, after all, isn'tthat
just what asm is all about? Arn't you just just calling even smaller,
well defined routines using asm language opcodes? And if you're chasing
down a bug it would certainly be easier to do if you could remove
already proven chunks of code from your search area. Any code that's
put into a .lib has (hopefully) already been thoroughly debugged so you
don't need to waste time searching for this nefarious critter there.

2) Code Re-use.

This is _the_ actual point.
I agree that this is probably the MAIN purpose of (static).libs

So, what we are talking about, here, is not about knowing
if the old Static Libs practice is interresting or not,
but to see what _Code Reuse_ Methods are good, and "good
for what", and "depending on what".
Good for not having to reinvent the wheel, of course.
Basically, calling for a Lib (Static or Dynamic) is Black-
Box Programming. Of interrest when calling for the OS Functions,
there usage, in Assembly should decrease with the importance
of the called materials. Take, as an example, what Master Pdf
did, in the Satic Library he designed for his HLL, in the "Math"
or in the "Chars" Folders... You will see there, innoumerous
functions, usually one page or two long, that, in Assembly,
would take one or two instructions. That is, an extreeme
case of absurd Black-Box programming, doing nothing but
hidding Assembly entirely. In such cases, there is a choice
to be done in between the HLL, and the Assembler road. Here,
clearly, the usage of the Static Library, is utterly incompatible
with any form of Assembly.
Incompatible? How is that inclmpatible? Aren't you hooking into the
'black box' of the OS or hardware of the machine itself? Does not asm
language itself supply mothods for doing this? So why then does making
use of other methods supplied by asm (such as calling a .lib function)
become, suddenly INcompatible?
At the other end of the picture, i have been given the example
of the "zip" Static Library, that seems to be provided without
Sources and without (not sure, at all) a DLL choice (is this
true?).
No, its not. Every Zip API I've ever seen comes with a dll. at least on
DOS or WinDOS. after all, DLLs themselves are a MS defined/implemented
format. But that's not to say I've seen/know about about ALL
distributions of ZIP. As I said, I'm prety new to this stuff.
If true, in such a case, the usage of Static Lib would
be accurate... as long as there would be no other choice...
and as long as nobody is going to rewrite all of that stuff.
Whose responsability, if the DLL version does really not exist?
Well... not mine, for sure... :))
No, It's not your fault.
Now, back to the real problem of Code Re-use... Depending on
the size of the Routines, they can be given in a Librarian
Tool (like the one of RosAsm), for the small Snippets. This
method has evident and huge advantages:

1) You can customize the selected Routine to your exact needs.
Well, if you created the code in the first place then you have the
access to the source and and you can message it and use however you
want. If someone else created the code, then you have no right to use
and/or change that code unless the give you that right...in which case
they probably gave you that source code as well. So you can use the
original source code in your app if you so desire. So what's the
problem.
2) You have it inside your Source. So, no Black-Box, here.

3) In case of error, the Source Level Debugger can point it
out, in the Source.
4) The Method is faster (just a mouse selection, and a [Ctrl]
[V]), simpler, and more secure than the other ones.
How is that simpler that just calling the routine you want? And how
"more secure"? You mean more secure from code piracy? When anyone
could look at your source file and see just how that routine is
implemented? Or do you mean more secure from your (mouse selection and
a [Ctrl] [V]) missing the last character on the last lin_? Or the
complete last line? Or the fuction that your code calls which never got
pulled in at all?
Still considering the sizes and the types of usage, there also
are the cases of "Modules". For this also, there are better
methods than Static Linking, with most of the same advantages
as above ("Include" thingies...).

Then, there are the DLLs. I suspect that some guys could wrongly
believe that the DLLs calls would 'consume' something... like
"calling time", or something like this, which is perfectly wrong.
There is no real difference in between calling a Function in a
DLL or inside the Binary. Just indirect, instead of direct... :
Nothing.
I personally think there is a BIG difference between them. You've got
control of whether you use a static lib function or not. If you don't
want to use it then don't. If you want to change it then change it. But
a DLL? You must use it if you're programming for Windows. And you
can't change it because you don't have the source for it and you
wouldn't dare change it if you DID have the source for it because any
change to it would affect so much else that also uses it. (like the
OS)

Considering all of these solutions, why on earth would one want
to pratice Black-Box Programming, in Assembly, while still
bloating the Binaries? What for?
I don't understand how this will "bloat the Binaries". The compiled (or
assembled, if you prefer) code gets pulled into the final assembled
..exe whether as preassembled external module or as redundantly
duplicated source code lines. But, if you don't want make use of the
functionality of static libs that is certainly you're right. You don't
have to.

Sorry for the long winded reply. Once again, if I'm mistaken anywhere
in this post please correct me. I'm willing to listen to any reasonable
contrary opinion or corrections hopefully learn something in the
bargain.

-Doug

.

Relevant Pages

  • Re: Cloning FASLD
    ... If you clone it in your BSP and build an OS design with that BSP, ... The lib is linked to create a dll - this is done by using that new ... why fasld_lib is a LIBRARY and not a DLL? ... The originale FASLD driver generates a fasld_lib.lib file not a ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Forwarding DLL
    ... Note that I use the same header file in my lib/dll/app project as in the lib. ... in particular not the exports. ... lib when I make the dll. ... But, during compilation of the dll, the class should be exported because FORWARDDLL_API is not an empty macro anymore, is __declspec. ...
    (microsoft.public.vc.language)
  • Re: Cloning FASLD
    ... If I include in my os design the build of my cloned FASLD and remove the ... The lib is linked to create a dll - this is done by using that new ... why fasld_lib is a LIBRARY and not a DLL? ... The originale FASLD driver generates a fasld_lib.lib file not a DLL ...
    (microsoft.public.windowsce.platbuilder)
  • Re: #pragma lib buggers everything up
    ... > derive the client application's classes from the classes in the lib, ... to link the final executable (be it an EXE or a DLL) and it turns out ... there's no problem discarding unused functions at this ... and derived class is very fragile - it depends on a particular compiler, ...
    (microsoft.public.vc.language)
  • [Problem] Porting IDC MMX _asm inline code to amd64
    ... I am trying porting IJL like lib to amd64 with WDK 6000 environment. ... separating the _asm inline code to .asm file. ... But the crash occur when myfunction try to do "movq mm0". ... myfunction PROC ...
    (microsoft.public.development.device.drivers)
Loading