Re: HLA stdlib v2.3 is now available

On Oct 3, 12:36 pm, Evenbit <nbaker2...@xxxxxxxxxxx> wrote:

All of the instructional material that *I* have been reading give me
the impression that the issue is not a HLL vs. ASM one

Certainly this has little to do with languages.
You can statically link in code in most languages (assembly or HLL)
and, likewise, you can also link in DLLs (shared objects) in most
languages. Only a few (typically brain-dead) languages only allow
dynamic linking. Visual Basic and RosAsm come to mind. No doubt there
are others, but they are in the minority.

but instead is
a Modern OS vs. Obsolete OS issue.

This is independent of OS, other than the fact that the OS must
provide run-time linking facilities of some sort.

Programmers are encouraged to use
dynamic linking on modern operating systems to save on resources. The
fact that static linking still enjoys wide-spread use serves to
demonstrate that this older method still holds value within the
programming community.

Static and dynamic linking serve two different purposes. Dynamic
linking works great if you have several applications (in particular,
concurrently running applications) that share a common code base. You
need only one copy of the code sitting in memory at one time, being
shared by all the applications that are (concurrently) using it.

One other benefit of dynamic linking is that you have only one copy of
the library sitting on the disk, rather than having separate copies
merged into each executable. However, as we're getting to the point
where terabyte disks cost less than the 143K floppy disk I had on my
Apple II computer, saving a few tens of kilobytes (or even megabytes)
on the disk is hardly an issue.

Dynamic linking, however, provides absolutely no benefit if only one
application uses the library (indeed, it becomes wasteful at that
point). Let's take the HLA standard library as an example. I could put
the whole thing into a DLL and then *any* assembler (RosAsm included)
could link against it. But look at what happens when such an
application loads -- it loads the *entire* library into memory. Talk
about wasting space! With static linking you only load the actual
functions you use -- with dynamic linking you get *everything* in the
DLL. This can pay off if several applications in memory are all using
the DLL at the same time (you get to amortize the cost of the DLL over
all the apps), but how many assembly apps does the average person run
at one time?

Now you could argue that you could break up the HLA stdlib into a set
of DLLs. But the bottom line is that the smallest you can make a DLL
is 4K (actually, it takes more space than this because of the indirect
pointers needed to do the linkage). Breaking the library down into
smaller pieces than 4K winds up wasting a lot of space, packing as
many functions into each 4K module winds up wasting space, again,
because it's unlikely you're calling all the functions in that module.

Then, of course, there is the application packaging issue. If you use
a DLL, the user needs to install that DLL in an appropriate location.
And God help the poor person that has one app that uses an older
version of the DLL and a new app that uses a later version of the DLL
(imagine an HLA stdlib v1.x DLL and an HLA stdlib v2.x DLL, for
example). Things start breaking real fast when this happens (this is
known as "DLL Hell"). Most of the time, it's a lot better to
statically link in all the library code you use so your application is
completely self-contained. For the cost of a few extra bytes on the
disk drive, this elimiates a large number of headaches.

DLLs are great for things like glibc, where dozens of apps can share a
single copy in memory and those apps usually get upgraded at the same
time the library does. They have not, however, been the panacea they
promised to be when they were popularized. Static linking is still the
most popular way to link library modules (especially user-written
library code, and library code not provided by the OS vendor) because
there are far less headaches associated with it.

And, lastly, don't forget the efficiency concerns. Dynamic linking
requires indirect jumps and calls (and often jumps to indirect jumps).
This is less efficient, and consumes a bit more space, than a direct
call (as you typically get with static linking).
hLater,
Randy Hyde



.

Relevant Pages

  • Re: Dynamic DLL Loading or Static ?
    ... A DLL is dynamic linked always: ... terms are load-time dynamic linking and run-time dynamic linking. ... > initialize this DLL and I'm loading it dynamically. ... This is the default value for WinXP SP1 and WinSrv03. ...
    (borland.public.delphi.nativeapi)
  • Re: c code reusability
    ... disk space and computer memory are relatively cheap. ... of dynamic linking, ... The average size of a loaded DLL is 558 KB. ...
    (comp.lang.c)
  • Re: Problem with reading an int with operator>>
    ... Yes, but as always with dynamic linking, this is no real advantage if I have to ship the DLL's myself. ... this advantage if I could keep all my Standard Library in the headers where it could be easily updated. ... Is it just a matter of removing all the "#ifdef _DLL" sections? ... an impediment to Microsoft updating the standard library when improvements have been found. ...
    (microsoft.public.vc.stl)
  • Re: crossing dll boundary ...
    ... variables in dll Main during the compile time. ... Dynamic linking if calling LoadLibrary/GetProcAddress instead. ... The member functions are exported functions in DllA. ...
    (microsoft.public.vc.mfc)
  • Re: When were scanf_s functions introduced?
    ... one that is a "web install" (checks dependencies and only downloads those that are missing, ... then the amount of space for the CRT installer is probably not going to matter much and ... the CRT dll MSVCR80.dll? ... Say I have several different apps to deploy. ...
    (microsoft.public.platformsdk.security)