BUG: Another great set of features within the scope of MS Windows compatibility
Compatible or not?
Have you ever wondered why your Windows operating system sometimes crashes, freezes, or seems to ignore commands/prompts? Mostly, this can be seen after a software update or change (for example, installing or uninstalling a program). Even after going through the trouble of checking the system requirements and making sure you meet or exceed all of them, and paying special attention to the famous phrase “Compatible with… (your operating system)”, do you find it completely frustrating? ? Why is compatibility with Windows such a big problem? These are very good questions, and you may find the answer just as frustrating as the problem. We can start with how the word “compatibility” is used. In this article, I will explain exactly what is happening. The information that you will learn here could help you in many ways with any future problems in Windows that result from the two famous things that are wreaking havoc on itself. They are: the Dynamic Link Library (DLL) files (always a problem with versions and location) and the Windows Registry (the set of core databases responsible for almost everything within Windows, frequently corrupted or misconfigured).
I’ll go straight to the point. The answer to all compatibility questions actually starts with the statement “(some program) … is compatible with MS Windows (whatever version)”. This is the most surprising factor involved in the problems we see all too often.
What is being said here is that the program was designed to operate with a Windows baseline. Basically it should work with your version of MS Windows if you meet these requirements. However, the compatibility statement does not say that this particular program is compatible with other programs that are already installed. Note that by “baseline” we simply mean your own Windows, with nothing else installed (no other software, not even MS Office, etc.).
That’s how it is! Programs must be compatible with each other in the same way as Windows itself.! Does it alarm you? Should be! This obviously results in too much testing for the end user and too much money for IT software professionals to figure out. Therefore, the compatibility statement only includes the version of the operating system and not necessarily any other software. There are too many variations from computer to computer for this to be feasible. You just learned why your company’s IT department usually won’t let us install whatever programs we want. Doing so will cause your system to crash, become generally unstable, or even put you at risk of being hacked. Not including the fact that with all the additional software we not only lose standardization, but IT would have a more complicated beast to provide ongoing support.
Problem #1
– Shared DLLs –
One technical aspect that I find interesting in this relates to Microsoft’s implementation of their library files (Dynamic Link Libraries or DLLs). For those unfamiliar with the Library files, it is nothing more than a compilation of “common code” that you can extract from, thus avoiding reinvention of the wheel. When you need to perform a function within your program, it’s much easier to make the request from a library file, which also reduces the amount of code you have to write. Although this is a common practice in the world of operating systems, Microsoft uses too many “shared dll’s” that are linked from entries in the Windows Registry.
That in itself doesn’t make sense, but if I were to ask how many of you have seen that confirmation dialog pop up during a program uninstall “Are you sure you want to remove the shared DLL…” then I’d guess I have your attention to those who experience those strange Windows questions.
Basically, the DLL in that scenario is registered in more than one program, hence the concept of “shared dll”. Therefore, removing a DLL that is used by other programs would cause the program or Windows to crash the next time some application tries to make a call to the now-missing DLL. This becomes very annoying for anyone. Unfortunately, the best solution is to never delete shared DLLs unless you personally know for sure that they are no longer needed by any application.
Problem #2
– DLL version and location –
With DLL file sharing and so far 32-bit operating systems in common, Microsoft has of course put 32-bit DLLs in a folder called SYSTEM32 and thus the legacy DLL from 16 bit would reside only in the normal SYSTEM folder. Since most of all applications consist of DLLs and executables (EXE) are only used to provide that fancy graphical user interface (GUI) (also known as the program buttons, images, text, and fields with which you actually interacts), then we can assume that most of our applications are stored in the SYSTEM32 folder. There are some exceptions. Some apps have custom DLLs for their private use and then just put their DLLs in the same program folder instead of putting them in the same folder. SYSTEM32. Simply put, DLLs make up 90% (give or take) of all the programs on your computer.
So what about versions and location?
** I have placed the asterisks here to draw your attention to this part of the article **
The easiest way to explain this section is to break it into small parts.
1- DLL files contain a certain number of lines of code. Each DLL version would have a certain function located on a certain line number. This is very important!
2- When an Executable program makes a request from a DLL, it also requests said function from said location. This is also very important!
3- Now, if after installing some program that you want to have, there is no way of knowing if the installer of this new program is going to overwrite any DLL file currently on your computer with a different DLL version of the program you are installing. What’s worse, most installers won’t even notify you of the conflict, instead replacing hundreds of files with different versions and the result is that you’ve just removed/overwritten the program code requirements for your already existing applications.
What happens next is something like:
==> Runtime error! This means that a line of code was expected but not found in the DLL. Runtime errors can represent the same scenario as when browsing the web and encountering popups for Java script errors on line X and character X, with the exception that errors in DLLs are not they are so nice to report the exact problem. Instead, it just says that you have a problem.
==> Freeze! Computers sometimes stop accepting user input (also known as a freeze) due to DLL problems. A line of code was requested, but resulting in a bad version may mean that the processor receives an instruction that is valid, but may not be what the application was looking for. Because a programmer doesn’t include extra code in the executable on how to handle this problem, a computer’s stupidity just stops dead in its tracks.
==> DLL not found! This is always fun. However, don’t let that fool you. The fact that the DLL is not found does not mean that it does not exist on your computer. Usually you can write down the name of the missing file, find it on your computer, and then copy/paste it into the SYSTEM32 folder or Applications program folder with the executable and this would resolve the issue.
As you can see, Microsoft’s implementation of Library files is a bit temperamental and requires a good understanding of what they need and what they don’t.
So before you install that new program, you may want to take a good system or partition backup before you tamper with what you have now that works for you.
Problem #3
– Register –
The Windows Registry is a collection of databases that make up the entire configuration of your system. These files list everything from installed hardware/software, settings or options made by the user or the system itself, what you may have chosen for desktop settings (wallpaper, screen saver, icon placement, visible icons). (yes/no) and much more).
Most people who know about your registry have usually heard and will share the very important warning “DO NOT EDIT YOUR REGISTRY”. While this is a very important note and should be adhered to just the same, you should also know that many changes or repairs to your system are not even possible without editing your registry.
One key thing to remember is if it ain’t broke, don’t fix it. If you don’t need to be on the registry, stay out of it. However, sometimes it is simply necessary. For example, you have uninstalled an application, you have restarted your computer but up to hundreds or even thousands of entries for this “just deleted application” may remain in your registry. The problem will be that your system will make references to a program that has been removed and it can produce many kinds of errors. This situation produces the same effect as having deleted the program folder and not having uninstalled the program correctly.
How can you avoid this problem? you can’t. Some program uninstallers do this intentionally so that a select few won’t be able to use the trial programs over and over again for the extra 30 days, thus avoiding having to make a purchase. That’s just one example, but it’s also very real. While other times the uninstaller may have been misspelled. More commonly, the uninstaller needs access to the same temporary files that the installer created when we installed the program on our computer, since it watches for the necessary associations during removal time. However, all too often these temporary files are deleted and the necessary references are now missing.
