These ideas seem to be very close to what I was thinking too. Having a default search path for plugins that is dynamic depending on the location of the OSGBase.dll and then loading all of these libraries into memory. Are their any new ideas on this subject?
-Aron On 1/25/07, Allen Bierbaum <[EMAIL PROTECTED]> wrote: > Dirk et al, > > Does this overlap with the discussion from a few months ago about a > plugin system? > > See: http://opensg.vrsource.org/trac/wiki/Dev/PluginsPathes > > Did anyone ever start trying out some of these ideas? > > -Allen > > Aron Bierbaum wrote: > > After doing more research into this problem, I think I know what is > > going wrong. According to the Dependency Walker documentation there > > are 5 different types of module dependencies. > > > > 1. Implicit Dependency (also known as a load-time dependency or > > sometimes incorrectly referred to as static dependency): Module A is > > implicitly linked with a LIB file for Module B at compile/link time, > > and Module A's source code actually calls one or more functions in > > Module B. Module B is a load time dependency of Module A and will be > > loaded into memory regardless if Module A actually makes a call to > > Module B at run-time. Module B will be listed in Module A's import > > table. > > > > 2. Delay-load Dependency: Module A is delay-load linked with a LIB > > file for Module B at compile/link time, and Module A's source code > > actually calls one or more functions in Module B. Module B is a > > dynamic dependency and will only be loaded if Module A actually makes > > a call to Module B at run-time. Module B will be listed in Module A's > > delay-load import table. > > > > 3. Forward Dependency: Module A is linked with a LIB file for Module B > > at compile/link time, and Module A's source code actually calls one or > > more functions in Module B. One of the functions called in Module B > > is actually a forwarded function call to Module C. Module B and > > Module C are both dependencies of Module A, but only Module B will be > > listed in Module A's import table. > > > > 4. Explicit Dependency (also known as a dynamic or run-time > > dependency): Module A is not linked with Module B at compile/link > > time. At runtime, Module A dynamically loads Module B via a > > LoadLibrary type function. Module B becomes a run time dependency of > > Module A, but will not be listed in any of Module A's tables. This > > type of dependency is common with OCXs, COM objects, and Visual Basic > > applications. > > > > 5. System Hook Dependency (also known as an injected dependency): This > > type of dependency occurs when another application hooks a specific > > event (like a mouse event) in a process. When that process produces > > that event, the OS can inject a module into the process to handle the > > event. The module that is injected into the process is not really a > > dependent of any other module, but does resides in that process' > > address space. > > > > It appears to me that currently when I link my application against > > FileIO.lib and ImageFileIO.lib I am creating a Delay-load dependency. > > So because the user will never call any functions in either of these > > libraries, there are not loaded into memory. If this is correct then > > we need to either create an Implicit Dependency, which I have no idea > > how to do, or start using a more traditional plugin architecture and > > an explicit dependency. > > > > Does anyone that might know more about this have anything to add? Does > > anyone know how to create an implicit dependency? How do people feel > > about a more traditional plugin system that would search a directory > > on disk calling LoadLibrary on each file in > > path/to/opensg/lib/plugins? I personally would like to get away from > > relying on static data initialization in order to do plugin > > registration. So for example each plugin would define a C function > > call that returns an instance of it's internal image/model loading > > class. Then we could load each library in a plugin directory, look for > > the correct symbol, and then explicitly get a reference to an image > > loader. > > > > Thanks, > > Aron > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Opensg-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/opensg-users > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
