|
From: Jim M. <jmi...@ya...> - 2011-02-13 09:57:31 |
I am possibly going to rewrite my df utility to work with freeDOS' FAT32 filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit regs). I cannot find any documentation on the functions that freedos uses for its filesystem functions, like getting filesystem volume space calculations (total & available). can anyone help me? ------------- Jim Michaels jmi...@ya... Ji...@Ji... http://JimsComputerRepairandWebDesign.com http://JesusnJim.com (my personal site, has software) http://DoLifeComputers.JesusnJim.com (group which I lead) --- Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1,000B=1KB][2^10B=1,024B=1KiB] [10^6B=1,000,000B=1MB][2^20B=1,048,576B=1MiB] [10^9B=1,000,000,000B=1GB][2^30B=1,073,741,824B=1GiB] [10^12B=1,000,000,000,000B=1TB][2^40B=1,099,511,627,776B=1TiB] Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB. computer memory (RAM) is measured in MiB and GiB. ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ |
|
From: Christian M. <cm...@bt...> - 2011-02-13 12:44:24 |
> I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and > 16-bit > regs). > > I cannot find any documentation on the functions that freedos uses for > its > filesystem functions, like getting filesystem volume space calculations > (total & > available). > > can anyone help me? Yes. Refer to Ralf Brown's Interrupt List's description of interrupt 21h function 7303h. (This is also referenced in the SeeAlso section of the description of interrupt 21h function 36h.) The data returned into your buffer by this function is partially different to that returned by function 36h, but testing this on a FAT32 file system and verifying whether the results match your expectations should work. I think to recall that on DOS versions that support function 7303h you can usually obtain information about FAT12 and FAT16 file systems using this function too. As to your exact request for a FreeDOS function, FreeDOS kernels with FAT32 support provide function 7303h. They also allow retrieving information about non-FAT32 file systems this way. Note that RBIL says: > on DOS versions which do not support the FAT32 calls, this function > returns CF clear/AL=00h (which is the DOS v1+ method for reporting > unimplemented functions) You have to be careful about this criterion. My observations indicate that DOS versions that do not support interrupt 21h function 73h indeed return with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL zero. It means AL zero and CF unchanged. Regards, Christian |
|
From: Eric A. <e....@jp...> - 2011-02-13 12:55:32 |
Hi Jim, > I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit > regs). > > I cannot find any documentation on the functions that freedos uses for its > filesystem functions, like getting filesystem volume space calculations (total & > available). > > can anyone help me? Indeed this is documented in Ralf Browns Interrupt List RBIL. You can look at my tiny 2005 example FAT32 size info tool: http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/ free-disk-space-tester-freetest.zip (Thanks to Alain for mirroring, my page is more down than up :-!) Binary is 1kB, NASM source 9kB so there are enough comments ;-) Regards, Eric > mov ax,7300h ; get a FAT32 property > mov dl,0 ; current drive > mov cl,1 ; "dirty-buffers flag" > int 21h > cmp ax,7300h ; AX still unchanged? > jz oldkernel > ; ignore the actual results of int 21.7300 (AL, AH) > mov byte [kern32],1 ; kernel has FAT32 support ... > mov al,[drvnam] ; drive letter > mov [what32],al ; plug letter into "x:\",0 string > mov dx,what32 ; in DS: string > mov di,size32 ; in ES: size info buffer > mov cx,30h ; buffer size, at least 2ch > mov ax,7303h ; get extended free space > int 21h > jc bug2 ; error? > ; Else: dd [free32+8] = bytes per sector > ; dd [free32+14h] = free sectors ... > kern32 db 0 ; flag: set to 1 if kernel supports FAT32 > what32 db "Q:\",0 ; the drive which we want to have checked > ; filled by int 21.7303.dsdx=&drvnam.esdi=&sizeinf.cx=2ch > ; which returns ax=7300 for non-FAT32 DOS versions or carry set > ; if FAT32 is supported but an error (AX) occurred during the call. > size32 dw 30h ; returns size > dw 0 ; returns version > %if 0 ; rest of the data can be in uninitialized (BSS) space in RAM... > dd 0,0,0,0 ; sec/clust1, by/clust, free clusters1, total clusters > dd 0,0,0,0 ; free sect2, total sect2, free clust2, total clust2 > dd 0,0 ; reserved > %endif ; 1: with compression adjustment / 2: without compression adjustment > ; even this can be clipped to 2 GB in Win9x: if a DOS TSR hooks int21, > ; some FAT1x compatibility feature triggers and clipping happens. ... > Public domain free disk space checker by EA 2004-2005 > > Usage: > FREETEST [X:] [4] > Drive spec is optional, default is the current drive. > The digit is an optional size unit selector, default 1 kByte: > 0->1k, 1->4k, 2->16k, 3->64k, 4->256k, > 5->1M, 6->4M, 7->16M, 8->64M, 9->256M. > Free space information is returned in errorlevel, 0 on error. > > Example: FREETEST C: 5 returns errorlevel 50 if at least > 50 MBytes are free on C:. Errorlevel is never above 255. |
|
From: dos386 <do...@gm...> - 2011-02-13 13:05:11 |
> I think to recall that on DOS versions that support function 7303h you > can usually obtain > information about FAT12 and FAT16 file systems using this function too IIRC worked for me on a FAT12 floppy ;-) > on DOS versions which do not support the FAT32 calls, this function > returns [BUG]CF clear/AL=00h[/BUG] Better don't look at AL, but into the buffer, set input size to $30 and accept output size $24 to $2C ;-) -- ~~~ wow ~~~ |
|
From: Rugxulo <ru...@gm...> - 2011-02-14 00:36:13 |
Hi, On 2/13/11, Jim Michaels <jmi...@ya...> wrote: > > I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit > regs). I think DJGPP does (try to) use int 21h, 7303h sometimes, but modern NT-based Windows (XP etc.) don't support it, IIRC, which complicates the matters. DJGPP does have its own DU.EXE (fil41[sb].zip), so you could check the sources for that. Also, are you using 2.03p2? Call it a hunch, but I'd suspect 2.04 would be more complete (better 4 GB file support, says Charles). You could also email djgpp-workers or CWS directly or even go back to comp.os.msdos.djgpp. (quoting Smash TV): "Good luck! You'll need it." |
|
From: Jim M. <jmi...@ya...> - 2011-02-14 05:37:45 |
I am using 2.04.
I was hoping a hint might spark some documentation on the FreeDOS filesystem API
so others (like me) can do development. :-)
you might see an increase in freedos programs if your API was documented. who
knows, maybe even commercial systems might be made or something.
I am hoping to implement some sort of fallback mechanism into the program so
that if int 21h, 7303h fails, I have int 21h, 36h to fall back on.
but I need to know exactly how to detect failure. not every programmer writing
production code does that... so I need documentation.
like for instance, is the carry bit set or cleared or something?
________________________________
From: Rugxulo <ru...@gm...>
To: Jim Michaels <jmi...@ya...>; fre...@li...
Sent: Sun, February 13, 2011 4:36:06 PM
Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other
programming functions/interfaces?
Hi,
On 2/13/11, Jim Michaels <jmi...@ya...> wrote:
>
> I am possibly going to rewrite my df utility to work with freeDOS' FAT32
> filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit
> regs).
I think DJGPP does (try to) use int 21h, 7303h sometimes, but modern
NT-based Windows (XP etc.) don't support it, IIRC, which complicates
the matters. DJGPP does have its own DU.EXE (fil41[sb].zip), so you
could check the sources for that. Also, are you using 2.03p2? Call it
a hunch, but I'd suspect 2.04 would be more complete (better 4 GB file
support, says Charles). You could also email djgpp-workers or CWS
directly or even go back to comp.os.msdos.djgpp.
(quoting Smash TV): "Good luck! You'll need it."
|
|
From: Eric A. <e....@jp...> - 2011-02-14 23:10:40 |
Hi again, > I was hoping a hint might spark some documentation on the > FreeDOS filesystem API so others (like me) can do development. :-) > > you might see an increase in freedos programs if your API was documented. > who knows, maybe even commercial systems might be made or something. That is not a FreeDOS API, it is simply Win9x / MS DOS 7 compatible so you can get documentation by reading about Win9x / MS DOS 7 :-) > I am hoping to implement some sort of fallback mechanism into the program > so that if int 21h, 7303h fails, I have int 21h, 36h to fall back on. As you can see in my example program, you indeed have to do that. In particular, if the kernel does not support FAT32, for example in WinNT / MS DOS 6 and older / FreeDOS "16" style kernels, then you have to stick to int 21 function 36... By the way, of course I do use both 21.36 and 21.7303 but maybe Assembly is not the programming language that you like best :-) > but I need to know exactly how to detect failure. not every programmer > writing production code does that... so I need documentation. > like for instance, is the carry bit set or cleared or something? That is also documented in my example program. http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/ free-disk-space-tester-freetest.zip 1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged, then the kernel is not aware of the 21.73xx FAT32 functions. 2. if the kernel does support FAT32, you can set ax=7303h, ds:dx = pointer to db "x:\",0 where X is the drive where you want to know the free / used space, es:di = pointer to 30h byte buffer for results, cx=30h, int 21h - if it sets carry or the bytes per sector is nonsense (buffer+8, dword) then it failed, otherwise buffer+14h has a dword with the number of free sectors. 3. if the kernel does not support FAT32, use good old 21.36 Enjoy :-) Eric PS: Depending on your memory model, you do not have to set the ES or DS part of the pointers, only the offset. Easier. |
|
From: Christian M. <cm...@bt...> - 2011-02-14 23:23:27 |
> 1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged, > then the kernel is not aware of the 21.73xx FAT32 functions. Why test another function (which is really undocumented at that, so unlikely to be implemented properly in other DOS versions) to determine whether function 7303h is supported? I mean, sure, it might work. Just: is there any advantage to it? I don't see one. I'd set ax=7303h, ds:dx->, es:di-> and cx as appropriate and CF=1. If CF=1 on return, there was an error. The error code in ax can be used to determine whether the function is supported but caused an error, or whether it is not supported at all. In the latter case ax equals 7300h (or even 7303h) or 0001h. Regards, Christian |
|
From: Jim M. <jmi...@ya...> - 2011-02-15 21:36:42 |
define "nonsense sector sizes". there are new large sector drives coming out,
where 1k sectors, 2k sectors, and 4k sector sizes are not uncommon. I heard
noises of this from a warning kb post from microsoft.
...but the disk industry's tech support says they have no knowledge of it (but
they probably don't know anything more than what's in their scripts). so how do
you define nonsense, now that these drives are a possibility? scsi drives, worm
drives, MO drives (I used to have one) already have the possibility of 1k
sectors.
alas, I tried my disk free space program, and I got nonsense results from
windows xp... usually I get something weird back. so I am going to have to
have somebody else test it who has a proper OS. my spare box has linux on it.
I need a freedos box. (maybe I should wipe it again?).
what I can't tell is if it fails over correctly. I know I checked the carry
flag correctly, if (1==r.x.flags&0x0001) {....
this is the frustrating side of programming...
here's a part of my source if it would help any.
typedef struct extFAT32FreeSpaceStructure {
/* 00h WORD*/uint16_t ret_size_of_returned_structure;
/* 02h WORD*/uint16_t
call_structure_version_ret_actual_structure_version;// (0000h)
/* 04h DWORD*/uint32_t
number_of_sectors_per_cluster_with_adjustment_for_compression;
/* 08h DWORD*/uint32_t number_of_bytes_per_sector;
/* 0Ch DWORD*/uint32_t number_of_available_clusters;
/* 10h DWORD*/uint32_t total_number_of_clusters_on_the_drive;
/* 14h DWORD*/uint32_t
number_of_physical_sectors_available_on_the_drive_without_adjustment_for_compression;
/* 18h DWORD*/uint32_t
total_number_of_physical_sectors_on_the_drive_without_adjustment_for_compression;
/* 1Ch DWORD*/uint32_t
number_of_available_allocation_units_without_adjustment_for_compression;
/* 20h DWORD*/uint32_t
total_allocation_units_without_adjustment_for_compression;
/* 24h 8 BYTEs*/uint64_t reserved;
} extFAT32FreeSpaceStructure;
void ShowDrive(unsigned int drive, bool verbose) {
ld total, davail;
int percent;
int64_t iDAvail, iTotal;
struct diskfree_t df;
//-------------------------start of meat-----------------------------------
extFAT32FreeSpaceStructure *pds = (extFAT32FreeSpaceStructure
*)calloc(sizeof(extFAT32FreeSpaceStructure), 1);
char * str = (char *)calloc(strlen("c:\\")+1, 1);
str[0]='A'+drive;
str[1]=':';
str[2]='\\';
str[3]='\0';
dosmemput(str, strlen(str)+1,
_go32_info_block.linear_address_of_transfer_buffer + 48);
pds->call_structure_version_ret_actual_structure_version=0;
dosmemput(pds, sizeof(extFAT32FreeSpaceStructure),
_go32_info_block.linear_address_of_transfer_buffer);
__dpmi_regs r;
r.x.ax=0x7303;
r.x.cx=sizeof(extFAT32FreeSpaceStructure);
r.x.ds=_go32_info_block.linear_address_of_transfer_buffer>>4;
r.x.dx=_go32_info_block.linear_address_of_transfer_buffer& 0x0f;
r.x.es=(_go32_info_block.linear_address_of_transfer_buffer+48)>>4;
r.x.di=(_go32_info_block.linear_address_of_transfer_buffer+48)&0x0f;
r.x.flags &= 0xfffe; //clear carry bit
__dpmi_int(0x21, &r);
if (r.x.flags & 1) {
//CF set on error
//error, so try fallback method of using old dos int21h function
36h _dos_getdiskfree()
//long long iTotal, iDAvail;
if (0==_dos_getdiskfree(drive, &df)) { // 0=default, 1=a, 2=b...
iDAvail=df.avail_clusters; iTotal=
df.total_clusters;
iDAvail*=df.bytes_per_sector;
iTotal*=df.bytes_per_sector;
iDAvail*=df.sectors_per_cluster;
iTotal*=df.sectors_per_cluster;
//cout.setf(ios::fixed);
//cout.unsetf(ios::scientific);
davail = ld(df.avail_clusters);
davail*= ld(df.bytes_per_sector);
davail*= ld(df.sectors_per_cluster);
total = ld(df.total_clusters);
total*= ld(df.bytes_per_sector);
total*= ld(df.sectors_per_cluster);
} else {
printf("ERROR:_dos_getdiskfree() failed. everything failed.
drive %c:\n", drive+'a');
return;
}
} else {
//success on int 21h 7303h, so extract results.
dosmemget(_go32_info_block.linear_address_of_transfer_buffer,
sizeof(extFAT32FreeSpaceStructure), pds);
iDAvail =
pds->number_of_sectors_per_cluster_with_adjustment_for_compression;
iDAvail *= pds->number_of_bytes_per_sector;
iDAvail *= pds->number_of_available_clusters;
iTotal =
pds->number_of_sectors_per_cluster_with_adjustment_for_compression;
iTotal *= pds->number_of_bytes_per_sector;
iTotal *= pds->total_number_of_clusters_on_the_drive;
//__dpmi_free_dos_memory(segds);
}
free(pds);
free(str);
//-------------------------end of meat-----------------------------------
iTotalDAvail += iDAvail;
iTotalTotal += iTotal;
if (drive == thisDrive) { // if current drive, show it.
printf("*");
} else {
printf(" ");
}
printf("%s", drivename[drive-a_drive]);
if (verbose) {
#if defined(__BORLANDC__) || defined(_MSC_VER) || defined (__MINGW32__)
printf("%I64d/%I64d (%I64d%%)\n",
#elif defined(__DJGPP__)
printf("%lld/%lld (%lld%%)\n",
#endif
iDAvail,
iTotal,
(iDAvail*100)/iTotal
);
} else { //if verbose
//-----disk usage graph
for (percent = int(graphLength); percent >= 1; percent--) {
if ((double(percent)/graphLength) >= (davail/total))
{
//left part of graph
if (isAscii) {
printf("-"); //°
} else {
printf("°");
}
} else {
//right part of graph
if (isAscii) {
printf("*");
} else {
printf("Û");
}
}
}
//-----disk free/total disk numbers
PrintSIint64_t(iDAvail);
printf("/");
PrintSIint64_t(iTotal);
double nd=davail*100.0;nd/=total;
printf(" (%4.2f%%)\n", nd); //compiler bug doesn't allow %%
} //end if verbose
}
Jim Michaels
________________________________
From: Eric Auer <e....@jp...>
To: fre...@li...
Sent: Mon, February 14, 2011 3:10:34 PM
Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other
programming functions/interfaces?
Hi again,
> I was hoping a hint might spark some documentation on the
> FreeDOS filesystem API so others (like me) can do development. :-)
>
> you might see an increase in freedos programs if your API was documented.
> who knows, maybe even commercial systems might be made or something.
That is not a FreeDOS API, it is simply Win9x / MS DOS 7 compatible
so you can get documentation by reading about Win9x / MS DOS 7 :-)
> I am hoping to implement some sort of fallback mechanism into the program
> so that if int 21h, 7303h fails, I have int 21h, 36h to fall back on.
As you can see in my example program, you indeed have to do that.
In particular, if the kernel does not support FAT32, for example
in WinNT / MS DOS 6 and older / FreeDOS "16" style kernels, then
you have to stick to int 21 function 36... By the way, of course
I do use both 21.36 and 21.7303 but maybe Assembly is not the
programming language that you like best :-)
> but I need to know exactly how to detect failure. not every programmer
> writing production code does that... so I need documentation.
> like for instance, is the carry bit set or cleared or something?
That is also documented in my example program.
http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/
free-disk-space-tester-freetest.zip
1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged,
then the kernel is not aware of the 21.73xx FAT32 functions.
2. if the kernel does support FAT32, you can set ax=7303h,
ds:dx = pointer to db "x:\",0 where X is the drive where
you want to know the free / used space, es:di = pointer to
30h byte buffer for results, cx=30h, int 21h - if it sets
carry or the bytes per sector is nonsense (buffer+8, dword)
then it failed, otherwise buffer+14h has a dword with the
number of free sectors.
3. if the kernel does not support FAT32, use good old 21.36
Enjoy :-)
Eric
PS: Depending on your memory model, you do not have to set
the ES or DS part of the pointers, only the offset. Easier.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Freedos-devel mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freedos-devel
|
|
From: Eric A. <e....@jp...> - 2011-02-15 22:18:10 |
Hi Jim,
> define "nonsense sector sizes"
> there are new large sector drives coming out,
> where 1k sectors, 2k sectors, and 4k sector sizes are not uncommon.
At the moment, FreeDOS only supports 512 bytes. I know of
no drives which have sectors above 8 kB sector size and
there are no drives where sector size is not a power of
two. In particular, sector size 0 is typical nonsense...
For a simple test, I would say 512 is fine, 512-8192 is
okay and everything else means that your int 21.7303 did
probably not work correctly, either for that drive or in
general for any reason, such as FAT32 support not present
or switched off or not compatible with a drive/ramdisk...
Of course DOS / Windows can still try to give you useful
results even then, but if it cannot even decide that the
sector size is between 512 and 8k, you should better give
good old int 21.36 a try for the drive in question ;-)
Make sure you wipe the buffer before calling int 21.7303
so you can tell the difference between nonsense results
and results left over from something else.
> I need a freedos box. (maybe I should wipe it again?).
You can also start FreeDOS from USB flash stick, CD or DVD
using for example syslinux, isolinux or maybe grub4dos :-)
I was even able to start it from SD cards in cardreaders,
even external ones. Laptops with built-in SD reader, too.
> extFAT32FreeSpaceStructure *pds = (extFAT32FreeSpaceStructure
> *)calloc(sizeof(extFAT32FreeSpaceStructure), 1);
Nice moment for wiping would be after that.
> char * str = (char *)calloc(strlen("c:\\")+1, 1);
> str[0]='A'+drive;
> str[1]=':';
> str[2]='\\';
> str[3]='\0';
There are probably more elegant ways for this...
> dosmemput(str, strlen(str)+1,
> _go32_info_block.linear_address_of_transfer_buffer + 48);
...
Apparently you use DJGPP. This has magic int21 call
helpers, so you can probably avoid dpmi_int and go32.
Please read the documentation about int86, int86regs,
int86x and similar. Much easier than manual DPMI and
of course much less error prone - unless of course
you manage to find an int21 call for which DJGPP is
not aware of the correct magic (e.g. 21h.33ffh ;-))
Another nice thing is:
#define peek(sg, f) _farpeekw( _dos_ds, ((uint32)(sg)<<4)+(f) )
#define peekb(sg, f) _farpeekb( _dos_ds, ((uint32)(sg)<<4)+(f) )
#define poke(sg, f, v) _farpokew( _dos_ds, ((uint32)(sg)<<4)+(f), (v) )
#define pokeb(sg, f, v) _farpokeb( _dos_ds, ((uint32)(sg)<<4)+(f), (v) )
Also, I think DJGPP has some generic data exchange
buffer which you can use for smaller tasks, so you
do not have to allocate manually even if you do not
use the magic int86 / int86x calls although those,
as said, make your life much easier anyway :-).
Regards, Eric
PS: In general, DPMI stuff is easier than Go32:
__dpmi_regs r;
int size = 512;
int segV = __dpmi_allocate_dos_memory(size/16, &selV);
r.x.ax = 0x4f00; /* vesa info */
r.x.es = segV; /* buffer segment */
r.x.di = 0; /* buffer offset */
pokeb(segV, 0, 'V');
pokeb(segV, 1, 'B');
pokeb(segV, 2, 'E');
pokeb(segV, 3, '2');
__dpmi_int(0x10, &r); /* video BIOS */
if (r.x.ax == 0x004f) {
...
_movedatab(selV, 0, _my_ds(), (uint32)&mybuffer[0], sizeof(mybuffer));
... display VESA info ...
}
__dpmi_free_dos_memory(selV);
|
|
From: Jim M. <jmi...@ya...> - 2011-02-20 08:02:02 |
Eric, Leland Holliday (sp?) told me that he reworked your freetest.asm in that
zip file and got it outputting correct numbers (the numbers were bogus) and
displaying usable output.
If that code is yours, and I get it from him, I could email it to you (or post
it here if you wish).
Jim Michaels
________________________________
From: Jim Michaels <jmi...@ya...>
To: fre...@li...
Sent: Tue, February 15, 2011 1:36:34 PM
Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other
programming functions/interfaces?
define "nonsense sector sizes". there are new large sector drives coming out,
where 1k sectors, 2k sectors, and 4k sector sizes are not uncommon. I heard
noises of this from a warning kb post from microsoft.
...but the disk industry's tech support says they have no knowledge of it (but
they probably don't know anything more than what's in their scripts). so how do
you define nonsense, now that these drives are a possibility? scsi drives, worm
drives, MO drives (I used to have one) already have the possibility of 1k
sectors.
alas, I tried my disk free space program, and I got nonsense results from
windows xp... usually I get something weird back. so I am going to have to
have somebody else test it who has a proper OS. my spare box has linux on it.
I need a freedos box. (maybe I should wipe it again?).
what I can't tell is if it fails over correctly. I know I checked the carry
flag correctly, if (1==r.x.flags&0x0001) {....
this is the frustrating side of programming...
here's a part of my source if it would help any.
typedef struct extFAT32FreeSpaceStructure {
/* 00h WORD*/uint16_t ret_size_of_returned_structure;
/* 02h WORD*/uint16_t
call_structure_version_ret_actual_structure_version;// (0000h)
/* 04h DWORD*/uint32_t
number_of_sectors_per_cluster_with_adjustment_for_compression;
/* 08h DWORD*/uint32_t number_of_bytes_per_sector;
/* 0Ch DWORD*/uint32_t number_of_available_clusters;
/* 10h DWORD*/uint32_t total_number_of_clusters_on_the_drive;
/* 14h DWORD*/uint32_t
number_of_physical_sectors_available_on_the_drive_without_adjustment_for_compression;
/* 18h DWORD*/uint32_t
total_number_of_physical_sectors_on_the_drive_without_adjustment_for_compression;
/* 1Ch DWORD*/uint32_t
number_of_available_allocation_units_without_adjustment_for_compression;
/* 20h DWORD*/uint32_t
total_allocation_units_without_adjustment_for_compression;
/* 24h 8 BYTEs*/uint64_t reserved;
} extFAT32FreeSpaceStructure;
void ShowDrive(unsigned int drive, bool verbose) {
ld total, davail;
int percent;
int64_t iDAvail, iTotal;
struct diskfree_t df;
//-------------------------start of meat-----------------------------------
extFAT32FreeSpaceStructure *pds = (extFAT32FreeSpaceStructure
*)calloc(sizeof(extFAT32FreeSpaceStructure), 1);
char * str = (char *)calloc(strlen("c:\\")+1, 1);
str[0]='A'+drive;
str[1]=':';
str[2]='\\';
str[3]='\0';
dosmemput(str, strlen(str)+1,
_go32_info_block.linear_address_of_transfer_buffer + 48);
pds->call_structure_version_ret_actual_structure_version=0;
dosmemput(pds, sizeof(extFAT32FreeSpaceStructure),
_go32_info_block.linear_address_of_transfer_buffer);
__dpmi_regs r;
r.x.ax=0x7303;
r.x.cx=sizeof(extFAT32FreeSpaceStructure);
r.x.ds=_go32_info_block.linear_address_of_transfer_buffer>>4;
r.x.dx=_go32_info_block.linear_address_of_transfer_buffer& 0x0f;
r.x.es=(_go32_info_block.linear_address_of_transfer_buffer+48)>>4;
r.x.di=(_go32_info_block.linear_address_of_transfer_buffer+48)&0x0f;
r.x.flags &= 0xfffe; //clear carry bit
__dpmi_int(0x21, &r);
if (r.x.flags & 1) {
//CF set on error
//error, so try fallback method of using old dos int21h function
36h _dos_getdiskfree()
//long long iTotal, iDAvail;
if (0==_dos_getdiskfree(drive, &df)) { // 0=default, 1=a, 2=b...
iDAvail=df.avail_clusters; iTotal=
df.total_clusters;
iDAvail*=df.bytes_per_sector;
iTotal*=df.bytes_per_sector;
iDAvail*=df.sectors_per_cluster;
iTotal*=df.sectors_per_cluster;
//cout.setf(ios::fixed);
//cout.unsetf(ios::scientific);
davail = ld(df.avail_clusters);
davail*= ld(df.bytes_per_sector);
davail*= ld(df.sectors_per_cluster);
total = ld(df.total_clusters);
total*= ld(df.bytes_per_sector);
total*= ld(df.sectors_per_cluster);
} else {
printf("ERROR:_dos_getdiskfree() failed. everything failed.
drive %c:\n", drive+'a');
return;
}
} else {
//success on int 21h 7303h, so extract results.
dosmemget(_go32_info_block.linear_address_of_transfer_buffer,
sizeof(extFAT32FreeSpaceStructure), pds);
iDAvail =
pds->number_of_sectors_per_cluster_with_adjustment_for_compression;
iDAvail *= pds->number_of_bytes_per_sector;
iDAvail *= pds->number_of_available_clusters;
iTotal =
pds->number_of_sectors_per_cluster_with_adjustment_for_compression;
iTotal *= pds->number_of_bytes_per_sector;
iTotal *= pds->total_number_of_clusters_on_the_drive;
//__dpmi_free_dos_memory(segds);
}
free(pds);
free(str);
//-------------------------end of meat-----------------------------------
iTotalDAvail += iDAvail;
iTotalTotal += iTotal;
if (drive == thisDrive) { // if current drive, show it.
printf("*");
} else {
printf(" ");
}
printf("%s", drivename[drive-a_drive]);
if (verbose) {
#if defined(__BORLANDC__) || defined(_MSC_VER) || defined (__MINGW32__)
printf("%I64d/%I64d (%I64d%%)\n",
#elif defined(__DJGPP__)
printf("%lld/%lld (%lld%%)\n",
#endif
iDAvail,
iTotal,
(iDAvail*100)/iTotal
);
} else { //if verbose
//-----disk usage graph
for (percent = int(graphLength); percent >= 1; percent--) {
if ((double(percent)/graphLength) >= (davail/total))
{
//left part of graph
if (isAscii) {
printf("-"); //°
} else {
printf("°");
}
} else {
//right part of graph
if (isAscii) {
printf("*");
} else {
printf("Û");
}
}
}
//-----disk free/total disk numbers
PrintSIint64_t(iDAvail);
printf("/");
PrintSIint64_t(iTotal);
double nd=davail*100.0;nd/=total;
printf(" (%4.2f%%)\n", nd); //compiler bug doesn't allow %%
} //end if verbose
}
Jim Michaels
________________________________
From: Eric Auer <e....@jp...>
To: fre...@li...
Sent: Mon, February 14, 2011 3:10:34 PM
Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other
programming functions/interfaces?
Hi again,
> I was hoping a hint might spark some documentation on the
> FreeDOS filesystem API so others (like me) can do development. :-)
>
> you might see an increase in freedos programs if your API was documented.
> who knows, maybe even commercial systems might be made or something.
That is not a FreeDOS API, it is simply Win9x / MS DOS 7 compatible
so you can get documentation by reading about Win9x / MS DOS 7 :-)
> I am hoping to implement some sort of fallback mechanism into the program
> so that if int 21h, 7303h fails, I have int 21h, 36h to fall back on.
As you can see in my example program, you indeed have to do that.
In particular, if the kernel does not support FAT32, for example
in WinNT / MS DOS 6 and older / FreeDOS "16" style kernels, then
you have to stick to int 21 function 36... By the way, of course
I do use both 21.36 and 21.7303 but maybe Assembly is not the
programming language that you like best :-)
> but I need to know exactly how to detect failure. not every programmer
> writing production code does that... so I need documentation.
> like for instance, is the carry bit set or cleared or something?
That is also documented in my example program.
http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/
free-disk-space-tester-freetest.zip
1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged,
then the kernel is not aware of the 21.73xx FAT32 functions.
2. if the kernel does support FAT32, you can set ax=7303h,
ds:dx = pointer to db "x:\",0 where X is the drive where
you want to know the free / used space, es:di = pointer to
30h byte buffer for results, cx=30h, int 21h - if it sets
carry or the bytes per sector is nonsense (buffer+8, dword)
then it failed, otherwise buffer+14h has a dword with the
number of free sectors.
3. if the kernel does not support FAT32, use good old 21.36
Enjoy :-)
Eric
PS: Depending on your memory model, you do not have to set
the ES or DS part of the pointers, only the offset. Easier.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Freedos-devel mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freedos-devel
|
|
From: Jim M. <jmi...@ya...> - 2011-02-14 05:45:45 |
oops, just saw this. actually, I don't know where this is documented, I was only able to see a brief blow-by mention of the function. does anyone know where documentation on int21h function 7303h is, since it is apparently publicly available somewhere? ________________________________ From: Christian Masloch <cm...@bt...> To: Jim Michaels <jmi...@ya...>; fre...@li... Sent: Sun, February 13, 2011 4:44:16 AM Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces? > I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit > regs). > > I cannot find any documentation on the functions that freedos uses for its > filesystem functions, like getting filesystem volume space calculations (total >& > available). > > can anyone help me? Yes. Refer to Ralf Brown's Interrupt List's description of interrupt 21h function 7303h. (This is also referenced in the SeeAlso section of the description of interrupt 21h function 36h.) The data returned into your buffer by this function is partially different to that returned by function 36h, but testing this on a FAT32 file system and verifying whether the results match your expectations should work. I think to recall that on DOS versions that support function 7303h you can usually obtain information about FAT12 and FAT16 file systems using this function too. As to your exact request for a FreeDOS function, FreeDOS kernels with FAT32 support provide function 7303h. They also allow retrieving information about non-FAT32 file systems this way. Note that RBIL says: > on DOS versions which do not support the FAT32 calls, this function > returns CF clear/AL=00h (which is the DOS v1+ method for reporting > unimplemented functions) You have to be careful about this criterion. My observations indicate that DOS versions that do not support interrupt 21h function 73h indeed return with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL zero. It means AL zero and CF unchanged. Regards, Christian ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 |
|
From: Jim M. <jmi...@ya...> - 2011-02-14 05:57:21 |
hmm. that program doesn't use int 21h function 7303h. it's going to take me a while to figure out what it's really doing. ________________________________ From: Eric Auer <e....@jp...> To: fre...@li... Sent: Sun, February 13, 2011 4:55:22 AM Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces? Hi Jim, > I am possibly going to rewrite my df utility to work with freeDOS' FAT32 > filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit > regs). > > I cannot find any documentation on the functions that freedos uses for its > filesystem functions, like getting filesystem volume space calculations (total >& > > available). > > can anyone help me? Indeed this is documented in Ralf Browns Interrupt List RBIL. You can look at my tiny 2005 example FAT32 size info tool: http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/ free-disk-space-tester-freetest.zip (Thanks to Alain for mirroring, my page is more down than up :-!) Binary is 1kB, NASM source 9kB so there are enough comments ;-) Regards, Eric > mov ax,7300h ; get a FAT32 property > mov dl,0 ; current drive > mov cl,1 ; "dirty-buffers flag" > int 21h > cmp ax,7300h ; AX still unchanged? > jz oldkernel > ; ignore the actual results of int 21.7300 (AL, AH) > mov byte [kern32],1 ; kernel has FAT32 support ... > mov al,[drvnam] ; drive letter > mov [what32],al ; plug letter into "x:\",0 string > mov dx,what32 ; in DS: string > mov di,size32 ; in ES: size info buffer > mov cx,30h ; buffer size, at least 2ch > mov ax,7303h ; get extended free space > int 21h > jc bug2 ; error? > ; Else: dd [free32+8] = bytes per sector > ; dd [free32+14h] = free sectors ... > kern32 db 0 ; flag: set to 1 if kernel supports FAT32 > what32 db "Q:\",0 ; the drive which we want to have checked > ; filled by int 21.7303.dsdx=&drvnam.esdi=&sizeinf.cx=2ch > ; which returns ax=7300 for non-FAT32 DOS versions or carry set > ; if FAT32 is supported but an error (AX) occurred during the call. > size32 dw 30h ; returns size > dw 0 ; returns version > %if 0 ; rest of the data can be in uninitialized (BSS) space in RAM... > dd 0,0,0,0 ; sec/clust1, by/clust, free clusters1, total clusters > dd 0,0,0,0 ; free sect2, total sect2, free clust2, total clust2 > dd 0,0 ; reserved > %endif ; 1: with compression adjustment / 2: without compression adjustment > ; even this can be clipped to 2 GB in Win9x: if a DOS TSR hooks int21, > ; some FAT1x compatibility feature triggers and clipping happens. ... > Public domain free disk space checker by EA 2004-2005 > > Usage: > FREETEST [X:] [4] > Drive spec is optional, default is the current drive. > The digit is an optional size unit selector, default 1 kByte: > 0->1k, 1->4k, 2->16k, 3->64k, 4->256k, > 5->1M, 6->4M, 7->16M, 8->64M, 9->256M. > Free space information is returned in errorlevel, 0 on error. > > Example: FREETEST C: 5 returns errorlevel 50 if at least > 50 MBytes are free on C:. Errorlevel is never above 255. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Freedos-devel mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: Tom E. <te...@dr...> - 2011-02-14 15:03:03 |
Dear Jim, > hmm. that program doesn't use int 21h function 7303h. it's going to take me a > while to figure out what it's really doing. to me it looks like you are either a) a complete idiot that is not able to ask google about 'int 21h function 7303h' b) a huge troll in both cases please leave us alone. Tom > ________________________________ > From: Eric Auer <e....@jp...> > To: fre...@li... > Sent: Sun, February 13, 2011 4:55:22 AM > Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other > programming functions/interfaces? > Hi Jim, >> I am possibly going to rewrite my df utility to work with freeDOS' FAT32 >> filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and 16-bit >> regs). >> >> I cannot find any documentation on the functions that freedos uses for its >> filesystem functions, like getting filesystem volume space calculations (total >>& >> >> available). >> >> can anyone help me? > Indeed this is documented in Ralf Browns Interrupt List RBIL. > You can look at my tiny 2005 example FAT32 size info tool: > http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/ > free-disk-space-tester-freetest.zip > (Thanks to Alain for mirroring, my page is more down than up :-!) > Binary is 1kB, NASM source 9kB so there are enough comments ;-) > Regards, Eric >> mov ax,7300h ; get a FAT32 property >> mov dl,0 ; current drive >> mov cl,1 ; "dirty-buffers flag" >> int 21h >> cmp ax,7300h ; AX still unchanged? >> jz oldkernel >> ; ignore the actual results of int 21.7300 (AL, AH) >> mov byte [kern32],1 ; kernel has FAT32 support > ... >> mov al,[drvnam] ; drive letter >> mov [what32],al ; plug letter into "x:\",0 string >> mov dx,what32 ; in DS: string >> mov di,size32 ; in ES: size info buffer >> mov cx,30h ; buffer size, at least 2ch >> mov ax,7303h ; get extended free space >> int 21h >> jc bug2 ; error? >> ; Else: dd [free32+8] = bytes per sector >> ; dd [free32+14h] = free sectors > ... >> kern32 db 0 ; flag: set to 1 if kernel supports FAT32 >> what32 db "Q:\",0 ; the drive which we want to have checked >> ; filled by int 21.7303.dsdx=&drvnam.esdi=&sizeinf.cx=2ch >> ; which returns ax=7300 for non-FAT32 DOS versions or carry set >> ; if FAT32 is supported but an error (AX) occurred during the call. >> size32 dw 30h ; returns size >> dw 0 ; returns version >> %if 0 ; rest of the data can be in uninitialized (BSS) space in RAM... >> dd 0,0,0,0 ; sec/clust1, by/clust, free clusters1, total clusters >> dd 0,0,0,0 ; free sect2, total sect2, free clust2, total clust2 >> dd 0,0 ; reserved >> %endif ; 1: with compression adjustment / 2: without compression adjustment >> ; even this can be clipped to 2 GB in Win9x: if a DOS TSR hooks int21, >> ; some FAT1x compatibility feature triggers and clipping happens. > ... >> Public domain free disk space checker by EA 2004-2005 >> >> Usage: >> FREETEST [X:] [4] >> Drive spec is optional, default is the current drive. >> The digit is an optional size unit selector, default 1 kByte: >> 0->1k, 1->4k, 2->16k, 3->64k, 4->256k, >> 5->1M, 6->4M, 7->16M, 8->64M, 9->256M. >> Free space information is returned in errorlevel, 0 on error. >> >> Example: FREETEST C: 5 returns errorlevel 50 if at least >> 50 MBytes are free on C:. Errorlevel is never above 255. > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel > |
|
From: Walt N. <wr...@ya...> - 2011-02-14 19:00:20 |
Frank van Gilluwe produced a very similar book called "Undocumented PC;" it is based heavily on Ralf Brown's work. The 2nd edition came out in 1997, but still doesn't go much beyond DOS 5. This book comes with a 3 1/2" floppy containing several code fragments that might be of interest to someone beginning to use assembler. I would stay away from the 1st edition: there were several significant errors. Walt Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces? To: fre...@li... Date: Monday, February 14, 2011, 10:51 AM The book is called "Undocumented DOS", but was written around 1993 (2nd Edition here). It contains material about MS-DOS 6.2, as well as discussing predictions of the upcoming "Chicago" operating system (to become Windows 95 and MS-DOS 7.00). Therefore it does not contain any information about the Int21.73 interface or FAT32. Here's a link to Amazon's description of the book, because apparently there's no Wikipedia article about it: http://www.amazon.com/Undocumented-DOS-Programmers-Structures-Programming/dp/020163287X Regards, Christian |
|
From: Jim M. <jmi...@ya...> - 2011-02-15 22:27:00 |
by size you mean the size of the structure? ouch... the size of the structure is exactly 0x2c including the reserved stuff. if you don't include the reserved stuff, it's 0x24. the first operation should be a calloc to allocate the structure, which zeros the structure memory first before the call, and zero the flags (which includes CF). with djgpp, they additionally instruct you to zero sp, and ss, so that go32 will automatically alloc a stack (lest you end up with garbage). with the thinking that if the OS doesn't support this function whatsoever and totally blows it, you will get a zero back your original stuff, and of course the zeroing of the structure leaves you with the size member coming back with what? zero. thus it is less than 0x24 (the size of the structure minus the reserved area) and thus an error. and of course of it is greater than 0x2c (the size of the structure including the reserved space), it is suspect as well. good catch. I set CF to 0 before I started, and I got 0 when I ended. windows xp. xp totally blew the function call. I set the entire structure to 0's before I started, and I got 0's back. but then again that's windows xp. it would be interesting to see what happens on other OS's... now I need a guinea pig freedos FAT32 machine to test my df program on... ________________________________ From: dos386 <do...@gm...> To: fre...@li... Sent: Mon, February 14, 2011 12:08:20 AM Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces? > RBIL is pretty much it (right? > http://www.delorie.com/djgpp/doc/rbinter/id/40/32.htm NO, see above. > I am hoping to implement some sort of fallback mechanism into the program > so that if int 21h, 7303h fails, I have int 21h, 36h to fall back on > but I need to know exactly how to detect failure See above: clear buffer, set "size" to $30, set flag(C) to 1, call INT $21 / AX=$7303, if ((flag(C)=1) or ("size" < $24) or ("size">$2C)) then /* F**K, do fallback to AH=$36 */ ... -- ~~~ wow ~~~ ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Freedos-devel mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: Christian M. <cm...@bt...> - 2011-02-15 22:43:11 |
CM>RBIL> on DOS versions which do not support the FAT32 calls, this function CM>RBIL> returns CF clear/AL=00h (which is the DOS v1+ method for reporting CM>RBIL> unimplemented functions) CM> CM> You have to be careful about this criterion. My observations indicate CM> that CM> DOS versions that do not support interrupt 21h function 73h indeed return CM> with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL CM> zero. It means AL zero and CF unchanged. JM> I set CF to 0 before I started, and I got 0 when I ended. windows xp. JM> xp totally blew the function call. No, you did. Please re-read the quote above to understand why Windows XP's NTVDM, to indicate an error, left CF at what you set before (in this case, zero). |
|
From: Eric A. <e....@jp...> - 2011-02-20 11:30:58 |
Hi Jim, > Eric, Leland Holliday (sp?) told me that he reworked your freetest.asm in that > zip file and got it outputting correct numbers (the numbers were bogus) and > displaying usable output. I find it strange when somebody says my software produces "bogus" results and that person even creates a "fixed" version before even telling me about the alledged bug. What sort of bogus did it show? And in what way was the output not "usable"? > If that code is yours, and I get it from him, I could email it to > you (or post it here if you wish). A diff would be useful, with explanations. If you have to send full attachments, you could send them directly to me. However, I just tested freetest again, and as you can see, it does exactly what it is supposed to do: > C:\>freetest /? > Public domain free disk space checker by EA 2004-2005 > > Usage: > FREETEST [X:] [4] > Drive spec is optional, default is the current drive. > The digit is an optional size unit selector, default 1 kByte: > 0->1k, 1->4k, 2->16k, 3->64k, 4->256k, > 5->1M, 6->4M, 7->16M, 8->64M, 9->256M. > Free space information is returned in errorlevel, 0 on error. > > Example: FREETEST C: 5 returns errorlevel 50 if at least > 50 MBytes are free on C:. Errorlevel is never above 255. > > FAT32 drives are fully supported by FREETEST. > C:\>freetest f: 5 > Free space on drive F: at least 8 * 1 Mbyte(s). > C:\>echo %errorlevel% > 8 > C:\>freetest f: 4 > Free space on drive F: at least 33 * ¼ Mbyte(s). > C:\>dir f: ... > 5 directories 8.755.200 bytes free |
|
From: Jim M. <jmi...@ya...> - 2011-02-22 21:16:33 |
Leland said his platform is Windows 98. but that's all I know. you can get a diff using winmerge. https://sourceforge.net/projects/winmerge/ winmerge is a windows program. otherwise, you can use DJGPP's diff.exe to generate a diff, it runs under freedos. I understand now that Leland seems to take preference to chkdsk's KiB format over everything else. This could explain the rewrite. I chose an SI units format and he chose to convert it to chkdsk format. to each his own I guess. I added a switch in my own program to make provision for people who want the output in specific units (like UNIX's 512-byte blocks or chkdsk's KiB). it simply divides the output by that number on the commandline and uses verbose mode, since I can't determine the SI units or computer iunits. He's also the only person who has been willing to test my df program on other platforms. All I need now is a windows-compatible binary VM that has DPMI (virtualbox doesn't). If I find a VM that works, I will see if I can offer it as a package on my site. and frankly, I'm tired of being middle-man. ________________________________ From: Eric Auer <e....@jp...> To: fre...@li... Sent: Sun, February 20, 2011 3:30:44 AM Subject: Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces? Hi Jim, > Eric, Leland Holliday (sp?) told me that he reworked your freetest.asm in that > zip file and got it outputting correct numbers (the numbers were bogus) and > displaying usable output. I find it strange when somebody says my software produces "bogus" results and that person even creates a "fixed" version before even telling me about the alledged bug. What sort of bogus did it show? And in what way was the output not "usable"? > If that code is yours, and I get it from him, I could email it to > you (or post it here if you wish). A diff would be useful, with explanations. If you have to send full attachments, you could send them directly to me. However, I just tested freetest again, and as you can see, it does exactly what it is supposed to do: > C:\>freetest /? > Public domain free disk space checker by EA 2004-2005 > > Usage: > FREETEST [X:] [4] > Drive spec is optional, default is the current drive. > The digit is an optional size unit selector, default 1 kByte: > 0->1k, 1->4k, 2->16k, 3->64k, 4->256k, > 5->1M, 6->4M, 7->16M, 8->64M, 9->256M. > Free space information is returned in errorlevel, 0 on error. > > Example: FREETEST C: 5 returns errorlevel 50 if at least > 50 MBytes are free on C:. Errorlevel is never above 255. > > FAT32 drives are fully supported by FREETEST. > C:\>freetest f: 5 > Free space on drive F: at least 8 * 1 Mbyte(s). > C:\>echo %errorlevel% > 8 > C:\>freetest f: 4 > Free space on drive F: at least 33 * ¼ Mbyte(s). > C:\>dir f: ... > 5 directories 8.755.200 bytes free ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Freedos-devel mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freedos-devel |
