11 ms·

Fixing a Small Calc.exe Bug

279 points by cryoW0lf 7y ago

pts_ 7y ago
The PR is not merged yet. They better do it before July 31st!
- elygre 7y ago
  It was merged "yesterday", some 28 hours ago, ref https://github.com/microsoft/calculator/pull/553 https://github.com/microsoft/calculator/pull/553.
- LoSboccacc 7y ago
  eh, it still gives a wrong result, except one is visibly wrong and the other subtly wrong.
  - pts_ 7y ago
    It's merged but not released yet I guess.
    - joshschreuder 7y ago
      I don’t think we’re at the point where Microsoft is doing Continuous Deployment to millions of Windows PCs for calc.exe :)
cududa 7y ago
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-detail/ https://techcrunch.com/2008/12/31/zune-bug-explained-in-deta...)
- King-Aaron 7y ago
  Also reminds me of the old "Printer won't print on Tuesdays" bug https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
  - aurbano 7y ago
    > This bug is causing printing using the brother cups drivers to fail on Tuesdays. Absolutely loved reading through the bug! haha
  - codezero 7y ago
    Wow that’s a zinger! The underlying issue with the file utility is bonkers! https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
  - decasia 7y ago
    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 7y ago
      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.
Yuioup 7y ago
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
- Kipters 7y ago
  The math engine is the same, just the UI layer is different
- airstrike 7y ago
  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 7y ago
    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 7y ago
      It's not important, but you're definitely wrong here.
EdSchouten 7y ago
Why did this change get merged without a unit test?
- fitnesshealth 7y ago
  The PR is not merged yet .
- iruoy 7y ago
  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 7y ago
    I think he meant that unit tests were not added for the scenario detailed.
  - d76d6776yudsy 7y ago
    No, this patch has no unit test.
piyush_soni 7y ago
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 7y ago
  > 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.
  - byte1918 7y ago
    It's also open source https://github.com/microsoft/calculator https://github.com/microsoft/calculator
    - gitgud 7y ago
      This Calculator project was added to GitHub 5 months ago in January now the project has 17,000 stars. Are these real people liking the project or has Microsoft got bots to boost it's open-source reputation... it's especially suspicious now since they own the platform now...
      - onefullclick 7y ago
        There are almost 8 billion people in the world. I think 17,000 people is a small number. And geeks are going to geek and nothing geekier than checking Microsoft Calculator, a simple project that everyone can relate to.
        guardian5x 7y ago
        I think you are right. Another possible explanation would be a big conspiracy though, and probably the government is also involved somehow.
CaliforniaKarl 7y ago
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 7y ago
  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/CONTRIBUTING.md#contributor-license-agreement https://github.com/microsoft/calculator/blob/master/CONTRIBU...
  - CaliforniaKarl 7y ago
    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 7y ago
      It says "you only need to do it once for Microsoft projects on GitHub". So maybe the author signed it before.
    - MikeHolman 7y ago
      Microsoft GitHub projects stopped spamming about CLA a while ago. It will only add a CLA comment to the PR now if you haven't yet signed the CLA and CLA is required. Since this is a one liner, CLA isn't required. But it looks like the CONTRIBUTING.md file wasn't updated to reflect this change.
VMG 7y ago
A "month" is a poorly defined unit of time and shouldn't be used to describe a duration.
- AndrewDucker 7y ago
  And yet people do.
  - lifthrasiir 7y ago
    Because approximate durations suffice for casual conversation. When you are talking about the exact date (as computers do) you need something more accurate.
    - C4stor 7y ago
      This example isn't about computer communication, it's about John Doe using the windows calculator to find the time between two dates.
      - lifthrasiir 7y ago
        Does that matter? It is clear that the duration between 2015-05-15 [1] and 2019-06-19 is about 2019 - 2015 = 4 years or exactly 1,496 days (or 1,497 days including both endpoints, yeah this is also somewhat ambiguous). It is much less clear that the duration in question is 4 years, 1 month and 4 days; depending on the use case months can be uniformly 30 days long, may or may count the "excess" days, or even do not matter (in which case the duration would be 4 years and 35 days). Generally such a duration is ambiguous without a context and it would be misleading to present it as exact. [1] https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-2015-05-15 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... (in case you wonder)
        Spivak 7y ago
        I'm not really sure what you're getting it. June 15th 2015 and July 19th 2019 is 4 years 1 month and 4 days apart. That is the duration that occurred between the two dates and is totally unambiguous to non-programmers. The fact that calendar distance and 'time' distance don't have a linear relationship and that math that governs the relationship between the different units isn't straightforward doesn't make it unprecise or misleading. It's totally exact. Just because you can't convert the calendar distance to time distance without context doesn't make it any less exact. Not so different to being unable to compute distance traveled by the revolution count of your wheels.
DigitalTerminal 7y ago
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?
- ngcc_hk 7y ago
  Agree, hard even though one may say a minor program.
- tremon 7y ago
  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 7y ago
    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 7y ago
      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,”
      - 7y ago
pappyvicky 7y ago
This is such a good post. One of the best posts that I\'ve read in my whole life. I am so happy that you chose this day to give me this. Please, continue to give me such valuable posts. Cheers! https://www.gangboard.com/app-programming-scripting/react-js-course?utm_source=backlinks&utm_medium=cmt&utm_campaign=coursepage&utm_term=reactjs&utm_content=sasi https://www.gangboard.com/app-programming-scripting/react-js...
kabwj 7y ago
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 7y ago
  > 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!
ngcc_hk 7y ago
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.
alexstromberg 7y ago
Hi
zerr 7y ago
It should be clarified in the title that it is about the UWP calc not the original Win32 calc.exe.
dboreham 7y ago
"Never work with children, animals, or calendar math.."
pfyra 7y ago
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 7y ago
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 7y ago
  Link to tutorial?
  - xtracto 7y ago
    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.htm http://www.kaoteq.com/sites/fravia/fravia-darkridge/nnhnpad.... 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.
_bxg1 7y ago
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 7y ago
  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%3Aclosed https://github.com/microsoft/vscode/pulls?q=is%3Apr+is%3Aclo... New MSFT really "gets" open source. It's an exciting time.
  - _bxg1 7y ago
    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 7y ago
      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!
    - cryoW0lf 7y ago
      Yeah, with the current CEO Microsoft got really active in the OSS Community. Still MS with Telemetry, like in the pre-compiled VSCode, but it's the right direction!
- dangets 7y ago
  I've also been extremely pleased with their acceptance, communication, and turn around with bugs filed on the mssql-jdbc driver. Code is typically fixed and new versions published fairly regularly. I hope they keep it up. https://github.com/microsoft/mssql-jdbc https://github.com/microsoft/mssql-jdbc
hzhou321 7y ago
Never use an unsigned type for numbers.
dhekitha 7y ago
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/tableau-training?utm_source=backlinks&utm_medium=cmt&utm_campaign=coursepage&utm_term=tableau&utm_content=jp https://www.gangboard.com/business-intelligence-training/tab...

279 points by cryoW0lf 7y ago

pts_ 7y ago

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

elygre 7y ago
It was merged "yesterday", some 28 hours ago, ref https://github.com/microsoft/calculator/pull/553 https://github.com/microsoft/calculator/pull/553.
LoSboccacc 7y ago
eh, it still gives a wrong result, except one is visibly wrong and the other subtly wrong.
- pts_ 7y ago
  It's merged but not released yet I guess.
  - joshschreuder 7y ago
    I don’t think we’re at the point where Microsoft is doing Continuous Deployment to millions of Windows PCs for calc.exe :)

cududa 7y ago

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-detail/ https://techcrunch.com/2008/12/31/zune-bug-explained-in-deta...)

King-Aaron 7y ago
Also reminds me of the old "Printer won't print on Tuesdays" bug https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
- aurbano 7y ago
  > This bug is causing printing using the brother cups drivers to fail on Tuesdays. Absolutely loved reading through the bug! haha
- codezero 7y ago
  Wow that’s a zinger! The underlying issue with the file utility is bonkers! https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
- decasia 7y ago
  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 7y ago
    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.

Yuioup 7y ago

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

Kipters 7y ago
The math engine is the same, just the UI layer is different
airstrike 7y ago
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 7y ago
  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 7y ago
    It's not important, but you're definitely wrong here.

EdSchouten 7y ago

Why did this change get merged without a unit test?

fitnesshealth 7y ago
The PR is not merged yet .
iruoy 7y ago
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 7y ago
  I think he meant that unit tests were not added for the scenario detailed.
- d76d6776yudsy 7y ago
  No, this patch has no unit test.

piyush_soni 7y ago

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 7y ago
> 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.
- byte1918 7y ago
  It's also open source https://github.com/microsoft/calculator https://github.com/microsoft/calculator
  - gitgud 7y ago
    This Calculator project was added to GitHub 5 months ago in January now the project has 17,000 stars. Are these real people liking the project or has Microsoft got bots to boost it's open-source reputation... it's especially suspicious now since they own the platform now...
    - onefullclick 7y ago
      There are almost 8 billion people in the world. I think 17,000 people is a small number. And geeks are going to geek and nothing geekier than checking Microsoft Calculator, a simple project that everyone can relate to.
      - guardian5x 7y ago
        I think you are right. Another possible explanation would be a big conspiracy though, and probably the government is also involved somehow.

CaliforniaKarl 7y ago

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 7y ago
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/CONTRIBUTING.md#contributor-license-agreement https://github.com/microsoft/calculator/blob/master/CONTRIBU...
- CaliforniaKarl 7y ago
  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 7y ago
    It says "you only need to do it once for Microsoft projects on GitHub". So maybe the author signed it before.
  - MikeHolman 7y ago
    Microsoft GitHub projects stopped spamming about CLA a while ago. It will only add a CLA comment to the PR now if you haven't yet signed the CLA and CLA is required. Since this is a one liner, CLA isn't required. But it looks like the CONTRIBUTING.md file wasn't updated to reflect this change.

VMG 7y ago

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

AndrewDucker 7y ago
And yet people do.
- lifthrasiir 7y ago
  Because approximate durations suffice for casual conversation. When you are talking about the exact date (as computers do) you need something more accurate.
  - C4stor 7y ago
    This example isn't about computer communication, it's about John Doe using the windows calculator to find the time between two dates.
    - lifthrasiir 7y ago
      Does that matter? It is clear that the duration between 2015-05-15 [1] and 2019-06-19 is about 2019 - 2015 = 4 years or exactly 1,496 days (or 1,497 days including both endpoints, yeah this is also somewhat ambiguous). It is much less clear that the duration in question is 4 years, 1 month and 4 days; depending on the use case months can be uniformly 30 days long, may or may count the "excess" days, or even do not matter (in which case the duration would be 4 years and 35 days). Generally such a duration is ambiguous without a context and it would be misleading to present it as exact. [1] https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-100-2015-05-15 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... (in case you wonder)
      - Spivak 7y ago
        I'm not really sure what you're getting it. June 15th 2015 and July 19th 2019 is 4 years 1 month and 4 days apart. That is the duration that occurred between the two dates and is totally unambiguous to non-programmers. The fact that calendar distance and 'time' distance don't have a linear relationship and that math that governs the relationship between the different units isn't straightforward doesn't make it unprecise or misleading. It's totally exact. Just because you can't convert the calendar distance to time distance without context doesn't make it any less exact. Not so different to being unable to compute distance traveled by the revolution count of your wheels.

DigitalTerminal 7y ago

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?

ngcc_hk 7y ago
Agree, hard even though one may say a minor program.
tremon 7y ago
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 7y ago
  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 7y ago
    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,”
    - 7y ago

pappyvicky 7y ago

This is such a good post. One of the best posts that I\'ve read in my whole life. I am so happy that you chose this day to give me this. Please, continue to give me such valuable posts. Cheers! https://www.gangboard.com/app-programming-scripting/react-js-course?utm_source=backlinks&utm_medium=cmt&utm_campaign=coursepage&utm_term=reactjs&utm_content=sasi https://www.gangboard.com/app-programming-scripting/react-js...

kabwj 7y ago

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 7y ago
> 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!

ngcc_hk 7y ago

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.

alexstromberg 7y ago

zerr 7y ago

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

dboreham 7y ago

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

pfyra 7y ago

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 7y ago

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 7y ago
Link to tutorial?
- xtracto 7y ago
  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.htm http://www.kaoteq.com/sites/fravia/fravia-darkridge/nnhnpad.... 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.

_bxg1 7y ago

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 7y ago
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%3Aclosed https://github.com/microsoft/vscode/pulls?q=is%3Apr+is%3Aclo... New MSFT really "gets" open source. It's an exciting time.
- _bxg1 7y ago
  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 7y ago
    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!
  - cryoW0lf 7y ago
    Yeah, with the current CEO Microsoft got really active in the OSS Community. Still MS with Telemetry, like in the pre-compiled VSCode, but it's the right direction!
dangets 7y ago
I've also been extremely pleased with their acceptance, communication, and turn around with bugs filed on the mssql-jdbc driver. Code is typically fixed and new versions published fairly regularly. I hope they keep it up. https://github.com/microsoft/mssql-jdbc https://github.com/microsoft/mssql-jdbc

hzhou321 7y ago

Never use an unsigned type for numbers.

dhekitha 7y ago

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/tableau-training?utm_source=backlinks&utm_medium=cmt&utm_campaign=coursepage&utm_term=tableau&utm_content=jp https://www.gangboard.com/business-intelligence-training/tab...