3 commits

Author	SHA1	Message	Date
Mohmed abdel-fattah	9b3c11122b	[misc] reinstate delay-loading of wininet and virtdisk DLLs ... * Per #2272 and #1877, MinGW has issues when delay loading libraries, but it is possible to apply a workaround to alleviate them, by redefining DECLSPEC_IMPORT before including the corresponding headers. * This is a bit more tricky to accomplish for virtdisk, as MinGW's windows.h header does include virtdisk.h on its own (rather than expect a formal include as MSVC does), so we have to prevent the virtdisk.h inclusion first, by defining a macro, and then apply our workaround. * Per https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/ea87573f-65ea-44a2-b4bb-ca96c0a136ab%40akeo.ie/#msg58793876 we are hoping that this should be a temporary workaround and that the root cause of the issue will be fixed in binutils. * Closes #2513.	2024-07-13 17:43:40 +01:00
Pete Batard	a3c75e480e	[core] revert to direct-hooking into wininet.dll ... * This reverts 3194a4dac4 on account that MinGW's delay loading of wininet.dll causes the application to prematurely close. * Yet another episode of the never ending #1877 saga...	2022-04-27 10:41:19 +01:00
Pete Batard	3194a4dac4	[net] drop direct hooking into wininet DLL and use delay-loading instead ... * Now that we can delay-load DLLs for both MinGW and MSVC, we can remove the cumbersome direct DLL hooks into wininet.dll (which is vulnerable to side loading when not delay-loaded) and revert to using direct API calls instead. * This reverts part of e1d864f755. * Also attempt to silence a Coverity warning.	2022-04-12 13:35:41 +01:00