Gyurkity Péter

A Midori válthatja le a Windowst

Miközben a felhasználók jó része a Vista utódjára vár, a Microsoft az egész koncepciót sutba dobó projekten dolgozik, amely új alapokra építené fel az operációs rendszereket - a túlsúlyos Windows leváltásával.

Nagyjából ennyiben össze is tudjuk foglalni mindazt, amit erről a titkos projektről tudni lehet, hiszen a Singularity, illetve Midori néven futó fejlesztést mély csend övezi Redmondban. A hivatalos, illetve félhivatalos megkeresésekre csúnya pillantásokat kapnak az érdeklődők, magáról a projektről, illetve az azon dolgozó csapatról pedig legfeljebb általános, kissé ködös leírásokat olvashatunk.

A Midori a napokban került igazán a képbe, miután a New York Times-ban megjelent cikk a Windows operációs rendszer súlyáról, bonyolultságáról és használhatóságáról értekezett. Nagy meglepetés nem érhet senkit, ha rögtön leszögezzük: a cikk nem éppen dicsérő hangnemben ír a szoftverről, kiemelve annak hátrányait. Erre lehet majd válasz a MinWin, a Windows kernel egy minimalizált változata, amelyről már korábban mi is beszámoltunk, az újabb hírek szerint azonban ez nem a Windows 7 lelke lesz. Az biztos, hogy a következő operációs rendszert a Vista tanulságaira építve fejlesztik, de hogy ez pontosan mit takar, azt még nem tudni.

A ZDNet egyik lelkes blogolója eközben arról ír, hogy a Midori (Singularity) igen érdekes eredménnyel jöhet majd ki valamikor a távoli jövőben. A projekt nemrég érte el az 1.0-ás mérföldkövet, ám részleteket továbbra sem árulnak el ezzel kapcsolatban. Olyan mondatokat olvashatunk a hivatalos oldalon, miszerint a teljes Windows-koncepciót félreteszik, megvizsgálva, hogyan is festene egy ilyen új platform. Fontos kitétel, hogy a teljes operációs program a C# nyelv egyik kiterjesztésében készül, így eleve ki tudják zárni a buffer túlcsordulásokra építő támadásokat, mivel magát a jelenséget szüntetik meg. Hasonló kijelentés, hogy mivel az összes mai operációs rendszer a 60-as években használt Multics platform alapelgondolásaira épít, ezt kell újradolgozni, merőben más (nem 40 éves) szemszögből közelítve meg az egyes problémákat.

Ennél többet nem igazán tudhatunk meg a csapat munkájáról, azt azonban érdemes megjegyezni, hogy a feladaton a szoftvercég nagyágyúi dolgoznak, mégpedig Eric Rudder vezetésével, aki anno Bill Gates lehetséges utódjaként is szerepelt. A belső források szerint a sokéves múltra visszatekintő veteránok (különféle hangzatos címekkel) maguk dolgoznak a kódon, ami jelzi, hogy nagyon is komolyan veszik a feladatot. Remélhetőleg a közeljövőben megtudjuk, hogy miként is fest szerintük a Windowst leváltó (vagy netán azt kiegészítő) rendszer.

