Loading Dll at Run time

Hi!!!

I have written a dll in Windows 2K environment which exports a class. I want to use this class in another application.

I want to load the library at run time using LoadLibrary() API. But the problem is how to use the class exported by this library.

Can anybody tell me how to do it??

Thanks in advance

Regards
Shaunak

Comments

  • : Hi!!!
    :
    : I have written a dll in Windows 2K environment which exports a class. I want to use this class in another application.
    :
    : I want to load the library at run time using LoadLibrary() API. But the problem is how to use the class exported by this library.
    :
    : Can anybody tell me how to do it??
    :
    : Thanks in advance
    :
    : Regards
    : Shaunak
    :

    use it just like you would if it were part of your application program. Link your application with the dll's *.lib file.
  • Hi!

    I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.

    Any ideas

    Regards
    Shaunak

    : : Hi!!!
    : :
    : : I have written a dll in Windows 2K environment which exports a class. I want to use this class in another application.
    : :
    : : I want to load the library at run time using LoadLibrary() API. But the problem is how to use the class exported by this library.
    : :
    : : Can anybody tell me how to do it??
    : :
    : : Thanks in advance
    : :
    : : Regards
    : : Shaunak
    : :
    :
    : use it just like you would if it were part of your application program. Link your application with the dll's *.lib file.
    :

  • : Hi!
    :
    : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    :

    you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
  • : : Hi!
    : :
    : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : :
    :
    : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    :
    [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:

    1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.

    2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.

    3. With this technology you cannot create objects on stack, like so:
    [code]
    void foo ()
    {
    MyObjectFromDLL object;
    // ^^^ Compiler will not find the body of constructor/destructor for it.
    }
    [/code]
    Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    [code]
    typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);

    void foo ()
    {
    HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    MyObjectFromDLL* pObject = pfnNew ();

    // Use your interface:
    pObject->Method1 (...);
    pObject->Method2 (...);
    pObject->Method3 (...);

    // Remove object and release the DLL:
    pfnDelete (pObject);
    FreeLibrary (hDLL);
    }
    [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    [/blue]
  • : : : Hi!
    : : :
    : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : :
    : :
    : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : :
    : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    :

    Hi!!

    Thanks for the reply but I have one more query. Is it still necessary to include the header file having the declaration of the class.
    In the example stated MyObjectFromDLL has been used but no where there is any refernce from where will the compiler know abt this class

    Regards
    Shaunak

    : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    :
    : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    :
    : 3. With this technology you cannot create objects on stack, like so:
    : [code]
    : void foo ()
    : {
    : MyObjectFromDLL object;
    : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : }
    : [/code]
    : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : [code]
    : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    :
    : void foo ()
    : {
    : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : MyObjectFromDLL* pObject = pfnNew ();
    :
    : // Use your interface:
    : pObject->Method1 (...);
    : pObject->Method2 (...);
    : pObject->Method3 (...);
    :
    : // Remove object and release the DLL:
    : pfnDelete (pObject);
    : FreeLibrary (hDLL);
    : }
    : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : [/blue]
    :



  • : : : Hi!
    : : :
    : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : :
    : :
    : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : :
    : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    :



    : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    :
    : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    :
    : 3. With this technology you cannot create objects on stack, like so:
    : [code]
    : void foo ()
    : {
    : MyObjectFromDLL object;
    : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : }
    : [/code]
    : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : [code]
    : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    :
    : void foo ()
    : {
    : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : MyObjectFromDLL* pObject = pfnNew ();
    :
    : // Use your interface:
    : pObject->Method1 (...);
    : pObject->Method2 (...);
    : pObject->Method3 (...);
    :
    : // Remove object and release the DLL:
    : pfnDelete (pObject);
    : FreeLibrary (hDLL);
    : }
    : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : [/blue]
    :


    Hi!!

    Thanks for the reply but I have one more query. Is it still necessary to include the header file having the declaration of the class.
    In the example stated MyObjectFromDLL has been used but no where there is any refernce from where will the compiler know abt this class

    Regards
    Shaunak

  • : : : Hi!
    : : :
    : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : :
    : :
    : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : :
    : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    :
    : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    :
    : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    :
    : 3. With this technology you cannot create objects on stack, like so:
    : [code]
    : void foo ()
    : {
    : MyObjectFromDLL object;
    : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : }
    : [/code]
    : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : [code]
    : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    :
    : void foo ()
    : {
    : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : MyObjectFromDLL* pObject = pfnNew ();
    :
    : // Use your interface:
    : pObject->Method1 (...);
    : pObject->Method2 (...);
    : pObject->Method3 (...);
    :
    : // Remove object and release the DLL:
    : pfnDelete (pObject);
    : FreeLibrary (hDLL);
    : }
    : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : [/blue]
    :

    [red]
    I encountered one more problem while trying to use the method stated by AsmGuru. When I am using GetProcAddress function to get the address of the function of a dll, it returns NULL if undecorated/non decorated function name is used but when I use decorated(found using dependency walker) it returns valid pointer to the function.

    Please explain this phenomenon
    Regards
    Shaunak
    [/red]


  • :
    :
    : : : : Hi!
    : : : :
    : : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : : :
    : : :
    : : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : : :
    : : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    : :
    :
    :
    :
    : : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    : :
    : : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    : :
    : : 3. With this technology you cannot create objects on stack, like so:
    : : [code]
    : : void foo ()
    : : {
    : : MyObjectFromDLL object;
    : : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : : }
    : : [/code]
    : : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : : [code]
    : : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    : :
    : : void foo ()
    : : {
    : : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : : MyObjectFromDLL* pObject = pfnNew ();
    : :
    : : // Use your interface:
    : : pObject->Method1 (...);
    : : pObject->Method2 (...);
    : : pObject->Method3 (...);
    : :
    : : // Remove object and release the DLL:
    : : pfnDelete (pObject);
    : : FreeLibrary (hDLL);
    : : }
    : : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : : [/blue]
    : :
    :
    :
    : Hi!!
    :
    : Thanks for the reply but I have one more query. Is it still necessary to include the header file having the declaration of the class.
    : In the example stated MyObjectFromDLL has been used but no where there is any refernce from where will the compiler know abt this class
    :
    : Regards
    : Shaunak
    :
    [blue]Of course, you need to include the class header file into both projects: the one to build a DLL and the one to build an EXE using that DLL (you need it in order to call methods and to define a PROCTYPEs).[/blue]
  • [b][red]This message was edited by AsmGuru62 at 2003-7-3 6:19:57[/red][/b][hr]
    :
    : : : : Hi!
    : : : :
    : : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : : :
    : : :
    : : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : : :
    : : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    : :
    : : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    : :
    : : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    : :
    : : 3. With this technology you cannot create objects on stack, like so:
    : : [code]
    : : void foo ()
    : : {
    : : MyObjectFromDLL object;
    : : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : : }
    : : [/code]
    : : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : : [code]
    : : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    : :
    : : void foo ()
    : : {
    : : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : : MyObjectFromDLL* pObject = pfnNew ();
    : :
    : : // Use your interface:
    : : pObject->Method1 (...);
    : : pObject->Method2 (...);
    : : pObject->Method3 (...);
    : :
    : : // Remove object and release the DLL:
    : : pfnDelete (pObject);
    : : FreeLibrary (hDLL);
    : : }
    : : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : : [/blue]
    : :
    :
    : [red]
    : I encountered one more problem while trying to use the method stated by AsmGuru. When I am using GetProcAddress function to get the address of the function of a dll, it returns NULL if undecorated/non decorated function name is used but when I use decorated(found using dependency walker) it returns valid pointer to the function.
    :
    : Please explain this phenomenon
    : Regards
    : Shaunak
    : [/red]
    :
    :
    :
    [blue]In order for [b][italic]GetProcAddress()[/italic][/b] to locate the function by name - you need to export it correctly from the DLL. There are few methods to do that. You should use WINAPI calling convention and export that name from the DEF file. Or you can use __declspec() keyword, but I think it is Microsoft specific, so the code may be not portable. I prefer the API way, to be a little farther from Microsoft specific stuff, so to speak...[/blue][code]
    [b].CPP[/b]
    MyClass* WINAPI NewInterface ()
    {
    return new MyClass (...);
    }

    VOID WINAPI ReleaseInterface (MyClass* pInstance)
    {
    delete pInstance;
    }

    [b].DEF[/b]
    EXPORTS
    NewInterface @1
    ReleaseInterface @2
    [/code]


  • : [b][red]This message was edited by AsmGuru62 at 2003-7-3 6:19:57[/red][/b][hr]
    : :
    : : : : : Hi!
    : : : : :
    : : : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : : : :
    : : : :
    : : : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : : : :
    : : : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    : : :
    : : : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    : : :
    : : : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    : : :
    : : : 3. With this technology you cannot create objects on stack, like so:
    : : : [code]
    : : : void foo ()
    : : : {
    : : : MyObjectFromDLL object;
    : : : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : : : }
    : : : [/code]
    : : : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : : : [code]
    : : : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : : : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    : : :
    : : : void foo ()
    : : : {
    : : : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : : : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : : : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : : : MyObjectFromDLL* pObject = pfnNew ();
    : : :
    : : : // Use your interface:
    : : : pObject->Method1 (...);
    : : : pObject->Method2 (...);
    : : : pObject->Method3 (...);
    : : :
    : : : // Remove object and release the DLL:
    : : : pfnDelete (pObject);
    : : : FreeLibrary (hDLL);
    : : : }
    : : : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : : : [/blue]
    : : :
    : :
    : : [red]
    : : I encountered one more problem while trying to use the method stated by AsmGuru. When I am using GetProcAddress function to get the address of the function of a dll, it returns NULL if undecorated/non decorated function name is used but when I use decorated(found using dependency walker) it returns valid pointer to the function.
    : :
    : : Please explain this phenomenon
    : : Regards
    : : Shaunak
    : : [/red]
    : :
    : :
    : :
    : [blue]In order for [b][italic]GetProcAddress()[/italic][/b] to locate the function by name - you need to export it correctly from the DLL. There are few methods to do that. You should use WINAPI calling convention and export that name from the DEF file. Or you can use __declspec() keyword, but I think it is Microsoft specific, so the code may be not portable. I prefer the API way, to be a little farther from Microsoft specific stuff, so to speak...[/blue][code]
    : [b].CPP[/b]
    : MyClass* WINAPI NewInterface ()
    : {
    : return new MyClass (...);
    : }
    :
    : VOID WINAPI ReleaseInterface (MyClass* pInstance)
    : {
    : delete pInstance;
    : }
    :
    : [b].DEF[/b]
    : EXPORTS
    : NewInterface @1
    : ReleaseInterface @2
    : [/code]
    :
    :
    :
    [red]
    Hi!!

    Thanks for the reply. I read about the ways of exporting function from a dll from MSDN.

    I am using __declspec(export) directive for exporting functions from the dll and was facing the problem as stated in the previous mail. Does that mean that for importing a function using run time linking from a dll which has used __declspec(import) method for exporting functions, we have to knoe the decorated name of the function?
    Kindly explain

    I have no idea as to how will export a class using the ordinal method(.DEF file).

    Regards

    Shaunak
    [/red]
  • : : [b][red]This message was edited by AsmGuru62 at 2003-7-3 6:19:57[/red][/b][hr]
    : : :
    : : : : : : Hi!
    : : : : : :
    : : : : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : : : : :
    : : : : :
    : : : : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : : : : :
    : : : : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    : : : :
    : : : : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    : : : :
    : : : : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    : : : :
    : : : : 3. With this technology you cannot create objects on stack, like so:
    : : : : [code]
    : : : : void foo ()
    : : : : {
    : : : : MyObjectFromDLL object;
    : : : : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : : : : }
    : : : : [/code]
    : : : : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : : : : [code]
    : : : : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : : : : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    : : : :
    : : : : void foo ()
    : : : : {
    : : : : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : : : : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : : : : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : : : : MyObjectFromDLL* pObject = pfnNew ();
    : : : :
    : : : : // Use your interface:
    : : : : pObject->Method1 (...);
    : : : : pObject->Method2 (...);
    : : : : pObject->Method3 (...);
    : : : :
    : : : : // Remove object and release the DLL:
    : : : : pfnDelete (pObject);
    : : : : FreeLibrary (hDLL);
    : : : : }
    : : : : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : : : : [/blue]
    : : : :
    : : :
    : : : [red]
    : : : I encountered one more problem while trying to use the method stated by AsmGuru. When I am using GetProcAddress function to get the address of the function of a dll, it returns NULL if undecorated/non decorated function name is used but when I use decorated(found using dependency walker) it returns valid pointer to the function.
    : : :
    : : : Please explain this phenomenon
    : : : Regards
    : : : Shaunak
    : : : [/red]
    : : :
    : : :
    : : :
    : : [blue]In order for [b][italic]GetProcAddress()[/italic][/b] to locate the function by name - you need to export it correctly from the DLL. There are few methods to do that. You should use WINAPI calling convention and export that name from the DEF file. Or you can use __declspec() keyword, but I think it is Microsoft specific, so the code may be not portable. I prefer the API way, to be a little farther from Microsoft specific stuff, so to speak...[/blue][code]
    : : [b].CPP[/b]
    : : MyClass* WINAPI NewInterface ()
    : : {
    : : return new MyClass (...);
    : : }
    : :
    : : VOID WINAPI ReleaseInterface (MyClass* pInstance)
    : : {
    : : delete pInstance;
    : : }
    : :
    : : [b].DEF[/b]
    : : EXPORTS
    : : NewInterface @1
    : : ReleaseInterface @2
    : : [/code]
    : :
    : :
    : :
    : [red]
    : Hi!!
    :
    : Thanks for the reply. I read about the ways of exporting function from a dll from MSDN.
    :
    : I am using __declspec(export) directive for exporting functions from the dll and was facing the problem as stated in the previous mail. Does that mean that for importing a function using run time linking from a dll which has used __declspec(import) method for exporting functions, we have to knoe the decorated name of the function?
    : Kindly explain
    :
    : I have no idea as to how will export a class using the ordinal method(.DEF file).
    :
    : Regards
    :
    : Shaunak
    : [/red]
    :
    [blue]You do not export a whole class - only two methods: to create a class instance and to destroy it. Once you create an instance you can use its methods - and you do not need to export the method names, because they are all virtual.[/blue]
  • : : : [b][red]This message was edited by AsmGuru62 at 2003-7-3 6:19:57[/red][/b][hr]
    : : : :
    : : : : : : : Hi!
    : : : : : : :
    : : : : : : : I do not want to link to the *.lib of the dll. I want to use LoadLibrary() so that whenever I require the dll i can load it. MSDN documents the way to access the function exported by the dll but is silent about the way to use a class exported by dll.
    : : : : : : :
    : : : : : :
    : : : : : : you have to link with the .lib file -- there is no choice. How do you think the compiler is going to resolve functions if you don't link with the .lib?
    : : : : : :
    : : : : : [blue]Here is how to make an interface to a class which is inside a DLL and not to have LIB linked:
    : : : : :
    : : : : : 1. Every single method of your class MUST be virtual, so the call to that method will not use a name (which must be resolved by linker), but instead will use an offset into a structure.
    : : : : :
    : : : : : 2. The instances of that class must be created and deleted by the DLL itself, so prepare these functions inside a DLL as exported, so you can call them using [b]LoadLibrary()[/b]/[b]GetProcAddress()[/b] tehcnology. Basically, one function should return a pointer to a newly created instance of the class, the second one takes the pointer to that instance and deletes it.
    : : : : :
    : : : : : 3. With this technology you cannot create objects on stack, like so:
    : : : : : [code]
    : : : : : void foo ()
    : : : : : {
    : : : : : MyObjectFromDLL object;
    : : : : : // ^^^ Compiler will not find the body of constructor/destructor for it.
    : : : : : }
    : : : : : [/code]
    : : : : : Instead, you have to dynamically load the DLL and 'ask' it to create and delete objects for you. That means you will have only object pointers to use:
    : : : : : [code]
    : : : : : typedef MyObjectFromDLL* (*NEWOBJPROC)(VOID);
    : : : : : typedef VOID (*DELOBJPROC)(MyObjectFromDLL*);
    : : : : :
    : : : : : void foo ()
    : : : : : {
    : : : : : HINSTANCE hDLL = LoadLibrary ("MYSERVER.DLL");
    : : : : : NEWOBJPROC pfnNew = (NEWOBJPROC) GetProcAddress (hDLL, "NewObject");
    : : : : : DELOBJPROC pfnDelete = (NEWOBJPROC) GetProcAddress (hDLL, "DeleteMyObject");
    : : : : : MyObjectFromDLL* pObject = pfnNew ();
    : : : : :
    : : : : : // Use your interface:
    : : : : : pObject->Method1 (...);
    : : : : : pObject->Method2 (...);
    : : : : : pObject->Method3 (...);
    : : : : :
    : : : : : // Remove object and release the DLL:
    : : : : : pfnDelete (pObject);
    : : : : : FreeLibrary (hDLL);
    : : : : : }
    : : : : : [/code]Basically, that technology is very close to COM technology, but COM has more, of course...
    : : : : : [/blue]
    : : : : :
    : : : :
    : : : : [red]
    : : : : I encountered one more problem while trying to use the method stated by AsmGuru. When I am using GetProcAddress function to get the address of the function of a dll, it returns NULL if undecorated/non decorated function name is used but when I use decorated(found using dependency walker) it returns valid pointer to the function.
    : : : :
    : : : : Please explain this phenomenon
    : : : : Regards
    : : : : Shaunak
    : : : : [/red]
    : : : :
    : : : :
    : : : :
    : : : [blue]In order for [b][italic]GetProcAddress()[/italic][/b] to locate the function by name - you need to export it correctly from the DLL. There are few methods to do that. You should use WINAPI calling convention and export that name from the DEF file. Or you can use __declspec() keyword, but I think it is Microsoft specific, so the code may be not portable. I prefer the API way, to be a little farther from Microsoft specific stuff, so to speak...[/blue][code]
    : : : [b].CPP[/b]
    : : : MyClass* WINAPI NewInterface ()
    : : : {
    : : : return new MyClass (...);
    : : : }
    : : :
    : : : VOID WINAPI ReleaseInterface (MyClass* pInstance)
    : : : {
    : : : delete pInstance;
    : : : }
    : : :
    : : : [b].DEF[/b]
    : : : EXPORTS
    : : : NewInterface @1
    : : : ReleaseInterface @2
    : : : [/code]
    : : :
    : : :
    : : :
    : : [red]
    : : Hi!!
    : :
    : : Thanks for the reply. I read about the ways of exporting function from a dll from MSDN.
    : :
    : : I am using __declspec(export) directive for exporting functions from the dll and was facing the problem as stated in the previous mail. Does that mean that for importing a function using run time linking from a dll which has used __declspec(import) method for exporting functions, we have to knoe the decorated name of the function?
    : : Kindly explain
    : :
    : : I have no idea as to how will export a class using the ordinal method(.DEF file).
    : :
    : : Regards
    : :
    : : Shaunak
    : : [/red]
    : :
    : [blue]You do not export a whole class - only two methods: to create a class instance and to destroy it. Once you create an instance you can use its methods - and you do not need to export the method names, because they are all virtual.[/blue]
    : [red]
    Hi!!

    Thanks again. I am still unable to use GetProcAddress without decorated names. I DO NOT want to use def files. Is there any solution to it or some resource where I can find the solution?

    Regards
    Shaunak
    [/red]

  • : : [red]
    : Hi!!
    :
    : Thanks again. I am still unable to use GetProcAddress without decorated names. I DO NOT want to use def files. Is there any solution to it or some resource where I can find the solution?
    :
    : Regards
    : Shaunak
    : [/red]
    :
    :
    [green]Try to extend the declaration of the exported functions with [b][code]extern "C"[/code][/b]This way, the function names in the resulting dll will be non decorated.[/green]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories