>>>get an "Insufficient disk space on destination drive" message. In fact
>>>there is plenty --too much-- room. I suspect it's making a DOS call to
>>>see what free space is available, probably getting an answer which it
>>>translates to a negative number; and then won't write out the file.
>> Probably this function:-
>> DOS 2+ - GET FREE DISK SPACE
>Yes, I think you are right. Interestingly, if I run "dir" at the
>(xdosemu) command line, I get back 2 Gig (2,147,450,880). So the
>freedos I'm using is OK. It's when I run my program that the problem
>occurs. I suspect they are using different calls.
I doubt that, actually.
Probably using this dosemu call, but doing something wrong with the
answers.
>> I should be able to make you a 'patch' TSR that loads in ram, and simply
>> limits the maximum number of clusters ever reported available to a
>> smaller value, I expect ;-).
>I think the TSR would be the best approach. I have seen several similar
>problems/queries on the mailing list; the TSR would probably work best
>for all of them.
>I still have the TSR program which fixed this in OS/2-DOS; it's named
>2gigfix.com. I tried it but it won't run in xdosemu. I think I have
>the source for it, if it would be of help to you.
That *would* be interesting to see. attach it to me in a private email
(attachments on email lists are bad news, generally).
>> Return: AX = FFFFh if invalid drive else AX = sectors per cluster BX =
>> number of free clusters CX = bytes per sector DX = total clusters on
>> drive Notes: Free space on drive in bytes is AX * BX * CX. Total space
>> on drive in bytes is AX * CX * DX. "lost clusters" are considered to be
>> in use. According to Dave Williams' MS-DOS reference, the value in DX
>> is incorrect for non-default drives after ASSIGN is run.
[snip]
>AX=0020 BX=FFFF CX=0400 DX=FFFF SP=FFFE BP=0000 SI=0000 DI=0000
>DS=0795 ES=0795 SS=0795 CS=0795 IP=0107 NV UP DI PL NZ NA PO NC
>0795:0107 BF4A59 MOV DI,594A
Right... erm... CX=0400, (1024) which means 1024bytes/sector, which
is really odd!. I have in fact never seen anything other than 512
bytes/sector. Maybe this is confusing your poor program which may
never have seen such a size, maybe...
I know that:
on FAT16 drives, 4kb clusters are used for disks upto 256mb.
on FAT16 drives, 8kb clusters are used for disks upto 512mb.
on FAT16 drives, 16kb clusters are used for disks upto 1024mb.
on FAT16 drives, 32kb clusters are used for disks upto 2048mb.
[not exactly sure about the smaller drives...]
note that 'standard' DOS fat16 never exceeds 2048mb.
However, there is FAT16 with 64kb clusters (nicknamed fat64)
which goes upto 4gb, and is supported only on windoze-NT-4/5/5.1.
Now, you are getting AX=0020 (32), i.e. 32 sectors per cluster, which
would make sense for drive size... given the weird 1kb sector size!
In MANY ways, basically compatibility with what is ''normal'' in DOS,
would make more sense to me if dosemu reported 512 (0x200) byte
sectors and 64 sectors-per-cluster (32kb clusters).
DX=FFFF (meaning, there are 65535 clusters on this drive).
BX=FFFF (meaning, there are 65535 clusters avaialble on this drive).
Now, your program is presumably computing the total space available....
>> Free space on drive in bytes is AX * BX * CX.
So, 0x0020 * 0xFFFF * 0x0400 = 0x7FFF8000
32 * 65535 * 1024 = 2147450880
So.... If the program used normal 8088 'MUL' instruction, it shouldn't
overload the 32bit number space available in registers DX:AX (or
whatever it is) for the result. In fact, if the program then compares
the high part of the result (0x7FFF) with a number it has precomputed
(i.e. the maximum space it may need), and then incorrectly uses
a 'after signed integer comparison' JL/JG type condiditional jump it
won't then get that wrong, either, as that number is in the
'positive signed integer' range (0x0000 -- 0x7FFF).
I wonder what exactly is happening with your program!
Would make a lot of sense (to me) if you sent me the binary of the
program with the problem, so I can search for the function call to
dos, to find out:-
-- if it uses that particular function call anyway
-- if it takes any notice of the sector-size rather than assuming
0x200 (512 bytes) in some form.
-- what it does with the result/comparison!
I can make a program to limit the returned maximum and available clusters
to something like 1FFF.... I wonder what your program does though!
Get back to me with what you can ;-)..
--S Iremonger // furrymonster <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
