http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK41420
(http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK41420%3Cbr%20/%3E)
I zipped up the entire directory of the example file I posted.
The workaround can be found in the souce. I put ;beforet the work around which is use a label not a proc.
seems it got moved:
http://lab.msdn.microsoft.com/productfeedback/SearchResults.aspx?text=&stype=1&fields=1&type=0&category=0&os=0&oslang=0&status=0&msstatus=0&resolution=0&chgdays=&validation=0&votes=&voterating=0&workarounds=False&attachments=False&product=0&version=0&creator=ThoughtCriminal&createdWithin=&submissionlang=0&productlang=0
Let us know if you get any feedback as various people here are interested in 64 bit MASM.
Reply:
QuoteThis is by design.
The C name decoration used by x86 requires an underscore be appended to each function (if you dump out the functions for an x86 image you will see this to be true... i.e. main becomes _main).
The assembler is behaving in the same way as the C compiler and auto appending this underscore.
you can view this on any obj for x86 by...
dumpbin -SYMBOLS t.obj
This is diffrent from previous versions of MASM. If you use PROC, you will be forced to use C name mangling.
I've tried everthing I can think of with EXTERNDEF, PUBILC - EXTERN, but nothing seems to make it reconizable to the linker so LNK2001 error.
There is a workaround, use a lable:
externdef ptr2main.PROC
ptr2main:
main PROC
.
.
endp
Lables work fine between multiple files.
If anyone else has the latest veris of masm and link, please test this. They say it's meant to be that way, but if you can link mutiple objs together is should be a bug.
Hmm this linker flag makes it work even without the label:
/Zf Makes all symbols public.
Using this flag adds a type to symbol in the object file: Type: DT_FUNCTION (peview)
DT_FUNCTION is not present in the PECOFF docs.