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.
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...
EXTERNDEF SomeData
the type is already known
in the modules where it is referenced...
EXTERNDEF SomeData:DWORD
or what ever the type is
here is that thread...
http://www.masm32.com/board/index.php?topic=15480.msg126841#msg126841
Yes I can change to the newer goody. But it doesn't solve my linking problem.
Darn vague error messages really tick my off.
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
The command lines should be something like:
\masm32\bin\ml /c /coff ProgA.asm
\masm32\bin\ml /c /coff ProgB.asm
\masm32\bin\Link /SUBSYSTEM:CONSOLE ProgA.obj ProgB.obj
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
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.
Hutch,
i learned from RedSkull that EXTERNDEF may also be used to make a data label public
in the module where it is defined...
EXTERNDEF SomeData
the type is already known
in the modules where it is referenced...
EXTERNDEF SomeData:DWORD
or what ever the type is
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.
ya know, i think you're right
i also like PUBLIC because it is the "old way" :bg
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
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.......
can you attach the source files ?
Source files are in an extreme state of flux.
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
Thanks guys for your suggestions.
I've already wasted a day playing with this. It's just not worth the hassle.
I'll try another way to skin the cat.
Create a file. Put the data I want to transfer in it.
Read it in the other program and I am done.
No hassle. No problems with the linker and less confusion.
That should end this thread.
Quote from: Shankleinvoke exitprocess, null ;This should take me to progb.
No, it should not. It should exit your program. You need to read up on
modules. If you link two programs together they become two modules in one program. You can only have one entry point and one exit point.
The advantage of EXTERNDEF is that it can be put into an include file and it will act as either PUBLIC or EXTERN, as required, depending on which module it is included in. Otherwise PUBLIC and EXTERN work just as well.
Quote from: dedndaveyou could use EXTERNDEF, but then you have to decorate the PROC names with "_"
I have never had to decorate the PROC names with an underscrore, I don't think that's the case.
sounds to me like CreateProcess would be usable, here
you want ProgramA to run ProgramB
another way to go is to create a thread - not sure that's what you want
creating a thread may sound scary, but it's even simpler than CreateProcess, in many ways