Microsoft is pushing more and more code into user space. The latest change is that they now insist printer manufacturers use UWP printer apps rather than drivers to add custom functionality to their printers; these apps are usually written in languages like C#.
I agree with Microsoft that the best method is probably to run less manufacturer code in the kernel, not to make the kernel accessible more easily. Running a garbage collector in the kernel sounds near impossible to pull off without GC bugs because C# isn't exactly suited for "I want to access some buffer but I can't because it hasn't been paged in and I'm in an interrupt handler".
> The latest change is that they now insist printer manufacturers use UWP printer apps rather than drivers to add custom functionality to their printers; these apps are usually written in languages like C#
it would be nice, however .NET Native is deprecated, Native AOT doesn't do UWP, and WinDev is pretty bullish in C++.
The GP I was responding to called for drivers written in managed C#, so .NET Native/AOT/C++ are the thing they want to move away from. The example code Microsoft provides (https://learn.microsoft.com/en-us/windows-hardware/drivers/d...) is all plain and simple C# with XAML UI.
I suppose you could write these tools in VB.NET or F# if you wanted to as well, but the goal seems to be to avoid memory and security risks in the printer framework by forcing everything into the nice and safe managed environment. Of course developers could always introduce vulnerable code into a managed environment if they wanted to, but most people don't intentionally make their programs more insecure, not even printer manufacurers.
I didn't realise that. Then again, I only experimented with AOT executables quite briefly. Perhaps Cosmos[1] stuck in my head more than what I read about AOT dotnet applications.
Depends, it can be already compiled to native code, in the case of still having MSIL, it is compiled by Windows Store before becoming available for distribution.
From the point of view of consumer, it is all AOT compiled code.
I agree with Microsoft that the best method is probably to run less manufacturer code in the kernel, not to make the kernel accessible more easily. Running a garbage collector in the kernel sounds near impossible to pull off without GC bugs because C# isn't exactly suited for "I want to access some buffer but I can't because it hasn't been paged in and I'm in an interrupt handler".