Some time ago (jun 27th, 2011) I took this procedure from PEG, but now the ssd I got (64Gb), shows an error about 2,758,010,569,262 being to large for a long datatye...
DEFINE INPUT PARAMETER pDrive AS CHARACTER NO-UNDO. DEFINE OUTPUT PARAMETER pName AS CHARACTER NO-UNDO. DEFINE OUTPUT PARAMETER pFileSysName AS CHARACTER NO-UNDO. DEFINE OUTPUT PARAMETER pSerieNumbr AS INT64 NO-UNDO. DEFINE VARIABLE mVolumeName AS MEMPTR NO-UNDO. DEFINE VARIABLE mFileSysName AS MEMPTR NO-UNDO. DEFINE VARIABLE iSerialNum AS int64 NO-UNDO. DEFINE VARIABLE iMaxLen AS INT64 NO-UNDO. DEFINE VARIABLE iFlags AS INT64 NO-UNDO. DEFINE VARIABLE iResult AS INT64 NO-UNDO. SET-SIZE( mVolumeName ) = 128. SET-SIZE( mFileSysName ) = 128. PROCEDURE GetVolumeInformationA EXTERNAL "kernel32.dll": DEFINE INPUT PARAMETER lpRootPathName AS CHARACTER. DEFINE INPUT PARAMETER lpVolumnNameBuffer AS INT64. DEFINE INPUT PARAMETER lpVolumeNameSize AS INT64. DEFINE OUTPUT PARAMETER lpMaximumComponentLength AS INT64. DEFINE OUTPUT PARAMETER lpFileSystemFlags AS INT64. DEFINE INPUT PARAMETER lpFileSystemNamebuffer AS INT64. DEFINE INPUT PARAMETER nFileSystemNameSize AS INT64. DEFINE RETURN PARAMETER bResult AS INT64. END. /* *************************** Main Block *************************** */ /* INPUT PARAMETER pLetra AS CHARACTER NO-UNDO. */ /* */ /* OUTPUT PARAMETER pNombre AS CHARACTER NO-UNDO. */ /* OUTPUT PARAMETER pFileSysName AS CHARACTER NO-UNDO. */ /* OUTPUT PARAMETER pSerieNumbr AS INTEGER NO-UNDO. */ RUN GetVolumeInformationA( pDrive, GET-POINTER-VALUE( mVolumeName ), GET-SIZE( mVolumeName ), OUTPUT iSerialNum, OUTPUT iMaxLen, OUTPUT iFlags, GET-POINTER-VALUE( mFileSysName ), GET-SIZE( mFileSysName ), OUTPUT iResult ). ASSIGN pName = GET-STRING( mVolumeName, 1 ) pFileSysName = GET-STRING( mFileSysName, 1 ) pSerieNumbr = iSerialNum . set-size( mVolumeName ) = 0. set-size( mFileSysName ) = 0.
Any clue?
Any reason your RUN GetVolumeInformationA (three outputs in the middle) does not match the external procedure signature (two outputs in the middle)?
If I fix this to:
/* https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx */ PROCEDURE GetVolumeInformationA EXTERNAL "kernel32.dll": DEFINE INPUT PARAMETER lpRootPathName AS CHARACTER. DEFINE INPUT PARAMETER lpVolumnNameBuffer AS INT64. DEFINE INPUT PARAMETER lpVolumeNameSize AS INT64. DEFINE OUTPUT PARAMETER lpVolumneSerialNumber AS INT64. DEFINE OUTPUT PARAMETER lpMaximumComponentLength AS INT64. DEFINE OUTPUT PARAMETER lpFileSystemFlags AS INT64. DEFINE INPUT PARAMETER lpFileSystemNamebuffer AS INT64. DEFINE INPUT PARAMETER nFileSystemNameSize AS INT64. DEFINE RETURN PARAMETER bResult AS SHORT. END. RUN GetVolumeInformationA( pDrive, GET-POINTER-VALUE( mVolumeName ), GET-SIZE( mVolumeName ), OUTPUT iSerialNum, OUTPUT iMaxLen, OUTPUT iFlags, GET-POINTER-VALUE( mFileSysName ), GET-SIZE( mFileSysName ), OUTPUT iResult ).
Then I get results (11.7.1 x64) - note that some of the mapping of some of those parameters looks off if you compare them to Microsoft's documentation.
Any reason your RUN GetVolumeInformationA (three outputs in the middle) does not match the external procedure signature (two outputs in the middle)?
If I fix this to:
/* https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx */ PROCEDURE GetVolumeInformationA EXTERNAL "kernel32.dll": DEFINE INPUT PARAMETER lpRootPathName AS CHARACTER. DEFINE INPUT PARAMETER lpVolumnNameBuffer AS INT64. DEFINE INPUT PARAMETER lpVolumeNameSize AS INT64. DEFINE OUTPUT PARAMETER lpVolumneSerialNumber AS INT64. DEFINE OUTPUT PARAMETER lpMaximumComponentLength AS INT64. DEFINE OUTPUT PARAMETER lpFileSystemFlags AS INT64. DEFINE INPUT PARAMETER lpFileSystemNamebuffer AS INT64. DEFINE INPUT PARAMETER nFileSystemNameSize AS INT64. DEFINE RETURN PARAMETER bResult AS SHORT. END. RUN GetVolumeInformationA( pDrive, GET-POINTER-VALUE( mVolumeName ), GET-SIZE( mVolumeName ), OUTPUT iSerialNum, OUTPUT iMaxLen, OUTPUT iFlags, GET-POINTER-VALUE( mFileSysName ), GET-SIZE( mFileSysName ), OUTPUT iResult ).
Then I get results (11.7.1 x64) - note that some of the mapping of some of those parameters looks off if you compare them to Microsoft's documentation.
Thanks.!!!! but won't blame my.. I just copy pasted the code ... (Oh.... I remember clearly... it was jun 27th, 2011... pun intended)