NSIS on HiDPI displays

mgrand · 18th July 2017, 10:37

Hello guys,

With the growth of HiDPI monitors, I'd like to have my NSIS installer compatible and running to its full potential.
As suggested by the documentation, I added

code:
ManifestDPIAware true

to my script and it works well for most of the GUI.

However, I'm running into 2 issues:
- I provided welcome and header bitmaps at twice the recommended size, and it works on HiDPI displays. But on standard displays, the downsampling applied looks very cheap to me and I would prefer to provide separate bitmaps for each scale factor, is that possible?
- The checkboxes used in components page are not rescaled on HiDPI (they appear very small). Is there a way to use native Windows checkboxes instead of bitmaps?

Thanks for the help

JasonFriday13 · 18th July 2017, 11:25

For the checkboxes, I had a quick look at the code and the image list seems to be hardcoded to 16x16.

I guess if the scaled size of the treeview can be retrieved, then the check bitmap could be resized in memory and then applied to the treeview. This also depends on how old the OS is as to how well this would work.

Anders · 18th July 2017, 12:25

I tried to create a "native" checkbox plug-in years ago but I never finished it because the theme API does not really support flat checkboxes IIRC.

mgrand · 29th July 2017, 14:57

It would be a nice addition to have flat checkboxes support. Looks like the only missing piece to a fully native-looking GUI.

Any ideas about welcome & header bitmaps? What's the proper way to have those bitmaps compatible with HiDPI diplays?

Anders · 29th July 2017, 20:15

There are some stretch options for the bitmap IIRC but it is never going to look great. You could have images of multiple sizes and extract in .onInit I guess.

Anders · 31st July 2017, 16:52

PHP Code:


			
!include LogicLib.nsh

System::Call USER32::GetDpiForSystem()i.r0

${If} $0 U<= 0

    System::Call USER32::GetDC(i0)i.r1

    System::Call GDI32::GetDeviceCaps(ir1,i88)i.r0

    System::Call USER32::ReleaseDC(i0,ir1)

${EndIf}

MessageBox mb_ok SysDpi=$0

and extract with a size based on https://msdn.microsoft.com/en-us/lib...px#CLOSEST_FIT

Quote:

int iSourceImageDPIToUse = 96; // We will assume 96 by default.

if (gDPI > 144)
iSourceImageDPIToUse = 192;
else if (gDPI > 120)
iSourceImageDPIToUse = 144;
else if (gDPI > 96)
iSourceImageDPIToUse = 120;

mgrand · 3rd August 2017, 13:53

Thanks! I will try that

Anders · 5th August 2017, 19:11

I looked at what it takes to create this plug-in again and even before I get to the theme stuff I see that the classic DrawFrameControl function does not know how to draw read-only checkboxes so some post paint tweaking will be required.

mgrand · 6th August 2017, 14:32

If anybody interested, here is the piece of code I used to show different bitmaps according to the DPI setting

PHP Code:


			
ManifestDPIAware true



!define MUI_PAGE_CUSTOMFUNCTION_SHOW showHiDpi

!insertmacro MUI_PAGE_WELCOME

!insertmacro MUI_PAGE_LICENSE "Resource\license.rtf"

!insertmacro MUI_PAGE_COMPONENTS

!insertmacro MUI_PAGE_INSTFILES

!define MUI_PAGE_CUSTOMFUNCTION_SHOW showHiDpi

!insertmacro MUI_PAGE_FINISH



Function .onInit

    File /oname=$PLUGINSDIR\welcome96.bmp Resource\welcome96.bmp

    File /oname=$PLUGINSDIR\welcome120.bmp Resource\welcome120.bmp

    File /oname=$PLUGINSDIR\welcome144.bmp Resource\welcome144.bmp

    File /oname=$PLUGINSDIR\welcome192.bmp Resource\welcome192.bmp



    File /oname=$PLUGINSDIR\header96.bmp Resource\header96.bmp

    File /oname=$PLUGINSDIR\header120.bmp Resource\header120.bmp

    File /oname=$PLUGINSDIR\header144.bmp Resource\header144.bmp

    File /oname=$PLUGINSDIR\header192.bmp Resource\header192.bmp

FunctionEnd



Function showHiDpi

    System::Call USER32::GetDpiForSystem()i.r0 

    ${If} $0 U<= 0 

        System::Call USER32::GetDC(i0)i.r1 

        System::Call GDI32::GetDeviceCaps(ir1,i88)i.r0 

        System::Call USER32::ReleaseDC(i0,ir1) 

    ${EndIf} 



    ${Unless} $0 == 120

    ${AndUnless} $0 == 144

    ${AndUnless} $0 == 192

        StrCpy $0 96

    ${EndIf}



    ${NSD_SetImage} $mui.WelcomePage.Image $PLUGINSDIR\welcome$0.bmp $mui.WelcomePage.Image.Bitmap

    ${NSD_SetImage} $mui.FinishPage.Image $PLUGINSDIR\welcome$0.bmp $mui.FinishPage.Image.Bitmap

    SetBrandingImage /IMGID=1046 "$PLUGINSDIR\header$0.bmp"

FunctionEnd

Also, it's important to note that HiDPI bitmaps size is not exactly the standard size multiplied by the scaling factor. Here are the values I used to fit perfectly (at least on Windows 10):

