Tim Slattery wrote:
> "Bill in Co." <
not_really_here@earthlink.net> wrote:
>
>
>> So I guess I don't understand the reason for the different DLL
>> methodology
>> used in the ASP thing very well, unless it would be near impossible (or
>> too
>> restricted) for an ASP page server host to simply store all the DLLs in
>> one
>> convenient stable location (just like they would on a PC), and use the
>> same
>> techniques. Is that it? (I don't have any experience with
>> "server-based
>> scripting", or writing ASP web pages, or anything like that, so that's
>> probably why I don't understand it).
>
> Let's see.....DLLs were first developed with the C (C++ wasn't around
> yet) methods I talked about. There are two ways to get your program to
> access a library like that: static and dynamic. The first means
> supplying the linker with the name of your DLL, so that it's in the
> *.exe file and is loaded when the *.exe file is. The second means that
> you call a system API function in your program and pass it the name of
> the DLL. In either case, you supply only the name of the library, not
> a path to it. The OS searches for it in the normal places: current
> directory, directory where the EXE lives, \windows, \windows\system,
> directories in the PATH environment variable, I forget the exact spec.
> Once the library is found, the program has to know the names (or
> numbers) of the functions in it, the parameters expected by each, and
> the values that will be returned. As I said before, the core windows
> libraries (user32.dll, system32.dll, kernel32.dll) work this way and
> have since at least Windows 3.0, when they didn't have the "32"
> suffix.
>
> ActiveX/Com servers let the calling program find out a lot of this
> stuff for itself. The caller calls an API specifying the name of the
> server DLL. That's looked up in the registry, which yields the
> library's location. It doesn't have to be along the search hierarchy
> that I gave in the previous paragraph, the registry entry will point
> to it wherever it is. There are a couple of functions that each COM or
> ActiveX server must have, the caller will invoke those to get names,
> arguments, and return values for all included functions. ASP pages are
> written in VBScript (sometimes Javascript, but usually VBScript). This
> kind of self-documentation makes it easier for a lightweight,
> dynamically interpreted language to use libraries.
Thanks Tim. And I'm still digesting this.
I guess the main advantage of the dynamic method then is that only when some
special DLL functions are needed is that relevant DLL code loaded, vs with
the static method, all the DLL code is always loaded, whether it is needed
or not.
I suppose the static method would generally utilize way too much memory and
resources to be very efficient or even practical, in many instances.