Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing and cleaning up the Visual Studio solutions #438

Open
aybe opened this issue Jan 3, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@aybe
Copy link
Collaborator

commented Jan 3, 2018

Here is a list of pending items I think are worth fixing:

(strike-through items have been accomplished)

  • get the SDL1 configurations to build
    • NOTE: all flavors are now working SDL1|SDL2, Debug|Release, Win32|x64
  • replicate the include and src folders structure in the project itself for better experience
  • further cleanup of solution:
    • organizing using solution folders
  • changing bin and obj to .bin and .obj for clarity (help/advice wanted)
    • I didn't do it because some deployment scripts I didn't write could break
  • as Visual Studio 2017 is free of charge, I see no benefit in keeping vs2013 folder (help/advice wanted)
    • as a consequence vs2015 should be renamed then
  • whatever else, providing it's worth it and relatively affordable (help/advice wanted)
@roytam1

This comment has been minimized.

Copy link

commented Jan 4, 2018

as Visual Studio 2017 is free of charge, I see no benefit in keeping vs2013 folder (help/advice wanted)

For XP-compat build. But I hope files can be in sync (installing multiple versions of VS is a pain on small SSD).

@aybe

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 4, 2018

When you install it,

2018-01-04 05_48_28-visual studio installer

I wonder if 2013 toolset would work on it ... going to try that and see if it works.

Otherwise,

  • isn't there another way to do this, generally, there are always multiple ways to do things in C++ ?
  • wouldn't some MinGW cross-build magically fix this ? :)

#403

@joncampbell123

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2018

I know that VS2017 supports Windows XP, the problem is that the stat/_wstat() function doesn't work when run under Windows XP. Microsoft did something to the C runtime from VS2015 on that prevents stat/_wstat from working on XP, even if targeting XP.

stat() is used heavily in the DOSBox-X source code to the extent that you can't mount images or folders without it.

The Linux side of the code however uses autoconfig. Perhaps the automake/autoconf files could be adapted so that one can run ./configure from a MinGW shell on Windows.

@joncampbell123

This comment has been minimized.

Copy link
Owner

commented Jan 5, 2018

I would like to keep vs2013 around for those who want to still compile for Windows XP, at least until building with MinGW is stable.

@joncampbell123

This comment has been minimized.

Copy link
Owner

commented Jan 5, 2018

All of the bin and obj references are in the vcproj and sln files. That includes the post-build custom steps. The other script that relies on the bin directory is the Perl script that packs the output into a ZIP file.

@aybe

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 5, 2018

  1. see Notice: Windows XP is officially unsupported, may bitrot unless others wish to submit patches to maintain unofficial support #403 for my XP workaround, while it doesn't solve eventual code source compatibility, it does address the ability to build for XP under 2017.

  2. eventually, I'd like to re-group to .bin and .old for clarity and in the mean time craft a little Windows script for zipping all of the flavors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.