Updating DLLs and Re-linking?

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
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sdjAuthor Commented:
Edited text of question
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.
sdjAuthor Commented:
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?

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

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.
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).
sdjAuthor Commented:
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?
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sdjAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.