During installation, some programs write more or less useful information in MS-Windows, more specifically, the information you see in the "Add/Remove programs" window of the setup panel.
One of the problems is due to the fact that those records are not based on any standard. Even their presence depends on the good will of the software editor. Oracle, for instance, records Oracle Server in the "Add/Remove Programs" window, but doesn't record anything for Oracle Client.
Another problem is that software uninstallation processes do not always clean all the information previously written in MS-Windows by the application.
This could lead to a situation where certain software is installed but not registered in Windows or to the opposite case, where certain applications have been uninstalled but are still registered in Windows.
Nowadays, it's quite rare to find companies that still install their software manually. Most of the time, they use disk images and then distribute their software remotely through the network.
In this case too, no standard can be applied. Each company will distribute software considering its own context and applying its own rules.
To be able to automatically recognize software applications in such cases, adapting software recognition systems to each company context is necessary.
The executable files that are present on a hard disk are theoretically a more reliable source of information for software recognition processes. But many problems remain and need to be solved first in order to master the management of installed applications. More particularly:
When the software is not an executable - the Oracle case is really interesting. Oracle not only does not register all its applications in Windows, but furthermore, the Oracle client is not an executable but a DLL. It's then necessary to detect files other than executables to be able to detect and count installed software applications.
When the software is a remote application - In a company, not all applications are necessarily installed locally on every PC. This means that software recognition systems must also be able to take remote applications into consideration.
When the software does not talk - Here again, the header information found in executables and DLLs is not necessarily sufficient or correct and fully depend upon the Editor's good will. Adobe, for instance, uses more then three distinct names for its sole company name identification!
When a software is incorrectly uninstalled - At times, uninstallations leave traces. If the only identification item is an executable and that executable remains in the PC after uninstallation, this item will still be considered active and will account for a license.
Etc. etc.
The problems related to software suites are even more complex. Microsoft, for instance, is constantly changing its license policy, especially when it comes to software suite licenses. And because each software editor has its own policy regarding suite licenses, there is of course no standard which would help to unify licenses management methods.
Once, the presence of EXCEL.EXE on a hard disk indicated an MS-Excel, an MS-Office, or an MS-Office Pro installation. Now things have become simpler concerning MS-Office products, but all other editors do not simplify things in the same way. Maybe this is better for your wallet but this still does not help suite detection. In fact, a suite is a commercial concept more than a technical one. This is why suites can't be detected based on the presence of a single file.