The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

DLLs and autoupdate

I realize I need to use DLLs to make it easier to update my application in bits and pieces instead of a giant redownload of everything.

As far as the types of DLLs go, I plan to stay away from runtime linking only because it appears to be a pain in the butt. You have to manually link to every exported func. This is not even always possible (as far as I can tell) when third-party libraries are involved.

So I am planning to go ahead and use the compiletime linking where I need the .lib.

Those of you with experience, do you think this is a good idea? How easy is it to update dlls linked at compile time a piece at a time? Do I need to rebuild the original up to use new DLLs? What are some of the gotchas?

Thanks
lost_in_dlls
Saturday, April 22, 2006
 
 
Is it correct that as long as I _add_ to the class APIs in the DLL and not modify anything that already exists, the applications compiled against the older DLL will still function?

But if I want to use something new I added into the DLL, then I'll have to recompile the main app.
lost_in_dlls
Saturday, April 22, 2006
 
 
First off, it sounds like you're targeting Windows.  This problems is actually quite a bit trickier than it might seem at first glance:

1.  You'll want to link via name, not ordinal, since ordinals change.  You would need to go out of your way to link via ordinal, so this is prob. not a problem. 

2.  If you want to avoid having to rebuild the entire application each time some piece changes, you will need to define the API's implemented by the dll's in such a way that they are "invariant" -- i.e., the definitions don't change even if the implementation does.

3.  If you're using C++, you must ensure that apps that use the API implemented by the dll have NO knowledge of the internal implementation of the C++ classes.  This is typically done by defining the API in the form of an interface (abstract base class), and making ONLY those declarations available to the app.  You will need to do things like use factory methods to create objects, rather than ctors, since the compiler needs the definition of the object to generate a call to the ctor.

4.  If you're using C, the problem is a bit simpler, since you don't have classes, vtables, etc.  With VB it's even easier, since in VB everything is a "framework" object (either COM or .Net, depending on version).

5.  You will run into problems if you try to mix/match compilers, since different compilers have different name-mangling algorithms.

6.  You will also run into problems if you allocate memory from one run-time heap and attempt to free it from a different heap. This can happen with multiple compilers, but also with the same compiler if different components use different compile options (e.g., release vs. debug w/VC++).  See http://aegisknight.org/cppinterface.html for more.

Some other good references can be found at:

http://www.gotw.ca/publications/mill05.htm

http://www.awprofessional.com/bookstore/product.asp?isbn=0201633620&rl=1
BillT Send private email
Saturday, April 22, 2006
 
 
#1 couldn't tell the difference between ordinals and names. How do I know which one I am using?

#2 Yup got it. I think that's what I said above (2nd post)

#3 OK, I understand the "keep the API the same", but why do I need a factory method instead of a ctor??

#4 No C.

#5 Not mixing compilers.

#6 I'll make sure I check the compile options.

Thanks!
lost_in_dlls
Saturday, April 22, 2006
 
 
Clearly I got lots of reading to do.
Thank you!
lost_in_dlls
Saturday, April 22, 2006
 
 
If you're using Visual C++, look up delayload.  It gives you the best of both worlds by letting you link statically to the lib but not loading the DLL until a function from it is used in your application. 

Keep in mind that splitting your app into a bunch of DLLs won't necessarily make updates any easier.  It's tricky making changes without breaking compatibility between DLLs.
SomeBody Send private email
Saturday, April 22, 2006
 
 
Hmmm.. Maybe it is better to just combine everything into a single exe and replace that to fix bugs etc?
lost_in_dlls
Saturday, April 22, 2006
 
 
"I realize I need to use DLLs to make it easier to update my application in bits and pieces instead of a giant redownload of everything."

If that's your only reason, you can use patches instead.

Wise (and I'm sure others) have a product to help do this. You can also roll your own. Basically, the tool generates an installer that will only contain the bits necessary to patch the existing program binaries of a given previous version.

I'm pretty sure that there are even server products that will generate "patch installers" on the fly.
Wayne B Send private email
Saturday, April 22, 2006
 
 
Wayne, could you explain more about how the installers do this?  Or, could you provide a reference to something that explains it?

What does the "patch" contain? .obj files, .lib files (to use C/C++ terms)?  Does it then modify the .exe and relink it?  How can this work?

It is my understanding that "patches" consist of updated components of your application.  These can be data files, config files, .exe files, .dll files, etc...  The installers can be made smart enough to know which ones to replace, but they can't actually modify an exe or dll with the "bits" that need updating as your post implies.
fjlaga
Sunday, April 23, 2006
 
 
Sorry, I should have used the correct terminology. It's commonly referred to as a "delta update" and basically it's an update file that contains just the differences between the machine's current version of a program and the new version.

Here is one product that will build one for you: http://www.lindersoftware.com/lspsfx10_1.htm

I would recommend that you try this product before trying to use anything that involves Windows Installer because Windows Installer can get complicated.

If you use Windows Installer (MSI files), then there are a few tools to build delta updates (referred to as MSP files or Window Installer patches). Wise has built-in patch creation, I don't know about Installshield. There are also stand-alone tools that can create MSP files from MSI files that were created with tools like Wise and Installshield.

This site is useful: http://www.appdeploy.com/

RTPatch makes MSP files: http://www.pocketsoft.com/

This freeware program makes MSP files as well: http://www.appdeploy.com/tools/detail.asp?id=249

There's also this (MSI generator): http://www.advancedinstaller.com
Wayne B Send private email
Sunday, April 23, 2006
 
 
"...but they can't actually modify an exe or dll with the "bits" that need updating as your post implies."

Why not?
Wayne B Send private email
Sunday, April 23, 2006
 
 
Wayne B Send private email
Sunday, April 23, 2006
 
 
I found the following article on CodeProject.com:
http://www.codeproject.com/dll/The_DLL_Hell.asp

It was very helpful in figuring out all the pitfalls of using DLLs, and how painful it can get when things need to change.

Maybe breaking things up into DLLs is not all that big a deal when it comes to fixing bugs and releasing new versions of the software.

Replacing everything in the install folder isn't the most gracious thing to do, but my app isn't hundreds of MB, so it shouldn't be all that bad I suppose.
lost_in_dlls
Sunday, April 23, 2006
 
 
I think you are right -- for a relatively simple application,  the whole "dll thing" may be overkill. 

However, if you're distributing some kind of library product that other applications link against, then it is pretty much essential that you deal with these issues.
BillT Send private email
Monday, April 24, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz