Hello
I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time.
Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine.
Is there a solution for this? What is Wine devs position on this matter?
Side question: Windows could make a 'clean start' with 64 bit environment, did they?
Thank you for your time.
Adam Klobukowski
Is there a solution for this?
Sure: black-box reverse engineer how MS is detecting the apps and enabling the hacks, create test cases showing that they exist, and implement them ourselves. --Juan
On 3/23/11, Adam Kłobukowski adamklobukowski@gmail.com wrote:
Hello
I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time.
Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine.
And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks.
Is there a solution for this? What is Wine devs position on this matter?
Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case.
Side question: Windows could make a 'clean start' with 64 bit environment, did they?
If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits.
James McKenzie
On 23.03.2011 16:01, James McKenzie wrote:
On 3/23/11, Adam Kłobukowskiadamklobukowski@gmail.com wrote:
Hello
I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time.
Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine.
And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks.
Is there a solution for this? What is Wine devs position on this matter?
Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case.
Side question: Windows could make a 'clean start' with 64 bit environment, did they?
If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits.
What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened.
Adam Klobukowski
2011/3/23 Adam Kłobukowski adamklobukowski@gmail.com:
On 23.03.2011 16:01, James McKenzie wrote:
On 3/23/11, Adam Kłobukowskiadamklobukowski@gmail.com wrote:
Hello
I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time.
Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine.
And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks.
Is there a solution for this? What is Wine devs position on this matter?
Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case.
Side question: Windows could make a 'clean start' with 64 bit environment, did they?
If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits.
What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened.
Looking at the results from the wine test suite on 64-bit, I'd say no.
What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened.
Speculating whether MS would have done this is probably not a very useful exercise. Still, I'd say it's exceedingly improbable: 1. The cost of reviewing all the code for what might be a hack is high, and what's the benefit? Less code to maintain can't be an answer, because the 32-bit versions of Windows still need the hacks. 2. Apps written for 64-bit Windows aren't created in a vacuum: they're probably ported from a 32-bit codebase first, or 32-bit and 64-bit versions are co-developed. The same, possibly erroneous assumptions that a 32-bit application might make would therefore need to be maintained in a 64-bit version.
A better place to ask questions like these might be http://blogs.msdn.com/b/oldnewthing/ --Juan
On 03/23/2011 11:02 AM, Juan Lang wrote:
What I meant as 'clean start' is that they could drop all hacks in 64bit environment. I wonder if that happened.
Speculating whether MS would have done this is probably not a very useful exercise. Still, I'd say it's exceedingly improbable:
- The cost of reviewing all the code for what might be a hack is
high, and what's the benefit? Less code to maintain can't be an answer, because the 32-bit versions of Windows still need the hacks. 2. Apps written for 64-bit Windows aren't created in a vacuum: they're probably ported from a 32-bit codebase first, or 32-bit and 64-bit versions are co-developed. The same, possibly erroneous assumptions that a 32-bit application might make would therefore need to be maintained in a 64-bit version.
A better place to ask questions like these might be http://blogs.msdn.com/b/oldnewthing/ --Juan
Still, we're probably not going to encounter the 64-bit equivalent of "If program is simcity, do this with the memory instead of that"
Though there are probably many newer hacks to worry about instead.
--Scott Ritchie
-
Adam Kłobukowski -
Austin English -
James McKenzie -
Juan Lang -
Scott Ritchie