Gyurkity Péter

128 bites lehet a Windows 8 és 9

Egy munkatárs internetes profiljában akadtak a szemfülesek újabb részletekre a Microsoft terveivel kapcsolatban - tervezik a 128 bites architektúra támogatását a következő operációs rendszerekben.

Az elmúlt hónapokban számos esetben olvashattunk arról, hogy a Windows 7 után valami egészen más érkezik majd, valószínűleg a jól ismert nevet is elhagyja a szoftvercég. Ehhez képest most egy alkalmazott LinkedIn profiljából meríthetünk némi információt a tervekkel kapcsolatban, ezek pedig több érdekes részletet is tartalmaznak, amelyekből legalább ilyen érdekes következtetéseket vonhatunk le.

A Windows 8 News még szeptember végén hozta le a hírt, hogy a Microsoft Senior Research & Development egyik munkatársa fontos hírmorzsákat közölt a LinkedIn oldalán található profijában. A cégnél immár több mint 7 éve dolgozó szakember többek között megemlítette (azóta eltávolított bejegyzéseiben), hogy jelenleg a tervezési fázisnál tartanak a Windows 8 és 9 operációs rendszereket illetően, itt pedig komoly eshetőségként merült fel a 128 bites architektúra teljes körű támogatása, mégpedig olyan partnerek részvételével, mint az AMD, az Intel, valamint az IBM. Utóbbi cégeket már bevonták az egyeztetésekbe, innentől kezdve pedig már csak az a kérdés, hogy valóban megmaradnak-e az eredeti elgondolás mellett a várhatóan 3 év múlva megjelenő következő verziónál.

A nagyobb internetes lapok csak az utóbbi napokban kezdték el átvenni a hírt, azzal egészítve ki azt, hogy a LinkedIn oldalán megtalálható bejegyzéseket már eltakarították, illetve hogy a Microsoft tervei valamennyire egybevágnak az AMD elképzeléseivel, amely Bulldozer kódnéven fejleszt olyan chipeket, amelyek már támogatnák a 128 bites architektúra bizonyos elemeit. Kezd tehát összeállni a kép, bár nyilván nem érdemes elsietni a találgatásokat, hiszen már korábban is volt arra példa, hogy fontos újításként beharangozott elemek maradtak ki az operációs rendszerekből.

