Hi wine community,
I took some time for reflexion following the thread "A step in the wrong direction, in an ocean of steps in the right direction" and to the explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
All function callable from outside wine should implement, as the first task they perform(1), a sanity parameter check. This check hasn't to be systematic, only really used parameters should be checked and only checks assuring those parameters can be safely used the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded.
So to decline the proposal operationally, I will take an example(2) :
BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED lpOverlapped, [...])
if ( lpOverlapped == NULL ) { #Call the function ExitWineCleanlyAndAdvertiseUser }
This call being justified by the statement, following some lines later : status = lpOverlapped->Internal;
The function ExitWineCleanlyAndAdvertiseUser being something like that :
<Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters to be determined>
#1 - Advertise user outputting a message, for example : "The application you used present a defect. Using it directly expose you to some security issue and indirectly expose others users to some other security issue."
#2 - Cleanly release all still allocated resources
#3 - Cleanly exit wine
A2 - offering flexibility
As I have understood that wine community is willing to be able to run all applications written for a Windows platform, even those relying on the worse behaviours of windows, I will propose too to add a registry key for the purpose of enabling / disabling wine "safe" mode. In this case it would make sense that "safe" mode is the default, with possibility to fall-back to "unsafe" mode when needed.
B - Advantages / Drawbacks to the proposal
Drawback of this solution I can think of are : 1 - It is contrary to the current consensus 2 - It implies a lot of work (even if this can be done bit by bit over a long period time, direction is what matters here) 3 - Detailed implementation of what I presented may very well not be as simple as I imagine, or even impossible 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here 5 - It can go against the interest of the author of those apps relying on Windows's bad behaviors (large firms for example) 6 - It doesn't cover all security issue in wine and it doesn't cover at all security issue in the calling app 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate)
Advantage of this solution I can think of are : 1 - Top-notch level of service to user : I can be informed when I use an unsafe software ! 2 - Encouragement to software industry : I must provide some clean and safe software or wine can judge me "unsafe" (=promoting "best-practices") 3 - Wine is better from it, so people will have a better opinion of wine 4 - Goal reached by wine are far beyond "Windows behaviours on free-OS platform" 5 - Wine is safer so more people will want to use it and to promote its usage
I think I will go no further than this proposal, so I leave the rest to you, from simply ignoring it to demonstrate me than I'm wrong or applying a variation, Guillaume
(1) TRACE, variable declaration or other task may come before though (2) Please don't argue about the coding style, I am not a technical expert (unlike you) and it would be off-topic
Guillaume SH escribió:
Hi wine community,
I took some time for reflexion following the thread "A step in the wrong direction, in an ocean of steps in the right direction" and to the explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
All function callable from outside wine should implement, as the firsttask they perform(1), a sanity parameter check. This check hasn't to be systematic, only really used parameters should be checked and only checks assuring those parameters can be safely used the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded.
So to decline the proposal operationally, I will take an example(2) : BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPEDlpOverlapped, [...])
if ( lpOverlapped == NULL ) { #Call the function ExitWineCleanlyAndAdvertiseUser } This call being justified by the statement, following some lines later :status = lpOverlapped->Internal;
The function ExitWineCleanlyAndAdvertiseUser being something like that : <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters tobe determined>
#1 - Advertise user outputting a message, for example : "Theapplication you used present a defect. Using it directly expose you to some security issue and indirectly expose others users to some other security issue."
#2 - Cleanly release all still allocated resources #3 - Cleanly exit wineA2 - offering flexibility
As I have understood that wine community is willing to be able to runall applications written for a Windows platform, even those relying on the worse behaviours of windows, I will propose too to add a registry key for the purpose of enabling / disabling wine "safe" mode. In this case it would make sense that "safe" mode is the default, with possibility to fall-back to "unsafe" mode when needed.
B - Advantages / Drawbacks to the proposal
Drawback of this solution I can think of are : 1 - It is contrary to the current consensus 2 - It implies a lot of work (even if this can be done bit by bit over along period time, direction is what matters here) 3 - Detailed implementation of what I presented may very well not be as simple as I imagine, or even impossible 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here 5 - It can go against the interest of the author of those apps relying on Windows's bad behaviors (large firms for example) 6 - It doesn't cover all security issue in wine and it doesn't cover at all security issue in the calling app 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate)
Advantage of this solution I can think of are : 1 - Top-notch level of service to user : I can be informed when I use anunsafe software ! 2 - Encouragement to software industry : I must provide some clean and safe software or wine can judge me "unsafe" (=promoting "best-practices") 3 - Wine is better from it, so people will have a better opinion of wine 4 - Goal reached by wine are far beyond "Windows behaviours on free-OS platform" 5 - Wine is safer so more people will want to use it and to promote its usage
I think I will go no further than this proposal, so I leave the rest to you, from simply ignoring it to demonstrate me than I'm wrong or applying a variation, Guillaume
(1) TRACE, variable declaration or other task may come before though (2) Please don't argue about the coding style, I am not a technical expert (unlike you) and it would be off-topic
I think I remember a discussion about a particular bug in which some version of an installer (InstallShield?) refused to work correctly because the wine version of one API call was checking a pointer parameter against NULL and returning an error code instead of crashing. If I recall correctly, it turned out that the installer *expected* the crash, and depended on the fault handler executing some code for its correct operation. So the NULL check was removed, the API now crashes with the invalid pointer (exactly like native) and that installer now works correctly. Maybe somebody who was involved in the actual fix can dig up a pointer to the relevant thread.
How would your proposal work in this case? Instead of the installer working normally (from the point of view of the user), wine now would show an unexpected popup with some message. Most probably the user won't read the message. Instead, he or she will complain that wine now has a regression and refuses to install program XYZ.
Regarding "encouraging best practices", this won't work for the zillion Windows programs already written for Windows that people might want to try under Wine. Especially abandonware. My personal opinion is that this proposal would be more annoying and helpful, and if ever implemented, it should be used as a debugging tool (disabled by default), rather than something the user sees. Maybe this could be implemented as a trace enabled by WINEDEBUG.
On Thu, 29 Jan 2009 14:07:13 -0500, Alex Villacís Lasso a_villacis@palosanto.com wrote:
Guillaume SH escribió:
Hi wine community,
I took some time for reflexion following the thread "A step in the wrong direction, in an ocean of steps in the right direction" and to the explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
All function callable from outside wine should implement, as thefirst
task they perform(1), a sanity parameter check. This check hasn't to be systematic, only really used parameters should be
checked
and only checks assuring those parameters can be safely used the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded.
So to decline the proposal operationally, I will take an example(2):
BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPEDlpOverlapped, [...])
if ( lpOverlapped == NULL ) { #Call the function ExitWineCleanlyAndAdvertiseUser } This call being justified by the statement, following some lineslater :
status = lpOverlapped->Internal;
The function ExitWineCleanlyAndAdvertiseUser being something likethat :
<Result to be determined> ExitWineCleanlyAndAdvertiseUser<Parameters to
be determined>
#1 - Advertise user outputting a message, for example : "Theapplication you used present a defect. Using it directly expose you to
some
security issue and indirectly expose others users to someother
security issue."
#2 - Cleanly release all still allocated resources #3 - Cleanly exit wineA2 - offering flexibility
As I have understood that wine community is willing to be able torun
all applications written for a Windows platform, even those relying on the worse behaviours of windows, I will
propose
too to add a registry key for the purpose of enabling / disabling wine "safe" mode. In this case it would make sense that "safe" mode is the default,
with
possibility to fall-back to "unsafe" mode when needed.
B - Advantages / Drawbacks to the proposal
Drawback of this solution I can think of are : 1 - It is contrary to the current consensus 2 - It implies a lot of work (even if this can be done bit by bitover a
long period time, direction is what matters here) 3 - Detailed implementation of what I presented may very well not be
as
simple as I imagine, or even impossible 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here 5 - It can go against the interest of the author of those apps
relying
on Windows's bad behaviors (large firms for example) 6 - It doesn't cover all security issue in wine and it doesn't cover
at
all security issue in the calling app 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate)
Advantage of this solution I can think of are : 1 - Top-notch level of service to user : I can be informed when Iuse an
unsafe software ! 2 - Encouragement to software industry : I must provide some clean
and
safe software or wine can judge me "unsafe" (=promoting
"best-practices")
3 - Wine is better from it, so people will have a better opinion ofwine
4 - Goal reached by wine are far beyond "Windows behaviours onfree-OS
platform" 5 - Wine is safer so more people will want to use it and to promote
its
usage
I think I will go no further than this proposal, so I leave the rest to
you,
from simply ignoring it to demonstrate me than I'm wrong or applying a variation, Guillaume
(1) TRACE, variable declaration or other task may come before though (2) Please don't argue about the coding style, I am not a technical
expert
(unlike you) and it would be off-topic
I think I remember a discussion about a particular bug in which some version of an installer (InstallShield?) refused to work correctly because the wine version of one API call was checking a pointer parameter against NULL and returning an error code instead of crashing. If I recall correctly, it turned out that the installer *expected* the crash, and depended on the fault handler executing some code for its correct operation. So the NULL check was removed, the API now crashes with the invalid pointer (exactly like native) and that installer now works correctly. Maybe somebody who was involved in the actual fix can dig up a pointer to the relevant thread.
How would your proposal work in this case? Instead of the installer working normally (from the point of view of the user), wine now would show an unexpected popup with some message. Most probably the user won't read the message. Instead, he or she will complain that wine now has a regression and refuses to install program XYZ.
Regarding "encouraging best practices", this won't work for the zillion Windows programs already written for Windows that people might want to try under Wine. Especially abandonware. My personal opinion is that this proposal would be more annoying and helpful, and if ever implemented, it should be used as a debugging tool (disabled by default), rather than something the user sees. Maybe this could be implemented as a trace enabled by WINEDEBUG.
Hi, I've been lurking on this list for awhile, thinking about how I could contribute to Wine.
I wanted to weigh in because I think this overall proposal is on the right track. Graceful handling of errors and crashes would provide a better user experience and potentially help increase the adoption of Wine by more casual users.
I don't know much about application fault/exception handling, but couldn't Wine just install its own top-level fault handler on each Wine thread/process? That way, each API call in Wine can mimic the crash behavior of Windows to satisfy applications like InstallShield, but if the application doesn't handle the exception, the global Wine handler will pick it up and handle it gracefully.
Please excuse me if I am totally off track here.
On Thu, Jan 29, 2009 at 11:31 AM, alex@centroidcafe.com wrote:
Hi, I've been lurking on this list for awhile, thinking about how I could contribute to Wine.
I wanted to weigh in because I think this overall proposal is on the right track. Graceful handling of errors and crashes would provide a better user experience and potentially help increase the adoption of Wine by more casual users.
I don't know much about application fault/exception handling, but couldn't Wine just install its own top-level fault handler on each Wine thread/process? That way, each API call in Wine can mimic the crash behavior of Windows to satisfy applications like InstallShield, but if the application doesn't handle the exception, the global Wine handler will pick it up and handle it gracefully.
What is the point? Either way, the app doesn't work as expected and Wine should be fixed. Adding a global exception handler doesn't fix anything and will more than likely break a handful of apps.
2009/1/29 alex@centroidcafe.com:
Hi, I've been lurking on this list for awhile, thinking about how I could contribute to Wine.
I wanted to weigh in because I think this overall proposal is on the right track. Graceful handling of errors and crashes would provide a better user experience and potentially help increase the adoption of Wine by more casual users.
I don't know much about application fault/exception handling, but couldn't Wine just install its own top-level fault handler on each Wine thread/process? That way, each API call in Wine can mimic the crash behavior of Windows to satisfy applications like InstallShield, but if the application doesn't handle the exception, the global Wine handler will pick it up and handle it gracefully.
Please excuse me if I am totally off track here.
Microsoft did this kind of thing with XP (you can find documents mentioning this on the net, I don't have any references to hand at the moment).
With Vista they have gone the other way. In fact, in order to meet the Windows Logo requirements on Vista you need to turn off structured exception handling (SEH) in C++ exceptions and let the program crash without disabling the Microsoft crash dialogs [1]. That is, if you had:
try { ((int *)0) = 10; } catch (...) { print("null pointer dereference!\n"); }
using SEH trry/catch (/EHs) causes 'null pointer dereference' to be printed on the console window and without (/EHa) causes the application to crash, bringing up a "Report this problem to Microsoft" dialog. Therefore, Microsoft are now advocating a crash early approach to error handling.
Why is this important?
If you have an application that produces an error in method A that sends a return code back to B that passes it back to C that returns a different error code back to D where you report the issue, if that is caused by a bug in method B (i.e. by passing a NULL to A because a memory allocation failed) *how do you know*. All you know is that D reported an error foo.
If you instead did not do a NULL pointer check on the argument, you would have easily found that B is passing A a NULL argument - just attach a debugger to the program.
I had some code that worked perfectly happily on XP, but crashed on Vista. That was a bug in my code. I wouldn't have found it if Vista had kept to trapping errors.
This is not to say that it should crash everywhere -- a lot of the coverity issues are actually issues. In fact, these static analysis and valgrind tools do a better job at spotting issues because of the null pointer dereferences. These tools can track the issues back to the call site and tell you exactly where the problem occurred. You then check for null *there*.
- Reece
[1] http://www.google.co.uk/search?q=Windows+vista+guidelines+logo+crash&btn... -- "Certified for Windows Vista Requirements", section 3.2
2009/1/29 Alex Villacís Lasso a_villacis@palosanto.com:
Guillaume SH escribió:
Hi wine community,
I took some time for reflexion following the thread "A step in the wrong direction, in an ocean of steps in the right direction" and to the explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
All function callable from outside wine should implement, as the firsttask they perform(1), a sanity parameter check. This check hasn't to be systematic, only really used parameters should be checked and only checks assuring those parameters can be safely used the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded.
So to decline the proposal operationally, I will take an example(2) : BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPEDlpOverlapped, [...])
if ( lpOverlapped == NULL ) { #Call the function ExitWineCleanlyAndAdvertiseUser } This call being justified by the statement, following some lines later :status = lpOverlapped->Internal;
The function ExitWineCleanlyAndAdvertiseUser being something like that : <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters tobe determined>
#1 - Advertise user outputting a message, for example : "Theapplication you used present a defect. Using it directly expose you to some security issue and indirectly expose others users to some other security issue."
#2 - Cleanly release all still allocated resources #3 - Cleanly exit wineA2 - offering flexibility
As I have understood that wine community is willing to be able to runall applications written for a Windows platform, even those relying on the worse behaviours of windows, I will propose too to add a registry key for the purpose of enabling / disabling wine "safe" mode. In this case it would make sense that "safe" mode is the default, with possibility to fall-back to "unsafe" mode when needed.
B - Advantages / Drawbacks to the proposal
Drawback of this solution I can think of are : 1 - It is contrary to the current consensus 2 - It implies a lot of work (even if this can be done bit by bit over along period time, direction is what matters here) 3 - Detailed implementation of what I presented may very well not be as simple as I imagine, or even impossible 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here 5 - It can go against the interest of the author of those apps relying on Windows's bad behaviors (large firms for example) 6 - It doesn't cover all security issue in wine and it doesn't cover at all security issue in the calling app 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate)
Advantage of this solution I can think of are : 1 - Top-notch level of service to user : I can be informed when I use anunsafe software ! 2 - Encouragement to software industry : I must provide some clean and safe software or wine can judge me "unsafe" (=promoting "best-practices") 3 - Wine is better from it, so people will have a better opinion of wine 4 - Goal reached by wine are far beyond "Windows behaviours on free-OS platform" 5 - Wine is safer so more people will want to use it and to promote its usage
I think I will go no further than this proposal, so I leave the rest to you, from simply ignoring it to demonstrate me than I'm wrong or applying a variation, Guillaume
(1) TRACE, variable declaration or other task may come before though (2) Please don't argue about the coding style, I am not a technical expert (unlike you) and it would be off-topic
I think I remember a discussion about a particular bug in which some version of an installer (InstallShield?) refused to work correctly because the wine version of one API call was checking a pointer parameter against NULL and returning an error code instead of crashing. If I recall correctly, it turned out that the installer *expected* the crash, and depended on the fault handler executing some code for its correct operation. So the NULL check was removed, the API now crashes with the invalid pointer (exactly like native) and that installer now works correctly. Maybe somebody who was involved in the actual fix can dig up a pointer to the relevant thread.
http://www.winehq.org/pipermail/wine-devel/2006-July/049830.html http://bugs.winehq.org/show_bug.cgi?id=5384
-
Alex Villacís Lasso -
alex＠centroidcafe.com -
Guillaume SH -
James Hawkins -
Reece Dunn -
Rob Shearman