Mail Archives: djgpp-workers/1998/03/11/07:14:47
Vik Heyndrickx wrote:
>
> Bill Currie wrote:
> > AFAICT from the Win3.0 VxD docs, the VMM (the real OS behind
> > windows, also the DPMI provider) uses the ring 0 stack to hold task
> > info, though I could easily be wrong.
>
> That indeed makes sense for versions up Win3.1 that don't necessarily
> run 'Enhanced' mode.
The VMM only ever exists in `Enhanced' mode (I think:|).
>
> > My 386/486 programmers guide impiles that STR is
> > allowed in ring 3 (only LTR isn't).
>
> Mine doesn't. Although it isn't really a securite risk to allow that STR
> instruction to run at CPL=3, so I could believe that.
No explicit statement, but I agree with you.
> > why not combine the dos psp and the windows vmid (?, can't remember the
> > correct name, RBIL isn't handy at the moment :(, but I remember seeing a
> > 2f16xx call to grab it). Sure, you wind up with a 32 bit number, but
> > that can be expressed in 6 chars (uuencode or related) with the rest (5
> > if the extension is used) used for time/counter/whatever.
>
> Problem is that the less bits are in the PID the easier it is to squeeze
> them in a filename (the original reason for the quest for a good PID).
> When there are 32 bits it may get impossible to combine them with a
> 'large enough' counter and the current time yielding an eight-character
> filename.
Hmmm, 24 bit hash of pid and vmid? Only takes 4 bytes to encode (hmm,
ARE there 64 valid chars in a dos file name??? (ie 7bit) 8 bit gets
messy due to dos converting lowercase chars to upper `randomly' based on
the current code page (I assume dos goes by code page, I KNOW it
converts them).
Another possibility: just add the pid and vmid. djgpp pids are
guaranteed to be separated by 0x90 (who's going to have 143 dos boxes?
some fool I s'pose, I once had about 10 (unmanagable, but still),
usually 3). Yes, I know, there's still plenty of opportunity for
clashing, but that's what the counter/timestamp are for.
Unfortunatly, you can't even assume the pid will be < 0xe000 (umb, no
ems). *sigh*
Interesting problem.
Hey, why not something like Robert Hoehne did in RHIDE, use tempory
directories in the temp dir, only the dir name is a direct sprintf of
the vmid, then ALL temp files are put in the appropriate sub dir. The
startup code could create the subdir at startup and remove it at exit...
maybe not, to remove it, the code would have to first clean out the dir
and then remove it and that will cause problems with nested apps.
Bill
--
Leave others their otherness.
- Raw text -