View previous topic :: View next topic |
Author |
Message |
wittier1
Joined: 20 Dec 2007 Posts: 2
|
Posted: Fri Dec 21, 2007 1:41 am Post subject: Problem with winuser.d... Could I get a ruling here? |
|
|
Ok, the situation is as such:
I've been pulling my hair out for the past few days trying to add these win32 bindings to a current project (by the way, kudos everyone who has contributed for giving such an essential project to the D community). I began the project using Phobos' std.c.windows.windows and quickly realized how limited (read: inadequate) it is for Windows programming. Hours of searching brought me here with the sense that the problem was solved. As a test, I attempted to convert the "winsamp" example to use my shiny new win32.windows module. The result was Exhibit A (below).
"What the deuce?" I distinctly remember muttering to myself.
I fiddled around with it until I was sufficiently irritated, then went to bed. The following day, I scoured docs, forums, and newsgroups for some answers. An interesting post on this very forum includes the same name-mangled CreateWindowA() error found in Exhibit A, though the discussion was not of help. I ended the day defeated again.
On the following morning, I decided to take a peek inside the win32 module. Exhibit B (below) shows a paraphrased code snippet of the section in winuser.d that houses CreateWindowA(). So CreateWindowA() does nothing but forward the call to CreateWindowExA(). Just for giggles, I change my code to call CreateWindowExA() directly. Lo and behold, this time it works flawlessly. All the frustration built up in the past couple days is instantly released and to fill its void, mysification rushes in.
I took another look at the file to see if I could learn something... I had noticed that the extern(Windows) block excludes (among other things) CreateWindowA()'s declaration and definition. For some more giggles, I modified the winuser.d file such that CreateWindowA() would now be included in the extern(Windows) block and reverted my code to call it rather than CreateWindowExA() directly. It works and now I'm as puzzled as ever.
What I'd like to know is:
1) Why does this work? That is, why is the symbol for CreateWindowA(), whose declaration and definition both exist in the module, mangled and made to be undefined outside the extern block and are made correct only within it?
2) Is this change proper? Should the change be committed?
Thanks very much.
Exhibit A
OPTLINK (R) for Win32 Release 8.00.1
Copyright (C) Digital Mars 1989-2004 All rights reserved.
main.obj(main)
Error 42: Symbol Undefined _D5win327winuser13CreateWindowAFPaPakiiiiT5win325win
nt6HANDLET5win325winnt6HANDLET5win325winnt6HANDLEPvZT5win325winnt6HANDLE
--- errorlevel 1
Exhibit B
...
} // extern (Windows)
...
HWND CreateWindowA(LPCSTR a, LPCSTR b, DWORD c, int d, int e, int f, int g, HWND h, HMENU i, HINSTANCE j, LPVOID k)
{
return CreateWindowExA(0, a, b, c, d, e, f, g, h, i, j, k);
}
...
extern (Windows):
... |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Fri Dec 21, 2007 5:26 am Post subject: Re: Problem with winuser.d... Could I get a ruling here? |
|
|
wittier1 wrote: | What I'd like to know is:
1) Why does this work? That is, why is the symbol for CreateWindowA(), whose declaration and definition both exist in the module, mangled and made to be undefined outside the extern block and are made correct only within it? |
Are you sure that you have linked the Windows API project correctly? This seems to me a typical "Error 42: Symbol Undefined" error, which occures when you forget to link the "win32.lib". The easiest way in my opinion to build the Windows API library is to use the makefile (you need GNU Make for Windows to be installed to use it).
wittier1 wrote: | 2) Is this change proper? Should the change be committed? |
No, I think what you observed was a interference with the default linkage of DMD. This is sometimes a little bit irritating if new people forget to link correctly with the project source. This will all be gone, if Walter includes the Windows API Project as the default in Phobos.
Please let us know if this solved your problem, otherwise you should attach your files and your used command lines.
LLAP,
Sascha Katzner |
|
Back to top |
|
|
wittier1
Joined: 20 Dec 2007 Posts: 2
|
Posted: Fri Dec 21, 2007 2:09 pm Post subject: |
|
|
I took your advice and installed MinGW+make, then tried to use makefile to build win32.lib. I've come up against the following problems:
1.
Quote: | ..\win32\commctrl.d(4389): function win32.winuser.CreateWindowW (wchar*,wchar*,uint,int,int,int,int,HANDLE,HANDLE,HANDLE,void*) does not match parameter types (const(wchar*),void*,uint,int,int,int,int,HANDLE,HANDLE,HANDLE,void*)
..\win32\commctrl.d(30): Error: cannot implicitly convert expression ("SysAnimate32") of type const wchar* to wchar*
make: *** [aclui.obj] Error 1 |
I worked through this by explicitly casting the first two parameters in the call to CreateWindow() to wchar*.
Quote: | HWND Animate_Create(HWND hwndP, UINT id, DWORD dwStyle,
HINSTANCE hInstance) {
return CreateWindow(cast(wchar*)(ANIMATE_CLASS.ptr), cast(wchar*)(null), dwStyle, 0, 0, 0, 0, hwndP,
cast(HMENU) id, hInstance, null);
} |
2.
Quote: | Assertion failure: 'sz == es2->sz' on line 1345 in file 'constfold.c'
make: *** [regstr.obj] Error 1 |
I dug through constfold.c to view the section in which the assertion failed. It seems to be related to string concatenation. I then went back to regstr.d and commented out every line I found the ~ operator. This worked, though my regstr.d is incorrect now.
3.
Quote: | Assertion failure: 'sz == es2->sz' on line 1345 in file 'constfold.c'
make: *** [shlobj.obj] Error 1 |
I applied the same tactic a I had used in regstr.d to shlobj.d, this time to no avail. Currently, the build fails when compiling shlobj.obj.
Since no one else seems to be having such issues, I guess these problems are my own fault. Please, help me to understand the discrepancy between our systems. What am I doing wrong? It's frustrating to not know.
If it helps at all, I'm using:
dmd.exe v2.007
When trying to compile winsamp, I've been using "dmd\bin\dmd.exe dmd\samples\d\winsamp.d dmd\samples\d\winsamp.def gdi32.lib"
mingw32-make.exe v3.79.1
When trying to build win32.lib, I've been using "make makefile win32.lib" |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Fri Dec 21, 2007 6:48 pm Post subject: |
|
|
wittier1 wrote: | If it helps at all, I'm using:
dmd.exe v2.007 |
This is the problem, the Windows API project is at this time not compatible with D 2.X. I think we will change this when 2.X becomes stable.
wittier1 wrote: | When trying to compile winsamp, I've been using "dmd\bin\dmd.exe dmd\samples\d\winsamp.d dmd\samples\d\winsamp.def gdi32.lib" |
You have to add "win32.lib" there also.
wittier1 wrote: | mingw32-make.exe v3.79.1
When trying to build win32.lib, I've been using "make makefile win32.lib" |
A simple "make" is enough. Make uses a file with the name "makefile" as default, and the win32.lib is also the default target of the makefile.
LLAP,
Sascha Katzner |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|