2. Fórumok
  3. Szoftverfejlesztés
  4. Delphi kérdések
  5. (téma lezárva)
Keresés

Aktív témák

  • #62 Auslander tag Alan #60
    #62
    Ö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

    Auslander

    tag

    válasz Alan #60 üzenetére

    <off>
    Amúgy Németországban fejlesztesz, ezért lettél ''külföldi''? Miben dolgozol, meg milyen projekteken (ha itt is érdekes és elmondható)?
    </off>

    OFF
    Igen, Németországban dolgozom. Egy DMS rendszeren dolgozunk, aminek szeptember 30-án volt a Release 1 bejelentése. Szóval nincs még igazán tesztelve:) Ez tulajdonképpen egy már meglévő rendszerünk frissítése. Ugyanis már tizenegynéhány éve a piacon van a régi termék, aminek ugyan kicsit szűkösek a lehetőségei, de ennek ellenére itt németországban piacvezetőnek számít. A lényeg, hogy az adott dokumentumhoz (ami lehet akár fax, e-mail, elektronikus dokumentum, bármi) attribútumokat lehet rendelni arhiváláskor, ami alapján a dokumentum újra elérhető, módosítható, stb... Az attributumok egy adott mask (form) segítségével adhatók meg, mind arhiváláskor, mind kereséskor. Természetesen ezek a form-ok Visual Basic-ben script-elhetők. A tape-library (hardver) szinten a cég terméke :)

    A rendszer teljes egészében C++ -ban íródott, amíg én meg nem érkeztem (2001), és COM alapokra van helyezve. Az adminisztációs/rendszergazda program az én kezem által kelt életre. Segítségével menedzselhetők az arhiváló formok, kereső formok, jogosultságok, csoportok, felhasználók, meg minden. No ez teljes egészében Delphi-ben íródott. Nem kis időbe telt rávenni az okosokat, hogy hadd csináljam ebben. (No persze előtte rengeteg más feladatom volt, ami C++ -ban lett implementálva). Ebben a tool-ban egyébként a kedvencem a form-designer, ami (jobb hijján) a Delphi designerére hasonlít. Rendest Object Inspectorral, meg minden. Jó sokáig szöszmötöltem vele :)

    No röviden ennyi. A Namespace extension is azért kell majd, hogy ne csak célprogrammal lehessen egy adott dokumentumot elérni, hanem direkt pl. a Word-ből is meg lehessen nyitni azokat, vagy az explorerből keresést indítani, vagy sorolhatnám még. Ámbár valószínű erre az idén már nem kerül sor.


    Remélem nem leszek kihajítva a moderátor által.
    ON

    Köszi a linket rögtön megnézem,

    Üdv:
    Ausländer


  • #57 Auslander tag Alan #56
    #57
    Ö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

    Auslander

    tag

    válasz Alan #56 üzenetére

    Szia,

    Izlések és pofonok, szerintem kifejezetten jópofa megoldás, hogy ha kernel vagy, minden folyamat címterében ugyanott találod a cuccaidat
    Ez ugyanúgy fennáll a másik megoldásnál is. No mindegy, túl sok jelentősége nincs.

    Mihez kell neked nem lapozható memória? Drivert írsz? Olyasfélét is kell nem soká. NO azért ezzel kapcsolatban lesz majd kérdésem, ami inkább Windows specifikus, mintsem Delphi, de valószínű nagy érdeklődésre fog számot tatrtani mások részéről is :)

    ...Egyébként mindig kinullázott memóriát kapsz,...
    Igen, most néztem az MSDN-ben, és valóban, a VirtualAlloc kinullázott memóriát ad vissza. Jó ezt tudni.

    ...ha saját magad által korábban használt lapot kapsz vissza, az nem biztos, hogy ki lesz nullázva (de ez nem is biztonsági rés).
    1. Ha én adom vissza, akkor új memória foglalásakor ezt igy érintetlenül nem kaphatom vissza. Ebben az esetben elvár(ha)tom, hogy nullázva legyen. A VirtualAlloc ebből a szempontból rendben is van.
    2. Ha rendszer vette le a working set -emből, és laphiba miatt kapom vissza, akkor viszont nyilván nem lesz kinullázva. Logikus.

    Tíz másodperces néma főhajtás a Motorola 680x0 sorozat emlékére. A legjobb processzorok voltak.
    Csatlakozom, habár én azért hozzávenném a Digital Alpha processzorait is, míg ki nem nyírták őket.

    No akkor most jövök:
    A problema a következő. Adott egy Namespace Extension (NE), ami valahonnan produkálja az infót a shell-nek, ami által pl az explorer meg tudja jelniteni a directory szerkezetét az NE-nek. Nomármost ez ugye csak egy virtuális adatszerkezet, fizikai megjelenése nincs. Viszont azt szeretnem, hogy amikor pl. a felhasználó Word-ből akar megnyitni egy állományt, ami az én NE-ben található, akkor én azt ad-hoc produkálni tudjam neki mondjuk egy adatbázisból, vagy akárhonnan máshonnan. Ezidáig ezt egy Filter Driver-el többé-kevésbé sikeresen implementáltam, de nem vagyok maradéktalanul elégedett vele. Többek közt azért sem, mert egy ügyes programozó simán átnyulhat felette, vagy mittoménmi. De legalább sikerült a Word-nek odaadni azt amit kért. Végül is járható út, de nekem nem szimpatikus, mert nem szeretnék minden Windows verzióra új driver-t írni. Arról nem is beszélve, hogy a NuMega 2.5 DDK is hagy bőven kívánnivalót maga után. Pár hetem elment vele, míg megírtam a hiányzó class-okat, és az sem biztos, hogy mind jó :F

    Kérdés:
    1. Van erre más megoldás a Device Driver írásán kívül?
    2. Ez a 'protokol' kérdés hogyan működik? Szereném az adataimat a következő URL minta alapján definiálni: AUSLANDER://gipsz/jakab/proba.doc
    (Valaki már említette a nevét, de rég volt, és elfelejtettem)
    3. És ha ez működik, akkor ez könnyen beépíthető-e egy NE-be?

    Egyébként a probléma nem teljesen független a Delphi-től, mivel a DeviceDriver kivételével minden Delphiben készült.

    Előre is köszi:
    Ausländer


  • #55 Auslander tag steveetm #54
    #55
    Ö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

    Auslander

    tag

    válasz steveetm #54 üzenetére

    Meggyőztél ;]

  • #53 Auslander tag lao ce #52
    #53
    Ö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

    Auslander

    tag

    válasz lao ce #52 üzenetére

    Szia,

    ...csak az erdekesseg kedveert ossze kellene vetni mas oprendszerek megoldasaval...
    Rendben, igaz én csak egyhez tudom hasonlítani, és ez a VMS/OpenVMS. Mivel a Windows NT fejlesztésében (leginkabb kernel) anno a DEC-től elcsábított/megvett fejlesztőmérnökök igen erős szerepet játszottak, ezért igen nagyfokú hasonlóság fedezhető fel a két rendszer memória/task kezelésében. A terminológia is közel azonos mindkét rendszer esetén. Azonos elvek a working-set-eknél, minkét rendszer pagefile.sys-nek hívja a lapozófájlt; a process által visszajuttatott memória a VMS-ben is először egy listára kerül, amit a processz visszakap, ha kell neki, ha még nem került vissza a rendszer listára, stb. Mindkét oprendszer flat-model-t használ. (Nem vagyok biztos benne, hogy a flat modell előnyösebb lenne a szegmentáltnál. Utóbbinál pl. viszonylag egyszerűen lehetne memóriamegosztást biztosítani két process között. Ez flat modellnél nem egyszerű. (jojo, használhatom a kernel memory space-et, de ez nem szép)). Azt, hogy most a VMS, vagy a Windows verzió a jobb azt nem tudhatom már, mivel a VMS-ről több mindent már nem tudok, mióta a Compaq(bérenc) megvette a Digitált. Brrrrrrrr.

    Alan
    Ha már így összefutottunk...
    Hogy kell Non Pagable memóriát allokálni Windowsban? És lehet-e kérni, hogy ez ki legyen már nullázva? VMS alatt ez működött. Erős a gyanúm, hogy Windows alatt is mennie kell valahogyan. Jó lenne, ha nem nekem kellene ezzel foglalkozni. A rendszernek van elég ideje, hogy nullázgassa a lapokat.

    ...Intel hardver adottságai miatt 4KB-os blokkokban intézi a virtuálismemória-foglalásokat...
    Az Intel adottságai miatt ez lehetne akár 4MB-os page is. No jó, csak a 386-osoktól kezdődően :)

    Egyébként tetszik amit írsz. Tömör, lényegretörő, érthető.
    Ha lenne Windows-al kapcsolatos kérdésem, azt a megadott e-mail címedre küldhetem?

    Üdv:
    Ausländer

Aktív témák

Hirdetés