The DLL Hell - Problems and Solutions

• Download demo - 6.26 Kb

Abstract

In this article, I am going to touch on problems of DLL backwards compatibility, which are also well known as the ‘DLL Hell’.

I am going to list results of my own investigation and also refer to other investigators’ results. At the end of the article, I will give my approach for solving one of the ‘DLL hell’ problems.

Introduction

Once I’ve got a task to solve the problem with the DLL updates. Some company supplied users with DLLs that contained classes that developers used in their C++ applications. In other words, it was some kind of a SDK in the DLL. There were no restrictions on how to use these classes, so developers derived from them while creating their applications. Soon they realized that their applications started to crash after the DLL updates. Developers were required to rebuild their applications to get versions that can work with the new DLL.

Further I will provide you with my research results on this problem, with the information I have gathered from the external sources and finally I will give my solution for one of the ‘DLL Hell’ problems.

Research results

As I have understood, the issue was in the modification of the base classes placed in the supplied DLL. I’ve overviewed several articles and found that the problem of the DLL backwards compatibility is not a new one but as a true researcher I’ve decided to make several experiments personally. As a result, I have got the following list of problems:

1. Adding of a new virtual method to a class exported from a DLL can cause the following problems:
   • If class already has a virtual method B and we are adding a new one named A before it, then we are changing the table of virtual methods. Now the first virtual method in the table will be A but not B and the client program which calls B will fail without recompilation as the call of B will cause the call of A and this is another method which possibly has other parameters and return type.
   • When a class doesn’t have virtual methods and none of its base classes have, then adding of a new virtual method to it or to its base class will cause adding of the pointer for the table of virtual methods. This will cause change in the class size. So the error will occur after a client program will allocate memory for the class (an amount of memory that was required before the class has been changed) and will try to modify some of the class' fields explicitly or implicitly. In this case, as the pointer to the table of virtual method is added to the beginning of the class, all addresses of the class fields are shifted and thus we will get an abnormal client program behavior or a runtime error.
   • In case when a class has virtual methods or any of its parent classes has, we can’t add virtual methods to classes exported from the DLL if they participate in the inheritance. We can’t add virtual methods not only to the beginning of the class declaration but also to the end of it. The problem is in shifting in the table of virtual methods. Note that even if you add a new virtual method to the end of the class declaration then the child’s virtual methods will be shifted.
2. Adding of a new field (of any kind) to a class declaration can cause following problems:
   1. Adding of a new field to the end of a class causes class size to change as in the case of adding of a virtual method to a class that didn’t have any. The client program will allocate less memory than it is required for a new class and this will cause referencing to the memory out of the class scope.
   2. Adding of a new field between existing ones is even worse. It will case all addresses of fields after the new one to be shifted and a client application will work with the incorrect addresses while working with the fields that are situated after the new field. We also have the problem as in the previous point here.

There are other reasons that can cause DLL backwards compatibility problems, so below is the list of solutions that are usually offered to overcome most of them.

DLL coding conventions in brief

This is the summary of solutions I’ve found in articles on the web and I’ve got while talking with different developers.

The following conventions of a DLL development are usually offered to support DLLs backwards compatibility:

