passing a string array from c++ into a masm function that will be called by c++

[qWord]

I've just asked on Embacadero's forum

a really funny forum: C++64 memcpy performance (read the 1. and 4. post)   

[jj2007]

mov al,[rdx]

DednDave and jj2007 vote for rep movsb 8)

[dedndave]

well - rep movsd isn't bad - lol
at least, not if both source and dest are 4-aligned

[bobl]

That's quite an eye opener re the 64bit stuff.

To add kernel32.lib I tried...
shift/F11,
adding it's directory to the path environment variable
and looking for a header file to include (there doesn't seem to be a kernel32.h)
but am still not seeing it on the linker line. I guessing I should.
I asked on Embarcadero's forum this morning how to do this but no-one's come back.
Does anyone here know?
I feel a bit embarrased asking.

[Gunther]

Hi qWord,

a really funny forum: C++64 memcpy performance (read the 1. and 4. post)   

that's real fun.  :t

Gunther

[qWord]

bobl,
you only need to add .....lib\PSDK\kerenl32.lib  to the linker command line as you did is with the object file created by MASM.
(Because this lib comes with your compiler, there is no need to convert it).

[bobl]

Thanks for the advice. I thought I'd tried that but just double checked.
I added the masm obj/lib using shift/f11 and selecting the files.
I've just used shift/F11 with BCB's own kernel32.lib

Here's the linker line now...

Code Select Expand


Linker command line
  -Tpe -Gn -v -L"c:\program files\borland\bds\4.0\lib\debug";C:\my_delphi\my_cbuilder2006\proj4;"c:\program files\borland\bds\4.0\lib";"c:\program
  files\borland\bds\4.0\lib\obj";"c:\program files\borland\bds\4.0\lib\psdk";"c:\program files\borland\bds\4.0\Include\Indy9";"c:\program
  files\borland\bds\4.0\Lib\Indy9";"C:\Documents and Settings\me\My Documents\Borland Studio Projects\bpl" -j -x -LC:\my_delphi\my_cbuilder2006\proj4
  -GA"C:\my_delphi\my_cbuilder2006\proj4\vfs27.tmp"="C:\my_delphi\my_cbuilder2006\proj4\Project1.res" c0x32.obj vcl.bpi rtl.bpi vclx.bpi dbrtl.bpi
  vcldb.bpi adortl.bpi dbxcds.bpi dbexpress.bpi vclib.bpi ibxpress.bpi xmlrtl.bpi vclactnband.bpi inet.bpi IntrawebDB_80_100.bpi Intraweb_80_100.bpi
  vclie.bpi inetdbbde.bpi inetdbxpress.bpi indy.bpi bcbsmp.bpi soaprtl.bpi dsnap.bpi bcbie.bpi bdertl.bpi teeui.bpi teedb.bpi tee.bpi vcldbx.bpi
  memmgr.lib sysinit.obj C:\my_delphi\my_cbuilder2006\proj4\Debug_Build\Unit1.obj
  C:\my_delphi\my_cbuilder2006\proj4\myomfdmasm.obj,C:\my_delphi\my_cbuilder2006\proj4\Debug_Build\Project1.exe,C:\my_delphi\my_cbuilder2006\proj4\Debug_Build\Project1.map,import32.lib
   C:\my_delphi\my_cbuilder2006\proj4\mas32_omfd.lib "C:\Program Files\Borland\BDS\4.0\lib\psdk\kernel32.lib" cp32mti.lib,,
  C:\my_delphi\my_cbuilder2006\proj4\vfs27.tmp
[Linker Error] Error: Unresolved external '_GetStdHandle@4' referenced from C:\MY_DELPHI\MY_CBUILDER2006\PROJ4\MAS32_OMFD.LIB|stdout.obj
[Linker Error] Error: Unresolved external '_WriteFile@20' referenced from C:\MY_DELPHI\MY_CBUILDER2006\PROJ4\MAS32_OMFD.LIB|stdout.obj


The line

Code Select Expand


   C:\my_delphi\my_cbuilder2006\proj4\mas32_omfd.lib "C:\Program Files\Borland\BDS\4.0\lib\psdk\kernel32.lib"

suggests that kernel32.lib is added
I also note that...."c:\program files\borland\bds\4.0\LIB\psdk" ie kernel32.lib's directory is there too higher up.
I'm therefore surprised that I'm still getting the error that you can see on the  end of the linker command line

Check out the attached image

FWIW _GetStdHandle@4 is not in kernel32.lib oer se but there is a single reference to GetStdHandle enclosed by ^L symbols

[bobl]

Here's the bit of kernel32.lib that contains getstdhandle.
I have no idea whether it is what is expected or not.
BTW I'm not expecting the masm forum to be BCB experts and have posted this question on the compiler's own forum.

Code Select Expand


mpletionStatus.KERNEL32.dll.Έ%.. ...GetShortPathNameA.KERNEL32.dll.†ˆ%.. ...GetShortPathNameW.KERNEL32.dll.pˆ#.. ...GetStartupInfoA.KERNEL32.dll.)ˆ#.. ...GetStartupInfoW.KERNEL32.dll..ˆ .. ...GetStdHandle.KERNEL32.dll.xˆ".. ...GetStringTypeA.KERNEL32.dll.'ˆ$.. ...GetStringTypeExA.KERNEL32.dll.Ј$.. ...GetStringTypeExW.KERNEL32.dll.ºˆ".. ...GetStringTypeW.KERNEL32.dll.{ˆ(.. ...GetSystemDefaultLCID.KERNEL32.dll.yˆ


[bobl]

The plot thickens...
If i do

Code Select Expand


extern GetStdHandle;
extern WriteFile;

I get

Code Select Expand


C++ command line for "Unit1.cpp"
  -D_DEBUG -DUSEPACKAGES;NO_STRICT;_RTLDLL -H="c:\program files\borland\bds\4.0\lib\vcl100.csm" -Hc -w-par -Od -b- -k -y -v -vi- -tWC -tWM -tW- -c
  -IC:\my_delphi\my_cbuilder2006\proj4;"c:\program files\borland\bds\4.0\include";"c:\program files\borland\bds\4.0\include\dinkumware";"c:\program
  files\borland\bds\4.0\include\vcl";"c:\program files\borland\bds\4.0\Include\Indy9";"c:\program files\borland\bds\4.0\Lib\Indy9"
  -oC:\my_delphi\my_cbuilder2006\proj4\Debug_Build\Unit1.obj -Hr"vcl.h"="vcl.h"
[C++ Error] Unit1.cpp(11): E2356 Type mismatch in redeclaration of '__stdcall GetStdHandle(unsigned long)'
[C++ Error] winbase.h(3550): E2344 Earlier declaration of '__stdcall GetStdHandle(unsigned long)'
[C++ Error] Unit1.cpp(12): E2356 Type mismatch in redeclaration of '__stdcall WriteFile(void *,const void *,unsigned long,unsigned long *,_OVERLAPPED *)'
[C++ Error] winbase.h(3569): E2344 Earlier declaration of '__stdcall WriteFile(void *,const void *,unsigned long,unsigned long *,_OVERLAPPED *)'


If I extern the same symbols that the linker is complaining about

Code Select Expand


extern _GetStdHandle@4;
extern _WriteFile@20;

I get

Code Select Expand


C++ command line for "Unit1.cpp"
  -D_DEBUG -DUSEPACKAGES;NO_STRICT;_RTLDLL -H="c:\program files\borland\bds\4.0\lib\vcl100.csm" -Hc -w-par -Od -b- -k -y -v -vi- -tWC -tWM -tW- -c
  -IC:\my_delphi\my_cbuilder2006\proj4;"c:\program files\borland\bds\4.0\include";"c:\program files\borland\bds\4.0\include\dinkumware";"c:\program
  files\borland\bds\4.0\include\vcl";"c:\program files\borland\bds\4.0\Include\Indy9";"c:\program files\borland\bds\4.0\Lib\Indy9"
  -oC:\my_delphi\my_cbuilder2006\proj4\Debug_Build\Unit1.obj -Hr"vcl.h"="vcl.h"
[C++ Error] Unit1.cpp(11): E2206 Illegal character '@' (0x40)
[C++ Error] Unit1.cpp(11): E2141 Declaration syntax error
[C++ Error] Unit1.cpp(12): E2206 Illegal character '@' (0x40)
[C++ Error] Unit1.cpp(12): E2141 Declaration syntax error


[bobl]

This looks similar to what I'm encountering
http://stackoverflow.com/questions/14726346/how-do-i-link-with-freepascal-a-nasm-program-calling-a-dll

[Dubby]

I believe it's a linker requirement. it's delphi product right? usually they go with the OMF file format for the linker , if I'm not mistaken.
I found this thread : http://forum.dlang.org/thread/j0u16n$1g7t$1@digitalmars.com

for digital mars though, but it seem that the problem is the same.

so give this: http://ftp.digitalmars.com/coffimplib.zip a try..
good luck..

[bobl]

Dubby
I just assumed BCB's lib was OMF but maybe not...it never occurred to me.
Here's my attempt...

Code Select Expand


C:\Program Files\Borland\BDS\4.0\lib\psdk>coff_import_lib_to_omf_import_lib kern
el32.lib kernel32_omf.lib -f -l -v
coff2def 0.01
Error: missing archive signature

I don't know what "missing archive signature means" but it was well worth a try.
Thanks for the suggestion.
It does beg the question though how do you know whether somethings in OMF format or not unless you convert it.
I'll give it the objconv treatment...and see if that works
Edit:
It didn't...I get the same errors.
Thinking about it...this isn't surprising because up until now...every time there's been an OMF-incompatibility the compiler/linker has signalled it and it's always been solved with objconv. There's no such signal with kernel32.lib.
An embarcadero forum member seems to think that my error messages show more decoration than there should be and that this might be a cdecl vs std_call incompatibility...I don't know...Any suggestion re the best way to test this?
I'm quite happy to follow this up but don't know how.

[Dubby]

wait wait, wait,, just to make everything clear..

1.  the unresolved come from masm assembled files right? what is the file? is it obj file or a lib file?
2.  is it OK if you write the function which uses those, which caused unresolved error, with the C++ compiler ? in this case is BCB2006. right?
3.  from where the kernel32.lib you link came from..?

as I never encountered with BCB, I can't really sure what is the problem like. my last suggestion is, if the result from question number 2 is OK, then you can open the obj or other similar file that the compiler produce with any hex editor and search the string which caused the previous error.. and see how's they looks..? I mean the decorative name or symbol or something like that..

[japheth]

An embarcadero forum member seems to think that my error messages show more decoration than there should be and that this might be a cdecl vs std_call incompatibility...I don't know...Any suggestion re the best way to test this?

I guess this is a correct assumption - the Borland import libraries contain undecorated publics ( missing the '_'-prefix and the '@nn'-suffix ).

Consequently, any coff2omf utilities won't fix this issue.

There are a few possibilities how a solution might be achieved:

1. create an OMF import library that contains decorations ( OW wlib or jwlib can do this )
2. adjust the source that contains the decorated imports and make it use undecorated variants
3. use another linker that can both handle OMF and COFF import libraries

All options are a bit "advanced".

[bobl]

Dubby
I'm very grateful for your thoughts and agree that narrowing down the source of the problem by elimination
i.e. testing that this is not an inherent problem in BCB2006 itself is a good idea.
My problem is...my knowledge at this level is all but non-existent and I wouldn't know what to use in c++ to exercise these symbols. I do need to address this weakness and am only going to do this through exposure so perhaps this problem is no bad thing.

Japeth
>a bit "advanced"
You're not joking but I suppose I'm asking for trouble doing what I'm trying to do with my limited understanding so it's sort of self-inflicted. Of the three options I'd prefer...the JWLink one
i.e. a while back it succeeded (in MichaelW's hands) on some gcc stuff where gcc's own failed
and since then I've always thought that when I get around to "doing" linkers...JWLink would be the one.
Perhaps it's about time now.
Having said that to solve this sort of problem I probably need to at least understand what all 3 options really do.
I'll have a read around.
Thank you very much indeed for the pointers.