Mail Archives: djgpp/2000/02/29/14:05:35
On Mon, 28 Feb 2000, Damian Yerrick wrote:
> On Mon, 28 Feb 2000 18:20:28 +0600 (LKT), Kalum Somaratna aka Grendel
> <kalum AT crosswinds DOT net> wrote:
>
> >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>
> >
> >> >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.
>
> OP wrote "how do I disable protection to access low memory?"
> I said "You don't [disable the protection]."
> You interpreted it as "You don't [access low memory]."
Not quite, I interpreted it as you dont *need* to disable protection to
acesss <1mb memory. Ie-: you can use farptrs
>
> >> >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)..
>
> Disk access, loading stuff into RAM, saving games. A write gone awry
> in the DMA or blit code could trash the kernel.
Well if you are so paranoid then enable nearptrs only before you execute
code that depends on it like blitting routines, and disable them
immediately afterwards.
Although this would cause a certain amount of performance problems due to
the complex DPMI calls (less so with modern day machines) you can develop
and beta test and root out the bugs with the above method then enable
nearptrs for the whole program in the final release version thus getting
the maximum performance possible.
Well consider the amount of WATCOm/DOS4GW games you have run over the
years (doom, doom2, command and conquer, the list is endless...) all of
them have nearptrs enabled by default (as you yourself have said), How
many times have they screwed up your system or HDD?
IMHO there are so many dos extended programs with nearptrs enabled out
there and I still have to see any one of them doing anything bad as such.
So the nearptr usage is nothing to be frowned upon or for other
programmers to get a heart attack about :-)
> >>
> >> 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 :-)
Well you didn't answer this part of my message. hmm.....
> >> >> >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.
>
> That's because code above has a bug.
???? which has the bug your code or mine?
>Mine might too.
> We're human (I hope).
No, I happen to be a neural network designed especially for newsgroup
posting and answering, running on a Athlon 1Ghz machine with 2GB of memory
and 10 20Gb SCSI drives ;-)
>
> >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.
>
> OK. So you better be *really* careful.
Sure, You have to be really careful not only when you use nearptrs but
when you write just about any code.
>
> >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.
>
> How is movedata() difficult?
Not difficult but slow...
Consider that you want to copy data in a interrupt handler (say a sound
card driver) where naturally performance is critical. And say that the
interrupt handler is called about 100 times a sec. Surely a inline
assembly routine called 100 times using nearptrs enabled and the rep movsd
insns would be faster than calling the equivalent movedata function 100
times?
Just imagine the overhead of setting up the stack 100 times etc during the
100 calls to movedata in a interrupt handler :-)
if you really want to use farptrs then farpoke* is a much faster option
than movedata IMHO.
>
> >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.
>
> Because I (and several thousand other players) paid $40 each to pay
> testers and debuggers.
This is distortion of the facts IMHO. Anyway I doubt that most of the 40$
went to the testers and debuggers, AFAIK it's the pay for programmers,
managers, developement costs, and artists/music etc that accounts mostly
for the final pricing.
FWIW there are companies that depend on users to do the beta testing.
7 Kingdoms was one such game in which the developers encouraged users to
download beta releases and test it out and submit the bugs.
>
> >BTW Damien, Maybe the reason why your "virus scanner" ;-) is so
> >innefective is that it doesn't take into account the line ending
> >problem ;-)
>
> It's on Usenet; DOS line endings are the standard on Usenet.
But maybe not on the mailing list ;-)
>
> >>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.
>
> Any Solaris viruses? HP-UX viruses?
Since every OS has it's bugs. It is _not_ impossible for someone to write
a virus for UNIX/LINUX, Just much harder than dos/windoze. There maybe
quite a lot of viruses out there lurking on UNIX boxes even. Who knows?
> >BTW Are there any friends on the list who know of any viruses for
> >UNIX/LINUX?
>
> Good luck.
Thanks but I don't need it. Quite a number of people already have followed
up with comments about the viruses that are available for UNIX/Linux.
Grendel
Hi, I'm a signature virus. plz set me as your signature and help me spread
:)
- Raw text -