原生程序 / 交互案例 / 阅读约 18 分钟
Windows 计算器：为什么 200 + 10% 等于 220？
使用 REA 分析 Windows 计算器的百分号键。对比加法和乘法，分析分支，并测试双操作数演示。
本页内容
01. 拆解之前，先试一试
保持两个数字为 200 和 10。按“应用 %”，第二个数字变成 20；再按“然后 =”，结果是 220。切换到乘法再试一次：第二个数字变成 0.1，最终结果是 20。
200 + 10%
按 %，看看第二个数字如何变化。
用同样的两个数字，先试加法，再试乘法。
双操作数百分比实验，并非完整的 Windows 计算器模拟器。
一个双操作数百分比实验，以及同时检查中间状态和最终结果的测试矩阵。
分析之前实验无需配置。若要分析二进制文件，请准备可供分析的 Windows 计算器安装包，并配置好原生程序分析后端。微软公开源码可用于额外交叉核对。 配置 REA →
02. 记录按键顺序
先明确问题：用户输入 200、选择加法、输入 10、按百分号、再按等号时，究竟发生了什么？记录按百分号和等号后各自显示的内容。中间操作数比单看最终答案提供更多线索。
这是标准模式的行为。请把模式、版本和按键顺序写进测试记录。重复按等号、省略操作数或再次按百分号都会引入额外状态；第一个实验先不涉及这些情况。
使用 REA 分析 Windows 计算器标准模式下的百分比行为。对比 200 + 10 % = 与 200 × 10 % = 两个按键序列。找出安装模块中负责算术的部分，再追踪百分比分支，以及随运算符变化的操作数变换。分别记录实际观察到的指令、对源码的解释和真实 GUI 输入结果。03. 计算逻辑未必在启动程序里
打开一个名字看似正确的可执行文件还不够。如果它把任务转交给另一个应用，就沿着调用继续进入已安装的软件包。记录实际分析的文件及其哈希值。
上游分析发现，算术逻辑位于 CalcViewModel.dll，而非小型启动程序 calc.exe。报告由分析人员辅助选择函数。微软公开源码帮助解释了运算符 ID，但未证明该源码对应已安装二进制文件的确切提交。
- 哪个文件包含算术分支？
- 什么决定执行百分比操作，什么记录上一个运算符？
- 前一个数值和当前输入存在哪里？
- 各个分支会调用哪些算术辅助函数？
04. 先重建操作数变换
对于加减法，输入的百分比相对于第一个数字计算；对于乘除法，则变成除以 100 后的小数。之后才应用待执行的运算符。实现和界面都应把这两个阶段分开。
实验要求分别按百分号和等号，让你看清状态变化。修改任一输入或切换运算符，都会开启新的计算流程。它接受两个有限数值，而非任意计算表达式。
只实现标准模式下的双操作数百分比行为：+ 和 − 将当前输入变为 entry × (first / 100)；× 和 ÷ 将其变为 entry / 100。保留变换后的操作数以供测试。只在按等号时应用待执行的运算符。处理除以零、空输入和重置。不要声称兼容重复按键或科学模式。05. 测试中间值，而不只是最终答案
两个错误有时会相互抵消，得到看似正确的最终答案。先断言变换后的操作数，再断言结果。纳入减法、除法、零和第一个数字为负数的情况，避免测试仅靠硬编码熟悉的加法示例就能通过。
如果你在 Windows 上实际运行得到不同结果，先核对模式和精确输入顺序，再修改公式。保存按键序列和显示状态。上游报告并未声称完成了原版 Windows GUI 输入验证，不要把它当成已经做过的测试。
06. 对比已知结果
将这些结果作为明确的检查点。与它们一致，只能支持这一小段规则，不能证明与整个应用兼容。
| 按键序列 | 按 % 后 | 按 = 后 |
|---|---|---|
| 200 + 10 % = | 20 | 220 |
| 200 − 10 % = | 20 | 180 |
| 200 × 10 % = | 0.1 | 20 |
| 200 ÷ 10 % = | 0.1 | 2,000 |
| 50 + 20 % = | 10 | 60 |
| 6 × 6 % = | 0.06 | 0.36 |
| 200 ÷ 0 % = | 0 | 无定义 |
将两个文件保存在同一文件夹，用 Node.js 运行验证脚本，无需安装软件包。
node check-case-labs.mjs07. 到底验证了什么？
本站针对自己实现的双操作数计算运行数值测试，包含微软公开的示例。我们没有执行微软的测试套件，也没有自动操作已安装的 Windows 应用。重复按百分号、重复按等号、完整表达式解析和科学模式均不在演示范围内。
来源： REA 的计算器证据报告 · 微软固定版本的百分比分支。教程、图示和浏览器实验均独立编写。