Windows Store/immersive apps: obtain product name and version via package functions if possible

[josephsl]

Hi,

Based on #7894 work:

Is your feature request related to a problem? Please describe.

App module class's product name and version descriptors are used to obtain name and version of the app associated with the app module class. However, there are cases when this does not work, particularly in regards to Windows Store apps (sometimes called "immersive apps"). For these, a container process is used, which causes file utils to say "invalid file version info".

The best known case is Windows 10 Calculator. Although the executable is unique (not wwahost.exe), product name and version cannot be fetched. Another example is Office 365 apps from Microsoft Store that not only presents a high-level version information (because these are converted desktop apps), but also comes with internal versions as seen through Store app package information (for example, 16.0 for desktop apps versus 16051 for Store apps).

Describe the solution you'd like

Detect and retrieve product name and version for immersive apps via package info functions from kernel32.dll (see #7894 for mechanics of this). If the app is not a hosted (immersive) app (such as on Windows 7 and many apps on Windows 8.x and 10), fall back to version info lookup.

Describe alternatives you've considered

None - leave it as is.

Additional context

Mostly useful for app module writers as they can easily detect versions for hosted apps in order to write workarounds. A proof of concept implementation is under active testing via Windows 10 App Essentials add-on.

Thanks.

[josephsl]

Hi,

Another case: Notepad in 20H1 build 18963 which is now a converted desktop app and will be updated via Microsoft Store.

Thanks.

[josephsl]

Hi,

After thinking about it, I am going to attempt the following solution:

1. Check which Windows release we're dealing with. Not only it makes the code run a bit faster on Windows 7 and avoid exceptions (see below), it allows us to drop support for Windows 7 easily once we progress to a point where this is unavoidable.
2. Try locating package full name by calling kernel32.dll::GetPackageFullName. If it returns 0, we're dealing with an immersive app, otherwise (error 15700), fall back to file version info method.
3. If this is an immersive app, parse the package full name structure.

Notes:

1. In order to fully implement this, the current file version info routine will become an inner function that returns a 2-tuple: product name, product version.
2. In terms of speed, although calling IsImmersiveProcess first may sound more intuitive, this will cause an exception to be thrown in Windows 7. This means both code paths (one with and one without this function) must be traversed in Windows 7. Therefore checking Windows release ensures NVDA will continue to call file version info routine as before without coming to package name parser.
3. Continuing from above, the only speed penalty is when dealing with native apps on Windows 8.x and 10. For these, both full package name (immersive process) and file version info (converted desktop or native apps) must be checked. Compounding the issue is that some apps are flagged wrong - File Explorer reports itself as "immersive" when in fact it is a native app, and Office 365 executables from Microsoft Store have their own internal version numbers even though they are not true immersive apps.

Thanks.

[josephsl]

Hi,

Update: #4259 falls under this category although it is specific to WWAHost - the same approach used in #10114 will also resolve that one too, and is under active testing via Windows 10 App Essentials.

Thanks.