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.

Existance of libraries

Do people who write desktop applications assume the existance of MFC libraries on the target system? How about VB libraries?

I am actually a WTL writer, so this is not an issue for me, but I was wondering how others handle the matter? I was under the assumption that the vast majority of computers have all the standard libaries, such that there would be no need to either statically link to the libraries (MFC) or to distribute them separately (VB).
Tuesday, September 14, 2004
Its the runtime library that's more often the problem.  MSVCRT in all its multifarious versions.
Simon Lucy Send private email
Wednesday, September 15, 2004
No! A professional install will always make sure that all dependent dll's are properly installed.
Ken McKinney Send private email
Wednesday, September 15, 2004
"No! A professional install will always make sure that all dependent dll's are properly installed."

So what you are saying is that it is still not possible to assume that standard libraries such as MFC exist on client systems? I still struggle with this concept, as I would imagine that any standard computer would run a set of applications that would at least include one app dependent on MFC and one on VB, allowing small time developers like myself to forego these libraries in my installation. What about standard Office applications (word, excel etc.)... What were they written in, if not MFC?
Thursday, September 16, 2004
The version of library, regardless of whether its MFC or not (actually I'd guess that a relatively low proportion of commercial applications on a particular user's machine would be either MFC or VB), that you used to develop your application may not be the same as the one sitting on the users machine.  It may be newer or older.

You have to provide the entire library and runtime package that you know your application will run with.  If they already exist, fine, if not they'll get installed.
Simon Lucy Send private email
Thursday, September 16, 2004
Yes you cannot assume that any of the standard libraries for MFC or VB are installed. You have to check for their existance and their version. If either don't exist or not recent enough) then you need to install the correct version.

A good install script is worth it weight in gold.
Rob Conley Send private email
Thursday, September 16, 2004
You always want to test your installation against a clean install of supported OS's.  I forget the details, but I had to add MFC71.dll to an installation recently, because of course nobody had it yet - especially a clean W2k machine.
(Actually, I think we removed the dependency on the dll rather than ship it, but the point remains).
Brian Send private email
Friday, September 17, 2004
And remember to install the MFCxxx.dll and MSVCxx.dll in your app folder, not in /system32.
Stephane Rodriguez
Saturday, September 18, 2004
Unless you're useing a .local file to force dll's to load from the aplication directory you need to ensure that the c and or c++ runtimes in the system directory are >= your required version.  Installing them to your application directory is a recipe for trouble since the ones in the system directory will be almost always be loaded by something and windows will use the already loaded copy.
Ken McKinney Send private email
Monday, September 20, 2004
MFC can be statically linked, getting the bits you need right in your executable, which is highly recommended.
Joel Spolsky Send private email
Monday, September 20, 2004
I would go with Joel on this one.  We always statically link to MFC.  Although there are certain circumstances where static MFC linking is not the best option, usually it is.

If you do want to do the DLL thing, I would reccomend that at the least you have your installer scripted to check for the currect versions of the MFC DLLs and then inform the user if they are not there and maybe provide another download link for them. Not telling the user will confuse them and make them think your software is broken.

One other way to do it my be to do a /DELAYLOAD on the MFC DLLs in your VC++ project.  Then you can do the checking right when your app starts and then inform the user at that point and exit gracefully.  I have not actually tried /DELAYLOAD on MFC DLLs so I am not sure what, if any, problems that there may be there.
Tuesday, September 21, 2004

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

Other recent topics Other recent topics
Powered by FogBugz