3 ms·

That version yes, absolutely. I expect at some point Microsoft will have made enough updates that they will say X version is no longer supported, and it will st

by petee 5y ago

That version yes, absolutely. I expect at some point Microsoft will have made enough updates that they will say X version is no longer supported, and it will stop working on its own. And its not like it's a product installed on some embedded device that will never get updates until then, Exchange will get security fixes for as long as it is exists and nobody will be running this version in 20 years. Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed.

masklinn 5y ago
> That version yes, absolutely. But in your alternate timeline the issue would only have been hit in 2043, and since in our timeline it was not noticed before it was hit, there is no reason to believe it would have been noticed in the alternate. So the exact same issue would have occurred, a few years later. I fail to see why that would be an improvement. > Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed. That is a completely unsubstantiated assertion.
- petee 5y ago
  I'll quote myself again, "Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then" I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there. The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes. Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.

by petee 5y ago

masklinn 5y ago

> That version yes, absolutely. But in your alternate timeline the issue would only have been hit in 2043, and since in our timeline it was not noticed before it was hit, there is no reason to believe it would have been noticed in the alternate. So the exact same issue would have occurred, a few years later. I fail to see why that would be an improvement. > Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed. That is a completely unsubstantiated assertion.

petee 5y ago
I'll quote myself again, "Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then" I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there. The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes. Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.