Sender: bill AT taniwha DOT tssc DOT co DOT nz
Message-ID: <35066048.AB7DCC1A@taniwha.tssc.co.nz>
Date: Wed, 11 Mar 1998 22:58:32 +1300
From: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
MIME-Version: 1.0
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
CC: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com,
        Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: Temporary files considered unsafe
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980310130222 DOT 4314B-100000 AT is> <350655E0 DOT A0EFE270 AT taniwha DOT tssc DOT co DOT nz> <350659E5 DOT 1930 AT rug DOT ac DOT be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.