A fejlesztői kit első változata március óta elérhető az egyetemi kutatók számára, további részleteket (azzal a kitétellel, hogy a Singularity maga NEM a következő Windows) pedig itt olvashatunk a platformról.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Sirkaan #77
    Szerintem a Midori != Windows 8. Windows 8 egy merőben más, de nem managed rendszer lesz.

    Gondoljatok csak bele egy Crysis 2 szintű játék hogy fog azon futni a jövőben. A játékfejlesztés elég erős ipar és egy ilyen managed rendszeren megpecsételődne az egész, már ami a windows-t illeti.
    .NET-es fejlesztőként tudom, hogy vannak buktatói a managed rendszernek, ami nem teszi alkamassá profi szintű rendszerközeli programok futtatására, ez sajnos tény. ;)
    A Vista C# graf felülete alatt is full natív DirectX támogatás van azért gyors, de Doom4-et nem írnék rá.
  • rigidus #76
    > adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos.

    Na, hat nagyjabol ezt probalom neked elmagyarazni. Ha pedig ezek az eltero adatszerkezetek egyetlen kozos grafba vannak szervezve akkor annak az egyes pontjai koze vektorok irhatok fel melyeken keresztul a leghosszabb ut determinalhato. (tovabbra is veges adatszerkezetekrol beszelunk)

    > Determinisztikus esetekre PLC-t használnak

    Altalanositas. Hol? Ipari kornyezetben lehet, de ennek semmi koze a temankhoz.

    > RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával.

    A tipusindexeles alapveto dolog.

    > sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e.

    Ez szinten nem ujdonsag.

    > Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény

    Ha tovabbra is kenyszerszeruen egy altalad valasztott konkret hagyomanyos nyelvi fordito, netan binaris targykod architektura sajatossagait alkalmazod altalanositasban.

    > mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét.

    Es itt tovabbra sincs kiemelve, hogy mindez a hagyomanyos operacios rendszereknel megszokasbol alkalmazott redundans osztaly/objektum nyilvantartas problemaibol adodik.

    Vegyel alapul egy terminalszervert ahol - mondjuk a gyakorlati pelda kedveert - 100 user van bejelentkezve es mindegyik 2 peldany Firefox-ot futtat. Az processzenkent (ures bongeszoket feltetelezve) nagyjabol 70MB, 200x70MB az 14GB-nyi lefoglalt memoria 200 redundans adattal ami 14GB helyett 70MB-tal is felirhato lenne ha van a hatterben egy kozos adatszerkezetbe szervezett egyszeru, kulturalt memoriahozzaferes-kezelesi strategia. Ha a merevlemezen rendelkezik egy futtathato binaris futtatasanak jogosultsagaval egy adott felhasznalo, akkor evidens, hogy ugyanannak a memoriaba mar korabban betoltott peldanyahoz is kell hogy jogosultsaga legyen, (!!) ha csupan az egyes felhasznalok altal folytatott tevekenyseg van kulon memoriateruleten kezelve es szeparalva. Ugyanezzel a modszerrel logikailag barmilyen eroforras megoszthato konkurrens peldanyok es felhasznalok kozott, csupan konfiguralas kerdese.

    > először is [b[biztos, hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed.

    Mivel?

    > A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak

    Igen, ezt jelenti az amit irtam: "Realtime tipusazonositas."

    > közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el.

    Es mekkora eroforrast visz el ha pont-pont kozti kapcsolatokra tucatnyi protokollt hasznalunk, netan egyikbol a masikba atjarunk?

    Melyik eroforrastakarekosabb? Egy jol atgondolt azonos protokollon keresztul barmilyen digitalis/digitalizalt adat tovabbitasa, vagy tucatnyi protokollt megirni, karbantartani, memoriaban tartani, egyidoben futtatni es netan egyikbol a masikba konvertalgatni?

    > Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak

    He?? Tobbek kozott eppen ezt hivatott garantalni azaltal, hogy a kozos protokollok (ertsd: kozos atjarasi pontok) miatt nem kell bloatware-eket karbantartani, nem kell 25-szor ellenorizni egy felhasznalo jogosultsagat ugyanahhoz az eroforrashoz, mert minden felhasznalo tevekenysege ugyanazon a grafon megy keresztul. Ha mar az elso lepesnel elakad a masodik kriteriumot meg sem kell vizsgalni. Es ez igaz barmely szituaciora, legyen az az eroforras akar egy memoriaterulet, egy tetszoleges periferia, egy hattertaron tarolt adat, vagy mittomen egy ugyviteli szoftver altal tarolt adatbazisrekord.

    > De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos.

    En nem igy emlekszem.

    > Tudod már miért akadt el az OO alapú Linux fejlesztése ?

    Nem, de attol tartok ezuttal sem fogom megtudni.
  • Jonah #75
    "1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?

    Nem-determinisztikus egy-egy fuggveny lefutasa."

    Visszacsatolt rendszerekben SEMMI sem determinisztikus, mert az egész egy nagy állapotgép. Determinisztikus esetekre PLC-t használnak, abban pedig biztosan nem lehet visszacsatolt hálózat, ezzel küszöbölve ki az illegális állapotokat (így nem lesz pl. a stop gombból fordulatszám növelés pl. marógépen).

    "2. Miert nem determinisztikus?

    Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)"

    adatszerkezetből adatszerkezetbe mutató adat elérési ideje korlátos, ha az elemek száma is korlátos. Az elérési időt csak a programozó határozza meg, legyen az akár VMT, vagy egy sima adattábla, esetleg közvetlen fügvényhívás azáltal, hogy milyen technikát alkalmaz.


    "3. Melyek ezek az esetek?

    Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)"

    RTTI működése a fordító kezében van. Minden típushoz hozzárendel egy bizonyos Typeid rekordot, melyben a típus sorszáma szerepel néhány más adat mellet. Ezt az értéket hasonlítja össze a beazonosítani kívánt típus azonosítójával. Ez viszont erősen korlátos futásidejű, C++ esetében 1-2% sebességcsökkenést okoz. sőt, léteznek advanced keresési technikák, ahol többezer adat közül max. 8-10 összehasonlításból megmondható a típusról, hogy megfelelő -e. ha pedig typeid(typespecifier) futásidejét nézzük, akkor annak ideje nagyjából egy órajelciklus, mert ez kb egy define-al egyenértékű művelet. Aztán a VMT-t meg jó is hogy nem írtad le. Mert amit te mondasz, az nem virtuális metódus lesz, hanem static osztály-tagfüggvény, aminek ténylegesen címet tesz bele minden tisztességes C++ fordító az álmoskönyvek szerint is. Virtual tagokra viszont ez nem érvényes, mert ott a VMT tagot az indexe fogja azonosítani (hasonképp mint ahogy egy DLL export függvényeit is azonosítják). Ezen index adat alapján lesz a tagfüggvény megkeresve és meghívva. Mindezt általában cachelik a fordítók a sebesség optimalizálás céljából (amig az objektum-mutató azonos típusra mutat, addig nem is szoktak új VMT keresést indítani). Persze lehet ezt is tárgykódban értelmezni, de sokkal rugalmatlanabbá válik a rendszer, ráadásul a VMT kérdése itt sincs megkerülve: mihelyst átadod az objektumod egy másik osztálynak, máris buktad az osztálytagfüggvény címét. A miértre válasz az öröklődés polimorf mechanizmusa. Ha egy osztálytagföüggvényt felülírunk, akkor annak indexe a régi osztály indexét örökli, de a leszármazottban a régi osztály metódusai még léteznek - mindössze az indexük íródik át (avagy egyes fordítókban egy külön pointer mutat a szülő osztály VMT-jére!).


    "4. Miert van erre szukseg?

    Hogy garantaljuk a tipusbisztos cimtartomany kezelest."

    először is [b[biztos[/b], hogy ezzel még nem lesz típusbiztos a címtartomány kezelésed. A típusbiztosság megköveteli, hogy a forrás és a cél típusa megfeleltethető legyen egymásnak. pl. a C++ eredetileg ilyennek indult, de aztán a C-ből átjött hozadék miatt már nem lett az.


    "5. Lehetseges ezt maskent garantalni?

    Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)"

    közös protokolokról nekem az usb jut eszembe. ott egy halom deszkriptor létezik, aminek a kitöltögetése a -közös protokol miatt- jókora erőforrást visz el. Vajon a közös protokolok nem visznek el erőforrásokat úgy, mint pl. egy VMT kezelés ?
    Ezen felül az autentikus adatszerkezetek által garantált adatelérési idővel pedig csak óvatosan. Ha nekem olyan az adatom, aminek a kinyerése az adatszerkezetből NP teljes problémát vet fel, akkor a garantálhatóságot dobhatod a kukába.

    "Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)"

    Na persze, és így lesz egy multitask operációs rendszerből multi threaded single task. Ami nagyjából semmit nem ér, mert ad egy nagy pofont az adatbiztonságnak, a szálbiztonságnak, a "közös lónak túros a háta" elvnek, de cserébe garantáltan felvet jópár deadlock problémát, illetve egy halom olyan dolgot, amit még az ellenségemnek és t. családjának sem kívánnék.

    Ebből nekem kb. az jön le, hogy lehet olvasott vagy, sokat foglalkoztál vele. De hogy OS-t nem írtál még sem embedded sem PC környezetben az biztos. Amúgy csípem a humorod, legalább értelmesen beszélgetsz:-) Tudod már miért akadt el az OO alapú Linux fejlesztése ? :-))

    üdv.
  • rigidus #74
    > pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt.

    Nem. Rossz a megkozelites. Csak a felszinig messz el a problema okozojanak keresesekor, majd egy felvalasszal felbe is hagyod a keresest. :-) MINDIG vezesd vegig lepesrol-lepesre visszafele a valaszt egy adott kerdesre es megtalalod az okozojat a gyokereknel (mely okozo rend szerint mashol is problemakat okoz).

    Peldaul, hogyan jutunk el az aktualis problema okozojahoz:

    1. Miert nem hasznaljak RTOS-ek alatt a OO nyelveket?

    Nem-determinisztikus egy-egy fuggveny lefutasa.

    2. Miert nem determinisztikus?

    Mert szinte ismetlodoen adatszerkezeteken keresztul kell elernie mutatokat melyek eleresi ideje bizonytalan. (proceduralis paradigmat kovetve is vannak ilyen esetek, de a hangsuly szinten a gyakorisagon van)

    3. Melyek ezek az esetek?

    Realtime tipusazonositas. (VMT-t szandekosan nem irom ide mivel futasidoben nem kell foglalkozni az osztalykonzisztenciaval ha a targykodban a metoduscimet tarolod. Ez kizarolag a forditasi idot befolyasolja)

    4. Miert van erre szukseg?

    Hogy garantaljuk a tipusbisztos cimtartomany kezelest.

    5. Lehetseges ezt maskent garantalni?

    Igen, lehetseges, ha az adatszerkezetek kozti atjarhatosagot kozos protokollokra helyezzuk. Ha autentikus adatszerkezeteket alkalmazunk melyek kozos protokollba (pl. kozos graf adatszerkezetektol fuggetlenul) szervezhetoek akkor globalisan, a teljes rendszerben tetszoleges adat eleresehez szukseges legrosszabb eleresi ido mindig determinalhatova valik. (Az most mas kerdes, hogy sokszor nem csak a legrosszabb eset, hanem ennel joval tobb informacio is determinalhato)

    Egyebkent a fenti modszerrel az OO alkalmazasokat jellemzo nagy memoriahasznalat is radikalisan csokken ha elunk is a kedvezo lehetosegekkel es eleve ugy epitjuk fel az OS-t, hogy a redundans memoriahasznalatokat mersekelje. (Ugye ha a problemat gyokereiben kezeljuk, varhato hogy mas problemaktol is szabadulunk, amelyeket talan korabban altalanosan el is fogadtunk mellektermekkent es igy mar nem is foglalkoztunk veluk)
  • Jonah #73
    Ez érdekes. Hogy mikor keresünk a VMT-ben ? pl. a virtuális metódusok hívásakor. ezen függvények hívása biztosan lassabb lesz. Emiatt nem is alkalmazzák embedded cuccokban RTOS-ek alatt. Inkább C és asm.

    üdv.
  • rigidus #72
    > mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását

    Meg mindig elbeszelunk egymas mellett. Elismetlem megegyszer: szo sincs a VMT megszunteteserol. Meg csak utalast sem tettem erre. Es kerem, hogy ezuttal tenyleg legyen vilagos.

    Az idezetemben ezert vastagitottam ki a "folyamatosan" szot, mert a kezdetektol fogva a VMT-ben valo kereses gyakorisagara (es modjaira) utalok.

    Most azt, hogy hogyan oldottam meg adatszerkezeteken keresztul az ilyen jellegu problemakat azt minimum egy hetes eloadas sorozaton keresztul tudnam levezetni neked. Nem apro konstrukcios ujitasokrol van itt szo (az en esetemben), hanem teljesen uj nyelvi leiro rendszerrol, teljesen uj eroforras kezelesrol, teljesen uj generacios forditoprogramrol. Meg forraskod sincs a hagyomanyos "szoveges fajl" ertelembe veve es megcsak a fogalom, hogy "fajl" sem letezik.

    Egy sokdimenzios csomoponti adatbazis van ahol a programozo/felhasznalo szemszogebol nincsen protokolbeli kulonbseg egy "konyvtar" mint gyujtoeszkoz, "fajl" mint taroloeszkoz, "port" vagy "halozat" mint I/O eszkoz, vagy akar felhasznalo, process, stb mert mindegyikuket transzparensen azonos protokollon keresztul eri el. Ami megkulonbozteti oket az a rajuk valo hivatkozas (nev, azonosito, stb).

    Ez a kialakitas termeszetenel fogva olyan teljesen uj lehetosegeket hoz amelyeket ha egyuttesen alkalmazunk akkor ujra kell alkotnunk a szamitastechnikarol, informatikarol eddig tanultakat es teljesen maskent kell megkozelitenunk reszproblemakat.
  • Jonah #71
    tudod, ezzel van egy kis gond....

    mégpedig: ha egy osztályalapú OS-t veszel alapul, biztosan nem kerülheted el a VMT alkalmazását, ami viszont minden egyes függvényhíváskor lassít egy picit. Talán többet mint egy szimpla "rep movsd". Ráadásul ez esetben is van egy probléma: nem tudod, és nem is tudhatod, hogy az adott OS fordításakor milyen címre linkelődik egy-egy metódus. Vagyis csak úgy, ha létrehozol egy -a metódusra mutató- adatterületet. aminek értékét átadod a megfelelő helyeken. Viszont még mindig van ezzel egy probléma. Ez pedig a méret, mert ha mindenkinek átadod ezt, akkor ők is tárolni fogják azt valahol, ami az erőforrások felesleges elfecsérléséhez vezet. Vagy mégjobb, átadunk egy mutatót, ahol ezen metódusok le vannak írva. És ezzel már gyak. létrehoztuk a VMT-t egy valamilyen osztályra. Aztán sebességbeli gondok is vannak.
    mert pl egy
    MOV ebx, [ebp+16*4]
    call ebx
    sokkal lassabb mint egy

    call directcall

    hívás. Nem beszélve az objektumpointerek kezeléséről, mert ott is akadnak gondok. emiatt az OO az embedded cuccokban nem véletlen nem kapaszkodott meg. Ha nem lenne sebességbeli gond, már régen abban írnák az oprenccerek zömét.

    Apropó, tudod, hogy végül miért akadt el az OO-ban írt linux?


    üdv.
  • rigidus #70
    > Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?

    Es most ahogy latom, hogy itt alapfogalmakban levo hianyossagok is felszinre kerultek, ugyanis a VMT lenyege - mint Virtualis Metodus Tabla - a neveben is hordozza, hogy az a virtualis metodusok cimterenek es egyeb kiegeszito adatainak gyujtemenye, nem pedig a polimorfizmus feltetele. A kettonek egyebkent semmi koze egymashoz.

    A VMT-ben kizarolag a virtualis metoduskenk, netan virtualis property-kent definialt elemek tarolodnak. Normalisan megirt forditoprogramok a VMT-t letre sem hozzak olyan osztalyoknal ahol virtualis elemek nincsenek definialva. Az oka pedig amiert a VMT-re szukseg van, hogy amikor egy leszarmaztatott osztalybol letrehozott objektumon belul egy felul nem irott metodusunk egy virtualis metodusara hivatkozik, azt tudnia kell, hogy az uj osztalyban nem lett-e veletlenul felulirva az ominozus virtualis metodus. Ha igen, akkor az ososztaly metodusanak a leszarmaztatott osztaly felulirt metodusara kell hivatkoznia, hiszen pont ez a virtualis elemek lenyege.

    A polimorfizmus pedig az orokolt valtozok, property-k, metodusok es egyeb osztalyokba foglalt elemekre valo hivatkozas a leszarmaztatott osztalyokbol azonos neven. Ennek pedig az egvilagon semmi koze a VMT-hez.
  • rigidus #69
    > Kiröhögöm a vakbelem, pont te beszélsz kultúráról, aki még az ékezetet sem ismeri és (idézlek!) "bisztos" a dolgában.... LoL

    Ekezet ismerete nem gond, meglete mar annal is inkabb. Ha Magyarorszagtol tavol elsz es nem all rendelkezesedre magyar nyelvu ekezetes billentyuzet, nem ismered a magyar billentyuzetkiosztast mert talan nincs is ra szukseged a hetkoznapi eletben meg nem a kultura hianyat jelenti, csupan azt, hogy a rendelkezesre allo lehetosegeid korlatozottak.

    A kozvetlen hangnemedbol feltetelezem, hogy Te egy magasan kvalifikalt szakmernok vagy aki annak idejen az egyetemen megtanulta, hogy a tanulas egyik legjobb eszkoze a kommunikacio mas szakemberekkel es annak a levezetese erzelmi kicsapongasok nelkuli pusztan muszaki alapokon. Abban is egeszen biztos vagyok, hogy az egyetemen elhangzott az is, hogy annyi tisztelettel kozelits meg masokat, mint amennyit viszont elvarsz magad is, tovabba abban is biztos vagyok, hogy ezek tettleges cafolataval - mint irasaid kulturalis minosegevel - nem hagynad, hogy masok hite meginogjon az altalanos muveltseged irant.

    > Basszuskulcs, a többalakúságot hogy realizálod ?

    Tovabbra is meggyozodesem, hogy egy kulturalisan erett, kutatoi figyelemmel rendelkezo kollegaval beszelgetek aki minden mondatot korultekintessel ertelmez.

    Ime egy korabban elhangzott mondatom amire a fenti valaszod erkezett:
    "miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?"

    Itt pedig a tobbi:
    ...ezeknek a problemaja egyetlen gyokerben keresendo es ez nem maga az OO paradigma, hanem ezeknek a jelenlegi megvalositasaba. (adatszerkezetkeben, kodgeneralasban, eroforraskezelesben es azoknak az EGYUTTES hatekony alkalmazasaban). A hagyomanyos operacios rendszereknel erre meglehetosen korlatozott lehetosegek allnak rendelkezesre.

    > Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?

    Ez hol hangzott el?
  • Jonah #68
    "Itt is megkerdeznem: kultura?"

    Kiröhögöm a vakbelem, pont te beszélsz kultúráról, aki még az ékezetet sem ismeri és (idézlek!) "bisztos" a dolgában.... LoL

    "miert van ra szukseg, hogy a VMT-ben, stb folyamatosan keresgelj?"

    Basszuskulcs, a többalakúságot hogy realizálod ? Avagy bármiféle interfészt, esetleg absztakt osztály leszármazottat (többszörös öröklődés esetén) ?

    Te öt éve dolgozol ezen. Grat. Nyilván az ismereteid sokasága gátolt meg eddig az elkészültében :DDDDD

    üdv.