QuoteI have also noticed the posix issues with Windows builds of the command line server: the game will instantly quit when started, with no error message
It likely only effects Standard when building with MSVC. It seems MSVC POSIX link system does not support the windows only UTF-16 Unicode aware API, throwing link errors as the implementations cannot be found. This means my recent drive for Unicode awareness has broken the ability to build POSIX servers in MSVC.
When trying to build a simple windowless server from the other back ends apparently the graphics code tries to access mutexes it should not (no graphics so no mutexes) so causes a segmentation fault unless built single threaded. This might only apply to standard.
Quote from: DrSuperGood on December 10, 2017, 02:42:27 AM
When trying to build a simple windowless server from the other back ends apparently the graphics code tries to access mutexes it should not (no graphics so no mutexes) so causes a segmentation fault unless built single threaded. This might only apply to standard.
I cannot reproduce this for standard (compiling on linux, multithreaded server, no graphics - works).
QuoteI cannot reproduce this for standard (compiling on linux, multithreaded server, no graphics - works).
Try building a GDI backend windowless server for Windows. The windowless server usually uses the POSIX backend but that is no longer supported by MSVC as its POSIX link system is not aware of Windows Unicode support.
GDI and windowless make no sense. POSIX is the windowless (graphicless really) backend, and as a backend is mutually exclusive with GDI as a backend. Also, color depth 0 is only compatible with the POSIX backend.
MinGW still works for a Windows command line server.
I have split this topic from that relating to performance when connecting to Simutrans-Extended servers, as this is quite a separate issue. May I ask whether this should be moved to the bug reports subforum as being a Standard issue?
This can be moved to standard bugs.
One simply builds the POSIX back end as a Windows console application, not link it as POSIX application. Linking as a POSIX application does not work as the POSIX libraries do not support the Windows only Unicode API, something that is not made clear anywhere. I recently patched in a fix in allowing MSVC to build it, it was missing some macros and imports.
Thank you for this - I have now incorporated the fix into Extended.
However, I am still unable to get a working command line server build in Extended: any attempt to build a command line server executable (simgraph9.cc included, simgraph16.cc excluded; simsys_posix.cc included, simsys_w.cc excluded) results in an executable that will quit instantly with no error on being started: it prints no messages to the command line, and does not trigger the very first line of simu_main() in the debugger. I am afraid that this is beyond my understanding.
The ability to build a command line server executable in Windows will make it much easier for me to look into the problem relating to Extended load times on the servers.
MSVC has a POSIX build options that is different from a Windows console application? I wasn't aware that the Windows NT offered POSIX support except through various POSIX subsystems, the current one being the Ubuntu-thingy, which are quite distinct from the Windows subsystem normally used.
QuoteMSVC has a POSIX build options that is different from a Windows console application?
It is a linker option.
It must be meant for easy porting or something, not for Simutrans which has code for Windows already. Headless Simutrans on Windows can run as just a regular console application. It doesn't need some POSIX compatibility stuff.
QuoteHeadless Simutrans on Windows can run as just a regular console application. It doesn't need some POSIX compatibility stuff.
The backend file should really be renamed to "simsys_cl" (command line) rather than "simsys_posix" to avoid confusion.
I think "console" would be more understandable than "cl". Although I guess one could run it fully detached as a service as well.