FormatMessage Error

[raleeper]

I am giving up on the FormatMessage Error problem.

Don't give up so easily, no mystery is safe in the Masm32 Forum:

Code Select Expand

include \masm32\include\masm32rt.inc

.radix 16  ; test with and without
MyTest PROTO: DWORD, :DWORD

.code
AppName db "Masm32 is great!", 0
Hello db "A message:", 0

start:
invoke MyTest, offset AppName, addr Hello
exit

MyTest proc arg1:DWORD, arg2:DWORD
LOCAL msg:MSG, wx:HWND
  MsgBox 0, arg1, arg2, MB_OK
  ret
MyTest endp

end start


Olly reveals that the LOCALs are, well, a bit odd. Check for sub esp, xx :bg

Interestingly enough, JWasm produces the same nonsense.

Well, I'm not going to work on it now, and asking others to go on seems to me just like asking others to do (not help with) your homework.  So I won't.

Thanks, Robert

[jj2007]

Robert, don't worry - we just discovered a Masm bug thanks to your problem. That's like having a party in the Forum - champagne!! :green2

[raleeper]

Robert, don't worry - we just discovered a Masm bug thanks to your problem. That's like having a party in the Forum - champagne!! :green2

Well, that vindicates my "curse Microsoft" to some extent.

I'll watch your further progress with considerable interest.

Thanks

[raleeper]

Robert, don't worry - we just discovered a Masm bug thanks to your problem. That's like having a party in the Forum - champagne!! :green2

Well, that vindicates my "curse Microsoft" to some extent.

I'll watch your further progress with considerable interest.

Thanks

If I used pushed the parameters, used 'call FormatMessage' instead of 'invoke...' and did my own stack cleanup (for 4 parameters that would just be 'add esp 16d' [and maybe also restore ebp] wouldn't it?),, might that be a viable workaround until a masm patch is available.  Or is the bug more pervasive?
{This is still low priority for me.  Even if you say 'try it, I might not get aroun to it for a while)

[dedndave]

i think it's easier to avoid the radix of 16   :U

[ToutEnMasm]

delet the .radix in testp and recompile,you see :

E:\poubelle
Assembling: essai.asm
E:\poubelle
Assembling: testp.asm
testp.asm(306) : error A2048: nondigit in number
testp.asm(333) : error A2048: nondigit in number
testp.asm(334) : error A2048: nondigit in number
testp.asm(390) : error A2048: nondigit in number
testp.asm(391) : error A2048: nondigit in number
testp.asm(393) : error A2048: nondigit in number
testp.asm(399) : error A2048: nondigit in number
testp.asm(414) : error A2048: nondigit in number
testp.asm(462) : error A2048: nondigit in number
testp.asm(466) : error A2048: nondigit in number
testp.asm(467) : error A2048: nondigit in number
testp.asm(474) : error A2048: nondigit in number
testp.asm(327) : error A2006: undefined symbol : dspl_0

seems the .radix (not very used) have some strange effects

[ToutEnMasm]

The badest effect is that you are lose in your syntax.

   invoke   CreateFontIndirect,edi
   mov   [hfont1], eax   ;<------------------------------------------ mov hfont1,eax        N errors like this

use
.if eax ==
.endif

instead off:
  cmp eax,value
Jxxx

Masm is able to translate a .if in the correct jxx and put also the label for you.

[ToutEnMasm]

and finally the big error:

chinst   DD   0         ;14 Dwords at 14,18,1C and 2C are copied
   DD   0         ;18   from LFwc in newwin
   DD   0         ;1C
   DD   0         ;20 From CreateSolidBrush,0EEEE00
   DD   0         ;24
   DD   ChldClass      ;28 ClassName
   DD   0         ;2C

Use structures

NAME STRUCT
chinst   DD   ?         ;14 Dwords at 14,18,1C and 2C are copied
name1   DD   ?         ;18   from LFwc in newwin
name2   DD   0         ;1C
name3   DD   0         ;20 From CreateSolidBrush,0EEEE00
   DD   0         ;24
   DD   ChldClass      ;28 ClassName
   DD   0         ;2C

NAME ENDS

[raleeper]

and finally the big error:

chinst   DD   0         ;14 Dwords at 14,18,1C and 2C are copied
   DD   0         ;18   from LFwc in newwin
   DD   0         ;1C
   DD   0         ;20 From CreateSolidBrush,0EEEE00
   DD   0         ;24
   DD   ChldClass      ;28 ClassName
   DD   0         ;2C

Use structures

NAME STRUCT
chinst   DD   ?         ;14 Dwords at 14,18,1C and 2C are copied
name1   DD   ?         ;18   from LFwc in newwin
name2   DD   0         ;1C
name3   DD   0         ;20 From CreateSolidBrush,0EEEE00
   DD   0         ;24
   DD   ChldClass      ;28 ClassName
   DD   0         ;2C

NAME ENDS

You mean to tell me that a block of data declared with a label as I have done will assemble differently than the same thing done with a structure?  In either case won't eg., hbkbr or LFwc.hbkbr evaluate to LFwc+20h?  And the OS will put the same value in ebp and all references to the block or structure will be [ebp+something], and the same thing whether the data is declared one way or the other, which the OS won't even know.  What am I missing?

For reference, my block is:

Code Select Expand



LFwc LABEL DWORD ;LFile Window Class structure
DD SIZEOF WNDCLASSEX ; 0 wc.cbSize
DD lfstyle ; 4 wc.style
DD OF WProc ; 8 wc.lpfnWndProc
DD 0,0 ;0C wc.cbClsExtra, wc.cbWndExtra
hinst DD ? ;14 wc.hinst
hicon DD ? ;18 LoadIcon,0,IDI_APPLICATION
hcurs DD ? ;1C LoadCursor,NULL,IDC_ARROW
hbkbr DD ? ;20 CreateSolidBrush,0FF0000h
wcmen DD 0 ;24 wc.lpszMenuName
DD OF ClassName ;28 wc.lpszClassName
hiconsm DD ? ;2C wc.hIconSm
;30 end LFwc


(Please pardon the tabs)

[jj2007]

Nothing wrong with the tabs. Old versions of MS Internet Explorer had problems, but FF always handled them well:

Don't open "attached" tabs.zip - it is just the screenshot you see above.

@ToutEnMasm: What you write looks very improbable. Could you post a working example showing the effect you are claiming? Merci.

[raleeper]

@ToutEnMasm: What you write looks very improbable. Could you post a working example showing the effect you are claiming? Merci.

Sure.  I can't tell if the child window is really showing correctly since it's undeveloped, but the main window seems to have no problems'

[ToutEnMasm]

Without the used of .iF and structures,masm couldn't verify that all is well written.
The big error is here.It is just laborious write with no secure.

[jj2007]

Sure.  I can't tell if the child window is really showing correctly since it's undeveloped, but the main window seems to have no problems'

Example back. If have added a trailing h wherever I could so that you can switch between radix 10 and 16. CreateWindowEx is misbehaving for radix 16....

Depending on whether you assemble with radix 10/16, code size differs considerably. Really strange.

@ToutEnMasm: You are on the wrong track. Try a more constructive approach please.

Edit: The wrong stack alignment is present up to MASM version 8.0. Version 9 and 10, and the latest JWasm version, work fine

[ToutEnMasm]

@ToutEnMasm: You are on the wrong track. Try a more constructive approach please.

Perhaps can you give those remarks for you ,No ?
and if not is the same.
if the macro language exists is to help writing      ;<--------------------------------------

[jj2007]

It seems the PROLOGUE/EPILOGUE macros are affected...

end of CWProc:

Code Select Expand

CPU Disasm
Address    Hex dump          Command                      Comments
004013E3   ³.  E8 4A010000   call <jmp.&user32.DefWindowP ; ÀUSER32.DefWindowProcA
004013E8   ³.  61            popad
004013E9   ³.  5D            pop ebp
004013EA   ³.  C2 1600       retn 16  <<<<<<<<<<<<<<<< retn 10 for the radix 10 version
004013ED   ³>  61            popad
004013EE   ³.  33C0          xor eax, eax
004013F0   ³.  5D            pop ebp
004013F1   ³.  C2 1600       retn 16  <<<<<<<<<<<<<<<< retn 10 for the radix 10 version