hi all,
i use statically linked dll's in my program ... or rather ... i have to.
is there a way to unload a dll completetly from my process, reload it
dynamicaly via LoadLibrary and update all the entries in my import-dir?

in case you think it's suspicious - it's not ... im writing interfaces for cad
systems and i have to implement their frameworks into my projects - which
is a common task. not so common is that when i kill a session i can not
create a new one in a specific cad system. only when i restart my
application. i thought reseting everything myself could be ... fine?

is it legal at all (my first guess was: yes) and has anyone ever tried it?
thanks,
paul :shock: :shock: :shock:
Posted on 2004-12-28 09:10:45 by mob
Are you writing the DLL for a closed-source application, or are you writing an application that loads closed-source DLLs? If you're in control of the application, why do you have to use implicit (not static) DLL linkage?
Posted on 2004-12-28 10:32:53 by f0dder
i tried that but i have tons of header files, extern objects and whatnot.
fixing all that would cost me way more time than going into my import dir.
i still have to be able to work like before - well, i see ... i'll just try it out.
Posted on 2004-12-29 05:54:58 by mob
hehe, interfaces, the language is a interface to the machine,the 0 and 1 are a interface for understand opcodes, the opcodes are the interface that is used for instruct the processor :). Dont know but is funny ;).

My only sugestion and I dont know if f0dder is refering to that with "why do you have to use implicit (not static) DLL linkage?" you need a function for "recognogize" the interface and load it, and one for unload the interface.

You can have global variables for hold the addresses of the functions of the DLL, or you can pass a structure with a model for the names of the functions :), you can get the space like if where a global var, or you can allocate the space for this one at runtim with alloc or some....


The point with a Interface is to know how/forwhat analize the stronges of your interface and weakness of it... if there is already the interface, you should know it... if there is no interface and there are already a lot of include files and suchs... that would be a problem :D.

In principle you only need: a recognogizer and loader, a unloader for the main app (the one that will load the interface) and then for the interface you should use some for: Initialization, deinitialization specially and one for check compatibility of the interface (for example can return a number for check if the actual DLL module is to old for load it... or too new and the main app have no suporfor this new Interface), from there, I guess depend on the porpuose of the interface.


Is that what you whant to know??? or??

I have another interesting way in mind.. but I will see later :D and dont know if work or already implemented somewhere hehe.
Posted on 2004-12-29 10:20:06 by rea
By the way, rereading I guess you already know that ;)...


Dont know how the PE structure is, but if the process can overwrite the contents of addresses, I guess, yes you can use the static import library like if where the global variables that I say before... there should not be problem if you handle like that.... pheraphs the order, dont know, would be best if you can write the final application manually (the import libraries for hold a order) with nasm or fasm you can have more control over that, but I guess with masm is near to posible :D...
Posted on 2004-12-29 10:25:29 by rea
thank you all
well structures here and there ... its not my interface i didn't wrote it but
i have to use it. i know the ~PE structure though but i never did or saw
something quite like that before so i though i could ask. im not sure what
happens to all the extern symbols though - it's c++ at least, so that could
be an issue.
paul
Posted on 2004-12-30 06:10:10 by mob