NT 5.2 compatibility (XP x64, Server 2003 x64) broken for all 64-bit applications, tons of error messages

[GrandAdmiralThrawn]

Currently, MacType 2019.1-beta6 doesn't work properly on 64-bit NT 5.2 systems, such as Windows XP Professional x64 Edition or Windows 2003 Server x64.

The reason appears to be that the 64-bit binaries and libraries of MacType are built/linked under the assumption that certain Vista+ functionality is present on all x64 machines. This is not the case for XP x64 and Server 2003 x64.

As a result, font rendering does not work for any 64-bit applications on such systems, and each x64 application launch will spawn some missing function call error(s), which is really nasty, especially on boot (it happens even at the Winlogon stage!).

I inspected the files, and here's a list of kernel32 api function calls implemented in the bins/libs that break on XP:

• EasyHK64.dll => InitializeCriticalSectionEx()
• MacLoader64.exe => Wow64GetThreadContext(), Wow64SetThreadContext()
• MacType64.Core.dll => InitializeCriticalSectionEx()
• MacType64.dll => Wow64GetThreadContext(), Wow64SetThreadContext()
• mt64agnt.exe => EnumerateLoadedModules()

Here's an example of the error happening upon launching a 64-bit program:

Also, when closing MacType's Wizard, this happens (bugreport):

I'm not sure how MacType is being compiled, but if it's done in MS VisualStudio, you'd definitely need to change the platform toolset for the 64-bit parts, e.g. from v140 to v140_xp or similar.

Thank you.

[snowie2000]

This is a problem of the installer since we don't support x64 version of XP/server 2003. All those x64.dlls should not be extracted. @sammilucia

[GrandAdmiralThrawn]

This is a problem of the installer since we don't support x64 version of XP/server 2003. All those x64.dlls should not be extracted. @sammilucia

Are there any plans to support the platforms? Because if it's working only for 32-bit programs, then it won't be very useful, and the user experience will be inconsistent across 32/64-bit programs on those operating systems.

Of course, if it's too niche, that's understandable as well.. although... ezgdi can do it.

Thanks for your work!

[snowie2000]

I already tried, but unfortunately failed. It's not because as of the release of XP x64, Microsoft didn't think too much about the interaction between the x86 apps and x64 apps. There are very few APIs available to intercept x64 process from an x86 process and there seem to be no people working on it so far.

In fact, Mactype can work with XP x64 with limited functions. HookChildProcess doesn't work if you start an x64 process from an x86 process and vice versa. MacTray.exe can't manage x64 process because it can't access x64 processes with our current process proxy, it has to be rewritten. The reason that ezgdi can work on it is that it uses a much simpler loading method: WindowsHook which has tons of compatibility problems, but it works without knowing the exact status of the x64 process.

x64 bit of server 2003 and xp is rarely used and already abandoned by Microsoft. Things are moving forward, I think we've tried our best and should focus on more modern OSes people are using as what we are doing to the endless updating Windows 10.

[GrandAdmiralThrawn]

Too bad... This would've been the most important thing for me.

But it can't be helped I guess.

Thank you for the explanation. I thought that if I would hack the binaries, redirecting all kernel32 calls to my own stub DLL, I could just provide the program with a reimplementation of the missing functions, while re-directing all others to the real kernel32. dll. That trick has worked on a lot of programs and games before (like Oleg Ovcharenkos / UncleVasyas "Stellaris WinXP fix" or KawaiiSaras / ScavengerSpbs binary fixes for XCom).

But those weren't mixed 32-/64-bit programs, so I'm not sure if those hacks would apply here (This is a bit beyond my skill levels)...

Anyway, if this is a "won't fix", I can understand.. I'm aware, that XP x64 is indeed very niche...

[snowie2000]

Thank you, but you don't need to hack the binaries. MacType is an open source software. You can simply replace those calls to the missing APIs to your custom implementation, and as long as you did it correctly, everything should work well.

Actually, Windows never provided enough APIs to interop between x86 and x64 processes. Currently, Windows allows x64 processes to access x86 processes via an API set of wow64*, but x86 processes have nothing to do with any x64 processes. Even as simple as fetching information about x64 processes is not completely possible. There is where wow64ext comes into play. It allows us to do some limited things to x64 processes from wow64 which is pretty enough for MacType now.

If you could provide or find such replacement for XP for those missing APIs, I think we can make MacType completely functional on XP x64.

PS: Don't bother fixing APIs such as InitializeCriticalSectionEx, a simple recompilation of MacType with XP toolkit is enough to fix it.