» home
» bugs
» git

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000035 [litestep core] core tweak always 2007-10-14 07:04 2009-04-20 12:56
Reporter ilmcuts View Status public  
Assigned To
Priority none Resolution open  
Status feedback   Product Version 0.24.7
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.
Attached Files

- Relationships
related to 0000036feedback Race condition if modules set error mode 
child of 0000092feedback LiteStep 0.26.0 - Release 

-  Notes
(0000067)
ilmcuts (manager)
2007-10-14 07:09

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.
(0000072)
jugg (manager)
2007-11-06 13:20

Do we want to "solve" this? The litestep core has no concept of a "modules" directory. That is entirely an OTS specification.
(0000075)
xjill (developer)
2007-11-25 21:16

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.
(0000077)
ilmcuts (manager)
2007-12-23 17:48

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.
(0000096)
jugg (manager)
2008-04-25 11:46

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?
(0000260)
nochoa (reporter)
2009-04-20 12:56

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.

ModuleLibraryPath c:\LiteStep\Libs\

It seems like a simple solution to an annoying problem, though I'm not sure how feasible this is.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker