How do u write *.COM files. are they like batch files, or are they compiled? ive tried searching google but couldn't find anything. sorry to bug u.
Printable View
How do u write *.COM files. are they like batch files, or are they compiled? ive tried searching google but couldn't find anything. sorry to bug u.
com files and exe files are the same I guess... (?)
i really doubt it, one system's command file won't run in another system..that's the not the same with exes
.com files are different than .exe files. Checkout www.wotsit.org
.com files and .exe files are different.
there are several ways to compile to a .com rather than a .exe.
The first way I ever compiled to a .com was using the DOS debug utility. I would write programs in assembly and it would allow you to save them as .com files.
You can also make .com files using a linker. At least I think that is what it is called....correct me if I am wrong. When you first compile a program it makes an object file, from there it can make either a .com or a .exe file using the linker. I have not tried this with C++ programs, but I have tried it with my Assembly programs and it works. I havent tried it for C++ because generally I just use .exe's for my C++ programs.
com files must be kept extremely small (by today's standards). that's why they were abandoned for exe files. com files are in essence flat binaries.
you can assemble com files using dos's debug program. you can also assemble com files through nasm. all com files also start at 100h.
> ive tried searching google but couldn't find anything
When I looked into COM (I bought several books), I also had problems in understanding it due to the junk marketing lingo put about by Microsoft.
While I don't use COM myself, here's what I now understand.
1. COM is a binary object packaging technology. I.e. you can distribute your compiled object tools, but keep your source code to yourself.
2. COM files are essentially DLLs. Instead of exporting flat function calls, you export objects (or to be precise pointers to objects)
3. There are serious compatibility issues in sharing compiled object orientated resources between different compilers in Windows because compilers rarely agree on the binary format of objects.
4. To overcome this, COM relies on pointers to pure virtual base classes. This is a standard technique, and is not unique to COM. However, because MS want you to believe that it is their technology, they never explain this. However, for this to work, different compilers must agree on the same v-table format of objects. This is generally the case.
5. Significantly, COM adopts an approach in which a COM DLL contains only one COM class. Therefore, any program built around COM will typically use a large number of COM binary files. The linkage between COM objects and the corresponding binary files is done through the windows registry. In other words, the code in your program is dependent upon the registry at very deep level. I.e. your program says I want a new instance of this object, and the registry defines which binary file to load. This is all done behind the scenes to the developer.
6. Like many other object technologies, COM has an independent type language (IDL). In otherwords you define the declaration of your class (the header file in effect) and an IDL utility will produce the skeletal code needed to access it in your chosen language.
Hope this helps
7. It appears MS is abandoning COM. If not, why have they developed MSIL (byte code in effect) for .Net?
that's a different kind of com, there...
no, it's not
LMFAO....Quote:
Originally posted by Xterria
no, it's not
Yes it is....
There's an old executable format that ends with the .com extention......its different from the .exe version and M$ more or less abandoned it ages ago....that's why most PE executables these days are all .exe......some old linkers still support .com linkage.......TLINK.exe (TASM) for example
Component Object Model is a technology from M$ that allows an interface led programming method and allows you to use objects with all languages that support COM (VB,VBScript,Delphi,C++,J++)....
>There's an old executable format that ends with the .com extention
Oh... I remember those. I think.
Do a HD search. I found 53 .COM files. The majority were in the Windows dir but some came with older apps I've got installed such as QBasic, Turbo Pascal. There even appears to be a REM.COM in DJGPP. Does nobody remember Edit.Com? And where do you get off calling 'em old!? :p I beg your pardon, sonny. ;)Quote:
>There's an old executable format that ends with the .com extention
Oh... I remember those. I think.
</Pointless Rant>
Was that Win2k and above?Quote:
Originally posted by lightatdawn
Do a HD search. I found 53 .COM files. The majority were in the Windows dir but some came with older apps I've got installed such as QBasic, Turbo Pascal. There even appears to be a REM.COM in DJGPP. Does nobody remember Edit.Com? And where do you get off calling 'em old!? :p I beg your pardon, sonny. ;)
</Pointless Rant>
There are hang-ons........and the loader still recognises the format...but they are pretty basic programs (more or less raw binary) and they dont have the extra info an .exe will.
I downloaded a specific virus sweep from Norton a while back and I noticed that was a .com file.........they had a reason to use that format I suppose :)