K: Metakérdés: egy konkrét személyről van itt szó?
V: Természetesen nem, Bobó (korábban más név állt itt, de rájöttem, hogy az valós személyeket sérthet) a mindnyájunk lelkében élő ihletett programozó, aki nem tervez, nem gondolkozik, csak lelkesen beleveti magát a munkába, aztán utána az özönvíz.
K: Csak ennyi?
V: Kell még hozzá némi egészséges hübrisz, ami nem engedi, hogy a hibáinkat elismerjük és javítsuk.

K: Mit tett értünk Nyomasek Bobó?
V: Ő erőltette a szóközt tartalmazó fájl- és könyvtárneveket, mint "Program Files" és "Documents and Settings".

K: De ha azt leszámítjuk, akkor mit tett a fájlnevekért?
V: Támogatta és ajánlotta az ékezetes betűk és speciális jelek használatát a fájlnevekben, az ő sugallatára születnek a Kedves Jenő Bácsi!.docx-szerű fájlnevek.

K: Na jó, de azon kívül?
V: Ő találta ki, hogy a 64-bites Windows-komponensek a System32 könyvtárba kerüljenek, azoknak a kedvéért, akik képesek a 32-bites programjukat 64-bitesre átalakítani, de az meghaladja a képességeiket, hogy ezen átalakítás során a programjukban a 'system32' könyvtárnév összes előfordulását 'system64'-re cseréljék.

K: Na jó, de azon kívül?
V: Az előbbiekkel kapcsolatban kitalálta azt is, hogy egy-egy könyvtár neve attól függjön, hogy ki kérdezi, például 'c:\users' vagy 'c:\felhasználók'; 'c:\program files (x86)' vagy 'c:\program files'

K: De az ismert fájlkiterjesztések elrejtése, na arról csak nem állítod, hogy nem volt jó ötlet tőle?
V: Nagyon jó ötlet volt, a loveletter-szerű vírusok sokkal kevesebb kárt tudtak volna okozni nélküle.
K: Na jó, de legalább ki lehet kapcsolni az elrejtést...
V: Kivéve a .lnk kiterjesztés elrejtését.
K: Azt miért kivéve?
V: Mert a képernyőn megjelenő ikonfeliratok a Desktop könyvtárban lévő fájlneveken alapulnak, azok pedig *.lnk fájlok. Márpedig furcsa lenne, ha a Sajátgép.lnk-szerű ikonok látszanának a desktopon.

K: És az alternatív adatstreamek koncepciója, arról csak elismered, hogy zseniális!
V: A legmesszebbmenőkig. Mondjuk ne akard archiválni, vagy más fájlrendszerű partícióra átmásolni az ilyen fájlt, mert elveszhetnek az alternatív streamek adatai.
K: Jó, de akkor is remek dolog, hogy így a felhasználó "háta mögött" lehet adatokat tárolni a fájljaiban!
V: Kétségtelenül, de azért örömmel hallanék egy nem rosszhiszemű alkalmazást hozzá. (Tehát nem vírusterjesztés, nem trójai program, nem másolásvédelem.)

K: De a fordítóprogramok fejlesztésében nem vett részt Bobó?
V: Dehogynem, ő találta ki az UB-optimalizálást, vagyis hogy a compiler tudatosan hibás kódot generálhat, ha 'úgy látja, hogy a kódban Undefined Behaviour (UB) van'

K: Na jó, de azon kívül?
V: Továbbá a compiler megteheti, hogy egy 'memset'-et figyelmen kívül hagyjon, ha szerinte a kérdéses memóriát azután már úgysem használja a program. (Biztonsági kérdések nem érdeklik a mi Bobónkat.)

K: De vajon a programozási technikák kifejlesztésében is részt vett?
V: Hogyne, ő találta ki az exception-öket, illetve azok elődeit, például az ONERRORGOTO-t. Zseniális invenció: a program X-pontján fellépő hibát a program Y-pontján kezeljük, mert 'ott nyilván több információ áll rendelkezésünkre arról, hogy mi is lehetett a gond az X-ponton'.

K: De hát vannak olyan függvények/metódusok (pl. a konstruktorok), amik nem tudnak 'hagyományosan' hibát jelezni!
V: És mit gondolsz, ezeket ki találta ki?

K: De mást nem tett a hibakezelésért?
V: Ő találta ki memcpy_s, strcpy_s szerű függvényeket, azok számára, akik nem tudnak egy hossz-ellenőrzést leprogramozni (strlcpy-ről, snprintf-ről sem hallottak), de arra képesek, hogy minden egyes ilyen 'safe' hívás előtt meghívják a set_constraint_handler_s függvényt.
K: Miért nem elég egyszer meghívni, a program elején?
V: Bobó is így gondolja, mivel a programjait egyedül fejleszti, külső komponenseket nem használ. Egyébként eljutna arra a gondolatra, hogy tőle független programrészek bármikor elállíthatják a handlert.
K: Dehát ha nála a hibakezelés amúgy is annyiból áll, hogy 'álljunk le, baj van'?
V: Bingó, ennyiből áll nála a hibakezelés.