1. Coding conventions:
   • Each class exported from a DLL or its base class should have at least one virtual method to add a virtual methods table to a class. This will allow adding of virtual methods to it later.
   • If you are going to add a virtual method to a class, add it after all other virtual methods’ declarations. This will allow not to spoil the order of methods in the virtual methods table.
   • If you are planning to extend a class with the new fields later, then add there a pointer to the structure where you will add them. In this case while adding a new field, you will add it not to the class but to the structure and so the size of the class won’t change. Work with the structure as with the storage of additional class fields and add corresponding fields’ accessors to the class declaration if it is required. In this case, the DLL must be linked to a client application implicitly.
   • To solve the problems stated in the previous points, you may also make the pure interface classes for all exported classes, but in this case it will be impossible to inherit these classes in the client application and it will be also impossible to make the hierarchy of exported classes in the DLL.
   • Distribute two versions of the DLL and LIB (Debug/Release) because if you will distribute only Release version then users who are developing clients won’t be able to debug their application as Release and Debug modes have different heap managers and thus if release DLL will allocate memory which will be freed in the debug client application (vice versa), it will cause a runtime failure. There is also another possibility to solve this problem. You may add methods to allocate and deallocate memory for the DLL classes to the DLL and also prohibit deallocation of the client’s application objects in the DLL. But it is not simple to maintain this solution.
   • Don’t change the default parameters in the DLL classes’ methods as they are moved to the client’s code at compile time.
   • Beware of modification of inline methods.
   • Check that all enumerations don’t have default element values. As while adding/removing a new enumeration member you may shift values of the old enumeration members. That is why each member should have a unique value assigned to it. Also it should be documented if enumeration can be extended, because in this case client application developer should keep it in his mind.
   • Don’t change macros in DLL headers.
2. Use DLL versioning: In the case of major DLL changes it is good to have an ability to change the DLL name like Microsoft does with the MFC DLL. For example, there can be the following DLL name template: Dll_name_xx.dll Where xx is the number of the DLL version. Sometimes it is required to make big changes in the DLL, which break its backwards compatibility. In this case, the new name should be assigned to the DLL. While an installation to an OS, a new DLL, the old one will not be removed and clients compiled with it will still use it. At the same time, clients compiled with the new DLL will use the new one.
3. DLL backwards compatibility testing: There are too many possibilities to break the DLL’s backwards compatibility and that is why there should be some kind of backwards compatibility testing.

Below I am going to discuss the problem of virtual methods and I will also give a solution for one of its variants.

Virtual methods and inheritance

Let us investigate an example with virtual methods and inheritance:

/**********Exported class (dll) **********/
class EXPORT_DLL_PREFIX VirtFunctClass{
public:
    VirtFunctClass(){}
    ~VirtFunctClass(){}
    virtual void DoSmth(){
        //this->DoAnything();  

              // Uncomment of this line after the corresponding method 

              //will be added to the class declaration

    }
    //virtual void DoAnything(){} 

         // Adding of this virtual method will make shift in 

         // table of virtual methods

};

/**********Inherited class (client app) **********/
class VirtFunctClassChild : public VirtFunctClass {
public:
    VirtFunctClassChild() : VirtFunctClass (){}
    ~VirtFunctClassChild(){};
    virtual void DoSomething(){}
};

Let’s imagine that we have classes listed above. The first one is the my.dll member and the second one is the class defined in the client’s application. Now we will make some changes in the DLL class i.e. uncomment the following two lines:

//virtual void DoAnything(){}

and

//this->DoAnything();

This will symbolize some changes in the SDK classes.

Now if we won’t recompile the client’s application, then the VirtFunctClassChild class will not know anything about the new virtual method void DoAnything() that was added to its base class, so its table of virtual methods (vtable) will contain only the two methods in the following order:

1. void DoSmth()
2. void DoSomething()

This is not correct because the vtable should be as follows:

1. void DoSmth()
2. void DoAnything()
3. void DoSomething()

Then if after instantiation of the VirtFunctClassChild class, someone will call its void DoSmth() method, it will cause calling of the new virtual method void DoAnything(). The base class knows that it should be a second method in the vtable and so it will try to call it. Obviously this will cause calling of the void DoSomething() method of the child class as the vtable of the VirtFunctClassChild class contains this method in the second position and it doesn’t contain the void DoAnything() method at all !!!!

It is important to note that in case of prohibiting of inheritance from the DLL classes with adding of new virtual methods, we will still have the same problem because in this case (just imagine that there was no virtual void DoSomething(){} method in the VirtFunctClassChild class), the call of the void DoAnything() method from the base class will cause referencing to the empty memory as there will be only one member in the vtable.

Now it is obvious that there is a serious problem with adding of the new virtual methods but there is an ability to solve it in case when virtual methods are used to handle callbacks.

COM and others

Now it is time to tell that these problems are not only the well know ones and that there are not only special conventions that can help to solve them but that there are technologies that allow to avoid most of the DLL backwards compatibility problems. One of these technologies is Component Object Model (COM). So if you want to forget problems with your DLLs, use COM or any other appropriate technology.

Let us now return to the task that was given to me. The task I was talking about in the beginning of the article. It was to solve the backwards compatibility problem of one product that was a DLL.

I knew about COM and thus my first proposal was to start using COM in this project to overcome all the issues. This approach was rejected because of the following reasonable causes:

1. The product already had a COM server on one of its inner layers.
2. It is rather expensive to rewrite a large set of interface classes into COM.
3. As this product is a DLL library, there are a lot of applications that use it, so they did not want to force their customers to rewrite them.

In other words, what was required was to propose the most costless way to check the DLL backwards compatibility problem.

Of course, I should say that the main issue of this project was adding the new fields and virtual callback functions to the interface classes. The first problem is simply solved by adding a pointer to a structure (that will contain all new fields) to the class declaration and it is a common approach I have mentioned above. But the problem with the virtual callback functions was new. Further I propose the costless and effective way to solve it.

Virtual callback methods and inheritance

Let us imagine that we have a DLL with the exported classes someone has to inherit from, to implement virtual functions to handle callbacks in his application. We want to make minor changes in the DLL. This change should allow us to painlessly add new virtual call back functions to the DLL classes in the future. At the same time, we don’t want to affect applications that use the current DLL version i.e. all we can expect is that they will be once recompiled with the new DLL version but that should be done for the last time. So these are target settings and here comes the solution:

We can leave every virtual callback method as it is in the DLL's classes. All we have to remember is that adding of the new virtual method to any class definition may cause failure if a client application would not be recompiled with the new DLL version. We want to avoid this problem. The “Listeners” mechanism can help us here! If virtual methods, defined and exported from the DLL classes, are used to handle callbacks, then we can move new virtual methods to the separate interfaces.

Let’s look at the following example:

// Uncomment this definition to get sources after the DLL

// interface extension

//#define DLL_EXAMPLE_MODIFIED


#ifdef DLL_EXPORT
    #define DLL_PREFIX __declspec(dllexport)
#else
    #define DLL_PREFIX __declspec(dllimport)
#endif

/**********Exported class (dll) **********/
#define CLASS_UIID_DEF static short GetClassUIID(){return 0;}
#define OBJECT_UIID_DEF virtual short 
      GetObjectUIID(){return this->GetClassUIID();}

//Base interface for all callback handlers extensions

struct DLL_PREFIX ICallBack
{
    CLASS_UIID_DEF
    OBJECT_UIID_DEF
};

#undef CLASS_UIID_DEF

#define CLASS_UIID_DEF(X) public: static 
     short GetClassUIID(){return X::GetClassUIID()+1;}

#if defined(DLL_EXAMPLE_MODIFIED)
//Newly added interface extension

struct DLL_PREFIX ICallBack01 : public ICallBack
{
    CLASS_UIID_DEF(ICallBack)
    OBJECT_UIID_DEF
    virtual void DoCallBack01(int event) = 0;  //new call back method

};
#endif // defined(DLL_EXAMPLE_MODIFIED)


class DLL_PREFIX CExample{
public:
    CExample(){mpHandler = 0;}
    virtual ~CExample(){}
    virtual void DoCallBack(int event) = 0;
    ICallBack * SetCallBackHandler(ICallBack *handler);
    void Run();
private: 
    ICallBack * mpHandler;
};

It is easy to see that all we have to do to prepare the DLL’s classes for extension with the new virtual methods is to:

1. Add ICallBack * SetCallBackHandler(ICallBack *handler); method;
2. Add the corresponding pointer to each exported class definition;
3. Define 3 macros;
4. Define one common CallBackI interface.

I have added the ICallBack01 interface definition here as an example of how the CExample class can be extended with the new virtual callback method.

It is obvious that new virtual methods should be added to a new interface. One interface for each DLL update (i.e. if we want to add several new virtual callback methods to one class at the same time [for one DLL release], we should add them to one interface).

Each new interface (for one class) should extend the previous interface. In my example I have only one extension interface ICallBack01. If in the next release we will need to add a new call back virtual method to this class then we will create a new interface ICallBack02 that will extend the ICallBack01 interface in the way the ICallBack01 extends the ICallBack.

Macros in the code above are used to define methods required to check the interface version. For example when we are adding the new interface ICallBack01 with the new method DoCallBack01, we should check (in the CExample class) if we can call it on the ICallBack * mpHandler; member. This check should be done in the following way:

if(mpHandler != NULL && mpHandler->GetObjectUIID()>=ICallBack01::GetClassUIID()){
    ((ICallBack01 *) mpHandler)->DoCallBack01(2);
}

All these is made in the case when the new call back interface is added and the call back is inserted in the CExample class, so it is very easy.

Now you can see that the client’s applications would not be affected by these changes. The only thing will be required after the first DLL classes’ update (adding of macros, base interface ICallBack definition, SetCallBackHandler method, ICallBack pointer) is the client application's recompilation.

Later when someone will add the new callback, he will do it via the new interface addition (like adding of the ICallBack01 interface in our example). It is obvious that such change would not affect anything, as the order of virtual methods will not be changed. So the client applications will work in the old manner. The only thing you should remember is that client applications will not receive the new callbacks until they implement the new interface.

It is also important to note that DLL users will still be able to work with it easily. This is the client’s class example:

#if !defined(DLL_EXAMPLE_MODIFIED)
//Before a new interface is added to the dll.

class CClient : public CExample{
    //Everything remains as it was

public:
    CClient();
    void DoCallBack(int event);
};
#else // !defined(DLL_EXAMPLE_MODIFIED)

//After the interface ICallBack01 was added client may (not necessarily)

//change his class in the following manner to handle new events

class CClient : public CExample, public ICallBack01{
public: 
    //The constructor changes

    CClient();
    //Everything remains as it was

    void DoCallBack(int event);
    //Add the new virtual method definitions 

    //(for methods inherited from the ICallBack01)

    void DoCallBack01(int event);
};
#endif // defined(DLL_EXAMPLE_MODIFIED)

Note that an example project is attached to this article. It is called Dll_Hell_Solution.

Example Project

In the example workspace, you will find two sub projects:

1. Dll_example - contains the example DLL sources
2. Dll_Client_example - contains the example DLL client sources.

The ./Dll_Hell_Solution/Dll_example/dll_example.h file contains a commented out DLL_EXAMPLE_MODIFIED macro definition. Uncomment it to emulate the DLL's classes update.

To check that everything works, perform the following steps one by one:

1. Build the Dll_example and then the Dll_Client_example projects (with DLL_EXAMPLE_MODIFIED undefined) to emulate the initial situation. Run client application.
2. Uncomment the DLL_EXAMPLE_MODIFIED macro definition. Build the Dll_example. Run the client application. Everything will work as it should!
3. Immediately rebuild the Dll_Client_example project. Run the client application. This will emulate its update that will allow to access the new functionality of the DLLs classes.

That is all about the example project. Just download and explore it to get all details.

Conclusion

In this article:

• I have represented my research on the DLL backwards compatibility problem.
• I have summarized the list of solutions proposed by different developers.
• I have offered my approach for solving the problem with virtual functions and inheritance.

I believe that this article will be helpful for anyone who has come across the ‘DLL Hell’.

References

While working on this article, I have used the following material:

• ‘DLL Maintenance Made Easy’ by Geoff Vandegrift

