search

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.78k stars 319 forks source link

Modern Windows Runtime API for Registry access #1153

Open JaiganeshKumaran opened 3 years ago

JaiganeshKumaran commented 3 years ago

Proposal: Modern Windows Runtime API for Registry access

Today if you want to access the Windows Registry programmatically, you need to use outdated C style APIs. Although Microsoft .NET does provide a wrapper, it can't be used from other languages. Although an UWP app probably doesn't have access to the entire registry, it will be at least useful for desktop apps.

Summary

Provide a new, modern Windows Runtime wrapper on top of Win32 registry APIs similar to ApplicationDataContainer but with the ability to access global system registry keys if the app has access to them.

Rationale

Scope

Capability Priority
This proposal will allow developers to access the Registry through a modern WinRT API Must
ghost commented 3 years ago

@Jaiganeshkumaran

ghost1372 commented 3 years ago

i used this nuget package and worked fine
<PackageReference Include="Microsoft.Win32.Registry" Version="5.0.0" /> But it would be great if an built in API is created and there is no need for a nuget package

JaiganeshKumaran commented 3 years ago

i used this nuget package and worked fine <PackageReference Include="Microsoft.Win32.Registry" Version="5.0.0" /> But it would be great if an built in API is created and there is no need for a nuget package

That's for .NET apps only, not all Windows apps.

JaiganeshKumaran commented 3 years ago

@Jaiganeshkumaran

  • so basically you want to "winrot" just in different languages other than C/C++/C# ?

In my opinion apps shouldn't write to the system registry for private app data and should use a private hive (which is what ApplicationDataContainer does but you can't create your own with it). Unfortunately Windows Rot is still an issue however system registry access may still be needed for certain things (eg: reading or writing existing system setting keys for diagnostic applications).

  • This proposal under the hood wants "automatic registry clean-up tech to be implemented too for unpackaged apps" unless that will be implemented it is basically winrot again just in a COM wrapper.

Such a feature would be great however with unpackaged apps, the system knows very little. It's just a bunch of executables and it can't know when an app is no longer there or not (installers aren't directly tied with the app, it just copies and registers certain things like adding it to the Apps & features list but Windows doesn't know an executable is part of an app that originally came from an installer.

  • applies only to unpackaged desktop apps. (packaged apps too can with undertualizedResources but that defeats the whole purpose of packaging.)

That's fine, there were already some Windows Runtime APIs that can be only used from an unpackaged app and the point is to provide a modern, clean interface to everything and not just provide stuff that's only for a specific app model.

asklar commented 3 years ago

C++ apps can already use the WIL library for easier registry access, I don't think we need yet another way.

ghost commented 3 years ago

C++ apps can already use the WIL library for easier registry access, I don't think we need yet another way.

Code that started its life inside Windows and is being moved into Project Reunion may similarly start as a mix of the two patterns until we can convert them forward to fully modern C++ with minimal use of result-oriented flow. https://github.com/microsoft/WindowsAppSDK/issues/688#issuecomment-816384586

AdamBraden commented 3 years ago

We could invest in new apis, but the existing ones are available to many languages via the Win32Metadata project:

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

Have you had a chance to take a look at that?

ghost commented 3 years ago

@AdamBraden would you mind answering a Existential-crisis concern ?

if "win32 metadata" can enable "projections into different langs" for C-based win32 apis

then why was on earth COM and it's evolution WinRT even created in the first place ? why does COM/WinRT and c#/winrt, c++/winnrt even exist ? Is it an attempt to discard/trash the whole idea/mechanism of COM/WinRT and their corresponding APIs ? (yes, I'm now also wondering why does even winUI 3 is subset of winrt instead of win32 metadata ?/why does Windows App SDK APIs are COM based instead of win32 metadata based ?)

JaiganeshKumaran commented 3 years ago

We could invest in new apis, but the existing ones are available to many languages via the Win32Metadata project:

https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/

Have you had a chance to take a look at that?

The problem with APIs exposed through the Win32 Metadata project is that the APIs still retain their unnatural naming convention, weird Windows specific types and type aliases instead of language types etc...

dongle-the-gadget commented 2 years ago

RegistryRT?