You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
In a pure DOS system: Is there any way to read the free space on DRIVES LARGER THAN 2 GIGS ??
If an exact amount can’t be done -- is there a way to get an approximate value??
A pure DOS system doesn't support logical drives of over 2Gb.
If your DOS system is on a network, it may be that the network software
supports more than 2Gb/drive. In that case, you might see whether there's
a network API for DOS that you can call to get the drive size.
Sorry, I used a poorly crafted statement in trying to get my point across.
What I mean to say is this:
WITHOUT INTERFACING WITH "MS WINDOWS" IN ANY WAY - Can a PB/DOS program
read the free space on DRIVES LARGER THAN 2 GIGS ?? or at least come up with an
approximate value to go by??
Well, if you were willing to read the drive using BIOS calls, then read and
interpret the partition table, then learn how to interpret the format
for each partition (it's operating system dependent), then I guess you could
figure out how to calculate the free space.
It seems like a good way to kill a few months ... what's your application, if you
don't mind me asking?
Question:WITHOUT INTERFACING WITH "MS WINDOWS" IN ANY WAY - Can a PB/DOS program read the free space on DRIVES LARGER THAN 2 GIGS ??
Technically correct answer as supplied by Mr. Mason:..if you were willing to read the drive using BIOS calls, then read and interpret the partition table, then learn how to interpret the format for each partition..
WITHOUT INTERFACING WITH "MS WINDOWS" IN ANY WAY - Can a PB/DOS program
read the free space on DRIVES LARGER THAN 2 GIGS ?? or at least come up with an
approximate value to go by??
A count of unused clusters is maintained in the FS_INFO sector
on FAT32 partitions. FS_INFO is located at logical sector 1,
just after the partition boot sector. The sector id is "RRaA"
at offset 0, and the unused cluster count is a DWORD at offset
1E8h. Take that value and multiply by the bytes per cluster and
you have the available free space.
Also, available free space is returned by the DIR command, so
c$ = "DIR C:\@@@ | FIND ";CHR$(34);"free";CHR$(34);" > space.txt"
(where "@@@" stands for some non-existent file)
SHELL c$
Then parse the string returned in space.txt for the unused bytes
of disk space value.
Note the these methods are not guaranteed to return a correct
value in all cases.
WITHOUT INTERFACING WITH "MS WINDOWS" IN ANY WAY - Can a PB/DOS program read the free space on DRIVES LARGER THAN 2 GIGS ?? or at least come up with an approximate value to go by??
If your DOS program is running in a Windows DOS box, you can use the DOS service at INT 21h, function 7303h "GET EXTENDED FREE SPACE ON DRIVE" to retrieve this information.
Without Windows, there is no easy way to do it. As the largest volume size DOS natively supports, using FAT16, is 2GB, a DOS application would not normally encounter a volume larger than 2GB anyway.
------------------
If you try to make something idiot-proof, someone will invent a better idiot.
If you try to make something idiot-proof, someone will invent a better idiot.
This is based on a code that Mark Collins posted here last year.
Code:
Type DiskBuffer
Info AS STRING * 512
End Type
Type DriveParameters
Size AS WORD
InformationFlagTable AS WORD
CylindersTotal AS DWORD
HeadsTotal AS DWORD
SectorsPerTrack AS DWORD
SectorsTotal AS QUAD
BytesPerSector AS WORD
End Type
TYPE XInt13BufferStructure
PacketSize AS BYTE
Reserved AS BYTE
BlocksToTransfer AS WORD
TransferBuffer AS BYTE PTR
StartingBlock AS QUAD
END TYPE
%FALSE = 0
%TRUE = NOT %FALSE
$INCLUDE "REGNAMES.INC"
DIM DI AS DriveParameters
DIM GetBack AS DiskBuffer
CLS
Int13_Parameter &H0080, DI
PRINT DI.Size;" Buffer Size"
Temp% = LEN(BIN$(DI.InformationFlagTable))
PRINT STRING$(8-Temp%, "0");BIN$(DI.InformationFlagTable);" Flag Table"
PRINT DI.CylindersTotal;" Total Cylinders"
PRINT DI.HeadsTotal;" Heads Total "
PRINT DI.SectorsPerTrack;" SectorsPerTrack"
PRINT DI.BytesPerSector;" BytesPerSector"
PRINT CQUD(DriveInfo.SectorsTotal)
X&& = DI.CylindersTotal * DI.HeadsTotal * DI.SectorsPerTrack * DI.BytesPerSector
PRINT X&&; "Bytes Total"
FOR I&& = 1024 TO 1025
Int13_READ &H0080, GetBack, I&&
PRINT GetBack.Info
NEXT I&&
END
FUNCTION Int13_Check(DriveNum AS INTEGER)
REG %AX, &H4100
REG %BX, &H55AA
REG %DX, DriveNum
CALL INTERRUPT 13
FLAGM?? = REG(%FLAGS)
ACCUM?? = REG(%AX)
BASEM?? = REG(%BX)
COUNT?? = REG(%CX)
DATAM?? = REG(%DX)
IF BIT(FLAGM??, 0) = 1 THEN
FUNCTION = %FALSE
EXIT FUNCTION
END IF
SHIFT RIGHT ACCUM??, 8
FUNCTION = %TRUE
END FUNCTION
SUB Int13_READ(DriveNum AS INTEGER, Sector AS DiskBuffer, SectorNumber AS QUAD)
DIM XInt13Buffer AS XInt13BufferStructure
XInt13Buffer.PacketSize = &H10
XInt13Buffer.Reserved = &H00
XInt13Buffer.BlocksToTransfer = 1
XInt13Buffer.TransferBuffer = VARPTR32(Sector)
XInt13Buffer.StartingBlock = SectorNumber
REG %AX, &H4200
REG %DX, DriveNum '&H0080
REG %DS, VARSEG(XInt13Buffer)
REG %SI, VARPTR(XInt13Buffer)
CALL INTERRUPT &H13
END SUB
SUB Int13_WRITE(DriveNum AS INTEGER, Sector AS DiskBuffer, SectorNumber AS QUAD)
DIM XInt13Buffer AS XInt13BufferStructure
'Initialize Buffer Information For Write
XInt13Buffer.PacketSize? = &H10
XInt13Buffer.Reserved? = &H00
XInt13Buffer.BlocksToTransfer?? = 1
XInt13Buffer.TransferBuffer = VARPTR32(Sector)
XInt13Buffer.StartingBlock&& = SectorNumber&&
REG %AX,&H4300
REG %DX, DriveNum
' REG %DX,&H0080
'Load Segment Pointer For Disk Address Packet Buffer Into DS Register
REG %DS,VARSEG(XInt13Buffer)
'Load Offset Pointer For Disk Address Packet Buffer Into SI Register
REG %SI,VARPTR(XInt13Buffer)
CALL INTERRUPT &H13
END SUB
SUB Int13_SEEK(DriveNum AS INTEGER, Sector AS DiskBuffer, SectorNumber AS QUAD)
DIM XInt13Buffer AS XInt13BufferStructure
'Initialize Buffer Information For Write
XInt13Buffer.PacketSize? = &H10
XInt13Buffer.Reserved? = &H00
XInt13Buffer.BlocksToTransfer?? = 1
XInt13Buffer.TransferBuffer = VARPTR32(Sector)
XInt13Buffer.StartingBlock&& = SectorNumber&&
REG %AX,&H4700
REG %DX, DriveNum
' REG %DX,&H0080
'Load Segment Pointer For Disk Address Packet Buffer Into DS Register
REG %DS,VARSEG(XInt13Buffer)
'Load Offset Pointer For Disk Address Packet Buffer Into SI Register
REG %SI,VARPTR(XInt13Buffer)
CALL INTERRUPT &H13
END SUB
SUB Int13_VERIFY(DriveNum AS INTEGER, Sector AS DiskBuffer, SectorNumber AS QUAD)
DIM XInt13Buffer AS XInt13BufferStructure
'Initialize Buffer Information For Write
XInt13Buffer.PacketSize? = &H10
XInt13Buffer.Reserved? = &H00
XInt13Buffer.BlocksToTransfer?? = 1
XInt13Buffer.TransferBuffer = VARPTR32(Sector)
XInt13Buffer.StartingBlock&& = SectorNumber&&
REG %AX,&H4400
REG %DX, DriveNum
' REG %DX,&H0080
'Load Segment Pointer For Disk Address Packet Buffer Into DS Register
REG %DS,VARSEG(XInt13Buffer)
'Load Offset Pointer For Disk Address Packet Buffer Into SI Register
REG %SI,VARPTR(XInt13Buffer)
CALL INTERRUPT &H13
END SUB
SUB Int13_PARAMETER(DriveNum AS INTEGER, DriveInfo AS DriveParameters)
DriveInfo.size = SIZEOF(DriveInfo)
REG %AX, &H4800
REG %DX, DriveNum
REG %DS, VARSEG(DriveInfo)
REG %SI, VARPTR(DriveInfo)
CALL INTERRUPT &H13
END SUB
Its not tested very well at all, so be careful and back up your
data.
If this is an OS/2 box, the following utility for OS/2 is reported
to be able to fake out the DOS applications into thinking that a
maximum of 2GB is available no matter what.
=================================
Martin Kiewitz's vCOMPAT v0.32b
=================================
Released on 23.02.2003
Written and (c) by Martin Kiewitz
Dedicated to Gerd Kiewitz
-------------------------------------------------------------------------------
============
| FOREWORD |
============
OS/2 / eComStation's VDM is nearly perfectly emulating a real DOS
session. Did I say nearly? Yes, I did.
Some programs are too restrictive in their use of DOS APIs.
And some MDOS-APIs do not behave 100% like in real DOS. Additionally
some programs contain library bugs, so they won't run on faster
machines even under real DOS (like e.g. Turbo Pascal CRT Unit bug).
That's why I did this compatibility VDD. It hooks itself into the
middle of several APIs and it contains a magical VM patcher, that is
able to patch out some buggy routines on-the-fly, which means the user
won't even notice that he got a broken program.
vCOMPAT also contains code to patch out bugs in DPMI based (eg DOS4GW)
games, so that they will run under OS/2 / eCS. This code is not
absolutely failsafe and it *could* make a DPMI application crash, so
if you experience a crash try to disable this feature. If you are
using a DPMI application that is already working as expected, don't
switch this feature on.
The package is:
2-23-03 0:00a 8443 0 vcompatv032b.zip
I think I picked it off HOBBS, probably one of the best archive
sites available to the OS/2 folks:
In the OS/2 world we've been having to deal with this issue for a
very long time now and with backwards compatibility extending to
even the original DOS days, it's sure true that DOS programs are
fraught with this problem.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment