From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200107111706.TAA05758@father.ludd.luth.se>
Subject: Re: DJDIR Windows 2000 investigation results #1
In-Reply-To: <001201c10a0b$05de5760$0a02a8c0@acceleron> from Andrew Cottrell at "Jul 11, 2001 11:11:38 pm"
To: djgpp-workers AT delorie DOT com
Date: Wed, 11 Jul 2001 19:06:13 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Andrew Cottrell:
>  > > So it looks like my FAT32 detection routines will be needed after
> > > all.
> >
> > I'm not sure.  It's possible that a simple version check is enough.
> I have a small suspicion that FAT32 detection would not help as the problem
> is probably in the Win2K VDM implementation. I have two physical hard drives
> in my Win2K box. The first hard drive is split into three partitions, C: &
> D: are NTFS while E: is FAT32. The seconds hard drive is H: and is FAT 32.
> (F & G are DVD and CDRW drives).

So what are the results of your test program (the ac-ed one) on the
FAT32 partition?

> The simple addition of os_major checking before setting the FAT32 extended
> bit in the appropriate LFN int 21 calls fixes the issue, but what if any are
> the side affects?
> 
> Sample code mod from src/libc/dos/io/_open.c that works is:
>   if(use_lfn) {
>     r.x.ax = 0x716c;
>     r.x.bx = (oflag & 0xff);
>     if (7 <= _osmajor && _osmajor < 10)   /* NEW CHECK */
>     {
>       r.x.bx |= 0x1000;  /* FAT32 extended size. */
>     }
>     r.x.dx = 1;   /* Open existing file */
>     r.x.si = __tb_offset;
>   } else {
>     if(7 <= _osmajor && _osmajor < 10) {
>       r.x.ax = 0x6c00;
>       r.x.bx = (oflag & 0xff) | 0x1000; /* 0x1000 is FAT32 extended size. */
>       /* FAT32 extended size flag doesn't help on WINDOZE 4.1 (98). It
>   seems it has a bug which only lets you create these big files
>   if LFN is enabled. */
>       r.x.dx = 1;                        /* Open existing file */
>       r.x.si = __tb_offset;
>     } else {

This would be ok if WINDOZE 2k doesn't support that extended bit on
the FAT32 partitions.

If it does, then you'd not be able to create file bigger than ~2GiB
in spite of it should be possible. Perhaps this is acceptable for
WINDOZE 2k which doesn't work so well anyway? (I don't think so.)


Right,

						MartinS