August 2021 - Wine-Devel - list.winehq.org

[PATCH] mscoree: Add a buffer for Mono's debug output.

by Esme Povirk

Signed-off-by: Esme Povirk <esme(a)codeweavers.com> --- dlls/mscoree/metahost.c | 13 ------- dlls/mscoree/mscoree_main.c | 64 +++++++++++++++++++++++++++++++++- dlls/mscoree/mscoree_private.h | 2 ++ 3 files changed, 65 insertions(+), 14 deletions(-) diff --git a/dlls/mscoree/metahost.c b/dlls/mscoree/metahost.c index a272f83020a..c362265cf5d 100644 --- a/dlls/mscoree/metahost.c +++ b/dlls/mscoree/metahost.c @@ -137,8 +137,6 @@ static MonoAssembly* CDECL mono_assembly_preload_hook_fn(MonoAssemblyName *aname static void CDECL mono_shutdown_callback_fn(MonoProfiler *prof); -static void CDECL mono_print_handler_fn(const char *string, INT is_stdout); - static MonoImage* CDECL image_open_module_handle_dummy(HMODULE module_handle, char* fname, UINT has_entry_point, MonoImageOpenStatus* status) { @@ -378,17 +376,6 @@ static void CDECL mono_shutdown_callback_fn(MonoProfiler *prof) is_mono_shutdown = TRUE; } -static void CDECL mono_print_handler_fn(const char *string, INT is_stdout) -{ - const char *p; - for (; *string; string = p) - { - if ((p = strstr(string, "\n"))) p++; - else p = string + strlen(string); - wine_dbg_printf("%.*s", (int)(p - string), string); - } -} - static HRESULT WINAPI thread_set_fn(void) { WARN("stub\n"); diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c index a4567e96de2..a268638c879 100644 --- a/dlls/mscoree/mscoree_main.c +++ b/dlls/mscoree/mscoree_main.c @@ -50,6 +50,14 @@ WINE_DEFAULT_DEBUG_CHANNEL( mscoree ); WINE_DECLARE_DEBUG_CHANNEL(winediag); +struct print_handler_tls +{ + int length; + char buffer[1018]; +}; + +DWORD print_tls_index = TLS_OUT_OF_INDEXES; + typedef HRESULT (*fnCreateInstance)(REFIID riid, LPVOID *ppObj); char *WtoA(LPCWSTR wstr) @@ -214,6 +222,46 @@ HRESULT WINAPI CorBindToRuntimeHost(LPCWSTR pwszVersion, LPCWSTR pwszBuildFlavor return ret; } +void CDECL mono_print_handler_fn(const char *string, INT is_stdout) +{ + struct print_handler_tls *tls = TlsGetValue(print_tls_index); + + if (!tls) + { + tls = HeapAlloc(GetProcessHeap(), 0, sizeof(*tls)); + tls->length = 0; + TlsSetValue(print_tls_index, tls); + } + + while (*string) + { + int remaining_buffer = sizeof(tls->buffer) - tls->length; + int length = strlen(string); + const char *newline = memchr(string, '\n', min(length, remaining_buffer)); + + if (newline) + { + length = newline - string + 1; + wine_dbg_printf("%.*s%.*s", tls->length, tls->buffer, length, string); + tls->length = 0; + string += length; + } + else if (length > remaining_buffer) + { + /* this would overflow Wine's debug buffer */ + wine_dbg_printf("%.*s%.*s\n", tls->length, tls->buffer, remaining_buffer, string); + tls->length = 0; + string += remaining_buffer; + } + else + { + memcpy(tls->buffer + tls->length, string, length); + tls->length += length; + break; + } + } +} + BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); @@ -222,12 +270,26 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { case DLL_PROCESS_ATTACH: runtimehost_init(); - DisableThreadLibraryCalls(hinstDLL); + + print_tls_index = TlsAlloc(); + + if (print_tls_index == TLS_OUT_OF_INDEXES) + return FALSE; + + break; + case DLL_THREAD_DETACH: + if (print_tls_index != TLS_OUT_OF_INDEXES) + HeapFree(GetProcessHeap(), 0, TlsGetValue(print_tls_index)); break; case DLL_PROCESS_DETACH: expect_no_runtimes(); if (lpvReserved) break; /* process is terminating */ runtimehost_uninit(); + if (print_tls_index != TLS_OUT_OF_INDEXES) + { + HeapFree(GetProcessHeap(), 0, TlsGetValue(print_tls_index)); + TlsFree(print_tls_index); + } break; } return TRUE; diff --git a/dlls/mscoree/mscoree_private.h b/dlls/mscoree/mscoree_private.h index c4692b4e656..106171f8e43 100644 --- a/dlls/mscoree/mscoree_private.h +++ b/dlls/mscoree/mscoree_private.h @@ -219,4 +219,6 @@ extern HRESULT get_file_from_strongname(WCHAR* stringnameW, WCHAR* assemblies_pa extern void runtimehost_init(void) DECLSPEC_HIDDEN; extern void runtimehost_uninit(void) DECLSPEC_HIDDEN; +extern void CDECL mono_print_handler_fn(const char *string, INT is_stdout); + #endif /* __MSCOREE_PRIVATE__ */ -- 2.30.2

Aug. 31, 2021

Re: RFC: Reparse Point/NT Symlink Support [3]

by Erich E. Hoover

On Tue, Aug 31, 2021 at 11:11 AM Zebediah Figura (she/her) <zfigura(a)codeweavers.com> wrote: > ... > Doesn't this end up being a problem regardless of how we store symlinks > internally, though? As far as I can tell, all of this logic should > happen on the PE side. When we let the OS handle symlinks for us then everything seems to work properly, though it's possible that I've missed something. Best, Erich

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Alexandre Julliard

"Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes: > On 8/31/21 1:25 PM, Alexandre Julliard wrote: >> "Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes: >> >>> (3) Most importantly, I would like to coöperate with distributions. As >>> I understand, they already don't like the way we distribute wine-mono >>> and wine-gecko, and I don't think we should annoy them any further by >>> going behind their back and distributing more pre-built libraries. >>> >>> I know people here think that they won't want to distribute PE >>> libraries, but I'm inclined to think that at least some distributions >>> won't be happy with our proposed solution either. See [1] [2] [3] [4] >>> for popular distributions trying to discourage source imports and >>> static libraries. I get that we're a special case, and maybe >>> distributions will think so too, but I really want to again argue that >>> we shouldn't be making that decision for them. >> Have you tried asking them? > > I haven't yet. I didn't really want to speak on behalf of the Wine > project if the consensus was against consulting them, and I didn't > want to start that conversation without the possibility that its > fruits would at least be taken into account. But if there are no > objections I'll start writing some mails. I don't see any harm in asking. I'll admit that I'm fairly skeptical, so it will be up to you to build a convincing case. Getting the buy-in of the major distros is obviously a required step. >> Remember that we need the libs to have custom names, to avoid conflicts >> with Windows apps shipping the same libs. > > Yep, I've been keeping that in mind. If we want to distribute shared > libraries I'm inclined to think the best solution there is to copy (or > symlink, or fake-symlink) them into the prefix with different names. This won't work for nested dependencies. For instance the PE libpng is going to import the PE zlib, so it needs to have been renamed at build time already. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Zebediah Figura (she/her)

On 8/31/21 1:25 PM, Alexandre Julliard wrote: > "Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes: > >> (3) Most importantly, I would like to coöperate with distributions. As >> I understand, they already don't like the way we distribute wine-mono >> and wine-gecko, and I don't think we should annoy them any further by >> going behind their back and distributing more pre-built libraries. >> >> I know people here think that they won't want to distribute PE >> libraries, but I'm inclined to think that at least some distributions >> won't be happy with our proposed solution either. See [1] [2] [3] [4] >> for popular distributions trying to discourage source imports and >> static libraries. I get that we're a special case, and maybe >> distributions will think so too, but I really want to again argue that >> we shouldn't be making that decision for them. > > Have you tried asking them? I haven't yet. I didn't really want to speak on behalf of the Wine project if the consensus was against consulting them, and I didn't want to start that conversation without the possibility that its fruits would at least be taken into account. But if there are no objections I'll start writing some mails. > Remember that we need the libs to have custom names, to avoid conflicts > with Windows apps shipping the same libs. Yep, I've been keeping that in mind. If we want to distribute shared libraries I'm inclined to think the best solution there is to copy (or symlink, or fake-symlink) them into the prefix with different names.

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Rémi Bernon

On 8/31/21 8:06 PM, Zebediah Figura (she/her) wrote: > (1) I really don't want to have to build any libraries that aren't part > of Wine. More importantly, I don't want anyone who's not a regular Wine > developer to ever have to build any libraries that aren't part of Wine. > Also, if I do need to build (say) libvkd3d-shader, I want to *only* have > to build libvkd3d-shader and not all of the Wine dependencies at once. > > This is quite likely the only thing that holds me back from contributing > to wine-mono (not that this is entirely Esme's fault; the problem > affects mono upstream, although wine-mono has doubled down on it) > (Well, things like zlib is clearly not part of Wine, but TBH I don't really see how vkd3d is not a part of Wine.) With the PoC you could already be working on the dependencies sources in the "wine-ext" umbrella project, building whichever Wine module depends on it to test it. If you don't need to build any Wine module to test it, then just build the project with its own build system. Then, having a separate umbrella project has its drawbacks and I agree with Alexandre here that it makes bisection inconvenient. But even if we consider having the sources included in Wine you could very well have a configure flag to point to an alternate source location, while still using Wine makefiles to build the corresponding Wine module. > (2) I would like bisecting dependencies to not be a pain. As someone who > will be working on vkd3d a lot, this is quite important to me. Ideally > this means that the dependencies should exist in shared libraries, not > static ones. > > I would also like to be able to develop in a separate tree, since git > submodules are terrible for doing active development on a component. > Rémi's proposed solution does not really allow for that as far as I can > tell. > Anyway, I'm not sure vkd3d if was in question here. I mentioned it previously as an example of external dependencies which I would find nicer to have integrated with Wine build (alongside with wine-mono and wine-gecko but they're way beyond reach), but I don't know that we're planning on any change there. > As an aside, I still think there is something to be gained in using > shared libraries to reduce disk space. Almost all of our PE dependencies > are not only shared across multiple DLLs, but will often be loaded > multiple times in the same process (vkd3d, faudio, gnutls, libpng, zlib, > freetype, mpg123 all come immediately to mind. To some degree we can try > to abstract that out with our own shared-to-static shims, but that takes > some work which I think is rather unnecessary.) > Well, my PoC didn't use shared libraries because it seemed to be the initially intended way with Jacek idea. However, using Wine makefiles it's really just a matter of few lines and a specfile to make them DLLs instead. > (3) Most importantly, I would like to coöperate with distributions. As I > understand, they already don't like the way we distribute wine-mono and > wine-gecko, and I don't think we should annoy them any further by going > behind their back and distributing more pre-built libraries. > I'm sure they dislike the wine-mono / wine-gecko situation more because we're downloading them separately from an untrusted source rather than because they embed a lot of already packaged third-party dependencies. FWIW building them as part of Wine would probably be much appreciated, regardless of their content. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Rémi Bernon

On 8/31/21 4:47 PM, Alexandre Julliard wrote: > I like your idea of using the Wine makefiles and bypassing the upstream > build system. I'm not convinced that it can work in all cases, but when > it works it definitely makes things a lot easier. > Sure, I was even surprised it went so well. I guess we're lucky so far. >> * There's some remaining dependencies, although I thought maybe they >> weren't the most important ones, and maybe a unixlib split could be >> more appropriate: > > More important ones would be GnuTLS and libxml2. It may be interesting > to see how well GnuTLS works with your scheme. > I can have a try. -- Rémi Bernon <rbernon(a)codeweavers.com>

Aug. 31, 2021

[PATCH] mscoree: Don't trace arguments in CorExeMain.

by Esme Povirk

This can overflow the debug buffer. We could print each argument on an individual line, but command-line arguments can be obtained other ways and turned out to usually not be useful. Signed-off-by: Esme Povirk <esme(a)codeweavers.com> --- The argc trace is added so I don't get confused about whether logs are from a verion of Wine that traces arguments or not. The filename trace is kept because it's very convenient for the +mscoree trace to show every managed PE image loaded in the process. dlls/mscoree/corruntimehost.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/dlls/mscoree/corruntimehost.c b/dlls/mscoree/corruntimehost.c index 51522c57d83..c4dfbe88b99 100644 --- a/dlls/mscoree/corruntimehost.c +++ b/dlls/mscoree/corruntimehost.c @@ -1449,10 +1449,7 @@ __int32 WINAPI _CorExeMain(void) GetModuleFileNameW(NULL, filename, MAX_PATH); - TRACE("%s", debugstr_w(filename)); - for (i=0; i<argc; i++) - TRACE(" %s", debugstr_a(argv[i])); - TRACE("\n"); + TRACE("%s argc=%i\n", debugstr_w(filename), argc); filenameA = WtoA(filename); if (!filenameA) -- 2.30.2

Aug. 31, 2021

Re: [RFC PATCH 0/5] XAudio PE conversion.

by Alexandre Julliard

"Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes: > (3) Most importantly, I would like to coöperate with distributions. As > I understand, they already don't like the way we distribute wine-mono > and wine-gecko, and I don't think we should annoy them any further by > going behind their back and distributing more pre-built libraries. > > I know people here think that they won't want to distribute PE > libraries, but I'm inclined to think that at least some distributions > won't be happy with our proposed solution either. See [1] [2] [3] [4] > for popular distributions trying to discourage source imports and > static libraries. I get that we're a special case, and maybe > distributions will think so too, but I really want to again argue that > we shouldn't be making that decision for them. Have you tried asking them? Remember that we need the libs to have custom names, to avoid conflicts with Windows apps shipping the same libs. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2021

[PATCH v2] avicap32: Partially implement capCreateCaptureWindowW.

by Gijs Vermeulen

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=38011 Signed-off-by: Gijs Vermeulen <gijsvrm(a)gmail.com> --- dlls/avicap32/Makefile.in | 1 + dlls/avicap32/avicap32_main.c | 91 ++++++++++++++++++++++++++++------- 2 files changed, 75 insertions(+), 17 deletions(-) diff --git a/dlls/avicap32/Makefile.in b/dlls/avicap32/Makefile.in index 8f5a1089d5c..f320a58f04b 100644 --- a/dlls/avicap32/Makefile.in +++ b/dlls/avicap32/Makefile.in @@ -1,4 +1,5 @@ MODULE = avicap32.dll IMPORTLIB = avicap32 +IMPORTS = user32 C_SRCS = avicap32_main.c diff --git a/dlls/avicap32/avicap32_main.c b/dlls/avicap32/avicap32_main.c index 9e2a99d4c7c..3a421f330f4 100644 --- a/dlls/avicap32/avicap32_main.c +++ b/dlls/avicap32/avicap32_main.c @@ -56,36 +56,75 @@ WINE_DEFAULT_DEBUG_CHANNEL(avicap); +static WCHAR class_nameW[] = {'W','i','n','e','A','v','i','C','a','p','C','l','a','s','s',0}; + +static LRESULT CALLBACK avicap_wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) +{ + switch(msg) + { + default: + if (msg >= WM_CAP_START && msg <= WM_CAP_END) + FIXME("Unhandled message %#x\n", msg); + return DefWindowProcW(hwnd, msg, wparam, lparam); + } +} + +static void register_class(void) +{ + WNDCLASSEXW class; + + class.cbSize = sizeof(WNDCLASSEXW); + class.style = 0; + class.lpfnWndProc = avicap_wndproc; + class.cbClsExtra = 0; + class.cbWndExtra = 0; + class.hInstance = GetModuleHandleW(NULL); + class.hIcon = NULL; + class.hCursor = LoadCursorW(NULL, (LPWSTR)IDC_ARROW); + class.hbrBackground = (HBRUSH)(COLOR_BTNFACE+1); + class.lpszMenuName = NULL; + class.lpszClassName = class_nameW; + class.hIconSm = NULL; + + if (!RegisterClassExW(&class) && GetLastError() != ERROR_CLASS_ALREADY_EXISTS) + ERR("Failed to register class!\n"); +} + +static void unregister_class(HINSTANCE instance) +{ + if (!UnregisterClassW(class_nameW, instance) && GetLastError() != ERROR_CLASS_DOES_NOT_EXIST) + ERR("Failed to unregister class!\n"); +} /*********************************************************************** * capCreateCaptureWindowW (AVICAP32.@) */ -HWND VFWAPI capCreateCaptureWindowW(LPCWSTR lpszWindowName, DWORD dwStyle, INT x, - INT y, INT nWidth, INT nHeight, HWND hWnd, - INT nID) +HWND VFWAPI capCreateCaptureWindowW(const WCHAR *window_name, DWORD style, INT x, + INT y, INT width, INT height, HWND hWnd, INT id) { - FIXME("(%s, %08x, %08x, %08x, %08x, %08x, %p, %08x): stub\n", - debugstr_w(lpszWindowName), dwStyle, x, y, nWidth, nHeight, hWnd, nID); - return 0; + FIXME("(%s, %08x, %08x, %08x, %08x, %08x, %p, %08x): semi-stub\n", + debugstr_w(window_name), style, x, y, width, height, hWnd, id); + + return CreateWindowExW(style, class_nameW, window_name, style, x, y, width, height, + hWnd, NULL, GetModuleHandleW(NULL), NULL); } /*********************************************************************** * capCreateCaptureWindowA (AVICAP32.@) */ -HWND VFWAPI capCreateCaptureWindowA(LPCSTR lpszWindowName, DWORD dwStyle, INT x, - INT y, INT nWidth, INT nHeight, HWND hWnd, - INT nID) -{ UNICODE_STRING nameW; - HWND retW; +HWND VFWAPI capCreateCaptureWindowA(const char *window_name, DWORD style, INT x, + INT y, INT width, INT height, HWND hWnd, INT id) +{ UNICODE_STRING window_nameW; + HWND ret; - if (lpszWindowName) RtlCreateUnicodeStringFromAsciiz(&nameW, lpszWindowName); - else nameW.Buffer = NULL; + if (window_name) RtlCreateUnicodeStringFromAsciiz(&window_nameW, window_name); + else window_nameW.Buffer = NULL; - retW = capCreateCaptureWindowW(nameW.Buffer, dwStyle, x, y, nWidth, nHeight, - hWnd, nID); - RtlFreeUnicodeString(&nameW); + ret = capCreateCaptureWindowW(window_nameW.Buffer, style, x, y, width, height, + hWnd, id); + RtlFreeUnicodeString(&window_nameW); - return retW; + return ret; } #ifdef HAVE_LINUX_VIDEODEV2_H @@ -195,3 +234,21 @@ BOOL VFWAPI capGetDriverDescriptionW(WORD wDriverIndex, LPWSTR lpszName, TRACE("Version: %s - Name: %s\n", debugstr_w(lpszVer), debugstr_w(lpszName)); return TRUE; } + +BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, void *reserved) +{ + TRACE("(%p %d %p)\n", instance, reason, reserved); + + switch(reason) + { + case DLL_PROCESS_ATTACH: + DisableThreadLibraryCalls(instance); + register_class(); + break; + case DLL_PROCESS_DETACH: + if (reserved) break; + unregister_class(instance); + } + + return TRUE; +} -- 2.33.0

Aug. 31, 2021

Re: [PATCH 1/2] wininet: Return ERROR_CANCELLED for unsupported errors in InternetErrorDlg.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=96933 Your paranoid android. === debiant2 (32 bit report) === wininet: internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12168) === debiant2 (32 bit Chinese:China report) === wininet: internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12168) === debiant2 (32 bit WoW report) === wininet: internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12168) === debiant2 (64 bit WoW report) === wininet: internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12040) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12041) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12042) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12044) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12052) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12053) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12166) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12167) internet.c:1573: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1578: Test succeeded inside todo block: Got 1223, expected 1223 (12168) internet.c:1587: Test succeeded inside todo block: Got 1223, expected 1223 (12168)

Aug. 31, 2021