gordonl@microsoft.UUCP (Gordon LETWIN) (03/22/90)
Microsoft is working on a major upgrade to DOS and I'd like to solicit input from the "power user" communitiy. I've never met a programmer who didn't think that they could have "done it better" with regards to someone else's product, so here's an opportunity to enlighten us. Please note that the DOS operating system has to remain "DOS" in the sense that Microsoft already has a strategy for a high end OS which requires that programs be rewritten - i.e., OS/2. So our next major release needs to continue to run existing DOS programs and whatever new features it has, it must offer those features to existing programs. Or, the new features must be expressed in utilities and programs which ship with the system. An example of this later would be a screen and menu oriented replacement for the CONFIG.SYS file. So, if you've ever wished that DOS was better in some way (and who hasn't?), email your input to me at uunet!microsoft!gordonl Mailers willing, I'll acknoledge all mail. Depending upon volume and time I may not have time to reply at length, though. thanks gordon letwin microsoft
smw@maxwell.Concordia.CA ( Steven Winikoff ) (03/23/90)
In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: >Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. I've never met a programmer who >didn't think that they could have "done it better" with regards to someone >else's product, so here's an opportunity to enlighten us. > . > . > . >So, if you've ever wished that DOS was better in some way (and who hasn't?), >email your input to me at > > uunet!microsoft!gordonl I'm sure this will really spark a long discussion! In any case, while I know that Gordon asked for mail, I'm posting this to see how other people feel about these ideas... My personal short list of pet peeves about DOS (as a user interface) are all things that would be addressed by a "better" shell. I know that there are others out there (eg 4DOS, MKS Korn shell, etc.), but I prefer to stick with the "standard" one so that I know I won't get bitten by incompatibilities while developing software to run under DOS. (I currently use DOS 3.3, and have never seen 4.x, so I apologize in advance if any of the following are already implemented.) 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!) 2) Interpreting the asterisk in wildcard expressions similarly to how it's done in Unix (eg handle things like *X.* by generating a list of all files whose names end with the letter X, regardless of extension -- something that DOS 3.3 provides no way to accomplish). 3) Aliases and some sort of command history (currently provided by third parties, of course, but there's no standard mechanism). 4) An easy, standard way to express search paths of arbitrary length (subject to environment space limits, of course!) It would also be nice, IMHO, to have a (separate?) search path for data files. I'm sure I could come up with more if I thought about it long enough, but these alone would be enough to get me to switch to a newer version. ------------------------------------------------------------------------ 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)
marshall@wind55.seri.gov (Marshall L. Buhl) (03/23/90)
>> *** Gordon Letwin asks for desired DOS enhancements. *** 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!) This would be a bitch. I know I hardcoded these characters in my sorted directory listing program. I'm sure others have too. Have you considered using the PROMPT command to remap those two keys? 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? >2) Interpreting the asterisk in wildcard expressions similarly to how it's > done in Unix (eg handle things like *X.* by generating a list of all > files whose names end with the letter X, regardless of extension -- > something that DOS 3.3 provides no way to accomplish). Oh, please, please, please. Anyone ever "DEL *X.*"? Pissed, weren't you? >3) Aliases and some sort of command history (currently provided by third > parties, of course, but there's no standard mechanism). And the software interferes with other apps. I'll take this one too. >4) An easy, standard way to express search paths of arbitrary length (subject > to environment space limits, of course!) Gee, do you think we can afford a whole 1KB environment instead of 132 byte one? Nothing like being cheap in all the wrong places. ;-) > 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. I have programs which use environment variables to tell them where to look for data files. Additional requests from me: 5) A decent batch language with console I/O and better branching. Also integer and real math. 6) The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file. 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. 8) 32-bit operating system. Hooks for future 64-bit. 9) An OS where developers don't have to cheat to get decent performance. 10) Verified deletes. Branch deletes. Move files without copying. 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. 12) Windows built in. 13) A good, standard way to load/unload TSRs. Also, be able to use holes in RAM. 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. 15) Push and Pop directories. 16) Virtual memory management. 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. Basically, I'd like DOS to include all of my favorite add-ins as standards. 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
2011_552@uwovax.uwo.ca (Terry Gaetz (UWO Astronomy)) (03/23/90)
In article <1990Mar22.202023.25752@seri.gov>, marshall@wind55.seri.gov (Marshall L. Buhl) writes: >>> *** Gordon Letwin asks for desired DOS enhancements. *** > > 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!) Yes! > This would be a bitch. I know I hardcoded these characters in my sorted > directory listing program. I'm sure others have too. Then the programs should be recoded and recompiled :-) > Have you considered using the PROMPT command to remap those two keys? I prefer that a key perform the action listed on the keycap. > 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? The terminal emulator should be fixed. >>2) Interpreting the asterisk in wildcard expressions similarly to how it's >> done in Unix (eg handle things like *X.* by generating a list of all >> files whose names end with the letter X, regardless of extension -- >> something that DOS 3.3 provides no way to accomplish). > > Oh, please, please, please. > > Anyone ever "DEL *X.*"? Pissed, weren't you? Yes. PLEASE fix this! [...] > Additional requests from me: > [...] > 15) Push and Pop directories. 15a) Swap two directories. I am most frequently jumping back and forth between two directories (eg. source directory and test directory). It would save a lot of typing if DOS remembered the previous directory and allowed one to jump back to it: c:\firstdir> cd \anotherdir c:\anotherdir> swapd c:\firstdir> swapd c:\anotherdir> [etc.] This can be handled by a batch file, but I think DOS should do it. > -- > Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov -- Terry Gaetz -- gaetz@uwovax.uwo.ca -- gaetz@uwovax.bitnet
rbw00@uts.amdahl.com (Richard Wilmont) (03/23/90)
And wouldn't it be nice if we could do asynchronous I/O. I understand that
the restriction of synchronous I/O is usually dictated by BIOS coding (?)
but if the DOS *standard* included interrupts for doing it then we could
put more effective pressure on BIOS vendors. I could use this facility in
ways: My search program could read the first block, issue an asynchronous
read for the next block and begin searching the one just read.
We used this technique on early computers to obtain a benefit we called
*I/O OVERLAP*.
Oh, this facility will also need a way to check on the status of a
previously issued I/O command (also called WAIT or CHECK).
I run 2 hard drives in my home machine and would like to be able to start
an I/O to physical drive 1 before the previous command to physical drive
2 has finished.
Not asking for multiprogramming or multitasking, just peripheral/compute
overlap.
- Dick Wilmotwoodside@ttidca.TTI.COM (George Woodside) (03/23/90)
> *** Gordon Letwin asks for desired DOS enhancements. ***
Ignoring the shell requests for a moment, the DOS enhancement that most
recently caused me the greatest difficulty was the inability to get/set
(especially SET, when the media does not contain a DOS compatible boot
sector) removeable media configuration data, and cause the equivalent
of a media change to occur via software.
Next is a standard method to have an arbitrarily long argument string
passed as input to a program in a manner that does not require the
program to parse a response file, or at least doesn't break when a
program using one attempts to invoke another program.
--
* George R. Woodside - Citicorp/TTI - Santa Monica, CA *
* Path: woodside@ttidca *
* or: ..!{philabs|csun|psivax}!ttidca!woodside *smw@maxwell.Concordia.CA ( Steven Winikoff ) (03/23/90)
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)
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (03/24/90)
How about DOS built in access to Expanded Memory on 808[6,8], and *DOS* access to Extended Memory on 80[2,3,4]86 machines (as opposed to BIOS access.) How about the HPFS for DOS. kaleb@mars.jpl.nasa.gov Jet Propeller Labs Kaleb Keithley spelling and grammar flames > /dev/null
mvolo@uncecs.edu (Michael R. Volow) (03/24/90)
And while were fantasizing, how about: 1)Longer file names 2)Password and write-protecting directories 3)Linking files to other directories. M Volow, VA Medical Center, Durham, NC 27705 mvolo@ecsvax.edu 919 286 0411
gpitcher@edpmgt.UUCP (Glenn Pitcher) (03/24/90)
In article <1990Mar22.202023.25752@seri.gov>, marshall@wind55.seri.gov (Marshall L. Buhl) writes: > >> *** Gordon Letwin asks for desired DOS enhancements. *** > > 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!) > > This would be a bitch. I know I hardcoded these characters in my sorted > directory listing program. I'm sure others have too. > Couldn't the shell be altered to intercept those directory requests and remap the characters before the actual open (or whatever) command is issued? This way, everyone would be happy :-) > > >2) Interpreting the asterisk in wildcard expressions similarly to how it's > > done in Unix (eg handle things like *X.* by generating a list of all > > files whose names end with the letter X, regardless of extension -- > > something that DOS 3.3 provides no way to accomplish). > This is a definate. I consider this to be a big, nasty bug that's existed *way* too long. > >3) Aliases and some sort of command history (currently provided by third > > parties, of course, but there's no standard mechanism). > We have these capabilities on our PC's and I tell 'ya, I wonder how I ever worked without them. > > 6) The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file. > Amen!! > 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. > If you really need an entire terabyte right now, I've got an IBM 3090 I'll sell 'ya *real* cheep :-) > > 10) Verified deletes. Branch deletes. Move files without copying. > I think that the verified deletes should be included as an option in the delete command. This way, if you always want to verify the delete, you can set up an alias. Moving files is another biggie in my book. While were at it, I would like to see disk optimization and file recovery. -- Glenn Pitcher UUCP: {crash,ucsd}!edpmgt!gpitcher Programmer/Analyst & INTERNET: I wish Unix Guru in training EDP Management, Inc. * Proud member of Team.Net * =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
dlow@hpspcoi.HP.COM (Danny Low) (03/24/90)
>Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. > gordon letwin > microsoft Writing as a user, what I most want is make the resident portion of MSDOS SMALLER! I installed 4.01 and lost 32K of RAM! This was a duplicate of my existing 3.3 configuration with none of the selectable extra features of 4.01. Half the programs I frequently used no longer ran off PCSHELL from PCTOOLS Deluxe. I went back to 3.3 as I decided I could live with a partitioned disk better than I could live with bouncing in and out of PCSHELL to run FREQUENTLY used programs. RAM cram is bad enough without DOS making it worst. If DOS gets any bigger I will not be able to run many of my applications. There are two enhancements I want. The first is a command line editor. The second is a more sophisticated batch language. First priority is a counter (e.g. DO %COUNT% TIMES). Second priority is more flexible ERRORLEVEL checking (e.g. IF ERRORLEVEL <= 10). Danny Low "Question Authority and the Authorities will question You" Valley of Hearts Delight, Silicon Valley HP SPCD dlow%hpspcoi@hplabs.hp.com ...!hplabs!hpspcoi!dlow
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/24/90)
Before I comment on what Marshal wrote, may I point out that the original
article stated quite clearly that Microsoft intends to retain full backward
compatibility in DOS (obviously!) and that it's their low-end OS and is not
to compete with OS/2 (okay, so the original post didn't put it in those words,
but that's the idea).
In article <1990Mar22.202023.25752@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes:
$>4) An easy, standard way to express search paths of arbitrary length (subject
$> to environment space limits, of course!)
$Gee, do you think we can afford a whole 1KB environment instead of 132 byte
$one? Nothing like being cheap in all the wrong places. ;-)
In DOS verions 3.10 (at least) and later, you can set DOS to use an
environment as large as you want it (within reason). However, there are a
couple of problems that people have encountered with the fact that some
versions of DOS shrink the environment space to less than you've specified
if you don't use it all, so perhaps future DOS versions could grow and
shrink their environments according to the user's needs.
$5) A decent batch language with console I/O and better branching. Also
$ integer and real math.
Something like Unix's case and if-else-elseif structures could be
implemented without affecting backward compatibility. This would relieve
the batch programmer of having to use a series of IF statements or a FOR
statement with a bunch of GOTOs to implement a case, and would make batch
files much easier to read.
$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.
$8) 32-bit operating system. Hooks for future 64-bit.
Not likely ... this would not provide backward compatibility (or at
least not with any level of reliability), and would infringe upon OS/2's
territory.
$10) Verified deletes. Branch deletes. Move files without copying.
It's always puzzled me why the rename function call will move a file
without copying anywhere on a given drive, but the DOS rename command
doesn't let you do this.
$12) Windows built in.
This would have to be optional, since many users do not want Windows
on their machines (and also would not want to pay the extra money for it);
also, to allow users to use Windows/286 or /386 on their machines according
to processor type, this would have to be an option.
$13) A good, standard way to load/unload TSRs. Also, be able to use holes
$ in RAM.
The way most versions of DOS work when allocating memory is that they
select the lowest chunk in memory that is large enough, so holes in RAM
can already be used. (With recent versions, you can change this
strategy to be either the highest chunk that is large enough, or the smallest
chunk that is large enough, but I don't imagine [m]any people do this.)
$16) Virtual memory management.
Once again, this won't be implemented since a) it doesn't promote
compatibility and b) it's the territory of OS/2.
I can think of a few other Unix-like things I'd like to see added to the
shell, such as the ability to input to an environment variable from stdin
(which, through redirection, would allow files to be read into environment
variables too), the ability to redirect stdout, a sleep command to sleep
for a given time, filename completion (as in csh or tcsh), the ability
to specify a "temporary" path where DOS stores intermediate files during
pipes, and heavier use of expanded memory (I don't know how extensively
DOS 4 uses EMS ... forgive me if it already does all it could :-).
And all this just from a user's perspective ...
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."richard@calvin.spp.cornell.edu (Richard Brittain) (03/24/90)
Have people notices that the vast majority of the things mentioned in this
thread so far are features of the shell, not the system services, and that
they are pretty much solved with 4dos (and possibly with the other commercial
compeditors liek command-plus)
I wrote to Mr Letwin and suggested Microsoft license 4dos. Stranger things
have happened.
Though not often.
Richard Brittain, School of Elect. Eng., Upson Hall
Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.spp.cornell.edu
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richardaustin@bucsf.bu.edu (Austin H. Ziegler, III) (03/26/90)
How about a *real* piping system with virtual files so that shtuff we like on unix will be more available! austin -- austin@bucsf.bu.edu (bigstuff to austin@buengf.bu.edu) 700 Commonwealth Box 2094, Boston, MA 02215 (617) 375-8272 BUENG '93 "Authenticating USENET in its current form is like putting a lock on the wrong side of the exit door." -- Chuq von Rospach, news.misc
raymond@sunkist.berkeley.edu (Raymond Chen) (03/26/90)
Ahem. All this discussion about "What I wish were in DOS" is very nice, but it's not going to do one whit of good if Gordon Letwin doesn't see any of it. Here's what Mr Letwin wrote: >So, if you've ever wished that DOS was better in some way (and who hasn't?), >email your input to me at > > uunet!microsoft!gordonl > >Mailers willing, I'll acknoledge all mail. Depending upon volume and time >I may not have time to reply at length, though. So, please, send your wish lists to Mr Letwin. (Of course, if you think it merits discussion, post it, too; but don't forget to send a copy to Mr Letwin!) -- raymond@math.berkeley.edu Maintainer of the csip Frequently Asked Questions
boerner@ut-emx.UUCP (Brendan B. Boerner) (03/26/90)
Here are a couple of things I wouldn't mind seeing in a new version of MS-DOS. I realize some have already been mentioned but I thought I'd send the whole list as is anyway. 1) The ability to load/unload device drivers at any time - not just during the boot process. Sorta like Novell's Netware Loadable Modules on NetWare/386. 2) A TSR Manager. Programs written to use it would let it know what resources that they need (e.g. what interupts they would like to be activated on). It would keep track of what program uses what interrupts so if a call were made to unload a TSR, it would be able to unload it without affecting others in the chain. This mechanism could also handle making sure ALL tasks attatched to that interrupt get called. This would prevent TSRs from attatching to an interrupt and then not calling whatever was previously attatched. By not requiring TSRs to call others in the chain, it seems that memory could be compacted when a TSR was removed without affecting others (since they wouldn't be storing addresses of other TSRs to run). 3) A file system which supports symbolic links, e.g. more than one directory entry could point to the same file. 4) Rename (or move) across directories within the same volumne which does not require a copy. I beleive that DOS already provides this although COMMAND.COM doesn't use it. 5) A better wildcard capability. Dir *X.* would display files ending with X, with any extension, not all files. 6) A larger command line limit. This would allow paths with length greater than 128 chars. Brendan -- Brendan B. Boerner Phone: 512/471-3241 Microcomputer Technologies The University of Texas @ Austin Internet: boerner@emx.utexas.edu UUCP: ...!cs.utexas.edu!ut-emx!boerner BITNET: CCGB001@UTXVM.BITNET AppleLink: boerner@emx.utexas.edu@DASNET#
amf@ecs.soton.ac.uk (Andrew Fountain) (03/26/90)
smw@maxwell.Concordia.CA ( Steven Winikoff ) writes: >In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: >>Microsoft is working on a major upgrade to DOS and I'd like to solicit >>input from the "power user" communitiy. I've never met a programmer who >>didn't think that they could have "done it better" with regards to someone >>else's product, so here's an opportunity to enlighten us. All I need is better Windows support. (Which probably = smaller) -- amf@ecs.soton.ac.uk Dr. Andrew Fountain Tel: +44 703 592831 Dept of Electronics and Computer Science Fax: +44 703 593045 University of Southampton Telex: 47661 SOTONU G Southampton SO9 5NH England
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/27/90)
In article <2019@clyde.concordia.ca> smw@maxwell.Concordia.CA ( Steven Winikoff ) writes:
$>Have you considered using the PROMPT command to remap those two keys?
$No, mainly because I don't know how to do that.
Don't bother. You need ANSI.SYS (or equivalent) for this and it will
slow down your screen I/O. The idea is to embed an ANSI sequence to
remap a given key into your prompt so that ever time you're at the DOS
prompt, it ensures that your keys are mapped the way you want them.
$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.)
The reason is that you can't find out what path you were executed from
unless you're using DOS 3 or better. Of course, this is no excuse for
being too lazy to add code to check for DOS 3 and, if so, keep track of
where you were invoked from ...
$>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?
No it wouldn't ... except that then users would expect that they could
pass a huge command line to an external command and would start complaining
of a bug in DOS.
$>10) Verified deletes. Branch deletes. Move files without copying.
$YES! How hard can it be to manipulate directory entries??
Moving files without copying, for example, has been part of the DOS
RENAME function call since the idea of paths came along. It's just that
COMMAND.COM's designers decided they didn't want us to be able to do that.
$>12) Windows built in.
$Who could argue with that?
As long as I'm allowed to wipe it off my hard drive and it doesn't
increase the price of DOS, I don't mind. But I don't want to be forced
to pay for it and have it clutter up my memory and hard disk and degrade
system performance just because I may want a new version of DOS.
$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...)
Most of those really aren't hard to write ... the only reason people
are so thrilled with many of them is that Norton did them right, and DOS
either didn't do them, did them wrong, or did them far too late. Writing
a program like FA would take an experienced programmer a couple of hours.
But you do have a good point. Microsoft should have a close look at
the features of various toolkit packages, make a note of some of the things
they do, and write their own to do those functions.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/27/90)
In article <246@edpmgt.UUCP> gpitcher@edpmgt.UUCP (Glenn Pitcher) writes:
$Couldn't the shell be altered to intercept those directory requests and
$remap the characters before the actual open (or whatever) command is issued?
If you alter the shell, this would only affect commands issued from the
shell. Pathnames entered within applications would still require the use
of the \ regardless of what you set.
Changing the path separator, however, could be implemented as a DOS
call so that changes would be universal.
$> >3) Aliases and some sort of command history (currently provided by third
$> > parties, of course, but there's no standard mechanism).
$We have these capabilities on our PC's and I tell 'ya, I wonder how I ever
$worked without them.
Indeed! I never knew what I was missing until I started using Unix
a fair bit. I now find COMMAND.COM so confining, compared to tcsh, that
I've been driven to write my own command shell (yes, I know there are
plenty available ... but I like rolling my own programs; and don't write
me asking for a copy, as it's far from complete).
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."ghost@cup.portal.com (Robert Bruce Ferrell) (03/27/90)
How about unix style links? That would eliminate beucoup
batch files on some machines I know.
ghostcup.portal.com or bferrell@mcimail.com
Yes, I AM unique... so far :-)robert@ireq.hydro.qc.ca (R.Meunier 8516) (03/27/90)
They should bundle 4DOS 3.0 with the next version of MS-DOS -- ----------------------------------------------------------------------- Robert Meunier Institut de Recherche d'Hydro-Quebec Ingenieur 1800 Montee Ste-Julie, Varennes Internet: robert@ireq.hydro.qc.ca Qc, Canada, J3X 1S1
bob@omni.com (Bob Weissman) (03/27/90)
In article <246@edpmgt.UUCP>, gpitcher@edpmgt.UUCP (Glenn Pitcher) writes: > In article <1990Mar22.202023.25752@seri.gov>, marshall@wind55.seri.gov (Marshall L. Buhl) writes: > > >> *** Gordon Letwin asks for desired DOS enhancements. *** > > > > 10) Verified deletes. Branch deletes. Move files without copying. > > > I think that the verified deletes should be included as an option in the > delete command. This way, if you always want to verify the delete, you > can set up an alias. Moving files is another biggie in my book. Moving files is easy. I wrote a MV.EXE which is very similar to the Unix mv(1) command. It allows all three forms mv filename1 filename2 mv directory1 directory2 mv filename ... directory The only visible difference with mv(1) is the lack of three flags -, -f, and -i. I'll be happy to share it if anyone wants it. But you guys are all missing the point with requests like this. The capability exists in the operating system already; what you are griping about is the command interpreter, which is only a program. -- Bob Weissman Internet: bob@omni.com UUCP: ...!{apple,pyramid,sgi,tekbspa,uunet}!omni!bob
scholes@boulder.Colorado.EDU (SCHOLES MARTIN LEE) (03/27/90)
In article <2019@clyde.concordia.ca> smw@maxwell.Concordia.CA ( Steven Winikoff ) writes: >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. >------------------------------------------------------------------------- Ok, here's another nice option that UNIX has, and I wish DOS had... Command line filename expansion. Let DOS put the file names on the command line with all of the wonderfull regular expressions of UNIX, like del filever.00[123] that would be nice. Marty
emigh@ncsugn.ncsu.edu (Ted H. Emigh) (03/27/90)
What I would like to see is for DOS to be "somewhat" reentrant. By somewhat I mean that I would be willing to prepare DOS for another DOS call by saving various parameters. Something like a DOS function where I supply the area where the parameters are saved, then call the SAV_PARM function -- on exiting my routine, I would call RES_PARM function. -- Ted H. Emigh, Dept. Genetics and Statistics, NCSU, Raleigh, NC uucp: mcnc!ncsuvx!ncsugn!emigh internet: emigh@ncsugn.ncsu.edu BITNET: emigh%ncsugn@MCNC.UUCP or emigh%ncsugn@ncsuvx.ncsu.edu
gpitcher@edpmgt.UUCP (Glenn Pitcher) (03/28/90)
In article <1920@borabora.omni.com>, bob@omni.com (Bob Weissman) writes: > In article <246@edpmgt.UUCP>, gpitcher@edpmgt.UUCP (Glenn Pitcher) writes: > > In article <1990Mar22.202023.25752@seri.gov>, marshall@wind55.seri.gov (Marshall L. Buhl) writes: > > > >> *** Gordon Letwin asks for desired DOS enhancements. *** > > > > > > 10) Verified deletes. Branch deletes. Move files without copying. > > > > > I think that the verified deletes should be included as an option in the > > delete command. This way, if you always want to verify the delete, you > > can set up an alias. Moving files is another biggie in my book. > > Moving files is easy. I wrote a MV.EXE which is very similar to the > Unix mv(1) command. It allows all three forms > mv filename1 filename2 > mv directory1 directory2 > mv filename ... directory > The only visible difference with mv(1) is the lack of three flags -, -f, > and -i. I'll be happy to share it if anyone wants it. > > But you guys are all missing the point with requests like this. The > capability exists in the operating system already; what you are griping > about is the command interpreter, which is only a program. > Yes, these features do exist in the OS as it is like you say but what everyone is saying is they want Microsoft to use them in the shell. This way, everyone's shell will be the same and we won't have to depend on third party shells such as 4DOS. I'm not saying the 4DOS is bad, I personally like it, but it would be nice for the head honcho (Microsoft) to utilize all of their own tools. -- Glenn Pitcher UUCP: {crash,ucsd}!edpmgt!gpitcher Programmer/Analyst & INTERNET: I wish Unix Guru in training EDP Management, Inc. * Proud member of Team.Net * =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
neese@adaptex.UUCP (03/28/90)
>Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. I've never met a programmer who >didn't think that they could have "done it better" with regards to someone >else's product, so here's an opportunity to enlighten us. 1) A more flexible way to allow removeable media support? 2) Bourne shell like features in COMMAND.COM (i.e. wild-cards, meta-char..) 3) No more 1024 cylinder restrictions. I know this would be more difficult to do and keep backward compatiblity, but look hard at this. A resonable restriction would be 4096 cylinders, 64 heads, 64 sectors/trk. 4) Support for more than 2 mass storage devices. 5) A complete MS-DOS development system that would include the tools that makes UNIX so nice to develope on (i.e. grep, sed, awk, vi, cut, paste...). 6) A better file system, that would allow unlimited partition sizes. I know this would break some things, but make how about the option anyway. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {texbell,attctc}!cpe!adaptex!neese merch!adaptex!neese uunet!swbatl!texbell!merch!adaptex!neese
bmarsh@cod.NOSC.MIL (William C. Marsh) (03/28/90)
In article <260E5E5A.5404@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: $In article <246@edpmgt.UUCP> gpitcher@edpmgt.UUCP (Glenn Pitcher) writes: $$Couldn't the shell be altered to intercept those directory requests and $$remap the characters before the actual open (or whatever) command is issued? $ $ If you alter the shell, this would only affect commands issued from the $shell. Pathnames entered within applications would still require the use $of the \ regardless of what you set. These utilities are broken! DOS has always accepted '/' and '\' for directory separators during DOS calls. $ Changing the path separator, however, could be implemented as a DOS $call so that changes would be universal. It is now. Actually, what is implemented is the 'switch' character, which the applications look for the switch character to indicate options. Unfortunatly, It's just that fewer and fewer of the DOS utilities look anymore... -- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
sbanner1@uvicctr.UVic.CA.UUCP (S. John Banner) (03/28/90)
>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!) Definitely a big problem, but if the DOS utilities started using it, the others would follow pretty quick. You don't have to try fixing things in a way that non-DOS (i.e. programs that come with DOS) programs understand (beyond the current undocumented call), just make that undocumented call that everyone uses actually work, and make the DOS utilities use the UNIX standard. >>Have you considered using the PROMPT command to remap those two keys? Don't do it, it's not worth the hastle. Annother request that came in here somewhere that I will certainly add my vote for is real wild cards. This is the single biggest defisioncy that DOS has ever had (IMHO anyhow). >>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. Yep, this would be a good one. >>6) The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file. Yep, nice and fairly easy to impliment. >>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. Difficult yes, but not that hard. Use 32Bits for the length of a memory block (no more worse on compatability than the FAT change in DOS4.00), and have an Extended Allocate Memory function that will return an extended segment address (giving preference to memory beyond the first Meg), and all the current programs run just fine, and new programs can use as much as the longest available segment. As for relocating DOS, that doesn't have to happen, because you can just mark the ``memory block'' from A000:0000-F000:FFFF, as used, and every one is happy. >>8) 32-bit operating system. Hooks for future 64-bit. Get serious folks, I know I don't want to be using DOS37 in the year 2000. Just update it so that it is still usefull, as there are still lots of people for whom it is the best alternative due to the hardware they have. Just work on phasing DOS out, while phasing in a real OS (no, not OS/2; I would be happy with UNIX myself, but I don't expect to see that one do it either). >>10) Verified deletes. Branch deletes. Move files without copying. >YES! How hard can it be to manipulate directory entries?? Yep, definitely a good one. >>12) Windows built in. >Who could argue with that? I could. That's why I refuse to by a Mac. Don't do it. >>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...) Yep, that would be usefull. >>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! Yep, real nice. >>16) Virtual memory management. >Indeed! Why not? Indeed, if you have access to the full memory (see above), it shouldn't be THAT much harder to add, though maybe as a device driver would be sufficent... >>Gee, maybe I should try Unix or a Mac. 8-) I plan on using Unix, just as soon as I can afford my own Unix box, but as I said above, I would rather spend my life writing software for a 256K, 4.77Mhz IBM 3270/XT (if you have never used one, you don't know the meaning of a slow IBM/PC yet), using MicroSoft C5.1 than have to use a Mac for a significant portion of my work (Oh, No, I think my biases are peeking through :-). But seriously folks, that is one of the biggest advantages of the PC, over the Mac. If you don't like COMMAND.COM, you can always write/buy a replacement, and use that instead, whereas on the Mac you are pretty much tied to that hideous mouse. S. John Banner ccsjb@uvvm.UVic.CA ccsjb@uvvm.bitnet ...!uw-beaver!uvicctr!sol!sbanner1 ...!ubc-vision!uvicctr!sol!sbanner1
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/28/90)
In article <18888@boulder.Colorado.EDU> scholes@boulder.Colorado.EDU (SCHOLES MARTIN LEE) writes: > > Ok, here's another nice option that UNIX has, and I wish DOS had... >Command line filename expansion. Let DOS put the file names on the command >line with all of the wonderfull regular expressions of UNIX, like >del filever.00[123] that would be nice. Marty No, please don't! There would go the possibility of positional parameters for commands, and we'd be stuck with Unix-style ugly option switches. We'd lose the knowledge of what the user actually typed, and get stuck with all the horrible escape sequences you have to use in Unix shells just to type special characters in a command. What would be nice is if the Find First and Find Next services could support more patterns in filenames. Just don't go messing with the command line. Duncan Murdoch
jcb2647@cec1.wustl.edu (James Christopher Beard) (03/28/90)
I think the first step in upgrading DOS is to add the things that innumerable programmers have added one by one on their own as TSR's. 4DOS, a replacement command processor from J.P. Software, incorporates most of these fixes in one place, including - command-line editing combined with command histories (in a far more useful form than unix's c-shell provides), - aliases (with replaceable parameters and environment variables), - command completion, - file selection from command-line wildcards (something sh and csh don't have in anything like as useful a form) - built-in help - batch file enhancements like IFF...ENDIFF, GOSUB, INPUT, INKEY, ... (Note that MS's WHAT command, included as a demo with some past versions of MASM, provides some of the system information and user-input features that batch files need and 4DOS supplies.) - LOCAL and ENDLOCAL commands to allow explicit differentiation of child environments without launching child shells. I've probably left some out. Note that 4DOS includes many Unix shell features, often in a more-usable form. But one thing that DOS/4DOS batch files sadly lack is the ability to capture standard output of a command in an expression, as in csh lines using the `...` construct. This is enormously useful, and there's simply no DOS work-around that reproduces it. (Almost as good would be an ability to redirect standard output to the value of an environment variable.) Jamie Beard (beard@wuibc2.wustl.edu)
jsulliva@cvbnet.UUCP (Jeff Sullivan, x4096 MS 4-2) (03/28/90)
Dear Microsoft,
Let me preface my list by saying that (before PC's), I started
out on VMS, then worked primarily on DOS. In my career, I have since
worked on Macs and now (mainly) Unix. My home '386 PC runs DOS (4.01)
and will continue to run DOS until Unix becomes more affordable.
I wouldn't expect the new DOS to ever have the ease-of-use of the
Mac, not the power of Unix (and I won't complain about either). DOS is
DOS and what I would like to see is a better DOS.
As I compiled this list, I kept saying "4DOS does that!". So, my
first suggestion is to take a look at 4DOS, as was suggested in PC Mag's
recent Technical Excelence award write-up. FYI, 4DOS is a shareware
COMMAND.COM replacement with which I have no affiliation.
Anyway, in order of my own preference:
- aliases (builtin)
Like Unix (or 4DOS). alias and unalias commands.
- command history & command editing (builtin)
I use dosedit, but I like Unix csh (c-shell) better.
- the ability to link files
I have several copies on my disk that should be links.
I'd like to see a Unix-like 'ln' utility.
- ability to load in extended/expanded memory
To save on conventional RAM.
- ability to use "/" as directory delimiter and "-" as option delimeter.
What can I say, a lot of Unix people complain!
- pushd, popd (builtin)
Great for batch files!
- increase size of valid command strings and PATH.
Link lines constantly exceed the character limit for DOS commands.
- a competent text editor
Why not bundle the one that comes with MSC (ME?) ?
Unix provides 'vi', and although I don't use it, I can get by.
I couldn't even use EDLIN to edit the AUTOEXEC.BAT even if I needed to!
- filename completion.
A press of ESC or F9 to complete or scroll thru completed filenames.
- password protection
And "home directories".
- include Unix-like utilities (grep, diff, sed)
Luckily, those exist in the public domain. All developers need grep!
- improve MORE
I rewrote my own in a day to handle wildcards and tee's.
- turn off sounds (beeps/games) altogether using an environment variable.
Something like SET NOBEEP in your AUTOEXEC.BAT.
- screen saver (builtin)
I'd like to see random shapes/colors, but would welcome a simple blanker.
- memory mapper
Something like PCTools MI (graphical a plus!).
- better file browser (builtin)
Like 4DOS or Vern Beurg's LIST would be nice.
- script utility
Start up a script to save all interactions to a file. Just like Unix.
Thanks for listening, I hope it helps (us all)!
Jeff Sullivan / Computervision/Prime \ {decvax|linus|sun}!cvbnet!jsulliva
CADDS R&D / Bedford, MA 01730 \ jsulliva@cvbnet.prime.com
MSDOS_input_reply
Jeff Sullivan / Computervision/Prime \ {decvax|linus|sun}!cvbnet!jsulliva
CADDS R&D / Bedford, MA 01730 \ jsulliva@cvbnet.prime.comben@val.com (Ben Thornton) (03/28/90)
smw@maxwell.Concordia.CA ( Steven Winikoff ) writes: >>9) An OS where developers don't have to cheat to get decent performance. Or, perhaps more importantly, how about an OS that DOCUMENTS EVERYTHING. so that programmers don't HAVE to cheat... >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...) Or perhaps use XTREE as a guideline... >>16) Virtual memory management. >Indeed! Why not? Definitely! Oh and how about adding a simple scheduler that could manage multiple tasks that live in EMM? Like QEMM? >>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... Aye, there's the rub... -- Ben Thornton packet: WD5HLS @ KB5PM Internet: ben@val.com Video Associates Labs uucp: ...!cs.utexas.edu!val!ben Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
richard@calvin.spp.cornell.edu (Richard Brittain) (03/28/90)
In article <1990Mar27.184657.12589@cec1.wustl.edu> jcb2647@cec2.UUCP (James Christopher Beard) writes: >I think the first step in upgrading DOS is to add the things that >innumerable programmers have added one by one on their own as TSR's. >4DOS, a replacement command processor from J.P. Software, incorporates >most of these fixes in one place, including ............ >I've probably left some out. Note that 4DOS includes many Unix shell >features, often in a more-usable form. But one thing that DOS/4DOS >batch files sadly lack is the ability to capture standard output of a >command in an expression, as in csh lines using the `...` construct. >This is enormously useful, and there's simply no DOS work-around that >reproduces it. (Almost as good would be an ability to redirect >standard output to the value of an environment variable.) The INPUT command reads stdin, and therefore can be used to do this. It isn't all that `command` is, but can still be very useful. If stdin is more than 1 line, only the first line is written into the variable. e.g., if 4DOS did not have %_CWD, you could always get it with cd | input %%cwd Point %tmp at a ram disk, and the above involves no disk activity. I use it to get the switch char and force it to a known state - or else you cannot use setdos reliably. (switch just writes the switchar to stdout). switch | input %%switchar setdos %switchar%W- Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard
richard@calvin.spp.cornell.edu (Richard Brittain) (03/28/90)
In article <1828@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >In article <18888@boulder.Colorado.EDU> scholes@boulder.Colorado.EDU (SCHOLES MARTIN LEE) writes: >> >> Ok, here's another nice option that UNIX has, and I wish DOS had... >>Command line filename expansion. Let DOS put the file names on the command >>line with all of the wonderfull regular expressions of UNIX, like > >No, please don't! ........ ............. >What would be nice is if the Find First and Find Next services could support >more patterns in filenames. Just don't go messing with the command line. Check out the WILDUNIX program posted to cbip last year sometime. It is TSR that traps findfirst and findnext and does the Right Thing. Unfortunately, it confuses WordPerfect for some reason I never figured out. Everything else seems to work with it. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard
jmerrill@jarthur.Claremont.EDU (Confusion Reigns) (03/28/90)
In article <1990Mar28.010044.5653@val.com> ben@val.com (Ben Thornton) writes: >>>16) Virtual memory management. >>Indeed! Why not? > >Definitely! I have heard second-hand from someone at Microsoft that Windows/386 3.0 will have demand-paged memory; i.e. if you need more memory, and there's some that you haven't used in a while (such as the command processor you used to load Windows), it will get swapped to disk. -- Jason Merrill jmerrill@jarthur.claremont.edu DISCLAIMER: Of course, I could be wrong.
ean@gvlv3.gvl.unisys.com (Ed Naratil) (03/28/90)
Having had to use UNIX, MS-DOS, PC-DOS, CTOS, and BTOS operating systems, I would like those users who want to see more UNIX type commands added to DOS go completely UNIX and leave DOS out of it! --- Ed Naratil (All standard disclaimers apply) AMPR: W3BNR@N3LA.#EPA.PA.USA.NA ean@gvlv3.gvl.unisys.com
schrader@loligo (Dave Schrader) (03/28/90)
I am unable to reach the original base note author via EMail (if someone wants to forward this to him I would appreciate it...). I would like to see DOS become fully reentrant. That could solve a lot of problems for a lot of people (me included...). DFSchrader Florida State University Computing Center (Standard Disclaimer applies)
jcmorris@mwunix.mitre.org (Joe Morris) (03/29/90)
>Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. I've never met a programmer who >didn't think that they could have "done it better" with regards to someone >else's product, so here's an opportunity to enlighten us. - A defined mechanism for unhooking chains of stolen interrupts. IBM had this problem years ago with the (IBM-provided) "Service Aid" utilities for OS/360, and developed a procedure which allowed an interrupt stealer to back out of the interrupt chain even if a later program had stolen the same interrupt. - Along the same line, permit a multiplex-interrupt TSR to disappear. The most flagrant problem-causer is the CD-ROM Extensions, which occupies a huge amount of memory. Users who work hard at it have reported success at evicting MSCDEX from memory, but can't seem to get it to reinstall if they need it again later. (Of course, a reboot fixes that problem.) - Command aliasing and directory linking a la UNIX (tm and all that) - A way for users to select different CONFIG.SYS files at boot time. It took me about 60 bytes of patching in IBMBIO.COM to do this... - Disk volume-level read-only status. - User-installed exits from the system at interesting points. This would allow a user to intercept a command (e.g., 'foobar') and see if it should be given special treatment, such as invoking Mansfield's REXX interpreter instead of being limited to .bat, .com, or .exe modules. Also, permit the exit to be established and withdrawn as necessary without having to reboot the system: this would allow applications to have specialized front ends without requiring CONFIG.SYS changes. - Provide a way to load and unload device drivers as required without a reboot. - Provide complete documentation as part of the basic package. (Try finding the command documentation in the PC-DOS 4.0 package.) This should include admitting to last-minute changes. When was the last time you saw IBM ship a README file? Also, make sure that the outside of the package clearly shows the release and maintenance level of the product inside, such as DOS 4.0 vs. 4.01. - Document *all* the control blocks (and paths to them) which can be reasonably expected to be of use to customers. Even if the control blocks may be altered in future releases, users deserve to be given the information they need for today's systems. The decision to access a control block which may change its format in the next release should be the user's, not the vendor's. Example: where is the Microsoft or IBM documentation on how to find the device driver chain? - Be prepared to admit that a problem exists with the product. While Microsoft sometimes seems to take far too long to fix problems, you can get their support people to agree that you have found a bug. It's almost impossible to get IBM to admit that problems exist with DOS. Boca: that's a HINT! - At the risk of being thrown out of c.s.i.p, vendors should take a clue from Apple's Macintosh line and bundle DOS with the hardware, with updates available to anyone who has a bundled system. If they won't do this, at least provide a public mechanism for obtaining bug lists and patches. Joe
smw@maxwell.Concordia.CA ( Steven M. Winikoff) (03/29/90)
> = cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) >> = smw@maxwell.Concordia.CA ( Steven Winikoff ) ----------------------------------------------------- >> ...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.) > The reason is that you can't find out what path you were executed from > unless you're using DOS 3 or better. Of course, this is no excuse for > being too lazy to add code to check for DOS 3 and, if so, keep track of > where you were invoked from ... Ah, but that's the point. It doesn't really matter whether the software in question is so old that it wasn't possible to handle directories at the time (in fact WordStar 3.3 was written before MS-DOS even *had* subdirectories, if my memory is correct...), or if it's simply a question of laziness on the part of the programmer. It's still a nuisance to use software that, in today's terms, is brain-damaged. It would simply be nice, IMHO, if the OS could be rewritten to make the problem go away. >>> 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? > No it wouldn't ... except that then users would expect that they could >pass a huge command line to an external command and would start complaining >of a bug in DOS. Ouch. There's no such thing as a perfect world, is there? > Moving files without copying, for example, has been part of the DOS > RENAME function call since the idea of paths came along. It's just that > COMMAND.COM's designers decided they didn't want us to be able to do that. Sure. Changing that now, however, couldn't be particularly difficult, and would certainly be upward compatible! >>> 12) Windows built in. >> Who could argue with that? > As long as I'm allowed to wipe it off my hard drive and it doesn't > increase the price of DOS, I don't mind. But I don't want to be forced > to pay for it and have it clutter up my memory and hard disk and degrade > system performance just because I may want a new version of DOS. That's basically what I had in mind myself. Of course, the original idea came from Marshall Buhl, and I can't presume to speak for him. >> 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...) > Most of those really aren't hard to write ... the only reason people > are so thrilled with many of them is that Norton did them right, and DOS > either didn't do them, did them wrong, or did them far too late. Writing > a program like FA would take an experienced programmer a couple of hours. Of course... but who wants to keep reinventing the wheel? > But you do have a good point. Microsoft should have a close look at > the features of various toolkit packages, make a note of some of the things > they do, and write their own to do those functions. That's exactly what I'm hoping for. I've even written similar things myself. But the point is that it would be nice to have these utilities centralized in the OS, rather than have to carry a box of diskettes with me whenever I'm asked to help out a friend (or a client!) who doesn't happen to have my own idea of the "perfect" utility set! ------------------------------------------------------------------------ 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)
lance@helios.ucsc.edu (Lance Bresee) (03/29/90)
In article <1640088@hpspcoi.HP.COM> dlow@hpspcoi.HP.COM (Danny Low) writes: >Writing as a user, what I most want is make the resident portion of >MSDOS SMALLER! I installed 4.01 and lost 32K of RAM! This was a duplicate >of my existing 3.3 configuration with none of the >selectable extra features of 4.01. Half the programs It would REALLY be nice to be able to load DOS into other memory locations, like the D and E pages, or better yet, to the upper half of the F page, so that you could put it in an EPROM and forget about it entirely. I'd also like to see a stripped down version with all utilities but the file handling being disk based, so you could replace them singly without having to load a shell and lose EVEN MORE MEMORY!!!!! lance
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/29/90)
In article <26909@ut-emx.UUCP> boerner@ut-emx.UUCP (Brendan B. Boerner) writes:
$2) A TSR Manager. Programs written to use it would let it know what
$resources that they need (e.g. what interupts they would like to be
$activated on). [...]
This is a nice idea, but it's a bit late to retrofit DOS with a TSR
manager. Think about how many TSRs there are out there - even if all
TSR makers switched to using this immediately, the number of older
TSRs would far outnumber those newer ones for years.
Also, in order to use this, a TSR writer would either have to write
two different versions of his/her TSR (since obviously an old-style one
would be required for older DOS versions), or have a larger TSR that
auto-detects what DOS version you have. Remember, there are still some
of people using DOS 2 out there, six years or so after DOS 3 came out,
and the same will apply for any newer DOS versions.
$6) A larger command line limit. This would allow paths with length
$greater than 128 chars.
This would be nice ... but it would be internal to DOS. The command line
passed to programs is found in the PSP, which has been the same size since
day 1. The only way around this would be to have DOS put the command line
in two places - one being the PSP, for backwards compatibility, and the
other being ... where? It can't be static because then it would be over-
written if you shelled out from your program and ran something else.
--
More half-baked ideas from the oven of:
****************************************************************************
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate ... for now!\n";dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/29/90)
In article <2032@clyde.concordia.ca> smw@maxwell.Concordia.CA ( Steven M. Winikoff) writes: > >That's exactly what I'm hoping for. I've even written similar things myself. >But the point is that it would be nice to have these utilities centralized >in the OS, rather than have to carry a box of diskettes with me whenever I'm >asked to help out a friend (or a client!) who doesn't happen to have my own >idea of the "perfect" utility set! You seem to be assuming that DOS 5 (or whatever this new one is named) is going to be instantly universally installed. But take a look at DOS 4: I'd guess that only about half the new machines being sold now come with it; very few people have upgraded existing machines beyond 3.x. You're going to be stuck with your box of diskettes for a long time, even if Microsoft puts all of the Norton Utilities and 4DOS into the new one. (Unless, of course, they price it low it enough.) Duncan Murdoch
marshall@wind55.seri.gov (Marshall L. Buhl) (03/29/90)
smw@maxwell.Concordia.CA ( Steven M. Winikoff) writes: >> = cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) >>> = smw@maxwell.Concordia.CA ( Steven Winikoff ) >>>> 12) Windows built in. >>> Who could argue with that? >> As long as I'm allowed to wipe it off my hard drive and it doesn't >> increase the price of DOS, I don't mind. But I don't want to be forced >> to pay for it and have it clutter up my memory and hard disk and degrade >> system performance just because I may want a new version of DOS. >That's basically what I had in mind myself. Of course, the original idea >came from Marshall Buhl, and I can't presume to speak for him. I have it on good authority that that's exactly what Marshall meant. If DOS comes standard with Windows, then more people will write software to support it. Keep in mind that I mean a GOOD version of Windows - not that garbage they've been selling for the last year or so. Still waiting for version 3. You may not remember the caveat I put at the end of my original follow-up, but I said I wanted all those things IF it did'nt cost more money or base RAM. As far as disk storage goes, what can be worse than Unix? The current version of Windows doesn't eat up more than a few MB. I'm probably wrong, but I guess that most of the people who will spend the money on DOS upgrades also can afford a decent hard disk. Anyway, Stephen, I would want it to be like the Shell that comes with DOS 4 - an option at install time. Marshall PS. I'm going on a two week brain wipe at the end of the week, so you folks will have one fewer overly-opinionated netter to deal with. If I'm successful, I probably won't even remember the net when I get back. PPS. I hope the original poster is taking good notes - I'd like a copy of the new "DOS Requirements Document" when I get back. -- 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
scholes@boulder.Colorado.EDU (SCHOLES MARTIN LEE) (03/29/90)
In article <592@gvlv2.GVL.Unisys.COM> ean@gvlv3.gvl.unisys.com (Ed Naratil) writes: >Having had to use UNIX, MS-DOS, PC-DOS, CTOS, and BTOS operating >systems, I would like those users who want to see more UNIX type >commands added to DOS go completely UNIX and leave DOS out of it! Interesting idea, but... I learned MS-DOS first, then fell in love with UNIX. It so happens that the bigger market for software is in MSDOS, not UNIX. I can't move the market to UNIX, but here is the opportunity for me to help make DOS more UNIX-like. If DOS users don't like the UNIX extensions, then they shouldn't use them. The rest of us, however, can use them. Marty
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/29/90)
In article <1990Mar28.200515.26593@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: >>>>> 12) Windows built in. > >I have it on good authority that that's exactly what Marshall meant. If >DOS comes standard with Windows, then more people will write software to >support it. Keep in mind that I mean a GOOD version of Windows - not that >garbage they've been selling for the last year or so. Still waiting for >version 3. I sincerely hope Microsoft will take a few moments to rethink their risky position market-wise. I have become more and more aware lately how much the Macintosh is becoming the PC of choice for all those users who want their computer to be a tool and not a hobby. I have a modest proposal to make: Microsoft should bundle Windows 3.0 with every copy of MS-DOS, and without raising the price. The first effect that this would have is to get users interested in using Windows. The next effect would be to get developers interested in developing software for Windows. The next effect would be that some of those customers that have been leaning towards the Mac would reconsider the PC world. The next proposal would be to provide a modern language with DOS that includes a Windows library. The effect of this would be to encourage more programmers and students to produce Windows software. It doesn't have to be an elaborate language. I'm thinking of GEM which had Basic-2 or something like that which could do GEM graphics (I believe that one was available in the UK, and wasn't bundled with GEM...). The big reason there isn't more interest in Windows software development right now is the cost of the SDK. As far as I know, only Actors provides the capability of writing Windows programs without buying the SDK. I am quite sure that Microsoft could do this if they wanted to. And they could price it under $100 if they wanted to. Look at the NeXT. It has software bundled with it that for any other system would cost the price of a NeXT. Even the Mac has HyperCard. Nobody is going to make anyone believe that Microsoft has to charge the prices they do in order to stay in business. They have the PC market in a stranglehold, and are pretty blase' about it. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/29/90)
In article <261106AB.2583@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > >$6) A larger command line limit. This would allow paths with length >$greater than 128 chars. > > This would be nice ... but it would be internal to DOS. The command line >passed to programs is found in the PSP, which has been the same size since >day 1. The only way around this would be to have DOS put the command line >in two places - one being the PSP, for backwards compatibility, and the >other being ... where? It can't be static because then it would be over- >written if you shelled out from your program and ran something else. A natural spot would be in the environment segment, just after the name of the currently executing program. Duncan Murdoch
richard@calvin.spp.cornell.edu (Richard Brittain) (03/29/90)
In article <261106AB.2583@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: >In article <26909@ut-emx.UUCP> boerner@ut-emx.UUCP (Brendan B. Boerner) writes: >$2) A TSR Manager. Programs written to use it would let it know what >$resources that they need (e.g. what interupts they would like to be >$activated on). [...] > > This is a nice idea, but it's a bit late to retrofit DOS with a TSR >manager. Think about how many TSRs there are out there - even if all >TSR makers switched to using this immediately, the number of older >TSRs would far outnumber those newer ones for years. This is obviously going to be true for all enhancements. If we think like this, then there really isn't much point in bothering. There are lots of things that could have been done a long time ago, before such a large base of software invented incompatible ways of doing the job, but that is no reason not to improve on things. >$6) A larger command line limit. This would allow paths with length >$greater than 128 chars. > > This would be nice ... but it would be internal to DOS. The command line >passed to programs is found in the PSP, which has been the same size since >day 1. The only way around this would be to have DOS put the command line >in two places - one being the PSP, for backwards compatibility, and the >other being ... where? It can't be static because then it would be over- >written if you shelled out from your program and ran something else. This doesn't sound so hard - the program loader allocates a memory block for the command line - as long as needed, then makes the PSP. Put the first 127 bytes in there as normal for old programs, and put the segment address of the argument block somewhere else in the PSP (there are still some "reserved" words I think). When the program terminates, the shell, or the program terminate service deallocates the argument block. I presume that something like this has to be done in unix ?. The startup code for DOS-5-aware programs reads the new argument block when building the argv array, or whatever your favourite language provides. Compiler vendors would have to ship a new startup object module - no big deal. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard
bcw@rti.rti.org (Bruce Wright) (03/29/90)
In article <26909@ut-emx.UUCP>, boerner@ut-emx.UUCP (Brendan B. Boerner) writes: > Here are a couple of things I wouldn't mind seeing in a new version of > MS-DOS. I realize some have already been mentioned but I thought I'd > send the whole list as is anyway. > > 1) The ability to load/unload device drivers at any time - not just > during the boot process. Sorta like Novell's Netware Loadable Modules > on NetWare/386. In general you can't do this, though if a driver is specifically written to be unloadable it's possible. Sometimes (maybe on the PC environment most of the time) you can unload a driver that wasn't written to be that way, but it's sort of an accident of the hardware/software environment if that's the case. Unfortunately the first time you find out about a problem with something like that is when your machine crashes or wipes out your disk or something, so it's not particularly recommended. > 2) A TSR Manager. Programs written to use it would let it know what > resources that they need (e.g. what interupts they would like to be > activated on). It would keep track of what program uses what > interrupts so if a call were made to unload a TSR, it would be able to > unload it without affecting others in the chain. Again, to do this right requires cooperation from the TSR's. Though you can get a fairly high percentage by just restoring the interrupt vectors in low RAM, there's always the possibility of other hardware or software modifications that might have been made. It wouldn't be practical to save the entire machine state before each TSR (!) > 3) A file system which supports symbolic links > > 4) Rename (or move) across directories within the same volumne > > 5) A better wildcard capability. Dir *X.* would display files ending > with X, with any extension, not all files. All of these would be nice, and would be quite implementable, though the first one would require some modifications to the disk structure (not the first time that's happened though). I've never understood why problem #4 exists, and problem #5 is essentially a crock that got carried over from CP/M (and should have been left there, IMHO). > 6) A larger command line limit. This would allow paths with length > greater than 128 chars. You might be able to make a special case for the PATH and SET commands (or possibly for all internal DOS commands), but in general this is not possible without introducing incompatibilities, which Microsoft is not likely to do. None of the programs that currently use command lines would be able to work after this kind of change!! It would be nice to allow the PATH to get longer somehow; although the performance resulting from such a long PATH isn't very good, it's sometimes helpful to do it temporarily. There is, of course, the possibility that some programs copy the PATH into a fixed-size variable and allowing PATH to grow that large could cause problems (though obviously only if you actually set it that large). Fortunately, I think such programs are probably fairly rare. Bruce C. Wright
georgf@polari.UUCP (George Forsman) (03/29/90)
In article <25100009@adaptex> neese@adaptex.UUCP writes: > >>Microsoft is working on a major upgrade to DOS and I'd like to solicit >>input from the "power user" communitiy. I've never met a programmer who >>didn't think that they could have "done it better" with regards to someone >>else's product, so here's an opportunity to enlighten us. > >1) A more flexible way to allow removeable media support? >2) Bourne shell like features in COMMAND.COM (i.e. wild-cards, meta-char..) Yes, this would be nice. >3) No more 1024 cylinder restrictions. I know this would be more difficult > to do and keep backward compatiblity, but look hard at this. A > resonable restriction would be 4096 cylinders, 64 heads, 64 sectors/trk. The restriction exists in the IBM PC bios and has been propogated to new BIOSs (DOS also inherits the problem). Removing the 1024 cylinder restriction in DOS will not help most machines, and may even cause serious problems. (To see the problem, look at a Partition table description, only 10 bits are allowed for the cylinder. Since the partition table is interpreted by the BIOS, a change in BIOS operation is needed for it to work.) The typical solution to this problem is to get a controller card that does it's own virtual track mapping so that the BIOS and DOS see the drive as having less than 1024 cylinders. >4) Support for more than 2 mass storage devices. As far as I know, MS-DOS will support as many drives as the ROM BIOS will support. I have not had any personal experience with more than two physical drives, but I have been told that DOS already does this. >5) A complete MS-DOS development system that would include the tools that makes > UNIX so nice to develope on (i.e. grep, sed, awk, vi, cut, paste...). This could be part of a "developer package" offered as an option. Remember that MS-DOS is used by lots of "end-users" who would not have need for these tools Unix systems are a little different in that users and administrators share the same system. This is not to say the Microsoft should go as far as IBM and remove things like EXE2BIN, LINK, etc. from the DOS disks and only offer them with the programmer's reference. >6) A better file system, that would allow unlimited partition sizes. I know > this would break some things, but make how about the option anyway. Better file system, yes! HPFS for DOS would be really neat, even thought there might not be any memory left after it was activated. "Unlimited partition size?" how about 2gig? DOS version 4.0 has this already. (And yes, it does break things, but not as many as you might expect) > > Roy Neese > Adaptec Central Field Applications Engineer George Forsman ...uw-beaver!sumax!polari!georgf "Only 15 miles from Microsoft!"
eichi@forty2.UUCP (Stefan Eichenberger) (03/29/90)
In article <154@cvbnetPrime.COM> jsulliva@cvbnet.UUCP (Jeff Sullivan, x4096 MS 4-2) writes: (List of many desired features of newer DOS (command interpreters) deleted) >- pushd, popd (builtin) > Great for batch files! Yes, but then, why not bundel it with dirs and the ability to pop into any directory on the stack - rather than the last one you pushed from, as 4DOS does (or is their release 3.0 better in this regard?) Anyhow, this is also a hint for the 4DOS people. -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!eichi Stefan Eichenberger BITNET: K807817@CZHRZU1A University of Zurich ----------------------------------------------------------------------------
baird@cod.NOSC.MIL (John M. Baird) (03/30/90)
In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: > Please note that the DOS operating system has to remain "DOS" in the sense > that Microsoft already has a strategy for a high end OS which requires that > programs be rewritten I previously mailed this directly to Mr. Letwin, but since no one else has mentioned them on the net, I am posting them for discussion. John Baird, Naval Ocean Systems Center, San Diego, CA USA Wish list things: 1. User configurable KEYBOARD.SYS to handle oddball keyboards. As an example of how to set it up, include a DVORAK configuration. This could also provide a standard way to switch control and caps-lock keys, Escape and ~ keys, etc, etc. and get rid of the hundreds of small TSR programs that people have written to do these things. Additionally, although this is going much farther, it could be used to program keyboard input, replacing the awkward PROMPT and escape sequences mess. 2. User configurable determination of what the internal DOS commands are. If someone wants to use their own DIR or COPY instead of the internal command, let them do it without having to patch COMMAND.COM 3. Improve the functionality of ANSI.SYS, so that NANSI.SYS, ZANSI.SYS, etc. are not needed. Hopefully, this would include cursor configurability (size, blink/no-blink) and border screen color control.
chuck@eng.umd.edu (Chuck Harris) (03/30/90)
Dear Microsoft, These are a few things I would like to see in dos: 1) a 'mv' command that works like unix (easy to do, I did it years ago). 2) a 'rm' command that can do rm -[irf] (eg kill a directory and everything in it, and prompt individual deletions if desired.) If you must ask questions on a *.* deletion, make an environment variable that will turn them off. 3) a 'more' that takes file names as well as stdin (easy to do, I did it too) 4) gimme 'ls' and don't calculate the disk size unless I ask for it...It takes too long. 5) Use the switchar function in all of your utilities so I can stop smacking myself on the side of the head when I slip into 'unix' thinking while I am in dos (eg. using '/' instead of '\'). Bill Gates in effect gave all the professional programmers in the world the finger when he allowed '\' to be the path separator, and '/' to be the option switch. 6) command lines longer than 128 chars (difficult I know). A keybuffer that is humungous would be nice too 15 chars is a joke (a rather bad one at that). 7) 'chmod' that knows about hidden files too (easy to do, we all did it). 8) DUMP EDLIN!!! nobody I know can use it. Me I'm old enough to figure it out but still can't use it reliably. Why not license JOVE? (an emacs like editor that works great on pc's. 9) put a little help in your commands so that when I screw up the arguments and the command knows it, it will prompt me like unix does. (eg. "ls -[aslRtc] [file] ...") 10)Is it really too late to fix wildcards so that they work correctly? The first time I typed DEL *r*.c and wiped my directory of all c programs, I almost died. (so did my PC!). 11)What about a way of setting screen and text colors that doesn't require the ansi.sys abortion? 12)What about fixing the ansi.sys abortion? If you need an example, go talk to Hershey Micro Consulting about FANSI-Console. 13)Oh yeah, how about moving all of the commands out of command.com, and onto disk. Most of your audience has discovered the harddisk, and we sure could use the ram space they would release. 14)Fix CHKDSK so that it understands the JOIN command, and checks ALL of the disks rather than quitting when it finds a joined directory. It is a real pain to have to go down to root, and un-join my disks, then run chkdsk, and then re-join everything. 15)Fix JOIN so that it can join disks to directories other than those at root. 16)Loooong paths would be nice too. 17)history like is done in kornshell would be nice. 18)alias strings would be great! as long as you can un-alias them on the fly. Well, that should be enough to keep you busy into the 21th century. Thanks for listening. Chuck Harris C.F. Harris - Consulting
andy@mks.com (Andy Toy) (03/30/90)
In article <1828@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >In article <18888@boulder.Colorado.EDU> scholes@boulder.Colorado.EDU (SCHOLES MARTIN LEE) writes: >>Command line filename expansion. Let DOS put the file names on the command >>line with all of the wonderfull regular expressions of UNIX, like >>del filever.00[123] that would be nice. Marty >We'd lose the knowledge of what the user actually typed, and >get stuck with all the horrible escape sequences you have to use in >Unix shells just to type special characters in a command. What escape sequences? Just put quotes around the argument or "set noglob" for csh or "set -o noglob" for ksh to prevent the shell from expanding the command-line arguments. These are all shell features and I can't think of a reason why Microsoft could not have more than one shell. Leave command.com the way it is and provide another shell in addition to command.com or provide better support in DOS for third party shells. -- Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519-884-2251 FAX: 519-884-8861
ulmer@plains.UUCP (Saltine Cracker) (03/30/90)
Dear MicroSoft,
Please ignore all requests to scrap Edlin from your Dos versions.
-Thank You,
Me.dhinds@portia.Stanford.EDU (David Hinds) (03/30/90)
Sorry, I've completely lost track of the start of this thread, and I don't know where we're supposed to be sending these suggestions. Can anyone post the E-mail address of the Microsoft rep. again? -David Hinds dhinds@popserver.stanford.edu
wallwey@boulder.Colorado.EDU (WALLWEY DEAN WILLIAM) (03/30/90)
In article <1990Mar29.165634.1267@eng.umd.edu> chuck@eng.umd.edu (Chuck Harris) writes: >Dear Microsoft, >..... >8) DUMP EDLIN!!! nobody I know can use it. Me I'm old enough to figure it out > but still can't use it reliably. Why not license JOVE? (an emacs like > editor that works great on pc's. >....... > C.F. Harris - Consulting EDLIN is horrible, but don't get rid of it! It's still great for editing 5 line files and the such. The other thing that is great about it is I can go anywhere, on anybodies pc, and if I have to edit something small, I KNOW I can use EDLIN. Its simple and quick. We do need a new standard "real "editor also--I think this was the main point--to be included in the standard operating system. My two cents worth... Dean Wallwey
marshall@wind55.seri.gov (Marshall L. Buhl) (03/30/90)
georgf@polari.UUCP (George Forsman) writes: >"Unlimited partition size?" how about 2gig? DOS version 4.0 has this >already. (And yes, it does break things, but not as many as you might expect) I would be upset if they made the partition limit 2 GB. We're seeing 1 GB 5.25" disks now, so 2 GB is fairly close. I've seen ads for WORMs with 2.5 GB on a side. I want something that we won't need to change until the 21st century. If you're going to change something, change it to something that you won't hit anytime soon. I would prefer 1 TB. In case you think I'm crazy to ask for all that space, we regularly take data on wind turbines that generate files that are tens of megabytes. We are working on a PCM based system that will generate 300 MB files. That's THIS year - not 2000. The situation will only get worse. 2 GB just won't cut it for the long haul. -- 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
marshall@wind55.seri.gov (Marshall L. Buhl) (03/30/90)
chuck@eng.umd.edu (Chuck Harris) writes: >Dear Microsoft, > These are a few things I would like to see in dos: >1) a 'mv' command that works like unix (easy to do, I did it years ago). I would prefer one that works BETTER than the *nix one. I want it to work just like XCOPY, but to move instead. I'm no *nix guru, but I know that "mv *.f *.for" does not work. Many times when I use mv, I'm surprised at the result. >2) a 'rm' command that can do rm -[irf] (eg kill a directory and everything > in it, and prompt individual deletions if desired.) > If you must ask questions on a *.* deletion, make an environment variable > that will turn them off. >3) a 'more' that takes file names as well as stdin (easy to do, I did it too) I gave up on more years ago. I use the SEE editor. I almost always want to go back. If I don't, I just use TYPE with ^S/^Q. >4) gimme 'ls' and don't calculate the disk size unless I ask for it...It takes > too long. Get a decent PC. It takes much less than a second on my 300 MB disk. >5) Use the switchar function in all of your utilities so I can stop smacking > myself on the side of the head when I slip into 'unix' thinking while I am > in dos (eg. using '/' instead of '\'). Bill Gates in effect gave all the > professional programmers in the world the finger when he allowed '\' to be > the path separator, and '/' to be the option switch. You mean profession *nix programmers - don't you. It never bothered me and I've been programming since '72. >6) command lines longer than 128 chars (difficult I know). A keybuffer that is > humungous would be nice too 15 chars is a joke (a rather bad one at that). A crime is more like it. >7) 'chmod' that knows about hidden files too (easy to do, we all did it). System files too! >8) DUMP EDLIN!!! nobody I know can use it. Me I'm old enough to figure it out > but still can't use it reliably. Why not license JOVE? (an emacs like > editor that works great on pc's. I don't know JOVE or emacs. Are they easy to learn and use? Can I teach them to a new user in 15 minutes? Are they "modeless", or do you have to "escape" from input mode to move the cursor like vi? Yuck. How pathetic! >9) put a little help in your commands so that when I screw up the arguments > and the command knows it, it will prompt me like unix does. > (eg. "ls -[aslRtc] [file] ...") Wouldn't hurt. While we're at it, how about unreadable online man pages? ;-) >10)Is it really too late to fix wildcards so that they work correctly? The > first time I typed DEL *r*.c and wiped my directory of all c programs, I > almost died. (so did my PC!). Can we sue over this? ;-) >11)What about a way of setting screen and text colors that doesn't require > the ansi.sys abortion? Hear. Hear. >12)What about fixing the ansi.sys abortion? If you need an example, go talk > to Hershey Micro Consulting about FANSI-Console. >13)Oh yeah, how about moving all of the commands out of command.com, and > onto disk. Most of your audience has discovered the harddisk, and we sure > could use the ram space they would release. Make room! Make room! >14)Fix CHKDSK so that it understands the JOIN command, and checks ALL of the > disks rather than quitting when it finds a joined directory. It is a real > pain to have to go down to root, and un-join my disks, then run chkdsk, > and then re-join everything. >15)Fix JOIN so that it can join disks to directories other than those at > root. >16)Loooong paths would be nice too. I prefer the temporary technique for applications. >17)history like is done in kornshell would be nice. You mean you would want to do the same thing more than once? ;-) >18)alias strings would be great! as long as you can un-alias them on the fly. I'll second that. > Well, that should be enough to keep you busy into the 21th century. >Thanks for listening. Great ideas! -- 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
dorsai@pawl.rpi.edu (03/30/90)
>Dear Microsoft, >..... >8) DUMP EDLIN!!! nobody I know can use it. Me I'm old enough to figure it out > but still can't use it reliably. Why not license JOVE? (an emacs like > editor that works great on pc's. >....... > C.F. Harris - Consulting > yes, please dump it! re JOVE... what about vi?!? i have Free Vi 1.9a (c) 1989 by Paul Vojta it's a great little editor for small text files and bat files -- respectfully yours, Gregory D. Moncreaff dorsai@pawl.rpi.edu
weave@sun.acs.udel.edu (Ken Weaverling) (04/02/90)
In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: >Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. I've never met a programmer who >didn't think that they could have "done it better" with regards to someone >else's product, so here's an opportunity to enlighten us. > PLEASE.... strengthen the batch language... including but not limited to... A way to manipulate env vars, like simple math, upper case strings, etc... Better loop controls Subroutines/functions Better conditional expresions I'll take anything! -- Ken Weaverling - Systems Administrator | Internet: weave@sun.acs.udel.edu Delaware Technical & Community College | Voice: +1 302 573 5460
schrader@loligo (Dave Schrader) (04/12/90)
Sorry to bring this topic up again and to post it here rather than EMail to the original poster but I still cannot reach him via EMail. I would like to see all of the MS/PC-DOS versions honor ALL of the file attribute bits. For example, I would like to see DEL check not just the file's ReadOnly/ReadWrite attribute bit but also the Directory's ReadOnly/ ReadWrite bit. Directories can also be made Hidden, ReadOnly, and System type files so why not implement the code to honor those bits. I, personally, would like to put all of the DOS files on a ReadOnly Hidden System directory. Just a thought. David Schrader schrader@loligo.cc.fsu.edu
ckindel@cs.arizona.edu (Charles E. Kindel, Jr. [Tigger]) (04/14/90)
In article <9682@sun.acs.udel.edu>, weave@sun.acs.udel.edu (Ken Weaverling) writes: > In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: > >Microsoft is working on a major upgrade to DOS and I'd like to solicit > >input from the "power user" communitiy. I've never met a programmer who > >didn't think that they could have "done it better" with regards to someone > >else's product, so here's an opportunity to enlighten us. > > > PLEASE.... strengthen the batch language... including but not limited to... > > A way to manipulate env vars, like simple math, upper case strings, etc... > Better loop controls > Subroutines/functions > Better conditional expresions > Gordon, Take a look at 4DOS 3.0 for _the_right_way_ to do a command processor. Another important thing, to me at least, is memory usage. DOS 4.0 is TOO big for me (I still use 3.3). Keep this "major upgrade" small! Glad to see you guys are looking out here.... ;--------------------------------+-----------------------------------; ; ckindel@cs.arizona.edu | Kindlco Software Systems ; ; CIS: 71551,1445 | [KiSS] ; ; Charles E. Kindel, Jr. | "Keeping it Simple, Stupid!" ; ;--------------------------------+-----------------------------------; ; 4225 N. First Ave, Suite 1315, Tucson, AZ, 85719, (602) 887-3359 ; ;--------------------------------------------------------------------;
bradley@cs.utexas.edu (Bradley L. Richards) (04/14/90)
In article <53686@microsoft.UUCP> gordonl@microsoft.UUCP (Gordon LETWIN) writes: >Microsoft is working on a major upgrade to DOS and I'd like to solicit >input from the "power user" communitiy. I've never met a programmer who >didn't think that they could have "done it better" with regards to someone >else's product, so here's an opportunity to enlighten us. > I realize I'm living in a fantasy land, but... How about full support for 80386/486 and true multitasking, but without all the baggage associated with O/S2? --------------------------------------------------------------------------- Bradley L. Richards bradley@cs.utexas.edu Department of Computer Science uucp: cs.utexas.edu!bradley :-) Univ of Texas, Austin, TX 78712 AFIT/CISP, WPAFB, OH 45433 ---------------------------------------------------------------------------
person@plains.UUCP (Brett G. Person) (05/04/90)
How about some way to allow dos to blank the screen? You could include a driver for config.sys, or something. -- Brett G. Person North Dakota State University uunet!plains!person | person@plains.bitnet | person@plains.nodak.edu
schrader@loligo (David F. Schrader) (05/04/90)
In article <4497@plains.UUCP> person@plains.UUCP (Brett G. Person) writes: > >How about some way to allow dos to blank the screen? >You could include a driver for config.sys, or something. >-- >Brett G. Person Amen! Make it a device driver that can be turned off/on by writing to it (like _burndev_) and make it check not just whether keys have been pressed but also whether the serial ports are active (mouse movement, modem usage, and the like) since many of these do direct screen writes without using bios/dos calls. Make it be able to post an user selectable image and move it around to prevent screen burn-in. Or make it call another program (like the one that has exploding fireworks) which is exited upon key/mouse activity. Let it be time adjustable. David