Hi, > > The post on this link is true for Windows 7 (May 6, 2009). It's 2018 > > now and MSI's property VersionNT got stuck on Windows 8 (602 if I > recall correctly). > > Quite right. I just talked to someone familiar with this here, and, as I > understand it, MSI will never offer a way to do this Right on Windows > 10. I'm not sure what the general messaging is from Microsoft around > MSI, but my personal perception is that it is not moving forward > anymore.
:( I agree it's an art to make an MSI, but being a known and documented standard, supporting commit/rollback, allowing sys-admins endless customizations of packages... (If only Microsoft offered more stock actions.) Well, I guess Microsoft is coming up with some awesome replacement in due time. :) Note a side take-home message: msiexec.exe will never be Windows 10 aware. > Fortunately, I *do* have a suggestion here...I think. > > First, though, let's make sure I'm thinking straight: In your new > system, there is an EXE that runs, detects the architecture, unpacks the > right MSI, and runs the right MSI, right? > > *If* I have that right, the EXE could be manifested as Windows-10-aware: > > Manifest contents: > https://docs.microsoft.com/en-us/windows/desktop/SysInfo/targeting-your- > application-at-windows-8-1 > VS workflow: > https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest- > inside-a-c-cpp-application > > Basically, you write an XML file and pack it in the EXE as a resource. > Visual Studio will do this for you if the file is in your VS project > source file list. I'm not sure how you'd do this with mingw_w64, but > you'd probably invoke the equivalent of mt.exe: > > https://stackoverflow.com/questions/1423492/how-do-i-add-a-manifest-to- > an-executable-using-mt-exe > > The parent installer could then call GetVersionEx without being lied to > and pass it in to your CustomAction DLL through msiexec: > > https://www.codeproject.com/articles/16767/how-to-pass-command-line- > arguments-to-msi-installe > > Let me know if that doesn't make sense or won't work for what you're > doing. I am familiar with EXE and manifests, thanks. Nevertheless, I really appreciate your time to extensively research and provide useful references in the debate. In my professional career I make EXE (or WSH) "parent installers" only because end-users usually have no clue what platform is their Windows. You can't do one-MSI-fits-all-platforms for native apps, so the parent installer EXE takes platform choice away from users. All other decision logic is inside MSI packages making them fully autonomous - once you pick the right one for your platform of course. Even if we do make a Windows 10 aware "parent installer" to inject DriverCertification property to the MSI, we get complications in one considerable use case... <SideNote> Actually, I wouldn't be on this boat at all if I wasn't interested into Group Policy deployment of OpenVPN professionally. I work for a SOHO-sized company with zero budget to run anything more than Group Policy MSI deploys, and I am totally fed with running from one employee to another to assist them with keeping OpenVPN up-to-date, since OpenVPN only has an EXE installer for the time being. Therefore, I was thinking of repackaging OpenVPN into MSI for my own needs, but later learned that OpenVPN community is interested in it too. </SideNote> When the MSI package is installed by Group Policy Client, the MSI is launched directly by msiexec.exe. There is no parent installer EXE in between. Therefore, the MSI command line parameter which TAP driver to install would need to be authored by sys-admins. This would make Group Policy deployment of OpenVPN more complicated on sys-admins as it should be. Hence my design choice to select the TAP driver within MSI itself. I would have used the VersionNT property, but it says "I am Windows 8" on Windows 10. I would have used a custom action and MSDN recommended Win32 API for Windows version detection, but when launched by Group Policy Client the parent process is msiexec.exe (which doesn't manifest as Windows 10 aware, remember take-home message above) thus the API says "I am Windows 8" on Windows 10 again. Hence such a complex workaround to detect the MSI has been launched on Windows 10. Microsoft made me do it. ;) Please, note one last thing... I totally agree with everybody saying "you shall not test for OS version, but on feature presence instead". That's why this custom action *does not* return the Windows version - not to tempt anybody else to use it for OS version detection. The FindSystemInfo custom action's only output is the "DriverCertification" property that is set to "", "attsgn", or "whql". The name "FindSystemInfo" was picked generic on purpose, to allow us to add other detections missing in MSI should we need any down the road. After all this, I realized I mistitled the patch. It should have read "Add MSI custom action for reliable driver flavour selection". Best regards, Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
