Mail Archives: djgpp/2011/03/16/16:00:09
"Rod Pemberton" <do_not_have AT notreplytome DOT cmm> wrote in message
news:ilr1cl$in9$1 AT speranza DOT aioe DOT org...
> "Rod Pemberton" <do_not_have AT notreplytome DOT cmm> wrote in message
> news:ilqu49$5v6$1 AT speranza DOT aioe DOT org...
> >
> > Here's
> > my code, after my .sig, which is *tested* and *working*.
> >
>
> Let me clarify that...
>
> Windows 95/98/SE/ME provides function 7303h for FAT32 drives. Looking at
> RBIL, I'm not sure if this is available in real mode MS-DOS, or not.
> I.e., it may only be available in a Windows console, or "dosbox".
>
> So, the code I posted works with DJGPP v2.03 and v2.04 in a Windows 98 SE
> console widow, or "dosbox". The code *does not* work for me with MS-DOS
> v7.10. DOSLFN upto and including v0.40e supports most of the 71xxh LFN
> functions and none of the 73xxh FAT32 functions. So, DOSLFN doesn't help
> any.
>
> For a the working code in a console window, r.x.ax=7303h and CF=0. The CF
> is: r.x.flags&1. For MS-DOS v7.10, my code returns r.x.ax=57h and CF=1.
> RBIL says AL=0 on unsupported DOS versions. So, 7303h _should_ be
> supported. If it works in a Windows 98 console, it works for real mode
> DOS too. Sorry, I do not know what the issue is yet, i.e., programming
> error by me, or an unsupported function in DOS. I could try Jason's code
> for you...
>
Once r.x.ax and r.x.cx are initialized, Jason's code works in both DOS
and Windows console. That means 7303h is supported for both, at least for
MS-DOS v7.10. If RBIL is correct, you'd need a DOS from Windows 95 or
later.
To fix my version so it works correctly like Jason's, two changes are
needed:
1) add the following line as the first line of lfn_7303()
_farpokew(_dos_ds, __tb+2+OFFS, 0); /* initialise the version */
2) add this include with the other includes at the beginning
#include <sys/farptr.h>
So, with those two changes to my code, you have a __working__ example, as
desired.
Instead of setting the a value and then needing to copy the entire
structure, Jason farpoke's a value of zero for:
extFAT32FreeSpaceStructure.call_structure_version_ret_actual_structure_versi
on
You could set it to zero, and then copy the structure. That would be more
understandable.
Good luck,
Rod Pemberton
- Raw text -