| delorie.com/archives/browse.cgi | search |
| 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 |
| 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 |
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |