Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!n8emr!bluemoon!bytehead From: bytehead@bluemoon.uucp (Bryan Price) Newsgroups: comp.os.msdos.misc Subject: Re: EXE2BIN in PCDOS 4.0 Message-ID: Date: 24 Mar 91 04:19:17 GMT References: <1991Mar20.230005.28573@bronze.ucs.indiana.edu> Sender: bbs@bluemoon.uucp (BBS Login) Organization: Blue Moon BBS ((614) 868-9980/2/4) Lines: 52 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 > Indiana University | /* They are _my_ thoughts, and you can't > Graduate School of Business | have them, so there! */