Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!midway!gsbsun!valley From: valley@gsbsun.uchicago.edu (Doug Dougherty) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Stripped down DOS? Message-ID: <1991Apr18.215411.2303@midway.uchicago.edu> Date: 18 Apr 91 21:54:11 GMT References: <1991Apr17.165452.7670@ccu.umanitoba.ca> Sender: news@midway.uchicago.edu (NewsMistress) Organization: University of Chicago Lines: 31 kdorff@nmsu.edu (Kevin C. Dorff) writes: >Well, as I see it I think that someone should: > rewrite command.com so that it makes commands EXTERNAL. I know that >this would not save a LOT of space. It could retain a FEW but I think >it would be great. Most DOS commands *are* external (MODE, CHKDSK, FORMAT, etc) The resident portion of COMMAND.COM (It is COMMAND.COM that contains those few DOS "commands" that aren't external [dir, cls, etc]) is only about 3 or 4K, so I don't think you have much of a point. (In fact, I think most of the non-external commands are not in the resident portion, but nevertheless, in terms of COMMAND.COM overhead, the 3 or 4K resident portion is the only part that matters) Incidentally, I disremember the exact details of what happens when an application, running above the resident portion of COMMAND.COM, issues an INT 2E call, referencing a command not currently resident. Does COMMAND allocate memory above the application and load parts of itself there? (I think this is right, since I know if you are coding a .COM program that uses INT 2E, you have to free memory (as with EXEC), but I'm not sure if that applies when the command is a COMMAND.COM built-in) Yes, this is drift... -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)