Some Tinkering with Visual Studio 2017

[Connery]

Spoiler:

So, this thread is mostly a publication of my progress on maybe getting the 3.5 files to run with VS 2017, if that's even possible.
I'll describe what I did in here and edit or post new stuff when I find the time, so if somebody else wanted to do the same, they would have some pointers :)

Do keep in mind that I got some experience in C++ but im nowhere near profiency or near the knowledge I got in, say, Java for instance (regarding IDE and language stuff). I program fluently in named language and Python, but I also have a good amount of experience with programming in ANSI-C (µC programming) so C/C++ isn't new and also not unfamiliar to me :)

Insights I gained on the way:

Spoiler:

• 4Story is a DirectX application which makes use of the Microsoft MFC and ATL libraries. From this it follows that in case we wanted to compile the application with VS, we'd need both these libraries.
  
  A guide on how to install them for VS 2017 can be found here.
  
  In case you do not know how to find your VS launcher: Simply look for "Visual Studio Installer" in your installed applications and execute it. It will open the launcher which enables you to add and remove sdks etc. for VS 2017.
• 4Story was written in VC 7.1 and is not source compatible with a functionally identical version of itself when compared to VC 14/17.
• 4Story's sound and music relies on Direct Music, which was deprecated by Microsoft some time ago. A possible Replacement for that is XAudio2.

Note: I'm under heavy load with real-life stuff right now so this project is currently paused (03.07.18)
Update #8:

So, I had a few days off and took care of some things 8also working on some C/CPP projects to sharpen my understanding).

The main issue we are facing right now is that we are getting header errors, which are caused by an older version of SAL.

I recently dived into the topic regarding compiling D3D9 sources under Win7 and stumbled upon this:

DX9 has pre-compiled libs that use an older runtime than VS2012 - you will get linker errors, and a couple of header compiler mismatches.

This looks rather promising, ill continue looking into that particular topic for now.


Current progress:

So, the main issue seems to be that the provided D3D SDK does not go well with the current gen windows SDK. FC what do?

Well, now how about this: If we managed to find a D3D SDK which still includes DirectMusic (support for that has been deprecated a few years ago) and is compatible with current gen windows SDKs, we should be good to go.

-> Well, this will not work out. I cannot find a singl download of the 9b SDK, which means that this path is a dead end.
Instead, I had the following idea come to my mind: Why are there d3d10 headers in the provided DX includes? I do not think that Dx10 was released back when the 9b SDK came out (2006), so the SDK we are given is, in fact and to no suprise, a self-assembled hybrid.

So, if this is in fact a customized SDK, it has to be possible to use the older sources with the newer ones, as in that the newer sources support the older ones.

So, what about this: Since dmusic was deprecated, we could extract the corresponding files and only include them, but not the rest of the SDK.
Since the newer SDKs already include the DX SDK, we'd effectively end up with a custom SDK.
_______________________________________________

Updates:

Spoiler:

Update #7:

Spoiler:

So, I had a good 7hrs of sleep and I'm still working on this. Because I resolved all the for-loop int declarations, I ran out of pointers and now started pondering on what makes me stuck rn.

So, let's have a look at the first few error messages:

1>------ Build started: Project: Engine Lib, Configuration: Debug Win32 ------
1>D3DCamera.cpp
1>includes\dx\include\codeanalysis\sourceannotations.h(78): warning C4467: usage of ATL attributes is deprecated
1>windows kits\10\include\10.0.10240.0\ucrt\corecrt.h(457): error C2059: syntax error: 'constant'
1>windows kits\10\include\10.0.10240.0\ucrt\corecrt.h(457): error C2144: syntax error: 'int' should be preceded by ';'
1>windows kits\10\include\10.0.10240.0\ucrt\corecrt.h(457): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

(...) 

So, during compilation, the compiler spotted something it cannot understand and this is "constant". If we have a look into the coresponding header file (corecrt.h), we see that the line in which the rror occurs looks like this:

_Field_range_(1, 2) int _locale_mb_cur_max; 

The next error is targeting the "int" element, so we can assume that the result of the macro

_Field_range_(1, 2) 

was

"constant" 

.

The question now is: Why does this macro insert "constant" in this location? I had a further look at the macro and dived deeper into the SDK, What I found out was that this macro is part of SAL, the

Microsoft source-code annotation language. Simply stated, SAL is an inexpensive way to let the compiler check your code for you."

So, this makes things more interesting now. The moment we depend on afx, things go downhill - but why? Well, afx is tightly tied to the windows sdk and thus the newer code is included.

This newer code, as we have seen, now integrates SAL and now the question is: Could it be that SAL is not enabled per default and this is the reason why we cannot compile?
Was SAL even present back then?

The latter is not the case because when trying to include sal.h , I got a result located within the DX SDK.

But maybe this is the reason why: We have two sources for a sal.h header and perhaps the version of the SDK is newer and supports annotations which were simply not present back when the DX SDK was released.

What I imagine to be happening is the following:

• The DX SDK includes its sal.h, which presumably has an include guard in place
• The win SDK includes its sal.h, but because the include guard is probably the same, no additions are made, but named additions are crucial for later compilations

And indeed, on line 15 of the sal.h file, there's a

#pragma once 

which tells the compiler to include this header just one time.

A simple line count compairson also showed the expected result: The version located in the DX folder had a line count of 1998​ whilst the one located in the MSVC 14 directory has 2972 . This is great!

Now we can make assumptions based on this:

• The reason why the errors show up in the source files of the sdk is that the sal.h file may only be included once and the included one (from the DX SDK) is older than the sal.h file with which the win sdk was built.
• In order to fix this issue, we have to somehow use the newer sal.h file without breaking the DX SDK.
  
  • We have to differenciate between two possible cases now:
    
    1. The newer sal.h file is backward compatible and replacing it in the DX sdk will not cause any troubles
    2. The newer sal.h file is not backward compatible
    
    
  • If the 1st one applies, we are potentially done with this error
  • If it is not the case, we have to take a look at what exactly changed and whether or not it is possible to let the DX SDk compile with its own sal.h file whilst the win sdk runs with its newer version of the file

Obviously, the latter option would be the best because it would not create any unexpected side effects.

I'll see what I'll do, although the 1st option is definitely what I'm going to try first.

Update #6:

Spoiler:

Spoiler:

I made a breakthrough and successfully compiled the first project of the solution. I fixed the faulty for loops in the TCML project and voila:

Spoiler:

1>------ Build started: Project: TCML, Configuration: Debug Win32 ------
1>cinterf.cpp
1>_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
1>cinterf.cpp(247): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>string.h(119): note: see declaration of 'strcpy'
1>cinterf.cpp(284): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>string.h(119): note: see declaration of 'strcpy'
1>cinterf.cpp(408): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>string.h(119): note: see declaration of 'strcpy'
1>cinterf.cpp(409): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>string.h(119): note: see declaration of 'strcpy'
1>TCMLParser.cpp
1>_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
1>tcmlparser.cpp(43): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>stdio.h(205): note: see declaration of 'fopen'
1>tcmlparser.cpp(133): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>stdio.h(205): note: see declaration of 'fopen'
1>Generating Code...
1>Microsoft.CppBuild.targets(1386,5): warning MSB8012: TargetPath(TCML.lib) does not match the Library's OutputFile property value (TCMLd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>Microsoft.CppBuild.targets(1388,5): warning MSB8012: TargetName(TCML) does not match the Library's OutputFile property value (TCMLd). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>TCML.vcxproj -> TCML.lib1>Done building project "TCML.vcxproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

Update #5.1:

Spoiler:

As expected, the sources do conatin errors, which I will be fixing now. This is gonna be a long night ...

Mini update: Only 909 errors and 238 warnings to go! When I started, I had over 1k errors :)

_______________________________________________
Update #5:

Spoiler:

I can barely keep my eyes open from the lack of sleep but one last thing went through my head before I actually wanted to call it for the day:

If the Hello World projects compile perfectly and the Engine Lib does not, how can I exclude the project configuration from being the culprit?

So far, we have gotten to know that the source of the project and the currently used toolset of VS 2017 are a priori incompatible.
We do know that the EngineLib is part of the sources and thus potentially could contain code which is not readable for our toolset. So, in order to prove that it is the includes, and not the configuration of the EngineLib project, we'd have to create a somewhat identical project and see whether we could synthetize an identical error message by only including the files the EngineLib does.

The error messages when compiling the EngineLib were the following:

Spoiler:

1>------ Build started: Project: Engine Lib, Configuration: Debug Win32 ------

1>D3DCamera.cpp

1>\windows kits\8.1\include\um\objidlbase.h(6174): error C2061: syntax error: identifier '__RPC__out_xcount_part'

1>\windows kits\8.1\include\um\objidlbase.h(6178): error C2061: syntax error: identifier '__RPC__in_xcount_full'

1>\windows kits\8.1\include\um\objidlbase.h(6382): error C2061: syntax error: identifier '__RPC__out_xcount_part'

