Marius Negrutiu

Fix confirmed. Binaries built with -D_WIN32_WINNT=0x0400 load succesfully in NT4

Thank you, Pali. I'm using mingw package from msys2 to build my project, and your fix is not yet released there. I'll re-test as soon as it becomes available and report back with the results. Cheers!

msvcrt!_strtoi64 doesn't exist in Windows NT 4

Good point. I've committed the changes here.

After some more research I think there's a better way to fix this... It turns out that -fno-tree-loop-distribute-patterns flag turns off the pattern recognition (such as memmove, memcpy, memset, etc.) and fixes our linker error. It also requires no changes to decompress.c. More details here (look for "-ftree-loop-distribute-patterns"). Check out my full commit here.

I'm afraid this wouldn't work. From compiler's perspective *(pos + v) is the same as pos[v]. You'll get the same linker error. It's the volatile keyword that turns off compiler optimizations and prevents memmove calls. Another approach would be to enclose the entire decompress.c into a pragma block like so: #pragma GCC push_options #pragma GCC optimize ("O0") ..existing code... #pragma GCC pop_options That would turn off optimizations on the entire file, and, get rid of typecasts...

Hi guys. I've been struggling with this issue myself for a few days... Indeed, the gcc10 optimizer identifies code that moves memory and replaces it with msvcrt!memmove calls. My approach was to disable these optimizations in decompress.c by using the volatile qualifier on destination addresses. For instance, the line decompress.c:266 while (v > 0) { pos[v] = pos[v-1]; v--; } ...would become... while (v > 0) { ((volatile UChar*)pos)[v] = pos[v-1]; v--; } See my full commit here.

This is exactly what I was looking for. Thanks!