Mono 2.0

Programozás

A Mono Project bejelentette a Mono 2.0-s verzióját. A Mono a .NET keretrendszer portolható, nyílt forrású implementációja UNIX, Windows, Mac OS X és más operációs rendszerek számára. A 2.0-s verzióban érkező változásokról a release notes szolgál részletes információkkal.

( emberk | 2008. 10. 06., h – 16:14 )

Egy teljesen inkompetens embertől származó kérdés (Én eddig cask C,C++, és ASM-el foglalkoztam). Ez nem nagyon hasonlít a java-ra?

Azért ma már a 3.5-ös .NET framework sokkal többet tud, mint a Java, rengeteg dolog van bene, olyanok, hogy el sem hiszi az ember, ha nem a saját szemével látja.
Hátrány, hogy iszonyúan nehezen tanulható, sok minden nincs rendesen dokumentálva, olyan, hogy ha überpró .net3.5 coder vagy, akkor iszonyat könnyen tudsz összerakni profi alkalmazásokat, minimális "kézimunkával", hameg csak hobbiprogramozó vagy, szinte esélytelen beletanulni átlátni.
Részemről én utálom a .nt frameworkot, inkább java.
(Igaz, én csak egy hobbikóder vagyok.)
A c# viszont elsőre sokkal jobban tetszik, mint a Java nyelv, hátránya ennek is, hogy jkóval bonyolultabb annál. (Viszont vannak property-k. :) )

Légyszi mondj példákat mivel tud többet a .NET platform mint a Java platform. Én nagyon sokáig kerestem, de nem leltem. Ha tudsz ilyeneket, akkor sorold, mert nekiállok lefejleszteni Java-ra is ezeket a hiányfeaturákat a közösség örömére.

--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

A java generics tényleg szerencsétlen, de Java 7-re talán átdolgozzák (ld. reified generics).
Kódépítésre van Java Compiler API, amivel egy java forrást tartalmazó string-ből betölthetsz egy osztályt, amit reflection-nel hívhatsz.
Silverlight-szerű technológia a JavaFX, scriptnyelvvel (~ xaml), browser pluginnel.

A byte kód szintű generics tényleg hiányfalat, már sokaknak szemet szúrt és várható hogy tesznek ellene valamit.

A Reflection.Emit megvalósítható Java-val is, hiszen lehet runtime bytekódot generálni, bár nem annyira egyszerű mint .NET platformon. Mellesleg hál'Istennek hogy nem egyszerű. Aki ilyet csinál, annak remélem 10 év tapasztalata van a dologban és két anyja is, aki debuggolja a kódját.

WPF-et meg nem szeretnék látni soha Java-n, szerintem senki sem. Van UI layer számos (SWT, Swing) még ha nem is néznek ki natívan, de legalább multiplatformosak.

hétfőre kész legyen!

Hova küldhetem az ajánlatot?
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.

A kódemittálás nem feltétlenül evil, bár tény, hogy nem triviális, és könnyű magad lábon lőni.
Viszont kíválóan alkalmas runtime proxy típusok generálására (mondjuk attribútomokkal vezérelve - CAS-szerű dolgok). Compiler API ilyen esetben ugye nem játszik (hozzáteszem, nem vagyok nagy Java guru, biztos meg lehet oldani valahogy).

Hova küldhetem az ajánlatot?
Szerintem próbáld meg a Jonathan.Schwartz@sun.com-ot. :)

Ami hatalmas elony a .Net-nel az a P/Invoke. Java eseteben eleg bonyolult C cuccokat hivni (JNI wrapper szukseges hozza, azt meg raadasul nem is egyszeru programozni), mig .Net-bol nem kell C extension, siman bele lehet hivni barmilyen shared libbe.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

.NET Framework sok elemből áll.
Egyrészt egy VM-ből, ez hasonlít a JVM-re (GC, JIT, stb)
Van itt egy CLI nevezetű cucc, ami a Java bytecode megfelelője.
Meg van egy hatalmas lib, hasonlóan ahogy a Java-hoz is van.

Az egyik legnagyobb különbség a Java bytecode és a CLI között, hogy ez utóbbi nyelvfüggetlen, szemben az előbbivel.
Emiatt már-már nevetségesen egyszerű egy C# osztályt használni mondjuk Visual Basicben, Pythonban, vagy akár C++-ban. (Pontosabban C++/CLI-ben, ami egy C++ variáns.)

Illetve elég könnyű C++/CLI-ben egy tetszőleges C++, vagy C könyvtárhoz "managed" wrappert írni.

Illetve talán még ide kell vennünk az egészhez a Visual Studiot, amiben még egy jobban képzett majom is összekattingat fél óra alatt egy raktárprogramot, akár webes felülettel.

Persze ez mind win-re igaz.
A mono-ban van egy c# fordító, egy VM ami annyiban biztosan kevesebbet tud wines társánál, hogy nem tud C++/CLI-ből fordított kódot futtatni, illetve a lib-ek egy része sincs még portolva.

Általánosságban elmondható, hogy ha nagyon akarsz, tudsz cross-platform programot írni, de csak úgy nem fog sikerülni.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

De igaz, olvass utána. Jó, esetleg túl erősen fogalmaztam:

A java bytecode csak a Java nyelv támogatására lett kifejlesztve. Nem lehetetlen más nyelvekkel használni, de sok vele a szívás.
A CLI már a tervezés első pillanatától nyelvfüggetlen.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Megnéztem a bejelentést, kiderült, hogy a lib-ek egész jó állapotban vannak, persze van 2-3 év lemaradás, de már minden együtt van egy komolyabb programhoz. Ha nem hivogatsz natív könyvtárakat, és OS specifikus dolgokat, akkor nincs gond a cross-platform fejlesztéssel.
Ez persze Java-val is így van...

A VM minden bizonnyal lassabb mint a win-es, de aki gyors programot akar ne használjon VM-et. :)

Illetve egy személyes megjegyzés:
Kénytelen voltam megtanulni a C#-ot, és azt kell mondanom, elég szobatiszta nyelv. Jobb szeretem mint a Java-t, de ez magánvélemény.
Igaz ezzel nem vagyok egyedül, mert a Vala is a C#-ra hasonlít.
Szerintem ha ez a project beérik, az hatalmas lökést jelenthet a gnome-nak...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

".NET Framework sok elemből áll.
Egyrészt egy VM-ből, ez hasonlít a JVM-re (GC, JIT, stb)"

Miféle VM, kéremszépen? Ne terjesszük a hülyeséget.
Nincs a .NET-ben semmiféle VM, hanem van helyette JIT fordító.

A C#/Visual bézik/managed-C++ fordítók MSIL kódra fordítják a programot, és amikor ezt a MSIL kódot tartalmazó .exe-t elindítod, a .NET JIT fordítója natív kódra fordítja.
Nincs semmiféle VM-ben futtatás. Natív kód fut.
Ha jót tévedek, az újabb Java implementációk is JIT fordítóval dolgoznak már VM helyett.

VM != interpreter

A VM (virtuális gép) csak azt jelenti, hogy az alatta lévő réteghez képest extra szolgáltatásokat ad hozzá. A JVM és CLI (vagy CLR -- mindig elfelejtem, hogy melyik melyik) esetén ez pl. az osztályok, objektumok támogatása, szemétgyűjtés, izoláció ... stb.

Az, hogy ez a virtuális gép JIT fordítót, interpretert, vagy valamilyen keveréket (pl. HotSpot) használ, az a VM megvalósításának módja.

Üdv,
Gergely

Nemnemnem.

A .NET az egy framework. Olyan, mint anno Delphi ideében volt a VCL.
Vagy olyan, mint monjduk a QT4. Vagy a wxwidgets. stb.stb.
(Csak nyílván jóval többet tud.)

"A VM (virtuális gép) csak azt jelenti, hogy az alatta lévő réteghez képest extra szolgáltatásokat ad hozzá."
Nem hinném, hogy ezt jelenti (sőt!). Ennyi erővel a QT4, a VCL, a wxwidgets, sőt a glibc is VM (virtuális gép)?

