Hi wine community,<br><br>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 <br>explanations some of you kindly exposed to me.<br>
<br>As a follow-up I am making a proposal.<br><br>A - The proposal<br><br> A1 - The core proposal<br><br> All function callable from outside wine should implement, as the first task they perform(1), a sanity parameter check. This check <br>
hasn't to be systematic, only really used parameters should be checked and only checks assuring those parameters can be safely used <br> the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded.<br>
<br> So to decline the proposal operationally, I will take an example(2) :<br><br> BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED lpOverlapped, [...])<br><br> if ( lpOverlapped == NULL )<br> {<br>
#Call the function ExitWineCleanlyAndAdvertiseUser<br> }<br> <br><br> This call being justified by the statement, following some lines later : status = lpOverlapped->Internal;<br><br><br> The function ExitWineCleanlyAndAdvertiseUser being something like that :<br>
<br> <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters to be determined><br><br> #1 - Advertise user outputting a message, for example : "The application you used present a defect. Using it directly expose you to some <br>
security issue and indirectly expose others users to some other security issue."<br><br> #2 - Cleanly release all still allocated resources<br> <br> #3 - Cleanly exit wine<br><br><br> A2 - offering flexibility<br>
<br> As I have understood that wine community is willing to be able to run all applications written for a Windows platform,<br> even those relying on the worse behaviours of windows, I will propose too to add a registry key for the purpose of enabling / disabling <br>
wine "safe" mode.<br> In this case it would make sense that "safe" mode is the default, with possibility to fall-back to "unsafe" mode when needed. <br><br>B - Advantages / Drawbacks to the proposal<br>
<br> Drawback of this solution I can think of are :<br> 1 - It is contrary to the current consensus<br> 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)<br>
3 - Detailed implementation of what I presented may very well not be as simple as I imagine, or even impossible<br> 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here<br>
5 - It can go against the interest of the author of those apps relying on Windows's bad behaviors (large firms for example)<br> 6 - It doesn't cover all security issue in wine and it doesn't cover at all security issue in the calling app<br>
7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate)<br><br> Advantage of this solution I can think of are :<br> 1 - Top-notch level of service to user : I can be informed when I use an unsafe software !<br>
2 - Encouragement to software industry : I must provide some clean and safe software or wine can judge me "unsafe" (=promoting "best-practices")<br> 3 - Wine is better from it, so people will have a better opinion of wine<br>
4 - Goal reached by wine are far beyond "Windows behaviours on free-OS platform"<br> 5 - Wine is safer so more people will want to use it and to promote its usage<br><br><br>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,<br>
Guillaume<br><br>(1) TRACE, variable declaration or other task may come before though<br>(2) Please don't argue about the coding style, I am not a technical expert (unlike you) and it would be off-topic<br>