starr@shell.UUCP (10/05/83)
BUGS IN DOS 2.0
From reading the news, it seems that most PC users are using DOS 2.0.
A few bugs have been reported recently.. Let me add a few more.
I wanted to use the environment area to stuff printer configuration
info. It didn't take long to discover that the environment CANNOT be
expanded beyond 128 bytes.
I removed everything from my AUTOEXEC file which terminated and remained
resident (the DOS manual tells you this will prevent environment
expansion). Well, according to the DOS documentation, the IBMDOS and
IBMBIO files load device drivers, which MUST terminate and remain
resident. Thus, your environment can NEVER grow beyond 128 bytes.
Besides, everyone wants to install device drivers, print spoolers, etc.,
all of which terminate and remain resident. How is one supposed to
allocate sufficient space in the environment to anticipate what the
user (or programs the user runs) will require? I would like to be able
to boot and allocate 5K for environment space.
Most of you have probably heard of the bu in the key redefinition routine,
wherein you can only redefine (around) 128 bytes. After that, you begin
writing into some area of memory where you shouldn't ought to write...
no error messages. There is a fix that works in the Sept. PC, pp586-7.
It involves using DEBUG to modify the ANSI.SYS file.
If you wish to execute a program in a different subdirectory than the
on you are currently in, you'd better have a PATH telling DOS how to
get there. You cannot merely say
\c\com\program
This merely causes DOS to give you another prompt.
Has ANYONE been able to get piping or redirection (of input) to work
with a user written program (e.g. myprog < some.file, where myprog is
reading from stdin)? My programs just HANG at the end of the file... a
^Z appears as the last line. (P.S. I use the CiC86 compiler).
Batch (.BAT) files cannot be nested. I don't recall if they could be in
earlier DOS versions either. They are also HORRRIBLY SLOW. It seems as
thought COMMAND.COM is loaded to interpret EVERY line of your .BAT file.
Recall that this is the Microsoft idea of a shell!
There are more bugs, but the ones I have found are minor. Now, onto
COMPLAINTS
Microsoft wants us to use DOS for everything. Has anyone timed the speed
with which DOS writes to the screen? Is it 300 or 400 baud?
Why does the "echo off" command echo itself?
When supplying a 10Mb hard disk, why can't we have a cleanup routine,
which will make the files reside in contiguous disk space? When I first
got my XT, it was pretty fast. Now, with 48 subdirectories, 685 files,
and 8 months of use, floppies are faster in many cases! I wouldn't care
if the routine took 3 hours. I'd do it once a month anyway!
With subdirectories, it seems like a link capability would be useful.
I currently have 30 COPIES of stdio.h and 45 COPIES of pe.pro (the
key definition profiler for the Personal Editor). What a waste of disk
space!!!!!!!
The date does not always (usually) change at midnight. Whatever routine
they use to update the date really stinks. I have left the PC I have at
work on over the weekend, only to come in Monday and find that the date
still says Friday. This may seem like a trivial complaint, but it really
makes bookkeeping difficult.
NOTE
I have sent every item above (and more) to IBM and got no response.
Since DOS 2.0 was released in March, doesn't it seem like 2.1 should
be here by now????
RF Starrjay@rochester.UUCP (Jay Weber) (10/08/83)
In reference to the complaint about CiC86 programs hanging when
you redirect the input: That is due to the C library interacting
with DOS 2.0. The function call used in ascii mode is "buffered
keyboard input with echo". The echo part is why you see the file
printing on the screen whether you printed it or not. The system
call gets the redirected character from the file, thinking it is
from the keyboard, and through ignorance, echoes it. Aha! You say,
why not use the "no echo" call(s)? Well, then it won't work
correctly when typing from the keyboard. You could do an ioctl
function call to find if the input is the console and act accordingly,
but it is probably better and possibly easier to just rewrite
the library routines to do the new 2.0 calls. I have done some of
this. When I come up with a universally usable set of new routines,
I'll post them.
The reason why it hangs is because the keyboard input system call
reads until a newline character is fetched; when you redirect the
input, the last character sent is a ^Z -- what you see on the
screen is the ^Z echoed, and it is waiting for a newline that
you cannot give. Frustrating, since it is inside a system call
"never to return", so you cannot BREAK it. Rebooting is the only
thing to do. A quick fix might be to change the library routines to
not use the buffered system calls.
By the way, I wrote a very tiny but handy c routine, called safe().
All it does is check to see if there is a character on the input,
discard the result, and return. What it does is allow you to
BREAK out of infinite loops if a call to safe() is inside the
loop. Helps out alot in debugging, becasue I hate rebooting
when. I screw something up.
-Jay Weber
{jay@rochester, ..!seismo!rochester!jay}