DrSuperGood's patches

[DrSuperGood]

Speaking of which, is there any chance my patch for detecting user directory and my patch for MSVC 2015 are going to get committed? I am concerned they have been overlooked.

[Ters]

Speaking of which, is there any chance my patch for detecting user directory and my patch for MSVC 2015 are going to get committed? I am concerned they have been overlooked.

I was thinking of the same, but I wasn't sure if any of them were into Windows and/or Haiku. The latter in particular, is prissi's field.

[Dwachs]

You mean the patches in these two posts?

http://forum.simutrans.com/index.php?topic=14705.msg145651#msg145651

http://forum.simutrans.com/index.php?topic=14744.msg145652#msg145652

They were not easy to find, as they are buried in discussions.

I neither have windows 8 nor Haiku installed to test ...

[Ters]

I haven't tested the MSVS2015 compatibility patch. Though I have MSVS2015, I have no plans to set up a Simutrans build in it (simply because I have no need at the moment, being more interested in exploring other things). The patch only concerns things inside #ifdef _MSC_VER, so for me to test it with mingw should be pointless. It would be nice if someone with an older MSVC++ tried compiling simsys_posix.cc, though. The version checks in that might not be very backward compatible, both as they are and as they become in the patch. Although if no one has such an old MSVC++ now, it might not be likely that anyone ever will.

[kierongreen]

These haven't been overlooked but Ters raised a number of points in those threads such as:

But there is no point in spending lots of efforts on preparing for a possible change still many years into the future. Considering when we dropped support for Windows 9x, and the continued popularity of Windows XP, it will likely be ten years until Windows XP support is dropped. And there is currently nothing to gain from targeting any newer Windows versions explicitly. I just proposed we do a trivial fix to a small problem, not redesign a lot of things. Not that those things are not a good idea, but do them separately. That way, any problems with the bigger rewrite won't hold up the small fix.

and

My only small concern is that selecting different code should, in general, be an explicit configuration in the build, so that one has to explicitly decide to use it. That way, one knows that one has done something different from everyone else, which can avoid lots of wasted time wondering why something works on your computer and not on everybody else's, or vice versa, should there be a breaking difference in the two code paths.

and

Just to try and be a bit more clear: There are two, maybe three, separate issues here. The first is just a curiosity in why it was considered worthwhile to write code specifically for Vista+ that is functionally identical to the code for Windows 2000/XP+. I don't understand, and I like to understand. The default target Windows version in the build doesn't really have anything to do with the patch, it's just something I started think about when I saw a version switch. Maybe I should have started another discussion for that.

My stance would be that compiles for Windows 10 and in MSVC 2015 should be functionally identical to those for other platforms. Obviously if there is something that prevents compiling or running that needs to be fixed, but having too many target platforms makes testing a lot more difficult.

[DrSuperGood]

should be functionally identical to those for other platforms

Not possible with OS specific stuff. Fundamentally how a platform like Linux or Mac OS works is different from how Windows works. The best one can do is abstract away OS call functionality to more generic functionality calls (which happens a lot already) and then implement those functions in a platform specific way, adapting as required.

At some stage the way file paths are managed and resolved should be changed. Specifically recommended practices for modern Windows is to use wide character type Unicode as they do not want modern Windows applications (Mobile, 10, XB1) using multi-char encoding. For Linux and other platforms the change would add extra safety to how paths are fetched and resolved. Both Mac and Windows should have their folder names starting with uppercase as is the standard on those platforms where as Linux should keep its small case folder names (currently there is a mixture of small case and first letter uppercase on Windows and Mac). When/if such changes are implemented the Vista and modern approaches would appear much more tidy and manageable.

[Ters]

There is a difference between supporting three/four OSes, and also supporting multiple versions within those OSes. Especially for Windows, which goes through great pains to be backwards compatible.

Simutrans using wide characters (even conditionally) will however cause too many points of conversion. The Win32 API is called with string parameters in something like five places (RegisterClass, CreateWindow, SetClipboardData, WindowProc and WinMain/sysmain) in the entire codebase for a GDI build. (There is also hostname to IP somewhere in the network code, but that is the Berkeley socket API.) Better to just use UTF-8 in Simutrans, and convert in those few places. That's what every other cross-platform program and library I know of does. The libraries used by Simutrans also likely uses the ANSI API, probably more that Simutrans itself, so there is nothing to gain by converting Simutrans alone.

As for the message from Microsoft that modern Windows applications should not use multi-byte, they are probably referring to how the ANSI API encourages ignorance of Unicode. Microsoft also seems to no longer make ANSI versions of new API functions and interfaces, probably both to force Unicode thinking and to save work. Using the Unicode API and converting to UTF-8 is likely fine by them, although it makes little sense to do so if Windows is all you target (which is what Microsoft cares about, at least sort of). And modern Windows applications should not use the Win32 API either. Nor C++, except for the other C++. For cross platform development, Microsoft seems to be pushing for JavaScript.

Making Simutrans unconditionally Unicode based on UTF-8 is the right choice my opinion, but that's completely unrelated to the V2 home directory patch.

[prissi]

The reason I used the A functions when introducing Unicode was, that windows 98/2000 (which can be surely dropped) and Mingw did not support the unicode versions. But also the automatic tool/version number builder in the makefile was not happy with 8 bit UTF-8 for 16 bit wide character calls. I need to check whether this is still the case.

And for dr_time, the standard windows executable uses timeGetTime() on windows, which would also do for Posix without all those conversions. Also SHGetFolderPath will work for the forseeable future, as any dynamic linked program for XP will die without it.

[Ters]

We've already dropped Windows 9x/Me. Windows 2000 supports Unicode, as the wide API is a Windows NT thing.

And one can obviously not call a wide API function using multi-byte (UTF-8 or otherwise) string. One needs to convert the string for the handful of wide API calls Simutrans need. Seems like the code for that is #if 0-ed in simsys_w.cc.

A possibly more pressing issue is whether libraries like zlib and bzip support Unicode file names on Windows.

[DrSuperGood]

A possibly more pressing issue is whether libraries like zlib and bzip support Unicode file names on Windows.

I think they do, I recall seeing macros for that.

[Ters]

I think they do, I recall seeing macros for that.

That is good. It means that Simutrans can do Unicode file names on alle platforms supporting it (as far as I know).

Still, most string operations towards the outside in Simutrans probably relate to pak files, configuration files, save games, networking and scripts. Especially for the latter three, continuously converting between UTF-16 and UTF-8 won't be a good idea. Internal text rendering operates on UTF-8 already.

However, this is derailing again. This has nothing to do with the two patches presented.