|Anonymous | Login | Signup for a new account||2020-02-20 01:36 PST|
|Main | My View | View Issues|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000035||[litestep core] core||tweak||always||2007-10-14 07:04||2009-04-20 12:56|
|Summary||0000035: External DLLs cannot be placed in module directory|
|Description||If a module links to a 3rd party DLL, that DLL needs to be placed in our application directory. This is incompatible with NLM, among other things.|
|Additional Information||The underlying problem is that module DLL's directory is not part of the system's DLL search path. Only things like %path%, the application directory, system32, or the current directory are searched.|
|Tags||No tags attached.|
|This can be solved by wrapping our LoadLibrary calls with SetDllDirectory on platforms that support it (XP SP1 and up). On other platforms, we can use SetCurrentDirectory instead. In both cases this requires that all LoadLibrary calls be serialized. This requirement can be softened if we only allow modules to be loaded from specific directories.|
|Do we want to "solve" this? The litestep core has no concept of a "modules" directory. That is entirely an OTS specification.|
|This could be useful regardless of whether there is a modules directory or not (as long as the module's elsewhere than app dir), so it's not like this would be some hack for OTS. It makes stuff easier for mod devs and keeps the app dir cleaner, but it might not need high priority. In the worst case scenario the module dev could figure out the dir on his own somehow.|
|Read that part of the summary as "the MODULE'S directory", not "THE module directory". All it means is that DLLs a module depends on can't necessarily live in the same directory as the module.|
Ok, how do we want to solve this?
It seems that any .dll a module might be linking against should be "shared" anyway, so placing the shared dll in the root litestep folder makes the most sense (although I am also a fan of keeping that dir clean). If we allow modules to keep system dlls or other dependencies in their folder, it would get messy since by using the convention of having a dedicated "modules" folder, one now no longer "knows" that xyz.dll in the folder is not a litestep module, but rather some module's dependency.
However, yes, I agree that in certain instances being able to load a module from an arbitrary location without copying all of its dependencies over to the litestep folder would be helpful.
As for the NLM issue, perhaps its time for an update to NLM, and not the core?
Perhaps I'm the odd man out, but if certain specifications specify a "module" directory, why can there not be a "Library" directory? How about a new option that is added to the core that allows you to specify an alternative path to search for DLL libraries? This path would then be added to the existing DLL search path.
It seems like a simple solution to an annoying problem, though I'm not sure how feasible this is.
|2007-10-14 07:04||ilmcuts||New Issue|
|2007-10-14 07:09||ilmcuts||Note Added: 0000067|
|2007-10-14 07:17||ilmcuts||Relationship added||related to 0000036|
|2007-11-06 13:20||jugg||Note Added: 0000072|
|2007-11-25 21:16||xjill||Note Added: 0000075|
|2007-12-23 17:48||ilmcuts||Note Added: 0000077|
|2008-04-22 12:46||jugg||Status||@10@ => @30@|
|2008-04-25 11:46||jugg||Note Added: 0000096|
|2008-04-25 11:46||jugg||Status||@30@ => feedback|
|2008-12-31 04:06||ilmcuts||Relationship added||child of 0000042|
|2009-03-05 14:46||ilmcuts||Relationship deleted||child of 0000042|
|2009-03-05 14:46||ilmcuts||Relationship added||child of 0000092|
|2009-04-20 12:56||nochoa||Note Added: 0000260|
|Copyright © 2000 - 2009 Mantis Group|