why com files are so small in size yet they give the same result as that of exe file. what amendments should we do to convert asm source code to covert in com file after assembling.
: why com files are so small in size yet they give the same result as that of exe file. what amendments should we do to convert asm source code to covert in com file after assembling.
.com files are raw binary executables. If you make a file filled with nops (0x90), and rename it to .com, it will get executed without any problem. .coms are normally smaller than the size of one segment (64K). So, converting might be difficult.
[b][red]This message was edited by Darius at 2002-7-31 11:55:43[/red][/b][hr]
: : why com files are so small in size yet they give the same result as that of exe file. what amendments should we do to convert asm source code to covert in com file after assembling.
: .com files are raw binary executables. If you make a file filled with nops (0x90), and rename it to .com, it will get executed without any problem. .coms are normally smaller than the size of one segment (64K). So, converting might be difficult.
: Take care,
Uh, it will execute without any problem... until it runs out of nops and starts executing just whatever happens to be in memory after the program.
How 'bout put 0xB8 0x00 0x4C 0xCD 0x21 at the end. (0xCD 0x20 would probably be fine, but I prefer to use the proper method of exiting a DOS program).
If it is possible to change a some .exe into a .com file (it's not always possible, in fact, I'd say typically it's not possible), then the savings in space wouldn't be that great. The EXE header doesn't take much space except for potentially the fixup table. If the fixup table is huge, I'm betting you won't be able to convert it anyways.
The fixup table is for code such as the following...
mov ds, ax
This would load the .data segment (if you are using TASM) into DS. It's common code for the beginning of an EXE. Now looking into how a linker and assembler work, we see what happens and why a fixup table is needed. Let's say your total code takes up 0x500 bytes. The assembler/linker is probably going to stick the data segment immediately after it. However you want to refer to data in the data segment from offset 0 not offset 0x500. So, the segment register needs to be loaded with a value that will start right after the code. Well, that's easy it's CS+0x50... um... but what is CS? The assembler/linker don't know. In fact, no one knows until the file is loaded by DOS at which point it picks a CS to load the exe. That's when the fixup table comes in. The fixup table is simply a list of segment:offset pairs that point into the memory of the program. Of course, once again we have the problem of not knowing the segment. So, the fixup table works like the very addresses it's fixing. Basically, DOS loads adds CS to the segment and then it adds CS to the value located at segment+CS:offset. So in the example above, 0x50 would be stored as the operand to mov ax,
and a fixup entry would be added that pointed to the operand of that opcode. This is necessary for ALL references to segments. Therefore, mov ax,
or anything like it can't be used in a .com file. Of course, mov ax, ds is perfectly fine since it requires no knowledge to generate the proper code.
In this example you could get rid of that dependency by replacing mov ax,
with mov ax, cs ; add ax, 0x50 ; mov ds, ax. Of course that would require you to know that you needed 0x500h bytes.
The exe header also has some other things. A .com file is always loaded at offset 0x100 and always starts with CS=DS=SS. An exe file can specify what address to start at and can change SS and DS always points at the PSP on loading (this is true for both .com files and .exe files and this explains the offset 0x100 for .com files, the first 0x100 bytes hold the PSP).
Finally, all this applies to DOS exe's. Windows exe use the PE file format (well Win16 uses NE, but who uses Win3.1?) which is totally different (though they do start with the old DOS exe header for backwards compatibility, basically it loads a little stub program that says "This program can only be run in MS-Windows" or whatever).
If you are making DOS exe's chances are the overhead of the exe header is not too significant for complicated programs. If you are aiming for tiny tiny program sizes then you should be targetting a .com file in the first place. If you are making Windows exe's then check out win32asm.cjb.net. There are tools there that will compress the PE header and can (possibly significantly) reduce the size of the executable and there is NeoLite which is a program that compresses your code,then adds a stub program to the compressed code that decompresses your code when it's run. This is totally different from the PE header compression I was talking about earlier, that just manipulates the PE header and does NOT use a compression algorithm. A side benefit of using NeoLite is that your code becomes a little more difficult to disassemble and reverse engineer. However, most likely it won't even slow down someone who knows what they are doing.
A parting gift:
Smallest functioning executable file under DOS/Windows that's made up of nothing but printable ASCII characters. It's 8 bytes. Requires a Pentium. It doesn't do anything really, but it doesn't crash either. Just put it into a .com file with notepad or something and execute it. Step through it with a debugger to see how it works if you curious.
Search for assembly gems to find more programs like that one, though others usually do something.
"We can't do nothing and think someone else will make it right."
-Kyoto Now, Bad Religion
It looks like you're new here. If you want to get involved, click one of these buttons!
Assembly Code Share
Getting started in assembly
C and C++
C/C++ on Linux/Unix
C/C++ Windows API
C++ Game Development
Delphi and Kylix
Java Server Pages
Access databases and VB
Advance Visual Basic
DirectX Game dev
Newbie Game Programmers
Cooling & Overclocking
Database & SQL
Sound & Music
FreeLance Software City
C# & VB.NET School Support
Join the Team
Comments on this site
New programming languages
Off topic board
Mobile & Wireless
Operating Systems & Platforms
Witsbits Go Cloud
Embedded / RTOS
Windows CE & Pocket PC
Networking And Security
Windows 2003 Server
RUP & UML
Quality & Testing
Active Server Pages
HTML & WEB-Design
Mobile Internet & Messaging
WEB-Services / SOAP
In this Discussion