calculator

calculator copied to clipboard

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.

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

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.

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.

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.

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?

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

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

/cc @rudyhuyn

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.

@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.

@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++.

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

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.

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#.

There have been many occasions in which C# applications are faster than C++ applications. Even re-writing the .NET to C# makes it faster than when it was in C++. gRPC performance test shows that C#/ .NET is very fast. And .NET 6 is going to make things even faster - low memory consumption, better performance and of high productivity.

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

Thanks @MMiloslavsky for bring up such a good question and also thanks @saint4eva for the justification. Performance impact is indeed a concern of migrating to C#. However, we are keeping the core calculator engine in C++ to make sure the Arbitrary-Precision rational library and the engine stays as best as what they are. The remaining big parts are View and ViewModel, which don't have too much workloads with them in usual case. Moving them to C# from C++/CX may have more benefits than the cost it brings.

Topic starter wrote:

Calculator is a great project for developers starting with UWP. However, it is implemented in C++ with managed extensions... Having calculator project in C# would make this project accessible to a much wider audience... Please consider converting this project to C#.

You wrote:

we are keeping the core calculator engine in C++

I don't see the reason for migrating then.

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

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?

Surely UWP won't seriously be the target given UWP is more or less dead? Why is WinUI 3 not being considered?

https://docs.microsoft.com/en-us/windows/apps/winui/#:~:text=WinUI%203%20is%20the%20native,10%20and%20later%20OS%20versions.

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.

... 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.

FYI: "UWP platform is now deprecated".

FYI: "UWP platform is now deprecated".

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

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.

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

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.

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

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.

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

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#.

Migration from c++ to C#