Header bitmap:
96dpi: 150x57
120dpi: 175x70
144dpi: 225x83
192dpi: 300x109

Welcome/Finish bitmap:
96dpi: 164x314
120dpi: 191x386
144dpi: 245x458
192dpi: 327x603

Anders · 6th August 2017, 14:57

I would strongly recommend that you use the algorithm I posted, use >=, not == and pick the largest image you can fit.

mgrand · 6th August 2017, 18:58

It looks good! Checkboxes scale correctly with the DPI.
Are they native Windows controls or custom drawing?

Quote:

Originally Posted by Anders

I would strongly recommend that you use the algorithm I posted, use >=, not == and pick the largest image you can fit.

Right, thanks

Anders · 6th August 2017, 15:16

Here is a very basic attempt to do native checkboxes, only classic style for now, will investigate themes later.

Quote:

XPStyle on
ManifestDPIAware true

Page Components "" OnCompShow
Page InstFiles

Function OnCompShow
SysCompImg::ApplyFlat
FunctionEnd

Section Normal
SectionEnd
SectionGroup /e Group
Section /o UnChecked
SectionEnd
Section Checked
SectionEnd
SectionGroupEnd
Section /o RO:U
SectionIn RO
SectionEnd
Section RO:C
SectionIn RO
SectionEnd

Let me know how this looks

Anders · 6th August 2017, 19:57

It uses the DrawFrameControl API to draw on a custom imagelist. It is probably the same API used by the classic theme.

Anders · 9th August 2017, 20:36

On the theme side of things, on Vista+ the TVS_EX_PARTIALCHECKBOXES style would be usable but TVS_EX_DIMMEDCHECKBOXES cannot be used for the read-only image so there is no way to get native flat themed checkboxes. Next step is to try to use the theme API to draw 3d checkboxes.

mgrand · 16th August 2017, 11:02

Thanks for investigating

I'm not familiar with neither Windows API nor NSIS internal programming, but wouldn't it make more sense to use native checkbox controls instead, like nsDialogs?

Anders · 25th August 2017, 14:14

New version.

SetClassic: Classic flat look
SetFlat: Same as classic for now
SetThemed: Themed on XP+, same as SetFlat on <= 2000
GetSysDpi: System DPI in $0

mgrand · 26th August 2017, 10:06

Awesome! The checkboxes now really look consistent with the rest of the GUI

Anders · 27th August 2017, 18:26

New version, added Unicode and 64-bit builds.

Support for custom bitmaps:

Quote:

Function OnCompShow
SysCompImg::GetSysDpi
${If} $0 > 144
File "/oname=$PluginsDir\check.bmp" "${NSISDIR}\Contrib\Graphics\Checks\big.bmp" ; 192
${ElseIf} $0 > 120
File "/oname=$PluginsDir\check.bmp" "${NSISDIR}\Contrib\Graphics\Checks\red-round.bmp" ; 144
${ElseIf} $0 > 96
File "/oname=$PluginsDir\check.bmp" "${NSISDIR}\Contrib\Graphics\Checks\grey.bmp" ; 120
${Else}
File "/oname=$PluginsDir\check.bmp" "${NSISDIR}\Contrib\Graphics\Checks\simple.bmp" ; 96
${EndIf}
SysCompImg::SetCustom "$PluginsDir\check.bmp"
FunctionEnd

mgrand · 11th September 2017, 18:15

Really cool

Will this be merged into NSIS?

Nutzzz · 11th September 2017, 23:10

Yes, thanks for this, @Anders !

I've experimented with this a bit, and another issue is the scrollbars (for, e.g., the License Agreement) are very small.

Anders · 12th September 2017, 12:39

Windows is drawing the scrollbars, not us. There is EnableNonClientDpiScaling but I don't think we can use it. I will investigate PerMonitorAwareV2, we might be able to support that.

Hugh · 11th August 2018, 00:20

I've tried using both a normal-size and an over-sized banner bmp (2x) using the modern_headerbmp.exe UI, but unlike mgrand I'm not seeing it scale properly at HiDPI (ie. at 200% I would have expected to work with the 2x sized banner). It appears to maintain the exact pixel counts regardless of scale or the image being used, instead of percentage coverage, as if the size was pixel-fixed (possibly in the modern_headerbmp.exe resource?). I used ResourceHacker to check the control sizes in the exe, but I couldn't determine which control affects the banner (a full-width banner, unlike 1046 which appears to be a 100x35 image).

ManifestDPIAware and ManifestSupportedOS have been set (true and all, respectively), which fixes the text scaling, but not the image. I've tried all the different settings with MUI_HEADERIMAGE_BITMAP_STRETCH to no avail. I've also attempted to use SetBrandingImage (as per https://stackoverflow.com/questions/...stallers-pages), along with using AddBrandingImage before calling SetBrandingImage to see if that changes the behaviour when using the oversized image, but I'm getting "no branding image found in chosen UI!" and I'm not sure that's the right way of solving this issue.

Any ideas?

Anders · 11th August 2018, 19:24

Resources use dialog units, not pixels. The final pixel size is calculated by Windows at run-time and it is based on the font size (dialog unit) and DPI.

More information would be nice. Windows version? Is the primary monitor 200% DPI? Logged out and back in after changing DPI?

Hugh · 15th August 2018, 00:24

After some further investigation, it looks like we're manually setting image sizes via SetWindowPos(), which would explain the issues, so this has been resolved.

However, I noticed that the window size is slightly narrower in 120dpi mode (125%), while all other modes (100%, 150%, 200%) show the correct window width. This shows up because it will cut off part of the banner on the right side, as well as wrap text that doesn't wrap in any other dpi mode.

I'm also seeing something similar happening with jp/ko languages as well, regardless of DPI, but not to en-us or zh-cn. In the language case, the window is much wider than the normal window. I'm not sure it's necessarily related to the 125% mode issue, but it may be due to a similar mechanism.

Anders · 15th August 2018, 10:36

Again, you are not telling me your Windows version.

The pixel size depends on the font because dialog units are based on the font. On Windows 10, some far east fonts are no longer installed by default and that might mess things up so make sure the font listed in the .nlf language file is actually installed. (Installing the keyboard layout and/or UI language should fix it IIRC)

Hugh · 16th August 2018, 01:10

For the 125% DPI problem, the Windows versions I have seen this on are Windows 7, 8.1, 10, and Server 2008 R2 non-exhaustive.

For the language issues, I've been testing with localized Windows 7 installations, but I believe I have seen them across a similar range at some point or another. So the takeaway here is to ensure that the font specified in the .nlf language files exist on the system first for localized installations...I will check on that, thanks.

Anders · 16th August 2018, 09:49

The font issue only exists on Windows 10 (and 95/NT4 if you care about those).

I believe 120 dpi used to be known as Large Fonts in Windows and might have some weird compatibility hacks, not sure.

SyneRyder · 27th August 2021, 08:51

Sorry to revive an ancient thread, but I was struggling with getting the SysCompImg DLL to work, and hopefully this might help others. I'm using NSIS v3.06.1, MUI (and not MUI2, if it matters), and to get the DLL to work I had to call it using a custom function before the components page on dialog show via MUI_PAGE_CUSTOMFUNCTION_SHOW, eg:

!define MUI_PAGE_CUSTOMFUNCTION_SHOW ShowHiDpiComponents
!define MUI_PAGE_CUSTOMFUNCTION_PRE SetupComponents
!insertmacro MUI_PAGE_COMPONENTS

Function ShowHiDpiComponents
SysCompImg::SetThemed
FunctionEnd

Function SetupComponents
# Do my other pre-page code here
FunctionEnd

I'd been trying to call the DLL from the MUI_PAGE_CUSTOMFUNCTION_PRE function, and that just doesn't work.

I'd feel slightly happier if the source for SysCompImg was available somewhere too, but for now I'm happy to finally have HiDPI checkboxes in my installer!

rgreen · 19th June 2022, 16:09

MUI2

A problem exists in uninstallers.

SysCompImg.dll detects 144 dpi, if you set the DPI-aware declaration in ManifestDPIAware to 'true', correctly.

This is on a 4K monitor (with a 150% scale-factor for fonts and such).

It works for the installer but not for the uninstaller.

Maybe it's my mistake. I tried also "ManifestDPIAware true" in the uninstaller script, but the default (that can't be changed?) is false.

I can tell that Windows system does the scaling. And it should not.

The installer spawns the uninstaller. It looks hacky when the installer is 144 dpi 'not blurred' and the uninstaller is 96 dpi 'blurred'.

Note, I assume that 96 dpi is what happens when "ManifestDPIAware false" is set. Just I don't set it to that.

Anders · 19th June 2022, 21:38

Quote:

Originally Posted by rgreen

It works for the installer but not for the uninstaller.

Maybe it's my mistake. I tried also "ManifestDPIAware true" in the uninstaller script, but the default (that can't be changed?) is false.

ManifestDPIAware is supposed to apply to both. What do you mean by "uninstaller script"?

Are you using !uninstfinalize to sign the uninstaller?

There might be some Windows caching going on if you previously had an older version without ManifestDPIAware?

You can download Resource Hacker (or Manifestview) and inspect the manifest of the uninstaller, it should have <dpiAware xmlns="...">true</dpiAware> in there somewhere.

It works correctly for me on Windows 10.

rgreen · 19th June 2022, 22:11

Thanks.
I viewed the manifest in ResourceHacker. It looks ok.

PHP Code:


			
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware></windowsSettings></application>

No to !uninstfinalize.

"ManifestDPIAware true" in the installer had been present before. I did not add it to the uninstaller script, which is a separate *.nsh, until now. I pasted this mesagebox into "\NSIS\Contrib\Modern UI 2\Interface.nsh". It runs before anything else has a chance:

PHP Code:


			
MessageBox mb_ok SysDpi=$0



Installer = 144

Uninstaller = 96

The spawned instance of the uninstall binary and the regular click-and-run instance return 96 and graphics are blurred by Windows DWM.

Works on Window 10, not 11!

Anders · 19th June 2022, 23:37

You can try adding ManifestDPIAwareness "System" as well but that should not really make a difference.

I don't have Windows 11 to test on.

rgreen · 20th June 2022, 00:19

'system' appears similar to 'true', I think.

The question is whether to use DPI-awareness. Hugh (above) mentioned a quirk of Windows at 120 dpi. The width is more narrow. It opens a whole new can of worms.

If you have header Bmps with fixed proportions for 96, 120, 144, 192, should you stretch the 96 dpi image to 119 and the 120 dpi image to 143?

===

Do we know or can you guess if the uninstaller problem is an 11 bug, or more likely my Windows 11?

Anders · 20th June 2022, 00:40

Quote:

Originally Posted by rgreen

'system' appears similar to 'true', I think.

Yes but it uses the newer manifest element.

For anyone not using custom pages you can do:

PHP Code:


			
ManifestDPIAware True

ManifestDPIAwareness "PerMonitorV2,System"

but it does not work correctly on secondary monitors with a different DPI for custom pages. I have even seen unexplainable issues on the license page. The specifics of per-monitor DPI dialog automatic layout has still not been explained by Microsoft AFAIK.

Quote:

Originally Posted by rgreen

The question is whether to use DPI-awareness. Hugh (above) mentioned a quirk of Windows at 120 dpi. The width is more narrow. It opens a whole new can of worms.

If you have header Bmps with fixed proportions for 96, 120, 144, 192, should you stretch the 96 dpi image to 119 and the 120 dpi image to 143?

Do we know or can you guess if the uninstaller problem is an 11 bug, or more likely my Windows 11?

Don't know and don't know. Seeing as it works on 10 and we are using the correct documented manifest elements it does smell like a 11 bug but I don't really understand why it would only affect the uninstaller.

rgreen · 20th June 2022, 01:37

Very possibly I am using custom pages on a system with one monitor. I'd make two observations, I did not notice distortion of controls at 96, 120 and 144 dpi with "ManifestDPIAware True/System/False". Adding `"ManifestDPIAwareness "PerMonitorV2,System"` did not unfortunately fix the uninstaller.

In the beginning I thought it was a security restriction. The uninstaller is created on the user's computer that would void my original manifest.

Maybe we'll never know. Thanks anyway.

Anders · 20th June 2022, 02:05

Regarding "ManifestDPIAware True/System/False", System and True are the exact same thing. At first only true existed, then when per-monitor became a thing in 8.1 the terminology used by Microsoft changed. System means aware of the DPI on the primary monitor, blurry on others if they have a different DPI.

False should have the same effect as not setting this attribute at all (I say should as setting it adds false to the manifest and not setting it at all does nothing to the manifest).

Ignoring the manifest, you could try

PHP Code:


			
Function un.onInit

System::Call 'SHCORE::SetProcessDpiAwareness(i1)'

FunctionEnd

rgreen · 20th June 2022, 02:28

If the manifest says 'false', the attribute is redundant if also false. Hmm, ok.

I'm not sure what having no manifest does. In the unlikely event that removing the manifest entirely fixes the uninstaller, it means it's a bug.

Is there a way to programmatically disable manifest creation in the uninstaller? Removing it by force in ResourceHacker from the file breaks the uninstaller. On second thought, I wouldn't take it out. It must be right to have a manifest.

Anders · 20th June 2022, 02:48

The dpi manifest attribute was invented in Vista. No attribute is "XP mode".

As a test you can remove it with ResHacker but you need to run it with /NCRC to get passed the startup check. You can try the System::Call thing, just remove ManifestDPIAware.

For no manifest at all you need RequestExecutionLevel none and XPStyle off at the bottom of your .nsi (and no Manifest lines (doh)).

rgreen · 20th June 2022, 03:53

Removing ManifestDPIAware from the script as you pointed out is the same as 'false'.

I can play with manifests. I got a code off a NSIS forum thread many years ago that allows you to manually configure manifests. So far it hasn't resolved the uninstaller issue:

PHP Code:


			
!define MANIFEST

!ifdef MANIFEST

  !define ResHacker "${ABSDIR}\Resource Hacker\ResourceHacker.exe" ; external tool

  !tempfile tmpexe

  !tempfile tmpmanifest

  !define level "none" ; = 'RequestExecutionLevel user'

  !define build ${NSIS_VERSION}

  !appendfile ${tmpmanifest} '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">\

<assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Nullsoft.NSIS.exehead" type="win32"/>\

<description>Nullsoft Install System "${build}"</description>\

<dependency><dependentAssembly>\

<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" \

processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>\

</dependentAssembly></dependency>\

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">\

<security><requestedPrivileges><requestedExecutionLevel level="${level}" uiAccess="false"/></requestedPrivileges></security>\

</trustInfo>\

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application>\

<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>\

<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>\

<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>\

<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>\

<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>\

</application></compatibility>\

</assembly>'

  !packhdr "${tmpexe}" '"${ResHacker}" -addoverwrite "${tmpexe}", "${tmpexe}", "${tmpmanifest}", 24, 1, 1033'

  !delfile "${tmpexe}"

!endif

I took out the dpi-aware lines:

PHP Code:


			
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings>\

<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>\

</windowsSettings></application>\

But, ...

The removed lines appear to be hard-coded. The (un)installers retain the original more or less apart from an added OS, and include that which I removed:

PHP Code:


			
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware></windowsSettings></application>

Here is the whole manifest, virtually identical to the default NSIS manifest:

PHP Code:


			
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1"

          manifestVersion="1.0">

    <assemblyIdentity version="1.0.0.0"

                      processorArchitecture="*"

                      name="Nullsoft.NSIS.exehead"

                      type="win32"/>

    <description>Nullsoft Install System v3.08</description>

    <dependency>

        <dependentAssembly>

            <assemblyIdentity type="win32"

                              name="Microsoft.Windows.Common-Controls"

                              version="6.0.0.0"

                              processorArchitecture="*"

                              publicKeyToken="6595b64144ccf1df"

                              language="*"/>

        </dependentAssembly>

    </dependency>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

        <security>

            <requestedPrivileges>

                <requestedExecutionLevel level="requireAdministrator"

                                         uiAccess="false"/>

            </requestedPrivileges>

        </security>

    </trustInfo>

    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">

        <application>

            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>

            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>

            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>

        </application>

    </compatibility>

    <application xmlns="urn:schemas-microsoft-com:asm.v3">

        <windowsSettings>

            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

        </windowsSettings>

    </application>

</assembly>

All that has changed is the executionLevel: asinvoker -> requireAdministrator

And one more OS.

And, ...

PHP Code:


			
Installer = 144

Uninstaller = 96

No change.

PHP Code:


			
    <application xmlns="urn:schemas-microsoft-com:asm.v3">

        <windowsSettings>

            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

        </windowsSettings>

    </application>

No change, despite my best efforts to remove the code manually.

Windows 10 works and Windows 11 is broken. I can live with that.

rgreen · 20th June 2022, 03:57

Here is the manifest I replaced manually:

PHP Code:


			
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1"

          manifestVersion="1.0">

    <assemblyIdentity version="1.0.0.0"

                      processorArchitecture="*"

                      name="Nullsoft.NSIS.exehead"

                      type="win32"/>

    <description>Nullsoft Install System v3.08</description>

    <dependency>

        <dependentAssembly>

            <assemblyIdentity type="win32"

                              name="Microsoft.Windows.Common-Controls"

                              version="6.0.0.0"

                              processorArchitecture="*"

                              publicKeyToken="6595b64144ccf1df"

                              language="*"/>

        </dependentAssembly>

    </dependency>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

        <security>

            <requestedPrivileges>

                <requestedExecutionLevel level="requireAdministrator"

                                         uiAccess="false"/>

            </requestedPrivileges>

        </security>

    </trustInfo>

    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">

        <application>

            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>

            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>

            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>

        </application>

    </compatibility>

    <application xmlns="urn:schemas-microsoft-com:asm.v3">

        <windowsSettings>

            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

        </windowsSettings>

    </application>

</assembly>

I couldn't expunge:

PHP Code:


			
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>

That seems to be hard-coded.

PHP Code:


			
Installer = 144

Uninstaller = 96

Windows 11. No change.

18th July 2017, 10:37	#1
mgrand Junior Member Join Date: Jul 2017 Posts: 8	NSIS on HiDPI displays Hello guys, With the growth of HiDPI monitors, I'd like to have my NSIS installer compatible and running to its full potential. As suggested by the documentation, I added code: ManifestDPIAware true to my script and it works well for most of the GUI. However, I'm running into 2 issues: - I provided welcome and header bitmaps at twice the recommended size, and it works on HiDPI displays. But on standard displays, the downsampling applied looks very cheap to me and I would prefer to provide separate bitmaps for each scale factor, is that possible? - The checkboxes used in components page are not rescaled on HiDPI (they appear very small). Is there a way to use native Windows checkboxes instead of bitmaps? Thanks for the help

18th July 2017, 11:25	#2
JasonFriday13 Major Dude Join Date: May 2005 Location: New Zealand Posts: 923	For the checkboxes, I had a quick look at the code and the image list seems to be hardcoded to 16x16. I guess if the scaled size of the treeview can be retrieved, then the check bitmap could be resized in memory and then applied to the treeview. This also depends on how old the OS is as to how well this would work. "Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me) NSIS 3 POSIX Ninja Wiki Profile

18th July 2017, 12:25	#3
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	I tried to create a "native" checkbox plug-in years ago but I never finished it because the theme API does not really support flat checkboxes IIRC. IntOp $PostCount $PostCount + 1

29th July 2017, 20:15	#5
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	There are some stretch options for the bitmap IIRC but it is never going to look great. You could have images of multiple sizes and extract in .onInit I guess. IntOp $PostCount $PostCount + 1

5th August 2017, 19:11	#8
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	I looked at what it takes to create this plug-in again and even before I get to the theme stuff I see that the classic DrawFrameControl function does not know how to draw read-only checkboxes so some post paint tweaking will be required. IntOp $PostCount $PostCount + 1

29th July 2017, 14:57	#4
mgrand Junior Member Join Date: Jul 2017 Posts: 8	It would be a nice addition to have flat checkboxes support. Looks like the only missing piece to a fully native-looking GUI. Any ideas about welcome & header bitmaps? What's the proper way to have those bitmaps compatible with HiDPI diplays?

3rd August 2017, 13:53	#7
mgrand Junior Member Join Date: Jul 2017 Posts: 8	Thanks! I will try that

