Jump to content

IsRunningAsUwp() detection for AutoIt Apps published via the Windows Bridge to UWP as MSIX/APPX for the Windows Store - (Moved)

Recommended Posts

I am looking to code IsRunningAsUwp() detection for AutoIt Apps published via the Windows Bridge to UWP borrowing from code here in C#: DesktopBridgeHelpers/Helpers.cs at master · qmatteoq/DesktopBridgeHelpers · GitHub More info also here: GetCurrentPackageFullName function (appmodel.h) - Win32 apps | Microsoft Docs

The P/Invoke equivalent looks to be a pain in AutoIt and I am sure that DllStructCreate|GetData|GetPtr etc are required so if anyone one else finds this of interest and useful to them they are most welcome to contribute: I hacked a workaround as IsRunningAsUwp() (I think its only the "\VFS\" that matches!) whereas IsRunningAsUwpToDo() is to be fixed and coded up properly using DLLStruct functions as I mentioned and I figure that there will be a Guru around here with this stuff as I have also heard that the AutoIt Devs are planning a move to UWP and the below is going to be pretty fundamental (at least until then although similar will likely wind up in the libraries eventually anyways..). 

OutputDebugString() is here:


Func OutputDebugString($lpOutputString)
    DllCall("kernel32.dll", "NONE", "OutputDebugString", "STR", $lpOutputString)

The script to be fixed is here: 

#Include <OutputDebugString.au3>


Func IsRunningAsUwp()
    If IsWindows7OrLower Then
        Return False
    Return StringinStr(@ScriptDir, "\WindowsApps\") > 0 Or StringInStr(@ScriptDir, "\VFS\") > 0

Func IsRunningAsUwpToDo()
    If IsWindows7OrLower Then
        Return False
    Local $packageFullNameLength = 0;
    Local $packageFullName[$packageFullNameLength];
    Local $result = DllCall("kernel32.dll", "LONG", "GetCurrentPackageFullName", "UINT32*", $packageFullNameLength, "PWSTR", $packageFullName)
    OutputDebugString("$result=" & String($result))
    OutputDebugString("packageFullNameLength=" & String($packageFullNameLength))
    OutputDebugString("packageFullName=" & String($packageFullName))
    Local $packageFullName[$packageFullNameLength];
    Local $result = DllCall("kernel32.dll", "LONG", "GetCurrentPackageFullName", "UINT32*", $packageFullNameLength, "PWSTR", $packageFullName)
    OutputDebugString("$result=" & String($result))
    OutputDebugString("packageFullNameLength=" & String($packageFullNameLength))
    OutputDebugString("packageFullName=" & String($packageFullName))
    Return $result <> $APPMODEL_ERROR_NO_PACKAGE And $packageFullNameLength > 0

Func IsWindows7OrLower()
    Local $objWMIService = ObjGet("winmgmts:\\localhost\root\CIMV2")
    Local $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem", "WQL", 0x30)
    If IsObj($colItems) Then
        For $objItem In $colItems
            Local $version = $objItem.Version
            OutputDebugString("Win32_OperatingSystem.Version=" & $version)
            Return Number($version) <= 6.1
        Msgbox(0, "", "No WMI Object for Version found in WMI Class Win32_OperatingSystem")
    Return False

Kindest Regards, Matthew 

Link to post
Share on other sites

You should read AutoIt's dllcall reference doc.

I think this may work:

Local $aCall = DllCall("kernel32.dll", "LONG", "GetCurrentPackageFullName", "uint*", 0, "wstr", Null)
Local $iRequiredSize = $aCall[1]
Local $tPackageName=DllStructCreate("wchar Data[" & $iRequiredSize & "]")
Local $aCall = DllCall("kernel32.dll", "LONG", "GetCurrentPackageFullName", "uint", $iRequiredSize, "ptr", DllStructGetPtr($tPackageName))
Local $sPackageName=$tPackageName.Data

;or maybe
Local $aCall = DllCall("kernel32.dll", "LONG", "GetCurrentPackageFullName", "uint", 1024, "wstr*", Null)
Local $sPackageName=$aCall[1]




Link to post
Share on other sites

Not quite:

Syntax/Runtime Errors on:

Local $iRequiredSize = $aCall[1]
Local $iRequiredSize = $aCall^ ERROR

Fixed the Error on:

Local $sPackageName = $tPackageName.Data
Local $sPackageName = $tPackageName^ ERROR


Local $sPackageName = DllStructGetData($tPackageName, "Data")

Link to post
Share on other sites
Posted (edited)

Perhaps the return value itself is a DllStruct?

Pretty sure I tried it without the subscript to no avail but I will look again. Its a bugger because I have to update and redeploy the app each time by hand to test. And another reason for reaching out..

Decided I am going to use a UWP Launcher (as I need UWP AutoStart: Grrr!) but even that is a pain as you cannot pass regular command line arguments to the Win32 AutoIt App so would still like the internal routine and for security as well. Amazing how complicated .NET and Windows et al Frameworks are becoming..

Ah maybe I could compile and call a small exe built from the original C# from the command line (that exit code or stdout string I can get!) and be done with (Auto)it but without having to port the rest of the App for which it is just fine (no systray in UWP eeither 2nd Grrr!). This is like cryptic VB syntax to me anyways and is very painful in comparison to C#.. Although my earlier hack works OK its just a hack and I am compelled to fix it.

Another option: the original C# as a DLL with the simple integer return code of 0 or 1: that'll do it as well as I can get that DllCall working. I am thinking that Autoit like VB is a language just written to maximize forum questions and answers and the usage of same haha! If AutoIt was so brilliant and easy (like C# P/Invokes) then someone would have answered me back with a fully working answer wouldn't they HAHA! 😉

Nah: I am already Run-ing and ShellExecute-ing several other exes from my AutoIt systray app and which really do all of the work so I can call another one.. IsRunningAsUwp.exe in C# is a cleaner hack!

Edited by matthewjs
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Danyfirex
      Hello guys.  I recently saw some posts that Windows 10 provides OCR API. So I decided to create a UDF.
      What's UWPOCR?
      UWPOCR UDF is a simple library to use Universal Windows Platform Optical character recognition API.
      Get Text From Image File. Get Text From GDI+ Bitmap. Easy to use.  Usage:
      #include "..\UWPOCR.au3" _Example() Func _Example() Local $sOCRTextResult = _UWPOCR_GetText(FileOpenDialog("Select Image", @ScriptDir & "\", "Images (*.jpg;*.bmp;*.png;*.tif;*.gif)")) MsgBox(0,"",$sOCRTextResult) EndFunc Get Words Rect(Example):

      More examples here.
      Check UWPOCR UDF on GitHub.
    • By Jibberish
      Hello all,
      I searched the forums for UWP but got nothing helpful. Our team is going to move from our current code to UWP and rebuild our app.  I use AutoIt to automate long boring tests.
      Does anyone know how AutoIt plays with UWP programs?
    • By Jon
      I'm writing some build scripts for a Windows 10 build. One thing I want to do is optimise the build for a business desktop. And that means removing all the "toy" Windows Store apps that are reinstalled every time a new user is logged on. Zune Music - I'm looking at you. AppX packages are staged or provisioned in the Windows 10 image, and also installed per user as required. The PowerShell CmdLets are named Get-AppXProvisionedPackage and Get-AppXPackage respectively.
      To get a list of packages installed for the current user we run:
      Get-AppxPackage | Format-Wide -Property NameHere is the list returned by Windows 10 Enterprise:
      Microsoft.VCLibs.140.00 Microsoft.VCLibs.140.00 Microsoft.NET.Native.Framework.1.0 Microsoft.NET.Native.Framework.1.0 Microsoft.NET.Native.Runtime.1.0 Microsoft.NET.Native.Runtime.1.0 Microsoft.Windows.CloudExperienceHost Microsoft.AAD.BrokerPlugin Microsoft.Windows.ShellExperienceHost windows.immersivecontrolpanel Microsoft.Windows.Cortana Microsoft.AccountsControl Microsoft.BioEnrollment Microsoft.LockApp Microsoft.MicrosoftEdge Microsoft.Windows.AssignedAccessLockApp Microsoft.Windows.ContentDeliveryManager Microsoft.Windows.ParentalControls Microsoft.WindowsFeedback Microsoft.XboxGameCallableUI Microsoft.XboxIdentityProvider Windows.ContactSupport Windows.MiracastView Windows.PrintDialog Windows.PurchaseDialog microsoft.windowscommunicationsapps Microsoft.BingFinance Microsoft.BingWeather Microsoft.BingNews Microsoft.Getstarted Microsoft.Windows.Photos Microsoft.WindowsStore Microsoft.XboxApp Microsoft.WindowsCamera Microsoft.ZuneMusic windows.devicesflow Microsoft.WindowsAlarms Microsoft.SkypeApp Microsoft.ZuneVideo Microsoft.WindowsSoundRecorder Microsoft.WindowsPhone Microsoft.WindowsMaps Microsoft.WindowsCalculator Microsoft.People Microsoft.Office.OneNote Microsoft.MicrosoftSolitaireCollection Microsoft.MicrosoftOfficeHub Microsoft.BingSports Microsoft.Appconnector Microsoft.3DBuilderIt's interesting that some of the old desktop applications have been replaced by Universal AppX packages. For example, Windows Calculator. 
      The list above just includes the AppX package name, there are more properties available:
      Get-AppXPackage Microsoft.WindowsCalculatorName : Microsoft.WindowsCalculator Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Architecture : X64 ResourceId : Version : 10.1507.15010.0 PackageFullName : Microsoft.WindowsCalculator_10.1507.15010.0_x64__8wekyb3d8bbwe InstallLocation : C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1507.15010.0_x64__8wekyb3d8bbwe IsFramework : False PackageFamilyName : Microsoft.WindowsCalculator_8wekyb3d8bbwe PublisherId : 8wekyb3d8bbwe IsResourcePackage : False IsBundle : False IsDevelopmentMode : False Dependencies : {Microsoft.VCLibs.140.00_14.0.22929.0_x64__8wekyb3d8bbwe} 
      Once you have package names you can use Remove-AppXPackage to uninstall for the user, and Remove-AppXProvisionedPackage to remove from the image, then you run SysPrep and the applications will not be installed for new users of that image.
      Most of the package names are fairly self explanatory, but each package can contain multiple applications. It's not obvious that the "toy" Windows Mail application is included in the microsoft.windowscommunicationsapps package. Here is a PowerShell script that cycles through all the packages and shows the applications inside:
      $packages = Get-AppxPackage foreach ( $package in $packages ) { Write-host "Package: $($package.Name)" $manifests = Get-AppxPackageManifest -Package $package foreach ($manifest in $manifests) { foreach($app in $manifest.Package.Applications.Application) { Write-Host " Id: $($app.Id)" Write-Host " Executable: $($app.Executable)" } } Write-Host }Example output for microsoft.windowscommunicationsapps:
      Package: microsoft.windowscommunicationsapps Id: microsoft.windowslive.mail Executable: HxMail.exe Id: microsoft.windowslive.calendar Executable: HxCalendarAppImm.exe 
      The Id gives you a good idea of the individual applications, but I imagine there is a way to get the proper Start Menu display name. Need to do a little more digging though.
  • Create New...