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?