While going thru a report about analyzing the index.dat file I was following along with how they located a “File Time” date/time stamp.
The Hex bytes in my case are 2E 8B B4 71 0E D3 CD 01 then you are supposed to reverse the bytes 01 CD D3 0E 71 B4 8B 2E .
Convert them to decimal then you can convert from file time to a normal Date/Time if you are doing it the long way. Insted of using the API function.
Using the built in calculator the bytes convert to 129992023254272814 decimal then run thru a file time to Date time Converter I made. I get 12/5/2012 11:32:05 AM ,Which Agrees with what another tool I have list in the File.
Last Write Time : 12/5/2012 11:32:05 AM
Where the Problem comes in is when I try to use the same method you would use to do a hex to decimal conversion by hand as listed here http://www.webelfin.com/webelfindesign/hexdec.html
]. The Output from this type of Function returns a larger amount than what the built in calculator does.
The app that uses the function below takes as input the reversed hex string. Validates the input string. Then does a lookup on the hex values then stores those values in a collection. Then passes off to the function to do the x*(16^n) work. Then puts that in to a collection then adds them together then outputs the result to the window.
After resolving problems with the big calculations coming out as Scientific notation here is what I ended up with
Private Function ConvToDec(ByVal ipStr As List(Of Int64))
Dim Output As String
Dim idx As Integer
Dim strbldr As New StringBuilder
Dim strbldr2 As New StringBuilder
idx = ipStr.Count - 1
Dim fincoll As New Collection
For Each elm In ipStr
Dim nstr As Long = (elm * Math.Pow(16, idx))
idx = idx - 1
Dim finalString As String
Dim nindex As Integer
nindex = fincoll.Count
Dim nstr2 As Long
For Each itm As Long In fincoll
nstr2 = nstr2 + itm
finalString = nstr2
strbldr2.Append(itm & " ")
nindex = nindex - 1
Output = nstr2 & vbNewLine & vbNewLine & strbldr2.ToString
And Here Is the Output:
01CDD30E71B48B2E <---- Input Hex string
0 1 12 13 13 3 0 14 7 1 11 4 8 11 2 14 <------ converted bits
129992023254272814 <---- converted using the Calculator
2079872372068360000 <--- Numbers bleow Summed by excell
2079872372068365024 <------ Output Sum From Application
1152921504606846976 <----- Returned Calculated numbers.
I guess My question is, Is ther a problem with this function that I am not seeing or does it prove that calculating this way for large Conversions is not the best way to use that function ?
Of course after I posted I realized where the problem was.
I had to add a -1 as noted above for the Collection difference of starting from 0 or 1. The output now agrees with the calculator. I discovered after trying only 1 byte. I had been using half or all for my test.