Moving modules to use msvcrt has had the unfortunate side effect that tracing LONG_PTR/DWORD_PTR/etc. using %ld no longer works—since a long is 32 bits wide as far as msvcrt is concerned, it cuts off top 32 bits on 64-bit platforms. This has already caused me some grief while debugging.
I'm not sure what we can use in its place, though:
* Our msvcrt supports the standard %z, %j, %t. I originally assumed this would work, but unfortunately it seems native msvcrt only supports this on 64-bit and only in very recent versions of Windows. mingw-w64 accordingly spits out warnings if we try to use it in 32-bit code. I think ucrtbase always supports them, but only some modules use ucrtbase (and especially considering e.g. tests I doubt that converting everything else to use ucrtbase is a good idea).
* Both builtin and native msvcrt always support %I, but it's nonstandard and it spits out warnings when you try to use it when not compiling with mingw.
* PRIxPTR (etc.) almost works, except that on 32-bit both mingw and the native compiler spit out warnings because it expands to "x" while the type is defined as "long int".
* Along those lines I guess we could define our own PRI-type macro...
* We could also cast to (void *), or cast to a 64-bit type and use wine_dbgstr_longlong(), though this has the unfortunate side effect of forcing us to trace in hexadecimal.