#418 Experimental MSVC project file for X64

[Carlo Bramini]

Attached to this issue there is the project file that I created for compiling the X64 emulator from VICE with MSVC.

The project file requires Visual Studio (obviously) and VCPKG.
VCPKG is used for adding support for thirdy party libraries required by VICE.
So, you must clone it from GITHUB and compile the libraries:
- sdl2-image
- sdl2
- zlib
Don't forget to integrate VCPKG with the command:

vcpkg integrate install

The archive with the project files must be uncompressed under the vice-emu-code directory, to keep relative paths working.

VCPKG is unable to handle sdl2-main module correctly.
So, you must open the properties of the project, next go to "Linker->General" and under the option for additional libraries directories, add the path where VCPKG has installed SDL2.
My path is C:\Users\carlo\Documents\GitHub\vcpkg\installed\x64-windows\lib\manual-link, but yours will be surely different.

Now you are ready to build X64 with Visual Studio .
I sent a number of patches to be evaluated before this issue, they will fix all issues with MSVC except one.
Unfortunately, Microsoft C compiler doesn't support #warning directive to the preprocessor.
There is no way to bypass this limitation, at least until VS2022 (not tried with VS2026 yet).
You can solve it only by deleting or commenting the lines with such command to preprocessor.

This is what I did:

Index: src/6510core.c
===================================================================
--- src/6510core.c      (revision 45868)
+++ src/6510core.c      (working copy)
@@ -845,7 +845,7 @@

 #ifndef ANE_LOG_LEVEL
 #define ANE_LOG_LEVEL 0
-#warning "ANE_LOG_LEVEL not defined, disabling by default"
+//#warning "ANE_LOG_LEVEL not defined, disabling by default"
 #endif

 #if 1
@@ -1383,7 +1383,7 @@

 #ifndef LXA_LOG_LEVEL
 #define LXA_LOG_LEVEL 0
-#warning "LXA_LOG_LEVEL not defined, disabling by default"
+//#warning "LXA_LOG_LEVEL not defined, disabling by default"
 #endif

 #if 1
Index: src/lib/libzmbv/zmbv.c
===================================================================
--- src/lib/libzmbv/zmbv.c      (revision 45868)
+++ src/lib/libzmbv/zmbv.c      (working copy)
@@ -52,7 +52,7 @@
 #elif defined(__GNUC__)
 #define ATTR_PACKED __attribute__((packed,gcc_struct))
 #else
-#warn "make sure to define ATTR_PACKED for your compiler"
+//#warning "make sure to define ATTR_PACKED for your compiler"
 #define ATTR_PACKED
 #endif

But this is not portable like all other changes, so I left it out.

I hope that you will find my work useful.

[gpz]

Thanks for all the patches.... i will look at them in the next day(s)

[gpz]

BTW, it would be helpful to know how you configured the code, and what the other changes contained in this zip are - ultimatively we want to provide the project files in the regular tree and it should just work :)

[gpz]

oh and the last case (ATTR_PACKED) - does it even work? i mean, can you actually produce working zmbv files?

[Carlo Bramini]

I don't think it is working.
This ATTR_PACKED is used for declaring zmbv_keyframe_header_t only.
In my opinion, these lines should be added before zmbv_keyframe_header_t declaration:

#ifdef _MSC_VER
#pragma pack(push, 1)
#endif

for saving the current state (PUSH) and setting the byte aligment (1) and these lines after:

#ifdef _MSC_VER
#pragma pack(pop)
#endif

for restoring the aligment previously saved with the PUSH.

EDIT: another way without using any packing directive could be this one:

enum {
    high_version = 0,
    low_version,
    compression,
    format,
    blockwidth,
    blockheight,
    zmbv_keyframe_maxitems
} zmbv_keyframe_items;

typedef uint8_t zmbv_keyframe_header_t[zmbv_keyframe_maxitems];

and replacing stuff like:

header->high_version

into:

header[high_version]

In my opinion, this is a cleaner and fully portable, but it needs more changes.

[gpz]

as said, these things need to be done upstream

[gpz]

i fixed libzmbv in the upstream repo (which happens to be mine...) and also in VICE of course - please try

the other #warning things, perhaps they should be changed into something like

#ifdef _MSVC_VER
#pragma message ("Warning: ....")
#else
#warning "..."
#endif

?

[Carlo Bramini]

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.

[gpz]

patch applied in r45880

[gpz]

@carlo_bramini so, i managed to build x64sc using vs2022 - that is a very good start!

then, i tried to enable reSID ... and i get drowned in errors - this is very weird. It looks like the problems relate to functions that are being "templated" using macros - perhaps this is another msvc quirk? Any ideas?

[Carlo Bramini]

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.

[gpz]

very cool, this also works!

i have seen in the list of files that some UI files for scpu64 and x64sc are there - does the project file allow to switch between these? ie the question is: what would be the smartest way to set this up to build all emulators, not just one?

that said, i tried to modify the project to build xvic the other night - and after some massaging could "almost" build it, but there seems to be some problem with the preprocessor, or order of includes, which produces errors in winnt.h (the "opcode" macro in vice somehow clashes with it)

[gpz]

PS: one thing i noticed is that src/vic20/carts is missing in the include path in the project

[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.

[gpz]

I am playing around with doing it manually... i also think just making a bunch of sub projects is the way to go.

as said before, you can configure the source with --enable-cmake and then you can import the result into visual studio - kindof, i couldn't make it work last time i tried. My experience with VS is very limited though, so no idea what the problem really was :)

That said, we are not going to officially support and/or maintain this stuff - since none of us even uses windows (as daily driver anyway). I'd put these files into the "building" dir in the source tree, with a readme that explains some things to get them going (i started writing this already)