I've noticed that some programs installed on Windows have more than three numbers in their versions. The installer creation software vendor that I use claims in their support forum that Windows Installer only uses three numbers (like major.minor.patch).
My question is, how do these other installers set different formats?
Some even have rather wacky date-like values embedded in them.
The DisplayVersion uninstall entry is just a string value and can be set to anything the installer wishes (especially if it is not a MSI based installer). Windows itself does not use this string for anything other than showing it to the user.
MSDN does say that DisplayVersion is "Derived from ProductVersion property" but that of course only applies to MSI installers.
The documentation for ProductVersion claims the syntax is major.minor.build but that same page also says:
Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.
Related
How would I get a list of EVERY program into a text file for windows 95-windows 10. The uninstall programs in control panel doesn't have the version and publisher for the older operating systems, and wmic does not display every program. Even the uninstall registry, which I thought would be my savior, does not list every program. I can see discrepancies between that and the uninstall programs tab. Powershell and the like are off the table since it is relatively new.
Some combination of the following:
Enumerate registry for HKEY_CURRENT_USER\Software\Microsoft\CurrentVersion\Uninstall and HKEY_LOCAL_MACHINE\Software\Microsoft\CurrentVersion\Uninstall. And probably HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall on 64-bit os (might be duplicated). These are the list of installed programs that appear in the Control Panel's "Program and Features" section. Notice that some of the entries are straight-forward and have most of the data you want. Others are a GUID - this corresponds to an MSI installation.
For all the entries obtained in #1 that reference a GUID, use the MSI API to find the installation information you seek. Start with MsiEnumProducts. From there you can get at version info of installed applications.
Brute force search for EXEs installed in C:\Program Files and C:\Program Files (x86). For each EXE found, you can use this method to get the version information.
You want a list of applications installed from the Windows Store? Ask me for a code sample if that's important too.
The registry uninstall registration requirements in the 90's was just the display name and the command to start the uninstallation. Windows 2000 added support for more values and exposed them in the new UI but they were still optional. In recent years a couple of them became a requirement to pass the Windows Logo tests but they are still optional for non-certified applications so the uninstall key is not guaranteed to contain version/publisher information for every entry. Portable applications are not listed in the registry so if you need a inventory of everything then you need to inspect all exe files and ignore the registry.
Supporting everything back to Win95 RTM is going to be tough since you have nothing except batch files as a scripting option. VBScript is a optional component that normally gets installed with IE 4 and I don't even remember if it is possible to get Powershell on these systems.
I don't think it is possible to extract the version information with a simple batch file, you probably need the help of a 3rd-party tool. The issue with 3rd-party tools is that a lot of them depend on the Microsoft CRT run-time .DLLs and Windows 95 RTM does not have them out of the box, not even msvcrt.dll.
If you can raise your requirement for Win95 to have Windows Scripting Host installed (redistributable or part of IE4) then you could write a VB/Jscript file that uses the FileSystemObject to both walk the entire directory tree on every drive and to get version information from .exe files.
If that is unacceptable then you need to try to find a tool that can extract version information. There is a Microsoft tool named filever.exe listed here but I don't know if it works on Win95 and a NirSoft tool here but I'm not sure if it supports stdout redirection from the commandline (but it is open source so you could fix that if needed). Even if you find a suitable tool you would still need to walk the directory tree looking for .exe files and that is not going to be fun when you are limited to command.com and its DOS compatible batch handling.
My recommendation is to write a new application. I can't recommend writing it in a .NET language because you would be dealing with versions 1-4 and it is not installed on XP and older by default.
The way I see it, you have 3 options if you are writing it yourself: Visual Basic 6, Delphi (something old, v3 or older perhaps) or C/C++.
For C/C++ any version of Microsoft Visual C++ or MinGW/GCC will do but the older the better and you must not link to or use any C run-time library stuff (you might get away with static linking with MinGW but not recent versions of Visual Studio). If I was doing this I would use Visual Studio 6 or 2003 and build with /Zl & /NODEFAULTLIB. There are multiple small standalone CRT libraries if you need them. If you use any recent version of Visual Studio you will manually have to hex-edit the file to make it run on anything older than XP.
The actual implementation needs to call FindFirstFileA (and friends) on Windows 95/98/ME and FindFirstFileW on other systems to walk the directory tree and GetFileVersionInfoA/W (and friends) to get version info.
If you are feeling fancy you could perhaps filter out files in %WinDir% signed by Microsoft. Good luck...
I have a .msi created with InstallShield that i'm trying to work correctly in a per user installation for Windows Vista and Seven.
I'm virtualizing Vista and Seven with virtuabox, with 3 accounts each :
-Admin1 (default account)
-Admin2
-User1
Whatever account i'm signed, it always install the software for Admin1, and the .msi always give me the choice between Permachine and peruser.
i can give the value i want (through InstallShield) to Allusers parameter, it doesn't affect the behavior on Vista and Seven.
I'm desperatly trying to use Orca/windows installer logs/Winlogutl.exe
I don't know what to look for with these tools.
So My question is :
How can the behavior of my .msi on Windows Vista and Seven be so weird?
What can i look for to resolve the problem?
The behavior of the ALLUSERS property, as occasionally used before the UAC era to provide a "for all users or just me" option, was not well conceived and does not work well, especially in the post-UAC era. On Windows Vista, you can only choose one value for the setting on your .msi package that has it elevate or not; ALLUSERS does not change this. Since it always (or never) elevates, you can really only handle one of the two scenarios.
Windows 7 and Windows Installer 5 introduced the MSIINSTALLPERUSER property which can override the setting that causes the package to elevate. Thus the same package can either elevate and install for everyone, or can remain non-elevated and install for "just me". While versions of InstallShield since Windows 7 came out provide this configuration option, it will still not work on Windows Vista.
So unfortunately you cannot get the behavior it sounds like you desire on Windows Vista unless you offer two packages. Your single package will always (or never) elevate, and thus will always install for everyone or just the administrative account to which it elevates. For Windows 7 you should be able to use the MSIINSTALLPERUSER approach.
So there is this software. When installed it somehow (probably reads file or registry entry) recognizes my windows operating system.
It's supposed to do some tasks only once per unique computer. If I uninstall the program and re install it, the software remembers that it has been installed and therefore do not do the task.
If I use system restore, software also does not do the tasks. If I load image of the system before the install, software also doesn't do the tasks.
If I re install a fresh copy of windows, then only the software does the task. IP even does not matter. Everything is the same, except it is a brand new copy of Windows operating system.
So I guess that the software reads some kind of unique operating system identifier, then connects to server to create a user profile.
So the question is? What could be those files which software uses to check system identifier? So far I have found out that there are entries under registry. WindowsNT/CurrentVersion and Windows/Cryptography but software do not rely on them.
Where else should I search? Any software which could help me find out?
Maybe it's reading the ProductId value from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.
Microsoft says:
The product key also forms the basis
for the product ID that is created
when Windows XP is installed. Each
licensed instance of Windows XP has a
unique Product ID.
Take care, for some OEM smopuiM versions, there is only one licensed instance of Windows XP. So you can find the same product ID for two PC.
You can use FileMon and RegMon by SysInternals to check what files and keys in registry are being accessed
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.
This is a bit of a strange problem. I have an installer that needs to check the version of Windows Installer on a machine, so I use the VersionMsi property to do this.
However, when trying it out on a Vista 32-bit machine, I have found that it reports that I have 4.05 installed. So I checked msi.dll, msiexec, etc and found that they were all at 4.5.
There must be a registry value or something else that is still pointing to 4.05, so I was wondering if there is a way to safely rollback to 4.05 and then apply the update again?
Thanks
The documentation for InstallerVersion attribute of the wix Package element shows a hint (emphasis added by me):
The minimum version of the Windows
Installer required to install this
package. Take the major version of the
required Windows Installer and
multiply by a 100 then add the minor
version of the Windows Installer. For
example, "200" would represent Windows
Installer 2.0 and "405" would
represent Windows Installer 4.5. For
64-bit Windows Installer packages,
this property must be set to 200 or
greater.
Also, if you think about it, 4.05 and 4.5 are exactly the same if you interpret the dot as a number separator rather than a decimal point. 05 is just a way to write 5 with two digits in that case.
My guess is that it's something weird going on inside WiX and/or your registry since the "05" portion is neither, so to speak, Microsoft nor generally accepted way of versioning products.