Mail Archives: djgpp-workers/1996/07/25/10:07:49
On Wed, 24 Jul 1996, Charles Sandmann wrote:
> > > The higher bits of omode are masked out before a possibly existing
> >
> > > ! r.x.bx = oflag & 0xff; /* :TOM: new open() doesn't mask out upper bits,
> >
> > Charles - what does Win95 expect in BH? Can we just leave it
> > unmasked, or will the spare bits we use confuse it?
>
> I can't find my LFN docs right now (sigh) but I do know that additional bits
> were defined. Which ones will have to wait a bit til I can find the DOCS.
I dug out the docs that Charles once sent to me (btw, I think the
Interrupt List is quite up-to-date on this now), and I think there *is* a
conflict. The following bits are defined in 716Ch for the BX register:
0000h readonly
0001h writeonly
0002h readwrite
0003h "reserved; do not use"
0004h nomodlastaccess (readonly, doesn't modify last access time)
0010h deny-readwrite
0020h deny-write
0030h deny-read
0040h deny-none
0080h noinherit (child doesn't inherit the handle)
0100h no-buffering (read and write go directly to the disk)
0200h no-compress (not compressed on a compressed volume)
0400h alias-hint (use DI as the numeric tail for short name)
2000h n-criterr (don't call Int 24h handler when crit. err.)
4000h commit (commit file after each write)
- Raw text -