www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - console output in dll doesn't work

reply Trass3r <un known.com> writes:
I tried the simple(st) official dll example (which I fixed slightly to  
compile; using the dll_helper module etc)

export void dllprint() { write("hello dll world\n"); }

The code is executed (I checked with a debugger) but nothing is printed in  
the console window.
Mar 31 2010
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Trass3r wrote:

 I tried the simple(st) official dll example (which I fixed slightly to 
 compile; using the dll_helper module etc)
 


What was the fix? The example in samples/d/mydll compiles fine and looks 
very much the same.


 export void dllprint() { write("hello dll world\n"); }
 
 The code is executed (I checked with a debugger) but nothing is printed 
 in the console window.


In contrast to printf the std.stdio.write functions seem to buffer the 
output. When the DLL is unloaded, console output is already closed by 
the application.

Two possible solutions:
1. call stdout.flush() after writing
2. set std.c.stdio._fcloseallp = null; before terminating the exe, but 
expect scrumbled output from the DLL and the exe
Mar 31 2010
parent reply Trass3r <un known.com> writes:
 What was the fix? The example in samples/d/mydll compiles fine and looks  
 very much the same.


Note that I'm talking about D2.

1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of  
..\..\..\windows\bin\dmd
2. printf isn't defined by default anymore.
3. The gc code etc in DllMain is for D1 I guess. I used code from  
http://www.digitalmars.com/d/2.0/dll.html instead.
4. HINSTANCE g_hInst; wasn't (__g)shared



 In contrast to printf the std.stdio.write functions seem to buffer the  
 output. When the DLL is unloaded, console output is already closed by  
 the application.

 Two possible solutions:
 1. call stdout.flush() after writing


doesn't fix it.



 2. set std.c.stdio._fcloseallp = null; before terminating the exe, but  
 expect scrumbled output from the DLL and the exe


fixes it. need to find out why.
Mar 31 2010
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Trass3r wrote:

 What was the fix? The example in samples/d/mydll compiles fine and 
 looks very much the same.


 Note that I'm talking about D2.
 
 1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of 
 ...\..\..\windows\bin\dmd
 2. printf isn't defined by default anymore.
 3. The gc code etc in DllMain is for D1 I guess. I used code from 
 http://www.digitalmars.com/d/2.0/dll.html instead.
 4. HINSTANCE g_hInst; wasn't (__g)shared


These were fixed in dmd-2.042. I guess you are using an earlier version 
of the example.
Mar 31 2010
next sibling parent Trass3r <un known.com> writes:
 These were fixed in dmd-2.042. I guess you are using an earlier version  
 of the example.


Indeed. Seems like I was still using dmd2.042beta or some mixture.
Mar 31 2010
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 31/03/2010 21:21, Rainer Schuetze wrote:

 Trass3r wrote:

 What was the fix? The example in samples/d/mydll compiles fine and
 looks very much the same.


 Note that I'm talking about D2.

 1. The path in build.bat is incorrect: is ..\..\..\bin\dmd instead of
 ...\..\..\windows\bin\dmd
 2. printf isn't defined by default anymore.
 3. The gc code etc in DllMain is for D1 I guess. I used code from
 http://www.digitalmars.com/d/2.0/dll.html instead.
 4. HINSTANCE g_hInst; wasn't (__g)shared


 These were fixed in dmd-2.042. I guess you are using an earlier version
 of the example.


a bit OT sorry..
Rainer,
did you give D2 static variables inside an DLL a try ? Are they thread 
local ? it looks like but I am not sure. In case that they are > another 
question is coming up > who cares about de- alloc. Guess I have to. You 
see me clueless.
Mar 31 2010
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
BLS wrote:

 a bit OT sorry..
 Rainer,
 did you give D2 static variables inside an DLL a try ? Are they thread 
 local ? it looks like but I am not sure. 


static variables that are neither const/immutable nor shared are in 
thread local storage.


 In case that they are > another
 question is coming up > who cares about de- alloc. Guess I have to. You 
 see me clueless.
 


I'm not sure what you mean by "de-alloc". The dll_helper functions in 
DllMain take care of initializing and deinitializing the tls-data 
(running static ctors and dtors) when new threads are created or 
terminated.

With the current version you cannot share gc-allocated memory between 
DLLs. When the DLL is unloaded the complete heap used by the DLL is 
destroyed.
Mar 31 2010
parent BLS <windevguy hotmail.de> writes:
 I'm not sure what you mean by "de-alloc". The dll_helper functions in
 DllMain take care of initializing and deinitializing the tls-data
 (running static ctors and dtors) when new threads are created or
 terminated.



Sorry, my question was not very exact. Nevertheless you've  answered my 
question :)


 With the current version you cannot share gc-allocated memory between
 DLLs. When the DLL is unloaded the complete heap used by the DLL is
 destroyed.


Not sure about the impact.

Bjoern
Mar 31 2010