search

enlyze / EnlyzeWinCompatLib

Let MSVC v141_xp/Clang targeted applications run on even older Windows versions
MIT License
27 stars 7 forks source link

Windows 98 and Windows 10 SDK compatibility #1

Open danielmarschall opened 2 years ago

danielmarschall commented 2 years ago

Thank you very much for your solution of making Visual Studio applications compatible with older Windows versions.

I try to achieve to run an application on Windows 95 while compiling using Visual C++ 2019. Currently I need to compile with OpenWatcom in order to create a Win95 binary of my application.

I have following problems:

(1) In winnt_50.cpp at function _CompatInterlockedFlushSList :

        SLIST_HEADER NewHead = InitialHead;
        ListEntry->Next = NewHead.Next.Next;
        NewHead.Next.Next = ListEntry;
        NewHead.Depth++;
        NewHead.Sequence++; // not existing

In my Windows 10 SDK, the field "Sequence" is only available if defined(_AMD64_) or defined(_ARM64_), but not for defined(_X86_) or defined(_ARM_).

For x86, the definition in my Win10 SDK is:

typedef union _SLIST_HEADER {
    ULONGLONG Alignment;
    struct {
        SLIST_ENTRY Next;
        WORD   Depth;
        WORD   CpuId;
    } DUMMYSTRUCTNAME;
} SLIST_HEADER, *PSLIST_HEADER;

For the moment, I have simply commented out the line. But I am not sure if that fix is appropriate.

(2) In my application I have following unresolved Win2000 dependencies which are supported by EnlyzeWinCompatLib:

(2a) In addition, I see following unresolved Win98 dependencies:

=> For these two functions, I have created following patch (sorry, I am not used to GIT/PullRequests, so I just uploaded my code). EnlyzeWinCompatLib-Patch-VTS-1.zip I haven't tested the functions themselves, and I am not sure if winnt_50.cpp is the correct "home" for these two functions. I think I should have called the file win98.cpp, since it implements functions missing in Windows 98. With the patch, I could successfully run my application on Windows 98 SE!

(2b) Win95 has more additional dependencies (used by the SDK, not used in my code):

=> Would it be possible to write patches for these functions as well? I would be super happy about it!

(3) When I untick the option "Inherit from parent or project defaults" as described on your website, I get a lot of errors of unresolved symbols, so I cannot build my executable. What am I doing wrong? image

If I simply place the source files into my own project (without dependency), then it works.

(4) My application (a Photoshop plugin) crashes on one Win2000 computer and on another Win2000 VM it doesn't crash.

The crash happens when I call the function ceil. Directly after ceil is executed, the CompatInterlockedFlushSList compatibility function is called, and after that call, the program crashes.

int main() {
..........
        simplealert(_strdup("Debug A"));
        int32 y = (int32)ceil((x / 10.) * 9);
        simplealert(_strdup("Debug D"));
..........
}

extern "C" PSLIST_ENTRY WINAPI
LibInterlockedFlushSList(PSLIST_HEADER ListHead)
{
........
            MessageBox(NULL, "B", "Debug", MB_OKCANCEL);
            pfnInterlockedFlushSList = _CompatInterlockedFlushSList;
            MessageBox(NULL, "C", "Debug", MB_OKCANCEL);
........
}

This sample program will output the debug messages A, B, C and then crashes. So, I have the suspicion that the reason is my commented out NewHead.Sequence++, and it is most likely dependent on the CPU of the computer.

But, theoretically, it is also possible that Visual C++ 2019 creates CPU OP codes which cannot be executed by the CPU of the old computer (Intel Celeron 500 MHz), and the call to InterlockedFlushSList is invoked by a crash handler or similar. Having ceil crashing probably means that there is some CPU airthmetic related stuff going on, probably in combination with compiler optimizations.

(5) When I included the .asm files in my project and enabled "masm", I cannot compile my application with Win64 anymore. (I compile my application in 32 and 64 bit)

Following errors show up when I try to compile as X64:

  1. I get a lot of errors at _CompatInterlockedFlushSList, saying "union _SLIST_HEADER has no member Next/Depth/Sequence".

  2. The asm files show that .model flat has a syntax error, because "model" is not existing in x64

How can I completely disable "masm"/EnlyzeWinCompatLib for the X64 build?

Thank you for your help!

ColinFinck commented 2 years ago

Hello @danielmarschall. Thanks for your feedback! I'm surprised that any of this is compatible to Windows 98 SE, considering that it's a completely different line of Windows that came with its own SDK. I would expect a lot of problems regarding non-existing kernel and Unicode APIs. Due to that, and as we fortunately don't have a customer still running Windows 9x, I currently have no plans to officially add support for it to EnlyzeWinCompatLib. You are free to click "Fork" on GitHub though and maintain your own version with Windows 9x compatibility.

That said, I can answer some of your questions though:

(1) You are apparently using the "msvc-v141-xp" branch of EnlyzeWinCompatLib, which provides compatibility down to Windows 2000 using the Windows SDK 7.1. I have superseded this version by the "clang" branch, which adds support for older Windows (Windows NT 4.0) and newer Windows SDK (10.x). Read my newer post for all details: https://building.enlyze.com/posts/targeting-25-years-of-windows-with-visual-studio-2019/

Among other things, that code fixes the mentioned problem with the _SLIST_HEADER by defining its own structure.

(2a) SetFilePointerEx and GetFileSizeEx are also implemented in the "clang" branch for Windows NT 4.0 compatibility.

(2b) I'm surprised that FindFirstFileExW is apparently the only Unicode function that's missing on Windows 95. Your proposed fallback to FindFirstFileA sounds like a possible last resort. But I would first check where it's actually used.

InitializeCriticalSectionAndSpinCount is implemented in the "clang" branch for Windows NT 4.0 compatibility, and exactly as you proposed (ignoring the spin count, it's just an optimization).

IsDebuggerPresent can be implemented to always return FALSE.

For a first try, I would also implement IsProcessorFeaturePresent to always return FALSE. In the worst case, some code simply runs less efficiently. Check what actually uses that function and what feature is checked. Even when that function is present on Windows 98 or NT 4.0, it may always return FALSE for some requested features, simply because the operating system doesn't know about that CPU feature. Just compare the current documentation of IsProcessorFeaturePresent to the old one.

(3) For the "msvc-v141-xp" branch, this is a two-stage process. You first untick "Inherit from parent or project defaults" and then include "EnlyzeWinCompatLib.h". That header file has "/lib" commands to add the missing library references again, but AFTER linking to EnlyzeWinCompatLib first. As the clang compiler doesn't support it that way, it's done differently in the "clang" branch.

(4) Try moving your entire project to my "clang" branch and the Clang toolkit as proposed in my latest blog post. See the clang version of my Wizard-2020 project as an example.

This should solve both of your problems:

(5) Off the top of my head, I would select all files of EnlyzeWinCompatLib, right-click them --> Properties and set "Excluded From Build" to "Yes" for the "x64" configuration. This still builds EnlyzeWinCompatLib, but the resulting library should be empty. Which is fine, because linking works then, but no API is overwritten. You could as well wrap each of its source files in #if defined(_X86_) statements.

danielmarschall commented 2 years ago

Hello,

thank you very much for your extensive answer!

I am sure there are no Windows 95/98 users of my software out there, but it gives me a "good feeling" to document that my software works with every 32/64 Windows version of Windows that has every existed. Yes, it sounds a bit strange, and is probably also mixed with a lot of nostalgia :-) It would be nice if EnlyzeWinCompatLib could help me building with Visual Studio, but if it will fail, I can still continue using OpenWatcom for the x86 builds of my application.

I will try your "clang" branch and check if the problems persist.

In re (2):

I have checked the following directories and searched for all .c and .h files

It seems like IsProcessorFeaturePresent is only used for some kind of security error reporting, so it doesn't seem to be anything important.

What I don't understand is why FindFirstFileExW is included in my executable. This function is not used in any C-files of my own project, and it is not used by any C-files by the CRT/SDK. Do you have an idea where I can find out where it might come from?

(4) The clang compiler supports a fine-granular -march parameter to set the exact target CPU you want to build for. I use -march=pentium-mmx here, which should also work with every Celeron.

I don't have much experience with these compiler settings. I have a question: Will this compiler setting let my code be less effective on modern CPUs, by omitting fancy OP codes that could improve performance, or will the executable determine its own CPUID in order to find out which code branch will be used?

ColinFinck commented 2 years ago

I don't have much experience with these compiler settings. I have a question: Will this compiler setting let my code be less effective on modern CPUs, by omitting fancy OP codes that could improve performance, or will the executable determine its own CPUID in order to find out which code branch will be used?

-march sets the baseline CPU architecture. The compiled binary is not supposed to run on a CPU below that. Detecting a CPU feature at runtime and using a faster implementation needs to be done manually. Some Visual Studio CRT math functions may already do that, but this is the exception of the rule.

If -march=pentium-mmx is used, it will likely omit opcodes that are taken for granted on modern computers. Whether that has a noticable performance impact depends on your actual application.