1. |
Mi??? (mind) |
5 sor |
(cikkei) |
2. |
COM vagy EXE? (mind) |
13 sor |
(cikkei) |
3. |
Valogatos C fordito (mind) |
21 sor |
(cikkei) |
4. |
2 hatvany (mind) |
55 sor |
(cikkei) |
5. |
CPU gysz; DOS atir.; Escom; .COM vs. .EXE (mind) |
35 sor |
(cikkei) |
6. |
Mini editor (mind) |
109 sor |
(cikkei) |
7. |
Re: ceb feladvany hetvegere (mind) |
48 sor |
(cikkei) |
|
+ - | Mi??? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>Szita Gabor keres aksit a gepebe. Rossz hirem van: ket (!) evvel
Mi???? En ugyan semmifele aksit nem kerestem.
Szita Gabor, Chicago
|
+ - | COM vagy EXE? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Valogatos C fordito (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>>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
|
+ - | 2 hatvany (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | CPU gysz; DOS atir.; Escom; .COM vs. .EXE (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Mini editor (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
+ - | Re: ceb feladvany hetvegere (mind) |
VÁLASZ |
Feladó: (cikkei)
|
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
|
|