[Feature] Replicate UWP File API to provide improved performance via Win32 APIs

[h82258652]

Describe the problem this feature would solve

The storage API is very slow. Take an example, when you call StorageFolder.GetItemsAsync on a folder which contains lots of files, it will takes very long.

Describe the solution

Use FromApp series API in api-ms-win-core-file-fromapp-l1-1-0.dll can improve the performance. But these API are both Win32 API, which means we need to use PInvoke and face the handle (that's terrible).

Describe alternatives you've considered

I hope there are some file and directory API like System.IO, but base on api-ms-win-core-file-fromapp-l1-1-0.dll.

Additional context & Screenshots

https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-file-fromapp-l1-1-0dll
microsoft/microsoft-ui-xaml#1465 (comment)

Hello, 'h82258652! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[Kyaa-dost]

@h82258652 Thanks for highlighting the issue. Opening the discussion with the team to investigate further and provide any possible resolution.

[michael-hawker]

@h82258652 what's your specific suggestion/ask for the toolkit? It seems like there's already discussion going on in the WinUI/Reunion threads about this?

[h82258652]

@michael-hawker Oh sorry, I don't describe this clearly. I hope the toolkit can add some IO classes like this:

public static class UwpDirectory
{
    public static IEnumerable<string> EnumerateFiles(string path)
    {
        var hFile = FindFirstFileExFromApp(
            path + "\\*.*",
            FINDEX_INFO_LEVELS.FindExInfoBasic,
            out var findData,
            FINDEX_SEARCH_OPS.FindExSearchNameMatch,
            IntPtr.Zero,
            0);

        if (hFile.ToInt32() != -1)
        {
            do
            {
                var itemName = findData.itemName;
                if (itemName == "." ||
                    itemName == "..")
                {
                    continue;
                }

                yield return Path.Combine(path, itemName);
            } while (FindNextFile(hFile, out findData));
        }

        FindClose(hFile);
    }
}

Same usage as Directory.EnumerateFiles, the developers can easy replace their codes.
And also the toolkit can improve the performance which used the Storage API (like this)

The discussion in the WinUI/Reunion I don't found before, I will have a look. I found the discussion in the dotnet runtime repo, but it is closed.

[michael-hawker]

Thanks @h82258652 that's much clearer. I thought that might be where you were going with the suggestion, but I wasn't sure.

So, basically the idea would be to replicate the existing UWP API surface, but with the differing implementation underneath to allow for swapping it out with a namespace change and improving performance.

This seems like a bigger undertaking, the first step would be mapping out each API and which equivalent functions we could use, eh?

Is this something you're thinking of helping build or just filing here as a suggestion?

@azchohfi thoughts on this type of API surface? We've shied away from trying to ship 'fixes' for issues in the platform. I'm not sure if we want to invest in this area as a stop-gap? It almost seems like something that should just ship as part of Reunion itself, I'm not sure on their current plans and timelines though. Maybe @jonwis can help us understand that and advise us in this space?

[Kyaa-dost]

@h82258652 what do you think of contributing in this space? ⬆️

[h82258652]

@Kyaa-dost I don't know if it is worth, there are lots of File and Directory APIs which means very much works to do, and seems Microsoft giving up the WinRT.:disappointed_relieved: