locked
Plugins with implicitly loaded dlls RRS feed

  • Question

  • I am writing a plugin for a software of another vendor. The platform is Windows CE 6.
    This plugin is situated in a 'Plugins' folder whose location is defined by the host software.
    The plugin implicitly loads another dll in the same folder - well, it tries to, but unsuccessfully.

    If I move the implicitly loaded dll into the Windows folder, everything works fine. But this, as well as moving it into the folder of the host executable seems too invasive, I would like to have all my stuff in one place.

    Is there any possibility, given that I can not change what happens before my plugin is loaded, to make the implicit loading succeed within the same folder?

    Side note: I have never understood, why implicitly loaded dlls are not searched for in the folder of the dependent dll as well.

    Friday, August 15, 2014 2:26 PM

Answers

  • So, your plugin loads another DLL, right? Why not explicitly load and specify the full path when using LoadLibrary then?

    There's no such thing as a PATH environment variable on CE, but there is a way you can extend the searched path by setting a registry key, see this http://msdn.microsoft.com/en-us/library/ee488933.aspx

    This only works if you are the OEM (if you create the kernel) because that registry setting has to be in the BOOT hive. I think you'll need to move away from implicit loading to explicit loading and specify the full path.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.



    Saturday, August 16, 2014 4:28 AM

All replies

  • So, your plugin loads another DLL, right? Why not explicitly load and specify the full path when using LoadLibrary then?

    There's no such thing as a PATH environment variable on CE, but there is a way you can extend the searched path by setting a registry key, see this http://msdn.microsoft.com/en-us/library/ee488933.aspx

    This only works if you are the OEM (if you create the kernel) because that registry setting has to be in the BOOT hive. I think you'll need to move away from implicit loading to explicit loading and specify the full path.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.



    Saturday, August 16, 2014 4:28 AM
  • Well, as I have come to understand, implicit loading is mainly done in order to extensively use the classes exported by the loaded dll. When loading explicitly I would end up with a string of function pointers, which is not my favorite option.

    I think I will invade Windows instead.

    But still the question remains, why the dll is not looked up in the dependent dll's folder, seems quite a natural idea to me. Am I missing something?

    Saturday, August 16, 2014 9:28 AM
  • I fully agree with you. I think big Windows changed to this behavior around Windows 98, but CE never caught up. Also, it's a bit more difficult as there is no "current directory" in CE, but I agree it shouldn't be too difficult to get the loader to look in the same location as the exe or DLL loading the DLL.

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    Saturday, August 16, 2014 11:33 AM