K: De mit tett Bobó a C-programozásért?
V: Ő találta ki az 'errno'-t. A felhasználói program a libc-n keresztül kezdeményez egy rendszerhívást, a rendszerhívás visszaadja a hibakódot, a libc pedig, ahelyett hogy továbbítaná a hívónak, egy globális változóba teszi. Persze a multithreading ekkor még az álmok ködös birodalmában sem létezett.

K: Na jó, de azon kívül?
V: Mit gondolsz, ki találta ki a zéró-terminált stringet?

K: Na jó, de azon kívül?
V: Ő találta ki, hogy a nulla 'pointerként' nem feltétlenül csupa nulla bitet jelent, hanem esetleg valamilyen platformfüggő értéket, ami adott esetben meggyorsítja a hibás memóriahivatkozások leleplezését (pl AIX-on hagyományosan 0xdeadbeef értéket használnak ilyen értelemben).
Amikor emlékeztetik arra, hogy memóriaterületeket (amik persze pointereket is tartalmazhatnak) 'bzero'-val vagy 'calloc'-kal szokás inicializálni, azt feleli: hát ne úgy csináljátok!
K: És ha kitalált volna egy INVALID_POINTER szerű szimbólumot, hogy az jelképezhesse platformfüggő invalid pointert?
V: Sajnos ez nem jó: túl flexibilis, kompatibilis megoldás lenne.
K: De még milyen előnye van ennek a nem-nulla nullának?
V: Például szerencsésen elrontja az alábbi makrókat:

#define offsetof(T,F) ((size_t)((char *)&(((T *)0)->F)))
#define sizeofrf(T,F) (sizeof(((T *)0)->F))

K: Azért ezen lehet segíteni egy ügyes kivonással, ugye?
V: Hogyne, de van annál Bobósabb megoldás is:

#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)

K: Ez jó megoldás, nem?
V: Annyira jó, hogy adott esetben ilyen üzenetet fakaszt belőle a clang:

offsetof (struct sockaddr_in, sin_addr.s_addr)
warning: using extended field designator is an extension

K: Ez tulajdonképpen mit jelent?
V: Azt, hogy Bobó addig halmozta egymásra a hibás döntéseket, hogy végül neked kellene szégyenkezned, amiért egy nemtriviális esetre is használni akarod az offsetof-ot.

K: Na jó, de azon kívül?
V: Az a csodás ötlete támadt, hogy a 'NULL' vagyis a nulla-pointert jelentő szimbólum esetleg ne pointer legyen, hanem adott esetben a felhasználó legyen szíves (void *)NULL szerű csodákat alkotni, vagyis a nulla pointert pointerré típuskényszeríteni.

K: Igen, de a libc fejlesztésében részt vett?
V: A gets függvényre a legbüszkébb, de sok más eredménye is van, például a függvények által visszaadott értékek terén, például hogy a fgets siker esetén nem a beolvasott karakterek számát adja vissza.
K: Ugyan, csak meg kell hívni az strlen-t...
V: Ugye?! Hiszen nem valószínű, hogy az inputban NUL-karakter legyen...
K: És hogy a syslog(3)-nak nincs visszatérési értéke (vagyis ha eleve hibás paraméterekkel hívtam meg, arról sem kapok visszajelzést), az is Bobóka érdeme?
V: Bizonyám, és méghozzá segítő jószéndékból: ha lenne visszajelzés, azt a hívó esetleg 'rosszul értelmezné'.

K: És a POSIX-szabványosítás, abban részt vett?
V: Hogyne, az apróságokra is van gondja, például úgy döntött, hogy az usleep feleslegessé vált, hisz ott a nanosleep. (Arról Bobóka nem tud, hogy egyesek olyan programokat szeretnének írni, amik régi, 'nanosleep' előtti gépeken is kell működjenek.)

K: És még milyen unixos szabványosításban segített?
V: Itt van rögtön a terminálkezelés: az elmúlt ötven év nem volt elég ahhoz, hogy kialakuljon az egyetértés, hogy a BackSpace gomb mit kellene csináljon: eltünteni a kurzor előtt álló karaktert, vagy kiírni, hogy ^H , vagy kiírni, hogy ^?.
K: Ebben pontosan micsoda Bobóka személyes érdeme?
V: Például meggyőzte a különféle linux-disztibútorokat, hogy a terminfo-adatbázis csak azért van, hogy legyen mit meghekkelni.

K: De a Windows programozásban mit talált ki?
V: Például az ő leleménye, hogy a 32-bites DLL-ek nem pozíciófüggetlen (PIC) kódot tartalmaznak, így csak akkor lehet őket különböző processzek között megosztani, ha éppen sikerül azonos memóriacímre elhelyezni a virtuális címtartományban.

K: De mást nem talált ki DLL-ügyben?
V: De, azt a gyorsító fogást, hogy a DLL-beli függvények elérése ne csak név, hanem azonosító szám (ordinal) alapján is történhessen. Persze ezek a számok még a Microsoft saját DLL-jeiben sem maradnak állandók, tehát mindenképp meg kell akadályozni, hogy a programunk így linkelődjön.

K: És még mit?
V: Például azt, hogy a 'long' típus 32-bites maradt 64-bites módban is. Ennek két fontos oka volt, az egyik az, hogy Unixban nem így van, a másik az, hogy lehetnek olyanok, akiknek a 64-bitesre hosszabbodó 'long' gondot okozna. Szerencse, hogy a 64-bitesre hosszabbodó WPARAM és LPARAM nem okoz gondot senkinek.
K: De lehet, hogy csak arra gondolt, hogy nem kevés munkájába kerülne átnézni a különféle struktúrákat, hogy hány helyen használt LONG-ot INT32 helyett (vagy ULONG-ot DWORD helyett).
V: Nem mondod?!

K: De mit tett a Java-programozókért?
V: Hát mit gondolsz, ki az, aki az egyik verzióban betesz a SE-be egy új featúrát, mert trendi, a következőből meg kiveszi, mert elavult?

K: De azon kívül semmit?
V: Az ő leleménye volt az, hogy fordításkor a \uXXXX szekvenciák kifejtése a lexikális elemzés előtt legyen, így például egy stringet le lehet zárni egy \u0022 szekvenciával, egy sort pedig egy \u000D szekvenciával.

K: Az Oracle-adatbáziskezelő fejlesztésénél mit segített?
V: Megengedte, hogy a NLS_LANG nevű környezeti változót a felhasználó szabadon beállítsa bármire, de ez alól kivétel az AL16UTF16 érték, arra nem szabad állítani. Miért? Mert az a NLS_NCHAR változónak a szokásos értéke!

K: És a PC-s hardware-ben nem segített?
V: Nem-e? Az 8086-os CPU szegmens*16+offset elvű címzési rendszerét egymaga csinálta!

K: Na de azon kívül?
V: A hard-diskek kezelésénél annyira ügyelt a bitekkel való takarékosságra, hogy bele is szaladtunk az 504 megabájtos korlátba (C/H/S=1024/16/63), aztán a 7.875 gigabájtos korlátba (1024/256/63), aztán a 127.5 gigabátjos korlátba (65536/16/255), vagy választhatóan a 128 gigabájtos korlátba (28 bites lineáris cím). (Egyes hardware/BIOS/OS verziók másféle korlátokkal szolgáltak, pl. 7.39 gigabájt (1024/240/63), 31.5 gigabájt (65536/16/63))

K: Na jó, de azon kívül hol spórolt még a biteken?
V: Az IBM System/360-as sorozatának 32-bites gépei csak 24 bitet használtak a címzéshez (maximum 16 megabájt), a felső nyolc bitet Bobika jól ki tudta használni másra. Jó mulatság volt azután mindent újracsinálni a /370 sorozatnál, ahol már 31 bit vett részt a címzésben.
Ugyanezt a Macintoshnál is előadta, Motorola 680x0 processzoron.

K: Na jó, de azon kívül hol spórolt még a biteken?
V: Mit gondolsz, ki találta ki a 32-biten tárolt timestamp-et illetve fájlméretet? (Lásd Y2038-problem illetve Large File Support).

K: És más nem területen nem tett semmit a takarékosság érdekében?
V: Dehogynem, az egész Year2000 mizéria nem lett volna, ha nem találja ki a hat karakteren tárolt dátumokat!

K: De villamosmérnökként mit tett értünk?
V: A villamosmérnökök szabványügyi testülete (IEEE) befogadta az Ethernet-keret formátumát 802.3 néven, de a mi Bobónk javaslatára a 'típus' mezőt 'hossz'-ra változtatták. Sajnos ezzel sem sikerült megakadályozni több protokoll párhuzamos használatát, mivel a 'típus' definiált értékei (pl IP: 2048, IPv6: 34525) nagyobbak a 'hossz' maximumánál (1500).

K: Na jó, de a számítástudományban nem jeleskedett?
V: Például még 1975-ben kitalált egy ellenőrzőszám-képzési algoritmust, ami egy tízjegyű számhoz rendel egy tizenegyedik ellenőrző számjegyet, úgy hogy az véd egy számjegy elrontása ellen, véd két szomszédos számjegy felcserélése ellen, de nem véd az utolsó számjegy és az ellenőrzőjegy felcserélése ellen.

K: Na de mit tett az Unicode érdekében?
V: Ő döntött úgy, hogy 16 bit elegendő a világ összes karaktere számára (kiegészítő adat itt), tehát az UCS-2BE lehet az univerzális formátum. Vagy az UCS-2LE. Akkor már két univerzális formátum is van! De legalább fix méretűek a karakterek, nem úgy mint az 1-6 bájtos UTF-8 szekvenciák.
Okos szavára hallgatott is a Microsoft, az IBM, az Oracle, a Sun és még sokan mások.
Aztán valahogy kiderült, hogy 16 bit mégsem elegendő mindenre, tehát Nyomasek Bobó előállt a helyettesítő párok ötletével, így lett az UTF-16LE meg az UTF-16BE.
Így újra minden rendben, bár ettől kezdve a karakterek nem fix méretűek, és az ábrázolható karaktertartomány kétmilliárdról egymillióra csökkent, de ez sem baj, legalább az UTF-8 szekvenciák maximális hosszát is négyre lehetett csökkenteni.
K: De legalább az UTF-32 esetén minden karakter fixen négy bájtos.
V: Az biztos! Itt van például ez: ю́ (cyrillic small letter yu with acute) – ez kétszeresen is négybájtos: az első négy a betű, a második négy az ékezet rajta [forrás: http://utf8everywhere.org/],

K: Na de a kis részletekkel nem törődött?
V: Dehogynem, hála neki van egy csomó rosszul vagy sehogysem definiált vezérlőkarakterünk; például a U+AD kódú SHY karakter, ami igen hasznos funckció lenne sorkizárt szövegekbe feltélteles elválasztások beillesztésére, ha a definíciója nem ez lenne: ez a karakter egyes kontextusokban feltételes elválasztást jelenthet.

K: A big-endian platformon fejlesztőkért ugyan mit tett?
V: Ügyesen felfedezte, hogy egyes esetekben különböző méretű integerek pointerei helyettesíthetik egymást, pl. egy 'uint64_t' típusű változó címét használhatjuk olyankor, amikor 'uint32_t *'-ot várnak tőlünk (persze előtte kinullázva), mivel a magasabb helyiértékű bitek ugyis 'hátul' vannak. Mármint little-endian platformon. Big-endian platformon ez nem működik, de tanulságos hibakereséshez vezet.

K: Na jó, de még mit?
V: Ezt a hibát úgy akarta jóvátenni, hogy bevette a C-szabványba, hogy különböző méretű integerek pointerei közötti typecast Undefined Behaviour. Ezt még kapcsold össze az UB-optimalizációval, és azt kapod, hogy adott esetben egy byte-sorrend megfordító függvényből a fordító belátása szerint azt generál, amit csak akar, 'hiszen UB van benne!'

K: Ugyan mit tett a lokalizáció érdekében?
V: Hát szerinted kinek köszönhetjük az érthetetlenségig megmagyarított szakkönyveket, a magyarra fordított programnyelveket (MS Office), a tizedespont helyett a tizedesvesszőt?
K: Speciel a tizedesvessző tök logikus, hiszen a felhasználók ahhoz vannak szokva.
V: A felhasználók már tök jól hozzászoktak a tizedesponthoz, amikor Bobus elkezdte a tizedesvesszőt erőltetni...
K: Hát majd szépen mindenki átszokik a tizedesvesszőre, felhasználók és programozók egyaránt...
V: A programozók csak akkor szokhatnának át, ha a pontot és a vesszőt teljesen megcséréljük (rosszabb esetben más írásjeleket is belekavarhatunk a dologba), és így teremtjük meg az inkompatibilitás újabb csodáit, pl:

for (rekord,fld= 1,0; rekord,fld<=3,0; rekord,fld += 0,5)
    printf ("%g". rekord,fld);

K: De a dátumok kezeléséért nem tett semmit?
V: Dehogynem, mikor észrevette, hogy a magyar dátum-sorrend (év-hónap-nap) logikus, rendezésbarát, és még az ISO 8601 szabvánnyal is összhangban van, akkor felhorgadt benne a világpolgár, és elkezdte a külföldi dátumformátum használatát erőltetni. Nem az ő hibája, hogy ilyen dolog, hogy külföldi dátumformátum egyszerűen nem létezik, különféle kultúrkörök különféle formátumokat használnak (pl. mm/dd/yy, dd/mm/yy), angol nyelvterületen például úgy kerülik el a félreértéseket, hogy a hónap rövidítését betűkkel írják: Nov 30 17:13:36 2018).