Hali!

{$M Stack size, Heap min, Heap max}

A egavga.bgi betoltesehez hell heap, ezert a heap min nem jo ha 0. Ha heap
max-szal tudod szabalyozni, hogy "mennyi memoria marad" az elinditott
programnak. Ezzel a te programod alatt vagod a fat, mivel csak a max heap-
nyi marad a programodnak. Ezert kell "beloni". Az elinditando programnak
durvan a Teljes szabad mem-(program meret+max heap size) marad. A min heap
csak azt szabalyozza, hogy mennyi az a minimum aminak a programod betoltese
utan szabadon kellene maradni, tehet ha ennyi nincs akkor a "program too big to
 ..."
uzenetet kapod.
Ha az inditando programoknak igy keves lenne a hely, akkor vagy szetszeded a
menu programodat overlay-ekre es megfeleloen kicsire teszed az ovr buffert, vag
y
irsz egy kis (1KB-10KB) exe-t, ami elsonek a menudet inditja, ami befejezodesek
or
"visszaadja" ez elinditando program nevet, amit a kis exe-d fog inditani. Az eg
esz
egy ciklusba, es kesz (ha a menu "ures"-t ad vissza akkor a kis exe is befejezo
dik).
Sok sikert!

Szia, Otto. mailto:

Sziasztok!

Vegre valahara volt egy kis idom gondolkodni :), ezert most 
nehany valasz kovetkezik.
=============
Istvannak (meg mindig) karakterfelismeres ugyben: mire
kigondoltam volna az elkereso algoritmust lelotted a poent,
de sebaj, most atirtam 16 bitesre.
@next:               Indulasnal - dh=0 (az elozo word felso
  mov ah,dh          byteja a shifthez), ESI - a bitmap ele-
  mov dx,bitmap[esi] jere mutat. A konturmap tartalmat meg-
  mov al,dl          forgattam, alap 1-es es 0-val maszkol,
  shr ax,1           -> - 1 utasitas.
  mov ah,dh          Az eredmeny: 2-vel tobb utasitas mint a   rcr
ah,1           tied, de fele annyi ciklus (kozelites),
  xor ax,konturmap[esi]  fele annyi indexelt memoria olvasas,
  and ax,dx          -> gyorsabb.
  jnz @vanatmenet    Kigondoltam 32-bitre is. Me'g gyorsabb,
  add esi,2          persze csak akkor, ha 32 bites kodot
  jmp @next          irunk.
Istvan, tervezel meg folytatast, vagy a tobbi resz mar tul
bonyolult? (esetleg nem akarod lekozolni a teljes recognita
forraskodot? :))
==============
Hidasi Jozsinak a himem.sys nelkuli mem. kezeles ugyeben:
Van ra mod, de ehhez csupasz DOS kell (nincs semmi vedett
uzemmodot hasznalo progi: emm386, winXX, stb...), es 386-tol
folfele proci. A lenyeg: atkapcs vedett modba, DS,ES,stb..
limit 4 Gbyte-ra, visszakapcs. Ezutan egy 32 bites cimzessel
( mov XX,ds:[EXX] ) elerheto a teljes memoria. A himem is
ezt csinalja, aki nem hiszi fejtse vissza. Egyebkent a
himem.sys kodjanak a memoria kezeles csak kisebb reszet teszi
ki, a tobbi az A20 vonal kapcsolgatasa, mert X tipusu gepen
Y fele keppen kell (hajra szabvany!).

Hogy ne csak a levegobe beszeljek legyen pelda is:
;Kell egy GDT 3 descriptorral
gdt db 0,0,0,0,0,0,0,0  ;null descriptor, nem hasznalt
    db 0ffh,0ffh,?,?,?,9fh,0,0 ;A kodhoz.
    db 0ffh,0ffh,0,0,0,93h,0cfh,0 ;Az adathoz. Limit=4G,
                                  ;Base=0.
;Kell egy mutato, ami a GDT-re mutat abs cimmel, az LGDT
;utasitashoz
gdt_point dw 18,?,? ;hossz 18 byte, a cimet majd beallitjuk
start:
;a cimek beallitasa gdt-ben, es a gdt_point-ben
  mov ax,cs | rol ax,4 | mov bl,al | and ax,0fff0h
  and bl,0fh | mov cs:[gdt+0ch],bl | mov cs:[gdt+0ah],ax
  mov cs:[gdt_point+2],ax | mov cs:[gdt_point+4],bl
;atkapcs vedett modba
  mov bx,10h | lgdt gdt_point
  mov eax,cr0 | or al,1 | mov cr0,eax
  db 0eah | dw offset @jmp1, 8 ;(= jmp far @jmp1)
;szegmens hatarok beallitasa
@jmp1: mov es,bx | mov ds,bx ( fs, gs stb...)
;visszakapcsolas
  and  al,0FEh | mov  cr0,eax
  db   0eah | dw offset @jmp2, seg @jmp2 ;(= jmp far @jmp2)
@jmp2:

Bocs ha olvashatatlan lett, de nem akartam kilometer hosszu
levelet. Lehet hogy van benne hiba, nem probaltam ki, de a
lenyeg benne van. Ami kimaradt: A20 vonal engedelyezese,
proci tipus es uzemmod ellenorzes, INT letiltasa.
===================
Gyongyosi Peternek Pascal gond ugyben. Lehet hogy kell a
BGI-nek egy kis heap, ezert ne vedd teljesen 0-ra, hanem kiserletezd ki
mennyi az az ertek aminel meg betolti.
( {$M $4000, X, X} - X-et alitgasd, pl. a BGI meretenek
mondjuk 2-szeresere vagy valami ilyesmi, ha betolti lehet
csokkenteni, ha nem akkor meg novelni).
Persze lehet hogy igy sem lesz szerencsed, es nem fer el
egyszerre a programod, amit futtatni akarsz, meg a BGI is a
mem-ben.
===================
Udv mindenkinek
Emze, Mihaly Zoltan
---
MailTo:

On  5 Mar 98 at 16:16,  > wrote:

> Melyiknek oruljek jobban???

Szerintem annak, amikor a sys+user time kisebb. Ekkor van a proci 
legkevesbe lefoglalva, marad ideje mast csinalni.

Egyebkent nem ertem, nagy pufferes read/write-nal miert megy feljebb
a sys ido? Amikor az adat megerkezesere var, az az ido (jo driver
eseten) nem szamit bele a sys-be, mert tipikusan nem 
busy-waiting-gel varnak a driverek. Nem lehet, hogy csak meresi
pontatlansag?

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Kedves Lista!

Koszonom a sokk valaszt!

Vegul is az derult ki, hogy ha kicsi a lefoglalango buffer, akkor 
mindegy. A heap-ot hasznaltam vegul is, mert rajottem, hogy nem baj az, 
hogy ha parancssorban megadhatom a buffer meretet...

> Felado :  [Hungary]

> > main() {char buffer[0x10000]; ...
[...snittt...]
> Szerintem a heap-et szeresd, a stack-et amugy is sok egyeb minden
> terheli. Apropo! Bizti az, hogy az elso kodreszlet a stack-ben foglal
> neki helyet???

Igen! A main is ugyan olyan fv, mint a tobbi. A C indulaskor elokesziti 
a terepet, push-olja az arg-okat, environ-t majd egy call main()-t 
csinal. A C-ben a fuggveny altal lefoglalt tomb a stack-ra kerul, 
kulonben nem lehetnem rekurzivan meghivni. Marpedig Te barmikor 
kiadhatsz egy main(int, char**, [char **0]) hivast. Ehhez kell nemi 
perverzio, de szabad!

Koszonet && ha'la!

Udv From:, a kikeleti

Fri, 6 Mar 1998 03:04:51 EST  
  "HIX CODER" >  irta :
>
>A stack-en gyorsabb, viszont azt a puffert nem tudod kiadni a rutin
>futasa utan, csak a rutinban, vagy az altala hivottakban
>hasznalhatod.
miert? nincs sp?
push bp
mov bp,sp
mov ax,word ptr [bp+8] mondjuk.

es miert gyorsabb? En regiszterre optimalizalok.


>-------------------------------------------------------<
Kovacs Karoly (   )
>-------------------------------------------------------<

Fri, 6 Mar 1998 03:04:51 EST  
  "HIX CODER" >  irta :
>ha mar nem kell, emellett a stack-en levo valtozoknal konnyebben >elofordulhat
,
>hogy olyan felulirasi hibat kovetsz el, ami eszrevetlen marad, nem jar >
viccelsz? szerinted hogy lehet C-ben a stack-et felulirni?

>memory
>fault-tal. Meg egy hatrany az, hogy a malloc()-kal letrehozott tombot a >letre
ho
>zo
>fuggveny visszaadhatja, lokalis valtozora mutato pointer-t azonban nem, az
>ervenytelen lesz a fuggvenybol torteno kilepes utan. DOS-ban termeszetesen >ne
m
na jo. szertinted egy fuggveny lokalis valtozojanak helyfoglalasa
hogy tortenik? nem a stacken? nehogyma ne tudjam mi az a cim.
miert lenne ervenytelen egy, modjuk 1234:1234 hivatkozas?
esetleg nem az van ott amire szamitasz. :-o

>lehet 64K-nal nagyobb stack szegmenst hasznalni, tehat az elso modszer
>elmeletileg portolhatosagi problemat is jelent.
ezt nem tudtam. hogy lehet?
tudtommel hugeban is 64K a stack.

>-------------------------------------------------------<
Kovacs Karoly (   )
>-------------------------------------------------------<

Sziasztok!

Tulajdonkeppen meg az elozo kerdesemre sem kaptam meg valaszt, de nem
tudtam varni, es az emlitett menuprogramot megirtam karakteresen.
(mellesleg, ez volt a korrekt megoldas, mert csak igy fert be egy emberi
memoria-keretbe ). Ekkor vetodott fol a problema: az az allat Pascal nem
tud batch fajlokat futtatni? Exec-el kifagy legalabbis. Mit tudtok
tanacsolni? Fontos lenne, mert ha ezt a problemat sikerul athidalnom,
akkor lehet, hogy a helyi korhaz majd' osszes munkaallomasan ez fog
futni, annyira jol sikerult. Es az igen nagy dicsoseg lenne, legalabbis
nekem, mert ez lenne az elso *igazan* hasznos programom. Szoval
segitsetek! Elore is kosz,

Gyongyosi Peter