Carlo Bramini

Besides doing it manually with Visual Studio and create a number of sub-projects and static libraries like autoconf/automake does, probably the best and easier to maintain solution is to write something for creating everything on the fly with CMake. Today, I started to do something, it is not difficult but it requires some time.

Hello, I did a solution with a project file that you can use for building X64 emulator with resid. Resid has been added with a separate project file and compiled as static library, otherwise there is a conflict because there are source file with the same file and so the object files are overwritten. The attached file provides the new project. Don't forget to adjust again the path where sdlmain.lib is stored.

After reading your message, I also tried and you are right. I'm 100% sure that the Microsoft C/C++ compiler doesn't define WIN32 but only _WIN32 (I just tried to make a test) and in the past I was forced to do that change because an error happened. But now it works because the WIN32 macro has been added into the project file by Visual Studio, as you can see from the attached screenshot. So, it seems that the patch is no longer needed until WIN32 is defined somewhere. PS: I just read that you too...

Yes, I think that it can be also done like this, if you accept to manually add the path into the properties of the project.

I attached a refreshed patch that just uses system API Sleep() on Windows for emulating unix sleep() function. Tested on both MSVC and MinGW.

I think that it works because MinGW defines both _WIN32 and WIN32 (just tested), while Microsoft C compiler defines only _WIN32. However, WIN32 can be also added into the options of the preprocessor into Visual Studio, if someone wants, so this patch is not strictly required. However, it is also a good idea to signal this issue to the developers at OpenCBM, in my opinion.

I think that it works because MinGW defines both _WIN32 and WIN32 (just tested), while Microsoft C compiler defines only _WIN32. However, WIN32 can be also added into the options of the preprocessor into MSVC, if someone wants.

I fixed the build with MSVC by using your suggestion. Attached patch solved it. I made it for both vice\src\6510core.c and vice\src\6510dtvcore.c. Actually, I have not tested the changes into vice\src\6510dtvcore.c with MSVC, but I imported them with Winmerge, so I think that everything is fine.