Check if GetProcAddress returns null? It seems to me you're looking for _magicFunction but defining magicNumber, two different names.

On 19/12/2011 18:01, Andrej Mitrovic wrote:
> Check if GetProcAddress returns null? It seems to me you're looking
> for _magicFunction but defining magicNumber, two different names.

that's be it. can't remember the rules for whether it will have a leading underscore, but you can always use dependency walker to find out:

http://dependencywalker.com/

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Dne 19.12.2011 19:39, Simon napsal(a):
> On 19/12/2011 18:01, Andrej Mitrovic wrote:
>> Check if GetProcAddress returns null? It seems to me you're looking
>> for _magicFunction but defining magicNumber, two different names.
>
> that's be it. can't remember the rules for whether it will have a
> leading underscore, but you can always use dependency walker to find out:
>
> http://dependencywalker.com/
>

Hi guys,

thanks for your response... but it is not the problem. I must have made a mistake writing this down.

It actualy returns a procedure address and the procedure is called. It lands inside export extern (C) int magicNumber() and crashes when attempting to allocate memory for Something.

I have used dependency walker, that is why I asked why only the first function is exported with underscore and the others are not.

Martin

> It actualy returns a procedure address and the procedure is called. It lands inside export extern (C) int magicNumber() and crashes when attempting to allocate memory for Something.

Did you properly initialize druntime?

Dne 19.12.2011 23:09, Trass3r napsal(a):
>> It actualy returns a procedure address and the procedure is called. It
>> lands inside export extern (C) int magicNumber() and crashes when
>> attempting to allocate memory for Something.
>
> Did you properly initialize druntime?

As I am just starting with D, the most precise answer I can give you is: I don't know... how do I tell? Or in another way - the code for D library is almost complete except for imports. The rest was done for me by Visual D.

Martin

Am 19.12.2011, 23:13 Uhr, schrieb Martin Drašar <drasar@ics.muni.cz>:

> Dne 19.12.2011 23:09, Trass3r napsal(a):
>>> It actualy returns a procedure address and the procedure is called. It
>>> lands inside export extern (C) int magicNumber() and crashes when
>>> attempting to allocate memory for Something.
>>
>> Did you properly initialize druntime?
>
> As I am just starting with D, the most precise answer I can give you is: I don't know... how do I tell? Or in another way - the code for D library is almost complete except for imports. The rest was done for me by Visual D.

It's explained there: http://www.dlang.org/dll.html

Dne 20.12.2011 0:02, Trass3r napsal(a):
> Am 19.12.2011, 23:13 Uhr, schrieb Martin Drašar <drasar@ics.muni.cz>:
>
>> Dne 19.12.2011 23:09, Trass3r napsal(a):
>>>> It actualy returns a procedure address and the procedure is called. It
>>>> lands inside export extern (C) int magicNumber() and crashes when
>>>> attempting to allocate memory for Something.
>>>
>>> Did you properly initialize druntime?
>>
>> As I am just starting with D, the most precise answer I can give you
>> is: I don't know... how do I tell? Or in another way - the code for D
>> library is almost complete except for imports. The rest was done for
>> me by Visual D.
>
> It's explained there: http://www.dlang.org/dll.html
>

Well as far as I can tell, the runtime is initialized with call to Runtime.initialize(). This call is executed inside dll_process_attach here:

> extern (Windows)
> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
> {
>     final switch (ulReason)
>     {
>     case DLL_PROCESS_ATTACH:
>         g_hInst = hInstance;
>         dll_process_attach( hInstance, true );
>         break;

so I would say that the runtime is properly initialized.

Martin

test.cpp: http://www.ideone.com/uh7vN
DLibrary.d: http://www.ideone.com/fOLN8

$ g++ test.cpp
$ dmd -ofDLibrary.dll DLibrary.d
$ a.exe
$ 9

Dne 20.12.2011 2:22, Andrej Mitrovic napsal(a):
> test.cpp: http://www.ideone.com/uh7vN
> DLibrary.d: http://www.ideone.com/fOLN8
>
> $ g++ test.cpp
> $ dmd -ofDLibrary.dll DLibrary.d
> $ a.exe
> $ 9

Hi, Andrej,

you are right, this works. Problem is going to be either in VisualD or cv2pdb.

For those who are interested:
The version produced by VisualD simply does not work and crashes. Hovewer, if you just execute dmd command that VisualD uses and then manually call cv2pdb, everything works fine and you can hapilly debug in Visual Studio.

Library compiled by VisualD:
----------------------------
DLibrary.dll | size: 936 082B
DLibrary.pdb | size: 248 832B

Library compiled by using VisualD commandline parameters:
---------------------------------------------------------
$ dmd dllmain.d -g -debug -X -Xf"DLibrary.json" -deps="DLibrary.dep" -of"..\Debug\DLibrary.dll" -map "DLibrary.map"

Results after calling cv2pdb on the DLibrary.dll

DLibrary.dll | size: 935 570B
DLibrary.pdb | size: 248 832B

Manual execution of that two commands produces library that works and is debugable and also, by some strange coincidence, 112 bytes smaller.

Funny... if you have any ideas, do not hesitate to share ;-)

Regards,
Martin

I'd say make a small test-case and file it to visuald's bugtracker.