2009/1/29 Alex Villacís Lasso <a_villa...@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 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
>>
>>
> 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
--
Rob Shearman
