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

[David Gerard]

2009/1/25 Ben Klein <shacklein at gmail.com>:

> Wine's goal is perfectly clear: to provide, as best as possible, a
> complete and accurate implementation of win32 (and win64 long-term)
> and related APIs. If putting invalid data into a specific function
> causes a known crash on the only other implementation of win32
> (Microsoft Windows), especially considering that win32 is standardised
> by the same company that produces Windows, it can be assumed that the
> crash is the correct behaviour and Wine should emulate it.


Is it possible to meaningfully enhance Wine by crashing the app, but
in such a way as to note on the terminal that the crash is for
compatibility with Win32, what crashed where, etc?


> No, it's dooming Wine to have more success than it should have. Big
> difference. In implementing win32 API, Wine inherently opens up *nix
> to a whole new world of malware. Sure, it still needs to be explicitly
> run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine",
> but that won't stop spyware, trojans, worms etc. completely. And it
> shouldn't, because if Wine attempts to stop malware, then legitimate
> applications will surely suffer too. Not to mention legitimate
> software that *acts* like malware, e.g. punkbuster :)


Wine running malware correctly is a valuable feature, e.g. ZeroWine:

  http://www.offensivecomputing.net/?q=node/1028

It runs malware in Wine on Debian on QEMU for the purpose of producing
a full trace of all Win32 calls.


- d.