3 ms·

I'm a bit surprised when seeing the main language is C++ instead of C#. Btw, it looks promise. I think I will love it with Find All feature, intuitive and info

I'm a bit surprised when seeing the main language is C++ instead of C#. Btw, it looks promise. I think I will love it with Find All feature, intuitive and informative.

bloblaw 5y ago
Wow, how times have changed! I say that because when C# was released, many Windows developers refused to use it and continued to only write Windows programs in "native" languages like C++, VB6, and Delphi. I must admit my own bias and state that I still prefer applications written in "native" code on Windows (C++ / Delphi) to C#. It's not really an issue worth arguing over these days (and hasn't been for years), but there it is. FWIW, all the SysInternals tools are C++
- pilif 5y ago
  VB6 didn’t produce native binaries
  - BusTrainBus 5y ago
    Yes it did.
  - bloblaw 5y ago
    VB6 did support compiling "native" binaries by default, and not to p-code, as previous versions did. https://blog.decompiler-vb.net/the-truth-about-p-code/ https://blog.decompiler-vb.net/the-truth-about-p-code/
- userbinator 5y ago
  The startup times are noticeably longer for anything non-native, and noticeable can turn into annoyance when it's an application you're unlikely to leave open all the time, like a registry editor.
0xdeadb00f 5y ago
> I'm a bit surprised when seeing the main language is C++ instead of C#. May I ask why? That isn't that surprising to me.
foepys 5y ago
With the current state of .NET I wouldn't either. Once Microsoft makes up its mind about which way it wants to go for UI and distribution of desktop applications, maybe. I don't want to use buggy, incomplete WinForms, deprecated, half-abandoned, buggy WPF, or unfinished WinUI.
- foepys 5y ago
  To the people downvoting this: WPF is complete, done, never to be changed again according to Microsoft. But nevetheless they have recently started fixing bugs for .NET 6. Notably not the one where returning from the Windows 10 lock screen made the application freeze. They called that production-ready for .NET 5. [1] WinForms is a mess. They reinvented the wheel when porting it from .NET Framework by changing APIs, then noticing that this wasn't a good idea because porting applications from .NET Framework would become a complete rewrite which would make WinForms on .NET pointless. So they stopped changing the APIs halfway through, which makes it still necessary to rewrite complex UIs. [3] The WinForms designer in Visual Studio does not work with third-party controls (even your own) when targeting .NET 5/6. You need to sign an NDA to get access to internal VS APIs to do that. They call that production-ready. [2] WinUI 3 is missing a lot of controls and features. But because Windows 11 needed to be released, they implemented the bare minimum that they needed for themselves and called it production-ready. It's a mess. A huge mess when developing a desktop UI application larger than a calculator. 1: https://github.com/dotnet/wpf/issues/2158 https://github.com/dotnet/wpf/issues/2158 2: https://devblogs.microsoft.com/dotnet/windows-forms-designer-for-net-core-released/ https://devblogs.microsoft.com/dotnet/windows-forms-designer... > We are working closely with the control vendors such as Progress Telerik, DevExpress and GrapeCity on supporting their controls in the Windows Forms designer in the nearest future for .NET Core and .NET 5 projects. We are also collaborating with ActiPro, Infragistics, and SyncFusion. Situation unchanged, no access to the APIs without an NDA. 3: https://docs.microsoft.com/en-us/dotnet/core/compatibility/winforms https://docs.microsoft.com/en-us/dotnet/core/compatibility/w...
  - contextfree 5y ago
    Windows 11 doesn't currently use WinUI 3 at all, it's all still WinUI 2.x/UWP XAML based, including the new stuff. Actually I don't think WinUI 3 currently has any immediate advantages over WinUI 2.x from the app developer's point of view, except that there's a nice Visual Studio template for creating standalone Win32 apps using it, but I believe you can achieve more or less the same thing with a little more upfront work by just making an app that does its entire UI in one big XAML Island, and in fact that's how Windows Terminal works. The long-term advantages are supposed to come from WinUI 3's XAML and composition stack being decoupled from the Windows OS build.

