[0.4.11][DOC] Correct README.WINE regarding winhttp.dll

Because we reverted [WINHTTP] in releases/0.4.9 and releases/0.4.10 and releases/0.4.11
to the state before 9048599788 (==SVN r75944) which was WineStaging-2.9

Ftr: Back then the winhttp_winetest was not reverted as well, which makes a few of the tests hang. (which is one but not the only reason)

Current state of those tests:
0.4.14-release-93-g10d0e9b  RosBELin GCC8.4.0 does not hang 'most of the times' but sometimes it does, later during 0.4.15-dev even more tests were disabled here
0.4.14-release-93-g10d0e9b  RosBEWin2.1.6dbg  winhhtp.dll 301.568 Winestaging-4.18 kernel32_vista-dep    winhttp_apitest 21executed, 1failure   winhttp_winetest notification 643executed, 26fail, 1skip  winhttp_winetest url 243executed, 1failure   winhttp_winetest winhttp 4964executed, 14failures, 1skip
0.4.13-release-159-ge70a565 RosBEWin2.1.6dbg  winhhtp.dll 301.568 Winestaging-4.18 kernel32_vista-dep    winhttp_apitest 21executed, 1failure   winhttp_winetest notification 409executed, 26fail, 1skip  winhttp_winetest url 223executed, 1failure   winhttp_winetest winhttp (hangs more than 5minutes)
0.4.12-release-188-gd73c71e RosBEWin2.1.6dbg  winhttp.dll 303.616 Winestaging-3.9  kernel32_vista-dep    winhttp_apitest 21executed, 1failure   winhttp_winetest notification 409executed, 26fail, 1skip  winhttp_winetest url 223executed, 1failure   winhhtp_winetest winhhtp 5037executed, 15failures, 0skip
0.4.11-release-197-gdbcd8aa RosBEWin2.1.6dbg  winhhtp.dll 297.984 Winestaging-2.9                        winhttp_apitest 21executed, 1failure   winhttp_winetest notification (hangs more than 5minutes)  winhttp_winetest url 223executed, 1failure   winhttp_winetest winhttp (hangs more than 5minutes)
0.4.10-release-214-g711e70c RosBEWin2.1.6dbg  winhhtp.dll 295.424 Winestaging-2.9
0.4.9-release-225-g9ff478e  RosBEWin2.1.6dbg  winhttp.dll 295.424 Winestaging-2.9                        winhttp_apitest 21executed, 1failure   winhttp_winetest notification (hangs more than 5minutes)  winhttp_winetest url 223executed, 1failure   winhttp_winetest winhttp (hangs more than 5minutes)
0.4.8-release-234-g862997f  RosBEWin2.1.6dbg  winhttp.dll 302.592 Wine-3.0         kernel32_vista-dep    winhttp_apitest 21executed, 1failure   winhttp_winetest notification 409executed, 26fail, 1skip  winhttp_winetest url 223executed, 1failure   winhttp_winetest winhttp 5028executed, 12failures
0.4.7-release-263-g0c09cd7  RosBEWin2.1.6dbg  winhttp.dll 301.056 WineStaging-2.16 kernel32_vista-dep    winhttp_apitest 21executed, 1failure   winhttp_winetest notification (hangs more than 5minutes)  winhttp_winetest url 223executed, 1failure   winhttp_winetest winhttp 5015executed, 12failures

We toggled some of the hanging tests in:
0.4.14-dev-787-g 0685e02d9e workaround more tests in winhttp:winhttp hang
0.4.14-dev-717-g 68490c1613 Restore winhttp:notification test_persistent_connection execution
0.4.8-dev-861-g 89670a48ab workaround winhttp:notification test_persistent_connection hang
0.4.8-dev-237-g a22031dba6 workaround winhttp:notification test_persistent_connection hang

Since the testbots do no longer run with the GCC4.7.2 builds, it does not really make a lot of sense to port any of those workarounds back atm.

I do consider none of the above states really desireable, therefore I don't touch the mess today, just document it.
I dislike: the kernel32_vista-dep.
I dislike: the behavior in the synthetic tests.
I appreciate: In practice all of the above do behave rather sane in most practical (non-synthetic) tests.
Remember: The Flash-ONLINE-setups are broken also on XPSP3. We should not accept that as a valid testcase. That does not work even in 0.4.9RosBEWin2.1.6 / 0.4.13RosBEWin2.1.6 / 0.4.14RosBEWin2.1.6! Despite what the ticket CORE-13952 says. It lies!
Flash OFFLINE setup from rapps works. The app is discontinued.

I could imagine in the future:
-downgrade releases/0.4.8 and 0.4.7 also back to Winestaging 2.9 to kill the kernel32_vista-import. (Could be done with or without suppressing the hangs in the [too new] synthetic tests)
-observe whether releases/0.4.13 has any other issues in winhhtp-context, and if so we might want to step back to Winestaging-3.9 (the natural fit).

But not today.
The reverts were questionable from the standpoint of the synthetic tests and also
from the standpoint of the broken "Adobe Flash Online Updater". They might work by chance on the linux builds, but that does not transfer to the Windows builds. And most likely points to some (memory) corruption.
Reverts could only be justified by the kernel_vista removal.
This commit is contained in:
Joachim Henze 2023-10-01 05:46:24 +02:00
parent dbcd8aaa71
commit 5261d7ad85

View file

@ -200,7 +200,7 @@ reactos/dll/win32/windowscodecs # Synced to WineStaging-3.9
reactos/dll/win32/windowscodecsext # Synced to WineStaging-2.9
reactos/dll/win32/winemp3.acm # Synced to WineStaging-3.3
reactos/dll/win32/wing32 # Synced to WineStaging-3.3
reactos/dll/win32/winhttp # Synced to WineStaging-3.9
reactos/dll/win32/winhttp # Synced to WineStaging-2.9
reactos/dll/win32/wininet # Synced to WineStaging-3.9
reactos/dll/win32/winmm # Forked at Wine-20050628
reactos/dll/win32/winmm/midimap # Forked at Wine-20050628