(...) 

The error messages I received when compiling Hello World Library now were these:

Spoiler:

1>------ Build started: Project: Hello World Library, Configuration: Debug x64 ------

1>stdafx.cpp

1>windows kits\10\include\10.0.17134.0\um\objidlbase.h(6183): error C2061: syntax error: identifier '__RPC__out_xcount_part'

1>windows kits\10\include\10.0.17134.0\um\objidlbase.h(6187): error C2061: syntax error: identifier '__RPC__in_xcount_full'

1>windows kits\10\include\10.0.17134.0\um\objidlbase.h(6391): error C2061: syntax error: identifier '__RPC__out_xcount_part'
(...) 

As we can see, the error messages match up perfectly and this gives us a strong pointer towards the includes.

there are a few things I consider doing now:

• Have a look at the includes in the header file and exlude them one by one until I can find sth that causes the error messages
  
  • After I found that: Run the file through a syntax check and see whether it is in need of changes
  • In case it is in need of changes, refactor the file and see whether it is still the source of the issue

The only problem I see with this is that the errors are not thrown in the included sources but in the windows SDK. This is unfortunate but I think that it should be possible to track the culprit down regardless.

_______________________________________________


Update #4:

Spoiler:

So, apparently I overlooked a major hint in the epvpers thread I linked in Update #1:

I've converted the Server and Client code about an year ago from VC7.1 to VC14

This is most likely the reason why we can not compile the 3.5 VS 2003 sources in VS 2017: The sources are written in VC 7.1 and we are using VC 14 or even 17.

One might wonder now: But wait, C++ is downward compatible - why should we not be able to compile VC 7.1 code with a VC 14 compiler?

Well: VC is a Microsoft variant of C++. it is not a direct superset of C++ because it modifies the standard and implements it in its own way.

Moreso, C++ itself is backwards or downwards compatible but the VC++ code is not.

In fact, if I can trust this comment, there are not really any compilers which are exactly implementing the standard.

So, what exactly is now causing the issues with the WinSDK? Well, I do not really have any ideas because the target toolset of the project is already VC 17 and the WinSDK is causing currently inexplainable troubles for us.

I will investigate this further within the next update.

_______________________________________________


Update #3.1:

Spoiler:

I successfully created and compiled a HelloWorld application. Here are the outputs for the project being a

• CLI
• MFC
  
  and
• Desktop Application

respectively:

CLI

Spoiler:

1>------ Build started: Project: Hello World, Configuration: Debug Win32 ------
1>stdafx.cpp
1>Hello World.cpp
1>Hello World.vcxproj -> Hello World.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

MFC

Spoiler:

1>------ Build started: Project: Hello World MFC, Configuration: Debug Win32 ------
1>stdafx.cpp
1>ChildFrm.cpp
1>ClassView.cpp
1>FileView.cpp
1>Hello World MFC.cpp
1>Hello World MFCDoc.cpp
1>Hello World MFCView.cpp
1>MainFrm.cpp
1>OutputWnd.cpp
1>PropertiesWnd.cpp
1>ViewTree.cpp
1>Generating Code...
1>Hello World MFC.vcxproj -> Hello World MFC.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

Desktop

Spoiler:

1>------ Build started: Project: Hello World Desktop, Configuration: Debug Win32 ------
1>stdafx.cpp
1>Hello World Desktop.cpp
1>Hello World Desktop.vcxproj -> Hello World Desktop.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== 

From this we can deduce that the installed WinSDK is not faulty.

=> This, in return, means, that we have to take a closer look at what the compiler does not like when we include the SDK and then see what the possible causes could be. I do have a good hunch that we'll be diving into the C++ ecosystem of compilers and the standard of the language itself pretty soon.

_______________________________________________

Update #3:

Spoiler:

I temporarily discontinued the approach with Daffodil because the project is no longer active and I instead thought about the following: What would happen if I removed the windows sdk and vc includes? I could not spot any comparable includes in the project properties in VS 2003 so I went ahead and edited them in VS 2017.

The procedure was the following:

• Right click on EngineLib
• Click on "Prperties"
• Select VC++ Directories
• Click on "Include Directories" on the right
• Click on dropdown button
• Click on "<edit>"
• Remove check from checkbox "Inherit from parent or project defaults"
• Click OK
• Click apply
• Click OK

I then built the project and the result was that the compiler could not find "afx.h".
The file "afx.h" is part of the MFC library, so I wondered from where I could include this. I found the answer pretty quickly and went ahead to just see that I already installed the x86 and x64 libs for ATL and MFC already.
This is where I noticed, though, that the inherited options of the included files are