I'm a bit surprised when seeing the main language is C++ instead of C#. Btw, it looks promise. I think I will love it with Find All feature, intuitive and informative.

bloblaw 5y ago

Wow, how times have changed! I say that because when C# was released, many Windows developers refused to use it and continued to only write Windows programs in "native" languages like C++, VB6, and Delphi. I must admit my own bias and state that I still prefer applications written in "native" code on Windows (C++ / Delphi) to C#. It's not really an issue worth arguing over these days (and hasn't been for years), but there it is. FWIW, all the SysInternals tools are C++

pilif 5y ago
VB6 didn’t produce native binaries
- BusTrainBus 5y ago
  Yes it did.
- bloblaw 5y ago
  VB6 did support compiling "native" binaries by default, and not to p-code, as previous versions did. https://blog.decompiler-vb.net/the-truth-about-p-code/ https://blog.decompiler-vb.net/the-truth-about-p-code/
userbinator 5y ago
The startup times are noticeably longer for anything non-native, and noticeable can turn into annoyance when it's an application you're unlikely to leave open all the time, like a registry editor.

0xdeadb00f 5y ago

> I'm a bit surprised when seeing the main language is C++ instead of C#. May I ask why? That isn't that surprising to me.

foepys 5y ago

With the current state of .NET I wouldn't either. Once Microsoft makes up its mind about which way it wants to go for UI and distribution of desktop applications, maybe. I don't want to use buggy, incomplete WinForms, deprecated, half-abandoned, buggy WPF, or unfinished WinUI.

foepys 5y ago
To the people downvoting this: WPF is complete, done, never to be changed again according to Microsoft. But nevetheless they have recently started fixing bugs for .NET 6. Notably not the one where returning from the Windows 10 lock screen made the application freeze. They called that production-ready for .NET 5. [1] WinForms is a mess. They reinvented the wheel when porting it from .NET Framework by changing APIs, then noticing that this wasn't a good idea because porting applications from .NET Framework would become a complete rewrite which would make WinForms on .NET pointless. So they stopped changing the APIs halfway through, which makes it still necessary to rewrite complex UIs. [3] The WinForms designer in Visual Studio does not work with third-party controls (even your own) when targeting .NET 5/6. You need to sign an NDA to get access to internal VS APIs to do that. They call that production-ready. [2] WinUI 3 is missing a lot of controls and features. But because Windows 11 needed to be released, they implemented the bare minimum that they needed for themselves and called it production-ready. It's a mess. A huge mess when developing a desktop UI application larger than a calculator. 1: https://github.com/dotnet/wpf/issues/2158 https://github.com/dotnet/wpf/issues/2158 2: https://devblogs.microsoft.com/dotnet/windows-forms-designer-for-net-core-released/ https://devblogs.microsoft.com/dotnet/windows-forms-designer... > We are working closely with the control vendors such as Progress Telerik, DevExpress and GrapeCity on supporting their controls in the Windows Forms designer in the nearest future for .NET Core and .NET 5 projects. We are also collaborating with ActiPro, Infragistics, and SyncFusion. Situation unchanged, no access to the APIs without an NDA. 3: https://docs.microsoft.com/en-us/dotnet/core/compatibility/winforms https://docs.microsoft.com/en-us/dotnet/core/compatibility/w...
- contextfree 5y ago
  Windows 11 doesn't currently use WinUI 3 at all, it's all still WinUI 2.x/UWP XAML based, including the new stuff. Actually I don't think WinUI 3 currently has any immediate advantages over WinUI 2.x from the app developer's point of view, except that there's a nice Visual Studio template for creating standalone Win32 apps using it, but I believe you can achieve more or less the same thing with a little more upfront work by just making an app that does its entire UI in one big XAML Island, and in fact that's how Windows Terminal works. The long-term advantages are supposed to come from WinUI 3's XAML and composition stack being decoupled from the Windows OS build.