Index
> DOS > the difference between exe and com |
| Author |
|
|
nvictor 18 Feb 2007, 14:29
[updated]
Final code ... Code: format MZ
push cs
pop ds
mov ah,9
mov dx,message
int 21h
mov ax,4c00h
int 21h
message db 'Hello World!',24h push cs : store cs address on stack pop ds : store cs address in ds It's like cs = ds But I don't know why we must do that! |
|||
18 Feb 2007, 14:29 |
|
|
MCD 18 Feb 2007, 17:56
nvictor wrote:
Intel is responsible for that, it's because of the x86 instruction arcitecture. In short, there is no machine code for "mov cs,ds" |
|||
|
18 Feb 2007, 17:56 |
|
|
nvictor 18 Feb 2007, 18:01
[update]
nevermind. int 21h need ds:dx to store value of our string. [old] MCD, yes; but why do we do that? why not leave cs and ds like they were? I tried and there was garbage before the actual "hello World!" That's what I don't undertand. |
|||
|
18 Feb 2007, 18:01 |
|
|
rugxulo 18 Feb 2007, 20:35
A segment is 64k big, and hence a .COM file itself can be no bigger (actually, about 65100 bytes or so). To get around this segmentation limit, you use more than one segment. .EXEs can be a lot bigger than 64k (e.g. DJGPP, 32-bit pmode, has some that are > 1 MB), and as such you must tell it explicitly what to do. It's all a relic of old (usually pre-386) memory management. (Someone please explain this better than me if I described it incorrectly.)
|
|||
|
18 Feb 2007, 20:35 |
|
|
DOS386 19 Feb 2007, 12:54
Quote: binary file format is composed of four parts : a file header, a number of sections, a relocation table and a symbol table. Very limited usability of this info for DOS 
Quote: DOS EXE is a BFF holding the signature MZ in his file header, a number of sections and a relocation table There are no sections in DOS MZ-EXE. It was probably a Win32-PE EXE. Quote: Well I don't know much about sections, tables and symbol Forget about them for DOS development with FASM 
Quote: I've read in FASM programmer reference is the format MZ directive that ouputs MZ binary files. YES. Important 
Quote: Interesting, that's the way of writing exe files... Not only: http://board.flatassembler.net/topic.php?t=6735 Quote: get around this segmentation limit, you use more than one segment. .EXEs can be a lot bigger than 64k (e.g. DJGPP, 32-bit pmode, has some that are > 1 MB) <64 KB: One segment EXE or COM (multiseg possible but not useful) 64 KB ... cca 400 KB: MZ-EXE, multiseg, with relocs or other workaround cca 400 KB ... cca 1 MB: MZ-EXE with MZ overlay (obsolete, very bad) Huge: 32-bit DOS, use DPMI / DOS extender, many MB possible _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug Last edited by DOS386 on 22 Feb 2007, 05:06; edited 1 time in total |
|||
|
19 Feb 2007, 12:54 |
|
|
yumka 19 Feb 2007, 19:24
Look at MAME DOS for an example of huge DOS executable.
The last time i saw it was arround 10 MB. Crazy, crazy, crazy! It should be optimised with fasm.  |
|||
|
19 Feb 2007, 19:24 |
|
|
zir_blazer 19 Feb 2007, 21:44
yumka wrote: Look at MAME DOS for an example of huge DOS executable. If it was in FASM, not only it would be smaller, but it would be FASTER. There are a whole bunch of games that requieres everything that you can get, an example is the ancient but still ass kicking Gauntler Legends. Good examples of Console Emulators in x86 Assembler includes ZSNES for SNES and NeoRageX for NeoGeo, those both were capable of emulating games in real time that with other emulators done in high level languages you usually requiere TWICE the machine for archieving the same results. DOSBox in FASM would also be ass kicking. |
|||
|
19 Feb 2007, 21:44 |
|
|
rugxulo 20 Feb 2007, 05:14
NO$GMB (not written by me) was written in assembly, that's why it ran full-speed even on my old 486.
BTW, I think MAME.EXE is 36 MB (or so) but compressed to 8 MB w/ UPX. |
|||
|
20 Feb 2007, 05:14 |
|
|
yumka 20 Feb 2007, 20:53
Some MAME CPU's core are written in assembler, but in my opínion they are lost. An All-Arcade (games) simulator is a insane way to go.
You need to read all MB of exe to load a driver for CPU, sound, video and game specific. I mean read 35 Mb to use maybe 2 mb is not a effient solution. They should split it in many DLL, so you load 1 dll for CPU, 1 for sound, 1 for Video, 1 for MAME Core, and the specific game driver. |
|||
|
20 Feb 2007, 20:53 |
|
|
vid 20 Feb 2007, 21:28
yumka: I think DLL files have quite a lot overhead and are not portable.
when deciding between C and ASM, you decide between portability and performace... It's sad decision one way or another... |
|||
|
20 Feb 2007, 21:28 |
|
|
yumka 20 Feb 2007, 22:16
Yea you are right.
ld could make shared libraries for unix (.so) and for windows (.dll) But i don't know if that breaks compatibity with other MAME ports. At least with DOS they are not feasible. I suppose there must be a reason why all those programmers haven't adopted another model. |
|||
|
20 Feb 2007, 22:16 |
|
|
rugxulo 20 Feb 2007, 22:29
yumka wrote: Yea you are right. There are several ways to (supposedly) make .DLLs (or something very close in functionality) in DOS, but I've never tried 'em. Someone ask Japheth for his opinion! *buzz* |
|||
|
20 Feb 2007, 22:29 |
|
|
vid 20 Feb 2007, 23:15
rugxulo: actually, there were DLLs in DOS. Some borland stuff
|
|||
|
20 Feb 2007, 23:15 |
|
|
rugxulo 20 Feb 2007, 23:32
I meant that they aren't easily coded or used much (besides WDOS/X or DJGPP's EMU387.DXE).
|
|||
|
20 Feb 2007, 23:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|