teplovs@zoo.toronto.edu (Chris Teplovs) (03/15/91)
I recently created an EXE file on a system running MSDOS 4.01, and had no trouble converting it to a .COM file using EXE2BIN. When I recompiled the source code to an .EXE file on a system running PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the original floppies!). Anyone know if this is an isolated incident, or is this a problem with PCDOS 4.0? Thanks, Chris. -- Chris Teplovs | teplovs@zoo.toronto.edu Dept. of Zoology | teplovs@zoo.utoronto.ca University of Toronto |
valley@uchicago (Doug Dougherty) (03/16/91)
teplovs@zoo.toronto.edu (Chris Teplovs) writes: >I recently created an EXE file on a system running MSDOS 4.01, and had >no trouble converting it to a .COM file using EXE2BIN. >When I recompiled the source code to an .EXE file on a system running >PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the >original floppies!). Anyone know if this is an isolated incident, >or is this a problem with PCDOS 4.0? IBM decided a long time ago that ordinary users didn't need EXE2BIN and hence that they could afford to charge extra for it. Get EXE2COM by CJ Dunford, available on most boards and FTP sites.
rschmidt@copper.ucs.indiana.edu (roy schmidt) (03/21/91)
valley@uchicago (Doug Dougherty) writes: >teplovs@zoo.toronto.edu (Chris Teplovs) writes: > >>PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the >>original floppies!). Anyone know if this is an isolated incident, >>or is this a problem with PCDOS 4.0? > >IBM decided a long time ago that ordinary users didn't need EXE2BIN and >hence that they could afford to charge extra for it. > 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. 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. Of course, MS is always immune from their own official line :-). They still churn out .COM files in their own packages, just like they still use FCBs for internal DOS commands. Sigh. -- -------------------------------------------------------------------------- Roy Schmidt | #include <disclaimer.h> Indiana University | /* They are _my_ thoughts, and you can't Graduate School of Business | have them, so there! */
w8sdz@rigel.acs.oakland.edu (Keith Petersen) (03/21/91)
rschmidt@copper.ucs.indiana.edu (roy schmidt) writes: >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. How do you explain the fact that EXE2BIN comes with MASM, then? I think the reason it's no longer shipped with MS-DOS is because there are no programs supplied which create EXE files which need to be converted to COM files. Keith -- Keith Petersen Co-SysOp, Detroit Download Central 313-885-3956 (212/V22bis/HST/V32/V42bis) Internet: w8sdz@vela.acs.oakland.edu, w8sdz@eddie.mit.edu, w8sdz@brl.mil Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
gerardis@cs.mcgill.ca (Tony GERARDIS) (03/21/91)
In article <5479@vela.acs.oakland.edu> w8sdz@rigel.acs.oakland.edu (Keith Petersen) writes: >rschmidt@copper.ucs.indiana.edu (roy schmidt) writes: >>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. > >How do you explain the fact that EXE2BIN comes with MASM, then? > >I think the reason it's no longer shipped with MS-DOS is because there >are no programs supplied which create EXE files which need to be converted >to COM files. > >Keith >-- >Keith Petersen Ya and how would you explain the fact that EXE2BIN comes on Disk 3 of MSDOS 5.0. (Yes I already have a copy of the RELEASE CANDIDATE #3) Works like a charm and EXE2BIN is also supplied. PROBLEM SOLVED - MICROSOFT Still SHIPS EXE2BIN.EXE with MSDOS!!!! ------------------------------------------------------------------ gerardis@quiche.cs.mcgill.ca | The sun is the same in a relative way, | but you're older | And shorter of breath and one day | closer to DEATH. -Floyd
toma@sail.LABS.TEK.COM (Tom Almy) (03/21/91)
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
edso@arnor.UUCP (Edward C. So) (03/22/91)
> > valley@uchicago (Doug Dougherty) writes: > >teplovs@zoo.toronto.edu (Chris Teplovs) writes: > > > >>PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the > >>original floppies!). Anyone know if this is an isolated incident, > >>or is this a problem with PCDOS 4.0? > > > >IBM decided a long time ago that ordinary users didn't need EXE2BIN and > >hence that they could afford to charge extra for it. > > > 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. > EXE2BIN is on the Utilities diskette that comes with DOS Technical Reference manual. The same diskette also contains LINK, DEBUG, and the assembler source for VDISK(RAMDISK). -- Edward C. So edso@ibm.com (Internet) Computing Systems, IBM T.J. Watson Research Center
lair@ellis.uchicago.edu (Scott A. Laird) (03/22/91)
In article <1991Mar21.055841.10037@cs.mcgill.ca> gerardis@cs.mcgill.ca (Tony GERARDIS) writes: >In article <5479@vela.acs.oakland.edu> w8sdz@rigel.acs.oakland.edu (Keith Petersen) writes: >> >>How do you explain the fact that EXE2BIN comes with MASM, then? >> >>I think the reason it's no longer shipped with MS-DOS is because there >>are no programs supplied which create EXE files which need to be converted >>to COM files. >> >>Keith >>-- >>Keith Petersen > >Ya and how would you explain the fact that EXE2BIN comes on Disk 3 of >MSDOS 5.0. (Yes I already have a copy of the RELEASE CANDIDATE #3) >Works like a charm and EXE2BIN is also supplied. > > >PROBLEM SOLVED - MICROSOFT Still SHIPS EXE2BIN.EXE with MSDOS!!!! > >------------------------------------------------------------------ > gerardis@quiche.cs.mcgill.ca | The sun is the same in a relative way, > | but you're older > | And shorter of breath and one day > | closer to DEATH. -Floyd Actually, EXE2BIN.EXE is included on my MS-DOS 4.01 distribution disks. I know that _IBM_ stopped shipping EXE2BIN, but if Microsoft did, it was only for a limited time. I had thought that they had stopped, too, but when I looked several months ago, it was there. I also checked on some PC-DOS 4.0 floppies, and sure enough, no EXE2BIN. So Microsoft will still let us convert .EXE's to .COM's in DOS 4. Now if they would have just given us the memory to do anything else... I really hate having to use drive J:, thought, so 3.3 isn't perfect, either. When's my copy of DOS 5.0 going to start shipping? -- Scott A. Laird | Any semblance of the above to anything is purely lair@midway.uchicago.edu | coincidental, as it was the result of an infinite The University of Chicago | number of monkeys sneaking in to use my computer | for the afternoon.
dahlstr@hus.chalmers.se (Gunnar Dahlstrom) (03/22/91)
In article <1991Mar20.230005.28573@bronze.ucs.indiana.edu> rschmidt@copper.ucs.indiana.edu (roy schmidt) writes: >valley@uchicago (Doug Dougherty) writes: > >teplovs@zoo.toronto.edu (Chris Teplovs) writes: > > > >>PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the > >>original floppies!). Anyone know if this is an isolated incident, > >>or is this a problem with PCDOS 4.0? > > > >IBM decided a long time ago that ordinary users didn't need EXE2BIN and > >hence that they could afford to charge extra for it. > > >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. Why have Microsoft start supporting TINY model (to create .COM program) in C 6.0 if they have a line where they will not support this model?? > >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. It is verey simpel to write .COM program, you don't have to worry about to use different segments! > >Of course, MS is always immune from their own official line :-). They >still churn out .COM files in their own packages, just like they still >use FCBs for internal DOS commands. Sigh. > // Gunnar =============================================================================== Gunnar Dahlstrom Chalmers University of Technology Div. Building Technology 412 96 Gothenburg, Sweden E-Mail: dahlstr@hus.chalmers.se ===============================================================================
gerardis@cs.mcgill.ca (Tony GERARDIS) (03/23/91)
In article <1991Mar22.000601.5114@midway.uchicago.edu> lair@ellis.uchicago.edu (Scott A. Laird) writes: >> >>Ya and how would you explain the fact that EXE2BIN comes on Disk 3 of >>MSDOS 5.0. (Yes I already have a copy of the RELEASE CANDIDATE #3) >>Works like a charm and EXE2BIN is also supplied. >> >> >>PROBLEM SOLVED - MICROSOFT Still SHIPS EXE2BIN.EXE with MSDOS!!!! >> > >Actually, EXE2BIN.EXE is included on my MS-DOS 4.01 distribution disks. I know >that _IBM_ stopped shipping EXE2BIN, but if Microsoft did, it was only for a >limited time. I had thought that they had stopped, too, but when I looked >several months ago, it was there. I also checked on some PC-DOS 4.0 floppies, >and sure enough, no EXE2BIN. > >So Microsoft will still let us convert .EXE's to .COM's in DOS 4. Now if they >would have just given us the memory to do anything else... I really hate >having to use drive J:, thought, so 3.3 isn't perfect, either. When's my >copy of DOS 5.0 going to start shipping? > Well It was scheduled for this or next month but hey this is Microsoft we are talking about. Windows 3.0 was released about a year after schedule and 3.1 was also scheduled for next month (ya right!). Well All I can tell you is that hopefully it'll be released by the summer! Trust Me it will be worth every penny Microsoft asks for it! I'm using the 'MSDOS 5.00 RELEASE CANDIDATE #3' and it works beautifully. It is quite stable, and after all my device drivers are loaded( ie. smartdrive, ramdrive, mouse driver, himem.sys, etc) I still have 595k free! Now who needs QEMM with results like that from DOS! It's about time! ------------------------------------------------------------------------ gerardis@quiche.cs.mcgill.ca | The sun is the same in a relative way, | but you're older | And shorter of breath and one day | closer to DEATH. -Floyd
bytehead@bluemoon.uucp (Bryan Price) (03/24/91)
rschmidt@copper.ucs.indiana.edu (roy schmidt) writes: > valley@uchicago (Doug Dougherty) writes: > >teplovs@zoo.toronto.edu (Chris Teplovs) writes: > > > >>PCDOS 4.0, I couldn't find EXE2BIN (it doesn't seem to exist on the > >>original floppies!). Anyone know if this is an isolated incident, > >>or is this a problem with PCDOS 4.0? > > > > > 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. Microsoft has been having second thoughts on this. EXE2BIN exists at least on the DOS 5.0 betas, and I would assume would be on the actual release. Plus, I beleive the update to C 6.0 now allows .COM file creation. I haven't updated mine yet to find out. I need to clear out some more room on the HD! > 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. Well, .COM files load faster, will use the same amount of memory (all DOS programs get all available memory allocated to them at run-time!), and can be easier to disassemble! :-) > > Of course, MS is always immune from their own official line :-). They > still churn out .COM files in their own packages, just like they still > use FCBs for internal DOS commands. Sigh. > There are still some areas in DOS that make since in using FCBs. Deleting files with FCBs is actually much faster, primarily because when deleting you can specify wildcards in FCBs, and in the Unix style calls, you can only pass one name. I didn't believe this until I timed it myself. I've seen speed increases of 3000 percent (yes three thousand!). 2 seconds to delete 600 files using one (1) FCB, while it took over two minutes to delete using the Unix style command. And yes, the Unix style was optimized (I got all the names in a list first, which took under .25 seconds to do) > > -- > -------------------------------------------------------------------------- > Roy Schmidt | #include <disclaimer.h> > Indiana University | /* They are _my_ thoughts, and you can't > Graduate School of Business | have them, so there! */
Ralf.Brown@B.GP.CS.CMU.EDU (03/25/91)
In article <uuPaZ3w163w@bluemoon.uucp>, bytehead@bluemoon.uucp (Bryan Price) wrote: }There are still some areas in DOS that make since in using FCBs. Deleting }files with FCBs is actually much faster, primarily because when deleting }you can specify wildcards in FCBs, and in the Unix style calls, you can }only pass one name. I didn't believe this until I timed it myself. I've Note that there is an undocumented indirect DOS call; if you make the Unix-style delete call via that indirect entry, wildcards are enabled, and the Unix-style delete will be just as fast as the FCB delete. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers