X-Authentication-Warning: smtp3.ihug.com.au: Host p23-max10.syd.ihug.com.au [203.173.155.23] claimed to be acceleron
Message-ID: <005f01c10ac5$a3f10000$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>
References: <200107111706 DOT TAA05758 AT father DOT ludd DOT luth DOT se>
Subject: Re: DJDIR Windows 2000 investigation results #1
Date: Thu, 12 Jul 2001 21:27:30 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Reply-To: djgpp-workers AT delorie DOT com

> >  > > 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?
On Windows 2000 on both the NTFS and FAT32 (18GB partition) both failed in
the FAT32 extended bit was set, and both passed if the bit was not set. I
have refined the test app further to save me time and effort in testing, I
can easily make it pass or fail and conditionally test a few tests, I keep
changing it trying to better understand and test the problem.

> > 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.)
I will have written an app to create an approx 3GB file and the results are
with the changes outlined above included in the io\_*.c files:
    Windows 98 FAT32 partition exe running on Windows 98 - OK 12/07/2001
09:28p       2,946,776,700 TEST.BIN
    Windows 2000 NTFS partition exe running on Windows 2000 - OKAY
12/07/2001  09:22p       2,946,776,700 TEST.BIN
    Windows 2000 FAT32 partition with exe running on Windows 2000 - OKAY
12/07/2001  09:15p       2,946,776,700 TEST.BIN

It all looks okay for writing a file > 2GB with the mods. If the mod failed
what should have I seen?

The app uses fprintf to write in text mode 5,000 bytes of ASCII spaces at a
time to the test.bin file. I hope I don't haev to do this again as it takes
a long time to do on my Win98 box.

Regards,
Andrew