Nincs itt semmiféle interpreter, meg semmiféle VM. Ez masszív h.ülyeség, tévhit.
A .net program MSIL nevezetű bytecode-ra fordul. Ez kerül az exe-be.
Amikor ezt elindítod, ez az MSIL bytecode _natív gépikódra_ fordul, a kapcsolódó .net framework osztályokkal egyetemben. (A JIT - Just In Time - compiler fordítja le. _Nem futás közben_ interpretálja, hanem a futás _előtt_ lefordítja a bytecode-ot az adott architektúra natív kódjára, és a natív kód indul el.)

De nincs _semmilyen_ virtuális gép.
A .net programok natívan futnak a _fizikai_ gépen, mivel a JIT fordító natív, a platformra optimalizált kódra fordítja az MSIL bytecode-ot, és a .net framework használt részeit. Tehát a futó program igenis sok platformfüggő elemet tartalmaz, hisz natív.
Nem tudom, mit nem lehet ezen megérteni.
_Nincs_ virtuális gép. Nincs.

"Nincs itt semmiféle interpreter, meg semmiféle VM. Ez masszív h.ülyeség, tévhit."
Kicsit át kéne nézned a dolgokat, mielőtt lehülyeségezel valamit.

Az OS egy virtuális gépet definiál a user-space programok számára. Egy olyan virtuális gépet, ami több szolgáltatást nyújt, mint a hardver. A virtuális gép interfésze (leegyszerűsítve) a programok felé egyrészt az adott processzor utasításkészlete, másrész pedig az OS rendszerhívásai. Erre épülnek függvénykönyvtárak, amik az OS rendszerhívásait wrappelik, egészítik ki.

A JVM és a CLI/CLR ezt viszi tovább, behoznak egy új utasításkészletet (java bytecode / MSIL) és új alapfunkciókat (objektum-orientált típusrendszer, szemétgyűjtés).
Mellékszál, de ugyanezt csinálja pl. a VMWare illetve a Virtualbox, csak ott pont az a cél, hogy pontosan olyan interfészt nyújtson a virtuális gép, mintha egy valódi hardver lenne.

Az, hogy ez milyen módon van implementálva, az elv szempontjából lényegtelen. Pl. a te elméleted szerint a VMware / Virtualbox se VM, hiszen pont amiatt gyorsak ezek a VM-ek, hogy a natív kód fut közvetlenül a processzoron (persze trükközéssel).

Az első JVM-ek alapvetően interpreter alapúak voltak. Aztán jött az IBM féle JIT VM és a Sun féle hibrid HotSpot. Eközben az MS létrehozta a saját megoldását, és persze nem járták végig publikusan az interpreter -> JIT utat. Nagy valószínűséggel azonban a fejlesztés első időszakában ugyanúgy volt saját interpreteres implementációjuk. Érdemes megnézni, hogy először a Mono-ból is egy interpreter készült el, mivel nagyságrendekkel egyszerűbb megírni, mint egy jó JIT fordítót. A Mono is többször futott neki.

Az, hogy nincs egy DOTNETVM.EXE, még nem jelenti azt, hogy nincs is VM. Pl. bizonyos Java VM-ek illetve a Mono is beágyazható más processzekbe. Nyilván a Windowsba mélyen beintegrálták a futtatókörnyezetet, ezért nincs olyan külön processz. Ez egyébként megfigyelhető az egyéb komponenseknél is, ezért nincs külön Windows Application Server. Az, hogy az MS "Runtime"-nak nevezi "VM" helyett kizárólag arra szolgál, hogy a köznyelvben jobban elkülönüljön a két dolog.

Végül: Írod, hogy ennyi erővel a QT is virtuális gép. A QT egy könyvtár, ami ugyanúgy az OS virtuális gépét (utasítások, rendszerhívások) használja, mint a többi. Ezzel ellentétben a JVM és a CLI/CLR új utasításkészletet, "rendszerhívásokat" ... stb. definiál.

Üdv,
Gergely

"Az OS egy virtuális gépet definiál a user-space programok számára. Egy olyan virtuális gépet, ami több szolgáltatást nyújt, mint a hardver. A virtuális gép interfésze (leegyszerűsítve) a programok felé egyrészt az adott processzor utasításkészlete, másrész pedig az OS rendszerhívásai. Erre épülnek függvénykönyvtárak, amik az OS rendszerhívásait wrappelik, egészítik ki."
Aham. TEhát mondhatjuk, hogy pl. a notepad.exe is egy virtuális gépben fut. Értem. Aham.

"
A JVM és a CLI/CLR ezt viszi tovább, behoznak egy új utasításkészletet (java bytecode / MSIL) és új alapfunkciókat (objektum-orientált típusrendszer, szemétgyűjtés).
Mellékszál, de ugyanezt csinálja pl. a VMWare illetve a Virtualbox, csak ott pont az a cél, hogy pontosan olyan interfészt nyújtson a virtuális gép, mintha egy valódi hardver lenne."
A vmware és a virtualbox valóban vitruális gép. A .net programok pedig natívra fordítódnak az indítás pillantában, és a natív kód fut. Persze ha egy vmware-be telepített xp-n indítunk el egy dotnet-es exe-t, akkor az tényleg virtuális gépben fut. :)

"
Az, hogy ez milyen módon van implementálva, az elv szempontjából lényegtelen. Pl. a te elméleted szerint a VMware / Virtualbox se VM, hiszen pont amiatt gyorsak ezek a VM-ek, hogy a natív kód fut közvetlenül a processzoron (persze trükközéssel)."
Nem. a vmware / virtualbox az egy vm. Egy keretrendszer, egy framework, mint monjduk a QT, GTK vagy a .NET az nem vm. Hanem framework. (Mit nem lehet ezen érteni, miért kell össze-vissza magyarázni a h.ülyeséget?!...)

"Az első JVM-ek alapvetően interpreter alapúak voltak. Aztán jött az IBM féle JIT VM és a Sun féle hibrid HotSpot. ..."
Ezt nem tudom, hogy jön ide. Itt arról volt szó, hogy a .NET framework - a közhiedelemmel ellentében - nem tartalmaz semmiféle virtuális gépet.

"Nyilván a Windowsba mélyen beintegrálták a futtatókörnyezetet, ezért nincs olyan külön processz."
Persze, hogy nincs olyan külön processz, hisz nem is létezik. Mivel a .net bytecode-ot tartalmazó .exe fájl a futtatás pillanatában lefordul bináris, natív, a processzor opcode-jait tartalmazó, a processzoron natívan, közvetlenül futtatható kóddá. nincs semmi sen a windows mélyébe integrálva.
A .NEt az egy _framework_, egy keretrendszer, akárcsak a QT, vagy a wxwidgets. (Csak persze sokkal bövebb ezeknél.)
(Érdekesség még, hogy a win32 API-t az elkövetkező microsoft operációs rendszerekben a .NET framework fogja leváltani.)

"Végül: Írod, hogy ennyi erővel a QT is virtuális gép. A QT egy könyvtár, ami ugyanúgy az OS virtuális gépét (utasítások, rendszerhívások) használja, mint a többi. "
Persze, hogy nem virtuális gép a QT. Persze, hogy egy könyvtárrendszer, framework. Akárcsak a .NET.

Egyébként eredetileg ehhez írtam reagálásként: (ne forgasd ki a szavaimat, kérlek.)
"kisg: "A VM (virtuális gép) csak azt jelenti, hogy az alatta lévő réteghez képest extra szolgáltatásokat ad hozzá."
psc: Nem hinném, hogy ezt jelenti (sőt!). Ennyi erővel a QT4, a VCL, a wxwidgets, sőt a glibc is VM (virtuális gép)?"

Lehet azon lovagolni, hogy mit nevezünk virtuális gépnek. Ami tény: A processzoron előbb-utóbb natív kód fog futni, mindig. Más nem tud. Még akkor is, ha VirtualBox-ban futtatsz egy alkalmazást.
Úgy látom, te azt nevezed virtuális gépnek, ami oprendszert futtat. Én a CLR-t is virtuális gépnek nevezem, mert egy teljes platformot képez, a rá készített programoknak semmit nem kell tudniuk az oprendszerről, a hardverről.
A QT teljesen más tészta, az egy segédkönyvtár. Az nem futtat semmit, azt az alkalmazás tölti be, ha használja. .NET-es megfelelője a Base Class Library, ami szintén a CLR felett fut.
Szóval szerintem nem attól lesz valami virtuális gép, hogy előbb, vagy később áll elő a natív kód.

"A .NET sem futtat semmit".
Ne erőlködj. Nincs világvége, ha valamit nem jól tudtál. De állításaid alátámasztására átfordíthatnál nekem natívra egy .NET-es programot, ami aztán a Common Language Runtime nélkül is fut. Kíváncsi lennék pl, hogyan foglalna memóriát, vagy mi futtatná a gc-t :)

Az a baj, hogy definíciókon vitatkozol, amikor azok, függetlenül attól, hogy neked logikusak vagy sem, már léteznek.

A VM-et több értelemben szokták használni.

1. Az OS egy VM-et mutat a program felé, ezt úgy kell érteni, hogy neked nem kell mindent magadnak kezelni, az OS szolgáltatásai és a driverek elfedik a valódi hardware-t, így nem kell törődnöd vele, hogy pl milyen videókártya van a gépben, csak azzal, hogy OpenGL-t mennyire támogat.
Ezt a VM értelmezést elég ritkán hallani, leginkáb 10-20 éves tankönyvekben látható. :)

2. A másik VM jelentés az, mikor egy program "emulál" egy "teljes" gépet, saját gépikóddal. Ez lehet ugyanaz a gépikód mint a host gépé (VMware, Virtualbox). Lehet egy másik létező architectúra kódja (QEMU). És lehet egy kitalált kód (Java bytecode, MSIL/CIL, Python bytecode, LLVM).
Ebből a szempontból teljesen indifferens, hogy az a bizonyos kód hogyan lesz értelmezve. Lehet, hogy nincs szükség átfordításra csak bizonyos utasításoknál (VMware, VirtualBox). Lehet, hogy interpreter dolgozik (python, QEMU, Java), vagy valamilyen JIT (Java, MSIL/CIL, QEMU)

Adtunk már neked egy rakás linket, ahol ezek le vannak írva.
Mint ahogy arról is, hogy mi az a JIT, mi az az AOT, stb. stb.
Sajnos most nem velünk vitatkozol, hanem a teljes informatikus világgal, méghozzá definíciókon, és szóhasználaton. Nem nyerhetsz. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Tévedsz.

A .Net sokminden, többek között van benne egy CLR nevü cucc:
The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative.

A Qt4, wxWidgets, esetén fordításnál natív futtatható fájlt kapsz, amit a géped közvetlenül értelmez.

.Net esetében a fordító CIL (régebben MSIL volt neve) kódot állít elő.
Ezt nem a fizikai processzor értelmezi, mert nem tudja.
Az értelmező/natív kódra átfordító programot hívjuk Virtual Machine-nek. Hogy ez JIT, vagy interpreter, az ebből a szempontból részletkérdés.

"Amikor ezt elindítod, ez az MSIL bytecode _natív gépikódra_ fordul, a kapcsolódó .net framework osztályokkal egyetemben."
Ez, amit most mondaz nem a JIT, hanem az Ahead-of-Time lenne.
Mono-ban, és gcj-ben van ilyen.

A Just-in-Time lényege, hogy csak akkor fordítja le a kódot, mikor szükség van rá, ha a program egy részére nem kerül vezérlés, nem is fordul le.
Egyszerüen mondva, ha te meghívsz egy fv-t, amit addig még nem, akkor meg kell várnod míg lefordul. Persze ez így nem lenne sokkal gyorsabb, mint egy interpreter. Csak van itt a 80-20-as "szabály", ami az a megfigyelés, hog a futásidő 80%-ban a program 20%-ban van a vezérlés.
Mivel a JIT megtartja a már lefordított kódot, ezért a fordítás okozta lassulás nem érzékelhető, hiszen az a bizonyos 20% csak egyszer fordul le. Plusz futás időben olyan információk birtokában is lehet a fordító, ami egyébként fordítási időben nem állt rendelkezésre, ezáltal a kód még hatékonyabb lehet.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"A Qt4, wxWidgets, esetén fordításnál natív futtatható fájlt kapsz, amit a géped közvetlenül értelmez."
A CLR meg lfordítja a CIL (MSIL) kódot natív kódra. Így végül ugyan olyan natív kód fut, mint pl. a Qt4, wxwidgets hgasználata esetén.

