Már volt értelme a calc.exe kódja megnyitásának

 ( trey | 2019. június 19., szerda - 8:24 )

Egy csúf bug van a W10-ben található calc.exe-ben. Mivel a Microsoft nemrég megnyitotta a forráskódját, valaki úgy döntött, hogy megkeresi a hibát és kijavítja. A javítását be is olvasztották.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Aki egy számológépet nem tud megírni rendesen, annak az operációs rendszerét se használom, mert nem lehet különb.

Másik oldalról, meg jó kihasználják a közösséget, hogy fejlesszen nekik (vagy javítsák ki a hibákat) ingyen, amit ők keményen pénzért értékesítenek!

Most kivételesen a jó oldalát nézem. A manyeyeballs megnézte, megfixálta. Mindenki jól járt, én sem hiszem azt (majd ha a W10-be megjön a javítás, jelenleg szar), hogy szilveszterig még 5 hónapot, 613565756 hetet és 4 napot kell még várnom.

--
trey @ gépház

Az a 613565756 hét hamar eltelik ha van meló és érdekel is. :D

Jó helyen, jó társaságban csak úgy repül az idő :D

(117 99 341 é', mi a', leüli a vété ne'? A taládáé ü, nem máté' ...)

--
trey @ gépház

Igen, gondolom nálatok meg a kódolási munkába beleszól a grafikustól kezdve a pénzügyesen és a HR-esen át a takarítóig mindenki, sőt, csapatok is random beletúrnak a másik csapatok munkájába.

+1, gondolom most a summer intern, aki lekodolta ezt a rendkivul fontos rendszerkompnenst, kapott egy ejnyebejnyet

Megejnyebejnyezni egy ilyen bug miatt egy internt? Nagy rendszer szintu problemak vannak, ahol ezert egy lebaszas jar a rangletra legaljan levonek, ahelyett h. megneznek h. melyik senior alatt sikerult ezt eloadni, mi volt a code-review es mentoring process, milyen tesztek voltak ra irva es hasonlok... Ha mar.

Meg hat amugy is. Az Open Source community jelentos resze epit arra h. alapos teszteket nem kell irni, mert majd manyeyeballs, de ha az M$ csinalja ugyanezt, akkor meg nyilvan jot lehet rajta rohogni es elcelodni. Nem kerdezem meg, hogy ez vajon kettos merce-e. :P (Ezt ugy altalaban veve a kommentekre irtam itt, nem feltetlenul az elottem szolohoz.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

<troll>Az agilisbe ez nem fér bele?</troll>

--
trey @ gépház

Hehe, na igen...

(BTW, amit a cegek 99%-a agilisnek hiv, az minden, csak nem az, de ebbe most ne menjunk bele...)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nyilván. A troll tag nem véletlenül volt ott. Tapasztalatom szerint manapság egyre több helyen az "agilis" a "ki a fasz tudja hogy mi folyik ebben a kuplerájban szoftverfejlesztés címén?" szinonimája :D

--
trey @ gépház

+999999999999999999nagyonsokkilencesmég

> amit ők keményen pénzért értékesítenek!
> calc.exe

okay

Az is ki van fizetve. Vagy nincs? :D

Legalább tudjuk, hogy a kollégánál a calc.exe egy selling point. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Mint szoftverfejlesztő megnyugtatlak, hogy ebben semmi megdöbbentő nincs. 100 soros programban is simán lehetnek hibák. Nem a hibák jelenléte jellemez egy céget (mondjuk egy bizonyos szinten túl már igen) hanem, hogy hogy állnak hozzá.
--
:wq

Nem maga a hiba a probléma, hanem hogy ennyire teszteletlen, minősíthetetlen kódokat képesek kiadni a kezükből úgy, hogy mindezért a fél világ keményen fizet! Ez annyira alap probléma,hogy egy rendes teszten ki kellett volna jönnie. A calc.exe az a komponens, amiben a lehető legkevesebb hibának kéne lennie és nem ennyire szemet szúró, szinte ordító hibának.

Az itthon sok-sok pénzért fejlesztett (velem kapcsolatba kerülő) szoftverek 95%-ban ennél nagyságrendekkel ordasabb tervezési és kivitelezési hibák vannak az állami milliárdos rendszertől a különböző komolyságú ügyviteli rendszereken át a cél-utility szoftverekig bezárólag.

És olyan, hogy unit teszt vagy integrációs teszt, szerinted mennyi olyan fejlesztőnél van, aki Clipper-rel és Visual FoxPro-val kezdte? És ilyenből rengeteg van még üzemben. Mikor a GUI-ban a gomb click eventbe van beírva az adatbázis kezelés kódja?

Clipper-rel kezdte és PowerBuilder-nél tart 2019-ben :D

--
trey @ gépház

A kedvencem tovabbra is az a VisualAge C-ben, OS/2-re irt ipari rendszer volt, aminek a kodja joreszt a main.c-ben helyezkedett el, es egy tobbezer soros switch-case volt, ami a kulonbozo gomblenyomasokat kezelte.

Termeszetesen amellett h. szamos case-ag ugy volt tervezve, hogy a folotte levobol fallthrough-ol break; nelkul, az adatbazis (IBM DB/2) iras/olvasas makrok is itt voltak talalhatok (szepen a sor elejere indentalva, hogy jol olvashato legyen a kod!), valamint a kodduplikaciot elkerulendo a kulonbozo case agak praktikusan egymasba goto-ztak. :)

