public/extern

[shankle]

Having just a tad of trouble with this.

ProgA - Public statement
ProgB - Extern statement
Both programs will compile clean without linking.

Assembled ProgA but not link - .obj created
Executed this command -  Masm32: ml ProgB.asm ProgA.obj
Now I get various Link errors. My book does not have most of the
errros listed.
Thanks for any suggestions.

[dedndave]

i did something similar a while back
only, i created a little static library - very similar to linking object modules
from that, i learned that EXTERNDEF replaces the old PUBLIC and EXTERN directives
also - PROC's are already public - no need to declare those (unless specified as PRIVATE in the PROC line)
so - you only have to mess with data

in the module where it is defined...

Code Select Expand

        EXTERNDEF   SomeData
the type is already known

in the modules where it is referenced...

Code Select Expand

        EXTERNDEF   SomeData:DWORD
or what ever the type is

here is that thread...
http://www.masm32.com/board/index.php?topic=15480.msg126841#msg126841

[shankle]

Yes I can change to the newer goody. But it doesn't solve my linking problem.
Darn vague error messages really tick my off.

[dedndave]

without seeing the source code and the command lines, can't help much further
maybe it would help if you put the OBJ(s) in a LIB, then linked with the main module

[MichaelW]

The command lines should be something like:

Code Select Expand


\masm32\bin\ml /c /coff ProgA.asm
\masm32\bin\ml /c /coff ProgB.asm
\masm32\bin\Link /SUBSYSTEM:CONSOLE ProgA.obj ProgB.obj


[zemtex]

You should replace public-extern with externdef and proto. The first one is more limited.

But if you still want to keep using the old one you must declare and define it to make it public and then only declare it in the other module to make it extern.

PUBLIC Somevariable          <- declared

.data

SomeVariable DWORD 0      <- defined, therefore it is public

assemble it by running

ml /c /coff /Cp ProgA.asm ProgB.asm
link /SUBSYSTEM:WINDOWS /LIBPATH:x:\xxxxx\lib ProgA.obj ProgB.obj

[hutch--]

Jack,

the purpose of PUBLIC and EXTERNDEF is to make values visible across modules. If you declare a variable PUBLIC in one module then assume it in another with EXTERNDEF then the second module can see the variable in another module.

PUBLIC is to share a value around, EXTERNDEF tells the assmbler that the value is defined in another module.

[dedndave]

Hutch,
i learned from RedSkull that EXTERNDEF may also be used to make a data label public

in the module where it is defined...

Code Select Expand

        EXTERNDEF   SomeData
the type is already known

in the modules where it is referenced...

Code Select Expand

        EXTERNDEF   SomeData:DWORD
or what ever the type is

[hutch--]

Dave,

That makes sense as there is a number of overlaps in MASM but I think for documentation purposes that using PUBLIC is clearer when you are writing multi-module code.

[dedndave]

ya know, i think you're right
i also like PUBLIC because it is the "old way"   :bg

[RuiLoureiro]

I use (without problems) a file ProgA.glb with

EXTERNDEF   SomeData:DWORD
...
ProcA       proto :DWORD
...
then INCLUDE ProgA.glb in ProgA and in ProgB
I never had problems

[shankle]

Thanks fellows for your help.

I have given up on "externdef". Can't get rid of the unresolved externals using it.
PROGA is a menu that passes a piece of data to PROGB. Progb never returns
to Proga.

Details of PROGA(menu): public progx
Progx is defined as follows: progx db  '                ',0 ; 16 bytes
This field is built in a loop with this code:
  mov cl, cc.cc1
  mov byte ptr progx[eax],cl
  cl is loaded from wParam which has the data I keyed in.

mainprog  db 'progb',0
invoke GetFulPathName, addr mainprog, 100, addr buf3, addr buf4
invoke winexec, addr buf3, sh_show
invoke exitprocess, null
This should take me to progb.


Details of PROGB: extern progx:byte
invoke GetFullPathName, addr progx, 100, addr buf3, addr buf4
At this point the program should place data from progx on the screen

Link process - compile Proga obj only. compile Progb obj only.
link /subsystem:console or windows proga.obj progb.obj
This takes me into progb without letting me key in the data from proga.

link /subsystem:console or windows progb.obj proga.obj
This lets me key in the data and hangs there - not going to progb.

Scratched all skin off top of head.......
 

 

[dedndave]

can you attach the source files ?

[shankle]

Source files are in an extreme state of flux.

[dedndave]

that's ok, Jack
i made a simple example...

in my previous posts, i was wrong about a couple finer points

in the module where data is defined, you do have to specify the type (if using EXTERNDEF)
in a module where an external proc is called, you need a prototype for it
you could use EXTERNDEF, but then you have to decorate the PROC names with "_"

in Module.asm, PUBLIC could be used instead of EXTERNDEF - it's up to you

attached is a simple example, including a batch file to build