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.)
Your application must be able to find the DLL. Either in the same directory as the caller, in a directory in the system PATH or at a specific location that the calling application knows.
Hutch,
I am planning on using an application manifest to give Windows a path to load my libraries (/bin). (Applcation Manifests (Windows); http://msdn.microsoft.com/en-us/library/aa374191%28v=VS.85%29.aspx)
you could put the DLL in system32 and register it, as well
Quote from: dedndave on July 07, 2010, 08:25:44 AM
you could put the DLL in system32 and register it, as well
Is that legal? :eek
of course
many programs you have installed on your computer have done it
it's an especially good plan if you think the same library may be used by another program
of course, there may be version issues, that's what sxs is all about
It looks like a clutter, and makes hell for the simple user.
Oh, I don't think other applications would use it. Grouping the binaries together may be best for my case. Plus, it would be easy access for the user if they want to work off it.
here is a reg file i use...
REGEDIT4
[HKEY_CLASSES_ROOT\.dll]
@="dllfile"
[HKEY_CLASSES_ROOT\dllfile\shell\regdll]
@="Register ActiveX DLL"
[HKEY_CLASSES_ROOT\dllfile\shell\regdll\command]
@="regsvr32.exe \"%L\""
[HKEY_CLASSES_ROOT\dllfile\shell\unregdll]
@="Unregister ActiveX DLL"
[HKEY_CLASSES_ROOT\dllfile\shell\unregdll\command]
@="regsvr32.exe /u \"%L\""
[HKEY_CLASSES_ROOT\.ocx]
@="ocxfile"
[HKEY_CLASSES_ROOT\ocxfile\shell\regocx]
@="Register OCX Control"
[HKEY_CLASSES_ROOT\ocxfile\shell\regocx\command]
@="regsvr32.exe \"%L\""
[HKEY_CLASSES_ROOT\ocxfile\shell\unregocx]
@="Unregister OCX Control"
[HKEY_CLASSES_ROOT\ocxfile\shell\unregocx\command]
@="regsvr32.exe /u \"%L\""
that will allow you to right-click on dll and ocx files to register or unregister them
That's not quite what I was going for. :P
well - it shows you how to use REGSVR32 to register a DLL
REGSVR32 /? will also get you there
I think all your problems stem from having your dll in the bin directory.
Using LoadLibrary would be OK with a relative path, but not if the dll shows up in your imports.
Why the restriction of having to be in bin?
dave, you need to export the two procedures for regsvr32 to work. There are even a few windows components that don't (e.g. zip folders in win7 grrr.)
Sinsi,
What happens with storing libraries in the safe, comfy bin folder?
What happened to also putting the executable in the bin folder so that there wouldnt be a problem? :)
That's an old method; it needs to be more modern. Out with the old standards, in with the new. :clap:
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.
Quote from: jj2007 on July 07, 2010, 06:27:47 PM
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.
Quote from: Radio Ga Ga on July 07, 2010, 06:36:09 PM
Quote from: jj2007 on July 07, 2010, 06:27:47 PM
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?
I suppose using a COM Server would be out of the question? :wink
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?
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
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)
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.
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
Quote from: redskull on July 07, 2010, 11:12:40 PM
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,
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.
import table DllName works with paths.
Smallest PE file that downloads a file from the Internet and executes it (http://www.phreedom.org/solar/code/tinype/) - bombastic :cheekygreen:
drizz, doesn't work with win7 x64...
Quote from: drizz on July 08, 2010, 06:53:34 AM
import table DllName works with paths.
Smallest PE file that downloads a file from the Internet and executes it (http://www.phreedom.org/solar/code/tinype/) - 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.
Quote from: Radio Ga Ga on July 07, 2010, 07:28:05 AM
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 (http://msdn.microsoft.com/en-us/library/ms686203%28v=VS.85%29.aspx) function with your new DLL folder, this will add your new path to the DLL search order.
-chris
Quote from: jj2007 on July 08, 2010, 05:46:58 AM
Quote from: redskull on July 07, 2010, 11:12:40 PM
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.
Quote from: gwapo on July 08, 2010, 09:15:20 AM
Quote from: jj2007 on July 08, 2010, 05:46:58 AM
Quote from: redskull on July 07, 2010, 11:12:40 PM
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.
That makes sense, thank you.
It's been awhile, so I'm probably rusty, but I think load-time linking goes something like this:
1) The linker statically links "stub" function; that is, it actually inserts code into your EXE.
2) Your CALL instructions are hard-coded to call those stub functions
3) The stub function is simply an indirect JMP, in the form JMP [address]
4) This address points to a spot in the PE header import table, which is basically left "blank" when you link.
5) During the loading process, the OS hunts down and loads the functions you need
6) It fills in those blanks in the PE Header with the actuall addressess of the functions
7) You call the stub, the stub jumps to the address specified in the PE header, which is the function you want
-r
Red, that sounds suspiciously like what happens when we "statically" link a crt_ function.
Quote from: dedndave on July 07, 2010, 09:08:17 AM
well - it shows you how to use REGSVR32 to register a DLL
REGSVR32 /? will also get you there
regsvr32 only works with COM DLLs. That includes ActiveX, OCX and similar DLLs.
If you build a bare-bones DLL (meaning you have none of the required COM APIs), it just won't work.
Quote from: jj2007 on July 08, 2010, 04:19:38 PM
Red, that sounds suspiciously like what happens when we "statically" link a crt_ function.
I don't do much with C functions in assembly, but IIRC there are two different versions; the normal CRT functions can be load-time dynamically linked, just like any other API function (which use the process above), but there's also a "static" version of the runtime which can be linked old-school style (that is, copied into your EXE verbatim). But I could be wrong on all counts, as niether is my area of experitise.
-r