This is not a game. I would normally agree but not when it comes to low-level kernel drivers. They're a cyber security company making it even worse.
Not very long ago we had this client who ordered a custom high security solution (using a kernel driver). I can't reveal too much but basically they had this offline computer running this critical database and they needed a way to account for every single system call to guarantee that any data could have not been changed without the security system alerting and logging the exact change. No backups etc were allowed to leave the computer ever. We were even required to check ntdll (this was on Windows) for hooks before installing the driver on-site & other safety precautions. Exceptions, freezes or a deadlock? No way. Any system call missed = disaster.
We took this seriously. Whenever we made a change to the driver code we had to re-test the driver on 7 different computers (in-office) running completely different hardware doing a set test procedure. Last test before release entailed an even more extensive test procedure.
This may sound harsh but CrowdStrike are total amateurs, always been. Besides, what have they contributed to the cyber security community? - Nothing! Their research are at a level of a junior cyber security researcher. They are willing to outright lie and jump to wild conclusions which is very frowned upon in the community. Also heard others comment on how CS really doesn't really fit the mold of a standard cyber security company.
Nah, CS should take a close look at true professional companies like Kaspersky and Checkpoint; industry leaders who've created proven top notch security solutions (software/services) but not least actually contributed their valuable research to the community for free, catching zero-days, reporting them before no one even had a chance of exploiting them.
> I've been researching new backpacking gear this summer, looking on sites that are known to me, so I've been seeing lots of ads for that type of stuff naturally.
I develop WinForms applications at work and we use .NET Framework by choice, to aim for long-term stability and not the 'new thing'. We are not stuck we're loose. It's important to understand that MS Windows will never be able to get rid of the ability to run .NET Framework apps. Also, even though the new .NET supports WinForms, it's not a 1 : 1 port yet and we've done extensive testing on this. Not using .NET Framework would mean degrading the performance of the app (~30%). Try it out for yourself with a controls heavy application. I'm talking 100+ controls on a single app with real-time data fed through it. We use 3rd-party WinForms controls that's been in development for over 15 years. The GUI is modern and the performance excellent.
Words like 'legacy', in our case, means better stability and higher performance, and frankly, we neither trust nor care about Microsoft's opinion.
That said, I can understand that the new .NET is useful and an upgrade for those who wants cross-platform support among other things.
Absolutely. Main reasons being 1) that we don't need any of the new features modern .NET can offer and 2) we specialize in mission critical, high performance apps
For example, recently a customer wanted a security solution, a filesystem journaling application, powered by a low-level FS kernel driver (C/C++) together with a managed .NET assembly to interop with our unmanaged driver DLL. Running on the highest altitude - on top of the driver stack - means handling, filtering, and intercepting a huge amount of filesystem requests before it reaches other system components. Therefore, performance is key.
In that scenario, using modern .NET we experienced nonstop deadlocks which froze the whole system. .NET Framework had no issues keeping up.
I can also think of other examples e.g. issues working with custom virtual filesystems.
So yes, NET Framework would be my first choice for standard Windows-only desktop applications.
In what scenarios can you make .NET Framework perform faster than .NET 8? The expected performance difference is 2 to 10x in favor of the latter. It’s not even a choice. If you can reproduce the issue, please consider submitting it to dotnet/runtime rather than choosing obsolete target.
I already gave two examples 1) large-scale WinForms app with third-party controls and libraries and 2) Interop with FS kernel driver under heavy load
We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).
Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.
Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.
Would be interesting to learn more. It seems like you know your stuff well, but could it be that your ported code doesn't do things like it should be done in modern .net?
Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.
> could it be that your ported code doesn't do things like it should be done in modern .net?
I'm actually curious myself after this discussion. I didn't port it, my coworker did it and I'd have to ask him. I did take part in the benchmark though and watched all the deadlocks happening.
Found this old screenshot of our internal FS driver debugging tool - to give you an idea of what I mean by needing high performance: https://postimg.cc/mc6YQFbC
24,654 filesystem events in C:\Windows\ in just 1 minute and 30 seconds on idle. 814 read operations (36,7MB) + 948 write operations (66,9MB). Now imagine this system-wide (not just the Windows dir) under heavier load. This is where modern .NET could not keep up leading to the aforementioned deadlocks.
Sorry that I can't provide more specific info at this time. I can find out more on Monday.
If there is an issue, chances are it's in the for-new-.NET implementation of WinForms. Any regressions in the GC or CoreLib themselves are definitely not expected and can be submitted as issues to be fixed.
There can be latency differences in edge cases of interaction between threadpool used by specific version and Overlapped IO on Windows, but that's likely about all there can be.
It's important to note that .NET Core 3.1 -> .NET 5 -> 6 -> 7 -> 8 is a huge difference in compiler and corelib internals (less so in GC, with major steps in 6, 7 and 8 in regards to regions and now DATAS), so an issue that could have existed in one of the previous versions is likely to be fixed by now.
That would be an exceedingly poor choice. Libraries have even started to drop NS2.0 target as it is too limiting or requires if-defs and extra maintenance effort for obsolete targets.
I think JetBrains made a mistake by not including a Windows Forms designer much sooner, that supports 3rd-party controls/components [0] in the Rider IDE. Dealbreaker for me now and for many other companies I've worked for or know of. Unfortunately, we had to choose Visual Studio because of this.
According to their own developer survey, Windows Forms was at 22% in 2023 [1].
WinForms != legacy, because it's very extensible! Microsoft still maintains it (last update was 1 month ago). It is also still one of the flagship products for companies that make 3rd-party controls like DevExpress [2], Telerik, Infragistics, GrapeCity and several others.
Students in academia today will not learn about WPF, WinUI, UWP and whatever else MS' pushing. They learn Windows Forms - in my country and in Europe at least.
Hopefully we'll get to switch over to Rider soon, but it's been 5 years already [3]. Big mistake.
Given how messed up the travel has been since Windows 8, and the focus Azure and XBox nowadays get, Windows Forms and WPF are still the best way to target Windows from .NET on the Microsoft own frameworks (naturally there are Avalonia and Uno as well).
For the C++ folks, Microsoft has yet failed to produce anything better than MFC, C++/WinRT with XAML and COM/IDL ain't it.
https://github.com/vitoplantamura/HackerNewsRemovals
"List of stories removed from the Hacker News Front Page, updated in real time."