#886 NSIS installers always show warning on Windows 7

2.0 Series
closed-fixed
Amir Szekely
General (292)
5
2014-08-22
2009-04-01
Eric Lawrence
No

When a NSIS-installer runs on Windows 7, it will generally finish before the Win7 Program Compatibility Assistant verifies that it worked correctly. Because NSIS-installers use the old Vista manifest format, the user is prompted with an ugly "program compatibility assistant" warning after completion asking if they want to try reinstalling with different settings.

To fix this, we need to update NSIS with an updated manifest.

Microsoft says:

For windows 7, we are introducing a new application manifest support to enable apps describe the operating system they support. This will help appropriately give the compatibility modes for apps moving forward. Having this manifest will ensure turning off Program compatibility assistant in Win7.

Please see below instructions for adding this manifest, which his part of the app quality cookbook for windows 7 at http://code.msdn.microsoft.com/Windows7AppQuality under section applicaiton manifest.

Update the application manifest with the latest Compatibility information for operating system support. The section below describes the additions to the manifest:
• Name Space: Compatibility.v1 (xmlns="urn:schemas-microsoft-com:compatibility.v1">)
• Section name: CompatibilityInfo (New section)
• SupportedOS: GUID of supported operating system
The GUIDs that map to the supported operating systems are:
• {e2011457-1546-43c5-a5fe-008deee3d3f0} for Windows Vista: This is the default value for the switchback context.
• {35138b9a-5d96-4fbd-8e2d-a2440225f93a} for Windows 7: Applications that set this value in the application manifest get the Windows 7 behavior.
Microsoft will generate and post GUIDs for future Windows versions as needed.
An XML example of an updated manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>

Discussion

1 2 > >> (Page 1 of 2)
  • Eric Lawrence
    Eric Lawrence
    2009-04-01

    Error message seen on Win7

     
    Attachments
  • Eric Lawrence
    Eric Lawrence
    2009-04-01

    Incidentally, I encounter this problem with the latest version of NSIS (2.44).

     
  • John T. Haller
    John T. Haller
    2009-04-21

    I can confirm this on NSIS 2.44. It affects Windows 7 Builds after the public Beta and will apparently affect the Release Candidate in a few weeks and the final due in October or earlier. Microsoft has details on the compatibility section of the manifest here:

    http://msdn.microsoft.com/en-us/library/dd371711\(VS.85).aspx

    Only a single line needs to be added to the NSIS source to accommodate it. To the file manifest.cpp, after line 59 which is:

    xml += "\" uiAccess=\"false\"/></requestedPrivileges></security></trustInfo>";

    and before line 60 which is:

    }

    add a single line as:

    xml += "<compatibility xmlns=\"urn:schemas-microsoft-com:compatibility.v1\"><application><supportedOS Id=\"{35138b9a-5d96-4fbd-8e2d-a2440225f93a}\"/> <supportedOS Id=\"{e2011457-1546-43c5-a5fe-008deee3d3f0}\"/></application></compatibility>"

    That will take care of the issue and cause all installers to show as compatible with Vista and Windows 7.

     
  • John T. Haller
    John T. Haller
    2009-04-21

    Additionally, I've recompiled NSIS 2.44 with the additional change and it works properly on Windows 7 Build 7077 now (which is the latest leaked build).

    Oh and I accidentally left off the trailing ; at the end of my additional line.

     
  • John T. Haller
    John T. Haller
    2009-04-23

    After digging a bit more, my previous patch will actually cause problems for normal installers on Windows 7. Basically, we only need to avoid the Program Compatibility Assistant when we're not doing a normal installer... a standalone installer... which in Vista is keyed to the NSIS setting: RequestExecutionLevel user

    So, I've updated the code to only include our additional features when set as such. The previous patch can be ignored. We'll now be changing the case statement instead to read:

    case exec_level_user:
    level = "asInvoker";
    xml += "<compatibility xmlns=\"urn:schemas-microsoft-com:compatibility.v1\"><application><supportedOS Id=\"{35138b9a-5d96-4fbd-8e2d-a2440225f93a}\"/> <supportedOS Id=\"{e2011457-1546-43c5-a5fe-008deee3d3f0}\"/></application></compatibility>";
    break;

    That should do it for fixing the bug right now. Later on, we may wish to delve into more complete Windows 7 support.

    You can download a compiled version of the patch here:
    http://portableapps.com/node/19013

     
  • Eric Lawrence
    Eric Lawrence
    2009-05-01

    I'm not sure I understand why you'd do this only in that case?

    I'm encountering this problem for my applications which are set to

    RequestExecutionLevel admin

    not "user".

    thanks!

     
  • John T. Haller
    John T. Haller
    2009-05-04

    NSIS should work properly in Windows 7 without requiring this change provided that your app makes a change within the programs section of the registry (which shows up Add/Remove Programs). Unless the end user cancels the installation, in which case they will see the error (as they do on Vista I believe... at least for cancelled NSIS uninstallers). An admin-requiring installer that doesn't alter add/remove programs would be a different (and rarer) animal and may require deeper changes within NSIS to accomodate it.

    Technically, if you include the compatibility token, your installer is supposed to be fully Windows 7 aware and compatible. NSIS isn't to my knowledge, and may require more changes. This current patch is to fit a common need of non-admin installers so it may not be the end-all and be-all of it.

     
  • critternyc: You're correct on the *theory* of how registry modifications ought to work. However, per the Windows appcompat team (whom I've spoken to directly):

    "Your Setup.exe installs a single tiny dll, so it can be very fast. I believe it is updating the ARP list before PCA can make a baseline snapshot. If I take my time clicking through the install, PCA detects the changes properly. The fix here is to change the way PCA detects ARP changes. We could either block installs from starting until we finish our snapshot, or find a way to listen for changes in the registry.

    requestedExecutionLevel is the Vista indicator for PCA; NSIS needs a switchback manifest for Win7."

    The Win7 guys haven't done a snapshot change (at least for RC) and have not indicated that they plan to do so, so the best bet is to make NSIS simply use the proper manifest.

    This problem is the *only* problem I've seen with NSIS-generated installers on Win7.

     
  • John T. Haller
    John T. Haller
    2009-05-04

    I think the issue is that if the installer requires admin abilities, you can't just set an NSIS installer as having the compatibility token for Windows 7. If you do that, that means the installer is supposed to be smart enough to then ask Windows for admin level privs. If my patch were applied to all NSIS installers for Windows 7, they'd fail because they aren't asking for admin level privs and wouldn't then be allowed to write to Program Files or edit the add/remove programs keys.

    Like I said, my fix is a quick and dirty one for non-admin installers. And nearly all admin installers that work normally will already work properly on Win7. The exception would be admin-level installers that either don't alter add/remove programs or (apparently) those that close too quickly. For those, a more thorough rewrite of certain elements in NSIS would be required to be able to ask Windows 7 for admin abilities on the fly.

     
  • Eric Lawrence
    Eric Lawrence
    2009-05-05

    <<If you do that, that means the installer is supposed to be
    smart enough to then ask Windows for admin level privs.>>

    I think you might be confused about how NSIS's RequestExecutionLevel token works.

    When a manifest contains a requestedExecutionLevel of Admin, *it is* asking Windows to elevate and run it as an admin.

    And that's why NSI files that specify a RequestExecutionLevel end up writing an XML manifest to the setup program specifying the desire for requestedExecutionLevel=Admin.

    The problem here is that the manifest file format has changed between Windows Vista and Windows 7. Hence, makensis.exe needs to be updated to generate manifests in the new format to remain compatible and avoid the unneeded compatibility dialog.

    You're correct to note that indicating Win7 compatibility in the manifest is going to disable virtualization, but that's EXACTLY the behavior you want for an installer which is configured to elevate to Admin!

    (Keep in mind that specifying the RequestExecutionLevel disabled virtualization on Vista as well.)

    Cheers!

     
1 2 > >> (Page 1 of 2)