Mail Archives: djgpp/2000/02/28/07:44:18
On Mon, 28 Feb 2000, Damian Yerrick wrote:
> On Sat, 26 Feb 2000 20:28:15 +0600 (LKT), Kalum Somaratna aka Grendel
> <kalum AT crosswinds DOT net> wrote:
<snip>
> >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.
>
> I said protected, not protected mode. Windows 9x runs in the Intel
> x86 CPU's protected mode, but nothing protects the computer from being
> rebooted (accidentally or intentionally) from within a user program.
> Protected mode only provides a mechanism for memory protection; it
> doesn't require that operating systems provide such protection.
> DOS4GW doesn't IIRC.
AFAIK this stement is wrong. DOS4GW indeed provides memory protection for
badly behaved programs (do you remember the dumps that dos4gw outputs for
memory violation).
It's just that dos4gw doesn't have as much protection available for <1mb
as it has for >1mb memory range.
>
> >Yes you can acess memory using the farpokeb etc... functions.
> >Allegro is a library which uses this method.
>
> I guess you misunderstood me.
I'm sorry but I don't get it.
> >>
> >> You could _potentially_ overwrite the OS, leading to a crash or a
> >> corrupted FAT. Very bad. And according to Murphy, very probable.
> >
> >However it is worthwhile to consider the fact that ID software extensively
> >used nearptrs for the code for Quake.
>
> But does everyone have the beta testing resources of id Software?
How many people write code as complex as the ones that ID software wrote
for Quake? And how many users write code which need the same amount of
beta testing as Quake for that matter.
>
> >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..)
>
> Not to start a farptr vs. nearptr religious flamewar,
I do not wish to do that too.
> but how is a movedata() harder than a memcpy()?
>
> >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.
>
> All too easy in a buggy program on a single-HD laptop.
Comeon, nearptr's would be used in the code that needs to acess <1mb
memory. So if you take a game the code that depends on nearptrs being
enabled is likely to be very small in relation to the main code
(calculating player moves, stuff etc). IMHO so it should be reasonably
possible to root out most of the bugs in the code that would need to acess
< 1mb of meory (typically blitting routines, sound card, DMA acess etc)..
>
> >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 :-)
>
> My experiences with a hugeptr library I wrote in real-mode DOS (which
> I used in a graphics library that I abandoned when I found about DJGPP
> and Allegro) speak differently.
Well to be honest I didn't come across any problems while writing DOS4GW
programs or DJGPP programs with nearptrs enabled.
> >Although we can't match ID softwares ability root out bugs ;-)
>
> So use the CPU's. farptr is your friend.
Again, How many people write code of the complexity that ID software
wrote that dependens on nearptrs. So that means most people wont have need
to vast resources to root out bugs :-)
>
> >> >for(i=0;i<64000;i++)
> >> > _farpokeb(_dos_ds,0xA0000,+i,buffer[i]);
> >
> >char *p= (char *)(__djgpp_conventional_base+ 0xa0000);
> >for (i=0; i<64000;i++)
> >p=buffer[i];
>
> After getting and storing the selector for video RAM
> (pointing to 0xa0000 or whatever VBE 2 tells you):
> #include <sys/movedata.h>
> movedata(_my_ds, (unsigned)video_buffer, video_ds, 0, 64000);
I think you've missed the bus here Damien :-) Your code doesn't do the
same as the code I produced above.
>
> >Beautiful isn't it :-)
>
> Yes. What could be more beautiful than one simple function call?
One that uses less assembly code, faster, and that looks more nice to the
eye, and doesn't need all those messing with _dos_ds and other stuff..
Here's the equivalent of your above code that would be written in c if
nearptrs were enabled,
char *p=(char*)(__djgpp_conventional_base+0xa000);
for (i=0;i<64000;i++)
{
*p=0;
}
Beautifully simple and whats more lets have a look at the assembly
produced by GCC for the above code using -O3 etc.
movl ___djgpp_base_address,%eax
negl %eax
addl $40960,%eax
//for (i=0;i<64000;i++)
movl $63999,%ecx
L7:
decl %ecx
jns L7
movb $0,(%eax)
// {
// *p=0;
// }
The only insns that will be executed by in this clearing routine will be
the decl, jns and moveb. See how fast and simple the assembly is. So
getting back to your question of what could be better than one function
call?... one that uses only 3 instructions :-) And note that the memory
accessing part (the moveb) is only one isn. Ideal for performance critical
routines.
BTW I haven't acess to the movedata sources bit I bet it isn't as small or
fast as the above assembly :-)
The point i'm trying to make is that when you use nearptrs gcc can
optimize your code as it sees fit. Therefore you should get better
performance than movedata or even the farptrs.
>
> >AFAIK memory protection isn't disabled using nearptrs
> >since protected mode is still being used.
>
> x86 protected mode with nearptrs disables protection because you can
> now overwrite DOS.
Well IMHO the idea of a protected mode DOS is that you *should* be able to
acesss < 1mb memory as easily as possible. IMHO If you can't or it is too
difficult to access <1mb this might prove to be a hindarance to
programmers who use that environment.
You can also ovewrite dos in real mode programs too but tell me how many
of the thousnds of real mode programs/games (which have almost no memory
protection) corrupted your HDD as you accuse nearptr enabled programs of.
>
> >It just makes it more easier for a badly behaved
> >pointer to do unnatural things :-)
>
> Like corrupt the filesystem in the worst
> (very unlikely but very possible) case.
Please see my above message.
>
> >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 :-)
>
> What could be more cross-platform than text? GNU/Linux has ASCII too,
> just like DOS (except for line endings, which are DOS-style on Usenet
> IIRC).
I suppose you have answered your own comment about text portability
across dos and Linux ;-)
BTW Damien, Maybe the reason why your "virus scanner" ;-) is so
innefective is that it doesn't take into account the line ending
problem ;-)
>And Linux doesn't need virus scanners, as system EXEs cannot
> be overwritten by a user program.
>
I havent come across viruses that have been written for linux but I
suppose there might be a few.
BTW Are there any friends on the list who know of any viruses for
UNIX/LINUX?
Grendel
> This is McAfee VirusScan. Add these two lines to your .sig to
> prevent the spread of .sig viruses. http://www.mcafee.com/
^^^^^^^^^^^^^^^^
Too bad that your brand new toy isn't working Damien ;-)
Regards,
Grendel
Hi, I'm a signature virus. plz set me as your signature and help me spread
:)
- Raw text -