DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 906D7385E003
Message-ID: <b3fde2b3-49e4-429f-9134-26076b1c909c@dronecode.org.uk>
Date: Sun, 21 Jul 2024 16:53:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: setup.exe: Improvements of DPI handling
To: Yang Yu Lin <yylofficial@hotmail.com>
References: <CY8PR10MB6562B602DC0709BA00E404F5A2D92@CY8PR10MB6562.namprd10.prod.outlook.com>
Content-Language: en-US
Cc: cygwin@cygwin.com
In-Reply-To: <CY8PR10MB6562B602DC0709BA00E404F5A2D92@CY8PR10MB6562.namprd10.prod.outlook.com>
Precedence: list
From: Jon Turney via Cygwin <cygwin@cygwin.com>
Reply-To: Jon Turney <jon.turney@dronecode.org.uk>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On 07/07/2024 03:46, Yang Yu Lin via Cygwin wrote:
> When running setup on my device (Windows 11, connected with 2 screens
> which use different DPI revolutions), the setup appears bluury on my
> secondary screen (not on the primary screen).
> 
> Because current setup.exe.manifest just set the dpiAware element,
> which causes the setup cannot handle different DPI on different
> screen, the current solution is to add dpiAwareness element and
> change the value of dpiAware to true/pm to handle DPI in per-moniter
> mode (patch attached). More infomation can be found at
> https://learn.microsoft.com/windows/win32/sbscs/application-manifests#dpiAware
> and
> https://learn.microsoft.com/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows<https://learn.microsoft.com/zh-cn/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows>

Yes, this is clearly needed. Thanks very much for the patch, I have 
applied it.

>  Also, the necessary options to use the Unicode version of the
> Windows API functions is also added in another patch to avoid
> localized message is incorrectly encoded when using the --lang
> option.

Uh, can you explain a bit more what specific problem this fixes.

Because we don't make use of TCHAR, and internally make a lot of use of 
char strings containing UTF-8 encoded unicode, I'm not sure that 
switching to *W API variants everywhere is a good idea (and have been 
trying to avoid it so far).


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple