main logo
Subject: Re: Hexadecimal woes ! - Clarification
Author: "Paul Newton"
Posted: 2004/05/30 05:01:10
 
View Entire Thread
New Search


Hi Dan

I hope this posting will explain where all the confusion arises

On 29 May 2004 at 8:27, Dan Covill wrote:

> Well, -1.2706E+9 isn't the original value, to start with. <g> If you
> want a hex value that _matches_ that, you'll have to take the hex and
> clear the five low-order decimal places.

Not sure how to do that but never mind, lets get to real answer <g>

> However, there is more than one machine format for integers. So I
> guess the short answer is to take -1.2706E+9 and "convert" it to hex
> using the same tool that got it for you. <g>

Well it came from GetVolumeInformation in the WIN32API and this is
where the problem starts. Four different sources I have checked for
implementation of GetVolumeInformation declare the VolumeSerialNumber
as INTEGER and this is wrong !

These sources are FoxWiki, News2News, Tek-Tips and MS own
knowledgebase article Q139547. Reminds me of a quotation "Even when
all the experts agree they may well ne mistaken" (Bertrand Russell)

Declaring VolumeSerialNumber as INTEGER sometimes results in a
usually (always ?) negative number which cannot be
tranlated/converted to hex.

> IOW, it depends on what you're trying to do. As has been discussed,
> the -1.2706E+9 is a phoney - an artifact of interpreting a 32-bit code
> as an integer when it's not. So if you need to save it, save it as a
> Dword or string, and compare that so it doesn't get converted in
> either direction.

Not sure how I would save it as a dword after it has been returned as
an integer - but if you would care to enlighten me I'd be very happy.

So the real answer is to declare VolumeSerialNumber as STRING as in
the earlier posting where I showed a solution. This returns a four
character string. Taking the ASCII value of each character and
converting it to hex solves the problem and of course there is a much
easier way than the the dectobin and bintohex routines in the
previous example - it is simply, for each character (char) in the
string, TRANS(ASC(char)," /at/ 0") .D.O.T

Of course this ties in very nicely with Rob's explanation:

Hi Paul, the volume serial number is made up of TWO hex addresses -
not one.......

It is the date / time of when the disk was formatted and is
calculated like this.

Disk formatted on Sun, 19 October 2003 22:33:27.01

Lo word is calculated:
Month & Day 10/19 0A13
Sec & 1/100s 27:01 1B01
----
2514

Hi word is calculated:
Hours & Minutes 22:33 1621
Year 2003 07D3
----
1DF4
Volume Serial: 2514-1DF4

Robs suggestion of
"serial in hex should be:", TransForm(2 ^ 32 + serial, "@0")
does not work as should now be clear.

BTW if anybody needs a calculator that correctly converts negative
decimal values to hex and back again correctly check out the HP16C
calculator at http://www.hpmuseum.org/wrpn.zip

The HP41C (my first ever programming was done on an HP41C) is also
available at http://www.web-ee.com/Downloads/Calculator/V41R8.exe

So to recap the correct solution is:

DECLARE short GetVolumeInformation IN Win32API ;
STRING lpRootPathName, ;
STRING lpVolumeNameBuffer, ;
INTEGER nVolumeNameSize, ;
STRING lpVolumeSerialNumber, ;
STRING lpMaximumComponentLength, ;
STRING lpFileSystemFlags, ;
STRING lpFileSystemNameBuffer, ;
INTEGER nFileSystemNameSize

lcDrive = CHR(ASC("A")+2)+":\" && translate to letter (C:)

STORE SPACE(255) TO lpRootPathName, ;
lpVolumeNameBuffer, ;
lpVolumeSerialNumber, ;
lpMaximumComponentLength, ;
lpFileSystemFlags, ;
lpFileSystemNameBuffer

STORE 255 TO nVolumeNameSize, nFileSystemNameSize

= GetVolumeInformation(lcDrive, ;
@lpVolumeNameBuffer, ;
@nVolumeNameSize, ;
@lpVolumeSerialNumber, ;
@lpMaximumComponentLength, ;
@lpFileSystemFlags, ;
@lpFileSystemNameBuffer, ;
@nFileSystemNameSize )

cReturnHex = ""
FOR y = 1 TO LEN(ALLTRIM(lpVolumeSerialNumber))
cHex = TRANS(ASC(SUBSTR(lpVolumeSerialNumber,y,1))," /at/ 0")
cReturnHex = cHex + cReturnHex
ENDFOR y

WAIT WINDOW "Serialno .D.O.T "+cReturnHex

RETURN cReturnHex

Sorry about the long posting but I thought I'd put this finally to
rest.

PS Maybe somebody would care to post this to (i) the FoxWiki, (ii)
News2News (iii) Tek-Tips and, last but not least, (iv) MS <g>

Paul Newton
newton@steadman-group.com
Tel: +254-2-631657
Fax: +254-2-631658



 
©2004 Paul Newton
<-- Prior Message New Search Next Message -->