Announcement

Collapse
No announcement yet.

2 gig Drives and up

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

  • Mike Luther
    replied
    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]

    Leave a comment:


  • Mel Bishop
    replied
    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.


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

    Leave a comment:


  • Buck Huffman
    replied
    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


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

    Leave a comment:


  • Matthew Berg
    replied
    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.

    Leave a comment:


  • Fred Buffington
    replied
    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



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

    Leave a comment:


  • RM Green
    replied
    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


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

    Leave a comment:


  • Michael Mattias
    replied
    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.

    Leave a comment:


  • Jerry Mason
    replied
    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

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

    Leave a comment:


  • Tony Damigo
    replied

    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



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

    Leave a comment:


  • Tom Hanlin
    replied
    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

    Leave a comment:


  • Tony Damigo
    started a topic 2 gig Drives and up

    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

    ------------------
Working...
X