Egyenként képes hibernálni az alkalmazásokat a Windows 8

Egyenként képes hibernálni az alkalmazásokat a Windows 8
2012-04-18T18:00:16+02:00
2012-04-20T10:01:12+02:00
2022-10-25T09:41:52+02:00
  • És ami ott is felettébb idegesítő.


    Igen, ez a te véleményed. A gond az, hogy a mobilokat, a tableteket, de még a desktop oprendszereket se személyesen rád szabják, hanem a felhasználók többségére. Szabad neked ezt a feature-t nem szeretni, de ez nem objektíve hátránya a megoldásnak.

    Könnyű annak aki csak egy projekten dolgozik...


    Ezt kérlek honnan vetted? Egy IDE ablakban lehet ám több project is...
    Mutasd a teljes hozzászólást!
  • Az átlagfelhasználó
    1. nem olyan "control freak", mint te
    2. ha az is, piszkosul nem érti az alkalmazások és a rendszer működését, így gőze sincs arról, hogy mi a különbség a futó, a hibernált és a háttérben bezárt alkalmazás között, ha ez amúgy vizuálisan, felhasználói élmény szempontjából semmi különbséget nem jelent számára.

    A fentiekből eredően őt piszkosul nem fogja izgatni, hogy a Windows mit csinál majd az alkalmazással - ha viszont azt látja, hogy a szerényebb processzor és kevesebb memória miatt feleannyiba kerülő és egy töltéssel kétszer addig működő WP8 telefonja még sokkal reszponzívabb is (pl. mert sokkal jobban képes a rendelkezésére álló erőforrásokat kihasználni többek között az automatikus alkalmazáshibernációi miatt is), mint a kétszer annyiba kerülő és egy teljes munkanapot sem bíró csilliómagos Android vagy iOS telefonja, akkor bizony előbbit fogja megvenni.

    Igen, még a fejlesztő is, aki előbb-utóbb rá fog jönni, hogy eddig is csak azért volt fontos neki, hogy tudja hogy az alkalmazása a háttérben él -e még vagy már meghalt, mert a rendszere akadozott és neki kellett kézzel optimalizálnia (a taszkok kilövöldözésével) - de marhára nem fogja érdekelni onnantól kezdve, hogy a készüléke önmagától is rendesen, gyorsan és reszponzívan működik.

    Tudom miről beszélek. Az elsők között volt androidos mobilom (amit az összes korábbi smartphone platformról is elmondhatok), szenvedtem számos változatával, ismerem minden nyűgjét is - és nem olyan régen már túl is léptem rajta és már más rendszert használok. Majd ti is túl fogtok. Következőnek pedig egy Windows Phone mobilt tervezek majd venni.
    Mutasd a teljes hozzászólást!
  • Gyakorlatilag azt a gondolkodásmódot követi, amit mondjuk egy mobiltelefonon természetesnek veszel.

    És ami ott is felettébb idegesítő. Egy alkalmazás vagy fusson vagy ne. De ezt én döntsem el, és tudjak róla hogy ott van, fut, és eszi az erőforrásokat. A droidon is rohadt jó hogy ott csücsül benn egy rakás app anélkül hogy ezt látnád valahol, és csak a beállításokban lehet korrektül kilövöldözgetni őket.

    De a fejlesztő IDE-m is ugyanígy van beállítva. Ugye csak amiatt, hogy kikapcsolom a gépet (mondjuk újra kell indítani frissítés miatt, vagy aznapra végeztem a munkával), még nem akarom eltüntetni a folyamatban levő dolgaimat.

    Könnyű annak aki csak egy projekten dolgozik...
    Mutasd a teljes hozzászólást!
  • A fő gond az, hogy ez a funkció sokkal inkább idegesítő mint hasznos.


    Szerintem félreérted a funkció célját. Nem az a feladata, hogy lehibernálj egy programot, aztán majd két hét múlva vedd elő megint. A célja inkább az, hogy ne kelljen törődnöd vele, mi fut éppen és mi nem: van egy rakás programod, váltogatsz közöttük, és mindegyik egyszerűen csak előjön, ha kiválasztod. Az oprendszer meg a háttérben gondoskodik róla, hogy memóriahiány esetén először "hibernáljon", és ha ez nem segít, akkor be is zárjon processzeket. Gyakorlatilag azt a gondolkodásmódot követi, amit mondjuk egy mobiltelefonon természetesnek veszel.

    Egyébként is csak a saját nevedben tudsz beszélni. Én például már évek óta úgy használom a böngészőmet, hogy azzal a tabokkal jön fel, amivel legutóbb bezártam. De a fejlesztő IDE-m is ugyanígy van beállítva. Ugye csak amiatt, hogy kikapcsolom a gépet (mondjuk újra kell indítani frissítés miatt, vagy aznapra végeztem a munkával), még nem akarom eltüntetni a folyamatban levő dolgaimat.
    Mutasd a teljes hozzászólást!
  • Szerintem pedig leginkább azért lett sikeres, mert az Apple eladta a népnek - illetve, hogy nevet adott a gyereknek. Az emberek ugyanis nagyjából folyamatosan vesznek új mobiltelefonokat, és aki nem az 5000 forintos tesco takarékos készülékben gondolkodott, az addig is meg tudta venni a maga 60-70-100 ezer forintos mobilját. Az Apple ezt használta ki, hozzáadta a márkanevet, a design-t, kitalált hozzá egy jópofa maszatolós UI-t (pontosabban lenyúlta az egyik sci-fi filmből) és eladta a népnek mint prémium kategóriás telefont. És nyert. Aztán jött a gugli, és megcsinálta ugyanennek a klónját, stílusosan linux alapokon. De ettől, aki okostelefont vesz, az többnyire telefont vesz, a többi igazán csak mellékszolgáltatás. Ebben persze nagy pénz van - mindig is az volt - elvégre a telefon státusszimbólum is. A másik oldalon pedig az androidnak hála lassan nem lesz butatelefon, mivel a lassan a legolcsóbbakban is andorid lesz. És mivel ez a két platform van, így ezek nagyon gyorsan terjednek.

    A PC piac meg stagnál, a kettőből meg a nagyokosok kisakkozták, hogy a PC-t felváltja a kvarcjáték.

    Amúgy pedig az egyszer írd meg és mindenhol fut dolog ezzel valósul meg a legkevésbé. Ez ugyanis csak a MS által támogatott platformokon lesz elérhető. Azaz windows8 és kész. Ami persze nem lenne gond, ha mondjuk 1994-et írnánk. De most 2012 van, és a célbavett platforomokat nem a MS uralja.

    Akkor járt volna jól el a MS, ha legalább a .NET-es WPF-es és Silverlightos progikat, illetve a winforms valamilyen subsetjét változtatás nélkül lehetne futtatni a winRT-n. Akkor nem 0 programmal indulna el egy olyan piacon ahol a konkurencia alkalmazásboltjaiban tízezerszám állnak a kész alkalmazások.
    Mutasd a teljes hozzászólást!
  • Szerintem meg az okostelefon pont azért lett sikeres végül és azért szorít ki minden mást (nem csak a mobilok piacán, de a fényképezőgépekét, játékgépekét, sőt, netbookokét is felzabálja), mert jól egyesített magában mindent a kvarcjátéktól kezdve egészen a szerverfunkciókig. Nyilván nem tökéletesen mindenre, sőt, szinte mindenre szuboptimális megoldást nyújt, de a hétköznapokba nem is kell profi fényképezőgép, profi játékgép, profi laptop - hanem éppen elég ha balesetnél tudok közepes minőségű képeket csinálni amin látszik, hogy az autók hogyan álltak, ha a buszon-metrón-vonaton tudom valamivel múlatni az időt, és ha meg tudom nézni a legfontosabb leveleim, dokumentumaim, kedvenc weboldalaim.

    A Metro és a WinRT egy hasonló módon univerzális felület és alkalmazásmodell - ami ugyan nem tökéletes mindenre, sőt, mindenhol kompromisszumokra kényszeríti az embert, de cserébe az informatikatörténelemben először végre valóban ad majd egy olyan platformot, ahol a marketingszövegeken túl is megvalósulhat majd az "írd meg egyszer, futtasd mindenhol" koncepció (amelyen már korábban számtalan platform elvérzett, a Java-tól kezdve a .NET-en át a Google okosságaiig).

    Ez pedig egy piszkos nagy fegyvertény lesz a Microsoft kezeében és óriási fegyvertény a Windows mellett, azokon a platformokon is, ahol jelenleg még igen szerényen teljesít.
    Mutasd a teljes hozzászólást!
  • Eleve attól nem vagyok elragadtatva, hogy keverik a desktopot a kvarcjátékokkal. A két dolog alapvetően másra való - bár tény, hogy van 3-4 dolog amit kvarcjátékon és desktopon is lehet csinálni, Pl. webet, videót nézegetni, játszani - bár szvsz alapvetően más játékokat igényel a két platform. De igazán azt, ami miatt az emberek a desktopot használják nem lehet jól csinálni kvarcjátékon. És nem azért, mert nem lehet olyan vasat belegyömöszölni, hanem egyrészt mert a maszatolós felület napi 8 órában elég kényelmetlen a hagyományos billentyű-egér kombóhoz képest, másrészt ha szöveget kell bevinni, akkor a virtuális billentyűzet - amellett hogy rosszabb mint a legbóvlibb tajvani ipari hulladék - ki is takarja a képernyő nagy részét.

    A dolog másik oldala az időzítés. Már lassan egy fagyiért lehet ócsított droidos tabletet venni. Erre a piacra szerintem legalábbis kétesélyes a windows betörése, bár szerintem még ez is indokolatlan optimizmus. A hagyományos desktopon pedig a winRT és az egész win8 UI visszalépés a win7-hez képest. Ráadásul a csoda winRT-s cuccod nem fogod tudni eladni a win7-es és XP-s usereknek.
    Azaz, úgy 3-4 évig garantáltan elveszíted a potenciális usereknek nagyjából a felét (és ez már a 4. évben lesz, eleinte ez az arány sokkal rosszabb), míg a másik oldalon nincs rá garancia hogy a win8 nem fogja megismételni a WP7 "sikertörténetét", elvégre egy olyan piacra próbál betörni ahol már domináns szerepet tölt be az IOS, és mellette ott van egy szintén elég erős, ráadásul ingyenes Android. A MS-nek akkor is nagyon-nagyon nehéz ügy lenne ez, ha amúgy az egész fényévekkel lenne jobb mint a másik kettő.

    MS-ék ott szúrták el szerintem, ahol sokan mások is - nem fogják fel, hogy a desktop piac az egy, a kvarcjáték piac az még egy, és a kettőnek nem sok köze van egymáshoz. Senki nem fog okostelefonon napi több száz számlát felrögzíteni, és senki nem fog asztali PC-vel navigálni.
    Mutasd a teljes hozzászólást!
  • A fő gond az, hogy ez a funkció sokkal inkább idegesítő mint hasznos. A másik gond az, hogy normálisan megcsinálni eleve lehetetlen, mivel egy program a világgal kommunikál - a világot pedig nem lehet hibernálni a program mellé. Azaz, hiába szedné elő Pl. a notepad++ defaultból 20 évre visszamenőleg az összes szerkesztett fájlt, ha azokat már rég töröltem winchesterről. Na, és persze ez az első dolog amit kikapcsolok benne telepítéskor.
    De annak sem örülnék túlzottan, ha a Visual Studió az utoljára szerkesztett projektemmel indulna, úgy ahogy azt hagytam, mert egyrészt nem biztos, hogy legközelebb is ezt a projektet akarom megnyitni, másrészt nem biztos, hogy pont ott akarom csesztetni.

    Azaz, nem mondom hogy nincs olyan terület ahol ez hasznos lehet, de én ezt nem érzem annyira hasznos képességnek ami miatt érdemes win7-ről win8-ra váltani.
    Mutasd a teljes hozzászólást!
  • Hát igen, Win32 alatt ez nagyon bonyolultnak tűnik, de az egész gépre csak megoldották...


    Ha az összes processz megáll, akkor nyilván nincs olyan probléma, hogy egymásra várnak és deadlock lesz. Ha meg csak egy áll meg, akkor lehet.
    Az egész gépre megoldani is jár nehézségekkel, de inkább a driverek oldaláról, mert a rendszernek képesnek kell leállítania, majd felébredés után nagyjából a régi helyzetébe visszahoznia minden hardvereszközt. Persze még ezen a szinten se tökéletes a dolog, a TCP kapcsolatok pl. megszakadnak.

    elvileg akkor meg lehet oldani processenként is, különösen ha bevezetünk egy üzenetet, hogy le akarják állítani, az meg válaszol, hogy hozzájárul.

    De ha a programnak fel kell készülnie erre az eshetőségre, akkor a régi programokon nem fog működni, ez már eleve inkonzisztens felhasználói élmény. A másik, hogy egy szoftverfejlesztő cégnek miért lesz érdeke extra kódot írni ennek a támogatására? Ha összevetjük, hogy hány embert motivál a "suspend" funkció vásárlásra, és mennyit kell a lefejlesztésére költeni, szerintem az jön ki, hogy nem éri meg.

    De persze a jogot fenntartom, hogy tévedjek
    Mutasd a teljes hozzászólást!
  • A "Windows Phone, Fejlesztés lépésről lépésre" könyv felénél tartok (bár épp suspended a státusza), szóval egy első benyomásom van a Metro programozásáról.
    Ez alapján a webszerverhez hasonlóan stateless a Metro megközelítése, ami lehetővé teszi a process hibernálását.

    Hát igen, Win32 alatt ez nagyon bonyolultnak tűnik, de az egész gépre csak megoldották... elvileg akkor meg lehet oldani processenként is, különösen ha bevezetünk egy üzenetet, hogy le akarják állítani, az meg válaszol, hogy hozzájárul.
    A jövőre nézve megoldhatja a kérdést, különösen a menedzselt, futtató környezettel kontrollált alkalmazásoknál.

    Bár ki tudja mik a terveik?
    Ahogy én látom a Metro mindenesetre képtelen átvenni egy "igazi" alkalmazás feladatát (ahogy a weblapra is csak ráerőltetni lehet bizonyos funkcionalitást), így marad a win32/.net fősodor.
    Mutasd a teljes hozzászólást!
  • Nem csak GUI szálak léteznek a világon. Egy tetszőleges parancssoros programról, vagy egy GUI program worker thread-jéről legfeljebb a program fejlesztője tudná megmondani, hogy milyen állapotban biztonságos felfüggeszteni, az oprendszer látatlanban biztosan nem.
    Mutasd a teljes hozzászólást!
  • Rosszul irtam, na :D szoval az event handlerre gondoltam, inkabb ott legyen egy hibernalasi pont, mint egy tetszoleges idopontban, amikor isten tudja, hogy eppen mit csinal az a program.
    Mutasd a teljes hozzászólást!
  • Szerintem elbeszélünk egymás mellett. A Metro appokhoz nem értek, ezért javíts ki, ha tévednék, de az eddig olvasottak alapján két dolog történhet egy Metro app-pal, ebben a sorrendben:

    1. Suspend állapotba kerül. (Effektíve bármikor, amikor nem látszik, ebbe az állapotba kerül.)
    2. A memóriája majdnem teljesen kiíródik lemezre. (Csak akkor, ha az oprendszer szerint kevés a memória.)

    Ha nagyon akarjuk követni a hibernációs hasonlatot (amit az eredeti blogbejegyzés is csak hasonlatként használ), akkor az első lépés a suspend-to-RAM, a második a suspend-to-disk.

    Amiről te beszélsz, az az első lépés, és én is egyetértettem benne, hogy ezt a jelenlegi Win32 API-jal nem lehetne megoldani. Ahogy a blogbejegyzés is rámutat, a suspend-elt Metro app egyáltalán nem fut, vagyis a suspend műveletnél meg kell csinálni mindazt, amit írsz.

    A második lépéshez viszont már nem szükséges új API, se forradalmian új kód. Annyit kell a meglevő lapozás mellé implementálni, hogy extrém módon le tudja csökkenteni a processz working set-jét, és ezeket a lapokat folytonosan mentse a lapozófájlba. Erre mondtam, hogy ez egy ügyes tweak.
    Mutasd a teljes hozzászólást!
  • Van erről valami forrásod? Az eredeti blogbejegyzés csak a user memória mentéséről beszél, de attól persze még lehet, hogy a kernel memóriájából is ment.

    A cikk egyáltalán nem beszél kernel meg user memóriáról, kódról. Ugyanakkor teljesen nyilvánvaló, hogy ezt a processz hibernációt nem lehet úgy megcsinálni, hogy csak úgymond benyomom a pause gombot a processzen: azaz egyszerűen nem ütemezem újra, és szépen elmentem a user space területét a lemezre; aztán a visszaállításkor meg visszatöltöm mindezt a memóriába, újból engedélyezek a folyamat ütemezését, aztán minden mehet tovább ott, ahol megállt. Még azt se ha leszámítom azt, hogy ennek az egésznek csak akkor lehetne nekikezdeni, amikor az összes kernel-hívás visszatérését megvártam - ami megint nem feltétlenül egyszerű ill. megoldható, hiszen pl. a várakozás (ti. hogy új hívást már nem engedek be a kernel felől, de a függőeket még bevárom) önmagában is deadlockot okozhat, vagy pl. egy vagy több időkorlátos pending WAIT is elég érdekes dilemmát vet fel.

    Szóval egy nem kifejezetten erre tervezett architektúrában nem lehet csak úgy elmenteni a processz teljes user space-ét, anélkül, hogy a kernel space-ben is meg ne történne a társított erőforrások valamilyen parkolópályára helyezése (esetleg átmeneti teljes felszabadítása) - és az eredeti állapot elmentése. Mert hogy amikor hibernálod a processzt, akkor annak le kell iratkoznia az összes olyan kernel módú komponensek (beleértve a kernel mellett a meghajtókat is) felől érkező eseményről, aminek nem szabad az automatikus felébredését okoznia a hibernációból; ha ugyanis ezt nem teszed meg, akkor bármikor bármi újra beránthatja a folyamatod a memóriába, és kvázi a lapozást valósítod meg, csak nem lap- hanem processzgranularitással - aminek viszont semmi értelme nincs.

    A processz a hibernált állapotból történő visszatöltésekor (pl. előtérbe kerülésekor vagy valamilyen ébresztő esemény ill. időzítések esetében a garantált pontossági időintervallum lejárta után) ugyanakkor vissza kell tudni kapcsolódni a kernelbeli eseményekre, callbackekre, stb. amikről a hibernációkor leiratkozott a folyamat. Ehhez pedig a megfelelő kernelbeli adminisztrációs adatok lementése szükséges. Ez persze nem feltétlenül (sőt, egyáltalán nem) a kernel adatrégióinak egyes olyan "buta", lineáris kimentését jelenti, mint ahogy a hibernált user space-t ki tudod írni; de ettől még kell egy köztes réteg (ami akár futhat user módban is, de ami) kvázi "lebontja" a kernel felé a kapcsolatokat, megszünteti a visszahívási végpontokat, stb. arra az időre, amíg az adott program célzottan visszatöltésre nem kerül a hibernációból.

    Az átmeneti leiratkozás biztos megkerülhetetlen, mert a kernel felől érkező hívások nem kerülhetnek sem blokkolásra, sem várakozási sorba. Ezek ugyanis egyrészt blokkolhatnák pl. a hívó processzeket, másrészt, mert a sorbaállítással csak újabb memóriazabálás kezdődne (pont amit el akartunk kerülni a processz teljes hibernálásával). Harmadrészt mert a legtöbb esemény vagy csak az értesítés erejéig érvényes/értelmes, vagy rövid idővel azt követően értelmét veszti. Pl. egy félmásodpercenkénti időzítőhívás vagy akár egy hálózati kapcsolatfelvételei kérelemről szóló értesítés pufferelésének semmi értelme nincs, hiszen értelmüket vesztik ha nem kerülnek azonnal feldolgozásra. Stb.

    Szóval pont ezért nem lehet ezt az egész dolgot egy Win32 API felett transzparens módon megvalósítani, még a kernel teljes átdolgozásával sem, hanem csak egy kifejezetten teljesen aszinkron, és a különböző kernelerőforrások menedzsmentjét is kvázi automatikusan elvégző architektúrában.
    Mutasd a teljes hozzászólást!
  • Meg szerintem ha windowsos programot szeretne a win megszakitani, akkor azt kulturaltan is megteheti két winmain() hívás között.


    Hee? A WinMain() a processz belépési pontja, szóval processzenként pontosan egyszer fog meghívódni (ha csak nem vicces kedvű a processz, és meghívja magától még egyszer).

    Kulturáltan suspendelni egy Win32 processzt csak a saját beleegyezésével tudsz. Megszakítani éppen lehet TerminateProcess-szel, csak az meg nem igazán kulturált
    Mutasd a teljes hozzászólást!
  • Az egész rendszer szoftveres architektúrájának kell olyannak lennie, hogy az egyes programok állapota (beleértve a user space-en kívül a kernel térben tárolt adatokat is) rögzíthető, lemenethető és eltávolítható legyen a memóriából.


    Van erről valami forrásod? Az eredeti blogbejegyzés csak a user memória mentéséről beszél, de attól persze még lehet, hogy a kernel memóriájából is ment.

    Ehhez egy olyan rendkívül magasszintű, úgymond menedzselt kernel handle-ekkel dolgozó és viszonylag szimpla API kell, mint a WinRT, mert csak ebben az esetben kesz képes a rendszer az alkalmazás a magjához történő kapcsolódási pontjainak, referenciáinak felderítésére, elmentésére, majd azok teljesen transzparens visszaállítására a taszk visszatöltése esetén.


    Ha tényleg teljesen kipucol mindent ez a megoldás, beleértve a kapcsolódó kernel adatszerkezeteket is, akkor valóban szükség van erre. A cikk viszont ilyenről nem beszél, sőt még párszáz kilobájt private working set megmarad az úgymond "kipucolt" processzeknél is. Ha a kernel adatszerkezeteket nem kell kitakarítani, akkor ez már pusztán a lapozás speciális esetévé változik.

    Ezen kívül az API-nak teljesen aszinkronnak is kell lennie, mert ha nem az, akkor a rendszer nem lesz képes a deadlock veszélye nélkül még azt se bevárni a taszk hibernálásakor, hogy annak minden hívása visszatérjen kernel módból, és így kipenderíthetővé és konzisztens állapotban lementhetővé váljon akár csak az alkalmazás user-space tere is


    A deadlock veszélye nem a hibernáláskor, hanem még jóval előbb, a suspend-nél jön elő. Technikailag a Win32 processzeket is lehetne suspendelni (SuspendThread() API függvény már régóta van), csak senki nem garantálja, hogy az adott processz nem fog éppen lockot vagy valami hardvererőforrást. Ha jól értem, egy Metro app annyiban különbözik, hogy van biztonságos módja a szálak suspendelésére.

    Szóval teljesen igazad van abban, hogy ehhez új infrastruktúra kell, a meglevő Win32 programokra ez nem működne. Viszont nekem meg szintén igazam volt, amikor azt írtam, hogy amit a blogbejegyzés leír, az csak a meglevő lapozás tweak-elése. Az igazi "csoda" nem itt játszódik le, hanem még a Metro app suspend-elésénél.
    Mutasd a teljes hozzászólást!
  • Az azert gyanús, hogy LC nincs elragadtatva egy rendkívül magas szintű Microsoft dologtól.

    Meg szerintem ha windowsos programot szeretne a win megszakitani, akkor azt kulturaltan is megteheti két winmain() hívás között. A futo program hardveres megallitasa es a regiszterek, egyeb belso allapot elmentese persze jól jöhet azon programok hibernálásához, melyek fejlécében ott virít a [Not responding] jelzô
    Mutasd a teljes hozzászólást!
  • Persze.
    Mutasd a teljes hozzászólást!
  • Megvalósításában nem az, de végeredményét tekintve igen. És már a böngészőknél sem igazán van értelme - a lap amit néztél amikor elmentetted, mire legközelebb nézed már más van rajta - vagy meg sincs. Egy programnál pedig egyáltalán nem biztos, hogy abban az állapotban szeretném viszontlátni ahogy otthagytam. Szóval, ahol van ilyen lehetőség, ott én ki szoktam ezt a dolgot kapcsolni ha lehet. Nem mondom, hogy teljesen értelmetlen - lásd videotömörítés - de annyira nem nagy feature hogy akár egy windows reinstallt megérjen, nem hogy a megvásárlását, pláne éles környezetben a win7 lecserélését a bizonytalanra.
    Mutasd a teljes hozzászólást!
  • Az ARM MMU-k FCSE (Fast Context Switching) mechanizmusának korlátait öltöztették marketing köntösbe. A legprimitívebb mikrokernelek is ezt használják, mert egyszerű és gyors vele a taszk váltások kezelése.

    Ez tök másra való; nem mellesleg ezt a szerkezetet (ti. taszkállapotok automatikus megőrzése, taszkváltások hardveres támogatása) a PC-k már már a 286 óta tudták. Ha olyan egyszerű lenne ill. csak ez lenne a leírt alkalmazáshibernálás kulcsa, akkor nem kellene hozzá WinRT/Metro.

    Valójában persze az FCSE-nek és a hardveres taszktámogatásnak köze nincs az egészhez. Az egész rendszer szoftveres architektúrájának kell olyannak lennie, hogy az egyes programok állapota (beleértve a user space-en kívül a kernel térben tárolt adatokat is) rögzíthető, lemenethető és eltávolítható legyen a memóriából. Ezt pedig gyakorlatilag egyetlen generikus operációs rendszer sem biztosította idáig - és a jelenlegi API-jaik megőrzése mellett nem is fogja soha. Ehhez ugyanis hardveres támogatás gyakorlatilag abszolút nem szükségeltetik - a szoftveres architektúrának viszont erre a célra megfelelőnek kell lennie.

    Ehhez egy olyan rendkívül magasszintű, úgymond menedzselt kernel handle-ekkel dolgozó és viszonylag szimpla API kell, mint a WinRT, mert csak ebben az esetben kesz képes a rendszer az alkalmazás a magjához történő kapcsolódási pontjainak, referenciáinak felderítésére, elmentésére, majd azok teljesen transzparens visszaállítására a taszk visszatöltése esetén. Ezen kívül az API-nak teljesen aszinkronnak is kell lennie, mert ha nem az, akkor a rendszer nem lesz képes a deadlock veszélye nélkül még azt se bevárni a taszk hibernálásakor, hogy annak minden hívása visszatérjen kernel módból, és így kipenderíthetővé és konzisztens állapotban lementhetővé váljon akár csak az alkalmazás user-space tere is (a visszaállítás körüli problémákról nem is beszélve, amit önmagában ez nem old meg - tehát nem elégséges, csak szükséges előfeltétele a sikeres hibernálásnak).

    Szóval nem, ez piszkosul nem az, amit már X éve ismertek (nyilván felületes és rosszul, ha azt gondoljátok hogy az ugyanaz, mint ez), és pláne nem olyan dolog, amit akármelyik rendszer elő tudna húzni a zsebéből, akár az elkövetkező években sem. Legalábbis anélkül biztosan nem, hogy be ne vezetne egy a WinRT-hez hasonló, rendkívül magasszintű, menedzselt, teljesen aszinkron API-t.
    Mutasd a teljes hozzászólást!
  • most nehogy valaki belekössön, hogy ez nem ugyanaz! - egyébként végeredményét tekintve azonos mechanizmusról van szó

    Igen, ilyen alapon minden szoftver is ugyanaz, hiszen mindegyik csak bájtokat olvas meg ír a memóriából/-ba - lényegében tehát azonos mechanizmust valósít meg.
    Mutasd a teljes hozzászólást!
  • Még a Videoton VT20 gépére írtam taszk switchert Z80-ra.

    Nem veszélyes a dolog, a taszt memória területének kimentése/visszatöltése sem. De a problémák ezután kezdődnek.

    Az oprendszer hívások alatt nem lehet hibernálni.
    Sok erőforrás (hw, driver, plugin, kapcsolódó sw) státuszát nem tudod felügyelni, így lementeni sem.

    A win meg igen erősen összedrótozott rendszer (nem monolitikusak a programok, hanem dll-ek kapcsolati szövete).

    Vagyis az egész rendszer egyben hibernálása sem egyszerű dolog (nem is jött hamar, sőt késve jött és még sokáig voltak gondok vele), de a programonkénti valódi és biztonságos hibernálás azért nem triviális (ha már eleve nem olyanra lettek a programok és az oprendszer tervezve, kivitelezve).
    Mutasd a teljes hozzászólást!
  • Nem ritka, hogy sok évtizedes nagygépes rendszerek már tudtak dolgokat.
    VAX-on már akkor láttam olyat (standard működés), hogy az egyik monitoron futott a program, a másikon meg debugoltam azt a programot, amikor PC-n még nem is létezett dupla monitoros gép, PC-n a távolról debugról meg álmodni sem lehetett, pedig a VAX rendszer állítólag tudta (csak a több gép közötti hálózat akkor még mo-on fehér holló volt a nagygépeken is).
    Mutasd a teljes hozzászólást!
  • Az ARM MMU-k FCSE (Fast Context Switching) mechanizmusának korlátait öltöztették marketing köntösbe. A legprimitívebb mikrokernelek is ezt használják, mert egyszerű és gyors vele a taszk váltások kezelése.
    Mutasd a teljes hozzászólást!
  • Ezt a marketinget! Már meg nem mondom, melyik op.rendszerben találkoztam először olyan automatizmussal, hogy memóriahiány esetén diszk image-be került egy processz mindenestül, majd ha szükség volt rá, akkor visszatöltődött a memóriába és futott tovább. Amire biztosan emlékszem, az a VMS 5.5 volt, de nem kizárt, hogy már az OS/360-ban is volt ilyesmi.
    (most nehogy valaki belekössön, hogy ez nem ugyanaz! - egyébként végeredményét tekintve azonos mechanizmusról van szó)
    Mutasd a teljes hozzászólást!
  • Megvalósítható lenne, akár még XP-n is (vagy Win95-ön).
    Más kérdés, hogy akarják e, van e rá igény, esetleg nincs e aki ellenzi a dolgot és akár perelné is a MS-t, ha megcsinálná.

    Az is ötlet lenne, ha bármelyik programot tetszőleges pillanatban meg lehetne állítani, ez alatt a memóriában lenne, használható lenne az ablak meg amit nem a program vezérel, de maga a program nem futna tovább (még üresjárat sem lenne), és akkor folytatná ha tovább indítjuk.

    Ezt a megállított állapotot lehetne menteni (esetleg több különbözőt is egy programból), később bármikor visszatölteni, kész a hibernáció fejlettebb változata.

    Sőt, magáról a memóriáról is készíthető lenne úgy egy hibernált állás, hogy az ne vesszen el, és ha elromlana az oprendszer (esetleg nincs is a winyón), akkor a BIOS ezt a hibernált állást indítani tudná bármikor.
    Mutasd a teljes hozzászólást!
  • Remélem nem csak a metro ficsőrje lesz, mert akkor nem tudom kire is számítanak a Win8 asztali változat vevőjeként.

    Van már új tranzakcionális filerendszer?

    A nagy ipari felhasználóknak azért kell valamit villantani, mert már az XP is stabil volt, a Win7-re már olyan a kényelmi fok és üzembiztonság (pl. mentéshez volume shadow vagy lementett boot állapotok visszatéréshez), hogy az alkalmas üzemi állapot.
    Szóval az alkalmazások szempontjából kezd beérni a win (micsoda förtelem, nem fagy, nincs kékhalál, egyre kevesebb okból lehet a gatest szidni).

    Ez a megoldás nem azonos a böngészők (és pl. jobb szövegszerkesztők vagy fejlesztő eszközök) megoldásával, mert a teljes belső állapotot lementi, vagyis pl. filetöltés vagy mentés közben is leállhat aludni egyet. Meg hát nem a programfejlesztőnek kell megcsinálnia, az oprendszer csak úgy tudja... ja általában ez a dolga.

    Gondolom, ha megvalósítható, akkor pl. a tálcán az ablak bezárás/előtérbe hozás mellé lehet tenni egy menüpontot, hogy alkalmazás hibernálása.

    Mutasd a teljes hozzászólást!
  • Van pár progi aki most is eljátssza ezt, Pl. böngészők, de általában inkább idegesítő ez mint hasznos. Emiatt aligha fog váltani bárki is.
    Mutasd a teljes hozzászólást!
  • Dehát a cucc csak a Metro appokra működik, és nem kézzel hibernálod a programot, hanem az oprendszer csinálja magától, ha úgy érzi, hogy kevés a memória...

    A cikk alapján ez inkább a meglevő mechanizmusok ügyes tweak-elése, nem pedig forradalmi újítás, de azért biztosan hasznos lesz. (A working set ugye eddig is lecsökkent, ha ikonba raktál egy programot, ennek egy variációja lesz, hogy a suspend-elt Metro appnak akár majdnem nullára is csökkenhet a working setje. A másik újítás, amit a cikk ír, hogy az így kilapozásra kerülő memória folytonosan fog tárolódni a lapozófájlban, ami szintén jó ötlet, de magát a lapozás alapelvét nem érinti.)
    Mutasd a teljes hozzászólást!
  • Már megijedtem, hogy a Win8 az asztali felhasználók számára semmilyen extrát nem ad, vagyis semmi értelme nekik váltani.

    Ez azért jól jöhet, ha a levelezőt vagy a böngészőt vagy táblázatkezelőt szünetelteted, mert majd csak holnap kell, majd akkor folytatom a munkát, de nem az alkalmazásra van bízva (ami kockázatosabb - vagy megteszi, vagy nem), hogy mindent állítson vissza és folytassa ott ahol abbahagytuk.

    Esetleg, ha az agyadra megy, hogy éppen videót konvertál a géped és ettől belassulsz, akkor hibernálásba dobod és majd a kávészünetnél elengeded.

    Remélem így gondolják redmondban is
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd