The International Simutrans Forum

Development => Patches & Projects => Incorporated Patches and Solved Bug Reports => Topic started by: DrSuperGood on July 15, 2019, 05:09:22 AM

Title: Re: New Visual Studio Solutions and Projects
Post by: DrSuperGood on July 15, 2019, 05:09:22 AM
Debug builds of the dependency libraries are not really required as we are developing Simutrans and not the dependencies. The only time they would be useful is when running into bugs in those libraries, in which case they can be built as required if one cannot report the bug to the library maintainers.

In most cases it is perfectly fine if stack frames around those libraries are missing during debugging.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on July 15, 2019, 05:49:48 AM
If a library exposes the C runtime it uses, mixing debug and release can cause problems. For what I remember about zlib, bzip2 and libpng, they do not do so. I am not sure about freetype, pthread, and especially miniupnpc. With both a debug and non-debug C runtime at work, you probably get a less efficient memory usage, with multiple heaps. The same also happens whenever dependencies are compiled with another compiler or version of MSVC, though. At least until UCRT usage really gets universal.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: prissi on July 15, 2019, 02:19:14 PM
Sounds nice, but are you sure that this works on MSVC Express? Because that are the only free versions Microsoft released. With my installation I get
Quoteerror MSB8020: The builds tools for v142 (Platform Toolset = 'v142') cannot be found. To build using the v142 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Install v142 to build using the v142 build tools.   C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets   44   5   Simutrans GDI

Which means, please install compiler, linker, ... from MSVC 2019. This is not so cross release (and I would have been really surprised, if this would have worked.) However, since I am the last user of MSVC 2012, I seen no problem to update to something still supported. Oh, I checked, MSVC 2012 is the still supported, until 2023. Hmm, but  if it helps, we can certainly go to something which still starts on Windows 7. I think this is true for MSVC 2017?
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: DrSuperGood on July 15, 2019, 05:52:55 PM
Quote from: prissi on July 15, 2019, 02:19:14 PMSounds nice, but are you sure that this works on MSVC Express? Because that are the only free versions Microsoft released. With my installation I get
As far as I am aware express was deprecated by community. Community is also completely free for non commercial use, which is what Simutrans counts as. It is even free for some sorts of commercial use (turn over less than $100,000), but anything large scale will need a licence.

Since community is free there is no reason for people to be using a version less than 2019 to work on Simutrans. Only reason I still use 2017 is because last I checked (a few months ago) 2019 was still in pre-release.

