News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Drop support for Windows 9x

Started by Ters, February 01, 2015, 10:18:01 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ters

One thing that's constantly bothering me when setting up Simutrans to build with mingw is the following:

ifeq ($(BACKEND),gdi)
  LIBS += -lunicows
endif


It's not part of a standard mingw installation and is only required to provide Unicode support/emulation on Windows 95, 98 and Me. I'm normally one to argue for continued support for older systems, but these are so old that just getting online to download Simutrans must be a challenge (only very old versions of Internet Explorer and Firefox support Windows 98/Me).

Ters

Furthermore, with -DWINVER=0x0501, support for Win9x is dead already. So unicows has been pointless for some time already.

An_dz


DrSuperGood

The POSIX Windows build will only work for 2000 or later anyway due to the API I choose to use (might be improvable by someone who understands the time requirements higher up).

I would strongly recommend not supporting such ancient OS as Windows pre-2000. Not only would such a requirement highly restrict the API available (to the point some things might be over complicated to do) but also I would not encourage people to use such operating systems purely from the security point of view (we all remember how such systems were prone to viruses, and I am sure nearly 2 decades of no support has not helped).

If someone is using such an old operating system I would recommend they either look into a new computer, or that they consider some version of Linux (probably more recent and ore secure, even if working recent builds are not available for their hardware).

Ters

Quote from: DrSuperGood on February 04, 2015, 12:56:14 AM
I would strongly recommend not supporting such ancient OS as Windows pre-2000.

As I wrote in my second post, we don't, so the title of this topic has become misleading. But there are still things in Simutrans that has been put there to support Win9x that are now just vestigal.

isidoro

@DrSuperGood: although I understand your arguments against supporting the not-serious version of Windows, the security of those systems has little to do with it.  People decide what systems they use and devs decide what systems will ST run on.

Ters

It's also possible that those systems have become safer again because the viruses and worms targetting them are dying out, and nobody bothers making new. Windows NT 4.0 might be more exposed, having more in common with modern Windowses. The greatest problem with using those OSes is likely that the modern web won't work in browsers capable of running on them.

prissi

The missing IPv6 support is the strongest argument of no longer supplying windows9x builds. Apart from the fact that most hardware capable of running it has died out.

Markohs

Supporting something that it's more than 10 - 15 years old makes no sense imho. Of course we should remove all code related to support that, makes no sense keeping it and can introduce bugs and add unnecessary complexity to the code.

prissi

The only code for WIn98 is the Unicows.DLL. The Windows interface to GDI is the same (including some shady code to switch to 16 bit fullscreen).

Ters

Quote from: Markohs on February 06, 2015, 11:34:42 AM
Supporting something that it's more than 10 - 15 years old makes no sense imho.

Like STL? ;D

Quote from: prissi on February 06, 2015, 12:32:01 PM
The only code for WIn98 is the Unicows.DLL. The Windows interface to GDI is the same (including some shady code to switch to 16 bit fullscreen).

There might be some code that uses older version of some Windows API, but I don't think there's any place where using a newer API would gain anything. Support for Mingw32 also puts a limit on usable APIs.

DrSuperGood

QuoteSupport for Mingw32 also puts a limit on usable APIs.
Some of the code uses Macros to detect Visual C++ builds. For example when building POSIX it will employ a work around for Visual C++ as it lacks the required timing functions.

That said there really should be some guide line as to what the current platform requirements of Simutrans are (what platforms development will make sure it works on). Operating systems not on the list might still be able to build however committed code will not specifically target them and code revisions might lead to removal of support for platforms not on the list. This is important for choosing the APIs to use and to prevent bogging down code development with having to provide alternatives of everything for platforms determined as unsupported.

Ters

The limitations Mingw32 imposes are not really related to platform, at least not the way platform is usually understood in relation to system requirement. Which part of the Windows API Mingw32 provides isn't clear either, so the only way to tell if something can be done with Mingw32, is to try to do it with Mingw32. Stating that Simutrans should be buildable with Mingw32 at least makes it clear that this is a rule, but doesn't help those coding with MSVC.

Markohs

Quote from: Ters on February 06, 2015, 04:19:44 PM
Like STL? ;D

Well, you know what I meant, Ters, comeon. :)

STL might be old, but older is C++ and even older, C. What I meant is that it makes no sense actively supporting systems so obsolete, if you need to have code devoted to it. Code that's supposed to be mantained.

Ters

I just couldn't resist the temptation to make a comment of the fact that STL support matured about the same time that Win 9x became obsolete.

Ters

I've added a patch, in case that makes it easier to get this change in. It doesn't look like anyone actually wants this Win9x library.