Dynamic Linking

[Twister]

LoadLibray: When no path is specified, the function searches...

In other words (repeating what Hutch wrote already):
Use invoke LoadLibrary, chr$("mystuff") to let Windows crawl the usual places until it finds the dll
Use invoke LoadLibrary, chr$("bin\mystuff.dll") to get exactly that version.

That method would require many 'GetProcAddress' requests then set those addresses to variables.

[jj2007]

LoadLibray: When no path is specified, the function searches...

In other words (repeating what Hutch wrote already):
Use invoke LoadLibrary, chr$("mystuff") to let Windows crawl the usual places until it finds the dll
Use invoke LoadLibrary, chr$("bin\mystuff.dll") to get exactly that version.

That method would require many 'GetProcAddress' requests then set those addresses to variables.

So how would you dynamically link without using LoadLibrary and GetProcAddress?

[redskull]

I suppose using a COM Server would be out of the question?  :wink

[Twister]

I guess using regsvr32 could work.. I've just never worked with it before.

I could do this and it will run my library fine?

regsvr32 9878u.dll          ( in the /bin folder)?

And it will load it up just like it was in the System32 folder?

[redskull]

There's way more to making a COM object than just using regsrv.  For conventional DLL's, why not alter the PATH, or use something like this:

http://msdn.microsoft.com/en-us/library/ms686203

It won't save you the GetProcAddys, but like jj said, theres not much way to get around that

-r

[Rockoon]

You dont have to register COM or ACTIVEX DLL's these days:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

..you still have to do all the other COM cruft tho (if you want a valid COM object)

[hutch--]

If the title "Dynamic Linking" is what this question is about then you have ONE method and ONE method only, LoadLibrary(), GetProcAddress() and FreeLibrary(). The alternative is static linking and no matter what else you try, the caller must be able to find the DLL or you get an error.

None of this stuff is new and exciting, its just a collection of methods available from the operating system. When a question sounds like a "fishing expedition" I start to wonder what the intent is, there is nothing NEW to invent here and the general drift of the line of question sounds like someone looking for a non-standard technique for what can be described euphamistically as a non standard application.

Perhaps you should tell us what you have in mind and stop wasting the members time.

[redskull]

In the Microsoft parlance, there is "load-time dynamic linking" or "run-time dynamic linking", as well as regular old 'static linking'.  If the you are looking for load-time dynamic linking from a non-standard location, then short of altering the path before startup (perhaps as part of a batch file?), you are probably out of luck.  If you want to do run-time linking, then GetProcaddress is a neccessary evil.

-r

[jj2007]

In the Microsoft parlance, there is "load-time dynamic linking"

Red, now you make me curious. If I understand Microsoft correctly, you could use dll functions 'directly' as in static linking. How would that look like in Masm?
::)

[hutch--]

JJ,

Pretty ordinary stuff, the term "dynamic" in this context came from the design where you can load, run and unload a code section in a DLL. Normal LoadLibrary(), GetProcAddress(), FreeLibrary() stuff. The alternative is the normal technique in MASM where you use the import library and connect to the DLL as the app loads.

[drizz]

import table DllName works with paths.

Smallest PE file that downloads a file from the Internet and executes it  - bombastic :cheekygreen:

[sinsi]

drizz, doesn't work with win7 x64...

[jj2007]

import table DllName works with paths.

Smallest PE file that downloads a file from the Internet and executes it  - bombastic :cheekygreen:

The 97 bytes version works fine with Win XP:
@tiny.exe
@echo %errorlevel%  <<< echoes 42, the retval
@pause
Unfortunately Olly refuses to look at it...

From what I see, however, there is a difference between load-time and run-time dynamic linking - only that it's not so easy accessible with Masm.

[gwapo]

Would I be able to link an application to a dynamic-linked library then place that library in a different folder (/bin) and with the application in the parent folder? (I don't want the library in the same folder as the application.)

Call SetDllDirectory function with your new DLL folder, this will add your new path to the DLL search order.

-chris

[gwapo]

In the Microsoft parlance, there is "load-time dynamic linking"

Red, now you make me curious. If I understand Microsoft correctly, you could use dll functions 'directly' as in static linking. How would that look like in Masm?
::)

JJ, I'm not sure with MASM, but "load-time dynamic linking" is a common feature of HLL compilers where they insert stubs with series of LoadLibrary/GetProcAddress/FreeLibrary calls as opposed to hard-wired DLL/functions into import table. Load-time and run-time dynamic linking are exactly the same, except that in load-time dynamic linking, the compiler will do all the management/resolving/releasing for you.