bin2hex probs.....

[marco_xx]

hi,

if i use HEXDUMP.EXE from the example dir in /masm32/examples it generates a table like:

Code Select Expand



xnames db 54,53,32,48,48,32,54,57,32,55,50,32,54,70,32,55


if i convert it using:

Code Select Expand



.data
szFname_ascii db "d:\file_ascii.txt",0 ; plain text


bufferA       dB 560 dup(0)

.data?

xxxb dw ?


encode_write_ascii proc , inputx

invoke bin2hex,inputx,SIZEOF inputx,offset xxxb
mov esi,offset xxxb;bufferB



invoke write_data,inputx ; only writes: t203356 5 3 33      5333  t2Q 3      5333 26 5 323 53
; and not 0h,1dh,ffh etc......


ret
proc endp



This is really strange, bin2hex ......
if there was a tool like bin2DB for creating hextables......

names db 12h,13h,31h,0edh
db 0 ; for string.....

The way i do it now is using hexdump and MANUALY adjusting 0h, this is so boring......



anyway thanx for the help.

[dsouza123]

What is inputx ?

Unless it a pointer to a string you need
offset inputx

invoke bin2hex,offset inputx,SIZEOF inputx,offset xxxb  ; last parameter likely wrong

Remember dw isn't dword but a word
dd is for dword (aka double word, a 32 bit value).

db is byte
dw is word  2 bytes
dd is dword 4 bytes


For xxxb dw ? 
use xxxb dd ?

Also xxxb even as a dd it is just a pointer and not a buffer.
If it hold the address of a string then just have , xxxb

This is a good time o clear up some issues with the use of variables and API calls.

Code Select Expand


.data
  szInputBuf db "Whatever input text that is applicable goes here",0
  szOutputBuff db 256 dup (0)    ; holds the output
  lpInput dd 0
  lpOutput dd 0

.code
  mov lpInput, offset szInputBuf
  mov lpOutput, offset szOutputBuf
 
  invoke bin2hex, offset szInputBuf, SIZEOF szInputBuf, offset szOutputBuf
or
  invoke bin2hex, lpInput, SIZEOF szInputBuf, lpOutput
or
  invoke bin2hex, offset szInputBuf, SIZEOF szInputBuf, lpOutput
or
  invoke bin2hex, lpInput, SIZEOF szInputBuf, offset szOutputBuf


Just placing a string variable such as szInputBuf as a parameter,
without using offset
causes the first four bytes of its content to be pushed on the stack
not its address.

[marco_xx]

thanx

you saved my day.

[marco_xx]

I expirimented a bit with SEPERATORS...

Code Select Expand



seperator1  db "0",0
seperator2  db "h,",0

then i made a loop and formed my basic table.

This code has 2 bugs: formatting of hex... actualy spaces and line breaks.
And for some reason i cant write ANY buffer to disk...
But this is really cool stuff.













[attachment deleted by admin]

[marco_xx]

hmm i ran early`r on some problems. Symptoms where verry odd things like writing contents of the buffer "0h,1h,dh" as a file.
since i used segments in the .data section like this:

Code Select Expand


.data
;======== error handling:

error_stuff segment
ErrMsgTmpl db 'Error Code %i',13,10
      db 'Description: %s',0
      Unknown db 'UnKnownError',0
szerror  db "error detected!",0
error_stuff ends




and

Code Select Expand


filestuff segment
szFname db "d:\test.txt"
db 0
byteswritten db 0
bytestowrite db 200

filestuff ends



the program WRITES the output file to d:\test.txt

This happens EVERY time when i use LOTS of GLOBAL vars in the .data section.
Is this normal.. ? i dont understand why the filewrite problem is SOLVED with ONLY adding a segment.
Think i am onto something.  :cheekygreen:

Latest update: IT WORKS
Bugs:Spacing between 57h,0 123h,0 1fh,0 0ah,0 123h
strange.....










[attachment deleted by admin]

[marco_xx]

[solved everything]

Pfey this was quite hard.
bugs i solved:
* segments... proberly overlapping memory... i dunno...  :dazzled:
* small lib routines wich attach SPACES.... glad to have the source  :wink
* some bug in MY CODE with szmidstr that appended a 1,2,3,4,5 every 2th time the LOOP was run.

could not solve it if i didn`t  Worked around the bug hehehe (only needed a tool , not a stable version)
learned a lot.  :P


okay what it does now: takes a STRING and writes (hex)h,123h, etc to disc......
This is verry handy, verry hard to find
Have fun with the crappy source.








[attachment deleted by admin]