Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!harpo!seismo!hao!hplabs!sri-unix!BRACKENRIDGE@USC-ISIB
From: BRACKENRIDGE%USC-ISIB@sri-unix.UUCP
Newsgroups: net.micro.pc
Subject: Position Sensitive Code
Message-ID: <14975@sri-arpa.UUCP>
Date: Wed, 4-Jan-84 00:27:00 EST
Article-I.D.: sri-arpa.14975
Posted: Wed Jan  4 00:27:00 1984
Date-Received: Thu, 5-Jan-84 01:29:21 EST
Lines: 32

From:  Billy <BRACKENRIDGE@USC-ISIB>

In an earlier message it was pointed out that the FORMAT command
appears to be position sensitive, i.e. it does different things when
loaded at different places in memory.

I believe I am having similar problems with DISKCOPY. I am running DOS
2.0 and have about 30K of resident code on top of the normal operating
system.  I have also been getting PARITY CHECK 2 errors when doing
disk I/O in Mince and CodeSmith.  This behavior can be modified by
changing the size of the resident operating system.

Has anyone experienced similar difficulties with FORMAT, DISKCOPY, or
parity errors that appear to be position sensitive?

I believe the problems stem from programs attempting to do DMA over
64K memory segment boundaries.  DOS disk I/O calls take segment
register, offset, and transfer length as arguments.  The manual warns
clearly that a transfer should not be of such a length that it will
exceed the segment boundary.  Apparently there is no run time checking
in DOS as the responsibility for checking this condition is left with
the programmer.

I have not dis-assembled any of these programs to find out how they do
disk I/O, and whether they check for this condition.  I don't really
want to rewrite Microsoft's operating system.  It is easier for me to
just juggle the size of the operating system until a given program
appears to work.

If my theory is correct there must be other people who have
experienced similar problems and patches must be floating around to
fix the problem.