6th August 2017, 14:32	#9
mgrand Junior Member Join Date: Jul 2017 Posts: 8	If anybody interested, here is the piece of code I used to show different bitmaps according to the DPI setting PHP Code: ManifestDPIAware true !define MUI_PAGE_CUSTOMFUNCTION_SHOW showHiDpi !insertmacro MUI_PAGE_WELCOME !insertmacro MUI_PAGE_LICENSE "Resource\license.rtf" !insertmacro MUI_PAGE_COMPONENTS !insertmacro MUI_PAGE_INSTFILES !define MUI_PAGE_CUSTOMFUNCTION_SHOW showHiDpi !insertmacro MUI_PAGE_FINISH Function .onInit File /oname=$PLUGINSDIR\welcome96.bmp Resource\welcome96.bmp File /oname=$PLUGINSDIR\welcome120.bmp Resource\welcome120.bmp File /oname=$PLUGINSDIR\welcome144.bmp Resource\welcome144.bmp File /oname=$PLUGINSDIR\welcome192.bmp Resource\welcome192.bmp File /oname=$PLUGINSDIR\header96.bmp Resource\header96.bmp File /oname=$PLUGINSDIR\header120.bmp Resource\header120.bmp File /oname=$PLUGINSDIR\header144.bmp Resource\header144.bmp File /oname=$PLUGINSDIR\header192.bmp Resource\header192.bmp FunctionEnd Function showHiDpi System::Call USER32::GetDpiForSystem()i.r0 ${If} $0 U<= 0 System::Call USER32::GetDC(i0)i.r1 System::Call GDI32::GetDeviceCaps(ir1,i88)i.r0 System::Call USER32::ReleaseDC(i0,ir1) ${EndIf} ${Unless} $0 == 120 ${AndUnless} $0 == 144 ${AndUnless} $0 == 192 StrCpy $0 96 ${EndIf} ${NSD_SetImage} $mui.WelcomePage.Image $PLUGINSDIR\welcome$0.bmp $mui.WelcomePage.Image.Bitmap ${NSD_SetImage} $mui.FinishPage.Image $PLUGINSDIR\welcome$0.bmp $mui.FinishPage.Image.Bitmap SetBrandingImage /IMGID=1046 "$PLUGINSDIR\header$0.bmp" FunctionEnd Also, it's important to note that HiDPI bitmaps size is not exactly the standard size multiplied by the scaling factor. Here are the values I used to fit perfectly (at least on Windows 10): Header bitmap: 96dpi: 150x57 120dpi: 175x70 144dpi: 225x83 192dpi: 300x109 Welcome/Finish bitmap: 96dpi: 164x314 120dpi: 191x386 144dpi: 245x458 192dpi: 327x603

6th August 2017, 14:57	#10
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	I would strongly recommend that you use the algorithm I posted, use >=, not == and pick the largest image you can fit. IntOp $PostCount $PostCount + 1

6th August 2017, 19:57	#13
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	It uses the DrawFrameControl API to draw on a custom imagelist. It is probably the same API used by the classic theme. IntOp $PostCount $PostCount + 1

9th August 2017, 20:36	#14
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	On the theme side of things, on Vista+ the TVS_EX_PARTIALCHECKBOXES style would be usable but TVS_EX_DIMMEDCHECKBOXES cannot be used for the read-only image so there is no way to get native flat themed checkboxes. Next step is to try to use the theme API to draw 3d checkboxes. IntOp $PostCount $PostCount + 1

16th August 2017, 11:02	#15
mgrand Junior Member Join Date: Jul 2017 Posts: 8	Thanks for investigating I'm not familiar with neither Windows API nor NSIS internal programming, but wouldn't it make more sense to use native checkbox controls instead, like nsDialogs?

26th August 2017, 10:06	#17
mgrand Junior Member Join Date: Jul 2017 Posts: 8	Awesome! The checkboxes now really look consistent with the rest of the GUI

11th September 2017, 18:15	#19
mgrand Junior Member Join Date: Jul 2017 Posts: 8	Really cool Will this be merged into NSIS?

11th September 2017, 23:10	#20
Nutzzz Member Join Date: May 2007 Location: Orange County, CA, U.S.A. Posts: 73	Yes, thanks for this, @Anders ! I've experimented with this a bit, and another issue is the scrollbars (for, e.g., the License Agreement) are very small.

12th September 2017, 12:39	#21
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	Windows is drawing the scrollbars, not us. There is EnableNonClientDpiScaling but I don't think we can use it. I will investigate PerMonitorAwareV2, we might be able to support that. IntOp $PostCount $PostCount + 1

11th August 2018, 00:20	#22
Hugh Junior Member Join Date: Apr 2016 Posts: 11	I've tried using both a normal-size and an over-sized banner bmp (2x) using the modern_headerbmp.exe UI, but unlike mgrand I'm not seeing it scale properly at HiDPI (ie. at 200% I would have expected to work with the 2x sized banner). It appears to maintain the exact pixel counts regardless of scale or the image being used, instead of percentage coverage, as if the size was pixel-fixed (possibly in the modern_headerbmp.exe resource?). I used ResourceHacker to check the control sizes in the exe, but I couldn't determine which control affects the banner (a full-width banner, unlike 1046 which appears to be a 100x35 image). ManifestDPIAware and ManifestSupportedOS have been set (true and all, respectively), which fixes the text scaling, but not the image. I've tried all the different settings with MUI_HEADERIMAGE_BITMAP_STRETCH to no avail. I've also attempted to use SetBrandingImage (as per https://stackoverflow.com/questions/...stallers-pages), along with using AddBrandingImage before calling SetBrandingImage to see if that changes the behaviour when using the oversized image, but I'm getting "no branding image found in chosen UI!" and I'm not sure that's the right way of solving this issue. Any ideas?

11th August 2018, 19:24	#23
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	Resources use dialog units, not pixels. The final pixel size is calculated by Windows at run-time and it is based on the font size (dialog unit) and DPI. More information would be nice. Windows version? Is the primary monitor 200% DPI? Logged out and back in after changing DPI? IntOp $PostCount $PostCount + 1

15th August 2018, 00:24	#24
Hugh Junior Member Join Date: Apr 2016 Posts: 11	After some further investigation, it looks like we're manually setting image sizes via SetWindowPos(), which would explain the issues, so this has been resolved. However, I noticed that the window size is slightly narrower in 120dpi mode (125%), while all other modes (100%, 150%, 200%) show the correct window width. This shows up because it will cut off part of the banner on the right side, as well as wrap text that doesn't wrap in any other dpi mode. I'm also seeing something similar happening with jp/ko languages as well, regardless of DPI, but not to en-us or zh-cn. In the language case, the window is much wider than the normal window. I'm not sure it's necessarily related to the 125% mode issue, but it may be due to a similar mechanism.

15th August 2018, 10:36	#25
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	Again, you are not telling me your Windows version. The pixel size depends on the font because dialog units are based on the font. On Windows 10, some far east fonts are no longer installed by default and that might mess things up so make sure the font listed in the .nlf language file is actually installed. (Installing the keyboard layout and/or UI language should fix it IIRC) IntOp $PostCount $PostCount + 1

16th August 2018, 01:10	#26
Hugh Junior Member Join Date: Apr 2016 Posts: 11	For the 125% DPI problem, the Windows versions I have seen this on are Windows 7, 8.1, 10, and Server 2008 R2 non-exhaustive. For the language issues, I've been testing with localized Windows 7 installations, but I believe I have seen them across a similar range at some point or another. So the takeaway here is to ensure that the font specified in the .nlf language files exist on the system first for localized installations...I will check on that, thanks.

16th August 2018, 09:49	#27
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	The font issue only exists on Windows 10 (and 95/NT4 if you care about those). I believe 120 dpi used to be known as Large Fonts in Windows and might have some weird compatibility hacks, not sure. IntOp $PostCount $PostCount + 1

27th August 2021, 08:51	#28
SyneRyder Junior Member Join Date: Aug 2021 Posts: 4	Sorry to revive an ancient thread, but I was struggling with getting the SysCompImg DLL to work, and hopefully this might help others. I'm using NSIS v3.06.1, MUI (and not MUI2, if it matters), and to get the DLL to work I had to call it using a custom function before the components page on dialog show via MUI_PAGE_CUSTOMFUNCTION_SHOW, eg: !define MUI_PAGE_CUSTOMFUNCTION_SHOW ShowHiDpiComponents !define MUI_PAGE_CUSTOMFUNCTION_PRE SetupComponents !insertmacro MUI_PAGE_COMPONENTS Function ShowHiDpiComponents SysCompImg::SetThemed FunctionEnd Function SetupComponents # Do my other pre-page code here FunctionEnd I'd been trying to call the DLL from the MUI_PAGE_CUSTOMFUNCTION_PRE function, and that just doesn't work. I'd feel slightly happier if the source for SysCompImg was available somewhere too, but for now I'm happy to finally have HiDPI checkboxes in my installer!

19th June 2022, 16:09	#29
rgreen Junior Member Join Date: Jun 2022 Posts: 29	MUI2 A problem exists in uninstallers. SysCompImg.dll detects 144 dpi, if you set the DPI-aware declaration in ManifestDPIAware to 'true', correctly. This is on a 4K monitor (with a 150% scale-factor for fonts and such). It works for the installer but not for the uninstaller. Maybe it's my mistake. I tried also "ManifestDPIAware true" in the uninstaller script, but the default (that can't be changed?) is false. I can tell that Windows system does the scaling. And it should not. The installer spawns the uninstaller. It looks hacky when the installer is 144 dpi 'not blurred' and the uninstaller is 96 dpi 'blurred'. Note, I assume that 96 dpi is what happens when "ManifestDPIAware false" is set. Just I don't set it to that.

19th June 2022, 22:11	#31
rgreen Junior Member Join Date: Jun 2022 Posts: 29	Thanks. I viewed the manifest in ResourceHacker. It looks ok. PHP Code: `<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware></windowsSettings></application>` No to !uninstfinalize. "ManifestDPIAware true" in the installer had been present before. I did not add it to the uninstaller script, which is a separate *.nsh, until now. I pasted this mesagebox into "\NSIS\Contrib\Modern UI 2\Interface.nsh". It runs before anything else has a chance: PHP Code: `MessageBox mb_ok SysDpi=$0 Installer = 144 Uninstaller = 96` The spawned instance of the uninstall binary and the regular click-and-run instance return 96 and graphics are blurred by Windows DWM. Works on Window 10, not 11!

19th June 2022, 23:37	#32
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	You can try adding ManifestDPIAwareness "System" as well but that should not really make a difference. I don't have Windows 11 to test on. IntOp $PostCount $PostCount + 1

20th June 2022, 00:19	#33
rgreen Junior Member Join Date: Jun 2022 Posts: 29	'system' appears similar to 'true', I think. The question is whether to use DPI-awareness. Hugh (above) mentioned a quirk of Windows at 120 dpi. The width is more narrow. It opens a whole new can of worms. If you have header Bmps with fixed proportions for 96, 120, 144, 192, should you stretch the 96 dpi image to 119 and the 120 dpi image to 143? === Do we know or can you guess if the uninstaller problem is an 11 bug, or more likely my Windows 11?

20th June 2022, 01:37	#35
rgreen Junior Member Join Date: Jun 2022 Posts: 29	Very possibly I am using custom pages on a system with one monitor. I'd make two observations, I did not notice distortion of controls at 96, 120 and 144 dpi with "ManifestDPIAware True/System/False". Adding `"ManifestDPIAwareness "PerMonitorV2,System"` did not unfortunately fix the uninstaller. In the beginning I thought it was a security restriction. The uninstaller is created on the user's computer that would void my original manifest. Maybe we'll never know. Thanks anyway.

20th June 2022, 02:05	#36
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	Regarding "ManifestDPIAware True/System/False", System and True are the exact same thing. At first only true existed, then when per-monitor became a thing in 8.1 the terminology used by Microsoft changed. System means aware of the DPI on the primary monitor, blurry on others if they have a different DPI. False should have the same effect as not setting this attribute at all (I say should as setting it adds false to the manifest and not setting it at all does nothing to the manifest). Ignoring the manifest, you could try PHP Code: `Function un.onInit System::Call 'SHCORE::SetProcessDpiAwareness(i1)' FunctionEnd` IntOp $PostCount $PostCount + 1

20th June 2022, 02:28	#37
rgreen Junior Member Join Date: Jun 2022 Posts: 29	If the manifest says 'false', the attribute is redundant if also false. Hmm, ok. I'm not sure what having no manifest does. In the unlikely event that removing the manifest entirely fixes the uninstaller, it means it's a bug. Is there a way to programmatically disable manifest creation in the uninstaller? Removing it by force in ResourceHacker from the file breaks the uninstaller. On second thought, I wouldn't take it out. It must be right to have a manifest.

20th June 2022, 02:48	#38
Anders Moderator Join Date: Jun 2002 Location: ${NSISDIR} Posts: 5,548	The dpi manifest attribute was invented in Vista. No attribute is "XP mode". As a test you can remove it with ResHacker but you need to run it with /NCRC to get passed the startup check. You can try the System::Call thing, just remove ManifestDPIAware. For no manifest at all you need RequestExecutionLevel none and XPStyle off at the bottom of your .nsi (and no Manifest lines (doh)). IntOp $PostCount $PostCount + 1

20th June 2022, 03:53	#39
rgreen Junior Member Join Date: Jun 2022 Posts: 29	Removing ManifestDPIAware from the script as you pointed out is the same as 'false'. I can play with manifests. I got a code off a NSIS forum thread many years ago that allows you to manually configure manifests. So far it hasn't resolved the uninstaller issue: PHP Code: !define MANIFEST !ifdef MANIFEST !define ResHacker "${ABSDIR}\Resource Hacker\ResourceHacker.exe" ; external tool !tempfile tmpexe !tempfile tmpmanifest !define level "none" ; = 'RequestExecutionLevel user' !define build ${NSIS_VERSION} !appendfile ${tmpmanifest} '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\ <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">\ <assemblyIdentity version="1.0.0.0" processorArchitecture="" name="Nullsoft.NSIS.exehead" type="win32"/>\ <description>Nullsoft Install System "${build}"</description>\ <dependency><dependentAssembly>\ <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" \ processorArchitecture="" publicKeyToken="6595b64144ccf1df" language=""/>\ </dependentAssembly></dependency>\ <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">\ <security><requestedPrivileges><requestedExecutionLevel level="${level}" uiAccess="false"/></requestedPrivileges></security>\ </trustInfo>\ <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application>\ <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>\ <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>\ <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>\ <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>\ <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>\ </application></compatibility>\ </assembly>' !packhdr "${tmpexe}" '"${ResHacker}" -addoverwrite "${tmpexe}", "${tmpexe}", "${tmpmanifest}", 24, 1, 1033' !delfile "${tmpexe}" !endif I took out the dpi-aware lines: PHP Code: `<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings>\ <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>\ </windowsSettings></application>\` But, ... The removed lines appear to be hard-coded. The (un)installers retain the original more or less apart from an added OS, and include that which I removed: PHP Code: `<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware></windowsSettings></application>` Here is the whole manifest, virtually identical to the default NSIS manifest: PHP Code: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="" name="Nullsoft.NSIS.exehead" type="win32"/> <description>Nullsoft Install System v3.08</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="" publicKeyToken="6595b64144ccf1df" language=""/> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> </application> </compatibility> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware> </windowsSettings> </application> </assembly> All that has changed is the executionLevel: asinvoker -> requireAdministrator And one more OS. And, ... PHP Code: `Installer = 144 Uninstaller = 96` No change. PHP Code: `<application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware> </windowsSettings> </application>` No change, despite my best efforts to remove the code manually. Windows 10 works and Windows 11 is broken. I can live with that.

20th June 2022, 03:57	#40
rgreen Junior Member Join Date: Jun 2022 Posts: 29	Here is the manifest I replaced manually: PHP Code: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="" name="Nullsoft.NSIS.exehead" type="win32"/> <description>Nullsoft Install System v3.08</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="" publicKeyToken="6595b64144ccf1df" language="*"/> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> </application> </compatibility> <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware> </windowsSettings> </application> </assembly> I couldn't expunge: PHP Code: `<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>` That seems to be hard-coded. PHP Code: `Installer = 144 Uninstaller = 96` Windows 11. No change.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode