Date: Sat, 26 Feb 2000 20:28:15 +0600 (LKT)
From: Kalum Somaratna aka Grendel <kalum AT crosswinds DOT net>
X-Sender: root AT darkstar DOT grendel DOT net
To: djgpp AT delorie DOT com
cc: trancelucid AT videotron DOT ca
Subject: Re: Fastest bitblt?
In-Reply-To: <83mebssig8p8d943fekqr2sgumh48ermno@4ax.com>
Message-ID: <Pine.LNX.4.10.10002261941000.1032-100000@darkstar.grendel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Sat, 26 Feb 2000, Damian Yerrick wrote:

> On Fri, 25 Feb 2000 21:51:48 -0500, Trancelucid
> <trancelucid AT videotron DOT ca> wrote:
> 
> >I'm porting some source of mine (from Watcom and TC) to DJGPP, and the
> >main problem I'm having right now is accessing 0xA0000.

I too had the same problem as you and after some thought I decided to use
the nearptr method instead of the farpokeb ...etc for the reasons given
below, So you can decide which better suits your needs.

> 
> Watcom automatically nearptrs all memory.  DJGPP doesn't, primarily
> because it's descended from a GNU tool, and GNU is a protected OS.

Watcom32 (DOS4GW) is too a protected mode os (dosextender) so it is
_wrong_ to imply that dos4gw/Watcomc 32 extended dos is not a protected
mode environment.

> 
> >Both are 32bit compilers, so why would you need to
> >disable protection to access video memory in DJGPP?
> 
> You don't.

Yes you can acess memory using the farpokeb etc... functions. Allegro is a
library which uses this method. You can have a look at the allegro sources
if you wish and see wether you like this method or not.
 
> >How (un)safe is it to disable protection to access
> >video memory with memcpy()?
> 
> You could _potentially_ overwrite the OS, leading to a crash or a
> corrupted FAT.  Very bad.  And according to Murphy, very probable.  It
> happened when I was using TroubleSpace (officially DriveSpace from MS-
> DOS 6.22); good thing I was using DoubleGuard (extra layer of memory
> protection for DriveSpace drives).

However it is worthwhile to consider the fact that ID software extensively
used nearptrs for the code for Quake. So IMHO I think that it using
nearptrs _is_ useful and easy (just see how easy acessing memory using a
char *p pointer is than all those farpokeb etc..) providing that you are
careful when acessing memory using the pointer as it is very easy to
overwrite code or data using a stray pointer. 

So IMHO nearptrs are a useful feature and makes much more code portable
from Watcom to DJGPP and also that using nearptrs is resonably safe and
nothing to get a panic attack about :-) 

Although we can't match ID softwares ability root out bugs ;-) I still
have to see Quake (which extensively uses nearptrs) do something bad to my
system. So IMHO be careful when you use nearptrs and your program will
not do cause any unnatural acts to happen.

> 
> >Right now I use it
> >in a for loop:
> >
> >for(i=0;i<64000;i++) 
> >   _farpokeb(_dos_ds,0xA0000,+i,buffer[i]);

Just see how much more nicer the code would be if written with nearptrs
enabled,


char *p= (char *)(__djgpp_conventional_base+ 0xa0000);
for (i=0; i<64000;i++)
p=buffer[i];

Beautiful isn't it :-) 
So IMHO using nearptrs can lead to more easier coding and portability.
AFAIK memory protection isn't disabled using nearptrs since protected mode
is still being used. It just makes it more easier for a badly behaved
pointer to do unnatural things :-)

Grendel

> 
> This is McAfee VirusScan. Add these two lines to your .sig to
> prevent the spread of .sig viruses.  http://www.mcafee.com/

Hi, I'm a signature virus. plz set me as your signature and help me spread
:) 

^^^^ 
Thank you all the kind people who have set me as there signature.
Please help me fight this evil Yerrickafee virus scanner which also has no
version for linux :-)