Re:Mark Russinovich: “Working towards enabling Windows drive...
by pjmlp on Sunday September 24, 2023 @01:28PM
(#37635165)
> 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++.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by lloydatkinson on Sunday September 24, 2023 @02:09PM
(#37635608)
Native AOT is not dead I don’t know where you heard that https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Re:Mark Russinovich: “Working towards enabling Windows drive...
by pjmlp on Sunday September 24, 2023 @04:53PM
(#37637096)
Read very carefully what I wrote.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by lloydatkinson on Monday September 25, 2023 @11:06AM
(#37645059)
Very helpful reply.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by GoblinSlayer on Monday September 25, 2023 @05:30AM
(#37641309)
>Native AOT doesn't do UWP
Is there a need for it? Printing isn't performance sensitive.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by pjmlp on Monday September 25, 2023 @06:19AM
(#37641585)
The UWP execution model to start with, no JIT code allowed, based on COM.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by GoblinSlayer on Monday September 25, 2023 @10:15AM
(#37644141)
AIU the package for Windows Store contains msil, then Windows Store figures out what to do with it.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by pjmlp on Monday September 25, 2023 @10:26AM
(#37644324)
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.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by jeroenhd on Monday September 25, 2023 @10:18AM
(#37644177)
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.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by pjmlp on Monday September 25, 2023 @10:27AM
(#37644355)
C# is always managed, regardless of being AOT or JIT compiled.
GC and language runtime are still there.
Re:Mark Russinovich: “Working towards enabling Windows drive...
by jeroenhd on Monday September 25, 2023 @10:34AM
(#37644486)
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.
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".