[PATCH] msvcrt:msvcrt_get_flags: Fix bug 51846 - fopen(..., "wx")

[Ted Lyngmo]

Hi Piotr!

On 2021-10-08 10:18, Piotr Caban wrote:
> On 10/8/21 9:41 AM, Ted Lyngmo wrote:
>> Patch 1: msvcrt: https://testbot.winehq.org/JobDetails.pl?Key=99682
>>
>> This patch makes programs compiled by Visual Studio and that works as 
>> expected in native Windows also work in Wine.
>>
>> The only problem with my added test seems to be that programs 
>> cross-compiled with mingw does not work on native Windows so the tests 
>> fail.
>
> It doesn't look right. I'm not sure how you're testing it but as your 
> test shows msvcrt.dll is not supposed to handle x mode.

To me it looks like the opposite - that msvcrt.dll is supposed to handle it.

This is how I tested:

* I wrote a program using fopen(..., "wx") and compiled it with Visual
   Studio 2019. It works as it should in native Windows.

* I executed the binary compiled above in Fedora 34 with Wine
   6.16-staging, which printed
   0104:err:msvcrt:msvcrt_get_flags incorrect mode flag: x
   ... and overwrote the existing file.

* I downloaded the Wine source and compiled it to confirm that the bug
   still exists on master.

* I made a patch in dlls/msvcrt/file.c (msvcrt_get_flags) to add
   support for "x" and recompiled Wine clean.

* I executed the same program mentioned above using the Wine version I
   just compiled. The message "err:msvcrt:msvcrt_get_flags" was gone and
   the program instead behaved as it should. An existing file wasn't
   overwritten. If the file doesn't exist, it's created.

So, at this point I was pretty sure that was everything I needed to do. 
However, I then cross-compiled the same program with 
i686-w64-mingw32-gcc (Fedora MinGW 10.3.1-2.fc34, the same compiler used 
when building Wine). The same binary

* behaves properly in Wine.
* fails in native Windows.

>> Patch 2: ucrtbase: https://testbot.winehq.org/JobDetails.pl?Key=99684
>>
>> This patch fails less tests but does not solve the bug at all - so I 
>> don't think it's worth looking into why this patch also made totally 
>> unrelated tests fail. I think this patch can be abandoned.
>>
>> I'm not sure where to go from here.
>
> Are you sure you have tested it correctly? Did you recompile ucrtbase 
> with your patch?

I recompiled Wine after "make clean", "git clean -fdx" and "find -name 
'*.dll'" (which didn't show any dll's).

> The "misc.c:550: Test failed: 9 should be blank" failure is not related 
> to your patch and can be ignored. But there are other failures caused by 
> your patch:
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:1548: Test failed: creating file with mode wx failed
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:1557: Test failed: creating file with mode w+x failed
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> misc.c:372: Test failed: unexpected call global_invalid_parameter_handler
> 
> This generally shows that x mode is not supported in older version of 
> ucrtbase. While this needs to be fixed before the patch can go into wine 
> I would suggest focusing on understanding why the patch doesn't fix your 
> test app first (I guess it's a mistake while testing).

With the ucrtbase-patch, the app (compiled with VS2019) did not work 
since it still overwrote existing files. The .exe seems to need my patch 
to be compiled into msvcrt.dll for it to take effect.

Cross-compiling the app with mingw and running it on native Windows 
gives the result you showed above. It's the same result as with the 
msvcrt-patch. I guess Wine isn't involved at all here?

Could it be mingw that makes some mistake?

Br,
Ted