Ez nem semmi

[VF]

Thus spake Andras Tantos <andras_tantos at yahoo.com>:

> Nem ugyanazzal a forditoval. Az NT4-es idejen volt Visual C++ 1.0 talan? Ma
> Visual C++ 7.1 van, es erosen jon a 8.0 (mostnasag volt valami beta kiadas,
> ha jol sejtem). A fordito rengeteget valtozott azota.

Akkor kepzeld el, hogy van meg GCC, IAR, Maxxon, SAS, Hisoft, stb...
Mind masik fordito. Elmeletileg mindegyiken le kene fordulnia a
programnak, nem? Hiszen ez a C nagy elonye.

> Nem ugyanarra gepre. Az NT4-et a 386-os, 486-os idokben kezdtek csinalni, a

Azert az architektura nem sokat valtozott, es kulonben is ez a fordito
dolga, mi koze van hozza a programozonak?
Legalabbis elmeletileg, a gyakorlatban ugy tunik hogy a C-fanok eddigi
allitasaival ellentetben megis problema ez?

> hatekonyabb, arrol mar ne is beszeljunk. De nem csak errol van szo. Az NT
> eredetileg is multi-platform OS volt. Futott Mips-en, PowerPC-n, Alpha-n, es
> x86-on. Az NT4 meg parat tudott belole, a Win2000 azt hiszem csak x86-on
> volt. Azota bejott az IA64, es ha lehet hinni a pletykaknak, jon az AMD64
> verzio is. Szoval talan a 2000-es volt az egyetlen, ami csak x86-ra keszult
> el.

Ez a fordito dolga, nem? Hiszen az minden procira sokkal jobban
optimalizal mint ha egy profi asm fejleszto irta volna a programot,
es raadasul hibatlan is.

> Aki ezt mondta, az nem jol mondta. C-ben is, mint minden nyelven problema
> egy projekt karbantartasa. A magasabb szintu problema-leiras miatt kicsit
> konnyebb, mint ASM-ban, de igy is nehez.

Koszi, ezzel vegre en is egyet tudok erteni.

> Egy projekt managgelese (jaj, hogy irjak ezt magyarul?) osszetett es nehez,

Igy, csak 1 g-vel :))

> A Windows forraskod egesz biztosan tul nagy ahhoz, hogy egy ember teljesen
> atlassa (egyebkent ez szinte minden kereskedelmi meretu SW termekre igaz).

Az en kis mikrovezerlos programjaim, lehetnek akarmilyen komplikaltak,
szamomra mindig atlathatok. Lehet hogy x ev mulva nem, akkor majd
olvasgatom a kommentjeim es rohogok :) De most kepes vagyok atlatni az
egeszet. Ezert nem is ertettem hogy a tobbiek miert jonnek mindig a
linux kernellel...

> Nem lehetett volna ASM-ban irni a Windows-t, mert nem lehetett volna (teljes
> ujrairas nelkul) azokat a valtoztatasokat keresztul vinni benne, amiket
> keresztul kellett az evek soran. Hogy csak egy konkret peldat mondjak, az
> IA64-es Windows 2003 kihozasa lehetetlen lett volna. Ugy altalaban, ha
> ASM-ban irsz egy programot az a legbiztosabb modja annak, hogy a porject
> teljes elettartamara hozza lancold magad egy processzor-architekturahoz,
> talan annak egyetlen inkarnaciojahoz. Az NT fejleszteset valamikor '90 korul
> kezdtek. Most 2004 van, es meg mindig el. 14 ev alatt (Moore torvenye
> szerint) 8-9 processzor-generacion kellett vegig vinni a projectet.

Ez teljesen igaz, egy windoz meretu programrendszer eseten.
En a sajat asm forrasom barmikor toredek ido alatt mint a megirasa
tartott portolom barmely procira. Illetve a megfelelo helyen, ha szukseges,
megoptimalizalom az uj procira. Teny, hogy ennek jelentos resze olyan
mechanikus munka, ami magasszintu nyelvben elkerulheto lenne, es az
atiras kozben elkovetett hibaktol is megvedene.
Biztos hogy lassabb mint a C, de mukodik, mi is a 3. procin dolgozunk
kb 98 ota, amikor elkezdodott. Nem a szoftver atirasa a gond, hanem
folyamatosan valtozik a koncepcio a piaci helyzet szerint.
A PC progit at kellett irni windoz ala, a keszulekbe bekerult a grafikus
kijelzo, felhasznalobarat menurendszer, konfiguralhato szurok.
(Ez utobbiak azert csak most, mert diagnosztikai EKG-ban tilos szurni,
teljesen szabvanyosan feldolgozott jelet kell latnia a dokinak)
Tehat valoban nem egyszeru az elet, de nem az asm okozza a problemat.
Ha hetente at kene irni a progit, az gaz lenne, de igy hogy nehany
evente 1-2 nap, nem erdekes.

> Tantos Andras

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Microsoft Certified Angry OS Rebooter"