Can't load FCEUX project into Visual Studio

[robinhood2014]

The process bombs out with the following error message: C:\Users\donni\Source\Repos\fceux\vc\vc14_fceux.vcxproj : error : Error HRESULT E_FAIL has been returned from a call to a COM component.

[JasonWThompson]

It took some effort to get it to load for me, but I did it by modifying the project file. I'll post my version of the file to my GitHub fork tommorow and post a link here.

[bbbradsmith]

Could you explain in more detail what the problem is? (And what you had to modify to make it work?) I don't know how to duplicate the problem.... if I download the repository, open the vc14_fceux.sln, it will just build and run fine for me (in VS 2017 or 2019 community).

[JasonWThompson]

@robinhood2014, I changed the platform toolset from 140_xp to 141 in vc\vc14_fceux.vcxproj. I completely closed out of Visual Studio and then started it back up and it just work. You can look at my changes in my repo's fork:

https://github.com/JasonWThompson/fceux/tree/VisualStudio2019

I'm not very familiar with Visual Studio, but my guess is that neither of us has the 140_xp platform toolset on our system. Try it out and see if that works for you.

[bbbradsmith]

Ah, well the XP toolsets aren't installed by default, though I'm surprised there wasn't a more descriptive error given. It should tell you that the toolset is missing and give some sort of suggestion about how to acquire it, as far as I remember...

At any rate, in the menu: Tools > Get Tools and Features you can go to Individual Components and add the XP build support.

[robinhood2014]

"C++ Windows XP Support for VS 2017 (v141) tools"? That's marked as "deprecated" by the VS Installer, so we might want to do something to fix this.

[bbbradsmith]

The "deprecation" is that Microsoft doesn't want to support windows XP anymore, hence they only begrudgingly provide tools for building it. The only "fix" for this is FCEUX not supporting Windows XP anymore.

I don't consider doing that a fix for any real problem that we have. There doesn't seem to be any particular need to remove XP support, and FCEUX runs well on XP still. Even though the toolset is not installed by default, it's still very available.

Changing the toolset from v141_xp to v141 doesn't really benefit running it on Windows Vista and later, it just means the executable won't run on XP anymore.

[JasonWThompson]

Thanks! Following your instructions allowed me to open the solution in Visual Studio 2019 without modifications. I created a PR to add a note for future developers who want to poke at the code.

https://github.com/TASVideos/fceux/pull/132

[mossheim]

is there any interest in having VS projects generated from cmake instead of the checked-in project?

[bbbradsmith]

I don't see a practical advantage of adding a dependency on cmake tools to the windows build? TBH the fact that I could just download the source, open the .sln and build it with only Visual Studio is pretty much the reason I became involved in this project.

[mossheim]

the practical advantages are:

• you don't have to worry about losing compatibility with future versions of VS
• people have more flexibility in how they generate their projects
• a single build system is easier to maintain than two build systems, and easier to document

VS 2017 and later has built-in support for cmake-based projects: https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio/, so you could still drop it into Visual Studio and build without any extra trouble.

[bbbradsmith]

The advantages you listed are generic promises of systems like cmake. What I meant by practical advantage is that I'm trying to think of what it would make easier for FCEUX vs. what we're already doing.

• In my experience the pain of upgrading VS versions usually has a lot more to do with code maintenance than solution/project maintenance.
• I don't know what specific flexibility you're hoping to provide for this project.
• The windows build is very, very different than the linux one, so the way a single cmake project is going to account for this still would still look like "two build systems" to me, just contained in a different place.

So... if it's actually turnkey and I can still just open the solution and it will open the cmake project just like it was a regular VS project, then I'm theoretically neutral to it.

If it makes it harder for others to "dive in" to the code in some way, then I'd be opposed to it, but at this point I don't know what we'd really be looking at. My past experiences with cmake on windows are apparently out of date.

My baseline assumption for this kind of suggestion is that it looks like a lateral change that will have a lot of long-term maintenance burden as we slowly discover things that were lost in the switch. I could be wrong, but that's my gut reaction.

[mossheim]

no worries, just asking. :) i wouldn't contribute this to a project knowing that maintainers are opposed to it.

[bbbradsmith]

I would not stand in the way if others are in favour of it.