News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Windows 10 and Visual Studio 2015

Started by jamespetts, July 28, 2015, 10:05:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

QuoteDoes any of this represent a problem for developing Simutrans on VS 2015 as a Win32 application?
No, it should still run like all Win32 applications do. If anything it becomes easier since you can raise the C++ standard closer to this decade (if desired). They also claim possible performance improvements just from a re-compile (since the compiler can optimize some code better) however if this will actually be the case is another question.

Ters

Quote from: DrSuperGood on August 12, 2015, 07:17:05 PM
If anything it becomes easier since you can raise the C++ standard closer to this decade (if desired).

Unless you switch it to either another C++ or another "standard". The former is unlikely within Simutrans development as long as it is possible to import the existing project, and the latter has been an issue since forever (with GCC no better in that regard).

Another thing to look out for when upgrading the compiler is what the target platform ends up as afterwards. Just in case you don't want to lose players that have an older processor than the new compiler finds "fashionable", like our old night build server did some time ago. (Can't find any such detailed settings in VS2015, though. But then again, I have no experience doing C++ in Visual Studio, just some basic C# proof-of-concepts. Maybe such settings are the domain of the professional editions.)

jamespetts

One relevant issue is whether VS2015 supports Windows XP - I remember that VS 2012 needed a special extra download and configuration to do
so.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteUnless you switch it to either another C++ or another "standard". The former is unlikely within Simutrans development as long as it is possible to import the existing project, and the latter has been an issue since forever (with GCC no better in that regard).
That is entirely up to the director. James is developing Simutrans Experimental some what in parallel to standard and as such is free to raise the C++ specification for parts unique to experimental if desired. On the other hand for convenience it might be good to keep compiler compatible with standard. All comes down to choices really.

The biggest change with MSVC 2015 C++ is that the compiler now supports C++11 pretty much fully (as well as older standards with some newer features as well). C++11 should also be fully supported by newer versions of GCC (might need some compiler flags to link in some of the features) which should be available on general Linux systems. I think the reason standard still uses an older C++ standard is for some legacy and obscure system support (which do not have recent GCC builds or poorly maintained C++ compilers).

QuoteOne relevant issue is whether VS2015 supports Windows XP - I remember that VS 2012 needed a special extra download and configuration to do
so.
I think this might answer the question. Looks pretty good from what that page shows.

jamespetts

Thank you for that link: that is helpful. I think that it might be better to maintain compiler compatibility with Standard if possible, although I do not place the same emphasis on targeting non-standard platforms as does Standard: I am generally happy if Experimental can be compiled on Windows (XP and above), Mac OS X (for Intel) and Linux (32- and 64-bit). I wonder whether some of the more obscure platforms still need to be targeted by Standard or whether they are now so obscure that nobody is realistically likely to use them any longer? That might help to standardise and modernise development if that were so.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: DrSuperGood on August 13, 2015, 01:23:13 AM
That is entirely up to the director. James is developing Simutrans Experimental some what in parallel to standard and as such is free to raise the C++ specification for parts unique to experimental if desired.

I wasn't writing about raising, I was writing about switching. Now it is of course up to him if I still wants to support other platforms or not, but it should be an intentional switch.

Quote from: DrSuperGood on August 13, 2015, 01:23:13 AM
C++11 should also be fully supported by newer versions of GCC (might need some compiler flags to link in some of the features) which should be available on general Linux systems.

But this is only one of the C++es, and not the one Microsoft is trying hard to push.

My other point is that while both may support the C++11 standard, they've both added something extra. This was a lament that even when writing algorithms with no ties to platform, those who use Microsoft's compiler and those who use GCC can end up writing code that doesn't work for the other. The fact that mingw decided to depend on an unsupported (from a developer standpoint) and outdated C runtime, makes it even worse. Although Microsoft's compiler and the Windows SDK is still free, it is now only available through Visual Studio, which isn't that great if you have a headless Linux box on which you want to test compile targetting multiple platforms to make sure you haven't written anything platform specific in the common code.

