Fixed project/solution files to consistent format that Visual Studio generates

[kiyolee]

Nothing fancy. Make sure all project/solution files are DOS format. Removed trailing CRLF from *.vcxproj{.filters}.

[tomcw]

This PR affects all 29 VS .sln/.vcxproj{.filters}'s.

I did a binary comparison of all these VS files in both the top level folder & lib folders, and only these 2 differ:

• AppleWinExpress2010.vcxproj
• AppleWinExpress2010.vcxproj.filters

In both cases your file is 2 bytes smaller because it doesn't have the trailing CRLF.

But the problem is your PR contains complete replacements for all files, ie. all lines in those files!
I want the PR to contain just those files that have changed, and just the lines that have changed.

Can you re-submit?
Thanks.

[kiyolee]

When file format changes from unix to dos, all lines are meant to be changed. (unfortunately github have no option to do diff ignoring end of line mark. but git diff -w would show there is no change.) That's the main point of this PR. Similarly, *2010*.vcxproj became smaller by 2 bytes is also a point of this PR. Not sure what I can do to help. If you run dos2unix across all those files of unix format, that would produce the same result. That's what I did actually.
Note that I cloned your repository while keeping file format as is and so noticed the unix formatted project files. If you have configured git to check out files as dos format, you probably won't see the differences.
I submit this PR is to make my other later PRs easier (hopefully) to deal with. Those project files would have real changes and those changes would be more difficult to stand out if the file format gets into the way.

[tomcw]

Hmm... I have my Git for Windows configured as "Checkout Windows-style, commit Unix-style line endings" (ie. converts LF to CRLF on checkout, and vice versa. on commit), which explains why my binary comparison didn't see any differences.

I will experiment with "checkout as-is, commit as-is" to confirm this.

But in general, I think you are right: since these VS-generated files are Windows-only, then they should have CRLF line endings in the git repo (as others may checkout with just the "as-is" setting... although I'm sure VS will be able to cope with all types of line endings).

[sicklittlemonkey]

It can be configured per repository, which then overrides the user settings. https://help.github.com/articles/dealing-with-line-endings/#platform-all ​ Cheers, Nick.

[tomcw]

OK, I've now added a .gitattributes files to the AppleWin:master repo, here c8dc857.

This means that even though the VS files (eg. .sln, vcxproj etc) are stored in GitHub with a LF ending, they will be converted to CRLF on a checkout to your local PC (regardless of OS).

@kiyolee: can you check this on your system?

Assuming this works as expected then I don't see any need to replace the GitHub (remote) copies of these files with CRLF line-endings.

[rzumer]

Probably needs a rebase at this point, but I think it is a worthwhile change. Is there any use in VS project files being stored with UNIX-style line endings? I don't think so. While most configurations will obey the .gitattributes file and translate on check-out accordingly, this does not apply to someone downloading a source archive, for example.

[tomcw]

@rzumer - I year ago I tried with .gitattributes and then backed it out. See #487. At the time I concluded it wasn't really a worthwhile change, since none of the active developers had any issue with the current setup.

I'm not familiar with rebasing, so can you give clear steps as to how to achieve this?

[rzumer]

Since it affects every file, it might be simpler to do it on master and force push on this branch (by default maintainers have the ability to push to PR branches).

Actually, based on my experience with this, I think the reason why you had problems with the .gitattributes file is that the files that should use Windows-style line endings need to be committed as such. Otherwise, by default git tries to follow the rules in .gitattributes and perform the conversion over the files in the repository that are committed with UNIX-style line endings, which is why they appear as modified on a fresh check-out. Both are needed to ensure compatibility across different local git configurations.