Path: utzoo!attcan!uunet!clyde.concordia.ca!maxwell!smw From: smw@maxwell.Concordia.CA ( Steven Winikoff ) Newsgroups: comp.sys.ibm.pc Subject: Re: Need input for future DOS release Keywords: future DOS release Message-ID: <2019@clyde.concordia.ca> Date: 23 Mar 90 15:44:19 GMT References: <53686@microsoft.UUCP> <2017@clyde.concordia.ca> <1990Mar22.202023.25752@seri.gov> Sender: usenet@clyde.concordia.ca Reply-To: smw@maxwell.Concordia.CA ( Steven Winikoff ) Organization: Concordia University, Montreal, Quebec Lines: 151 BACKGROUND: 1) *** Gordon Letwin asks for desired DOS enhancements. 2) >> I replied with a couple of thoughts, to get a discussion started. 3) > Marshall Buhl (marshall@wind55.seri.gov) added some good ideas. ------------------------------------------------------------------------- >>smw@maxwell.Concordia.CA ( Steven Winikoff ) writes: >> >>In any case, off the top of my head, some things I'd like to see: >> >>1) A way that works, consistently across all commands (built-in or otherwise), >> to change the switch character and path separator character (so that I can >> make DOS look more like Unix!) > Marshall Buhl (marshall@wind55.seri.gov) writes: > >This would be a bitch. I know I hardcoded these characters in my sorted >directory listing program. I'm sure others have too. I'm sure you're right; I never said it would be easy, or even possible, to do; it's just something I'd like to see. For programs where you don't have source and which embed paths with backslashes, presumably either you'd wrap the program with a batch file which changes the switch and path separator back to - and \ respectively, or else just not ever change them in the first place. I agree that it would add complexity, but I think it can be done... (I may, of course, be wrong!) >Have you considered using the PROMPT command to remap those two keys? No, mainly because I don't know how to do that. >If DOS swapped the characters and you used your PC (like me) to log into >a *nix box, wouldn't your terminal emulator send "\"s instead of "/"s, >thus screwing up your *nix session? I don't see why. I may be missing something, but what I'm asking for is for DOS to change its interpretation of these characters. The ASCII codes which would be sent upline by an emulator wouldn't change (unless there's something here that I really don't understand, which is always possible, of course!). > . > . > . >> It would also be nice, IMHO, to >> have a (separate?) search path for data files. > >It seems to me this is the responsibility of the applications developers. It is! But not all applications are created equal, and not all developers know what they're doing. Most do, but many older programs don't know about things like environment variables, or bother to remember the directory they were called from originally... (Can you say "WordStar"? I thought you could. Pre-5.x, of course.) >Additional requests from me: > >5) A decent batch language with console I/O and better branching. Also > integer and real math. YES! This could be fully upward compatible, even. >6) The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file. Another good idea. It really wouldn't cost anything to increase the size of the command line buffer, would it now? >7) A 4 GB address space. Aw, heck. Let's go for a full TB. ;-) I > remember when 64K seems like more than anyone could ever put to use. Now, that really would be difficult; you'd have to find some way of remapping the space currently used above 640k... but I agree it would be wonderful if it could be done without fundamental changes to the nature of the system. >8) 32-bit operating system. Hooks for future 64-bit. OS/3? :-) (Would be wonderful, but I don't think Microsoft has any interest in competing with OS/2... more's the pity.) >9) An OS where developers don't have to cheat to get decent performance. > >10) Verified deletes. Branch deletes. Move files without copying. YES! How hard can it be to manipulate directory entries?? >11) A FULL SCREEN EDITOR. Wow! What a concept! Do you think it can be > done? ;-) EDLIN is EMBARRASSINGLY pathetic. This should have been > done in version 2. I was using editors as powerful as EDLIN back in > the early 70s. Surely progress has been made since then. I hate > trying to help others on their PC without my favorite editor. If > DOS included a good one, then we would be assured of being able to > work on other's PCs. I have to admit, I've never understood why there wasn't one. I've just gotten so used to carrying a toolkit with my own favourite editor in it, that I haven't really noticed the lack. >12) Windows built in. Who could argue with that? >13) A good, standard way to load/unload TSRs. Also, be able to use holes > in RAM. Again, difficult but worthwhile. Unloading an arbitrary number of TSRs is a *hard* problem (at least, it is if you haven't saved the machine state before each one was loaded...) >14) A TREELOOK like program. TREE is a joke. It would also be nice if > it would print the amount of space used within each directory and > another number which is the total of all its subdirectories. I wonder if it would pay for Microsoft to license some of the Norton Utilities (LD, FS, FA, etc. come to mind at this point...) >15) Push and Pop directories. Once you've used these on Unix, it's hard to be without them. They're also extremely useful, needless to say, in batch files that need to change their working directory! >16) Virtual memory management. Indeed! Why not? >17) And, of course, all of this without using up any more precious memory, > faster, more compatible, more powerful, and easier to install and use. If only it were possible... >Basically, I'd like DOS to include all of my favorite add-ins as standards. That's the point of the whole exercise, no? > > >Gee, maybe I should try Unix or a Mac. 8-) >-- >Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov >Senior Computer Engineer VOICE: (303)231-1014 >Wind Research Branch 1617 Cole Blvd., Golden, CO 80401-3393 >Solar Energy Research Institute Solar - safe energy for a healthy future ------------------------------------------------------------------------ Steven Winikoff smw@maxwell.concordia.ca Software Analyst Dept. of Computing services Concordia University voice: (514) 848-7619 Montreal, Quebec, Canada (10:00-18:00 EST)