On 2026-02-14 02:58, Corinna Vinschen wrote:
[CCing Thomas]
On Feb 13 17:36, Brian Inglis wrote:
On 2026-01-26 04:13, Corinna Vinschen wrote:
From: Corinna Vinschen <[email protected]>
Perform the check only if we're the root process of a Cygwin process
tree. If we start mintty from Cygwin, the PCA trigger doesn't occur.
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 1d5a452b4fbc..e080aa41bca2 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -253,6 +253,17 @@ frok::parent (volatile char * volatile stack_here)
systems. */
c_flags |= CREATE_UNICODE_ENVIRONMENT;
+ /* Despite all our executables having a valid manifest, "mintty" still
+ triggers the "Program Compatibility Assistant (PCA) Service" for
+ some reason, maybe due to some heuristics in PCA.
All makes sense and looks reasonable to a non-Windows type!
There are no differences between the windows or either mingw64 default
manifests, but mintty has extra, after tweaking its order and layout to
match, so perhaps something there needs updated in GH:
$ diff res.mft default-manifest.mft
--- res.mft 2026-02-13 17:21:21.491931500 -0700
+++ default-manifest.mft 2026-02-13 17:18:08.759527200 -0700
@@ -3,40 +3,22 @@
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
- <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
+ <requestedExecutionLevel level="asInvoker"/>
</requestedPrivileges>
</security>
</trustInfo>
--
- <dependency>
- <dependentAssembly>
- <assemblyIdentity
- type="win32"
- name="Microsoft.Windows.Common-Controls"
- version="6.0.0.0"
- publicKeyToken="6595b64144ccf1df"
- language="*"
- processorArchitecture="*"
- />
- </dependentAssembly>
- </dependency>
- <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
- <asmv3:windowsSettings>
- <dpiAware
xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings";>true</dpiAware>
- <dpiAwareness
xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings";>PerMonitorV2</dpiAwareness>
- </asmv3:windowsSettings>
- </asmv3:application>
</assembly>
But the mintty manifest looks correct. Compared to the default mainfest,
it just tells the OS that it's a GUI process and that it's DPI aware.
Maybe the older dpiAware could be set to "true/pm", but I can't judge
that, actually.
The rest of the manifest claims compatibility with all Windows versions
since Vista up to Windows 10/11, as usual. So it's no surprise that
task manager prints no downgraded OS compatibility context for mintty.
But then again, why on earth is mintty running in PCA job at all?!?
iIt would be great if we could get rid of this code in Cygwin.
OTOH, what keeps the PCA heuristics to change the rules with every
OS release?
Cygwin seems to have no mintty repos available!
Perhaps GH mintty/mintty should be mirrored on sourceware?
All but a few projects in the distro are not on sware. As long as
it's OSS and the sources can be found on a public repo, all is well,
isn't it?
Some maintainers and others will not touch GH, so have no access to those
upstreams, except via package sources, unlike most other apps and packages,
where I first looked for a mintty repo.
I know Thomas is working on getting mintty to a point where it can be built with
cygport in CI, like cygwin et al.
Wouldn't we all be happier if main CI was not on MS GH, and sourceware could
host some Windows build environment(s)?
I have asked the question, but other than responses saying that would be a good
idea, I am unsure if anyone knows what the policies are about hosting and
supporting commercially licensed software, and if there would be any capability
or technical support available?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
