maar mooi spul hoor dat exchange....

Helaas blijft het niet bij MS,
We merken in productie dat andere applicaties (meeste 32 bit versies) ook problemen hebben.

Hoor ook om me heen dat het daar niet goed gaat met applicaties.

- FluFFy

Ongelooflijk. In de 70/80-er jaren waren 'bytes' nog duur.
Hoe oud is die software eigenlijk?

De "oplossing" is dat Microsoft extra data heeft gecreëerd in december. 1 januari 20211232###### en 2 januari 20211233######. Het zal vast opgelost worden in de volgende CU die is uitgesteld (en in december had moeten komen).

Met andere woorden, de oplossing is eigenlijk een temporary solution en werkt alleen, omdat kennelijk invalid dates toch valid zijn. Nieuwe entry voor mogelijke maliscious entries? Even om in je achterhoofd te houden dit. Er bestaat namelijk geen 20211233, 20211234, etc etc.

Wat me echt opvalt in de industry, en dat is echt breder dan alleen dit, is de hoeveelheid bugs, fixes, halve fixes, of andere problemen bij providers van datalijnen er momenteel zijn. Lijkt echt alsof de kwaliteit onder druk staat. Mogelijk gevolg van het remote werken, waarbij het "koffie apparaat momentje" er niet meer is? Oftewel het ohja momentje?

ik denk dat je de oorzaak gaat vinden in perverse prikkels waar bedrijven mee te maken hebben die nu in corona tijd (crisis) uitvergroot worden omdat ze niet meer zo eenvoudig 'gemaskeerd' kunnen worden. net als houtrot, zodra je het ziet...

Pas 17 jaar. Dan verwacht je dat de meeste bugs er toch wel uit zijn he. Niet genoeg eye balls.

Ik kan me de commotie nog herinneren van 22 jaar geleden, toen veel oudere software ook aangepast moest worden omdat het datumveld te klein was.*

Rond de eeuwwisseling was het geheugengebruik van een datumveld zo goedkoop dat het onbegrijpelijk is dat men sindsdien niet 100 jaar vooruit dacht bij het schrijven van code.

*) Een collega programmeur moest in die tijd een financieel programma controleren op deze millennium bug. Hij mocht echter niet gelijktijdig de BTW bug fixen. Het BTW percentage stond nml als een fixed getal in de code en het was toen al bekend dat de btw in 2001 weer aangepast zou gaan worden. Het percentage was zelfs al bekend. Op die manier wist het bedrijf zeker dat hun klanten het daar daarop weer een update moesten kopen.

Ik moet me toch enigszins inhouden, wat knullig.

man,man,man.
echt.
Ze hadden 22 jaar de tijd om voor een oplossing te komen.

Ik heb ooit nog wel meegewerkt aan een pakket waarin BTW wel configureerbaar was maar het percentage was 2 cijfers
dus altijd een integer. Op een gegeven moment kwam er een BTW percentage met ,5 maar toen was ik allang niet meer
bij dat pakket betrokken, dat heeft vast ook paniek veroorzaakt.

Nou, als je lang genoeg wacht, misschien wel.
Of het wordt de standaard in Windows 13 :)

Ja echt, tijd zat. Waarom zou je er nu dan ook iets aan doen, als je het ook aan je opvolger kan overlaten.

Mogen we iets denken? Powershell? (en dan denk ik iets in de trend van ons-kent-ons de cartoonreeks van demorgen, altijd gemeen(d)!).

Kan hier eigenlijk maar 1 ding over zeggen.

man man man man.

Het geheugengebruik is al heel lang niet duur meer.
Wat wel - en nog steeds - 'duur' is , is werken met datatypes die groter zijn dan de natuurlijke word-size van de processor.
Het kan , en soms moet het , maar het komt zichtbaar en onzichtbaar met veel extra dingen.

In heel kritische secties van code is het nog steeds extreem pijnlijk als een enkele variable groter is dan een cache line / cq de registerbreedte van de processor . ( updates zijn opeens niet meer atomic )

En het heeft best een tijd geduurd voordat een 64-bit integer een 'normaal' datatype werd - ook op 32 bit systemen.
Wie er genoeg bij was heeft het lange proces kunnen zien waarin 'large file support' (files >2 of 4 G) aan Linux werd toegevoegd . Toen de disk-sizes groot werden, maar de CPUs nog veel 32 bit waren.
https://en.wikipedia.org/wiki/Large-file_support

(hint : 2G is de grootste waarde die een signed 32 bit integer kan aangeven, en 4G de grootste waarde van een unsigned 32 bit integer) .

Dat is ook de tijd waarin dit "serie nummer geformat als datum en verwerkt als signed 32 bit integer" geschreven werd.

Een _unsigned_ integer was waarschijnlijk een betere keuze geweest. Maar het is vrij gebruikelijk om een negatieve waarde (-1) te gebruiken als fout-indicactie . Goede kans dat als de "datum" conversie misgaat de functie zo'n waarde returned , en dat het daarom een signed (32 bit) integer is.