Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!uwm.edu!ogicse!zephyr.ens.tek.com!tekgen!sail!toma From: toma@sail.LABS.TEK.COM (Tom Almy) Newsgroups: comp.os.msdos.misc Subject: Re: EXE2BIN in PCDOS 4.0 Message-ID: <9173@sail.LABS.TEK.COM> Date: 21 Mar 91 15:58:00 GMT References: <1991Mar15.040327.27580@zoo.toronto.edu> <1991Mar20.230005.28573@bronze.ucs.indiana.edu> Reply-To: toma@sail.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 38 In article <1991Mar20.230005.28573@bronze.ucs.indiana.edu> rschmidt@copper.ucs.indiana.edu (roy schmidt) writes: >valley@uchicago (Doug Dougherty) writes: > >>PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the > >>original floppies!). >Actually, what you are seeing is the official Microsoft line. Microsoft >has decided that we should not write .COM programs anymore, and >therefore don't support/condone them. A sure way to decrease the number >of .COM files is by not giving you the utility to manufacture them. Of course, If you buy the right compilers (Borland, Zortech) you can make .COM programs without using Microsoft's EXE2BIN. Borland's linker will generate .COM files directly, and Zortech provides their own EXE2BIN. You still need EXE2BIN to generate device drivers (for most versions of DOS) or binary files for ROMs. In fact at least one example program in the Microsoft Windows SDK needs EXE2BIN to generate a binary file! >My question is, why would you want to convert a perfectly good .EXE file >to a .COM file? An .EXE file requires far less RAM to run (.COM needs >64K regardless of object code size) so making a small .COM file does not >really make sense anyway. This is not true. I wrote a Forth compiler years ago that generated COM files by default but would also generate EXE files. The EXE option was never smaller either in file size or during execution. At run time a COM file can be any size you want. MS-DOS gives all the available memory to a COM program, but the program can release any memory it does not need. Any COM program that uses exactly 64k is somehow being constrained by the compiler. For instance it is certainly possible for a COM program to have separate segments, and to actually take more than 64k to run (although DOS won't load COM files greater than 64k, limiting code+initialized data to 64k). I have yet to see a compiler, other than mine, that could take advantage of this other than by explicit casting to "far". -- Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply