* 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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.