Hi all.

quote: Original post by Skid

"So with DLLs you never have to recompile the executables using them."

If the DLL is statically linked, then you will only have to recompile it IF the exports change. Try changing the parameters or the name of the exported function in your testDll, or adding new ones. You will have recompile the client exe since the DLLs .lib file would have changed.

If the DLL is loaded at runtime, then you dont ever have to recompile the client.

Well, may be I did not express myself correctly. The person on which I was replying said "whenever the LIB changes" (and I think someone else also said "in bug fixes"). Well, when you add new functions, for instance, the LIB changes but you do not need to recompile the EXE. When you fix bugs on the DLL you also don't need to recompile the EXE.

But now what you are talking about here is *BREAKING* the EXE file compatibility whith the DLL's interface, that is something else, which will require not just EXE recompile, but it will have to be modified as well to comply with the new DLL interface.

You are right about dynamically binding the DLL functions (using LoadLibrary/GetProcAdress) only if you use a function table and the identifier to get the table address from the DLL does not change, but that would only work in the case of function name change. (Anyway, the header used to build the executable's file calling functions one name, and the header used to build the DLL's file calling it another is not good coding practice, is it? But the point is the EXE code is not broken.)

But in *ALL* cases, changing the parameters the function uses will break the EXE, requiring EXE modification and recompile, without regard to how you bind the DLL functions to the EXE.

The point is: (as long as no code is broken) EXEs will *NEVER* have to be recompiled even if the LIB or DLL used by those EXEs change.

Topgoro


Edited by - Topgoro on 4/19/00 12:42:16 PM

Just a quick correction to my posts:

When I say "dynamically link the DLL" what I actually mean is "dynamic binding of the DLL functions" (LoadLibrary/GetProcAddress)
When I say "statically link a DLL" what I actually mean is "static binding of the DLL functions"

(I am not the only one with this mistake )

Sorry for the inconvenience.
Topgoro

quote:You''re quite mad, you know that? Looking in WinNT/System32, I find 10MB of readily identifiable MFC DLLs.

I didn''t say they aren''t put there, just that they shouldn''t be. ''With the way it works at the moment'' is the bit I left out. Even this supposed auto-fixing stuff in win2k won''t help much.

quote:Given the great number of MFC based applications, that would be potentially an extra 10MB per application if they stored their MFC DLLs in the same directory. It''s more than likely you''ll have numerous applications, too (Visual C++, WordPad, Word, almost any C++ GUI application, regardless of author...).

Have you never seen the problems caused by applications blindly writing over DLLs without version checking them, or problems where MS changes the DLL but keeps the version number the same, or releases a newer DLL with an older version...

Or the fact that (to move to a different MS dll) the VC6 C runtime dll wasn''t compatible with the VC5 one, and so any VC5 app that was dynamic-linked to the runtime broke the moment a VC6 compiler / compiled app installed the new runtime...

And you would not believe the problems we''ve been having with the various microsoft data access dlls here at my day job...

All of these caused by various things overwriting the dlls in the system directory.

If they could do it right, then I would accept that it''s the right thing to do. But they can''t.

Not many DLLs qualify as being that shareable, anyway. A game shouldn''t need to. If it needs to upgrade something system-wise, it should come with the redistributables that should be provided for things - like GLSetup, for instance.

quote:It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

No, it wont. The mere presence of a file is inconsequential.

I didn''t say it were. That wasn''t the point I was making. See my points above.

quote:If you''re concerned about the versioning aspect of shared libraries, do what MFC does, and include the versioning info in the filename itself (this is akin to COM versioning).

There are still umpteen versions of MFC42.dll, you know. It just specifies the MFC version number, not the actual build of that version of MFC.

quote:All in all, I suggest everyone pick up a book on getting your applications certified for Windows (i.e., logo certification). It details the requirements of all applications that are released for Windows (not a strict rule, only one that you follow if you want to put the official "Windows Compatible" logo on your product).

Or just read the MSDN Library articles on the subject, should you have access to the CDs/DVD/website.

quote: P.S. - Delay loading rocks! =)

It does, doesn''t it?


TheTwistedOne
http://www.angrycake.com

quote: Original post by Topgoro

quote:
--------------------------------------------------------------------------------
Original post by null_pointer

Fourth comparison is updating files. With the static lib, you must update the whole executable (unless you have some sort of patching utility). With the dynamic lib, simply copy and paste the new DLL files on the old ones, and the executable will work. With shared libs, you must update the shared file, but make sure that the .LIB didn't change between builds.

--------------------------------------------------------------------------------

Well, while developing a DLL I made a Test.exe which simply calls a function In that DLL called "SelfTest", so I did not have to go back and forth testing the DLL, which was statically linked to the exe (or in NullPointer's terminology "LIB/DLL"). So with DLLs you never have to recompile the executables using them.

Oh, but I did make myself clear. Whenever the associated .LIB file is regenerated (when building the DLL) you must re-link. If the .LIB changed, the addresses of the exported functions (or variables or classes) changed.




- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/20/00 7:36:17 AM

quote:I didn''t say they aren''t put there, just that they shouldn''t be. ''With the way it works at the moment'' is the bit I left out. Even this supposed auto-fixing stuff in win2k won''t help much.

I wasn''t saying that they weren''t being put there. I was saying that they SHOULD be put there. I don''t need 15 copies of the same files scattered around my harddrive.

quote:Have you never seen the problems caused by applications blindly writing over DLLs without version checking them, or problems where MS changes the DLL but keeps the version number the same, or releases a newer DLL with an older version...

Rarely to commercial-grade applications overwrite DLLs without version checking. InstallShield, Wise, and other installation packages compare versions automatically...and any that use home-brewed installations do so as well. I''ve almost never had problems with this.

As far as releasing newer DLLs with older versions...this hasn''t ever happened. And neither does changes without incrementing the version. Can you give any examples?

quote:Or the fact that (to move to a different MS dll) the VC6 C runtime dll wasn''t compatible with the VC5 one, and so any VC5 app that was dynamic-linked to the runtime broke the moment a VC6 compiler / compiled app installed the new runtime...

Again, I''ll have to ask for examples. I''ve used every version of Visual C++, and built applications with each. I have also used Delphi since it was in beta; Visual J++ for the last 2 versions, and a great many business applications (Visio, Rational Rose, Office). Besides runtimes are incrementally updated as well (Msvcrt10.dll, Msvcrt20.dll, Msvcrt40.dll, etc.).

quote:If they could do it right, then I would accept that it''s the right thing to do. But they can''t.

I''m sorry your having so many problems. We certainly aren''t. =P

-------------------
Revolver, aka Brian Smith
MIS Programmer Analyst
brian.smith@realpage.com
RealPage >> www.realpage.com

My views aren't even mine, much less my employers. =)