News:

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

Main Menu

Procs on console projects: Where?

Started by AssemblyChallenge, July 07, 2015, 02:42:34 AM

Previous topic - Next topic

AssemblyChallenge

Hi all.

This is a no brainer on GUI projects but is killing me on console ones: Where should I put the Proc(s) code ??

Acording to MASM examples should be something like:


include1
include2
etc
.............
TheProc  PROTO ; not needed on EasyCode
...............
.data
..................
.code
main proc
.
invoke TheProc
.

invoke ExitProcess,0

main endp
..................
TheProc proc
    .
    code
    more code
    etc
    .
    ret
TheProc endp
..................
end main


My problem: If I put the Proc's code between Main and End, the theoretical "right" place:


Main EndP

   TheProc Proc
       blah
   TheProc Endp

End start


I get syntax errors, undefined symbols, etc. all over the Proc(s), even its labels explode. In the other hand, placing the Proc(s) outside of everything throws "unresolved external symbol" (which seems legit):


Main EndP

End start

TheProc Proc
       blah
TheProc Endp


The odd part: I'm very sure it was compiling fine with the first approach and then all of the sudden stopped working  :dazzled:  In EasyCode we don't need PROTO (which I tested anyway) so, what am I doing wrong here ??  :shock:

dedndave

Quote from: AssemblyChallenge on July 07, 2015, 02:42:34 AM
My problem: If I put the Proc's code between Main and End, the theoretical "right" place:

some old school teaching was that dependent routines went first
it shouldn't really matter, so long as you have a PROTO

Quote from: AssemblyChallenge on July 07, 2015, 02:42:34 AM

Main EndP

   TheProc Proc
       blah
   TheProc Endp

End start


"start" is defined in the end statement, but the entry is "Main"   :P

rrr314159

There's confusion between "main" and "start". Normally you wouldn't have both. One of them is defined as your entry in the linker statement, that's the (only) one to use. You can't put procs, or any other code, after the "real" end statement. Apart from that they can go anywhere above (except of course inside another proc, or structure or macro definition, and after .code of course). As long as there's a proto statement at the top you're ok; you can leave that out when the proc is called only from below, so - to keep things simple - just always put it in.

Quote from: AssemblyChallengeI'm very sure it was compiling fine with the first approach and then all of the sudden stopped working  :dazzled:

- you must have  changed something to do with the end statement (confusion between start and main), that's what u need to straighten out, not the proc placement

I am NaN ;)

AssemblyChallenge

Thank you guys.

One mistake on my behalf was using "End" as a Label  :icon_redface: . Yet, the biggest reason for compiling errors was using the Local directive inside the Procs.

Not sure if EasyCode takes the procedure's variables as local by default; couldnt find it on the manual. Maybe Ramon could make it clear for me if:


MyProc1 Proc Public
Local MyVar DB 'A', 0 ; this way fails compiling
       
        ; rest of the code
Ret
MyProc1 EndP


Is the same as:


MyProc1 Proc Public
MyVar DB 'A', 0 ; this one compiles fine
       
        ; rest of the code
Ret
MyProc1 EndP


With no risk of misunderstanding by the compiler.

dedndave

the syntax for local variables is different than globals

MyFunc PROC

    LOCAL   bLocal        :BYTE    ;1 byte
    LOCAL   abLocal[24]   :BYTE    ;24 bytes


notice that, in MASM, locals are always uninitialized
if you want them initialized, you have to do it with code

AssemblyChallenge

What the heck. I was defining local strings in a very very happy way  :lol:


Local MyString:DB "My string defined", 0


No wonder it failed  :icon_redface: Your explanation makes a lot of sense and my book only has examples of strings passed as parameters but not defined internally in the Procedures.

You nailed it. Thank you.  :t :t