Linux MS DOS discussions
 help / color / mirror / Atom feed
* Disk size
@ 2004-10-02 22:14 Joe Henley
  2004-10-02 23:32 ` S Iremonger
  0 siblings, 1 reply; 4+ messages in thread
From: Joe Henley @ 2004-10-02 22:14 UTC (permalink / raw)
  To: linux-msdos

Hi,

I have a DOS application which says there isn't room to write a file. I 
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.

I had this issue years ago when I ran this DOS application program in 
OS/2.  Now it's here in DOSEmu/Linux.  Anyone know how to tell the 
DOSEmu session it has only X amount of space; where X is some number DOS 
can deal with?

Thanks!

Joe Henley

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Disk size
  2004-10-02 22:14 Disk size Joe Henley
@ 2004-10-02 23:32 ` S Iremonger
  2004-10-10 15:49   ` Joe Henley
  0 siblings, 1 reply; 4+ messages in thread
From: S Iremonger @ 2004-10-02 23:32 UTC (permalink / raw)
  To: Joe Henley; +Cc: linux-msdos

>I have a DOS application which says there isn't room to write a file. I
>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

AH = 36h
DL = drive number (00h = default, 01h = A:, etc)

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. This function does not return
proper results on CD-ROMs; use AX=4402h"CD-ROM" instead. (FAT32 drive) the
reported total and free space are limited to 2G-32K should they exceed
that value


The reason for such overflow could be various things.
If you sent me the execcutable with the problem, I might try to fix it for
  you if you're lucky ;-).

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 had this issue years ago when I ran this DOS application program in
>OS/2.  Now it's here in DOSEmu/Linux.  Anyone know how to tell the
>DOSEmu session it has only X amount of space; where X is some number DOS
>can deal with?
More like a problem with the DOS program.

You might do well diagnosis-wise, is as follows:-

- run Dosemu as usual.
- Set the current working drive within freedos to the drive where you
    are having the 'too much disk space' problem -- i.e. do "D:" or
    similar.
- run "debug" (useful tool included with freedos and m$-dos).
- when Debug is running, '-' prompt will appear.
- type "a" (assemble) command, which should result a prompt
    something like '????:0100'.
- type "mov ah,36"
- type "mov dl,00"
- type "int 21"
- type "int 3"
- press enter again (blank line, leave assemble mode, back to '-' prompt)
- type "g" (run code, which should stop at the "int 3" breakpoint)
    [and will give a Register dump!!, which should be copied for us].
- type "q" (quit debug)

Then, please copy carefully the register dump that is shown.
I can see from that what kind of 'sane' (or 'insane') values are being
  returned from that dos function under dosemu.

>Joe Henley
-S Iremonger <exxsi@bath.ac.uk>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Disk size
  2004-10-02 23:32 ` S Iremonger
@ 2004-10-10 15:49   ` Joe Henley
  2004-10-11 13:23     ` S Iremonger
  0 siblings, 1 reply; 4+ messages in thread
From: Joe Henley @ 2004-10-10 15:49 UTC (permalink / raw)
  To: S Iremonger; +Cc: linux-msdos

Hi,

Thanks for your reply.  I have replied "in-line" below.  I appreciate 
any help, or TSR, you can provide.  Thanks!

Joe Henley

S Iremonger wrote:
>>I have a DOS application which says there isn't room to write a file. I
>>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.

> 
> AH = 36h
> DL = drive number (00h = default, 01h = A:, etc)
> 
> 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. This function does not return
> proper results on CD-ROMs; use AX=4402h"CD-ROM" instead. (FAT32 drive) the
> reported total and free space are limited to 2G-32K should they exceed
> that value
> 
> 
> The reason for such overflow could be various things.
> If you sent me the execcutable with the problem, I might try to fix it for
>   you if you're lucky ;-).
> 
> 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 had this issue years ago when I ran this DOS application program in
>>OS/2.  Now it's here in DOSEmu/Linux.  Anyone know how to tell the
>>DOSEmu session it has only X amount of space; where X is some number DOS
>>can deal with?

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.

> 
> More like a problem with the DOS program.
> 
> You might do well diagnosis-wise, is as follows:-
> 
> - run Dosemu as usual.
> - Set the current working drive within freedos to the drive where you
>     are having the 'too much disk space' problem -- i.e. do "D:" or
>     similar.
> - run "debug" (useful tool included with freedos and m$-dos).
> - when Debug is running, '-' prompt will appear.
> - type "a" (assemble) command, which should result a prompt
>     something like '????:0100'.
> - type "mov ah,36"
> - type "mov dl,00"
> - type "int 21"
> - type "int 3"
> - press enter again (blank line, leave assemble mode, back to '-' prompt)
> - type "g" (run code, which should stop at the "int 3" breakpoint)
>     [and will give a Register dump!!, which should be copied for us].
> - type "q" (quit debug)
> 
> Then, please copy carefully the register dump that is shown.
> I can see from that what kind of 'sane' (or 'insane') values are being
>   returned from that dos function under dosemu.
> 

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


> 
>>Joe Henley
> 
> -S Iremonger <exxsi@bath.ac.uk>
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Disk size
  2004-10-10 15:49   ` Joe Henley
@ 2004-10-11 13:23     ` S Iremonger
  0 siblings, 0 replies; 4+ messages in thread
From: S Iremonger @ 2004-10-11 13:23 UTC (permalink / raw)
  To: Joe Henley; +Cc: linux-msdos

>>>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 <exxsi@bath.ac.uk>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-10-11 13:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-02 22:14 Disk size Joe Henley
2004-10-02 23:32 ` S Iremonger
2004-10-10 15:49   ` Joe Henley
2004-10-11 13:23     ` S Iremonger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox