>Szita Gabor keres aksit a gepebe. Rossz hirem van: ket (!) evvel

Mi???? En ugyan semmifele aksit nem kerestem.

Szita Gabor, Chicago

En ugy tudom (legalabbis a Petho fele konyv ezt mondja), hogy az EXE
file-okat a DOS onnan ismeri fel, hogy az elso ket byte
 4D 5A

 Az altalad kozolt assembly programmal sikeresen atcseszted szegeny DOS
agyat, es azt hitte, hogy EXE-t futtat. Innentol a szerencsetlen elkezdene
relokalni, az eredmeny kiszmithatatlan. Ha valakinek pont ezzel a ket
obszcen utasitassal kell a programot kezdenie, akkor megerdemli. 
 Szerintem te csak a GURU-k szaktudasat tesztelgeted, mert ki van zarva,
hogy csak ugy veletlenul talaltad volna ki azt a programot. Vagy kivancsi
vagy milyen vad valaszok erkeznek majd a temaban? :-)

Szita Gabor, Chicago

>>struct malac { char coca[ 100 ]; };
>>malac huge rofi[ 1000 ]; // remelem, jo helyre raktam a huge-t!
>>malac huge *ui;
>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>
>>Ez nekem nem tetszett. A forditonak sem..
>>Megprobaltam typedef-fel buveszkedni, de nem sikerult sehogy sem
>>eletet lehelni bele...

Kedves L... azaz Tamas!! :-)

Le lehet forditani (en megtettem). Mi lehet a baj?
Talan az, hogy nem C++ -nak forditod? Mert ha nem, hanem
labbalhajtos C--, akkor bizony ki kell irni azt hogy 'struct'.
Typedef itt nem kell.

Sajnalom, hogy neked sem tetszett, a forditot meg csak megertem.

Udv,

Imre

Kanyo Miklos irja:

>>1/ a "malac huge rofi[ 1000 ];" tipusu statikus allokaciot minden
>>tisztesseges compiler megugat (BC++). Ha nem, akkor legkesobb
>>a linker: 'Object exceedes 64k'. Igaza van, mar amennyiben
>>normalisnak lehet tartani az egesz segmens:offset modellt!

Kedves Miklos, ezzel nem tudok vitaba szallni, de azt javaslom, hogy 
probald ki. Ez a programresz ugyanis TC2.0, TCPP, BC2.0 ec BC3.1-en
is lefordul:

struct malac { char coca[ 100 ]; };
malac huge rofi[ 1000 ]; // remelem, jo helyre raktam a huge-t!
malac huge *ui;

>>akkor utana mar nem kell Imre 'borzalmas' pointereit alkalmazni, a

Talan valogasd meg a szavaidat, legyszives.

>>2/ Ha mar egyszer sikeresen 'huge'-nak deklaraltal egy pointert, ...
>>a compiler megteszi azt:

Ez igy van, illetve ha a Fast Huge Pointers be van kapcsolva, akkor nem.
Emiatt kevertem ossze en is (bocs), mert eppen be volt kapcsolva, amikor
megneztem a TD-ben. Valojaban a compiler mindket esetben jol kezeli
a kifejezest (tehat 2 hatvany tovabbra sem kell).

>>Ha 'huge' modellt hasznalsz, akkor a problemak zome automatikusan
>>megoldodik.

Nem igy van, a huge modellnek a valo eletben semmi koze sincs a huge 
pointerekhez!! Huge modellben far pointereket hasznal a fordito. Ami mas,
az az, hogy a statikus adatok 64K< helyett is elfoglalhatnak.

>>A '2 hatvanya'-bol persze van ami igaz: a 2! A memmanager valoban 
>>word-re teszi (align-olja[sic!]) a 'huge' objektumokat, de ez maganugy!

Az viszont nem maganugy, hogy ez megintcsak nem igaz. Probald ki,
ha nem hiszed:

char huge miki, huge imi;

Nezd meg a cimeket a TD-ben, meglatod, hogy imi paratlan!!! :-)

Az alignrol egy erdekesseg: korai borland forditok, mint pl. a TC20 es
talan a TCPP10 is maximum 128K-s huge tombot engedtek meg. Az 
elemek merete nem volt megkotve, de a fordito mindig olyan cimen
kezdte a tombot, hogy szegmenshatarra essen az elemhatar!! Tehat
pl. a fenti rofi tombot 36-os offsett-tel kezdi! Termeszetesen ezt 
a modszert egy hatarra el lehet jatszani, kettore mar nem lehet
igazitani, innen a 128K hatar.

Udv,

Imre

A program ami a PC CPU gyari szamat kiirja:
szerintem humbug. Gondoljatok vegig, hogy az eljaras logikaja serul-e,
ha a program egyszeruen kiir egy veletlen szamot, es utana (mondjuk) egy
rejtett file-ba, vagy a CMOS RAM-ba leteszi (utobbi nem is rossz otlet...)

DOS atir.
Ha a meresiadatgyujto program valoban DOS hivasokkal ir a kepernyore,
akkor egyszeruen a PROGRAM > FILE stilusu redirection megoldja a problemat.

Escom akku:
elnezest, elfelejtettem, hogy gyartanak gyarilag forrfullel ellatott aksikat
is, ahol a ponthegesztes mar el van vegezve, es hoszigetelessel mar ezeket
lehet forrasztani. Tehat ez volna a megoldas. Utana fogok nezni, mivel kompa-
tibilis a szoban forgo aksi. Meg egy megjegyzes: tapasztalatom az, hogy a
NiCd aksik uo. meretben 2 klf. kapacitasban leteznek. Termeszetesen (?) a
notebook-okban a nagyobb kapacitasu van (dragabb, meg szerintem ezek agyon
is vannak hajtva). Meg kellene esetleg probalni a kisebb teljesitmenyut,
na persze, ha nem a halozatfuggetlen uzemeltetesi ido a celfv.

.COM vs. .EXE:
A DOS e ket file-t az elso ket byte-on talalhato MZ signatura alapjan
kuloniti el (Marek Zybowsky allitolag). Ezek utan edesmindegy, mi a file
kiterjesztese (ha .COM ill. .EXE, ezek ui. be vannak drotozva a COMMAND.COM-ba)
.
A DOS 4b00h service tenyleg nem nezi, mi a kiterjesztes.
A fentire jo pelda a 4DOS.COM, ami > 64k, tehat nem is lehetne .COM file,
es belul .EXE.

Ellenpelda: a DOS DEBUG viszont igenis a kiterjesztest nezi. A file elejet
ui. akkor es csak akkor interpretalja relokacios tablanak, ha .EXE. Ezert
.EXE file-t DEBUG-gal ugy lehet patchelni, ha az ember elotte atnevezi (pl. 
anyfile.BIN-nek).

Udv mindenkinek:
Prof

Mivel tobben kertek, (es a hetvegi GURU-k altalaban rovidebbek) 
elkuldom az e.com editort amit par szammal elobb emlitettem. 

section 1 of uuencode 4.02 of file e.arj    by R.E.M.


sum -r/size 26173/6248 section (from "begin" to "end")
sum -r/size 31199/4446 entire input file

Marosi Gyula hetvegi feladvanyara a valaszom --

Egy bizonyos DOS verzioig a prgmok ceb-sorrendben indultak el, azaz
ha beirtal egy command-ot, akkor azonos filename eseten a com indult,
majd exe, majd bat (nem egymas utan :-) ). Van olyan virus is, aki
ezt kihasznalja: nem az exe filehoz fuzi hozza magat, hanem uaz.com
neven olyan kodot hoz letre, ami eloszor elvegzi aldasait, majd execeli
az exet... En is irtam egyszer Novell Netware-hez egy login.com-ot,
talaljatok ki, mit csinalt...

Com elott indul: prgmozo kivalo kollegam irt egy CD-nyilvantarto prgmot,
(CD.EXE) Clipper-ben. Leforditotta, Norton Commander alatt inditotta, es
lass csodat, az semmit nem csinalt! Ha mi nem szolunk neki,
akkor ma is inditgatja lila szinu fejjel. Ugyanis a CD az egy belso
parancs :-O, az meg a com-nal is elobbrevalo. Hogy a Norton miert
nem kozvetlenul exec-elte meg a cd.exe-t, mikor siman entert nyomtak
rajta... valoszinuleg command.com /c -vel futtat?

Szoval a bizonyos verzioig (5.x-re tippelek) a parancssorba beirt extension
ignoralodott! Olyannyira, hogyha ugy inditottal prgmot, hogy "tonic.exe",
akkor legyen a TONIC exe vagy com, a PSP-ben $80 -tol kezdve (80H-tol, aki
a Motorola-szintaxist nem erti ;-) ) a parameterek ".exe" formaban
szerepeltek. Na, ez azert erdekes, mert egyebkent a parameterek elott
szerepel az a space, ami a command-ot es az arg-ot valasztja el, monjuk:
"tonic B:" eseten $81-tol: " B:<CR>", hat nem fantasztikus?
Manapsag azonban, ha extensiont is irunk a filename moge, akkor az indul.
Na, ebben nem vagyok 100% biztos.

Nos, hogyha mar megvan, melyik extension-u filet kell inditani, 
akkor a DOS a koetkezok alapjan donti el, hogy mit kell tennie:
- Ha a kiterjesztes .BAT, akkor becscs.
- Ha az elso ket karaktere a file-nak "MZ" (egyes forrasok szerint
  jelentese: Mark Zbikowsky), akkor EXE, relokalas, stb...
- Egyebkent $100-tol COM.

Fogd a kedvenc szovegszerkesztodet, irj egy com/exe kiterjesztesu
szoveget, aminek az elso ket betuje (uppercase) "MZ", maris kesz a
futtathato exe-file, nem kell az assemblerrel/debuggal vacakolni!

Mivel az exe headerben van checksum meg hossz, amibol ki lehet deriteni,
hogy tenyleges exe-filerol van szo, vagy csak az MZ-motorgyar eves 
jelenteserol, egy ilyen al-exe nem okozhat gondot. Csak a DOS-nak, aki
minden tovabbi nelkul raindit!

Gyulanak uzenem meg: ritkan szoktam com programjaim startupjakent a
dec bp / pop dx parost alkalmazni...

ERN0