Comment SHLoadIndirectString() fonctionne-t-il en interne?

Question

J'ai essayé d'obtenir des noms d'affichage (nom convivial d'une application) de toutes les applications UWP installées sur un système à partir d'une application de bureau. J'essaye d'employer SHLoadIndirectString() sur la chaîne de ressource obtenue de l'entrée de registre correspondant à ces apps. Prenons le cas de la calculatrice Windows.

SHLoadIndirectString() Utilisation

Il est chaîne de ressource peut être obtenue à partir HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\‌​Repository\Packages\‌​Microsoft.WindowsCal‌​culator_10.1705.1301‌​.0_x64__8wekyb3d8bbw‌​e\DisplayName entrée de Registre. La chaîne de ressources sur mon système pour cela est @{Microsoft.WindowsCalculator_10.1705.1301.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.WindowsCalculator/Resources/AppStoreName}

Pour obtenir le nom d'affichage, je voudrais faire SHLoadIndirectString(@{Microsoft.WindowsCalculator_10.1705.1301.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.WindowsCalculator/Resources/AppStoreName}).

observation expérimentale

1. (Experiment 1) I utilisé SHLoadIndirectString() pour deux utilisateurs différents (U1, U2 et). La langue de U1 était l'anglais, la langue de U2 était le français (FR-fr). Lorsque SHLoadIndirectString() a été exécuté à partir de U1, il a retourné Windows Calculator, et pour U2 j'ai obtenu Calculatrice Windows. Ainsi, la valeur renvoyée pour la même chaîne de ressources dépend du paramètre de langue de l'utilisateur actuel.
2. (Expérience 2) J'ai installé une application UWP U2, et a fait SHLoadIndirectString() à la chaîne de ressources dans DiplayName. J'ai eu une erreur dans U1, mais dans U2, cela m'a donné la chaîne requise correctement.
3. (Expérience 3) Quand j'ajouté chemin vers le fichier de ressources (resources.pri), à la chaîne des ressources, je me suis pas d'erreur dans U1. La chaîne de ressources antérieure était @{DJiT.edjing-DJmixerconsolestudio-PlayMixRecordShar_5.1.12.0_x64__3nf5xjt6s13jt?ms-resource://DJiT.edjing-DJmixerconsolestudio-PlayMixRecordShar/Resources/AppName}, que j'ai ensuite modifiée en @{C:\\Program Files\\WindowsApps\\DJiT.edjing-DJmixerconsolestudio-PlayMixRecordShar_5.1.12.0_x64__3nf5xjt6s13jt\\resources.pri?ms-resource://DJiT.edjing-DJmixerconsolestudio-PlayMixRecordShar/Resources/AppName} avant de passer à SHLoadIndirectString().

Trouver des solutions

1. SHLoadIndirectString()'s documentation dit que sa valeur retournée dépend de Shell environment or ResourceContext, sans donner beaucoup de détails pour chacun.

2. Deux projets qui tentent de créer Windows NT API pour exécuter des applications Windows sont ReactOS et wine. J'ai regardé à travers leur code source pour trouver l'implémentation de SHLoadIndirectString(), mais tout ce que les codes semblent faire est de faire un LoadLibrary() sur la chaîne de ressource, après avoir enlevé le symbole @ au début. Cela n'a aucun sens, pourquoi y aurait-il un tel DLL dans un système, car la chaîne de ressources pour chaque application est différente?

   • SHLoadIndirectString() implementation in ReactOS
   • SHLoadIndirectString() implementation in wine

Answer 1

de Windows XP vers Windows 7 SHLoadIndirectString uniquement utilisé LoadLibrary avec la syntaxe @filename.dll,resource documentée sur MSDN.L'entrée MUIVerb pour les enregistrements de type de fichier est peut-être l'utilisation la plus courante dans la nature.

Dans Windows 8, il a été étendu pour prendre en charge d'autres sources, en particulier les fichiers .PRI (Package Resource Index) utilisés par les applications WinRT/Modern/Store. Pour savoir exactement comment cela fonctionne, vous pouvez le faire dans un débogueur, mais ces détails d'implémentation ne sont pas quelque chose dont vous devriez dépendre, vous devriez seulement utiliser l'API documentée.

Sur Windows 8, il utilise diverses fonctions dans MrmCoreR.dll (mrmcorer!Microsoft::Resources::Runtime::CResource*) pour extraire le nom du package, il construit un chemin avec KERNEL32!PackageIdFromFullName + KERNEL32!GetPackagePath + "\resources.pri" puis il appelle Bcp47Langs!Windows::Internal::CLanguagesListFactory::GetUserLanguages pour obtenir une liste des langues préférées. Il crée ensuite une chaîne à partir du chemin (il convertit \ en %5) afin qu'il puisse vérifier si la chaîne de ressources est mise en cache sous HKCU\Software\Classes\Local Settings\MrtCache. Sinon, il lit la chaîne avec le gestionnaire de ressources. Les détails exacts du fonctionnement d'une ResourceContext (langue, échelle DPI, etc.) et la façon dont elle trouve la source véritable du fichier .pri sont probablement hors de portée pour cette question et un sujet beaucoup plus vaste en soi.