• $(VC_IncludePath);
  
  and
• $(WindowsSDK_IncludePath);

I had a good hunch that I maybe only needed to exclude the WINSDK include in order to get it running and was not disappointed with the next error message:

afxv_w32.h(25): fatal error C1083: Cannot open include file: 'winsdkver.h': No such file or directory 

This means that MFC and ATL itself include some things from the Windows SDK so in order to get things running, we need to focus on getting our code to compile with it.

From here we can make two assumptions:

1. The SDK is faulty
2. The Project/Solution configuration uses a C++ standard which is too old so the "newer" files are basically aliens for the compiler

The solution to 1. would be simply creating a test project in the solution (aka Hello World) and see whether it throws any errors.

The solution to 2. would be creating a project from scratch up and then porting the several project files over, which would presumably consume a lot of time.

I will stick to the 1st solution now though and then see what I can do with the project file, do some research etc.

_______________________________________________

Update #2:

Spoiler:

I have successfully compiled the 3.5 sources with VS 2003, this means that from here on I can start with the transition to VS 2017

My procedure from here on was the following:

- copy the VS 2003 filed over into my newly created vs 2017 directory
- open th TClient.sln file via the aforementioned method
- try to compile EngineLib

The result was exactly the one I expected: The compiler included the win 8.1 sdk and threw a lot of errors because it could not parse the SDK source files (for whatever reason).

We can now exclude that a misconfiguration of the project files is the most likely cause because in VS 2003, it worked.

Now it is about finding out whether and how Daffodil changes the circumstances.

_______________________________________________

Update #1:

Spoiler:

Someone has been able to upgrade the files to run sucdessfully with VS2013 and another one even to VS2015.

They give some more pointers and mention that mostly the development of C++ as a language itself is a cause

not that big deal if you know what happened in c++ language updates throughout the years

so it seems like this will be my next pointer to look over after I had a look at NTTD :

For any kind where you wish to use older C++ Code within NEW IDE's like 2015 or probably future versions, checkout the "Native Targeting Toolset Daffodil" it should be hosted on codeplex and it really solves up issues where you CANNOT upgrade the Code! Just wanted to drop that one out :P

_______________________________________________

Original post:

Spoiler:

So, as far as I could investigate, the common habit is to compile and alter the 3Story sources in Visual Studio 2003, however I wondered why it has to be exactly 2003 and not, for instance, 2017.

The reason why I'd like to use 2017 is, next to a better and more refined UI and dark template, is also the ability to ask for support on the MSDN forums in case I had questions regarding the handling and usage of the IDE and its functions.

To recap, what I was planning to do was building the application for windows 7. This meant that I needed a suitable SDK, but the SDK of win 8.1 is luckily downwards compatible to win 7 so I did not need (and actually could not) install the dedicated Windows 7 SDK from Microsoft.

I went ahead and installed the most recent VS 2017 Community build, imported the TProject solution file and so far it seemed to be working.

The procedure for this was the following:

• right clicked the .sln file and removed the write protection
• opened it in Visual Studio, klicked "ok" when it told me that it was about to perform a oneway-upgrade on the project files
• accepted the project despite of unknown origin
• selected the temporary option when it told me that the version control plugin linked in the solution is either not active or installed

To test whether it was working as expected, I added the includes for the DX directory and tried to build the TEngine project, which resulted in a hilarious amount (500+) of miss-parsed lines .

I assumed that, because I fiddled around with the project for some hours, I somehow fu-bar'd the settings as a whole and thus restored the project. I redid every single step I mentioned before and only added the missing includes to the project, in this case Engine Lib, just to be greeted again with the wall of text I saw before.

My suspicion now is that, since the std library is confirmed to be working, some of the configuration options either went missing during the oneway-upgrading process or the parsing of the sources is not done correctly.

The resons I think of which could be the culprit are

• different C++ standard
• specific compiler settings/arguments

However, GigaToni seems to have been able to get the 3.5 files to compile in VS 2005, so he might be able to give pointers.

But:

• There could also be the chance that some stuff is causing issues on my end, meaning that I'll build a test solution and see how it goes.
• I'll also install VS 2003 and see whether that works, too.

More information/entries when I got the time to continue :)Simply stated, SAL is an inexpensive way to let the compiler check your code for you.

[MentaL]

[TenseiV]

Good luck in this !

[pipitt05000]

Hey bro ! Watch 4Ever project, the project is on VS2017 on latest Win. 10 Kit !

You can try some things from this point :D