Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site shell.UUCP
Path: utzoo!linus!decvax!harpo!floyd!cmcl2!philabs!seismo!hao!kpno!ut-sally!cyb-eng!shell!starr
From: starr@shell.UUCP
Newsgroups: net.micro.pc
Subject: DOS 2.0 Problems
Message-ID: <118@shell.UUCP>
Date: Tue, 4-Oct-83 19:26:34 EDT
Article-I.D.: shell.118
Posted: Tue Oct  4 19:26:34 1983
Date-Received: Sun, 9-Oct-83 18:46:08 EDT
Organization: Shell Development CS Group, Houston, Texas
Lines: 81


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 Starr