Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips


After installing CityDesk, you have to reboot.

That's lame.

Donald E. Knuth
Wednesday, December 12, 2001

Not true.  You only have to reboot if you *HAVE* to reboot.  i.e. you had an older version of a dll that we need the newer version of - and since you can't replace a dll that is loaded into memory, it requires a reboot.

If your system is up to date, you don't have to reboot.

Anyway, this is just standard installation program stuff, it doesn't have much to do with CityDesk....

Michael Pryor
Wednesday, December 12, 2001

Why are you replacing DLLs that are being used by existing applications? Haven't you heard of DLL Hell? You should look into using DLL/COM redirection.

Donald E. Knuth
Wednesday, December 12, 2001

In fairness, this opinion isn't. Fair, that is.

You don't get a choice as to whether or not you need to install some DLLs (for instance, the VB runtime, or other system level DLLs). And a lot of times, they are in use. You can't avoid it. DLL Hell isn't a problem that is caused by lazy Fog Creek programmers. Solutions to such problems are operating system issues (such as the Microsoft "side-by-side" strategy). To blame Fog Creek for using system level DLLs that need to be replaced with a reboot isn't fair. They didn't set the rules; they just play by them.

Brad Wilson
Thursday, December 13, 2001

... or they could always put the DLL in the CityDesk directory, or does the DLL namespace not include paths?

Garth Kidd
Thursday, December 13, 2001

When Donald Knuth suggests that you "look into using DLL/COM redirection", I hope you at least gave it a moment's thought.


Jeff Logullo
Friday, December 14, 2001

COM does *not* solve DLL hell. That's very well known to folks who work in the field.

John Lam
Friday, December 14, 2001

Application specific copies of system level or runtime DLLs is horrible, horrible, just don't do it or recommend it.

Simon Lucy
Friday, December 14, 2001

The number of times I've heard the same 'reboot' complaint from people who just don't understand what they're talking about. After trying to explain for the umpteenth time you get to a stage where just can't be bothered!

Tim Owers
Friday, December 14, 2001

If you're using DLLs as just DLLs, they don't have to overwrite existing DLLs. Just put them in the application's "bin" directory (wherever the .exe is). That's the first place Windows looks when it's loading a .dll for an application. We did that for years with DLLs like mfc???.dll, msvcrt??.dll, etc. Disk space be really cheap these days. :)

Donnie Hale
Thursday, December 20, 2001

Unfortunately, Microsoft has an integrity system that prevents running certain "protected" DLLs (and thus their descendant DLLs) from the local user space. You cannot put MSVCRT*.DLL in your local directory and get it to run. It just simply doesn't work.

The SxS (Side-by-Side) features in XP alleviate this restriction a lot, because they allow cached versions of the DLLs to be used which permits "live upgrades" of system DLLs without requiring a reboot (and .NET uses its own version of SxS as well to prevent DLL Hell).

It really wasn't a simply solvable problem until the OS did the hard work for you.

Brad Wilson
Thursday, December 20, 2001

The other problem with Donnies solution (DLL in App Directory) is if whenyou start your application and an older verison of the DLL is already in memery (From another app) then Windows will force you to use the old DLL even thou you have the newer one in your apps directory.

There isn't a lot you can do to avoid DLL hell if you use 3rd party DLL's and OCX's. That is one of the reasons I try to only use my own DLL's that I have complete control over. However I realise this is very difficult to do with VB.

Anthony Richardson
Friday, December 21, 2001

*  Recent Topics

*  Fog Creek Home