microsoft / calculator

Windows Calculator: A simple yet powerful calculator that ships with Windows
MIT License
29.68k stars 5.38k forks source link

Migrate codebase to C# #893

Open PaulDotNet opened 4 years ago

PaulDotNet commented 4 years ago

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 commented 4 years ago

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

ghost commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

stevenbrix commented 4 years ago

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

/cc @rudyhuyn

ghost commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

MMiloslavsky commented 3 years ago

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.

saint4eva commented 3 years ago

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.

tian-lt commented 3 years ago

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.

MMiloslavsky commented 3 years ago

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.

JaiganeshKumaran commented 3 years ago

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

mdtauk commented 3 years ago

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?

lloydjatkinson commented 3 years ago

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

image

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

RokeJulianLockhart commented 3 years ago

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 commented 3 years ago

... 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 commented 3 years ago

FYI: "UWP platform is now deprecated".

JaiganeshKumaran commented 3 years ago

FYI: "UWP platform is now deprecated".

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

pjmlp commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

the-SecEng commented 2 years ago

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 commented 2 years ago

Migration from c++ to C#

tonyqus commented 2 years ago

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 commented 2 years ago

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

lloydjatkinson commented 2 years ago

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

PaulDotNet commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

skimhugo commented 2 years ago

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

DBJDBJ commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 7 months ago

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

DBJDBJ commented 7 months ago

WTL

loxsmoke commented 7 months ago

Would be cool in 1995

J0nathan550 commented 2 months ago

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

avalonia

J0nathan550 commented 2 months ago

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

MAUI sucks Avalonia is better