Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <35066496.18FD@rug.ac.be>
Date: Wed, 11 Mar 1998 11:16:54 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
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> <35066048 DOT AB7DCC1A AT taniwha DOT tssc DOT co DOT nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Bill Currie wrote:
> 
> 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:|).

DOS prg's DO run in Win3.1 not running in enhanced mode, don't they?

> > > 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?  

Even with 16 bits, some sacrifices have to be made.

> 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).

You can assume the existance of 39 (26 + 10 + 3) unique fn characters. I
know there are MORE, in fact many more, but I refuse to use any
character that might yield some problems even if those chances are
remote. The tempnam functions and family should be extremily reliable.

i.e. I won't use '[', nor '-', nor some others, nor any character with
an ASCII value exceeding 127.

> 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.

Some members of the 'temporary file name creation family' require you to
return a filename in a particular directory.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/