On 10/3/06, Pavel Roskin proski@gnu.org wrote:
From: Pavel Roskin proski@gnu.org
Compile oleaut32 for win32 but not for win64
Does win64 not come with oleaut32? What I'm really asking is, why are you making this change?
Hello, James!
On Tue, 2006-10-03 at 14:14 -0700, James Hawkins wrote:
On 10/3/06, Pavel Roskin proski@gnu.org wrote:
From: Pavel Roskin proski@gnu.org
Compile oleaut32 for win32 but not for win64
Does win64 not come with oleaut32? What I'm really asking is, why are you making this change?
It fails to compile. The error is "Invalid build platform for this stub"
Search for "oleaut32 wine win64" (without quotes) on Google to see multiple attempts to fix it somehow, for instance here:
http://www.winehq.org/pipermail/wine-patches/2006-June/027745.html
I understand oleaut32 can be fixed for win64, but nobody has done it.
I believe my patch is worth applying because it enables Wine compilation without applying incorrect hacks to the sources. Instead, a mechanism is established to disable some parts of Wine for win64 until they are ported properly. We may need it for other files.
The same mechanism is applied to ntdll/tests/generated.c. I believe we need ntdll/tests/generated64.c for 64-bit systems. Unfortunately, winapi_test generate many warnings, so I'm hesitant to provide my copy of generated64.c - it may be totally wrong.
Finally, the pad extension is needed to fix assertion failure on startup. The patch uses a clever trick to avoid preprocessor conditions. Instead, the number of integer and long files is selected so that the maximal length is 64 on win32 and 96 on win64.
On 10/3/06, Pavel Roskin proski@gnu.org wrote:
Hello, James!
On Tue, 2006-10-03 at 14:14 -0700, James Hawkins wrote:
On 10/3/06, Pavel Roskin proski@gnu.org wrote:
From: Pavel Roskin proski@gnu.org
Compile oleaut32 for win32 but not for win64
Does win64 not come with oleaut32? What I'm really asking is, why are you making this change?
It fails to compile. The error is "Invalid build platform for this stub"
Search for "oleaut32 wine win64" (without quotes) on Google to see multiple attempts to fix it somehow, for instance here:
http://www.winehq.org/pipermail/wine-patches/2006-June/027745.html
I understand oleaut32 can be fixed for win64, but nobody has done it.
I believe my patch is worth applying because it enables Wine compilation without applying incorrect hacks to the sources. Instead, a mechanism is established to disable some parts of Wine for win64 until they are ported properly. We may need it for other files.
Removing oleaut32 from the build just hides the real problem, and creates a slew of new problems. What will happen when an app tries to use oleaut32 with a win64 build of Wine? The correct solution is to fix oleaut32 to work with win64, no matter how difficult it is. We can't allow temporary hacks in the meantime, or there will be significantly less motivation to fix the real problem, because a workaround is available.
On Tue, 2006-10-03 at 14:46 -0700, James Hawkins wrote:
I understand oleaut32 can be fixed for win64, but nobody has done it.
I believe my patch is worth applying because it enables Wine compilation without applying incorrect hacks to the sources. Instead, a mechanism is established to disable some parts of Wine for win64 until they are ported properly. We may need it for other files.
Removing oleaut32 from the build just hides the real problem, and creates a slew of new problems. What will happen when an app tries to use oleaut32 with a win64 build of Wine? The correct solution is to fix oleaut32 to work with win64, no matter how difficult it is. We can't allow temporary hacks in the meantime, or there will be significantly less motivation to fix the real problem, because a workaround is available.
I understand this argument, but I think it doesn't always work this way.
Different people have different skills, different amount of time and different hardware.
If Wine for win64 builds somehow, many people will try to fix simple things, like compile warnings. That's a lot of rather simple work that may be too boring for an OLE guru. Somebody will probably debug further problems. And somebody will fix the broken parts.
If oleaut32 is left in the broken and "enabled" state like a roadblock, fewer people would be motivated to do simple things like fixing warnings and checking that their modifications compile for win64.
I, for one, don't have any experience with OLE and little experience with Window programming. Yet I have the 64-bit hardware and I knowledge to fix some simple things like printf warnings.
I'm not going to stop working on other projects and spend days learning OLE to fix oleaut32.
I could, however, fix the problem in generated.c problem one day because I know Perl scripting. But please note that the generated.c problem is only seen after oleaut32 is compiled (or skipped somehow). Somebody with Perl knowledge and a 64-bit system could just abandon the native compilation after seeing the failure in oleaut32, without even being aware that his or her knowledge would be very useful.
Conversely, somebody who knows how to fix oleaut32 could be stumped by the generated.c problem. Then we would have another roadblock that is supposed to motivate everybody (in theory).
It's just a matter of introducing some parallelism to use the available resources of the developers in a better way.
I'm not a regular Wine developer, and the above is just a little more than "my two cents". Let's not start a flamewar over this, OK?
On 10/3/06, Pavel Roskin proski@gnu.org wrote:
On Tue, 2006-10-03 at 14:46 -0700, James Hawkins wrote:
I understand oleaut32 can be fixed for win64, but nobody has done it.
I believe my patch is worth applying because it enables Wine compilation without applying incorrect hacks to the sources. Instead, a mechanism is established to disable some parts of Wine for win64 until they are ported properly. We may need it for other files.
Removing oleaut32 from the build just hides the real problem, and creates a slew of new problems. What will happen when an app tries to use oleaut32 with a win64 build of Wine? The correct solution is to fix oleaut32 to work with win64, no matter how difficult it is. We can't allow temporary hacks in the meantime, or there will be significantly less motivation to fix the real problem, because a workaround is available.
I'm not going to stop working on other projects and spend days learning OLE to fix oleaut32.
Ok, then either someone else will step up and fix it, or it will remain unfixed. Either way, oleaut32 should remain in the win64 build.
I'm not a regular Wine developer, and the above is just a little more than "my two cents". Let's not start a flamewar over this, OK?
Of course not, that would be silly. I, for one, hope you continue to submit patches and become a regular Wine developer. We can use the help. One thing you have to learn though is that the developers provide a lot of constructive criticism in order to keep Wine at a professional level, and you shouldn't take offense to it. It's all a part of the process.
-
James Hawkins -
Pavel Roskin