microsoft/calculator: the in-box Windows Calculator, its graphing gap, and its mock data
Windows Calculator: A simple yet powerful calculator that ships with Windows
At a glance
- What is it?
- Windows Calculator is the MIT-licensed UWP app that ships with Windows, written in C++ and C#. Reading the repository tells you what a developer build actually contains: a mock graphing engine, planet-based currency data, and a Windows 11 build 22000 floor.
- Who is it for?
- Adopt the repository if you want to read or modify the UI of the calculator that ships with Windows, or to reuse its XAML and calculation structure in your own UWP app. Do not adopt it if you need working graphing or live currency conversion, because the graphing engine is proprietary and absent, and the currency data in developer builds is mock data that references planets.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the repository actually contains, and who it is for
The README describes Windows Calculator as a modern Windows app written in C++ and C#, pre-installed with Windows, offering standard, scientific and programmer modes plus converters for units and currencies. The repository is the source of that app, published under the MIT License with copyright held by Microsoft Corporation. It is not a library you add to a project. It is an application, and the material gives no package identifier or NuGet artifact, so the practical way to consume it is to clone it and build it.
The audience is narrower than the feature list suggests. The prerequisites demand Windows 11, build 22000 or newer, a Visual Studio install with the Universal Windows Platform Development workload, the optional C++ Universal Windows Platform tools component, and the latest Windows 11 SDK. That rules out building on macOS or Linux, and rules out Windows 10 machines. If you want to study how a shipping first-party UWP app is organised, this is a readable target. If you want a cross-platform expression evaluator, this is the wrong repository and no amount of reading will change that.
Two evaluation models, infinite precision, and the C++/C# split
The README draws a distinction between the standard mode, which evaluates commands immediately as they are entered, and the scientific mode, which evaluates commands using order of operations. That is not a cosmetic difference. It means the two modes do not share a single evaluation path, and a change to operator precedence behaviour in one mode does not automatically reach the other. Anyone modifying arithmetic behaviour has to check both.
For basic arithmetic (addition, subtraction, multiplication, division) the README states the app provides infinite precision, linking to arbitrary-precision arithmetic, so that calculations never lose precision. The README does not say which numeric type backs this, and the supplied material does not name one. Treat the claim as scoped exactly as written: basic operations only.
The repository holds both C++ and C#. The topics list includes cpp, csharp, uwp, windows, xaml and the Windows 10 and Windows 11 tags. The README points to docs/ApplicationArchitecture.md for a general description of the architecture, and to src/Calculator.slnx as the solution to open. The material does not break down which components are C++ and which are C#, so any claim about the boundary between them would be guesswork.
The graphing engine is not in this repository
Graphing mode is listed on the roadmap, and the README is direct about the split. The UI from the official in-box Windows Calculator is part of the repository. The proprietary Microsoft-built graphing engine, which the README says also drives graphing in Microsoft Mathematics and OneNote, is not. Developer builds therefore have no graphing functionality, because the code builds against a mock implementation of the engine in src/GraphingImpl/Mocks on top of a common graphing API in src/GraphingInterfaces.
This is the single most important fact about the project for anyone evaluating it as a graphing calculator. You can work on the interface. You cannot ship the engine, because you do not have it. If your goal is a working graphing calculator, this repository gives you the shell and an interface definition, not the maths. The interface directory is the useful artifact here: it tells you what surface a replacement engine would have to satisfy, without telling you how the original satisfies it.
Currency conversion in developer builds uses planet data
The README states that the currency converter uses mock data in developer builds, and that the data Microsoft uses for the retail version is not licensed for your use. The mock data is described as clearly identifiable because it references planets instead of countries, and it stays static regardless of selected inputs. The feature list separately says currency conversion is based on data retrieved from Bing. Those two statements describe different builds: the shipped app talks to Bing, the developer build does not.
So a developer build cannot be used to validate anything about live rates, offline behaviour, or failure handling when the network is unavailable. The static planet data will not exercise those paths. Anyone planning work on the converter should assume the real data path is outside the repository and that the mock is a placeholder with no relationship to the production feed.
Building it, and the diagnostics flag
The clone command in the README is git clone https://github.com/Microsoft/calculator.git. After that, open src\Calculator.slnx in Visual Studio to build and run the app. There is no separate build script documented in the material, and no command-line build invocation is given.
Diagnostic data is disabled in development builds by default, according to the README, and can be enabled with the SEND_DIAGNOSTICS build flag. The README also notes that the project collects usage data and sends it to Microsoft, with a link to the privacy statement. The flag name is the only configuration key the supplied material provides. Nothing in the material describes CI beyond a badge pointing at .github/workflows/action-ci.yml.
UI tests need Windows Application Driver, and the README links to the WinAppDriver releases page. It does not give the test command. That is a gap worth noting before you plan a test-driven change: you will have to read the workflow file or the test projects to find out how the suite is invoked.
Where this is the wrong tool
The build floor is the first hard limit. Windows 11 build 22000 or newer is required, so a team standardised on Windows 10 cannot build the current source. The second is the missing engine, covered above. The third is the mock currency feed. Taken together, a developer build is a UI and arithmetic target, not a feature-complete calculator.
There is also a licensing asymmetry that is easy to miss. The repository is MIT, but the README says the currency data Microsoft uses is not licensed for your use, and the graphing engine is proprietary and simply not present. The MIT grant covers the code in the repository. It does not cover the data or the engine, because neither is in the repository. Nothing here is legal advice, but the practical reading is that a fork inherits the code and the interface definitions, and has to supply its own data feed and its own graphing implementation if it wants those features.
What a real alternative looks like: a library instead of an app
The clearest contrast is with an embeddable expression library such as mXparser or NCalc, which you reference from your own code and call to evaluate a string. Windows Calculator is the inverse shape. It is a complete UWP application with XAML views, a solution file, a Windows 11 SDK requirement and a Visual Studio workload, and the README offers no supported way to consume its arithmetic as a component. You take the whole app or you take nothing.
The difference in approach shows up in what you get. A library hands you an evaluator and leaves the interface, history, memory and unit conversion to you. This repository hands you the interface, history, memory and converters, and leaves you to extract the evaluator if that is what you wanted. Neither is better in the abstract. They fail in opposite directions: the library gives you no UI, and the app gives you no reusable package boundary. If your requirement is a numeric engine inside a service, the library shape matches it and this repository does not.
Maintenance cost and what the licence does not carry
The README says Calculator ships regularly with new features and bug fixes, and points to docs/Roadmap.md for plans and release schedule. The repository is not archived and the last push recorded is 2026-08-25. No releases were retrieved for this review, so there is no version number to cite and no changelog to inspect. If you fork, you are tracking a moving target whose release cadence is documented in the roadmap file rather than in release artifacts you can pin against.
The upgrade cost is dominated by the toolchain, not the code. Visual Studio with the UWP workload, the optional C++ UWP tools component, the latest Windows 11 SDK, the XAML Styler extension, and WinAppDriver for UI tests. Each of those is a moving dependency you re-satisfy on a new machine or a new CI image. The MIT licence lets you modify and redistribute the code with the copyright notice intact. It does not extend to the currency data or the graphing engine, and the README is explicit that the retail currency data is not licensed for your use. A fork that wants live rates has to source them separately.
Editorial conclusion
Adopt the repository if you want to read or modify the UI of the calculator that ships with Windows, or to reuse its XAML and calculation structure in your own UWP app. Do not adopt it if you need working graphing or live currency conversion, because the graphing engine is proprietary and absent, and the currency data in developer builds is mock data that references planets. Before you clone, verify that your machine runs Windows 11 build 22000 or newer, that your Visual Studio install includes the Universal Windows Platform Development workload plus the optional C++ UWP tools component and the latest Windows 11 SDK, and that you have the XAML Styler extension. Then open src\Calculator.slnx and confirm what the build produces before planning any work on top of it.
Community notes