Hogyan tilt le Windows opr. rendszer egy assembly utasítást?
2002-11-27T13:29:19+01:00
2004-03-09T12:27:43+01:00
2022-07-18T21:16:02+02:00
  • Az Általad vázolt világ szép, és jó, csak nem igazán találkozok vele.

    Fél giga ramom nem nagyon szokott megtelni

    Több éve fejlesztek kereskedelmi forgalomban levő programokat, de még nem találkozam olyan céggel, amelyik egy asztali gépben fél giga RAM-ot tartana. Ha azt javasolnánk nekik, hogy az átlagos 64(!)-128 Mbyte mellé még vegyenek kétszer ennyit, meg a jó öreg 133-as Pentium-ot le le kellene cserélni, hogy valamely programunk megfelelően fusson, az esetek nagy részében ajtót mutatnának nekünk.

    Hogy képzelik ezek a mai fiatalok, hogy nem maguk írják meg a vonalhúzó, a textúrázó, az árnyékoló, a körívrajzoló, ... algoritmust assembliben?

    Egy szempontból: Win95/98 alatt a CreateCompatibleBitmap max. 16 Mbyte méretű bitmap-et tud létrehozni, egy 300 dpi-s 24-bites scannelt A4-es kép 25 Mbyte körül jár. Ennek manipulálásához elfelejthető a Windows összes grafikus algoritmusa, mindent kézzel kell megoldani. A fenti módon lehetne mondani, hogy én csak NT vonal alá fejlesztek, erre a válasz az lenne: miért vegyek másik Windows-t, ha eddig minden jól ment, és meg lehet nézni a Windows-árakat (nem véletlenül tolta ki a Win98 terméktámogatás határidejét a Microsoft).

    Nem mondom, hogy csak az üljön gép előtt, aki perfekt assembly-programozó, de általánosságban elmondható (és elmondott): nagy mennyiségű adat gyors kezelésére assembly ajánlott. A baj csak az, hogy az általában oly módon, olyan körülmények között ismerkedik meg egy programozó az assembly-vel, hogy elhatározza, egy életre elkerüli, nem pedig az jut eszébe, hogy egy erőteljes feljesztőeszköz birtokába juthat.

    PS.: Kissé eltértünk a topic eredeti témájától ezzel a kérdéssel, és sajnos még a kérdésemre sem kaptam választ.
    Mutasd a teljes hozzászólást!
  • Ez nyilván a szakma megcsúfolása.


    Szerintem meg nyílván egyfajta piaci trend eredménye, miszerint a hardver egyre csak fejlődik, de a szoftver meg úgy "fejldődik" (lassúl, nő, ...) hogy egy kicsit a hardver elött legyen, ez további lökést ad a hardvernek, mire mégnagyobb szoftokat lehet kiadni, ... (a vevőt kivéve mindenki jól jár)

    És mivel ez a környezet adott, sokminden nem is zavar már annyira. Fél giga ramom nem nagyon szokott megtelni, pedig néha nagyon nyúzom ám a rendszert (Visual Studio + néhány IE + Opera + Word + Acrobat + ACDS + TV + ...). Úgyhogy az már nem is érdekelne ha egy négyzetet kirajzoló progi 3 mega ramot enne (eszik).
    Általában ha klikkelek valamire, akkor 1-2 másodpercen belül feláll a progi.
    Ami zavar, az viszont egyértelműen nem ennek a trendnek az eredménye, hanem elba***tt program. Pl: Miért tart a legújabb ACDS-nek fél percig, míg először feláll? Miért eszik néha 100% procit a word, mikor csak egyszerűen megnyitottam vele egy doksit? ...

    Nézem itt a prog.hu-n is a topikokat, hát elkeserítő. A "játekfejlesztes" alatt arról beszélnek, hogy milen engine-t hol lehet megvenni..


    Hát ez szörnyű . Hogy képzelik ezek a mai fiatalok, hogy nem maguk írják meg a vonalhúzó, a textúrázó, az árnyékoló, a körívrajzoló, ... algoritmust assembliben?
    Marha egyszerű:
    A jó programozó LUSTA. A szó legnemesibb értelmében. Ha valamit már megírtak egyszer, akkor nem fogom újra megírni (libek, OO fejlesztés, komponens alapú fejlesztés, WebServices, engine-k, ...).
    És nem is nagyon tudna megállni a piacon az az ember, aki maga írja meg a sorosport kezelését, winapiban az ablakok kirakását, a rajzoló rutinjait, ... (de nem is lenne értelme).

    Írtak ezek a gyerekek már önállóan egy amőba programot?

    Na ez viszont már más kérdés!
    Valószínüleg a legtöbben nem, és ami fontosabb: nem is tudnának. De ez független mindattól, amiről eddig írtam.
    Azért eléggé szomorú azt látni, hogy a sok lelkesedés ROSSZ lustasággal párosul, és a "programozó" olyanokat kérdez, hogy pl "Hogyan kell kört rajzolni C++ -ban?". Merthát ő megálmodta, hogy játékot fog írni, de ehhez kb. 1 éves Pascal háttere van, meg egy 10 oldalas C++ gyorstalpaló anyaga.

    Na mind1.
    Mutasd a teljes hozzászólást!
  • "Kivancsisagkeppen visual foxproban "irtam" egy progit:
    a = 1.
    majd csináltam belőle exe-t.
    Az eredmény 1MB, ja és kell neki még kb 1 mega dll hogy fusson is."


    A poén az, hogy egy valamirevaló fordító ezt ki is fogja szedni, hisz nem használod fel utána az értéket :)


    Ps: Azért nem kellene összevetni egy assembly programot egy Windowsos fejlesztőeszköz eredményével... Ez utóbbi ugyanis mást is csinál.
    Mutasd a teljes hozzászólást!
  • Sajnos ahogy a szoftvertermékek tervezési szempontjai között egyre kevésbé szerepel a hatékonyság, úgy szorul ki az assembly a szakmából és az oktatásból is.
    Kivancsisagkeppen visual foxproban "irtam" egy progit:
    a = 1.
    majd csináltam belőle exe-t.
    Az eredmény 1MB, ja és kell neki még kb 1 mega dll hogy fusson is.
    Ez nyilván a szakma megcsúfolása.
    (Ha nem irok 5kB terjelemben egy komplett vindózós asm cuccot akkó visszadaom az öszes papiromat - de az is csak azért 5k mert a PE header 2k)

    De ma ez megy, ezt lehet eladni.
    Nézem itt a prog.hu-n is a topikokat, hát elkeserítő. A "játekfejlesztes" alatt arról beszélnek, hogy milen engine-t hol lehet megvenni..
    Írtak ezek a gyerekek már önállóan egy amőba programot?

    Na mára ennyi, bocs, ha negatív voltam.


    Mutasd a teljes hozzászólást!
  • Elnézést, nem így szántam, hanem konkrétan: ez (a deadlock) speciel szerepel a felsőoktatási tananyagban, DE! Kissé bizarr, hogy 2000-ben az assembly oktatás csak a 8086 utasításkészletre korlátozódik, coprocessor, MMX említés szinten sem kerül elő, inline assembly helyett kizárólag full assembly programokat ismertetnek/kérnek, másrészt mondjuk WinAPI programozás egy(!) féléves spec. koll-ként vehető fel. Viszont legalább 5 tantárgy szól objektum-orientált tevezésről, köztük van olyan, ami kizárólag objektum-orientált ábrák szerkezetével foglalkozik. (a fentiek a szegedi egyetemről szólnak).

    Szerintem az itt hozzászólók nem a felsőoktatási anyag(ok)ról beszélgetnek.

    Elnézést még egyszer!

    PH
    Mutasd a teljes hozzászólást!
  • PH2000! erre a mondatodra, hogy "(Tanenbaum: Operációs rendszerek, Szeged prog.terv.mat III. félév <- felsőoktatás)" vagyis h "kene man tanulni is" csak 1 szoval reagalnek: Koszonom

    Rob
    Mutasd a teljes hozzászólást!
  • köszi, így teljesen érthető
    Mutasd a teljes hozzászólást!
  • ezúttal a témához hozzászólva:

    deadlock (holtpont): "egy processzusokból álló halmaz holtpontban van, ha mindegyik halmazbeli processzus olyan eseményre várakozik, amit csak egy másik, halmazbeli processzus okozhat." (Tanenbaum: Operációs rendszerek, Szeged prog.terv.mat III. félév <- felsőoktatás)
    azaz egymásra várakoznak, nem csinálnak semmit.

    livelock: "A condition that occurs when two or more processes continually change their state in response to changes in the other processes."
    az az eset, amikor 2 vagy több processzus folyamatosan változtatja állapotát válaszul valamely másik processzus állapotváltozására, azaz folyamatosan csinálnak valamit.

    hülye példákkal:
    holtpont az, ha két "fénymásoló program" igényt tart a scanner-re és a nyomtatóra egyszerre, de mindegyiknek csak az egyiket sikerül megszereznie, és várják, hogy a másik felszabaduljon; livelock az, amikor két ember egy ajtóban szembetalálkozik, és mindketten el akarják engedni egymást, majd egyszerre akarnak menni, erre mindketten félreállnak, ...

    A holtpont (deadlock) állapota felderíthető, OS szinten bizonyos esetekben feloldható (ha a várakozás tárgyát az OS kezeli)
    Mutasd a teljes hozzászólást!
  • Mig a deadlock allapotvaltozas nelkuli varas, a livelock allando allapotvaltas melletti korbe szaladas. Mint a kutya szalad a farka utan, de a farka meg minidg elorebb kerul, igy sosem kapja el :)
    Mutasd a teljes hozzászólást!
  • null
    Livelock: A condition that occurs when two or more processes continually change their state in response to changes in the other processes.


    hmm akkor orexem, en erre a deadlock (korbehalas tan magyarul) kifejezest tanultam. Tehat mikor a boltos azert nem tud szalamit adni, mert arra var, hogy a szallito alairja a szallitolevelet, amit azert nem irt ala, mert a meos nem hagyta jova, aki a boltos jovahgyasara var.
    tipikus szervezesi problem
    Mutasd a teljes hozzászólást!
  • Üdv mindenkinek!

    Nem kifejezetten a kialakult vitához akarok hozzászólni, de úgy gondolom, felvetésem kapcsolódhat az alapvető témához. Amennyiben Szerintetek mégnem, vagy tudtok megfelelőbb helyet, szóljatok, már itt sem vagyok.

    Tapasztalataim szerint korai Win95 és Win98 alatt, amikor a window-procedure megkapja a vezérlést egy esemény után, a coprocessor nem üres, újabb Windows verziókon (már a Win95 OSR, és Win98 magyar változatán is) azonban üres. Más szóval, a különböző Windows-változatok nem azonos körülményekkel adják át a vezérlést az alkalmazásnak. Ez azért probléma, mert (és ezért kapcsolom ehhez az előzményhez a hozzászólásomat) ha valaki Windows alá (csak így, egyszerűen) ír programot, és azt mondjuk átviszi a szomszéd gépére - ne adj' isten, kereskedelmi terméknek szánja -, akkor BÁRMELY Windows verzió alatt megfelelően működnie kell a programnak. És bár a Win9x vonalat kritizálja vagy dicsőítse akárki, pl. Magyarországon a Windows-os gépek legalább felén ilyen fut.

    Visszatérve a problémához, sehol nem találtam eddig anyagot a Windows kernel FPU-kezelésére vonatkozóan, bár a fenti (korai) változatok alatt pl. a GlobalAlloc utasítás viszont kiüríti az FPU-registereket. Ha valaki rendelkezik ilyen ismeretekkel, kérem, jelezze. (Van még néhány ilyen változat-specifikus érdekességem/kérdésem.)

    Előre is köszönöm!
    Mutasd a teljes hozzászólást!
  • Az LGDT utasítás csak a CPU belső 48bites GDT regiszterét tölti fel. Ez a regiszter tartalmazza a GDT címét és méretét. Szóval ezzel az utasítással csak regisztrálod a processzornak hogy hol keresse ezt a táblát.
    Amikor a szegmensregiszterbe töltődik egy szelektor akkor a processzor megvizsgálja hogy melyik táblába keresse a leírót, hogy egyáltalán létezik-e a megadott leíró, hogy jogod van-e betölteni, hogy hogyan viszonyul egmáshoz az RPL, CPL és a DPL stb..
    Na szóval az index töltődik be a szegmensregiszterbe vagyis abba bizonyos 16bites részbe, viszont van egy hidden part is amelybe betölti a leíró kezdőcímét, méretét , meg a tulajdonságait. Ezért van az például hogy ha védett mód alatt új GDT-t jelölsz ki az LGDT utasítással akkor még nem történik semmi hanem manuálisan egy MOV utasítással vagy egy TSS váltással újra be kell tölteni a leírókat a szegmensregiszterekbe hogy a rejtett részbe is betötődjenek az új értékek.

    Úgy képzeld el mint a TLB-t ott is amikor új lapot hozol létre akkor a processzornak jelezni kell egy INVLPG utasítással hogy töltse be a page table -ből az új lap leírót. Mert különben a processor azt mondja hogy #PF alias 0x0E!
    Mutasd a teljes hozzászólást!
  • Sőt, mi több:

    Livelock: A condition that occurs when two or more processes continually change their state in response to changes in the other processes. The result is that none of the processes will complete. An analogy is when two people meet in a hallway and each tries to step around the other but they end up swaying from side to side getting in each other's way as they try to get out of the way.


    Ez valóban csak egy része a lehetséges végtelen ciklus típusok halmazának.
    Mutasd a teljes hozzászólást!
  • szomnoru ha ezeket semmilyen targyban nem oktatjak. telleg kezd lecsuszni a felsooktatas


    Ki mondta, hogy engem oktatnak erre vagy valahol tanulok? :) Én arról beszéltem, hogy ezalatt a jónéhány év alatt, amióta elsősorban angol nyelvű szakirodalomból szerzem be az információimat, még nem találkoztam ezzel a kifejezéssel általános környezetben. Helyette a végtelen ciklust az "endless loop" kifejezéssel szokták jelezni. Csak ennyi :)

    Egyébként értékelem a finom beszólást, de azt hiszem, mellément :)

    Péter
    Mutasd a teljes hozzászólást!
  • *livelock: egy sajnalatosan nem determinisztikus befejezesu dolog, fog sincs, mikor lesz vege, pl processzek elbeszelnek egymas mellett, szal a vegtelen ciklus a livelock-nak csak egy formaja
    *deadlock: annal azert bonyolultabb, amit irtal, de lenyegeben vmi olyasmi
    *busy waiting: tevekeny varakozas; mikor egy processz pl addig kuld el egy uzenetet ujra es ujra, mig nyugtat nem kap, h "jovanna, feldolgozva. nolécci"

    szomnoru ha ezeket semmilyen targyban nem oktatjak. telleg kezd lecsuszni a felsooktatas, ech... de majd a BSc, a Bolognai rendszer remelhetoleg kicsit ujra feljebb pofozza a kovetelmenyeket es a hallgatok tudasat is

    kvp:
    a szegmens regiszter erteke nem egy index, amivel kivalasztasz egy deszkriptort a feltoltott DT-bol? akkor minek van LGDT utasitas ha nem tolt fel semmit? sztem aze valami csak feltolt :) legalabbis nalam fel szokott :)

    "windows9x-ben hibas a hw. virtualizalas"
    oylannyira, h nem meltatnam ilyen magasztos jelzovel a win9x-et h "hw virtualizalas" az csak a HAL-nak adatik meg :)
    ezert nem eri meg vedett modrol beszelni win9x alatt, csak NT alatt, v vmi epelmeju OS alatt

    Rob
    Mutasd a teljes hozzászólást!
  • beware: offtopic. pgdn.

    a vegtelen ciklus (vagy ahogy a progmat szakma hivja: "livelock")


    Én asszem sohasem találkoztam ezzel a kifejezéssel a _programozásban_, pedig olvastam angol nyelvű irodalmat tisztességgel. Ott "endless loop" a végtelen ciklus, illetve a deadlockot pedig két egymásra kölcsönösen várakozó folyamat esetén szokták használni.

    Nem kételkedem benne, hogy a valamelyik szakterületen a livelock elterjedt fogalom, de általánosságban, mint "progmat", kétlem, hogy aktívan használják.

    Péter
    Mutasd a teljes hozzászólást!
  • Sting jól beszélt. A processzorban (igen, ott belül) van 6 darab szegmensregiszter. Amit a szakirodalmakban emlegetnek szegmensregiszter néven, az tulajdonképpen ennek csak egy része (16 bitje), amit Te, mint programozó elérsz; ide töltöd be a szelektort. Amikor ennek a 16 bitnek (szelektornak) értéket adsz, akkor a szegmensregiszter többi részébe a processzor felszippantja a memóriából a DT megfelelő bejegyzését.

    Lényeg, hogy a szegmensregiszter kifejezés két dologra használatos. Mást kell érteni alatta, amikor programozol, és mást, amikor a processzor belső működését tanulmányozod.

    Mutasd a teljes hozzászólást!
  • meg a Deszkriptor Tablak is oda vannak FELTOLTVE


    Nincsennek. Minden szegmens regiszterhez tartozik ket 32 bites base/limit rejtett regiszter. (286/386-osokon meg lehetett irni ezeket a load machine state nevu dokumentalatlan utasitassal) A processzor sajnos tenyleg minden szegmensregiszter toltes alkalmaval a memoriabol huzza be az ertekeket.

    s miert is fagyasztja le a vegtelen ciklus a Windows regi, igazabol FLAT es DOS alapu valtozatait? mert esemeny (uzenet) orientaltak es nem preemptivek, vagyis az utemezo nem veszi el a futas jogat pl egy time slice lejartaval, hanem hagyja, hogy a processz vegigmondja mondokajat. NT alatt viszont meghatarozott quantumok uraljak a processzek futasidejet, es igy aztan teljesen kutyat sem erdekli, h valaki livelock-ban van, vagy busy waiting-ben. Emborok, tanuljatok Operncer elmeletet, auztan akkor legalabb nem beszelunk el egymas mellett es fokent nem vitatkozunk marhasagokrol!


    Nos nem egeszen. Egyszeruen arrol van szo, hogy a windows9x-ben hibas a hw. virtualizalas, es reszben kernel jogokkal futnak a dos-os alkalmazasok. Ott is van time quantum, csak sajnos a dos-os alkalmazasok kepesek modositani a valos interrupt flag-et is, pedig az intel kezikonyve szerint a v86 monitornak ezt nem lenne szabad engednie. Szoftveresen kellene emulalnia, minden in/out/int/iret/stc. utasitasra le kellene futnia a teljes monitornak, ahogy ez winnt es os/2 alatt meg is tortenik. Szerencsere az iP6-os magoktol (PII) mar van erre hardware-es tamogatas, de a win9x-ek meg 486-osokon is futnak, tehat ezt nem lehetett hasznalni. Rendes szoftveres v86 tamogatast pedig nem keszitettek a rendszerhez. (mivel akkor annyi regi dos-os jatek menne alatta mint winnt alatt, ami nem tul sok)

    A qnx limitalt v86 monitora pont igy mukodik, tehat a valos modu bios-t kernel jogokkal futtatja. (mivel csak a vesa modok bekapcsolasara hasznaljak, ezert nem is kell tobb)

    Viktor
    Mutasd a teljes hozzászólást!
  • Rejtett rész:
    Valóban létezik ez a bizonyos rejtett rész, másképpen a CPU-nak minden memóriamüveletnél ki kellene olvasnia a leírótáblából a kezdőcímet a limitet és a leíró tulajdonságait!

    Természetesen most Intel platformon vitatkozunk, vagy lemaradtam valamiről?

    Mutasd a teljes hozzászólást!
  • Sting, ezt nem igazan birom megemeszteni: a "processzor automatikusan betölti a szegmens regiszter "rejtett részébe" a szegmens kezdő címét, a szegmens méretét (szegmens határ) és a szegmenshez a hozzáférési jogokat"
    ha jol tudom, mar pedig 1996 ota ASMozok, akkor a szegmens regiszterek 16 bitesek. na most ez cimter (voltakeppen szelektor nevter) szerint jelent 2^16 erteket. Azt tudjuk, hogy miert lehet ebbe a 65536 fele ertekbol csak 8192-t kivalasztani, de hol a francba van a rejtett resze? Egy szegmens regiszterbe. En aki GEPI KODBA nyomulok neha (Vodka helyett), es ott azert elegge latszik "mennyi a hany bit"
    szal sztem az a "betolti a regiszterbe" dolog elegge brutal muvelet lenne : mintha egy DVD-t akarnal betenni egy floppy dirve-ba :) LOL
    nem a deszkriptorra gondoltal regiszter helyett? hm?
    regiszter a processzorban van (telleg csinaltal mar regisztert hardveresen? lasd: BME, v vmi rendes hw mernok szak, ott tanitgatnak regiszter epitgetest, pl 8085-on)
    meg a Deszkriptor Tablak is oda vannak FELTOLTVE szal attol h meg a progiban modosit vki egy tablat (vagyis lokalis helyen) anelkul h feltoltene, az nem jelen tobbet mint egy mezei tomb elem ertek valtoztatast, nem valodi DT valtoztatast.
    Destructor nem is ertem, h keveredtel meg. Az NT vedett modban van, s az meg keves is, van meg egy HAL (Hardware Abstraction Layer), ami egy virtualis HW-t interfeszt nyujt a platform fuggetlensegre, szal igazabol amin most vitatkozunk az csak Intel-en allja meg a helyet. De mindjart minden memoria es regiszter modell maskepp van SPARC (RISC) v Morotola procikon... pedig rajtuk is fut pl a Linux et al.

    kaeru: a vegtelen ciklus (vagy ahogy a progmat szakma hivja: "livelock") felismeres elegge nehezkes feladat, ugyanis nem lehet eldonteni, h valaki 1 masodperc alatt azert ugrik 20 ezerszer ugyanarra a cimre, mert poenkodik, vagy mert komolyan gondolja. en azt utalom legjobban, amikor egy szgep "ki akarja talalni, hogy EN mit akarok". Hat nehogymar egy gep modnja meg, h a sw fejleszto mit akar! a pofatlasagnak is van hatara

    s miert is fagyasztja le a vegtelen ciklus a Windows regi, igazabol FLAT es DOS alapu valtozatait? mert esemeny (uzenet) orientaltak es nem preemptivek, vagyis az utemezo nem veszi el a futas jogat pl egy time slice lejartaval, hanem hagyja, hogy a processz vegigmondja mondokajat. NT alatt viszont meghatarozott quantumok uraljak a processzek futasidejet, es igy aztan teljesen kutyat sem erdekli, h valaki livelock-ban van, vagy busy waiting-ben.
    Emborok, tanuljatok Operncer elmeletet, auztan akkor legalabb nem beszelunk el egymas mellett es fokent nem vitatkozunk marhasagokrol!

    de most telleg

    udv
    Rob

    Mutasd a teljes hozzászólást!
  • Az egész vita nem is azon volt hogy mi a különbség a win9x és NT alapú rendszerek között, hanem hogy win98 alatt símán írhatod a GDT-t míg win NT alatt ez már közelsem ilyen egyszerű feladat.
    Mutasd a teljes hozzászólást!
  • Én csak azt akartam megmutatni, miért nem mindegy, hogy Win 9x/Me vagy Win Nt/2000/XP. Ha ezt a kis programocskát lefuttatod Win 9x/Me alatt, lefagy a számítógép, miközben NT alapú rendszer alatt semmit sem csinál.
    Mutasd a teljes hozzászólást!
  • Tudod mi az az IOPL? Ebben az esetben csak az IOPL értékétől függ hogy a CLI mit is fog csinálni:

    1. IF = 0
    2. VIF = 0
    3. #GP

    A végtelen ciklus meg nem tudom hogy jön ide!
    Mutasd a teljes hozzászólást!
  • Próbáld ki a következő programocskát Win 9x/Me, valamint Win NT/2000/Xp alatt, és rájössz, mi a különbség:

    cli
    ide: jmp ide

    Win 9x/Me alatt semmilyen felelősséget nem vállalok!!!
    Mutasd a teljes hozzászólást!
  • 1. Mivel a Windowsba a Windows NT is beletartozik, ezért nem mondhatjuk általánosan, hogy Windows alatt a GDT szabadon átírható
    2. Mivel a Microsoft a Win9x vonalat hivatalosan is befejezte, ezért szerintem a jövőben a Windows szó alatt főként (illetve mindig) az NT vonalat értjük. Bár ezen még lehet vitatkozni, de akkor érvénybe lép az első pont.
    Mutasd a teljes hozzászólást!
  • OK, de tudtommal nem azon vitatkoztunk össze hogy WinNT vagy Win9x alatt lehet-e írni, hanem azon hogy egyáltalán windóz alatt.
    Mutasd a teljes hozzászólást!
  • Nem megírtam, hogy nem megy ?!

    Olyan hátast dobot W2K alatt az első utasításon ami írni próbált volna a GDT-be, hogy öröm volt nézni. De mellesleg Predator is megírta már ide, hogy NT alatt kellene megnéznéd, és mindjárt rájönnél mi a csízió...
    Mutasd a teljes hozzászólást!
  • Miért is?

    Ezt meg hogy érted? Látod hogy a GDT kapásból írható, vagy azt ne mondd hogy neked nem megy a prg amit küldtem?
    Mutasd a teljes hozzászólást!
  • Ja én azt hittem hogy Win9X alatt beszélünk, NT alatt nem tudtam kipróbálni.

    Mindenki Windowsról beszélt, általánosságban. Te is. A W9X-et mérvadónak tekinteni biztonság szempontjából egyébként szerintem önmagáért beszél.

    kijelentés nem minden esetben állja meg a helyét

    Miért is?
    Mutasd a teljes hozzászólást!
  • Ja én azt hittem hogy Win9X alatt beszélünk, NT alatt nem tudtam kipróbálni. Egyébként Sting elolvastam a cikket amit ajánlottál nem sok újat tanultam belőle, viszont felhívnám a figyelmedet a cikk végén a szegmens regiszter módosító utasításoknál LFS utasítás helyett LFG van. Nomeg gondolom mondanom sem kell hogy a cikkben a
    A szegmens kiválasztók elérhetőek a felhasználói programok számára úgy, mint egy pointer része, de értéküket reprezentáló leíróikat csak a link editorok vagy link betöltök - a kernel része - módosíthatják. (A felhasználói szintű programok nem.)

    kijelentés nem minden esetben állja meg a helyét.
    Mutasd a teljes hozzászólást!
abcd