Migrate codebase to C#

[PaulDotNet]

Calculator is a great project for developers starting with UWP. However, it is implemented in C++ with managed extensions which I would consider rather a niche language with a niche features in a niche area of UI development. It is a niche within a niche within a niche.

I know C++ but would never consider this language for UI development. This ship has sailed around year 2000. On the other hand if Microsoft would pay me a huge salary to develop UI apps in C++ I would seriously consider it. Then I would say no.

Having calculator project in C# would make this project accessible to a much wider audience and maybe would help adoption of UWP somewhat.

Please consider converting this project to C#. Future generations would thank you for it.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[ghost]

This pitch looks like it has everything it needs for review. In the meantime, we'll keep this idea open for discussion so the community has the chance to provide feedback. Check out our New Feedback Process for more info on the user-centered process we follow for new feature development.

[ghost]

We reviewed the pitch and would love to explore this idea further! The pitch is a great start, but there are still some open questions. I am moving this issue into planning to iron out some of those details and I created calculator-specs/csharp to track progress. A human will follow up with some feedback on your pitch shortly. Keep in mind that not all ideas that make it into the planning phase are guaranteed to make it to release. For more information on next steps, check out our spec workflow.

[grochocki]

Thanks for the submission, @PaulDotNet! To be honest, this is something we had already been discussing internally, but it is great to see that there is community interest in this as well. While we agree that migrating the codebase to C# would offer lots of benefits, porting is no trivial task, so we'll want to consider the pros and cons and make sure we have a plan that minimizes disruptions to the project and the community. Moving to next stage to investigate some of these details and assigning to @rudyhuyn to help drive discussion.

[mdtauk]

I think because this project originated within the Windows OS code base, and probably relies on code from the previous Win32 code - this is why it is as it is.

The team maintaining the project would be well versed in C++ but it does make it more difficult for others wishing to contribute.

If the core C++ project had an ability to "plug-in" C# modules, then adding new features becomes easier. But then if you decide to go that way in refactoring, what are the Pros and Cons to moving everything to C#?

WinUI 3.0 also allows the breaking out of the sandbox. Does the project remain a UWP app? If C# WinUI 3.0 relies on using a .NET Core framework, does the app want to take a dependency on it?

That is without considering if there is merit to keeping core code in a cross platform compatible C language, with an option to build a MacOS or Linux UI fork, which the community could work on?

[Titaniumtown]

I would love to see the windows 10 calculator on linux, hope that becomes a thing in the near future.

[stevenbrix]

FWIW, the Uno platform ported the calculator to C# already:
https://github.com/unoplatform/calculator

/cc @rudyhuyn

[ghost]

I have a question in my mind: won't this impact the performance? C++ binaries are much faster and lightweight as compared to those created using C#.

This is really a concern as a calculator ought to be a handy application. We don't expect our users to wait for five seconds in order to see our splash screen.

[miloush]

@Rahul-Dixit the performance impact of switching from Win32 to UWP was already much higher than what I would deem acceptable for a calculator app. The managed libraries are compiled ahead-of-time to native code anyway, so I wouldn't expect much of a difference between C++ and C# here.

[Chips1234]

@rudyhuyn @grochocki Any updates on the progress of the spec? I would love to see this migrated into C# as I'm much better at C# than at C++.

[JaiganeshKumaran]

@miloush .NET Native will be soon deprecated because it's incompatible with .NET 5

[MMiloslavsky]

Calculator and Paint are the only builtin apps I use regularly. Why? Because they are amazingly fast!
No doubt, switching from C++ to C# will degrade the performance.
I'm against this change.

[RokeJulianLockhart]

http://github.com/microsoft/calculator/issues/893#issuecomment-900144776, I am believing that most modern software is utilising both the Universal Windows Platform, and WinUI; the latter being for their interfaces. Therefore, surely that is irrelevant, as migration of its code-base to Win32 (or the myriad other old frameworks) is a ridiculously foolish proposition.

[pjmlp]

...
As for the core code, maybe they could look into moving from C++/CX to C++/WinRT?

Anyone considering this effort should take into account that to this day Visual Studio still doesn't support editing IDL files with syntax highlighing and code completion.

Additionally whatever mdil compiler generates has to be manually merged with existing C++ code.

A considerable downgrade from the C++/CX developer experience.

[MMiloslavsky]

FYI: "UWP platform is now deprecated".

[JaiganeshKumaran]

FYI: "UWP platform is now deprecated".

UWP isn't deprecated, latest .NET support and WinUI 3 is not available.

[pjmlp]

FYI: "UWP platform is now deprecated".

UWP isn't deprecated, latest .NET support and WinUI 3 is not available.

Yeah, it is not, just be happy to use legacy stuff without an update roadmap.

VB 6 runtime is also part of Windows 10, maybe we should go code some VB 6 apps then.

[mdtauk]

FYI: "UWP platform is now deprecated".

UWP isn't deprecated, latest .NET support and WinUI 3 is not available.

Not deprecated, but that is the intention. Future technologies will bypass UWP, and no more investment (apart from WinUI 2.X) will be made to it

[saint4eva]

Instead of C#, you should migrate WinRT code to C++/WinRT. You'll get much better performance than C++/CX.

C# is being proposed for the UI Views to open up community contributions to more developers. The core components of Calculator will remain in C++, and made into a WinRT component for other apps or controls can bundle/use.

