On 7/5/2024 9:59 PM, sticks wrote:
I have always found the split screen feature helpful and use it daily. Today, I noticed that the program Kindle for Windows seems to have a little difficulty only using half the monitor. This problem gets apparent if you have a book open and then
choose to see your highlights too. The Kindle windows gets bigger than half the screen and overlaps the other application. You can click on the 2nd app and it is fully visible as it should be on it's half of the monitor, with part of the Kindle now
covered. It's not how I've seen any other two programs operate using the split screen. I wonder why this is?
A Metro.App has "snap" capabilities or such.
Some sort of deal where it takes half a screen.
A Win32 program (legacy EXE) may not share this property.
The graphics rendering is done a different way.
Both types can be composited in the display manager (Z-azis viewing priority, sometimes).
The Metro.App is likely using webview or something. There is
some interface layer for the window it draws, which isn't
quite the same as before. This could also account for a certain
generation of Metro.App not being able to run on Windows 7.
A UWP might run on Win7 and Win10, but it specifically has
to be written for Win7 and there is some sort of indicator
in a manifest that it supports this. Just because something is
a UWP, doesn't mean it has to run on Win7. It has to be a "UWP for Win7"
to run on Win7.
You can see how using tools, it's difficult to tell once a thing is
running, what it is.
And when something hides inside a folder for which you have
no access (WindowsApp), then you are doubly flummoxed.
"Programs" have a multitude of places they can hide. You'd be
surprised where they end up. "Nothing up my sleeve": Bullwinkle.
If you're leet, you'll have no problem figuring it out,
at least that is what the MSFT Devs claim. "We don't need stenkin labels".
This is why the Memory Compressor (a system function), does not
appear in Task Manager, but *does* appear in Process Explorer.
Process Explorer gives you a second opportunity to collect information,
as in this picture:
[Picture]
https://i.postimg.cc/httG6Q1s/Guessing-at-program-type.gif
I did not specifically put Memory Compressor in that picture,
but it has the fewest labels of all, and this is why the
Task Manager may have decided not to list it.
Even if you told me it was "kindle.exe", that does not answer
the question. If you told me "kindle.exe 3,605,687 bytes" then
I would guess it is legacy Win32. If the file was
"kindle.exe 0 bytes" or "Kindle.exe 715 bytes" then we
would have our suspicions it was not win32 :-) There are
at least two conventions for manifested EXE Metro.App files.
They weren't happy with the older method, and you will find
variants, but the properties have not changed (the win32 loader
still cannot launch a manifested Metro.App). A shortcut to a
Metro.App refuses to carry command line parameters -- you cannot
edit the shortcut.
Is there a tutorial page on taxonomy at Microsoft ?
What do you think ?
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
