Re: DLL crash inside removethreadtableentry - where's the source code for that?
On Sunday, 17 February 2013 at 11:32:02 UTC, Ben Davis wrote: On 17/02/2013 07:56, Rainer Schuetze wrote: _removethreadtableentry is a function in the DM C runtime library. It has the bug that it tries to free a data record that has never been allocated if the thread that loaded the DLL is terminated. This is the entry at index 1. That's a good start :) Can it be fixed? Who would be able to do it? Or is there some code I can put in my project that will successfully work around the issue? I get the impression the source is available for money. I found this page http://www.digitalmars.com/download/freecompiler.html which mentions complete library source under a link to the shop. I *could* buy it and see if I can fix it myself, but it seems a bit risky. By the way, thanks for Visual D :) Sorry to necro this thread, but I'm currently experiencing the exact same issue. Was this ever fixed? If not, was there a bug filed?
Re: DLL crash inside removethreadtableentry - where's the source code for that?
On Saturday, 11 May 2013 at 07:38:53 UTC, Walter Bright wrote: I thought this was already fixed. What's the date/size on your snn.lib? The latest is: 02/25/2013 06:19 PM 573,952 snn.lib In dmd.2.062.zip (the one I'm using): 574,464 2012-12-11 7:30 AM In dmc.zip: 573,952 2013-02-26 11:19 AM -- the one I should be using? In dmc856.zip (from the Digital Mars site): 574,464 2012-12-11 7:30 AM Shouldn't these be in sync? :P Anyway, thanks for the tip. I'll give it a shot and post back.
Re: DLL crash inside removethreadtableentry - where's the source code for that?
Yep, problem solved. Thanks very much for your help! :)
How/why can toStringz() and toUTFz() be used as properties?
Hey all, Can someone please explain to me how and why it is that toStringz() and toUTFz() can be used in the following way? string a = 123; auto b = a.toStringz; auto c = a.toUTFz; Also, how is it that they can even be called as if they were class methods? That is: string a = 123; auto b = a.toStringz(); // -- Note I've added parentheses auto c = a.toUTFz(); As opposed to being limited to: string a = 123; auto b = toStringz(a); auto c = toUTFz(a); I need to understand this, as I wish to write a function toWinStr() that can be used in the same way which will accept any string type, and, based on something like version(Unicode) and const-ness, output a WinAPI LPSTR, LPCSTR, LPWSTR or LPCWSTR as appropriate. Is such a thing possible?
Re: How/why can toStringz() and toUTFz() be used as properties?
On Friday, 26 April 2013 at 08:49:10 UTC, anonymous wrote: On Friday, 26 April 2013 at 07:31:57 UTC, Trey Brisbane wrote: Hey all, Can someone please explain to me how and why it is that toStringz() and toUTFz() can be used in the following way? string a = 123; auto b = a.toStringz; auto c = a.toUTFz; Also, how is it that they can even be called as if they were class methods? That is: string a = 123; auto b = a.toStringz(); // -- Note I've added parentheses auto c = a.toUTFz(); As opposed to being limited to: string a = 123; auto b = toStringz(a); auto c = toUTFz(a); There's two things at work here: a) Universal Function Call Syntax (UFCS). That basically means that you can call a free function via method/property-like dot syntax. The first argument to the function goes before the dot. UFCS should be explained in the online language documentation, but if it's in there I can't find it. So, with UFCS you get from toStringz(a) to a.toStringz() . b) Empty parentheses are optional. -- Unless you compile with the -property flag. There has been some discussion about the future of the feature. Optional empty parentheses and/or the -property flag may go away in the future. That gets you from a.toString() to a.toString . I need to understand this, as I wish to write a function toWinStr() that can be used in the same way which will accept any string type, and, based on something like version(Unicode) and const-ness, output a WinAPI LPSTR, LPCSTR, LPWSTR or LPCWSTR as appropriate. Is such a thing possible? You just write your function so that toWinStr(stuff) works. UFCS and optional empty parentheses then enable stuff.toWinStr . Ahhh ok, thanks for explaining :)
Re: x64 Link Issues - Can someone please help?
On Saturday, 20 April 2013 at 04:46:45 UTC, dnewbie wrote: phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved external symbol _Dmain referenced in function main Please add -L/DLL to the command line. Ahhh ok, thanks! I assumed DMD would have detected the output file being a DLL and sent this itself, but clearly not. In any case, the DLL now builds fine, however one of my other projects in the solution is also refusing to build but for a different reason. Here is it's build output: -- Building: HookLoader (Debug|x64) Performing main compilation... C:\Development\Tools\ResourceCompiler\rc.exe /fo obj\Debug\Resources.Win32Manifest.res C:\Development\Projects\EyefinityMaximizer\HookLoader\Resources\Win32Manifest.rc Current dictionary: C:\Development\Projects\EyefinityMaximizer\HookLoader dmd.exe -debug -gc obj\Debug\Resources.Win32Manifest.res C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d main.d HookLoader.def -IC:\Development\Compilers\D\dmd2\src\phobos -IC:\Development\Compilers\D\dmd2\src\druntime\src -odobj\Debug -ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exe -m64 HookLoader.def(1) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored HookLoader.def(1) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored Creating library C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.lib and object C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLoader.x64.exp LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt --- errorlevel 1123 Exit code 1123 Build complete -- 1 error, 0 warnings -- Any ideas as to what would cause a 'failure during conversion to COFF'??
Re: x64 Link Issues - Can someone please help?
It seems my resources were breaking the link! Essentially, I was suffering from this problem: http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c/14144713 In any case, problem solved. Thanks! :)
Re: x64 Link Issues - Can someone please help?
On Friday, 19 April 2013 at 13:52:54 UTC, Steven Schveighoffer wrote: On Thu, 18 Apr 2013 21:19:34 -0400, Trey Brisbane tbrisb...@hotmail.com wrote: With regards to digitalmars.D.learn - I had considered posting there, but considering this isn't really a question about learning D, but rather about getting an existing D project to build, I decided against it. If that is however the preferred location for such a question, I will post there next time as you suggested. :) d.learn is for learning, or issues with building, or whatever. If it's something you don't know that you want to find out, it goes there. I guess a rule of thumb is if I have a question that I'm pretty sure someone has the answer to, it should go there. This NG is for general discussion about D features, proposals, interesting articles or related D posts, pretty much everything else. Most of us look at both, so use your best judgment, if you post to the wrong place, it's not the end of the world :) -Steve I have made a post in digitalmars.D.learn regarding this issue. Feel free to delete this thread. :)
x64 Link Issues - Can someone please help?
Hey all,
I'm currently using D for a hook-based project that requires me
to build both a 32bit and 64bit DLL. Naturally, the 32bit DLL
builds fine, however I'm encountering linking issues for the
64bit.
I followed the instructions at
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
for setting up 64bit building (albeit I didn't use his
environment variables - I just put the paths into sc.ini
directly), so if there's a problem with my setup, I don't see it.
Here is my build output (I'm using Xamarin Studio with Mono-D, if
that means anything):
---
Building: HookLib (Debug|x64)
Performing main compilation...
Current dictionary:
C:\Development\Projects\EyefinityMaximizer\HookLib
dmd.exe -debug -gc main.d
C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d
HookLib.def user32.lib
-IC:\Development\Compilers\D\dmd2\src\phobos
-IC:\Development\Compilers\D\dmd2\src\druntime\src
-L/IMPLIB:C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
-odobj\Debug
-ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
-m64
HookLib.def(1) : warning LNK4017: EXETYPE statement not supported
for the target platform; ignored
HookLib.def(2) : warning LNK4017: SUBSYSTEM statement not
supported for the target platform; ignored
HookLib.x64.obj : warning LNK4197: export 'CallWndProc' specified
multiple times; using first specification
Creating library
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
and object
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.exp
phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved
external symbol _Dmain referenced in function main
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
: fatal error LNK1120: 1 unresolved externals
--- errorlevel 1120
Exit code 1120
Build complete -- 1 error, 0 warnings
---
As you can see, there appears to be an issue with my usage of
DLLMain() as opposed to just main(). For 32bit building, the
documentation states that the compiler recognizes DLLMain and
works accordingly - is this also the case for 64bit building?
Here is my DLLMain function, in case I'm doing something wrong
with it:
---
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
// Main DLL switch
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
dll_process_attach( hInstance, true );
break;
case DLL_PROCESS_DETACH:
dll_process_detach( hInstance, true );
break;
case DLL_THREAD_ATTACH:
dll_thread_attach( true, true );
break;
case DLL_THREAD_DETACH:
dll_thread_detach( true, true );
break;
default:
break;
}
return true;
}
---
Any assistance would be appreciated, as this project is stalled
until I can build 64bit binaries.
Thanks and regards,
Trey
x64 Link Issues - Can someone please help?
Hey all,
I'm currently using D for a hook-based project that requires me
to build both a 32bit and 64bit DLL. Naturally, the 32bit DLL
builds fine, however I'm encountering linking issues for the
64bit.
I followed the instructions at
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
for setting up 64bit building (albeit I didn't use his
environment variables - I just put the paths into sc.ini
directly), so if there's a problem with my setup, I don't see it.
Here is my build output (I'm using Xamarin Studio with Mono-D, if
that means anything):
---
Building: HookLib (Debug|x64)
Performing main compilation...
Current dictionary:
C:\Development\Projects\EyefinityMaximizer\HookLib
dmd.exe -debug -gc main.d
C:\Development\Projects\EyefinityMaximizer\EyefinityMaximizer\eyemax\WinAPI.d
HookLib.def user32.lib
-IC:\Development\Compilers\D\dmd2\src\phobos
-IC:\Development\Compilers\D\dmd2\src\druntime\src
-L/IMPLIB:C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
-odobj\Debug
-ofC:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
-m64
HookLib.def(1) : warning LNK4017: EXETYPE statement not supported
for the target platform; ignored
HookLib.def(2) : warning LNK4017: SUBSYSTEM statement not
supported for the target platform; ignored
HookLib.x64.obj : warning LNK4197: export 'CallWndProc' specified
multiple times; using first specification
Creating library
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.lib
and object
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.exp
phobos64.lib(dmain2_4ac_1a5.obj) : error LNK2019: unresolved
external symbol _Dmain referenced in function main
C:\Development\Projects\EyefinityMaximizer\bin\Debug\HookLib.x64.dll
: fatal error LNK1120: 1 unresolved externals
--- errorlevel 1120
Exit code 1120
Build complete -- 1 error, 0 warnings
---
As you can see, there appears to be an issue with my usage of
WinMain() as opposed to just main(). For 32bit building, the
documentation states that the compiler recognizes WinMain and
works accordingly - is this also the case for 64bit building?
Here is my WinMain function, in case I'm doing something wrong
with it:
---
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int iCmdShow) {
int result;
void exceptionHandler(Throwable e) { throw e; }
// Init the D runtime
try {
Runtime.initialize(exceptionHandler);
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
iCmdShow);
Runtime.terminate(exceptionHandler);
} catch (Throwable e) {
MessageBoxA(null, e.toString().toStringz, Error, MB_OK |
MB_ICONEXCLAMATION);
result = 0;
}
return result;
}
---
Any assistance would be appreciated, as this project is stalled
until I can build 64bit binaries.
Thanks and regards,
Trey
Re: x64 Link Issues - Can someone please help?
On Friday, 19 April 2013 at 00:53:28 UTC, Vladimir Panteleev
wrote:
On Friday, 19 April 2013 at 00:24:27 UTC, Trey Brisbane wrote:
As you can see, there appears to be an issue with my usage of
WinMain() as opposed to just main(). For 32bit building, the
documentation states that the compiler recognizes WinMain and
works accordingly - is this also the case for 64bit building?
The entry point for DLLs is the DllMain function, not WinMain.
I'm not sure why building a DLL with a WinMain entry point
would succeed - I'd assume the resulting DLL wouldn't work.
In the future, consider posting questions on how to use D to
the digitalmars.D.learn group.
You're completely right. It seems I copy+pasted from the wrong
source file by mistake.
My DLLMain (not WinMain) is as follows:
---
extern (Windows) BOOL DllMain(HINSTANCE hInstance, ULONG
ulReason, LPVOID pvReserved) {
// Main DLL switch
switch (ulReason) {
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
dll_process_attach( hInstance, true );
break;
case DLL_PROCESS_DETACH:
dll_process_detach( hInstance, true );
break;
case DLL_THREAD_ATTACH:
dll_thread_attach( true, true );
break;
case DLL_THREAD_DETACH:
dll_thread_detach( true, true );
break;
default:
break;
}
return true;
}
---
With regards to digitalmars.D.learn - I had considered posting
there, but considering this isn't really a question about
learning D, but rather about getting an existing D project to
build, I decided against it. If that is however the preferred
location for such a question, I will post there next time as you
suggested. :)
