2. Fórumok
  3. Infotech
  4. Gates háttérbe vonul
Keresés

Új hozzászólás Aktív témák

  • #61 P.H. senior tag bambano #60
    Új Válasz #61
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    válasz bambano #60 üzenetére

    Az újrafordításnál nem a HAL-ra, hanem a felhasználói programokra gondoltam.
    Maga a bootolási folyamat nem érint személyesen, ebben a hónapban 3 boot-om volt, ha jól emlékszem. A legutolsó 9 napja :)

    Nem olyan egyértelmű, ki járt volna jobban. Az MS így járt jobban, mert el tudta/tudja adni az OS-eit (az XP-t meg főleg, kiemelt kompatibilitást ígérve). (Mi,) felhasználók is, mivel tudjuk használni a régebbi programjainkat, ami olcsóbb megoldás. (Mi,) fejlesztők is, mert sokkal egyszerűbb a fejlesztés, így is elég nehéz lenyomni a felhasználók torkán az inkompatibilitás miatti módosításokat.
    A végén úgyis az userekkel kell elhitetni, hogy hosszútávon jobban járnak valamivel, csakhogy nekik általában a pénztárca sokkal fontosabb. Nekik nem lehet felhozni ''a de mi lett volna, ha'' dolgokat.

    kisfurko: Valóban, tévedtem. Csak a nem illesztett szegmens betöltése dob hibát 3. szinten. Viszont, honnan tudom, hogy mit is érdemes betölteni? (Azt ne mondd, hogy a LDT/GDT is végigolvasható 3. szinten, megrémülök). Bár, minek is betölteni másik szegmens-t, amikor az teljes adatterület (DS/ES/SS) alapból futtatható módban van. :)

  • #56 P.H. senior tag dabadab #55
    Új Válasz #56
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    válasz dabadab #55 üzenetére

    minden egyes programsorra(ó?)l el lehet mondani
    Azért érdekes, hogy ez mindig csak Windows alatt merül fel.
    DOS alatt adott volt a közvetlen hardware-hozzáférés. Ha egy OUT utasítást megfog a kernel, akkor nem kompaitilis a DOS-sal, ergo nem teljes értékű DOS-emu. Ha nem, azt csinálok, amit akarok (egy DMA-csatornát felprogramozni nem egy utasítás volt) .

    (mod: italic)

    [Szerkesztve]

  • #54 P.H. senior tag dabadab #52
    Új Válasz #54
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    válasz dabadab #52 üzenetére

    És magában hordozza sebezhetőség potenciális lehetőségét.
    Ok, a DOS erős példa volt, de az NT API (~kernel) teli van obsolate-nek minősített Win31-Win9x-kompatibilis kódokkal. Lásd a múltkori WMF-problémát.

  • #51 P.H. senior tag bambano #49
    Új Válasz #51
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    válasz bambano #49 üzenetére

    A szegmensregiszterek oda mutatnak, ahova a Windows szeretné, és átadja process-indításkor, mivel az LDS/LES/LSS/LFS/LGS privilegizált utasítások, 3. (user) szinten soha az életben nem fogod lefuttatni őket.
    Mivel egy helyre mutatnak, ezért minden process-nek 1db virtuálismemória-területe van, amit a Windows bővítget, ha kell. Azon kívülre nemigazán lehet mutatni, a fentiek miatt.

    Linux vajon állt-e szemben olyan problémával, hogy egy biztonsági/kvázi-nagyszámítógépes kerrnelnek (NT) kell kompatibilisnek lennie egy 16-bites home kernellel (DOS-Win31-Win9x)? Ja, vagy újrafordítasz mindent? Ez is egy út lehet. (lásd még x86 vs. RISC).

    Írnak vírusokat. Viszont lehetővé teszi gyorsabb, hatékonyabb kódok készítését. Az MS egyszer már megszívta a biztonság vs. hatékonyság meccset az NT 3.x idejében, nem volt olyan marketinges, aki el tudott volna adni a 90-es évek elején otthoni felhasználásra egy OS-t, ami min. 16 MB memóriát kívánt. Most ugyan nem esett át a ló túloldalára, de csúszkál a nyeregben.

    Az EFI vajon hogyan orvosolja a Windows problémáit? :F

    Eszemben nincs flame-et kelteni, lehet, abba is hagyom, csak róbálom felvillantani, hogy nem minden az egy OS-ben, hogy ''fagy az Windows'', tervezéskor az elsődleges cél, hogy a fejlesztők kegyeiben járjanak. Egy OS alatt »mindent« meg kell tudni csinálni. A fejlesztőknek mindenképpen, őket nem lehet korlátozni. Az usereknek már annál inkább kellene.



  • #48 P.H. senior tag
    Új Válasz #48
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    Ha egy Windows csonttá fagy, alapvető a chkdsk c: /f /v (+ az összes volume-re is) lefuttatása reboot után. Hiába védett és log-olt az NTFS, azért egy fagyás utáni, teljesen felállt Win alatt is talál hibákat. Ez meg ugye további hibák/fagyások forrása is lehet. Emellett egy reg-cleaner heti rendszerességű használata is egyértelmű, főleg hobbiszintú instal/uninstall mellett. Hogy ezek miért nem alapvető részei a Windows-nak, azon lehet elmélkedni.

    Sajnos az MS küzd azzal a sajnálatos ténnyel, hogy a 90-es évek óta van egy termékvonaluk, amit Windows-nak hívnak, és az adott kereteken belül kompatibilisek egymással. Pedig pl. egy hibás kódot teljesen másképp tud lekezelni egy NT 4.0, egy Win98 mondjuk egy XP. Az is előfordul, hogy SDK szerint szabványosan kezeli le a hibát, a valóságban meg nem igazán. (Jó pár éve kizárólagosan assembly-ben fejlesztek, nem azért volt a munkahelyi gépemen Win98 alatt a Delphi az Indítópultban, mert sztahanovista vagyok. XP alatt a legdurvább esetet is el lehet egy jól irányzott Close-zal hárítani.)

    Az meg, hogy mi a stabil hardware, relatíve. Volt olyan az itthoni gépemen, hogy 2 prime nem hibázott, csak 5 óra múlva merevre fagyott a gép. Volt olyan, hogy 27 nap 100% prociterheléses uptime-ot után kékhalállal zártam le. Ezek napi egyszeri bekapcs-8 óra játék-kikapcs alatt vajon mennyire rendszeresen jönnének elő?

    Bambano: akár ezt is meg lehetne csinálni. De a Windows-t láthatóan úgy tervezték, hogy a legnagyobb szabadságot nyújtsa a programozóknak. Csak egy példa: a DS, az ES, és a SS szegmensregiszterek azonos szegmensre mutatnak. Ennek igen nagy előnye, hogy ASM szinten 6 helyett 7 (EBP is) lehet szabadon használni (az EBP alapból a vermet címzi, ami így azonos az adatszegmenssel), hátránya, egyrészt sok rendszertervezőnek a haja égnek állna ettől, másrészt pl. egyáltalán felmerülnek az verem-túlcsordulásos lukak, amiket divat vírusokban kihasználni.
    Na itt legyen okos az ember, hogy mi a jobb.
    Egymás memóriaterületére meg nem írogatunk, Win31 óta. De azon megintcsak lehet elmélkedni, hogy hiába SSE-capable Win98 óta minden Windows, még mindig nem 16-ra igazított a lefoglalt memória, pedig SSE General Protection Fault-ot dob sok esetben ilyenkor. (és vajon miért pont ezt? Hallgatom, Intel úr)

    [Szerkesztve]

Új hozzászólás Aktív témák

Hirdetés