Re: Carry flag state after a system function call

On 9/25/24 12:27, Robert Ayrapetyan wrote:
> It was a 32-bit executable of the Polish version of the Galador game
> (The Prince and The Coward).
> It contains wrappers around calls to kernel32 functions (e.g. _llseek).
> The very last instruction in most of the wrappers is clc, but not in
> all of them. One of them, wrapping _llseek, contained no clc
> instruction, causing random behaviour, when different versions of wine
> behaved differently depending on how the Carry flag was set based on a
> side effect of a stack frame cleanup code.
> At least in Windows XP it didn't work because it uses instructions
> which always set the Carry flag to true in the epilog of the
> SetFilePointer function.
> I don't think this is something we can fix in wine, if the application
> relies on the state of the Carry flag and doesn't explicitly clear it
> in case of success - it's a bug of that app,
> which may accidentally work in some specific Windows versions.
> I can provide a patch for this particular game which NOPs JB call
> after _llseek, but I don't think it's appropriate for winehq..
>
If this is just one msvcrt._llseek() and the behaviour is consistent on 
Windows (e. g., carry flags always ends up reflecting the error status), 
maybe an asm wrapper for this function in msvcrt is an option?