maybee@pogo.UUCP (Joe Maybee) (04/26/86)
It is possible, using MS C, to generate an .EXE
file that can be converted to a .COM file?
If so, could you tell me how it's done?
If you KNOW it to be impossible, would you please
explain why?
--
----Joe Maybee (...!tektronix!pogo!maybee)
"We have met the enemy and he is US!"
----Pogobc@cyb-eng.UUCP (Bill Crews) (04/29/86)
> It is possible, using MS C, to generate an .EXE > file that can be converted to a .COM file? > ----Joe Maybee (...!tektronix!pogo!maybee) Be aware that DOS .com files is likely to disappear in some future DOS release. Remarks to this effect have been heard from people at Microsoft and perhaps other significant places, although I am uncertain as to whether any OFFICIAL statement to this effect has been made, though I doubt it. In my experience, the disk space saved by using .com files is minimal. With the increases in disk speed (like ~30 ms) and cpu speed, the load time difference is approaching equivalence. Wouldn't it be nice if we could get off of FCBs, too? Not likely, though. -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
few@well.UUCP (04/30/86)
In article <2479@pogo.UUCP> maybee@pogo.UUCP (Joe Maybee) writes: >It is possible, using MS C, to generate an .EXE >file that can be converted to a .COM file? >If you KNOW it to be impossible, would you please >explain why? As far as I have been able to uncover, it is mostly impossible. microsoft's small-model run-time code makes at least (the smallest I have produced) four references to DGROUP, which is (in essence) the address of the data segment used while the program is running. This value is determined at load time (by the EXE file loader), and the references are "fixed-up" by the loader. The presence of "fix-ups" is noted by EXE2BIN, who complains that the file cannot be converted (as the program cannot simply be read into memory). Clever library coders can get around these references. [Begin Horn-tooting] I was one of the first to produce COM files with Lattice C, and still use it to produce Device Drivers and other Binary Goodies. [End Horn-tooting]. Note also that msc does not require that a run-time startup module be linked first (ala crt0.o), thus insuring that the program will "begin at the beginning". Instead, the Starting Address will occur at some address other than the CS:0100H required of COM files. Again, EXE2BIN will squawk. Finally, (oops, a fuzzy part here -- where's that damn manual...) COM files must be built with no stack segment (the linker should always complain), but I forget why (too many late hours). Some enterprising individual may write a run-time startup for msc (including all of the undocumented Flags and Gizmos, not to mention new versions of some library routines) which would allow COM files to be produced, but I have to charge money for that kind of stuff. Bon Compute! -- Frank Whaley EFS Management Software, Inc. UUCP: hplabs! ihnp4!ptsfa! seismo!lll-crg!well!few ARPA: well!few@lll-crg.ARPA
ljz@well.UUCP (05/08/86)
In article <2479@pogo.UUCP> maybee@pogo.UUCP (Joe Maybee) writes: >It is possible, using MS C, to generate an .EXE >file that can be converted to a .COM file? > >If so, could you tell me how it's done? > >If you KNOW it to be impossible, would you please >explain why? You can do it, but the easiest way is also expensive. In the library is a startup routine that sets up a stack, defines certain globals, etc., etc. This routine then passes control to your main() routine. Microsoft's startup routine is meant for .EXE files, which means that there's a STACK segment and some other things that make it impossible to generate a .COM file. Microsoft will *sell* you the source code to this module for $500.00 (!!) if you want to modify it so that you can create a .COM file. This is another example of what, in my opinion, is a user-hostile attitude on the part of Microsoft. Lattice C and others not only *give* you the source to this startup module, but will give you the source to an alternate startup module expressly for producing .COM files. You could write your own startup module and link it in ahead of Microsoft's library. It would need an 'ORG 100h' statement and no segment labeled 'STACK' ... that's all (I think) you need to ensure that EXE2BIN can convert the .EXE to a .COM. That part's fairly easy. The hard part is figuring out exactly what Microsoft does in its startup module and duplicating that (otherwise, you couldn't get the command line args, the stream-oriented file stuff wouldn't work right, etc.). Given Microsoft's "we-don't-give-a-damn" attitude for people who buy less than 100 copies of its software at a time, I fear you will have a difficult time getting the info from them. Sorry to give you such bad news. If anyone has been able to get more satisfaction from Microsoft on this than I have, then I'd love to see a posting of how to do this .COM file thing.
bright@dataioDataio.UUCP (Walter Bright) (05/13/86)
hIn article <1045@well.UUCP> ljz@well.UUCP (Lloyd Zusman) writes: >In article <2479@pogo.UUCP> maybee@pogo.UUCP (Joe Maybee) writes: >>It is possible, using MS C, to generate an .EXE >>file that can be converted to a .COM file? >Microsoft will *sell* you the source code to this module for $500.00 (!!) >if you want to modify it so that you can create a .COM file. This is >another example of what, in my opinion, is a user-hostile attitude on >the part of Microsoft. Lattice C and others not only *give* you the >source to this startup module, but will give you the source to an >alternate startup module expressly for producing .COM files. >If anyone has been able to get more >satisfaction from Microsoft on this than I have, then I'd love to >see a posting of how to do this .COM file thing. Using Datalight C, you can generate .COM files with a command line option: DLC -mc program Complete sources to the library and startup modules is also provided.