Mail Archives: djgpp/1996/07/15/22:17:14
On Fri, 12 Jul 1996, Bruce Foley wrote:
>
> If this is the case, then I imagine
> that any data (or code) associated with an ISR would cause
> a system crash if the interrupt was generated after the page had
> been swaped out (and was hence unavailable). Is this right?
>
Absolutely. This is exactly why you need to lock it with DPMI function
0x600.
Now something about the FAQ, so I suppose this goes to Eli:
I haven't d/l'ed the FAQ 2.01, maybe it's already there, but anyway,
here are some of my remarks:
* The FAQ says [used to say?] that OS/2 Warp probably does not support
FAT-DS. I am running OS/2 Warp revision 8.200 and it does. The FAQ
does [did] not mention Windows NT, which definitely does not support
FAT-DS, though. Also, the FAQ makes [used to make] the FAT-DS approach
look kinda scary (at least to me). It is clear, that every single
Watcom/DOS4GW application uses it (not sure, but I think Borland 4.5+
32 bit DOS apps do as well) and nobody seems to care much.
* The FAQ could [does?] have a hint to prevent GNU Make from crashing
under OS/2 Warp. The hint to set DPMI_DOS_API to ENABLED instead of
AUTO in DOS Settings for the session. DPMI_MEMORY_LIMIT is also nice
to experiment with.
* Now, I'm not sure about this one, but I think I somewhere saw the FAQ
[or other docs] say in the what's-new section, that starting from some
beta of V2, dos selector limit was set to 4GB (fat, eh?). However, when
I checked the sources, I saw it being set to 16MB. What did I miss?
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.
Plus one question to everybody:
? is it worth installing Linux on a 486DX4-100 with 16MB RAM and
? >NO INTERNET ACCESS< ? I used to think UNIX was mostly usefull to
? access the internet, but indeed, are people using Linux as a Desktop OS?
? What attracts me the most is gcc in its native [at least more native
? than DOS] environment. Is X programming difficult compared to MS-Win?
? Man, I could write X demos and recompile and run them on Suns at my
? university, is that right? How's the speed and stabilty of Linux?
? What about the HD space? Is it possible to uninstall all the internet
? stuff? What about sound and video cards? Are many of them supported?
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.
Orbital
- Raw text -