Updating DLLs and Re-linking?

Posted on 1998-01-30
Last Modified: 2013-11-19
Environment: Visual C++ 5.0, Windows 95

I have written an SDK package. The package includes a DLL named azvid10.dll and a library file azvid10.lib and a header file azvid10.h

The DLL includes several classes that are defined in the header file and can be used by anybody using the DLL. The classes are exported using the MACRO AFX_EXT_CLASS.

What I want to know is if I make changes to this DLL do I need to change the name and lib file? Does this depend on the changes I make, i.e. add a new class, add a new class function, change code in an existing class.

Microsoft seem to be frequently updating MFC42.DLL and I don't need to recompile my code. I know that if I have a flat DLL (exporting functions usinge extern "C"), I can export the functions using the .def file and then adding new functions does not invalidate the old dll, but what if I changed the parameters, then I guess a recompile and a name change to the DLL would be required?

Can you use a .def file for exporting complete classes?

Spencer Jones
Azure Limited
Question by:sdj
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Author Comment

ID: 1315221
Edited text of question

Expert Comment

ID: 1315222
If you change any of export class definition you must recompiler and rebuild project using your DLL. This si necessary because class structure and class size has been changed. If you don't do this you will get general protection error when using class. If you change only class function implementations you don't need to do anything with EXE using your DLL if your DLL is linked with import library. Since import library contains only function adresses and changing function implementation without affecting its arguments doesn't chnge function address in a DLL so you don't need even rebuild EXE.
Remember also you must rebuild and recompiler EXE if you change members order in the class definition. That's why OLE server is the best solutions since OLE interface is abstract class containing only methods which are the same as C++ class virtual functions and their addresses are ersolved in runtime. so if you add any method to OLE server to the end you don't need to recompiler or rebuild client which uses this server.
If you exprt global functions using extern "C" from a DLL and load DLL dinamically you don't need to recompile your EXE since function addresses are also resolved in run time.

Author Comment

ID: 1315223
This all makes sense. But the MFC42.DLL has not been changed since VC4.2 (if I recall correctly) does this mean the only changes in VC5.0 and SP1,2 and 3 are changes within functions?

If I add a new class to the DLL will it cause problems with applications that link to the new DLL but were compiled using the old lib?

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.


Expert Comment

ID: 1315224
Only changes which would affect the class data structure, or change the mangled export names of your current body of classes will cause problems.  This leaves MFC42.dll (and your dll) free to add classes at will without causing the problems you mention.  It also lets you make as many 'behind the scene' changes as you would wish.

This is true because when you export with AFX_EXT_CLASS, you are exporting each member of a class as a mangled name.  Clients of your dll will be linking (and loading) any import from your dll using the mangled name, so its absolute location within the dll does not matter.  Because of this, you could even add a (non-virutal) function to an existing class without a problem.

Are you writing this dll for use on the outside world?  If you are, you may want to reconsider using AFX_EXT_CLASS to export.  By using that macro (actually defined as __declspec( dllexport ) ), you will not be able to link your dll into Borland, for instance.  Nearly every compiler generates and recognizes totally different mangled function names.  This is one of the REAL headaches of C++ linkage over C linkage.

Expert Comment

ID: 1315225
As a side note:
You can change the parameters to the function and still keep the original function.  Basically you just overloaded the function to handle the different parameters ( this is C++ don't forget).

Author Comment

ID: 1315226
Your answers seem to conflict? I understand what name mangling is and from what tomd answered I believe he is suggesting that only references to the DLL using name mangling are stored in the LIB file.

But if I recompile the MFC Extension DLL after adding a new function surely the location of any other functions in the DLL will change, invalidating the address in the old LIB file? I recall from Mike Blaszczak's Professional MFC book that using _declspec(dllexport) means that all older applications will need to recompile if I add a function. I believe that AFX_EXT_CLASS is based on _declspec(dllexport)? Does this not mean that adding functions will invalidate the older DLL unless it is recompiled using the newer LIB file?

The SDK DLL is being used implicitly, do I need to think about exporting my class using a DEF file to allow it to be more upgradeable? Is it possible to export full classes via a DEF file?

Accepted Solution

galkin earned 100 total points
ID: 1315227
If you export global functions if you need to recompile the EXE using this DLL depends on the order of exported functions. If you add function to the end of the list of exported functions addresses of the previous functions will not chnage so you can use the old lib and not rebuild or recompile EXE. Of cause old lib doesn't contaon address of the new function(s) exported from a DLL. If you change the order of exported functions so you need to rebuild only your EXE with new lib. If you export entire class
and you change either class structure( add/remove/change any of class functions) you need to both recompile and rebuild EXE.Class is always exported using name mangling. Besides MFC extension DLL can be used ONLY with MFC EXE and version of MFC these modulus(DLL and EXE) must be linked to the same version of MFC. The simpliest way to export class or function from MFC extension DLL is as already been mentioned using MFC macro AFX_EXT_CLASS. If you want to use .def file you need to build .map file containg name mangling names of all functions and copy name of the functions you want to export to the .def file.
Anyway remember if you export class and this class has changed youmust recompiler and rebuild EXE. If you add new exported class to a DLL I guess you must rebuild EXE with new lib since addresses of old exported classes functions may change. It also depends on order these classes are exported. Unfortunaly I don't know what order is used but I think if you have one header file and add new exported class to the end of this header file old classes will not change but I may be mistaken.

Author Comment

ID: 1315228
It seems that this answer is confrontational to others. But the bottom line appears to be if anything changes in the header file that I supply with my .lib and .dll then I should get all the users to re-compile. Hence the best solution is to  change the name of the dll (myfile10.dll becomes myfile11.dll) and so on.

If I use a .def file however then I am able to "confidentally" add new functions to the export library and not require a name change or any re-compilation.

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction: Ownerdraw of the grid button.  A singleton class implentation and usage. Continuing from the fifth article about sudoku.   Open the project in visual studio. Go to the class view – CGridButton should be visible as a class.  R…
Introduction: The undo support, implementing a stack. Continuing from the eigth article about sudoku.   We need a mechanism to keep track of the digits entered so as to implement an undo mechanism.  This should be a ‘Last In First Out’ collec…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

617 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question