Golink bug or my mistake?

[Fredericvo]

I'm trying to port a simple DX9 program compiled with VC++10 to goasm and I'm facing some hurdles.

First I used Adaptasm which, to be honest, was disappointing as it made very little changes and didn't seem to recognise the single most recurring change to make:
i.e. MOV DWORD PTR offset[EBP],EAX became MOV Doffset[EBP],EAX rather than the intended MOV D[EBP+offset],EAX
so I manually updated all of them.
I was able to assemble the result but now it's Golink which gives me a headache.
I'm linking against kernel32.dll user32.dll d3d9.dll d3dx9_43.dl msvcrt.dll and still getting these errors:

Error!
The following symbols were not defined in the object file or files:-
_memset
c0000000h
_D3DXMatrixLookAtLH@16
_D3DXMatrixPerspectiveFovLH@20
_D3DXMatrixTranslation@16
_D3DXMatrixRotationY@8
_D3DXMatrixMultiply@12
c0400000h
_memcpy
Output file not madel

the d3dx9_43.dll seems to be the one on my system and anyway the one which the VC++ generated exe was linked against too. Then memset & memcpy seem to require msvcrt.dll but it doesn't work either. More alarming are the c0000000h & c0400000h as I do not have any such symbols as such but there are lines such as
__real@c0000000 DD c0000000h         ; -2
__real@41200000 DD 41200000h         ; 10

for defining floating point values fed to the matrices, so I'm afraid golink (or goasm?) sort of doesn't interpret this correctly.

Not sure if I can post the whole listing here as it might burden the forum. It's one of the simple dx tutorials which displays the spinning gouraud-shaded triangle.

[jj2007]

Not sure if I can post the whole listing here

Don't worry. Zip it and attach - as long as it's below 256k, it's ok.

Can't help you with the linker issue, as I use Masm32, but it might be a decoration issue.

Welcome to the Forum :thumbu

[wjr]

Hex numbers need to begin with a digit. To fix two of those errors, change those lines with c0000000h and c0400000h to 0c0000000h and 0c0400000h.

Not sure if this was a typo in your post, but if you copied your "linking against..." then you are missing an L in DLL for d3dx9_43.

memset and memcpy work fine without the leading underscore. Drop the symbol decoration or check out the GoLink /mix command line option.

[Fredericvo]

Hex numbers need to begin with a digit. To fix two of those errors, change those lines with c0000000h and c0400000h to 0c0000000h and 0c0400000h.

Not sure if this was a typo in your post, but if you copied your "linking against..." then you are missing an L in DLL for d3dx9_43.

memset and memcpy work fine without the leading underscore. Drop the symbol decoration or check out the GoLink /mix command line option.

Are you sure about the leading 0? In fact masm source had them but I needed to remove it because I got invalid number error from goasm.
I'd think the trailing h is unambiguous enough and just looked at goasm documentation which looks like so:
HELLO3 DD 12345678h         ;four bytes (a dword) set to 12345678h
HELLO4 DD 12345678D         ;four bytes (a dword) set to 12345678 decimal
HELLO5 DD 1.1               ;four bytes (a dword) set to real number 1.1

As for the missing L it was a typo I made here.
And I've tried using /mix, removed underscores but nothing helps...
Anyway I'll try again later but am now posting from my mobile

[donkey]

Hi,

The leading 0 is necessary only if your hex number begins with a letter (a..f) if it already begins with a digit it is redundant though it will be ignored. You can also use the C syntax for hex numbers 0xc0000000 in that case you do not include the h suffix.

You should not have any decoration of the API functions, the D3D function should be used without a leading underscore and no parameter information (@xx). Also, I haven't checked most of your D3D functions but I am fairly certain that d3dx9_43.dll does not contain D3DXMatrixLookAtLH, that function is in d3dx9_32.dll. For example this compiles just fine:

#dynamiclinkfile d3dx9_32.dll
invoke D3DXMatrixLookAtLH,0,0,0,0

[Fredericvo]

Sorry for the delay.
I changed the hex values to 0xC0000000 etc and removed all decoration.
Then I issued the following command:
golink /mix dx3.obj kernel32.dll user32.dll d3d9.dll d3dx9_43.dll msvcrt.dll

And it works  :cheekygreen:

So apparently, even though it isn't obvious from a PE_explorer analysis of D3dx9_43.dll it did include the right functions. It'd seem weird otherwise that the exe generated by LINK would otherwise successfully link with it.

Thanks for the prompt help.