Mail Archives: djgpp/1996/07/15/23:49:44
On 16/7/96 3:43 am, Orbital <vazndain AT zveris> did thus say >>>
>
>
> On Fri, 12 Jul 1996, Bruce Foley wrote:
>
[snip]
>
> Now, I would like to continue with the FAT-DS thread. If the problem was
> memory protection and not the NT and Linux DOS-box compatibility, then
> you could just enable near pointers, do your stuff and then disable them.
> However, this is slow, because __djgpp_nearptr.. functions issue DPMI calls
> etc. I found a cool workaround for that:
>
> [1] Allocate an alias to your data descriptor and set its limit to 4GB.
> [2] When you need near pointers, load ds and es with the alias.
> [3] When done reload ds and es with the original selector.
>
> Voila. Steps [2] and [3] are much faster than __djgpp_nearptr.. calls. To
> be more precise, there is no need to allocate the alias, it's already
> there, stored in __djgpp_ds_alias variable. Just fatten it and that's it.
> There is also no need to store the original one, as it is stored in a
> variable __djgpp_app_DS. Both of them are unsigned short ints. Now, a
> nearptr_enavble() would look like this:
>
> asm volatile ("mov __djgpp_dos_alias,%es; mov __djgpp_dos_alias,%ds");
>
> and nearptr_disable() would be:
>
> asm volatile ("mov __djgpp_app_DS,%es; mov __djgpp_app_DS,%ds");
>
> Plus it would take a single call to
>
> __dpmi_set_selector_limit(__djgpp_ds_alias, -1);
>
> somewhere at startup. Hope someone finds this useful. Tell me if I'm
> wrong somewhere as I have not tested it myself.
[snip]
>
> Enough for now. You must be pretty cool if you managed to read up to here.
> Man, this *is* a long message. Sorry if I didn't write anything interesting.
>
You have GOT to be kidding!! Pretty cool idea, I'll have to check it out. The
only possible problem that I can see is if the ds alias is ever different to the
app ds, but I believe that only happens during sbrk calls (unix mode), so the app
will never see them being different.
>
> Orbital
>
>
- Raw text -