Mikor a ceg osszerugta a port a (szerzodeses) fejlesztovel, megkertek h. fejlesszek bele valamit (en voltam az ifju-titan sysadmin kolyok akkoriban ott, a 2000-s evek elejen, aki "mindentmegold"). Akkoriban forrofejun nekiugrottam szinte minden kihivasnak, de szerencsere azt a kodot latva azert inkabb az eletosztonom gyozott. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Mesélj még. Lehetőleg valami konkrétumot, hogy te hogyan csinálnád. Meg, hogy mégis mi alapján mondod, hogy a calc.exe az, aminek szükségszerűen a legkevesebb hibával kell rendelkeznie.

Egyébként meglehetősen sok unit test van hozzá, ahhoz képest, hogy csak egy calculator app.

"hogy a calc.exe az, aminek szükségszerűen a legkevesebb hibával kell rendelkeznie."

Azért nem volna baj, hogy a nagy teljesítményű számológépen (ez lenne a számítógép) futó számoló app adott esetben hiba nélkül számolna. Ez lenne mondjuk a minimum elvárás vele szemben.

--
trey @ gépház

Engem ez kevésbé zavar, mint az, hogy a távoli gép tálcáját full screenben néha elrejti a host tálcája.

-----------
Akkor beszélsz igazán jól angolul, ha egy angol viccen őszintén tudsz nevetni

az a baj hogy microsoft. ha meg a linukkban van valami hiba vagy valamelyik openszósz szarjukban akkor legyintenek rá merhát' ingyé' vót' vaze'.

ez ilyen önigazolás, hogy az ubuntu mennyivel jobb választás volt.

khm... khm... linugz világban nincs teszteletlen kód, minden működik, szerintem az idei lesz a linux desktop éve... :)

bugok márpedig vannak. még a fizetős kódokban is...

Ordított, és a fülsértő zajt hallván az emberek először azt hitték, a szomszédos kommunában áldoznak a szent mag hívei. De azért a microsoftosok csak belenéztek a kódjukba, és mindenkinek, aki a hiba felé tekintett, kiszúrta a szemét. Ezért nem tudták meg, honnan jött az ordítás. A Microsoft viszont az államtól kurva sok lóvét felmarkolt vak emberek foglalkoztatásáért.

:)

Van ISTQB tesztelői minősítésem. A legfontosabb dolog a teszttel kapcsolatban, hogy "exhaustive testing is not possible". Ilyen, és ehhez hasonló edge-case-ek bárhol, bármikor átcsúszhatnak. A linux forráskódjában egész biztos, hogy még ilyenebbek is vannak. Azt se használd akkor.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Pont az ilyen eseteket erdemes vizsgalni. Foleg, hogy a konkurencianal evrol evre elojon valami hasonlo bug (iOS az idozona miatt nem ebreszt, lefagy, brickelodik, stb).

Egyebkent sok esetben a kimerito teszt is lehetseges lenne. (vagy valami, ami (pszeudo)random modon sok esetet megvizsgal, hatha elojon egy bugos is)

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szép kis hiba. Gyorsan megnéztem egy Windows 8.1-en, de ott még működik (nincs hét jelzés, lehet azért)

---
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

Nekem a céges win10-ből nem sikerült kicsiholnom ezt a hibát. :)
Csak hónapban illetve napban adja meg a különbséget.

Pontosan ezeket a dátumokat állítottad be?

Ha a regional settings nem magyar, akkor december 31-et állíts be. Időzónafüggő a hiba.

--
trey @ gépház

Céges win 8.1 pro a fenti adatokkal 5 hónap 6 nap, hét nélkül, a 152 nap stimmel. Most kinek higgyek? December 31-gyel 5 hónap, 153 nap...

Ilyen ősi Windowsom nincs. W10-zel van egyébként a probléma. A fenti kép az én Windowsomon készült. Verzió:

Számológép 10.1904.42.0

--
trey @ gépház

Itthoni win10pro hozza a fentit, percre pontosan... :-) számológép: 10.1904.42.0

Detto:
Calculator 10.1904.42.0

Nalam szepen hozza:

5 months, 613566756 weeks, 3 days

Kiszámoltam: karácsonyig már csak 4294967328-et kell aludni.

Nezd at ujra a szamolasodat, mert szerintem 4294967119-et :)

Szerencsére ott a calc.exe. Csak kinyitom és visszaellenőrzöm a számítást!

Szerintem ő is azzal ellenőrizte.

Erről, illetve az algoritmusról valahogy ez jut eszembe. Kicsit nehéz elhinni, hogy .NET-ben nincs beépített megoldás erre, mint mondjuk Java-ban a Period. Illetve elvileg használhatnák a NodaTime Period típusát is, az Apache 2.0 licences tehát felhasználható akár zárt szoftverhez is.

" Kicsit nehéz elhinni, hogy .NET-ben nincs beépített megoldás erre"

A Windows Calculator nem .NET runtime-ban fut, natív C++ app. NodaTime-ot sem tudnának emiatt használni.
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/

C++ chrono-ban pedig tudtommal nincs ilyen számolás, ami megadná két időpont közötti különbséget.

Ez egy elég jó érv. :) Feltételeztem, hogy ha UWP app akkor biztosan .NET.

Viszont ettől függetlenül elég gagyi dolog, hogy nem jól definiált ezek szerint az az algoritmus, amivel két dátum közötti különbséget megállapítjuk, és minden platform maga oldja meg a dolgot. Ennek a tudásnak közkincsnek kellene lennie, hogy ne kelljen minden platformon, nyelven újra feltalálni a spanyolviaszt.

C++20-ban jön.
--
https://naszta.hu

Ha megnyitnák a Windows forráskódját, abba is találnának egy csomó csúf bugot.

A calc.exe-nek meg nem a bugjait kéne javítani, hanem írni Windowsra normális számológépprogramot.


No keyboard detected... Press F1 to run the SETUP

A hibát használat közben találták, nem a forráskódot nézegetve...