prissi

If one targets more than one platform (especially Mac might be different from Linux and Windows) then using the latest compiler tricks is most likely not a good idea. Also raising the standard only in one tiny corner might be rather a concept for more confusion.

Certainly reliable multithreading on high level would be nice; but that is just something where compilers differ most.

Generally, throughout my life I wrote code for about ten different targets; and the more compiler specific extension one tends to use the more likely one stumble across a compiler feature which did not perform as expected (or just a bug). (Offtopic, my favorite was a TI DSP where sizeof(char)=sizeof(char[4])=sizeof(short)=sizeof(short[2]) with char actually ten bits which breaks most array code which assume otherwise.) But normally simple straight forward code tend to work always (and if it is quite straight forward, the optimiser should also be able to do a good job). So in the end, if there is not a very specific problem that can gain a lot I would keep thing simple and compatible as possible.

Ters

After Haiku, I actually think the most unsure target to support is mingw. The original project is stuck somewhere near the turn of the millennium in terms of API support. (C and C++ standards support is more up to date, as far as a two decades old C runtime allows.) The new mingw64 is more up to date (except that they still use the same C runtime, I think), but there are concerns about it violating Microsoft's copyrights (though that would likely apply to Wine as well). And the project seems uncoordinated when it comes to delivering a complete, runnable environment for installation on Windows. (The development of the surrounding msys environment is probably fragmented even more, as a variant is also used by Git for Windows. Which, ironically, is used by Visual Studio's git support, from what I can understand. Furthermore, all of these are just forks of cygwin.)

But mingw is used for building nightlies. And also the official releases so far.

DrSuperGood

I think Experimental is pretty much self built ATM. The versions for Windows I got for playing on the server appear to be MSVC built. If the Windows API problem can be solved then making from a Linux server should not be an issue either. Both MSVC and GCC are pretty good with the C++ standard up to about C++11.

Simutrans is a pretty complicated piece of software. Experimental is more so as it generally has higher system requirements. The sort of systems that Simutrans Experimental is aimed at generally have pretty standards compliant C++ compilers.

Ters

Quote from: DrSuperGood on August 14, 2015, 12:09:56 AM
If the Windows API problem can be solved then making from a Linux server should not be an issue either. Both MSVC and GCC are pretty good with the C++ standard up to about C++11.

The key issue is that it looks like it won't, at least not in a way that everybody agrees is legal. And to what extent can newer C and C++ standards be implemented using a (possibly somewhat non-standard) C89 runtime?

jamespetts

Experimental is not built with MinGW at present, but Standard is. Can somebody give some sort of idea of what sort of code is legal in the C++ 11 standard that will not compile on MinGW? Will any of that stuff compile on VS 2015 but refuse to compile on VS 2012?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Here I tried to post a C++11 patch.


// Array implementation. Compile time constant so should inline well.
static city_growth_factors_t const CITY_GROWTH_FACTORS[GROWTH_FACTOR_NUMBER] {
{ HIST_PAS_GENERATED, HIST_PAS_TRANSPORTED, &settings_t::get_passenger_multiplier },
{ HIST_MAIL_GENERATED, HIST_MAIL_TRANSPORTED, &settings_t::get_mail_multiplier },
{ HIST_GOODS_NEEDED, HIST_GOODS_RECIEVED, &settings_t::get_goods_multiplier } };

And it was producing this for some...
QuoteVisual Studio 6.0 
'identifier' : illegal symbol in context
Quotesimcity.cc:86:76: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default]

QuoteWill any of that stuff compile on VS 2015 but refuse to compile on VS 2012?
The above did compile in VS 2012. Although it had poor c++11 support it had enough for that feature.

Ters

Quote from: jamespetts on August 14, 2015, 10:20:54 AM
Can somebody give some sort of idea of what sort of code is legal in the C++ 11 standard that will not compile on MinGW?