One proposal was for creating a Calculator NumberBox which would pop out a mini calculator keypad, to allow for complex input.

As for the core code, maybe they could look into moving from C++/CX to C++/WinRT?

I think .NET Runtime and Libraries are of immense importance. And if the team switching to C# gave them tremendous increase in performance and productivity, then moving the calculator - both the UI and core engine - would produce outstanding performance and productivity. And more people would contribute to the codebase hence growth.

[DigitalDarkages]

If I may submit some VB .Net code for your consideration, it could be migrated to C# if that is your wish in the end, personally I like the ability to call an interrupt and drop in inline assembler like back when Borland Turbo C++ was a thing, but this code should make anyone reconsider what a calculator really is! BIGINT, unlimited bit based calculations, admittedly it would be hard to implement decimal division but I'm sure that there is in fact a way.......... Not my code, just admire the guy who wrote it because it made me think! https://drive.google.com/file/d/1Bg2k37YfoxjT9-FIA62ZHfLSKSspZJNH/view?usp=sharing

[lloydjatkinson]

If I may submit some VB .Net code for your consideration, it could be migrated to C# if that is your wish in the end, personally I like the ability to call an interrupt and drop in inline assembler like back when Borland Turbo C++ was a thing, but this code should make anyone reconsider what a calculator really is! BIGINT, unlimited bit based calculations, admittedly it would be hard to implement decimal division but I'm sure that there is in fact a way.......... Not my code, just admire the guy who wrote it because it made me think! https://drive.google.com/file/d/1Bg2k37YfoxjT9-FIA62ZHfLSKSspZJNH/view?usp=sharing

No.

[DigitalDarkages]

Ahh well it is your loss really here..... Thanks for reading my comment at least anyways! :-)

[goktugerol-dev]

I don't see any reason to do that but if the teams decides to do, I would like to contribute. It sounds like a lot of fun to migrate the entire code from C++ to C#.

[saint4eva]

Migration from c++ to C#

[tonyqus]

It has been about 2.5 years. I found one related issue #1598 but it happened one year ago. What's the plan now?

[PaulDotNet]

UWP is no longer relevant.
The calculator should be ported to C# and MAUI.

[lloydjatkinson]

I would expect it to be C# and WinUI 3 not MAUI.

[PaulDotNet]

I am just an anecdotal example of a developer who does not even know what the new UI framework name is.
Just port to C# and use {Windows.UI.Framework.Latest} whatever.

[DigitalDarkages]

Meh its not a "real" calculator if it is bit dependent on the type of processor you are using, it is just an interface to the cpu unless its bit depth can be specified to beyond the depth of the processor and I did suggest a working method for this but was laughed out of the room, the MOAR you know!

[DBJDBJ]

I think because this project originated within the Windows OS code base, and probably relies on code from the previous Win32 code - this is why it is as it is.

The team maintaining the project would be well versed in C++ but it does make it more difficult for others wishing to contribute.

This is not C++

[DBJDBJ]

I don't see any reason to do that but if the teams decides to do, I would like to contribute. It sounds like a lot of fun to migrate the entire code from C++ to C#.

This is not C++

[DBJDBJ]

Hello everyone, below you can find a feature branch created for the C# version Calculator App. It's still in developing progress but feel free to follow it and leave your comment on it. Thanks! https://github.com/microsoft/calculator/tree/feature/UICSharpCalculator

Performance impact is indeed a concern of migrating to C#. However, we are keeping the core calculator engine in C++

It was never in C++. But the plan is good, there is only one condition to make it work:

Refactor the core from the managed C++ to standard C++.

[JaiganeshKumaran]

@DBjdj C++/CX isn't managed C++; only syntax is similar to C++/CLI.

[skimhugo]

Why not migrate to MAUI, I think an MAUI project with c++ is a very good study case.

[DBJDBJ]

@DBjdj C++/CX isn't managed C++; only syntax is similar to C++/CLI.

It is three letters only: DBJ, thank you for your correction; in any case, C++/CX is not standard C++

Chrome Browser is using WTL .

I personally would prefer a pure standard C calculator implementation. With pure WIN32 front end.

[saint4eva]

Why not migrate to MAUI, I think an MAUI project with c++ is a very good study case.

Firstly, Maui does not have any c++ support - only C#.

Secondly, no need going through Maui and back to WinUI when you can just use WinUI and C#/ Xaml directly.

[skimhugo]

Why not migrate to MAUI, I think an MAUI project with c++ is a very good study case.

Firstly, Maui does not have any c++ support - only C#.

Secondly, no need going through Maui and back to WinUI when you can just use WinUI and C#/ Xaml directly.

Thanks for your reply. I just learning MAUI, and I do not know if it can interpo with C++. If it can interpo with C++, this project will become an all-platform app.

[JaiganeshKumaran]

@skimhugo MAUI only supports managed .NET languages. It is technically possible to compile C++ code with some business on each platform separately and somehow call it from C#, but you can't directly consume MAUI APIs from C++. Again, a cross-platform doesn't make much sense here, Windows Calculator is an inbox Windows app.

[Kreijstal]

uwp failed, maui not an option, ok, port it to GTK then.

[DBJDBJ]

WTL

[loxsmoke]

Would be cool in 1995