StarDestroyer.Net BBS

MKSheppard wrote:I think it has to do with M$ making the DLLs be used by everything at once, meaning that if one DLL fails, you get catastrophic system failure, as opposed to simply keeping the DLLs separate, like one set of DLLs for office, one set for IE, etc, and never shall one program call another program's dlls.

That could be one of the problems, but the way I understood it (in my limited Windows experience) was that some programs would write a different version of a DLL to whatever directory they're kept in (\System\win32 or something, I don't know, I like my OS POSIX-compliant and my slashes forward), and then other programs that required a previous or later version than the one the program had written would call the wrong one and you'd get errors all over the place.

Yes, there is DLL Hell (which I've fortunately never experienced on Windows) where poor installers overwrite DLLs with the wrong version, usually an older one. Most stuff has backwards compability, though.

%systemroot%\system32 (frontslash works too ) is usually where global libraries are stored, though sometimes they can be scattered around.

Linux has a reasonably workable solution: simply incorporate the version number of the library file into the filename. This way, you can have two different versions of the library coexist on the same system if you really need to.

Of course, it helps to have a filesystem which is not based on 8.3 filenames, so you can have very long filenames in system files (thus incorporating this extra data). Even the latest versions of Windows still use 8.3 character filenames for system files.

But the other problem is bad apps. Windows app installers can often overwrite system library files without even asking, and you might not even realize this until long after the fact. This is a problem of Windows development practices, the use of identical filenames for different versions of the same library, the short filenaming practice for Windows system files, and the fact that you can't tell what an executable installer is going to do before you click on it.

One might argue that a solution is to install apps as a power user rather than an admin, but this simply doesn't work for most apps because they insist on having admin access in order to run the installer.

AdmiralKanos wrote: One might argue that a solution is to install apps as a power user rather than an admin, but this simply doesn't work for most apps because they insist on having admin access in order to run the installer.

The real mind numbingly simple solution to all this is just to have a directory
in c:\fuckyouapp\DLL that has all the DLLs needed to run the program. There
are no DLLs replaced in your system folder, etc.

In theory, the installers are supposed to read the version metadata off the DLL and warn you. In practice, many don't do that. Some keep the DLLs locally to avoid this problem, though it's fairly rare.

The most infamous example was the Windows release of Wing Commander, which ignored DirectX versioning and automatically overwrote your computer with an older version.

Windows ME/XP was supposed to resolve this issue my making it more difficult to overwrite the system DLLs, but it may still happen. MS has released new guidelines, but as usual, they aren't always followed.

Then do CTRL-PASTE on the goddamned code, instead of
doing DLL calls.

Actualy very rarely you paste code. Instead programmers link to static libraries. That way library code is included with the executable.

And thus making the code more stable and less likely to bring
your system down in a flaming mess. Now, I don't mind games
calling DLL libraries, because that's really just a single program,
nothing else will use that AT ALL, but with M$, why do we need to have
the internet browser AND office application both calling from the
same DLL?

The reality is actualy reverse of what you think it is. DLLs are the ideal choice when multiple programs call the same functions or use shared code, DLLs are meant to shared. For example the Windows API is used by virtualy every Windows program. Therefore it resides in several DLLs. That way every program does not have to come with it's own copy of the API.

Also DLLs drasticaly reduce memory requirements for a program. Since a single copy of a DLL can be used by multiple applications simeltaneously much less memory is needed.

Also DLLs improve the ability to update and patch a program more easily. A program can use a newer of a DLL as long it's interface remains the same. So instead of reinstalling every application that uses a DLL only the DLL needs to be updated.

I think it has to do with M$ making the DLLs be used by everything at once,
meaning that if one DLL fails, you get catastrophic system failure, as opposed
to simply keeping the DLLs separate, like one set of DLLs for office, one
set for IE, etc, and never shall one program call another program's dlls.

That can be done if the programmer wishes so. But that would greatly increase the size of the application. Also updates would be problem. For example when a new version of Direct X is installed it overwrites the old DLLs. If every game came with it's own copy of Direct X then every game would have to be reinstalled.

In theory, the installers are supposed to read the version metadata off the DLL and warn you. In practice, many don't do that. Some keep the DLLs locally to avoid this problem, though it's fairly rare.

That is what image help functions are for. However as you noted few programmers use them.

Regarding metadata I heard the .NET platform has some nifty capability to prevent DLL hell situations that plagues earlier systems. You have any information regarding that ?

The most infamous example was the Windows release of Wing Commander, which ignored DirectX versioning and automatically overwrote your computer with an older version.

The Direct X Setup API was designed to properly install Direct X and prevent this kind of things from happening. When was this game released ?

Windows ME/XP was supposed to resolve this issue my making it more difficult to overwrite the system DLLs, but it may still happen. MS has released new guidelines, but as usual, they aren't always followed.

Following Winows 2000 it is impossible to delete system files. Only service packs or programs with proper authorization can change them. At least that is what the official documentation says.

The real mind numbingly simple solution to all this is just to have a directory
in c:\fuckyouapp\DLL that has all the DLLs needed to run the program. There
are no DLLs replaced in your system folder, etc.

If the DLL contains code that only that particular fuckyouapp application uses then there is no need to put it in a DLL in the first place.

The very reason for DLLs are to share code between multiple programs. If you do notwant to share code then why bother writting a DLL ?

evilcat4000 wrote:Regarding metadata I heard the .NET platform has some nifty capability to prevent DLL hell situations that plagues earlier systems. You have any information regarding that ?

Not really, but I suspect that there may be an internal versioning scheme that supports multiple library versions within the single file. MacOS X has something similar as well.

The Direct X Setup API was designed to properly install Direct X and prevent this kind of things from happening. When was this game released ?

Years ago. Apparently they forced an override on the DX component of the installer.

Following Winows 2000 it is impossible to delete system files. Only service packs or programs with proper authorization can change them. At least that is what the official documentation says.

Officially, yes, unofficially shit happnes.

evilcat4000 wrote: If the DLL contains code that only that particular fuckyouapp application uses then there is no need to put it in a DLL in the first place.

Tell that to Auran. They love libraries. They have about 23 different
libraries for Trainz and it's all kept in their own separate folder in the
trainz directory.

AdmiralKanos wrote:Windows app installers can often overwrite system library files without even asking, and you might not even realize this until long after the fact.

One of the old VB installers (those that you used to distribute your Visual Basic programs) used to copy some DLLs and activex controls as part of the INSTALLATION PROCEDURE (that means these DLLs didn't have to do with the app, but the setup itself). One of these DLLs was the RichText one, that allows you to use slightly complex text fields - like using WordPad instead of NotePad.

Interestingly enough, if you cancelled the installation, the program would delete all these files. And it totally fucked up WordPad.

One of the old VB installers (those that you used to distribute your Visual Basic programs) used to copy some DLLs and activex controls as part of the INSTALLATION PROCEDURE (that means these DLLs didn't have to do with the app, but the setup itself). One of these DLLs was the RichText one, that allows you to use slightly complex text fields - like using WordPad instead of NotePad.

Interestingly enough, if you cancelled the installation, the program would delete all these files. And it totally fucked up WordPad.

I have the source code for Wordpad. I will see if I can do something about it. Can you give me some more details like which version of VB and Windows cause this problem ?[/b]

Tell that to Auran. They love libraries. They have about 23 different
libraries for Trainz and it's all kept in their own separate folder in the
trainz directory.

That is done sometimes but it is rare. For example I once wrote a drawing application. The classes and functions for creating and drawing the elements like lines, circles etc resided in a DLL called elements.dll. Later however I changed the program to include the element classes with the executable.

DLLs are slower than static libraries so it is better to use static libraries if multiple programs do not need to use the same library.

The advantage of DLLs is that just one copy of a DLL needs to be loaded in memory to be shared by alll the applications that need them. This greatly reduces the amount of memory required to run programs.

Keep in mind DLLs are libraries. That means they are meant to be resused and shared.

evilcat4000 wrote:

...
Interestingly enough, if you cancelled the installation, the program would delete all these files. And it totally fucked up WordPad.

I have the source code for Wordpad. I will see if I can do something about it. Can you give me some more details like which version of VB and Windows cause this problem ?[/b]

I'm not very sure, it's been a while since that, and I think Windows 2000/XP always replace any lost DLLs faster than you can delete them. Probably VB 4.0 or so... it hasn't actually with the VB application, but some freeware/shareware that was on the net.

I'm pretty sure it "temporarily" replaced either the RICHTX32.OCX file or one of the riched DLL files.