Windows Calculator: why does 200 + 10% equal 220?

02. Write down the button sequence

Ask a precise question: what happens when the user enters 200, chooses addition, enters 10, presses percent, then equals? Record the display after percent as well as after equals. The intermediate operand tells you more than the final answer alone.

This is standard-mode behavior. Keep mode, release and key sequence in the test record. Repeated equals, an omitted operand and a second percent press introduce additional state; leave those out of the first experiment.

Investigate Windows Calculator standard-mode percentage behavior with REA. Compare the sequences 200 + 10 % = and 200 × 10 % =. Identify which installed module handles arithmetic, then trace the percent branch and operator-dependent operand transformation. Keep observed instructions, source interpretation and actual GUI input results separate.

03. The launcher may not contain the calculation

Opening a conveniently named executable is not enough. If it dispatches to another application, follow that handoff into the installed package. Record the file you actually analyzed and its hash.

In the upstream investigation, the arithmetic was in CalcViewModel.dll rather than the small calc.exe launcher. The report used analyst-assisted function selection. Its public Microsoft source reference helped interpret operator IDs; that reference was not proven to be the exact source commit of the installed binary.

• Which file contains the arithmetic branch?
• What selects percent, and what records the previous operator?
• Where are the previous value and current entry stored?
• Which arithmetic helpers are reached on each branch?

04. Rebuild the operand transformation first

For addition and subtraction, the entered percentage is relative to the first number. For multiplication and division, it becomes a fraction of 100. The pending operator is applied afterward. Keep those two stages separate in your implementation and in the interface.

Our lab makes you press percent and equals separately so you can see that state change. Editing either input or switching operators starts a fresh sequence. It accepts two finite numbers, not an arbitrary calculator expression.

Implement only this standard-mode two-operand percent behavior: + and − transform the entry to entry × (first / 100); × and ÷ transform it to entry / 100. Keep the transformed operand available for tests. Apply the pending operator only on equals. Handle division by zero, empty input and reset. Do not claim repeated-key or scientific-mode compatibility.

05. Test the intermediate value, not only the answer

Two mistakes can sometimes cancel out and produce the expected final answer. Assert the transformed operand first, then the result. Include subtraction, division, zero and a negative first number so the test suite cannot pass by hardcoding the familiar addition example.

If your fresh Windows run differs, check mode and exact input order before revising the formula. Save the key sequence and display states. The upstream report did not claim a completed original Windows GUI input check, so do not silently inherit one.