A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Hi wine team, First let me thank you for providing wine software witch I see as a strong asset in the expansion of free software and as a useful tool for people (like me) already using free software wherever possible. At this point, Wine is at a very good level both in API coverage, quality (less and less hack, more and more nice and clean solutions) and efficiency. Reaching that level required a tremendous work in all kinds of domains (implementation, coordination, patch value judgment, test suite...). In this regard I want to thank you again and congratulate you all guys, what you have done so far is quite an achievement. This week however I was quite puzzled by one commit : "kernel32: Make GetOverlappedResult crash on NULL args as native does."(1) As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) 2 - Free from charge 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) To summarize, I'm stating that removing the clean and safe way to handle NULL parameters in this function to fall back to bad and dirty crash, exposing security issue for user (a software can be created specifically by a ill-intentioned one to exploit this defect), all for the sake of being as bad as Windows is, is a step in the wrong direction. I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). Nevertheless, just as I said, I'm still very enthusiast about wine and still think it's great and very useful. I will continue to use it, promote its usage when suitable, and also warn about its known defects people around me. Guillaume (1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009 PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.
"Guillaume SH" <gsh.debianlists(a)gmail.com> wrote:
As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team.
That comes from a simple understanding that win32 API behaviour is defined by Microsoft, not by anybody else. Having a NULL check, or even an exception handler in an API is not fix for a defect as you might imply, that's actually good that applications crash when they pass invalid data. Wine needs to handle invalid case only when Windows does have them, and only if there are applications depending on that behaviour. If you whish to "fix" win32 API, make Microsoft hire you. -- Dmitry.
On Sunday 25 January 2009 12:39:22 Dmitry Timoshkov wrote:
"Guillaume SH" <gsh.debianlists(a)gmail.com> wrote:
As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team.
That comes from a simple understanding that win32 API behaviour is defined by Microsoft, not by anybody else. Having a NULL check, or even an exception handler in an API is not fix for a defect as you might imply, that's actually good that applications crash when they pass invalid data. Wine needs to handle invalid case only when Windows does have them, and only if there are applications depending on that behaviour.
If you whish to "fix" win32 API, make Microsoft hire you. What about an assertion right before the following line: *lpTransferred = lpOverlapped->InternalHigh;
This way it will still "crash" in the same circumstances, but will make it easier to debug programs.
"Ambroz Bizjak" <ambro(a)ambro.homelinux.net> wrote:
What about an assertion right before the following line: *lpTransferred = lpOverlapped->InternalHigh;
That will make the behaviour incompatible with Windows by generating wrong exception code.
This way it will still "crash" in the same circumstances, but will make it easier to debug programs.
In which way will it make easier in debugging? -- Dmitry.
2009/1/25 Guillaume SH <gsh.debianlists(a)gmail.com>:
This week however I was quite puzzled by one commit : "kernel32: Make GetOverlappedResult crash on NULL args as native does."(1)
Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform.
I see it as a matter of correctness. Unexpected success can be worse than unexpected failure. Imagine a case where, due to invalid data, an application would randomly destroy or corrupt data all over the user's computer. The only thing saving it is this kernel32 crash. If Wine doesn't have it, bye-bye data integrity. Of course, this is just a hypothetical. But it's important to note that Wine is not *meant* to be *better* than Windows, it's mean to *accurately* implement the win32 API. Thus, it's important to be able to reproduce positive and negative cases as the API is defined.
Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me :
1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them)
This one commit does not making the source any less open.
2 - Free from charge
This one commit does not put a price tag on Wine.
3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered)
If anything, it's communicating a defect more openly. We're specifically saying that, under the right circumstances, the API call will crash (the expected behaviour if running on a native system). Also note that commercial stakes do not factor in to Wine (with the possible exception of Crossover Office), and that Wine is certainly not hiding bugs from anyone. That said, bugs are unknown and unacknowledged until someone discovers them, and in the case of open-source software, that someone is invariably "the public" (i.e. an average user).
I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format).
You know what would be better? Convince people to not use win32 at all, and to use open APIs on open operating systems. We don't live in such a rationally open world. Wine has to deal with the proprietary and (in places) poorly documented win32 API, and in some cases simply reproduce behaviour not necessarily defined in the win32 spec but that is reliably reproducible on Windows (native) systems.
PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.
Wine doesn't have security. OK, that's a bit simplified, but Wine does not protect you from malicious software. Most malware on Windows systems are perfectly valid win32 apps, and if Wine was perfect then the malware would work in Wine too. With every improvement to Wine (in terms of API completeness, accuracy etc.), more malware can potentially run. That's just the way the cookie crumbles.
participants (4)
-
Ambroz Bizjak -
Ben Klein -
Dmitry Timoshkov -
Guillaume SH