
Fixing a Small Calc.exe Bug - cryoW0lf
https://www.petertissen.de/?p=77
======
cududa
This is _hilarious_!

Some of you might recall how all Zune devices died on 12/31/08.

Windows_Globalization_Calendar_AddMonths_System_Int32 was the root of it all,
apparently.

(For further reading on the Zune outage:
[https://techcrunch.com/2008/12/31/zune-bug-explained-in-
deta...](https://techcrunch.com/2008/12/31/zune-bug-explained-in-detail/))

~~~
King-Aaron
Also reminds me of the old "Printer won't print on Tuesdays" bug

[https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...](https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28)

~~~
decasia
I mean, this is a great example of how complex systems exhibit unpredictable,
emergent behavior. You think you are doing some process X (say, printing), but
it turns out that X relies on some more generic layer Y (a file utility layer)
which is running a set of arbitrary filter functions that you have no idea
exist. One of these filters then happens to check for some magic strings in
your data. And these hardcoded strings turn out to be strings that can also
occur in unrelated kinds of data...

What's the underlying issue, really? Is it that detecting file types by
checking for magic strings is always a bad idea? Or is it something more basic
about the architecture here, more like the leaky abstractions problem?

~~~
anyfoo
The problem here is that the printing pipeline uses the ‘file’ tool to detect
what the data to be printed is (e.g. PostScript), but ‘file’ can only ever
guess the content of a file. It is a heuristic, and as soon as you have a
heuristic, you will always run into cases where it gives a wrong result
(otherwise it’s not a heuristic anymore, obviously).

So, I would actually disagree with the author that it is strictly a bug in the
‘file’ utility, as there is simply no completely reliable way to determine
intended file type by just looking at the content[1]. You have to transmit
that information out of band, and this is why we have MIME types sent through
Content-type: headers in HTTP or email headers. File extensions are another
method (though also ambiguous: .TXT and .EXE are almost certain, but a .DB or
.BAK can be one of many things).

CUPS is probably applying this heuristic for convenience (“send anything to
your printer and it just prints!”), at the cost of correctness.

[1] A simple proof for that is the existence of “polyglots”, which in this
context are source code that happens to be a valid program in two or even more
different programming languages (often doing the same or similar things for
sport). Were CUPS to differentiate printing based on the programming language,
e.g. by applying different syntax highlighting, it would not know what
language to choose, and without out of band information there hardly even is a
“right” answer. In practice though you can detect a file type more reliably
than ‘file’, but at much more complexity than “let’s check some magic numbers
in some offsets to give the user an idea of what this might be”, and it still
wouldn’t be perfect.

~~~
ygra
It still _is_ a bug in the data for file, though. As the respective bug
states, the spaces should have been escaped and so file actually misidentified
everything with »Tue« in that place of the file contents as the wrong type.

------
_bxg1
Impressively, they did actually merge the fix:
[https://github.com/microsoft/calculator/pull/553](https://github.com/microsoft/calculator/pull/553)

It's good to see that Microsoft's "open source" programs aren't just code-
dumps

~~~
btown
For what it's worth, VS Code merges a tremendous number of PRs from the
community, despite having a dedicated team:
[https://github.com/microsoft/vscode/pulls?q=is%3Apr+is%3Aclo...](https://github.com/microsoft/vscode/pulls?q=is%3Apr+is%3Aclosed)

New MSFT really "gets" open source. It's an exciting time.

~~~
_bxg1
Sure- but that was conceived from the beginning as an open-source project, and
isn't even truly "compiled"; it's designed to be hackable. Calc.exe is a core
Windows utility, and was open-sourced after the fact.

~~~
oldmanhorton
Chakra was a many years old code base that was open sourced a few years ago,
and we got a large number of pull requests from the community merged and
shipped with windows and in chakracore releases. Object.fromEntries is one
that immediately comes to mind but I know there were more. It happens across a
lot of our projects!

------
DigitalTerminal
Time is hard. But like what does it even mean to say something is 4 months
away when the months could be different lengths? 4 months is a shorter time if
that period includes the end of February. This fixed result is strange but
does it even matter?

~~~
tremon
_what does it even mean to say something is 4 months away when the months
could be different lengths?_

The same thing it means when something is 2 years away when the years could be
different lengths?

The month is a well-defined unit _within the context of a certain calendar_.
And since a normal date representation contains the month as a singular
component, month additions are usually well-defined (the obvious exception
being, adding N months to yyyy-mm-31 -- the result is undefined, though most
people will assume it to refer to the first day of the month following).

There is no need to bring mathematical strictness into it, because months are
never used for that purpose. Moreover, no calendar system is built for
mathematical strictness anyway, so arguing for that kind of strictness is like
building a house on quicksand.

~~~
bscphil
You're right, but I think the problem does arise for "four and a half months
away". That actually requires you to pin down how many days are in a month.

~~~
gumby
It only requires you to know how many days are in _each_ month, and you have
to know what you’re counting. That’s the problem with calc: it discards the
semantics of “how I got here,”

~~~
organsnyder
I think it's more complicated, and depends on assumptions made by the speaker
and the listener: if I say "two and a half months from now", is the half-month
equal to 15 days or 14? If the target duration is February, perhaps I'd assume
14; but otherwise I probably assume 15; but what if February is one of the
whole months in between?

In my experience (in my culture), we avoid these problems by just assuming
that we'd never convey a precise date in this manner: anything more than a
week away we tend to convey with the exact date (March 15th); or, we might say
"exactly two weeks from today" or "exactly one month ago" (implying the same
numerical day-of-month, regardless of how long each month is), but I don't
think we'd ever say "exactly one and a half months from now".

And this is why calendars are hard: it's as much (or more) anthropology as it
is arithmetic.

------
piyush_soni
Interesting. This bug is reproducible in the 'new' Windows 10 calculator store
app, but not in the old Windows 7 calc.exe. So looks like a regression, unless
they completely re-wrote the whole calculator app (for which there seems to be
no reason).

~~~
chungy
> unless they completely re-wrote the whole calculator app (for which there
> seems to be no reason).

That's actually exactly what happened. The original calc.exe (in all versions
up to Windows 8.1) came from Windows 1.0, in plain C, very seldomly updated
over the years.

The one in Windows 10 is totally rewritten in C++ using the "Universal Windows
Platform" as an API rather than classic Win32.

~~~
ygra
The Windows 10 UWP calculator retains the math engine from before, which
actually _has_ been rewritten. The ancient calculator used standard floating-
point math, with the fun problems that entails, like 0.1 + 0.1 showing
0.19999999998. The current engine uses rational numbers as long as possible
and configurable precision for trigonometry, roots, etc. It also got further
upgraded over the years so that the root of a perfect square is always an
integer.

As for the bug in question, it could not have happened in the old calculator,
as that one didn't have the date math panel.

So for the UWP version they merely redid the UI and added a few things. The
actual calculator part is still the same as before (just open-source now).

~~~
piyush_soni
Are you saying that the 'old' (i.e. Windows 7 calculator) didn't have a Date
calculation panel? Because I'm seeing it right now in front of me.

~~~
moftz
I had no idea that was in there along with all of the other things like a PMT
calculator and unit conversion. I would normally switch to the scientific
calculator after getting a fresh Windows 7 and never open that menu again.

------
pfyra
I just tried the same thing on Windows 7 and got some curious results:

    
    
      From July 31 2019 to Dec 30 2019: "5 months; 6 days", 152 days
      From July 31 2019 to Dec 31 2019: "5 months", 153 days
    

I agree that there are 153 days from July 31 to Dec 31 (aug+sep+oct+nov+dec =
31+30+31+30+31 = 153) but I'd say that there are too many Februaries among the
months in the first result.

------
xtracto
Somewhat offtopic but this reminded me of a tutorial from ages ago which
showed how to add line numbers to notepad.exe . It was part of the things I
followed while learning about cracking and reverse engineering.

I remember being super happy when I replicated the functionality, using
wdasm32 and HIEW to patch my notepad code.

~~~
KennyFromIT
Link to tutorial?

~~~
xtracto
Oh man, this was ages ago, so I don't even know if it is still available on
the web.

The best I could found is a similar tut where they are adding other features
to notepad:

[http://www.kaoteq.com/sites/fravia/fravia-
darkridge/nnhnpad....](http://www.kaoteq.com/sites/fravia/fravia-
darkridge/nnhnpad.htm)

This brought me lots of memories, learning from +ORC, tKC and +HCU was the
bomb back when I was in University.

I could not find the one specific for adding line numbers though.

------
dboreham
"Never work with children, animals, or calendar math.."

------
zerr
It should be clarified in the title that it is about the UWP calc not the
original Win32 calc.exe.

------
dhekitha
This blog is the general information for the feature. You got a good work for
these blog.We have a developing our creative content of this mind.Thank you
for this blog. This for very interesting and useful.

[https://www.gangboard.com/business-intelligence-
training/tab...](https://www.gangboard.com/business-intelligence-
training/tableau-
training?utm_source=backlinks&utm_medium=cmt&utm_campaign=coursepage&utm_term=tableau&utm_content=jp)

------
EdSchouten
Why did this change get merged without a unit test?

~~~
iruoy
I've noticed a new way GitHub can show tests. There's a new checks tab at the
top of the issue. There[0] you'll find thatall unittests were successfull.

[0]
[https://github.com/microsoft/calculator/pull/553/checks](https://github.com/microsoft/calculator/pull/553/checks)

~~~
Illniyar
I think he meant that unit tests were not added for the scenario detailed.

------
CaliforniaKarl
One thing I find interesting, and which I like: As far as I can tell, this
commit was merged without the submitter needing to sign a CLA or otherwise
assign copyright.

~~~
lwf
The author signed a CLA. "7 checks passed", and if you click "View Details"
you see:

> license/cla All CLA requirements met.

Also mentioned in
[https://github.com/microsoft/calculator/blob/master/CONTRIBU...](https://github.com/microsoft/calculator/blob/master/CONTRIBUTING.md#contributor-
license-agreement)

~~~
CaliforniaKarl
That's good to know, and annoying, but also a little confusing.

The page you linked indicates that a bot will comment on the PR. I am looking
at
[https://github.com/microsoft/calculator/pull/553](https://github.com/microsoft/calculator/pull/553),
but I do not see any bot-generated comments, other than the "All CLA
requirements met." status line you mentioned; and I do not see a "cla-signed"
or a "cla-not-required" tag on the PR.

Still annoying, regardless.

~~~
fireattack
It says "you only need to do it once for Microsoft projects on GitHub". So
maybe the author signed it before.

------
pts_
The PR is not merged yet. They better do it before July 31st!

~~~
LoSboccacc
eh, it still gives a wrong result, except one is visibly wrong and the other
subtly wrong.

~~~
pts_
It's merged but not released yet I guess.

~~~
joshschreuder
I don’t think we’re at the point where Microsoft is doing Continuous
Deployment to millions of Windows PCs for calc.exe :)

------
VMG
A "month" is a poorly defined unit of time and shouldn't be used to describe a
duration.

~~~
ibejoeb
Months are pretty well and exhaustively defined. There are 13 of them. It's
just that it's not enough to say that there is a 3-month interval. You need to
specify either the dates or the months.

To say months shouldn't be used is sort of like saying that complex numbers or
vectors shouldn't be used. They are absolutely useful. We just deal with their
component parts separately.

~~~
orting
A month is not a well defined unit. There are four different month units: 28,
29, 30, 31 days. If you do calculations respecting this there will be no
problem.

Complex numbers and vectors are not a good analogy.

~~~
xelxebar
I believe you fail to grok GP's point.

The mapping from "month" units to "days" units is well-defined. It's just some
function that happens to be non-constant over the month ordinal.

Heck, if we start down the "precise time definition" rabbit hole, though, then
neither does "day" have some philosophically unassailable notion, _cf._ leap
seconds. Even the unit of "second" ends up pulling in a whole heck of a lot of
physics machinery just to nail down some semblance of rigor.

Anyway, despite being such an intuitively simple and practically functional
concept, the notion of time amd time measurement turns out to be suprisingly
subtle and to have a fascinating history. I highly recommend jumping down that
rabbit hole. Hehe

Anyway, I'm surprised calc.exe doesn't calculate with and store dates using
some kind of epoch time.

------
hzhou321
Never use an unsigned type for numbers.

------
alexstromberg
Hi

------
ngcc_hk
After reading it, I think it is an acceptable bug. Just can’t test it.

May be the strategy when doing this is change to a different approach. Not
calc as in unix or try hard to do it. But to it as a separate rule based
program.

------
Yuioup
OMG why does this get repeated constantly. Microsoft released the source code
to Windows Calculator, a Windows Store App. They did not release the source
code to the venerable calc.exe

~~~
airstrike
I think the software referenced in the article is the only calculator you get
on Windows 10, and the binary _is_ named calc.exe so you're technically
correct and incorrect at the same time

~~~
ntauthority
No, it's named something more like "Calculator.exe", but calc.exe is a stub
that will just activate the UWP app if present so that people and software can
still invoke calc.exe.

The old calculator was briefly shipped as a separate component called
"win32calc.exe" in 10-based versions without apps, and that's what the
calc.exe stub defers to in those cases.

~~~
bexsella
It's not important, but you're definitely wrong here.

------
kabwj
You said calc.exe and I thought you meant the one that’s closed source. I
imagined you using IDA to find and fix the bug. This is definitely not as
cool.

Also, props for working for free for a multibillion corporation.

~~~
gattilorenz
> Also, props for working for free for a multibillion corporation.

Sure, because no one should be proud of fixing a bug for the millions of
people that use that operating system. Satisfying intellectual curiosity and
helping somebody for free, the big evils of our time!