This isn't in C++11, it's from C11, but Visual Studio has supported this for some time as an extension to the standard. (Maybe it even was them that lobbied it into the C11 standard.)

char buf[BUF_SIZE];
strcpy_s(buf, "Hello", BUF_SIZE);


strcpy_s is the safer version of strcpy, and most functions in string.h has gotten such _s versions. Microsoft advocates that developers stop using the old functions, and rightly so, since these are probably the number one cause of all buffer overflow remote code execution exploits. (Although there are a few cases where just adding _s won't make your code any safer, because you still have to provide the correct inputs.)

It actually looks like even GCC on my Linux box doesn't support this.

DrSuperGood

#48
There are some minor compatibility problems with the pthread.h implementation and Windows SDK. I am trying to understand the specifics but it seems that Windows now does have "struct timespec" in "time.h". Since it is declared in the pthread.h header one can guess what happens.

Also I am getting this error...
Quotesized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function.
from lines like...

bild_besch_t* besch = new(4 * sizeof(PIXVAL)) bild_besch_t();

I am not sure what the line is meant to mean currently, I will need to look into it.

jamespetts

Is there not a pthread.h version that supports Windows 10?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteIs there not a pthread.h version that supports Windows 10?
Does not appear to be with the windows sdk. And the version of PThread used has not been updated for years.

I cannot test if it works or not until the other issue is resolved.

Ters

#51
Quote from: DrSuperGood on August 21, 2015, 05:07:42 AM
I am not sure what the line is meant to mean currently, I will need to look into it.

It is use of an overloaded new operator (provided in the Simutrans code somewhere) to allocate a chunk of memory larger than normal. This is an old C trick extended into C++. It lets bild_besch_t contain an array of arbitrary size, not point to one, which likely has been shown to be a performance issue in this case.

Although I don't really understand the quoted error. The wording doesn't even sound like an error.

Update:
Maybe it's trying to complain that there are no corresponding overloads for delete, although Simutrans never deletes besch instances anyway. Even if it did/does, the normal delete is just fine, so it should be a warning, not an error.

DrSuperGood

The solution does not appear that simple. What is happening I think is that it is saying that the allocation signature is not acceptable as it conflicts with the placement deallocation function. I am unsure if this is a bug (as the error has been shown in bug reports) or that the hackery being used is no longer supported.

Ters

Whether the exact trick is supported or not, new(...something...) (...possibly something...) is still part of the standard from what I could see in the documentation at cplusplus.com. Simutrans is not the only project depending on that feature. Maybe you found the answer to the original question: No it is quite the opposite of worthwhile to upgrade to Visual Studio 2015. At least until the possible bug is fixed.

jamespetts

We do need to know in the long-term whether there is a way of working with VS2015 or later. Simutrans has been around for 16 years, and I hope that it will be around for at least another 16.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

#55
This has nothing to do with MSVC 2015. It is a C++14 compatibility issue.

QuoteA declaration of a placement deallocation function matches the declaration of a placement allocation function if it has the same number of parameters and, after parameter transformations (8.3.5), all parameter types except the first are identical. Any non-placement deallocation function matches a non-placement allocation function. If the lookup finds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called. If the lookup finds the two-parameter form of a usual deallocation function (3.7.4.2) and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed. For a non-placement allocation function, the normal deallocation function lookup is used to find the matching deallocation function (5.3.5) [Example:
struct S {
  // Placement allocation function:
  static void* operator new(std::size_t, std::size_t);
  // Usual (non-placement) deallocation function:
  static void operator delete(void*, std::size_t);
};

S* p = new (0) S; // ill-formed: non-placement deallocation function matches
                  // placement allocation function


—end example]
The above is exactly what is happening at the moment. The "Usual (non-placement) deallocation function" for sized de-allocation is being inherited and matching the "placement allocation function".

Microsoft clearly explains it here...

Currently looking into solution.

Temporary solution...
Quote
If you don't want to update your code immediately, you can revert to the old behavior by using the compiler option /Zc:sizedDealloc-. If you use this option, the two-argument delete functions don't exist and won't cause a conflict with your placement delete operator.

Now just need to rebuild all the dependent libraries...

Ters

That description was not easy to get my head around. If I understand it right, C++14 introduced new signatures for operator delete that has the same signature as the corresponding old-style operator delete would for obj_besch_t's overloaded operator new. I would say this is a standard quite explicitly breaking backwards compatibility. They could have avoided that by adding new parameters at the beginning, not at the end where developers were given permission to do as they please.

jamespetts

Quote from: DrSuperGood on August 21, 2015, 11:58:39 PM
This has nothing to do with MSVC 2015. It is a C++14 compatibility issue.
...
Temporary solution...
Now just need to rebuild all the dependent libraries...

Does this mean (1) that it is necessary to use a special compiler switch when using MSVS 2015; (2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015; and/or (3) that MSVS 2015 can only be used with the potentially problematic C++ 14 standard?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: jamespetts on August 22, 2015, 10:39:23 AM
(2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015

When using dynamically linked libraries (dlls), these must be compiled against the same C and C++ runtimes if these APIs are not fully abstracted away (and all libraries must agree on static or dynamic linking of common dependencies). Otherwise, all kinds of thing might happen when one C runtime is given something created by another C runtime. (Implosion of the universe is unlikely, but not ruled out by the standard.) Simutrans normally uses static linking only, except for the C/C++ runtime itself and whatever API the backend is based upon (GDI, SDL, etc.). This means that the nightlies (and others adhering to this rule) only need to provide the exe file, but makes it impossible for users to do a minor upgrade of zlib or bzip without building a new exe file themselves.

DrSuperGood

QuoteThat description was not easy to get my head around. If I understand it right, C++14 introduced new signatures for operator delete that has the same signature as the corresponding old-style operator delete would for obj_besch_t's overloaded operator new. I would say this is a standard quite explicitly breaking backwards compatibility. They could have avoided that by adding new parameters at the beginning, not at the end where developers were given permission to do as they please.
They introduced it for optimization purposes. The placement allocator/decallocator was kind of obsolete outside of some very specific purposes (microcontrollers) and the only people generally using it were for the hack used in Simutrans.

One should be able to remove the sized destructor from the class somehow (so It defaults to the unsized one, since they are meant to be functionally equivalent when called by the compiler) however I am unsure of how to do that currently.

The other solution is to take advantage of different parameter type constructor/destructors. Simply wrapping the extra memory size in a enum or class (as described by Microsoft in the above link) and using that type as the signature would work since it will not be using the placement constructor/destructor but instead will use an entirely different constructor/destructor. This solution may need C++14 as I am unsure if different argument constructor/destructor was supported before then.

QuoteDoes this mean (1) that it is necessary to use a special compiler switch when using MSVS 2015;
Yes, currently you need to use that compiler switch until the code is made more c++14 compliant.

Quote(2) that some or all libraries (some of which do not normally need to be built specially as binaries are available) for Simutrans will have to be rebuilt to use MSVS 2015;
This is entirely dependent how you have it setup. Libraries generally need to be rebuilt to take advantage of compiler optimizations as well as changes in C++ standards. I built all of them in the past, I just need to get around to building them all again in MSVC2015. This is so link time optimization can be used (which allows optimizations like in-lining to be applied to library calls). The dll files I would not imagine needing to be rebuilt.

I am still in the process of doing this.

Quoteand/or (3) that MSVS 2015 can only be used with the potentially problematic C++ 14 standard?
I think it forces you to use parts of C++14. However the problems are not so much with the C++14 standard but the hacky old code Simutrans uses. Supporting C++14 building is always a good idea since it makes the code more future proof.

QuoteSimutrans normally uses static linking only, except for the C/C++ runtime itself and whatever API the backend is based upon (GDI, SDL, etc.). This means that the nightlies (and others adhering to this rule) only need to provide the exe file, but makes it impossible for users to do a minor upgrade of zlib or bzip without building a new exe file themselves.
It also uses a PThread dll. Currently I am trying to re-build compatible versions of the other libraries (zlib etc).

jamespetts

Perhaps when you have got it all running you could upload a step by step guide to building Simutrans on MSVS 2015? That would be extremely useful.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
They introduced it for optimization purposes. The placement allocator/decallocator was kind of obsolete outside of some very specific purposes (microcontrollers) and the only people generally using it were for the hack used in Simutrans.
Most uses I have seen for it has been for tracing memory allocations in debug builds.

Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
One should be able to remove the sized destructor from the class somehow (so It defaults to the unsized one, since they are meant to be functionally equivalent when called by the compiler) however I am unsure of how to do that currently.
Sized destructor? You mean the delete operator taking a size_t parameter? That is part of the standard, and there is none in the class. It's the global default that is causing trouble I think. Removing this is probably what the compiler switch you mentioned does.

Quote from: DrSuperGood on August 22, 2015, 04:12:31 PM
The other solution is to take advantage of different parameter type constructor/destructors. Simply wrapping the extra memory size in a enum or class (as described by Microsoft in the above link) and using that type as the signature would work since it will not be using the placement constructor/destructor but instead will use an entirely different constructor/destructor. This solution may need C++14 as I am unsure if different argument constructor/destructor was supported before then.

I don't see what your solution will accomplish. Constructors have always taken arguments, destructors never have or will. But constructors are for initializing the class. The memory is allocated by operator new, so that what must be customized, but the new standard has suddenly (carelessly and needlessly in my opinion, they could have prepended the new parameter to avoid conflict) stolen a signature that earlier standards let the developers use as they wished.

DrSuperGood

#62
QuoteSized destructor? You mean the delete operator taking a size_t parameter?
Yes sorry, read my post with "allocator/deallocator" instead of "constructor/destructor".

QuoteThe memory is allocated by operator new, so that what must be customized, but the new standard has suddenly (carelessly and needlessly in my opinion, they could have prepended the new parameter to avoid conflict) stolen a signature that earlier standards let the developers use as they wished.
Looking at how the standards documentation was modified it looks like an oversight rather than purpose. Hence they extended placement constructors to support any argument type for the first argument other than "size_t".

QuotePerhaps when you have got it all running you could upload a step by step guide to building Simutrans on MSVS 2015? That would be extremely useful.
I have managed to get it running. Required me to rebuild both compression libraries but not pthread or FreeType.

I have attached a patch with fixes a typo in a previous patch of mine (could not test it at the time as I did not have Windows 8, I forgot a ';') as well as fixes the issue with PThread. This is the minimum changes required to build 32 bit with MSVC 2015 using the " /Zc:sizedDealloc-" compiler flag. A better work around for /Zc:sizedDealloc- is needed in the future (since the feature could potentially provide performance benefits). I have not tested 64 bit building yet.

Currently my Simutrans project configuration in MSVC 2015 is kind of a mess. I am working on tidying it up slowly. The problems I ran into was because I use self-compiled and optimized version of the compression libraries which it wanted updated, so I had to update them (again with rather messy project configurations, I am unsure of what the various compiler options do the libraries produced).

jamespetts

Thank you for that. I have applied the change to simthread.h, but I am a little confused about the changes to posix.cc, partly because this file is not, in fact, used in MSVS compilations, and partly because the state from which the patch was changing the file is very different to my version of that file. Has this been changed substantially in Standard lately? Mine looks like this:


/*
* Copyright (c) 1997 - 2001 Hansjörg Malthaner
*
* This file is part of the Simutrans project under the artistic license.
*/

#ifndef _MSC_VER
#include <unistd.h>
#include <sys/time.h>
#endif

#ifdef _WIN32
// windows.h defines min and max macros which we don't want
#define NOMINMAX 1
#include <windows.h>
#endif

#include "macros.h"
#include "simsys.h"


bool dr_os_init(const int*)
{
// prepare for next event
sys_event.type = SIM_NOEVENT;
sys_event.code = 0;
return true;
}

resolution dr_query_screen_resolution()
{
resolution const res = { 0, 0 };
return res;
}

// open the window
int dr_os_open(int, int, int)
{
return 1;
}


void dr_os_close()
{
}

// reiszes screen
int dr_textur_resize(unsigned short** const textur, int, int)
{
*textur = NULL;
return 1;
}


unsigned short *dr_textur_init()
{
return NULL;
}

unsigned int get_system_color(unsigned int, unsigned int, unsigned int)
{
return 1;
}

void dr_prepare_flush()
{
}

void dr_flush()
{
}

void dr_textur(int, int, int, int)
{
}

void move_pointer(int, int)
{
}

void set_pointer(int)
{
}

int dr_screenshot(const char *,int,int,int,int)
{
return -1;
}

static inline unsigned int ModifierKeys()
{
return 0;
}

void GetEvents()
{
}

void GetEventsNoWait()
{
}

void show_pointer(int)
{
}

void ex_ord_update_mx_my()
{
}

static timeval first;

unsigned long dr_time()
{
timeval second;
gettimeofday(&second,NULL);
if (first.tv_usec > second.tv_usec) {
// since those are often unsigned
second.tv_usec += 1000000;
second.tv_sec--;
}
return (unsigned long)(second.tv_sec - first.tv_sec)*1000ul + (unsigned long)(unsigned long)(second.tv_usec - first.tv_usec)/1000ul;
}

void dr_sleep(uint32 msec)
{
/*
// this would be 100% POSIX but is usually not very accurate ...
if(  msec>0  ) {
struct timeval tv;
tv.sec = 0;
tv.usec = msec*1000;
select(0, 0, 0, 0, &tv);
}
*/
#ifdef _WIN32
Sleep( msec );
#else
sleep( msec );
#endif
}


int main(int argc, char **argv)
{
gettimeofday(&first,NULL);
return sysmain(argc, argv);
}
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: jamespetts on August 23, 2015, 10:04:27 AM
I am a little confused about the changes to posix.cc, partly because this file is not, in fact, used in MSVS compilations

Probably because whoever made it didn't use Visual Studio. Despite the name, posix.cc is for Windows as well.

jamespetts

That's very odd: I don't include posix.cc in my MSVS compile, and it always works (for Experimental). What does this file do?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

Quote from: jamespetts on August 23, 2015, 11:44:07 AM
That's very odd: I don't include posix.cc in my MSVS compile, and it always works (for Experimental). What does this file do?

Well, it's simsys_posix.cc, and like the other simsys files, only one is necessary in a given build. It's basically the server "backend", so that Simutrans runs as a console/service process behaving like server processes traditionally do.

jamespetts

Ahh, I see - but I am fairly sure that the no graphics server compiled for Windows also does not use simsys_posix.cc. Perhaps it ought to use it?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

I wanted to try out JIT2 multiplayer properly so needed a no graphics server. I looked at the MAKE file for how it builds a no graphic server and applied that to MSVC (although in a rather hacky way, need to revise how I did that).

It was not building because of a variety of reasons. I supplied a patch which was incorporated to fix this. However recently I noticed that the Windows 8 and newer build of the file contains a syntax error (forgot ';') which is why that is tagged along because otherwise the POSIX server will fail to build targeting Windows 8 and newer.

QuoteAhh, I see - but I am fairly sure that the no graphics server compiled for Windows also does not use simsys_posix.cc.
I was not aware of any other way to get a no graphics server. In any case MSVC should be able to build a POSIX build for portability reasons.

Specifically this patch was the one I posted to fix POSIX build for MSVC.

jamespetts

All that I had done before was to use simgraph0.cc rather than simgraph16.cc. I presume that that is the patch that I have yet to apply.

Are you aware of any way (apart from #ifdef directives in the files themselves) to tell MSVS which files to try to build separately for each build configuration?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.