Introducing the Experimental Microsoft.Windows.Storage.Pickers API

[DinahK-2SO]

Dear Developers,

We're excited to announce the experimental release of Microsoft.Windows.Storage.Pickers API, designed to address significant limitations in file and folder picking operations, and is available in 1.8.250410001-experimental1

Key Enhancements

• Admin Mode Support: File and folder pickers now function properly when an application runs with elevated privileges
• Container Mode Support: The new pickers also work seamlessly in containerized environments (win32-isolation)

Documentation

For detailed useage guide, please refer to below documentations:

• Microsoft.Windows.Storage.Pickers.md
• FileOpenPicker.md
• FileSavePicker.md
• FolderPicker.md

Known Issues

(Below known Issues will be fixed in experimental3)

1. FolderPicker crash when selecting "This PC" or special paths
   This issue is addressed in PR Fix FolderPicker crash when selecting "This PC" or special paths #5446

(Below known Issues are fixed in experimental2)

1. FileTypeFilter and FileTypeChoices
   The following issues are addressed in PR Supplements Missing Functionalities for FileOpenPicker.FileTypeFilter and FileSavePicker.FilterTypeChoices #5358:

   1. Missing comprehensive file type filter that includes all defined file types
   2. Failure to auto-append the first extension from choices when saving with unknown extensions
   3. Suggested file extension not updating when changing category selection

2. ARM64 Compatibility
   ARM64 devices currently experience a "Class not registered" error. This issue is addressed in PR Bugfix - Storage Pickers cannot launch on ARM64 #5367.

Feedbacks

We welcome your contributions and feedback on this experimental API. Please report any issues or suggestions through our standard channels.

Thank you for your continued support of the Windows App SDK.

[ghost1372]

Thank you
Introducing a FileTypeChoices property for FileOpenPicker would enhance its functionality by enabling the inclusion of detailed file extension descriptions.
#5255

[whiskhub]

