A step in the wrong direction, in an ocean of steps in the right direction (try 3)

[Ben Klein]

2009/1/25 Guillaume SH <gsh.debianlists at 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.