Open JaiganeshKumaran opened 3 years ago
@Jaiganeshkumaran
so basically you want to "winrot" just in different languages other than C/C++/C# ?
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.
applies only to unpackaged desktop apps. (packaged apps too can with undertualizedResources
but that defeats the whole purpose of packaging.)
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
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
- 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.
C++ apps can already use the WIL library for easier registry access, I don't think we need yet another way.
C++ apps can already use the WIL library for easier registry access, I don't think we need yet another way.
The main things that we use WIL for are:
- Consistent flow-control tools (xxx_IF_FAILED for both exceptional and result-oriented code)
- Adapting "old style" code to "new style" semantics in various places (errors, callbacks, threading, locking, etc.)
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
We could invest in new apis, but the existing ones are available to many languages via the Win32Metadata project:
Have you had a chance to take a look at that?
@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 ?)
We could invest in new apis, but the existing ones are available to many languages via the Win32Metadata project:
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...
RegistryRT?
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