News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

error msg?

Started by shankle, June 26, 2012, 12:49:14 AM

Previous topic - Next topic

shankle

OK JJ,
Took out the EBP and the same problem persists.
Thanks

jj2007

Post the exe, maybe with Olly I could tell you more.

satpro

#107
Quote from: shankle on July 15, 2012, 08:57:01 PM
This is not about my main problem but am curious why this messagebox is causing problems.
This code causes the messagebox to go into a loop from which I have to
reboot the puter to get out of it. It never goes to WM_CREATE.
WndProc:
        FRAME  hWnd,iMsg,wParam,lParam
        USES ebp,ebx,edi,esi
        Local hMemory,stm:SYSTEMTIME,ps:PAINTSTRUCT,hdc,hdcPrn
       
;   USED ONLY DURING TESTING PHASE
DATA SECTION <--Try adding this
;TM8              db   'begin of wndproc',0
CODE SECTION <--and this
      pushad <-- why?
      invoke MessageBox, NULL,addr TM8,NULL,MB_OK 
      popad <-- why?   
;   test end

     


Are you putting the string in label TM8 right in-line with your code, or do you keep the semi-colon (comment) when you test and put the data elsewhere?  If the semi-colon is removed and that's your actual data, then put "DATA SECTION" right before and "CODE SECTION" right after the string line.  I would say the computer thinks the string is code and is trying to execute it.  It's right in the middle of a code section.  Also, jj is right--the EBP needs to come out.  Is that message box the first thing in your Window procedure?  If so, it's getting called a lot.


jj,
You can cut & paste that mouseover stuff and make snarky demands all day long.  That doesn't change the fact that you're unwilling to admit to pushing registers un-necessarily.  I'm done with the back and forth.  Insult someone else.

dedndave

the MessageBox API preserved EBX, EBP, ESI, and EDI for you
you don't have anything in EAX, ECX, or EDX that needs to be preserved
WndProc:
        FRAME  hWnd,iMsg,wParam,lParam
        USES ebx,edi,esi
        Local hMemory,stm:SYSTEMTIME,ps:PAINTSTRUCT,hdc,hdcPrn

      invoke MessageBox, NULL,addr TM8,NULL,MB_OK

;.WM_CREATE
        cmp D[iMsg],WM_CREATE
         jne >>.WM_CHAR

even if that does "work", it's going to generate a lot of message boxes - lol
when a window is created, it receives several messages
if you're not using Vista, you might be happier using Beep...
WndProc:
        FRAME  hWnd,iMsg,wParam,lParam
        USES ebx,edi,esi
        Local hMemory,stm:SYSTEMTIME,ps:PAINTSTRUCT,hdc,hdcPrn

      invoke Beep,800,40

;.WM_CREATE
        cmp D[iMsg],WM_CREATE
         jne >>.WM_CHAR

shankle

Hi JJ,
Here is the ".exe" of my attempt at GoAsm.  I have zipped it to
conform to Hutches regs.
It is NOT a working program. It will take you to the Wndproc 
and die right there.
Have fun. I sure am ;)

shankle

Hi Satpro,
I sent you a message (I thought), Must have been in Sandboxie when I did it.
The TM statement is just there to remind  me what I coded.
It is defined in the Data Section.
I have remove  ebp.
I thought that the ";" was recognized in GoAsm as a comment. Am I wrong?

This messagebox is for testing ONLY. It will be removed as I get the program
working. Push/pop is there in the event i missed something which I obviously
have.

shankle

HI Dave,
Using Window 7 pro.
It does generate a lot of messages. Don't understand why.
Taking out the push/pop doesn't really make it any better.
Purpose in using it was to find out were my code was taking me.

satpro

Hi shankle,


Yes, the ";" is a comment.  Block comments are /* and */.  (no period)
I didn't know if you pulled the semi-colon to run the code.  I really do think you need to move that message box call.  Every time you get any kind of message that thing will run because it's first up in the WndProc.


I really hope you stick with GoAsm.  I like Masm, too, but just really enjoy coding with GoAsm.  Granted, there's a lot more code written for Masm and this is a Masm forum, but Jorgon really wrote a nice assembler and linker.  It's not laden with lots of extras, and is basically a 32/64-bit-only assembler, which is great.  It's simple, but powerful.  Kind of like the assembler I started with way back when.  And man, is it fast!  The thing I'm doing now is about 72k with about 30 files and it finishes in a couple of seconds.  I did have to read through the manual several times and usually keep it open while I program for things like syntax.  I use it with Notepad++ and can keep all the files right there with asm color-coding and unreal search/replace features.  It compiles & executes right from the editor.  The big difference between that and qeditor, which I like, too, is the tabbed files and multiple document (side by side) views.  What do you use?


Also, do you think there's any way I could look at the source (the startup, winmain, and data declaration) for your test program?  Maybe print it out and look at it closer.  The answer might just be "right there."  You never know.  I downloaded the .exe but didn't run it yet.  I've got a lot of stuff opened up right now 'cuz I'm coding.  But once we get your Window procedure ironed out you should be good to go.  That really is the hard part in the beginning.  Later, you'll laugh about it, I promise.

shankle

Hi Satpro,
Right now I'm in Frown mode.
I kind of expected it to work right out of the box.
Yes, It's going to be some kind of embarrassing error.

I started back in the 60s with the Assembler from IBM.
I like it better than Masm or GoAsm. It had a length code for everything
which I kind of miss.
It always is.

jj2007

Quote from: shankle on July 16, 2012, 06:49:42 AM
Hi JJ,
Here is the ".exe" of my attempt at GoAsm.  I have zipped it to
conform to Hutches regs.
It is NOT a working program. It will take you to the Wndproc 
and die right there.
Have fun. I sure am ;)

Thanks. As it seems, the very first message quits with a "ret", not with calling DefWindowProc; and of course it returns to no man's land. So you better check why the WM_CREATE handler does not call DefWindowProc.

As a general remark, using a MsgBox at the entry of WndProc cannot work (I think satpro mentioned that already). You better use console assembly & link, and a pushad / print whatever / popad sequence.

HTH, jj

shankle

Thank you JJ.
You made me take another look at WM_DESTROY.
When I converted this from MASM32 to GoAsm I got the
branch wrong.
Now the 1st window is flashing on the screen and goes to
"the program has stopped working".
To tired tonight. Will give it a rest and try tomorrow to
figure it out.

wjr

The other correction would be at the end of each message that you do process to place a jmp instruction (otherwise you continue the message comparisons and eventually end up at DefWindowProc). So it should look like something this:

jmp >.Return0     ;<--- at the end of each message that you process, usually should return 0
.WM_DESTROY
cmp D[iMsg],WM_DESTROY
jne >.Default      ;<--- no more messages to check, so pass do DefWindowProc
.Return0
xor eax,eax        ;<--- message processed, usually return 0
.Return
ret
.Default
INVOKE DefWindowProc, [hWnd], [iMsg], [wParam], [lParam]
ret

shankle

Getting there.
GoAsm complains about the 1st branch to Out2.
As you see it, it complains that the branch is to far.
If I change it to "jl >>.Out2" it gives an error message that
it is past the end of the program.       

       cmp D[holdR], 5
         jl >.Out2   ;** GoAsm complains about this branch**       
       add ebx, 4
       invoke WriteToPrinter, [hdcPrn],2926,3206,1837,ebx         
       cmp D[holdR],6
         jl >.Out2       
       add ebx, 4
       invoke WriteToPrinter, [hdcPrn],2926,3206,2035,ebx         
       cmp D[holdR],7
         jl >.Out2       
       add ebx, 4
       invoke WriteToPrinter, [hdcPrn],2926,3206,2233,ebx         
       cmp D[holdR],8
         jl >.Out2       
       add ebx, 4
       invoke WriteToPrinter, [hdcPrn],2926,3206,2430,ebx   
     
.Out2       









wjr

I shall look into correcting the Line Number given for that GoAsm error.

I suspect that your code snippet is not within a FRAME...ENDF. In that case, your labels beginning with a period (.Out2) have a local scope extending between the unique code labels with a colon that surround it. In other words, the label for the jump in jl >>.Out2 is not found since between the jump instruction and the jump target you have at least one unique label "SomeLabel:" defined. Some solutions...

- The above does not take place within a FRAME...ENDF block; the scope of the label is local to FRAME...ENDF.
- Perhaps you can go more local with ".SomeLabel" instead of "SomeLabel:"
- Use an unscoped re-usable label made up of digits or a character+digit(s):

cmp D[holdR],5
jl >>L2
;
;
SomeLabel:
;
;
L2:

shankle

Thanks WJR for replying.
I did not fully understand what you just wrote.
So let me explain my code more fully.
The code in the snippet above is within the Wndproc frame/endf code.
They should all be of a local scope I think. At least that's what I intended.
As you can see from the snippet there is nothing between the first Out2
and the label ".Out2" other than other Out2s.