Szvsz a meddő vita értelmetlen.

A .net működését a következőképp tudnám érzékeltetni:
pl. vegyük a gcc -t.
A gcc úgy működik, hogy a vannak a language-compilerek, amik egy REgister Transfer Language (RTL) (http://en.wikipedia.org/wiki/Register_Transfer_Language) nev bytecode-ra fordítják a programot.
Ezen, az RTL kódon hajt végre a GCC magja optimizációkat, különböző analíziseket, stb.
Ezután a fázis után, következik az assembly-kód generálás, az RTL kódból, architektúra-specifikus eszközökkel. (Ugye az assembly-kódot egy külső assembly-fordító fordítja le, ez most hagyjuk, elég az assembly-kódig mennünk.) (http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Structure)
Namost képzeld el, hogy mi lenne, ha a GCC-t két részre szednénk: meghagynánk a language-compiler és az optimization részt egy programban, aminek a kimenete az optimalizált RTL-kód. A másik rész tartalmazná az architektúra-specifikus RTL-to-assembly kódgenerálót.
Képzeljük el, hogy az első rész az RTL kódot egyből egy fájlba írja, aminek a kiterjesztése .exe .
Majd, amikor a programot futtatni akarjuk, akkor a futtatás előtt a másik rész hívódik meg, ami az aktuális architektúrára leordítja az RTL kódot, natív kóddá, ezután a natív kód elindul, és fut.
A .net is valahogy így működik. Nincs benne semmiféle virtuális gép.

Tessek mar megerteni, hogy a .Net NEM egyben forditja le a kodot - szemben a gcc-vel. Ennekokan a futas _nem_ kozvetlenul a processzoron zajlik, hanem a .Net VM figyeli magat a kodot, es amikor valamilyen metodushivas tortenik, akkor fordit egyet.

Ajanlom figyelmedbe a vonatkozo Wikipedia cikket, ahol raadasul pont a te peldadat cafoljak meg.

Ha belegondolsz, amit mondasz, hulyeseg is, hiszen ha futas _elott_ csinalna meg a precompilation-t, akkor csak nagyon kevessel lenne gyorsabb, mint az interpretalt kod - hiszen az osszes libet is le kell forditani, amit hasznal (amennyiben meg nem futott .Net app elotte). Ezzel szemben a "Just in time" azt jelenti, hogy "epp idejeben" (by webforditas.hu), vagy amikor szukseges.

A Java annyiban tud kevesebbet, hogy nincs benne kezi precompilalasra lehetoseg (a Wikipedia cikkben last az ngen.exe-t targyalo reszt), igy a runtime libek az elso java program inditasakor precompilalasra kerulnek.

Itt inkabb a nem teljesen egyertelmu elnevezes a gond. Mig a .Net es Java forditok virtualis gepek, addig a VMware/VirtualBox altal futtatott gepek emulalt gepek, a ketto 2 eltero technologia, az utobbi majdnem hasonlo, mint egy commodore/ZX Spectrum emulator, mindossze a processzoremulacio mas. Ott valojaban felig-meddig interpretalt vegrehajtas tortenik, nemi previzionalassal (ha van Guest Additions).

Remelem, hogy igy sokkal erthetobb.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( 4fonya | 2008. 10. 06., h – 19:25 )

Lehet hogy kipróbálom megint, hátha hajlandó működni is. Az 1.9-es sorozattal megpróbáltam összerakni egy szöveges megjelenítő ablakot csak úgy példának. A nagyjával megvoltam és kezdtem írogatni a kódot amikor elhasalt az egész fejlesztőfelület. Újból elindítottam és a kód egy része meg néhány grafikus elem egyszerűen eltűnt, pedig munka közben mentegettem sűrűn. Kidobtam az egész próbálkozásomat és újra kezdtem. Megint hanyattesett kb. ugyanott. Ugyanezt megcsinálta velem egy másik gépen is. Na ekkor mondtam azt hogy dugják föl maguknak az egészet.

( hrgy84 | 2008. 10. 07., k – 12:06 )

Ahogy elnezem, haldoklik is az ftp.novell.com rendesen...
LibGdiplus: 


50% [=================>                   ] 1.003.340      8.01K/s    ETA 02:51

-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.