Announcement

Collapse
No announcement yet.

2 gig Drives and up

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2 gig Drives and 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??

    T

    ------------------

  • #2
    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.


    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Comment


    • #3

      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??

      T



      ------------------

      Comment


      • #4
        Hi Tony,

        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?

        Cheers,
        Jerry

        ------------------

        Comment


        • #5
          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..

          Succinct answer No.
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Originally posted by Tony Damigo:


            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.

            Bob


            ------------------

            Comment


            • #7
              Tony, there's a disk information program on my site for pb 3.5
              that should get you what you want.
              http://pages.sbcglobal.net/oasys



              ------------------
              Client Writeup for the CPA

              buffs.proboards2.com

              Links Page

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Buck


                  ------------------

                  Comment


                  • #10
                    Another way is to: SHELL "CHKDSK > C:\somefile.txt"
                    Then parse somefile.txt to find the info you need. Tried it
                    on xp and this works okay.


                    ------------------
                    There are no atheists in a fox hole or the morning of a math test.
                    If my flag offends you, I'll help you pack.

                    Comment


                    • #11
                      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:

                      http://hobbes.nmsu.edu/

                      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.




                      ------------------
                      Mike Luther
                      [email protected]
                      Mike Luther
                      [email protected]

                      Comment

                      Working...
                      X