microsoft/calculator: the in-box Windows Calculator, its graphing gap, and its mock data

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

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. Treat the claim as scoped exactly as written: basic operations only.

The repository holds both C++ and C#. 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 README 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, 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 README provides. Nothing in the README 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-10-02. The repository has no published GitHub releases, 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.

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.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/calculator on GitHub
4. README