If you have found that this is not the full list of references, then please notify me and I will immediately fix this problem.

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 25 of 29 (Total in Forum: 29) (Refresh) FirstPrevNext

Using static const Struct inside a DLL afarfanmadrid 3:46 5 Jul '07   I am building a DLL with Borland 5.0 Enviroment. The Cpp files used inside this dll was obtained from a compiler that it generates cpp files(snacc compiler). I have updated the compiler, and then I had problems with static const struct variable defined inside some classess(see below code). with a previous mentioned compiler, the generated cpp file and this variable was initialized correctly. Perhaps the problem is in the cpp files generated by the compiler, but I am lost, because i do not know what is exactly the problem. So if somebody could give a clue of the problem, DLLs problem, or generadted cpp files problem that it does not work inside a DLL. //defintion.... class MegacoMessage: public AsnType { public: AuthenticationHeader *authHeader; Message *mess; static const AsnSequenceTypeDesc _desc;<--- PROBLEMATIC VARIABLE!!!!! ...... //cpp file , we call to initial the struct const AsnSequenceTypeDesc MegacoMessage::_desc ( &MEDIA_GATEWAY_CONTROLModuleDesc, "MegacoMessage", // `MegacoMessage' false, AsnTypeDesc::SEQUENCE, createMegacoMessage, _mdescs ); //cpp file calling firs time the variable _desc inside the DLL: Campo* megaco= dame_tipo_asn1(MEGACO::MegacoMessage::_desc.name, <--- THE VARIABLE IS NULL!!!!. not "MegacoMessage" initial value, what happens?? &MEGACO::MegacoMessage::_desc); thanks a lot of Antonio Sign In·View Thread·PermaLink Creating dialog in a DLL imadulhaq 1:32 29 Mar '05   I have created an MFC extension DLL. Then I hook some menues on through a callback function on a window. After menus are attached to the window I want to create dialog box when certain menu is clicked. For this I added a dialog box through resource editor and drived it through CDialog box. My question is this I can create MFC dialog in a callback function where every thing else is handled through API calls i.e., without MFC functions. I am handling this through the following code: case ID_XYZ: CMyDlg* dlg = new CMyDlg; dlg->Create(IDD_XYZDIALOG,NULL); ---| dlg->ShowWindow(SW_SHOW); | |-------> Here if NULL is put then Debug assertion failed! messages occurs, if I ignore it five six times then my dialog appears. And when hwnd is placed my application crashes. Sign In·View Thread·PermaLink Calling a Dll from sqlserver vinraks 5:51 9 Aug '04   hi, I need to call a dll(which is developed in c language) from sql server. I am getting an error while passing parameters to one function module. This is my code: DECLARE @retVal INT DECLARE @comHandle INT DECLARE @errorSource VARCHAR(8000) DECLARE @errorDescription VARCHAR(8000) DECLARE @retString VARCHAR(100) DECLARE @Method VARCHAR(100) DECLARE @Parameter VARCHAR(100) DECLARE @pRS VARCHAR(100) DECLARE @pRS1 VARCHAR(100) DECLARE @Addr_Tabl VARCHAR(100) DECLARE @Addr_Tab12 VARCHAR(100) DECLARE @Statusinfo VARCHAR(100) set @Addr_Tabl=null set @pRS1=null set @pRS=null -- Initialize the COM component. EXEC @retVal = sp_OACreate 'AGIL.SapEcommRfcs.1', @comHandle OUTPUT IF (@retVal <> 0) BEGIN -- Trap errors if any EXEC sp_OAGetErrorInfo @comHandle, @errorSource OUTPUT, @errorDescription OUTPUT SELECT [Error Source] = @errorSource, [Description] = @errorDescription RETURN END -- Call a method into the component EXEC @retVal = sp_OAMethod @comHandle, 'DimAs',NULL, @Method='Z_Ecom_Getstatus',@Parameter='Statusinfo',@pRS OUTPUT EXEC @retVal = sp_OAMethod @comHandle, 'DimAs',NULL, @Method='Z_Ecom_Getstatus',@Parameter='Order_Text',@pRs1 OUTPUT EXEC @retVal = sp_OAMethod @comHandle, 'Z_Ecom_Getstatus',NULL, @Salesdocument='0301322650' IF (@retVal <> 0) BEGIN -- Trap errors if any EXEC sp_OAGetErrorInfo @comHandle, @errorSource OUTPUT, @errorDescription OUTPUT SELECT [Error Source] = @errorSource, [Description] = @errorDescription RETURN END -- Print the value returned from the method call SELECT @pRS -- Release the reference to the COM object EXEC sp_OADestroy @comHandle When i execute the above procedure i am getting an error Server: Msg 119, Level 15, State 1, Line 28 Must pass parameter number 6 and subsequent parameters as '@name = value'. After the form '@name = value' has been used, all subsequent parameters must be passed in the form '@name = value'. Server: Msg 119, Level 15, State 1, Line 29 Must pass parameter number 6 and subsequent parameters as '@name = value'. After the form '@name = value' has been used, all subsequent parameters must be passed in the form '@name = value'. I appreciate your help. thanks vinodh Sign In·View Thread·PermaLink creating event dll in mfc shared dll Xins 18:18 10 Mar '04   hii, i'm developing a mfc dll program and i must make an event in my dll. how can i create an event for my dll using mfc shared dll and the event can be used in program that use this dll. please help me if u have any idea, thx a lot. regards, -xins Sign In·View Thread·PermaLink ActiveX in a dialog from a DLL LuisM 6:32 27 Nov '03   Thanks Ivan for this article. But I need help : I've a dialog in a DLL. I tested it from a client application and it works fine. But if I include in the dialog the Microsoft FlexGrid 6.0 control (an ActiveX component) the dialog isn´t created. The control is associated to a variable, and the dialog works fine if it is in a .exe file, not in the .DLL! I don't export de dialog class. I export a function to create a local object to show the dialog. Any suggestion? Thanks Sign In·View Thread·PermaLink Re: ActiveX in a dialog from a DLL Ivan S Zapreev 7:08 27 Nov '03   Please use the GetLastError() function to get the error id after the instantiation of the dialog fails. Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink Re: ActiveX in a dialog from a DLL LuisM 1:46 28 Nov '03   Thanks for you interest. I used the GetLastError() function, but I didn't get any error! The exported function is: //++++++++++++++++++++++++++++++++++ extern __declspec(dllexport) void OpenDlg() { AFX_MANAGE_STATE(AfxGetStaticModuleState()); CMyDlg dlg; DWORD error1 = GetLastError(); dlg.DoModal(); DWORD error2 = GetLastError(); } //-------------------------- I've tested the same code and the same dialog without the FlexGrid control and it was fine (the dialog was shown)!!!! But with de FlexGrid control, in debug mode, I've found error1 and error2 were 0 ! The Watch window in Viscual C++ 6.0 IDE reported (after the first call to GetLastError): ======================================================= dlg {CMyDlg hWnd=0x00000000} CDialog {CDialog hWnd=0x00000000} m_flexGrid {CMSFlexGrid hWnd=0x00000000} _messageEntries 0x1001b158 struct AFX_MSGMAP_ENTRY const * const CMyDlg::_messageEntries messageMap {...} error1 0 ======================================================= And the Output Window, after debug mode finished, reported: ======================================================= CoCreateInstance of OLE control {6262D3A0-531B-11CF-91F6-C2863C385E30} failed. >>> Result code: 0x800401f0 >>> Is the control is properly registered? Warning: CreateDlgControls failed during dialog init. The program 'D:\MyDLGClient\Debug\MyDLGlient.exe' has exited with code 0 (0x0). ======================================================= Any idea? Thank you, again. Sign In·View Thread·PermaLink Re: ActiveX in a dialog from a DLL Anonymous 2:08 28 Nov '03   I think that the following link may be helpful: http://www.sources.ru/cpp/mfc/t10286.htm You should check what is the error description for the result code 0x800401f0. Sign In·View Thread·PermaLink Re: ActiveX in a dialog from a DLL Ivan S Zapreev 2:11 28 Nov '03   By the way the Anonymous was me Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink Re: ActiveX in a dialog from a DLL LuisM 1:51 2 Dec '03   Thank you very much! The web you recommended me (http://www.sources.ru/cpp/mfc/t10286.htm) was very useful for me to understand some of the problems encountered. But the solution was very easy: The solution is: ------------------------------------------------------------------------- BOOL CMyDLLApp::InitInstance() { // TODO: Add your specialized code here and/or call the base class AfxEnableControlContainer( ); CoInitialize(NULL); return CWinApp::InitInstance(); } ------------------------------------------------------------------------- It works fine, without memory leaks! Thanks again. LuisM lmnieto2@ujaen.es Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: ActiveX in a dialog from a DLL Ivan S Zapreev 2:05 2 Dec '03   I am happy that I was able to help you a little bit. I cannot be considered to be a specialist in these fields. Definitely I am a beginner . Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink virtual functions of derived class not called ulischmidt 21:05 25 Nov '03   Hi I've created a baseclasses with virtual functions in a dll. then i created a new dll, a window class which is derived from 2 of the baseclasses (both as public). the virtual functions of the 2nd base class will be called, but not the ones of the 1st baseclass..... My dervied class is called CDesigner The 1st baseclass is called CVariable, which virtual functions are only called in the basclass.... The 2nd baseclass is called CCWindow. Here the functions of the derived class will be called correctly! don't understand really!! here are the relevant parts: ///////////////////////////////////////////////////////////////////////// // 1st dll #define CONNECTOR_EXPORTS #ifdef CONNECTOR_EXPORTS #define CONNECTOR_API __declspec(dllexport) #else #define CONNECTOR_API __declspec(dllimport) #endif //first baseclass class CONNECTOR_API CVariable { public: CVariable(); virtual void OnPropertyChanged(int propindex, float value); ........ }; //second baseclass class CONNECTOR_API CCWindow { public: CCWindow(); virtual int GetTextSize(const char *text); ......... }; ///////////////////////////////////////////////////////////////////////// // 2nd dll class CONNECTOR_API CDesigner : public CVariable, public CCWindow { public: CDesigner(); void OnPropertyChanged(int propindex, float value); int GetTextSize(const char *text); ........... }; cheers Uli Sign In·View Thread·PermaLink Re: virtual functions of derived class not called Ivan S Zapreev 0:53 26 Nov '03   What do you mean by the "the virtual functions of the 2nd base class will be called, but not the ones of the 1st base class”? Sorry I do not have time right now to implement your example, so can you please tell me what exactly is going wrong with the call of the first method? Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink Re: virtual functions of derived class not called ulischmidt 1:40 26 Nov '03   Sorry, i meant, the virtual functions, declared in the 1st baseclass will NOT be called in the derived class, but directly in the base class. My CDesigner class is derived from 2 baseclasses. both baseclasses implement virtual functions. The virtual functions (of both baseclasses) are overridden by the derived CDesigner class. If i call now a virtual function of baseclass CCWindow, the overridden functions of my derived CDesigner class will be called, all ok! but if i call the virtual functions of baseclass CVariable, they are called in the baseclass directly instead of the overridden functions in the derived CDesigner class and i don't know why!! hope this is clearer Uli Sign In·View Thread·PermaLink Re: virtual functions of derived class not called ulischmidt 1:46 26 Nov '03   one more test: - i implemeted one class called CVariable with virtual functions. - i derived class CCWindow from CVariable. No virtual functions are overridden. class CCWindow implements own virtual functions. - then i derived CDesigner class from CCWindow only and have overridden there the virtual functions of CVariable and CCWindow. The same happens: if i call virtual functions of baseclass CCWindow, the overridden functions of the derived class CDesigner are called, perfect! if i call virtual functions of baseclass CVariable, the Baseclass implementation of the virtual functions in CVariable are called instead of the overridden functions in derived class CVariable... ((( Sign In·View Thread·PermaLink Re: virtual functions of derived class not called ulischmidt 1:55 26 Nov '03   one more test: - i implemeted one class called CVariable with virtual functions. - i derived class CCWindow from CVariable. No virtual functions are overridden. class CCWindow implements own virtual functions. - then i derived CDesigner class from CCWindow only and have overridden there the virtual functions of CVariable and CCWindow. The same happens: if i call virtual functions of baseclass CCWindow, the overridden functions of the derived class CDesigner are called, perfect! if i call virtual functions of baseclass CVariable, the Baseclass implementation of the virtual functions in CVariable are called instead of the overridden functions in derived class CVariable... ((( header code snippets: #define CONNECTOR_EXPORTS #ifdef CONNECTOR_EXPORTS #define CONNECTOR_API __declspec(dllexport) #else #define CONNECTOR_API __declspec(dllimport) #endif class CONNECTOR_API CVariable { public: CVariable(); virtual void OnPropertyChanged(int propindex, float value); ...... }; class CONNECTOR_API CCWindow : public CVariable { public: CCWindow(); virtual void drawline(int x1, int y1, int x2, int y2, T_BCOLOR color=0); ......... }; //OTHER DLL: class CONNECTOR_API CDesigner : public CCWindow { public: CDesigner(); //overridden function called in baseclass only!!! void OnPropertyChanged(int propindex, float value); //overridden function called correctly here in derived class void drawline(int x1, int y1, int x2, int y2, T_BCOLOR color=0); ............. }; Sign In·View Thread·PermaLink Re: virtual functions of derived class not called Ivan S Zapreev 4:44 26 Nov '03   So in you main program (exe) you create an instance of the CDesigner class and call OnPropertyChanged and drawline methods. The wrong method is called when you call the OnPropertyChanged method. Is that right? Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink Re: virtual functions of derived class not called ulischmidt 4:59 26 Nov '03   yes, correct. the virtual method of the baseclass (CVariable) is called instead of the method in CDesigner. drawline method is called correctly in CDesigner. Sign In·View Thread·PermaLink Re: virtual functions of derived class not called Ivan S Zapreev 5:36 27 Nov '03   You definitely made some kind of mistake in your sources but it is difficult to understand what is it without them. I am sending you my test projects that work fine! Try to compare them with your sources. I can make a suggestion that you had created another virtual function instead of redefinition of the old one. For example you had changed the order, the type or the number of its parameters. Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink DialogBox(...) not working ulischmidt 21:51 18 Nov '03   Hi I created a (non MFC) Win32 dll which creates a window. in this window i want to display a dialog. So i created a resource Dialog, added resource.h and script1.rc to my dll project and call the dialog with INT_PTR ret = DialogBox(hMod, MAKEINTRESOURCE(IDD_DIALOG1), hWnd, (DLGPROC)DialogProc); ...but nothing happens !! GetLastError() returns 1812 - ERROR_RESOURCE_DATA_NOT_FOUND hMod is my valid instance handle, hWnd is my valid window handle My Callback is declared as BOOL CALLBACK DialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) Please help, thanks Sign In·View Thread·PermaLink Re: DialogBox(...) not working Ivan S Zapreev 19:05 20 Nov '03   I guess that this is because you did not load the DLL's resources to the global memory. Use the HGLOBAL LoadResource( HMODULE hModule, // module handle HRSRC hResInfo // resource handle ); function to load the DLL resources (HMODULE) It should fix the problem. Ivan S Zapreev cerndan@mail.ru Sign In·View Thread·PermaLink