If your 2012 has a commercial licence then nothing stops you installing 2019 Community as well since they will operate independently from each other. That way you can keep using 2012 for work while using 2019 for Simutrans or other open source (non-commercial) work.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on July 15, 2019, 07:39:18 PM
There is no 2019 Express. The page called "Visual Studio Express" simply gives you the community edition. And as far as I understand it, you can use the community edition for commercial projects, as long as they are open source. The terms Microsoft uses is enterprise/non-enterprise, not commercial/non-commercial, possibly because the latter may not seem to cover use in the government.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 15, 2019, 09:23:43 PM
Community is free for (a) open-source, (b) academic research, (c) training, (d) commercial projects with single developer or (e) up to 5 users on non-enterprise. With enterprise being anything over 250 PCs or U$ 1 million annual revenue. [1] (https://visualstudio.microsoft.com/vs/community/)

Quote from: prissi on July 15, 2019, 02:19:14 PM
Sounds nice, but are you sure that this works on MSVC Express?
I'm not, that's why I'm asking for feedback here.

Quote from: prissi on July 15, 2019, 02:19:14 PM
error MSB8020: The builds tools for v142 (Platform Toolset = 'v142') cannot be found.
To build using the v142 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...".
Install v142 to build using the v142 build tools.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets   44   5   Simutrans GDI

That's actually a little expected, I thought that VS2012 to VS2015 would be smart as VS2017 and VS2019 and ask if you just want to convert that to the tools you have (it kinds of, as the message offer right-click the project to change that), but it's very easy to just put a lower version. Still I've managed to find an undocumented way that uses the default installed version by default. Please re-download the zip.

Microsoft needs to improve the weak CLI interface and crap version compatibility with Visual Studio.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 16, 2019, 02:45:13 AM
After a lot of research this page (https://marketplace.visualstudio.com/items?itemName=KieranMockfordMSFT.SharedProjectReferenceManager) points that the shared project feature I used is available since VS2013 Update 2. So no VS2012 support.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: prissi on July 17, 2019, 03:11:09 AM
It does work for my 2012. However, I see a new warning appearing:
warning C4373: 'dialog_list_convoi_t::exit': Virtuelle Funktion überschreibt 'tool_t::exit'. Vorherige Compilerversionen werden nicht überschrieben, wenn sich die Parameter nur durch const/volatile-Qualifizierer unterscheiden.
Ok, it is German, it says: Previous Compilerversion would not have overwritte this virtual function, since there is a different const/colatile qualifier. (Despite they did ...)

I have one project saying "simutrans.main, needs migration" which is grayed out though.

So it surely can go in. Thank you.

And since I have the olf static minupnp.lib, I will keep releasing with it.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: prissi on July 17, 2019, 03:24:26 AM
Another thing: I cannot use the avbove libaries, since they are compiled with newer runtimes:
Fehler 40 error LNK2001: Nicht aufgelöstes externes Symbol "___acrt_iob_func". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(bzlib.obj) Simutrans GDI
Fehler 41 error LNK2001: Nicht aufgelöstes externes Symbol "___acrt_iob_func". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(compress.obj) Simutrans GDI
Fehler 42 error LNK2001: Nicht aufgelöstes externes Symbol "___acrt_iob_func". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(blocksort.obj) Simutrans GDI
Fehler 44 error LNK2001: Nicht aufgelöstes externes Symbol "___stdio_common_vfprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(bzlib.obj) Simutrans GDI
Fehler 45 error LNK2001: Nicht aufgelöstes externes Symbol "___stdio_common_vfprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(compress.obj) Simutrans GDI
Fehler 46 error LNK2001: Nicht aufgelöstes externes Symbol "___stdio_common_vfprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(blocksort.obj) Simutrans GDI
Fehler 37 error LNK2001: Nicht aufgelöstes externes Symbol "___stdio_common_vsprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\zlibstat.lib(gzwrite.obj) Simutrans GDI
Fehler 38 error LNK2001: Nicht aufgelöstes externes Symbol "___stdio_common_vsprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\freetype.lib(bdf.obj) Simutrans GDI
Fehler 1 error LNK2005: _sprintf ist bereits in freetype.lib(bdf.obj) definiert. C:\msys32\home\markus\simutrans\simutrans\trunk\LIBCMTD.lib(sprintf.obj) Simutrans GDI
Fehler 39 error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "___acrt_iob_func" in Funktion "_BZ2_decompress". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(decompress.obj) Simutrans GDI
Fehler 43 error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "___stdio_common_vfprintf" in Funktion "_fprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\libbz2.lib(decompress.obj) Simutrans GDI
Fehler 36 error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "___stdio_common_vsprintf" in Funktion "_snprintf". C:\msys32\home\markus\simutrans\simutrans\trunk\zlibstat.lib(gzlib.obj) Simutrans GDI


So I will continue to use the old ones ...
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on July 17, 2019, 04:56:58 AM
Quote from: prissi on July 17, 2019, 03:11:09 AMI see a new warning appearing:
Code: [Select]
warning C4373: 'dialog_list_convoi_t::exit': Virtuelle Funktion überschreibt 'tool_t::exit'. Vorherige Compilerversionen werden nicht überschrieben, wenn sich die Parameter nur durch const/volatile-Qualifizierer unterscheiden.
Ok, it is German, it says: Previous Compilerversion would not have overwritte this virtual function, since there is a different const/colatile qualifier. (Despite they did ...)
The English text for that warning is "previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers". I think "only" ("nur") is important here. According to the documentation, by "previous version of the compiler", it means Microsoft Visual Studio 2005 and earlier. I assume this warning is also generated for a couple of other exit implementations in that file as well.

Although the warning means that the current compiler is doing its job correctly, there isn't really much point in having the const qualifier on the parameter in these cases. The functions are very short, so little risk of the parameter being accidentally reassigned.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 17, 2019, 05:22:42 AM
Quote from: prissi on July 17, 2019, 03:11:09 AM
It does work for my 2012.
That's amazing, and unexpected.

Quote from: prissi on July 17, 2019, 03:11:09 AM
I have one project saying "simutrans.main, needs migration" which is grayed out though.
That's the feature that was only introduced with VS2013u2, it's interesting that VS2012 managed to at least use it.

Quote from: prissi on July 17, 2019, 03:11:09 AM
However, I see a new warning appearing:
[...] it says: Previous Compilerversion would not have overwritte this virtual function, since there is a different const/colatile qualifier. (Despite they did ...)
Actually they don't, dialog_list_convoi_t::exit has a parameter player_t* const while tool_t::exit doesn't have a const in the parameter.
Anyway, this is just a VS warning about compiling with VS2005 or older that did not follow the C++ standard.
I've probably lost the setting that suppressed this warning when moving stuff around.

Quote from: Ters on July 17, 2019, 04:56:58 AM
Although the warning means that the current compiler is doing its job correctly, there isn't really much point in having the const qualifier on the parameter in these cases. The functions are very short, so little risk of the parameter being accidentally reassigned.
Or put const on everything ;D
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Dwachs on July 17, 2019, 06:53:11 AM
Also const qualifier on pointers is pointless, as these are passed value.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on July 17, 2019, 02:43:25 PM
Quote from: Dwachs on July 17, 2019, 06:53:11 AM
Also const qualifier on pointers is pointless, as these are passed value.
It is not about the pointer as something coming from the outside, but the pointer internally. It prevents the pointer from being changed to point to something else during execution of the function. As such, it is just as useful for a plain int. Some might argue that a function where you can not see that parameters are being reassigned, are too complex and should be broken down into several.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: DrSuperGood on July 17, 2019, 05:33:27 PM
Quote from: Ters on July 17, 2019, 02:43:25 PMSome might argue that a function where you can not see that parameters are being reassigned, are too complex and should be broken down into several.
I agree as due to how optimizers work having constant parameters is recommended. This way the input parameter value is always available throughout the life of the function call. Any modifications to parameter values should be done as newly declared variables so as to be clear that the value is different from what were the parameters. The overhead from this is minimal and possibly entirely masked by the optimizer, especially for primitive types which do not have complex destructors.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on July 18, 2019, 05:57:49 AM
I see const for local variables (including parameters) more as communication between developers, or a safe-guard even against oneself. Compilers are clever enough to figure this out themselves. Even the Java compiler (source code to byte code) is clever enough to deduce that a variable is effectively constant (called final in Java), and it is supposedly quite stupid compared to C++ compilers, since the JIT-compiler (byte code to machine code during execution) is supposed to be the one doing optimizations. (The Java compiler needs to know this to enforce the rule that only effectively constant variables can be captured by lambdas and similar.)

Pointers-to-const (misleadingly often called const pointers), reference-to-const (const references), const globals and const members are something else. These do potentially tell the compiler something important, since these facts may span several compilation units.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 18, 2019, 02:51:21 PM
Got a VM and tested with all VS versions since 2010, here are the results:


Visual StudioOpen ProjectLibs Work
2019 CommunityFlawlessYes
2017 CommunityFlawlessYes
2015 CommunityFlawlessYes
2013 CommunityFlawlessNo
2012 ExpressConverts firstNo
2010 ExpressFailNot tested

The libraries working only after VS 2015 are expected as I've found this stackoverflow (https://stackoverflow.com/questions/32418766/c-unresolved-external-symbol-sprintf-and-sscanf-in-visual-studio-2015#32418900) and this MS page (https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019) pointing about it, basically ABI compatibility.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: prissi on July 21, 2019, 02:29:32 PM
SO now we have to state MSVC 2015 as minimum requirement. No problem though.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 22, 2019, 08:21:49 AM
2012 is the minimum, but you need to compile the libs yourself.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 24, 2019, 12:13:45 AM
I managed to get a static miniupnpc, the download link and the instructions on how to do it in the first post were updated to include it.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: ceeac on July 26, 2019, 08:03:14 AM
Found a bug: When building the entire solution, the GDI, SDL and Server projects are built in parallel and write to the same PDB:


fatal error C1041: cannot open program database 'C:\Users\ceeac\Desktop\simutrans\build\Debug\vc141.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on July 26, 2019, 04:48:30 PM
It was only the GDI and SDL2 that clashed, and since there are no advantages on doing so I've moved them to different folders. Now it will build the Debug, Release and Stable configurations inside a folder with the name of the backend. The executable will be placed directly inside the folder of the backend instead of the configuration to ease their retrieval, the names will be "Simutrans $(backend).exe" for stables, "Simutrans $(backend) Debug.exe" for debug builds and "Simutrans $(backend) Nightly.exe" for release.

Changes were committed on r8795.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: prissi on August 06, 2019, 01:54:41 AM
An important note is that when copying the above files in the lib folder of C++ (or what is the proper way to do this?), you need to copy the lib from the release folder, but the pthread~lib also from the debug folder (the version oith the d). Or else you cannot build debug version.

For me, in order to build the debug version, i had to add

<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>

instead just "MultiThreadedDebug"

EDIT:
Also one cannot open any C oder header files from Simutrans main, they all have the wrong path.

Moreover, Simutrans is not using exceptions, so maybe we should switch them off instead of ignoring them. But switching off will give lots of warnings, unless the following lines are included:

<PreprocessorDefinitions>USE_UPNP;...;WINVER=_WIN32_WINNT_WINXP;_HAS_EXCEPTIONS=0</PreprocessorDefinitions>

and

    <ClCompile>
      <ExceptionHandling>false</ExceptionHandling>
    </ClCompile>

in the respective compile flag section.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on August 12, 2019, 04:45:02 AM
I could not check that this weekend but I'll try during this week.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: An_dz on August 19, 2019, 04:09:24 AM
Checked the fixed, all look good. As for the exception we could disable them but I'm not sure if it's worth the trouble.
Title: Re: Re: New Visual Studio Solutions and Projects
Post by: Ters on August 19, 2019, 07:01:29 AM
Quote from: prissi on August 06, 2019, 01:54:41 AMMoreover, Simutrans is not using exceptions, so maybe we should switch them off instead of ignoring them.
As far as I can tell, _HAS_EXCEPTIONS enables/disables exceptions in Microsoft's STL. I have not been able to tell what it does without exceptions. Will out-of-bounds container access just return a default value? Will it actually access the out-of-bounds memory? Will it immediately call std::terminate, just like if the exception was ignored? Or maybe even call exit directly? Some pages suggest that it is an unsupported legacy feature, so the answer may not be defined. There are also other sources of exceptions.

The other option disables exception handling, which basically means ignoring exceptions. (The C++ runtime doesn't ignore them, though. If the program does, they end up there, which triggers a call to std::terminate.) Exception support with GCC and on 64-bit Windows has no (or negligible) runtime cost. I don't remember how the 32-bit Microsoft C++ compiler does it. It might be the same. On 64-bit Windows, exception support is part of the ABI, even for C programs. It is throwing exceptions that is expensive, relatively speaking.