Érdekes adalék, hogy a Microsoft jelenlegi álláspontja szerint a Windows 7 kiemelt jelentőségű állomás a Windows család életében, vagyis a következő verzió a jelenleg alkalmazott gyakorlat értelmében kevésbé fontos fejlesztés lesz (bár akkor felmerül a kérdés, hogy a Vista "Major", avagy "Minor" lépésnek minősült-e megjelenése idején).

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)
  • [HUN]FaTaL #84
    "Az opera peldaul kezeli a flash-t mindegy neki,"

    Persze mert az opera 32bites így önmaga is emulálva fut, benne egy 32bites flash playerrel. Nincs 64bites opera. Jelenleg csak IEből van natív 64bites (nincs is alatta flash), meg FFből valami tákolmány (ezalatt sincs flash).
  • BlackRose #83
    Ez igy kb. OK... de azért mégis csak van különbség ha több bit fér el a regiszterekben :) persze nem akkora mint ahogy sokan gondolnák de mégis. A 8088-80286 (és az utodok is részben) memóriakezelésével pedig nem igen kell foglalkozni, ugyanis ott éppen, hogy nagy baj volt a 16 bites regiszter és a 20 bites memóriacímzés... elképesztő sokat szívtunk annak idején a "szegmentált" memóriacímzésel az offszetekkel, nagyon sok korlátozás volt itt... még nem jött a 32 bites mód a PC szart sem volt képes a szintén 16 bites CPU-kal szemben de amelyeknek 32 bites regiszterei voltak (Apple, Amiga, Atari...) mindég a fél program a memóriával szarakodott és ami még roszabb volt a programozó több időt töltött (tudom mert csináltam) az adatstruktúrák adaptálására az adott memóriamodelhez és a korlátozások "áthidalására" mint a valódi problémák megoldására. Szóval a több bit jobb, a 128 bit jobb mint a 64 bit... a baj csak ott van, hogy jelenleg nincs rá szükség, ha ezt a fejlődési ütemet tovább tudjuk produkálni akkor lehet, hogy 10 év múlva majd kell de most jelenleg az ég világon nem tudnánk mit kezdeni vele és ha egy-két pici tartományban esetleg tudnánk akkor meg gazdaságilag nem értelmes mert nagyon sokba kerül a váltás és nincs megtérülés.
  • krajcsovszkig #82
    32 bites visztán is lehet több ramot elérhetővé tenni parancssorból csak lassú lesz a ramkezelés mint a rosseb.
  • Komolytalan #81
    Azért kicsit kerüljünk már képbe a mi hány bites ügyben. 8088-as processor, DOS:
    16 bites regiszterek
    8 bites adatbusz
    20 bites címzés
    32 bites fájlrendszer
    10 bites HDD track szám
    6 bites HDD sector/track szám.
    9 bites sector/byte szám.
    Oszt mégis működött, frankón. Az hogy az oprendszer hány bites semmi mást se határoz meg, minthogy a memóriát hány bites címzéssel éri el. Ezt persze a processzornak is tudnia kell, de ennyi. A processzor regiszterei, adatbusz, fájlrendszer, minden-minden hány bitessége ettől teljesen független. Nem kell összeszarni magunkat attól pl ha csak 16 bites regisztereink vannak, és 32 bitet kell címezni, mivel kb 3 db assembly műveletből össze lehet állítani a címet. Nem ettől lesz lassú a Crysis, hanem attól, hogy a winfos kiswapeli az agyát, hogy a játék 2G-s fájlos 1x betöltött adatfájlát cachelni tudja.

    Lehetett a 16 bites oprendszer (DOS) alatt com fileokat írni, amik 64Kbyte memóriát láttak. Meg lehetett exe-t, amik már 640Kbyte memóriát láttak (holott 1024-et kellett volna a 20 bites címzéssel, de hát ilyen az élet, ahhoz már kellett XMS/EMS, ami meg csak 286-on jött be).

    De lehetne arról is beszélni, hogy 32 bites linuxon mit is csinál a PAE kernel. Merthogy ez biztosítja azt, hogy a 4G feletti memória tartományt is ki lehessen használni. Igaz, 1 program továbbra is csak 32 bittel indexelhető memóriát ér el, de ha van 16 gigád akkor mondjuk 4x3.5G belefér (kernelnek meg egyebeknek is kell azért memória). Mindezt 32 bites oprendszeren ugyebár.

    Az hogy 1 fájl mekkora lehet az abszolúte nem függ attól, hogy az oprendszer hány bites. A DOS 20 bites volt, a file pointerek meg 32 bitesek, alapból, már akkor amikor 360KByteos-s floppy volt a menő. Fat32 filerendszerben a file pointerek 32 bitesek, tehát rakhatod 128 bites oprendszer alá is, akkor se fogsz benne 4G-nál nagyobb fájlt csinálni. NTFS filerendszerbe meg XP alatt is csinálhatsz 4Gnál nagyobb fájlt. Persze ha egy fos böngésző ezt úgy akarja, hogy beolvassa az egészet memóriába, és utána egyben kimenti, akkor ott out of memory lesz. De ez programkód gyengeség - 4G memóriát nem foglalunk le buffernek. Aki ilyet tesz el kéne tiltani a programozástól egy életre.
  • Komolytalan #80
    De írhatnál akár te is, mivel az swf formátum már évek óta nyílt. És nyílt formátumra nem csak linux alatt lehet fejleszteni, hanem pl windows alatt is. Senkinek sincs megtiltva.
  • BlackRose #79
    Főleg ha nem kis hanem nagy "indián". :)
  • Yv@n #78
    Há mer kéccer olyan jó mint a 64-es! :D
  • krajcsovszkig #77
    128 bit meg mi a f.sznak?
  • kvp #76
    "Mert linuxon nincs 32bites emuláció, tehát x64-es linuxon nem fut a 32bites program, csak 64bites. Ami nem gond ott ahol nem egy zárt szar fejlesztőjére kell várni(adobe)."

    Mondjuk 64 bites linuxon is van 32 bites mod (debian-on legalabbis), csak kevesbe tamogatott mint windows eseten.

    "vindózon azért kell várni meg a 32bites is, linuxon meg nem!"

    Mindket rendszeren megoldhato a 32 bites plugin futtatasa 64 bites bongeszoben, csak egyik rendszeren sem elegans a megoldas. Az opera peldaul kezeli a flash-t mindegy neki, hogy windows vagy linux es 32 bit vagy 64 bit. Csak nem elegans, nem gyors es nagyon nem stabil ha hack-elni kell valamit.

    "Pl engem kifejezetten zavarna ha a böngészőm 2G memóriánál többet használna, vagy ha egy html fájl több mint 2GByte lenne."

    Akkor az is zavaro ha egy 4 GByte-nal nagyobb file-t kell letolteni es mukodik, ugyanis egy 32 bites bongeszokon trukkozni kell, hogy ez menjen. 64 bites rendszereken sokkal egyszerubb es stabilabb kodot lehet irni. A nagy meretu kepek es egyeb beagyazott tartalmak kezeleserol nem is beszelve.
  • [HUN]FaTaL #75
    Mi van?:D Milyen HTML fájl? Te miről beszélsz?:D Kevés embernek sikerül ennyi baromságot egy HSZ-ben összehordani. Azért mert valami 64bites nem használ rögtön 2GByte memóriát .