"Erik de Castro Lopo" mle+win@mega-nerd.com wrote:
The file dlls/user32/tests/edit.c currently doesn't compile when configured with --enable-win64 because GWL_WNDPROC (in include/winuser.h) is not defined when _WIN64 is defined.
Then you need to fix the test instead of disabling it.
Dmitry Timoshkov wrote:
"Erik de Castro Lopo" mle+win@mega-nerd.com wrote:
The file dlls/user32/tests/edit.c currently doesn't compile when configured with --enable-win64 because GWL_WNDPROC (in include/winuser.h) is not defined when _WIN64 is defined.
Then you need to fix the test instead of disabling it.
In include/winuser.h we have:
#if !defined _WIN64 && !defined __WINESRC__ # define GWL_USERDATA (-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER 8 #endif /* _WIN64 && __WINESRC__ */
which means fixing the test requires first finding out the correct values of these defines under _WIN64. That seems a waste of effort when I'm aiming to get the simplest of WIN64 apps running, like a "Hello world" program that prints to stdout.
Secondly, being unable to compile wine configured with --enable-win64 because of a test for code that has zero percent chance of being correct anyway seems counter productive.
Erik
"Erik de Castro Lopo" mle+win@mega-nerd.com wrote:
In include/winuser.h we have:
#if !defined _WIN64 && !defined __WINESRC__ # define GWL_USERDATA (-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER 8 #endif /* _WIN64 && __WINESRC__ */
which means fixing the test requires first finding out the correct values of these defines under _WIN64.
winuser.h already has the correct values for _WIN64.
That seems a waste of effort when I'm aiming to get the simplest of WIN64 apps running, like a "Hello world" program that prints to stdout.
I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities).
Secondly, being unable to compile wine configured with --enable-win64 because of a test for code that has zero percent chance of being correct anyway seems counter productive.
It's counter productive to start fighting without investigating the subject first.
Dmitry Timoshkov wrote:
"Erik de Castro Lopo" mle+win@mega-nerd.com wrote:
In include/winuser.h we have:
#if !defined _WIN64 && !defined __WINESRC__ # define GWL_USERDATA (-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER 8 #endif /* _WIN64 && __WINESRC__ */
which means fixing the test requires first finding out the correct values of these defines under _WIN64.
winuser.h already has the correct values for _WIN64.
I has _WIN64, but if _WIN64 is defined then GWL_WNDPROC is undefined and the test in dlls/user32/tests/edit.c fails to compile.
I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities).
I'm sure I haven't, but if the wine code doesn't compile I can't debug any problems in these areas.
Erik
"Erik de Castro Lopo" mle+win@mega-nerd.com wrote:
I has _WIN64, but if _WIN64 is defined then GWL_WNDPROC is undefined and the test in dlls/user32/tests/edit.c fails to compile.
I'll let you figure this out on your own, that's a helpful thing to learn.
I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities).
I'm sure I haven't, but if the wine code doesn't compile I can't debug any problems in these areas.
user32 is not required for a simple "Hello World" app, isn't it?
Dmitry Timoshkov wrote:
I'll let you figure this out on your own, that's a helpful thing to learn.
????
user32 is not required for a simple "Hello World" app, isn't it?
I didn't disable test for user32, I disabled a single test. That test was testing edit controls and I am 100% sure that edit controls are not needed for a simple hello world program that prints to stdout.
Erik
2008/4/25 Erik de Castro Lopo mle+win@mega-nerd.com:
Dmitry Timoshkov wrote:
I'll let you figure this out on your own, that's a helpful thing to learn.
????
Try looking up GetWindowLongPtr in MSDN. That should be enough of a hint to help you to get the edit.c tests building properly with _WIN64 defined (as well as supporting WIN32).
- Reece
On Fri, 25 Apr 2008, Erik de Castro Lopo wrote: [...]
user32 is not required for a simple "Hello World" app, isn't it?
I didn't disable test for user32, I disabled a single test. That test was testing edit controls and I am 100% sure that edit controls are not needed for a simple hello world program that prints to stdout.
That's ok to do in your local Git repository.
However you have to understand that we cannot very well commit patch that disables a test which is very useful in garanteeing there won't be regressions in the very much used and about to go stable 32bit version for hypothetical progress in the 64bit version.
But by all means hack and slash your local tree so you can get to the crux of the matter quickly.
Francois Gouget wrote:
That's ok to do in your local Git repository.
However you have to understand that we cannot very well commit patch that disables a test which is very useful in garanteeing there won't be regressions in the very much used and about to go stable 32bit version for hypothetical progress in the 64bit version.
My patch only disabled this one test for Win64. It remained enabled and active for Win32.
However, after some rather subtle prompting from Dmitry Timoshkov and Reece Dunn, I have fixed the test so that it compiles correctly for Win32 and Win64.
Cheers, Erik
-
Dmitry Timoshkov -
Erik de Castro Lopo -
Francois Gouget -
Reece Dunn