X-Authentication-Warning: new-smtp1.ihug.com.au: Host p401-tnt3.syd.ihug.com.au [203.173.133.147] claimed to be acceleron
Message-ID: <001201c10a0b$05de5760$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010711121403 DOT 3487D-100000 AT is>
Subject: Re: DJDIR Windows 2000 investigation results #1
Date: Wed, 11 Jul 2001 23:11:38 +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

I am on the list(s). Have been for over 4 years (expect for ISP changes for
a few days or a week), but this is the first time I have been in a position
to help out. I have used DJGPP since the good old v1 days for writing serial
comms tools / debuggers at work and at home.

> On Wed, 11 Jul 2001, Martin Str|mberg wrote:
>
> > > So the non-LFN DOS functions do support the FAT32 bit, while LFN
> > > functions don't.  Gosh, what a mess!
> >
> > Well, as FAT16 partitions are documented (IIRC) to only support file
> > sizes up to ~2GiB, there's actually no need to support that flag for
> > non-FAT32 partition.
>
> I don't know if the partition on which Andrew tried that was FAT16.
> Andrew, can you tell?
I was running it from a share on the WIN98 box.

> > > Given this information, I see several possible ways to solve the
> > > problem.  But first, I'd like to understand more about this FAT32 bit
in
> > > function 716Ch of Int 21h.  Martin, did we actually check that this
bit
> > > is required for opening large files under LFN?  Perhaps we could throw
> > > together a short test program which tries to read/write such a large
> > > file, and test it on Windows 9X and on W2K; then we would know if the
> > > flag is needed, and if so, on what systems.

The src/libc/dos/io/_*.c files seem to be inconsistent as some check the
_osmajor version number if LFN is used and some don't. I tried two completly
different tests and the outcome was that both tests worked on Win2K. The
tests were:
1) Borrow the Windows NT detection from Allegro (uses getenv("OS") function)
and insert it inside the crt1.c setup_os_version(void) function to set a
variable which is then used in the potential LFN functions that need to be
modified to not set the FAT32 extended bit.
2) Check the _osmajor function when wsetting the FAT32 extended bit in the
potentially affected LFN functions. This seems to be the most appropriate
change that would least impact anyone as the LFN API with the FAT32 extended
bit will still be enabled on WIN 9x. Any thoughts on this? Code example
below.

> > I did. You can't create bigger files than ~2GiB without this flag on
> > WINDOZE 98.
?
> I think we should see if the same happens on W2K, before we decide how to
> proceed.
Do you have any sample apps for me to try? I have enough spare space for the
next few months at least. I would like to use the app that was used in the
original tests that way we can all test the same app on different Windows
vairants.

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

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 {

I have been unable to re-build RHIDE 1.4.7.8 as I cannot find the libgdb.h
file that is required to compile annotate.c. Any ideas on this one? Do I
need to get a dev GDB snapshot to get this file?


I have built the TurboVision library and the  SetEditor, but these do not
help in the test as SetEdit works even when there are no DJGPP environment
variables set.