Cool! I mentioned it in the PR already (#5155 (comment)), but writing it here again for visibility. 🙂
It would be nice if we could pass a custom file path as the starting location, and not just have predefined enum options of SuggestedStartLocation.

[eduardobragaxz]

I mentioned this in some PR before: why do they not return StorageFolder? It's much better. If all you want is a path, there's the StorageFolder path property.

Also, will this not work in AppContainer?

[DrusTheAxe]

why do they not return StorageFolder? It's much better. If all you want is a path, there's the StorageFolder path property.

Actually no. It's worse. The StorageFolder object doesn't spring forth from thin air. Ultimately the path gets resolved as a string and then a StorageFolder object gets created from the string. Thus

string path = foo.GetStorageFolder().Path

is really doing

string path = new StorageFolder(foo.GetPath()).Path

If you want the path as a string creating a StorageFolder around it to then get it out of the object and throw away the StorageFolder is pure overhead. This can be significant given creating a StorageFolder can involve access verification as well as the usual malloc+free, string copy, etc. That 'access check' overhead can add up fast.

(I say "can" as the implementation sometimes can employ clever jiujitsu to avoid the access check. Depends on the particular code path and state, so very much "it depends")

It makes more sense to provide string GetPath APIs to directly provide paths as a string than make folks do so by way of detouring thru a StorageFolder. That makes StorageFolder GetLocation APIs a nice addition for a subset of developers but a poor substitute for the string GetPath form.

[DrusTheAxe]

will this not work in AppContainer?

This was noted as a current limitation. AC support is desired but requires additional work so we couldn't deliver it in this initial drop. We too desire to get there. Please be patient.

Better to start somewhere and incrementally grow than all or nothing. Don't make perfect the enemy of the good :-)

[DarranRowe]

It sounds like you're saying there's a constants? documentation? gap here and that S-1-15-3-* is impossible given the current available information (except of course it exists, and has for over a decade). Is that the gist of it?

Yes. The Windows headers have always been really good at providing different names for semantically different uses of the same value. But just to be clear, specifically the capability version of the app package SID.

S-1-15-2-29491931-3757167503-2088895914-4267765888-652470154-1834349019-1553081041

vs

S-1-15-3-29491931-3757167503-2088895914-4267765888-652470154-1834349019-1553081041

The constants don't seem to be able to make this up, and I have never found any documentation stating that this kind of SID is possible either. I always just assumed that it was an implementation detail and ignored it.

[DrusTheAxe]

https://learn.microsoft.com/en-us/windows/win32/secauthz/app-container-sid-constants has relevant constants

• SECURITY_APP_PACKAGE_AUTHORITY ({0,0,0,0,0,15})

OK, there's the ...-15-... part

• SECURITY_APP_PACKAGE_BASE_RID (0x00000002L)
• SECURITY_BUILTIN_APP_PACKAGE_RID_COUNT (2L)
• SECURITY_APP_PACKAGE_RID_COUNT (8L)

'App Package RID' i.e. Package SID info. Thus the ...-2-...

• SECURITY_CAPABILITY_BASE_RID (0x00000003L)
• SECURITY_BUILTIN_CAPABILITY_RID_COUNT (2L)
• SECURITY_CAPABILITY_RID_COUNT (5L)

'Security [BuiltIn] Capability RID' i.e. Package Capability SID. Thus the ...-3-...

The 2nd+3rd constants are interesting

• SECURITY_BUILTIN_*_RID_COUNT is 2 for both
• SECURITY_*_RID_COUNT is 8 vs 5

Interesting the latter is 5 and not 8. I wonder if that's a typo? But the header file definitions I see are 5. So I freely admit I don't understand. Is it just me?

I do know code creating a PackageCapabilitySID from a PackageSID just changes the BASE_RID value

• PackageSID as a string transformation = copy but replace string[7] with '0' + SECURITY_CAPABILITY_BASE_RID (after verifying string[7] == `'0' + SECURITY_APP_PACKAGE_BASE_RID)
• PackageSID as a PSID transform = SID_IDENTIFIER_AUTHORITY sid{ SECURITY_APP_PACKAGE_AUTHORITY }; RtlAllocateAndInitializeSid(&sia, 8, SECURITY_CAPABILITY_BASE_RID, *GetSidSubAuthority(pkgsid, 1), ..., *GetSidSubAuthority(pkgsid, 7), out_pkgcapsid)` (after verifying input is a PackageSID)

If SECURITY_CAPABILITY_RID_COUNT was 8 would that make more sense to you? Yea or nay, can you explain why?

[DarranRowe]

If SECURITY_CAPABILITY_RID_COUNT was 8 would that make more sense to you? Yea or nay, can you explain why?

I think going into the capability SID types would show why.

First, there are the built in capabilities.

S-1-15-3-1

This is the capability SID for Internet Client. This type of capability has 2 RIDs.

Then there are device capability SIDs.

S-1-15-3-715121970-1157172444-427173784-4221709359

This is the capability for a magnetic stripe reader. The device class {2a9fe532-0cdc-44f9-9827-76192f2ca2fb}. This type of capability has 5 RIDs.

Then there are the app package capability SIDs.

S-1-15-3-29491931-3757167503-2088895914-4267765888-652470154-1834349019-1553081041

This is hash based. It has 8 RIDs.

Finally, there are the newer app capabilities.

S-1-15-3-1024-734518492-402359323-2580938124-1419864735-4212787651-2727913556-228323224-564805089

This is the capability SID for packageManagement. This has 10 RIDs. Silo capability SIDs should have the same RID count as app capabilities.

As a guess, I would think that SECURITY_CAPABILITY_RID_COUNT was for the device capabilities. So I would say that changing this from 5 to 8 would be undesirable because it would potentially introduce a breaking change. But I haven't had time to look into some historical things, like older Windows SDKs. Sometimes names make perfect sense in the context of history, but lose meaning as time goes on.