View Issue Details

IDProjectCategoryView StatusLast Update
0000836OpenMPTGeneralpublic2018-12-30 16:51
Reportermanx Assigned Tomanx  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product VersionOpenMPT 1.26.03.* (old testing) 
Target VersionOpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)Fixed in VersionOpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first) 
Summary0000836: Remove support for C++98 and C++03 compilers
Description

Still supporting these ancient compilers requires a huge amount of development time on work-arounds and re-implementing current, modern standard language features in sub-optimal fashion.

Support for obsolete and broken compilers should be removed as soon as possible.
This includes <strong>at the very least</strong> (this list is <strong>not</strong> up for discussion from my side, as removing fewer compiler will not gain us anything at all):
<ul>
<li>MSVC 2008, MSVC 2010, MSVC 2012</li>
<li>GCC 4.1, GCC 4.2, GCC 4.3, GCC 4.4, GCC 4.5, GCC 4.6</li>
<li>Clang 3.0, Clang 3.1</li>
</ul>
Requiring MSVC 2013, GCC 4.7, Clang 3.2 gives us usable C++11 support.
This will bump the minimum required Operating System versions for some common ones to:
<ul>
<li>Windows XP (removing Windows 98 SE + KernelEx, Windows ME + KernelEx, Windows 2000</li>
<li>Debian 7 (removing Debian 4, Debian 5, Debian 6)</li>
<li>Ubuntu 14.04 (removing Ubuntu 8.04, Ubuntu 10.04, Ubuntu 12.04)</li>
<li>FreeBSD 10 (removing FreeBSD 7, FreeBSD 8, FreeBSD 9)</li>
<li>CentOS 7 (removing CentOS 5, CentOS 6)</li>
</ul>
Note that all of these common OSs have already stable Long Term Support releases (which we would continue to support) out since more than 2 years now. For Windows, Long Term Support for Windows 2000 even expired more than 5 years ago by now.

Additional Information

Usable C++14 support would probably (at least) require additionally removing support for the following compilers:
<ul>
<li>MSVC 2013</li>
<li>GCC 4.7, GCC 4.8, GCC 4.9</li>
<li>Clang 3.2, Clang 3.3</li>
</ul>
This is currently not feasible at all, because it would mean removing support for the current LTS release of various Operating System.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Relationships

parent of 0000846 resolvedmanx Enable C++11 support on Android 
related to 0000821 resolvedmanx Document how libopenmpt can be used in multi-threaded environment 
related to 0001098 resolvedmanx Remove suppot for Clang 3.4 and Clang 3.5 
related to 0001183 resolvedmanx require C++14 

Activities

manx

manx

2016-07-30 09:35

administrator   ~0002529

We may want to take this to the forum and/or add telemetry data on used Operating System to the update mechanism of OpenMPT.

Saga Musix

Saga Musix

2016-07-30 16:37

administrator   ~0002530

Since r6705, there is telemetry for Windows/Wine versions in the update checker.

harbinger

harbinger

2016-08-04 15:20

reporter   ~0002539

I don't know about this. I came to ModPlug thru Windows 98 (actually an emulator of it on Mac), and I'd still be using it if I didn't have other applications that motivated me to get a Windows computer. I'm still on XP, but computers are often handed down that use obsolete platforms, and I'd hate to lose a potential user/member/colleague because our software is one version beyond their reach.
I have no intention of moving "up" from Windows XP, so when am I gonna get muscled out? (rhetorical question to make a point)

Now if you're doing an overhaul of the GUI and you need to do a serious update to the features, for which we simply didn't have the tech way back when ModPlug was open-sourced, that's different. Otherwise if you're only doing it for convenience's sake, maybe you can brainstorm a workaround, so that older computers are not once again denied a great old-school application.

Yes, perhaps a thread in the forums will bring us to a nice compromise or win-win answer....

Saga Musix

Saga Musix

2016-08-04 15:26

administrator   ~0002540

I don't know about this. I came to ModPlug thru Windows 98 (actually an emulator of it on Mac), and I'd still be using it if I didn't have other applications that motivated me to get a Windows computer.

This is 2016, not 2006. Most major software that people use no longer runs on Windows 98 or Windows 2000, making OpenMPT a very rare exception. You can always use an old version of OpenMPT on Windows 98 if you really must. Besides, what about the theortical Windows 95 users out there which also cannot use OpenMPT anymore since... more than 10 years ago?

Otherwise if you're only doing it for convenience's sake, maybe you can brainstorm a workaround, so that older computers are not once again denied a great old-school application.

The "convenience" we are talking about here directly correlates with motivation to work on the code at all. If the code is complicated to write (which it is when having to target C++98), it's also not fun to write. The "workaround" you are talking about is not upgrading to C++11, making writing new, maintainable code more complicated than necessary.

Saga Musix

Saga Musix

2016-08-04 15:31

administrator   ~0002541

(besides, it is very well possible that Win98SE and WinME may still be supported through KernelEx - only dropping Win2k support in the end. That entirely depends on which APIs are available in KernelEx and which are not. manx' list is just a worst-case assumption in this regard.)

manx

manx

2016-08-04 16:32

administrator   ~0002542

As far as I know, there is no way whatsoever to make a Win 9x kernel load MSVC 2010 (or later) binaries at all. I think I did try that in the past. After all, as far as I know, this was the one and only reason to still support MSVC 2008 at all.
Thus, Win98SE and WinME support <strong>will die</strong>.

manx

manx

2016-08-04 19:40

administrator   ~0002543

I have no intention of moving "up" from Windows XP, so when am I gonna get muscled out?

I think it is generally (as a goal to strive for) wise to support at least two versions (i.e. the latest two) of Visual Studio. Thus, as long as the second to latest Visual Studio release still supports Windows XP, it probably will not go away (for Win32old build variants). Full functionality already currently requires Windows 7 / 8.1 (mostly because of compressed lossy sample import).
Visual Studio 2015 still supports XP, thus Windows XP support is here to stay at least for the next 2 years, I guess. I cannot predict the future of course, and there may be or come around other reasons to remove Windows XP at some point.
Currently, however, I do not think there is much to gain from removing Windows XP support. Not so much because of Windows XP itself, but because of Wine, which in most aspects implements functionality roughly equivalent to Windows XP API level.

manx

manx

2016-08-09 09:32

administrator   ~0002586

I again just lost about 2 hours fighting broken compilers.

manx

manx

2016-08-14 17:00

administrator   ~0002601

Removing support for MSVC 2008, MSVC 2010, MSVC 2012 will remove support for the following CPUs in OpenMPT and libopenmpt builds:

  • Cyrix 6x86L
  • Rise mP6
  • IDT Winchip C6
  • IDT Winchip 2
manx

manx

2016-08-14 19:32

administrator   ~0002602

vs2015xp builds crash on Wine 1.0.1

manx

manx

2016-08-21 12:55

administrator   ~0002622

vs2015xp builds work on Wine 1.4.1

manx

manx

2016-08-21 13:10

administrator   ~0002623

I think it would be worth the effort to still support GCC 4.6 in some kind of ANCIENT configuration (like we are currently doing for MSVC 2008, GCC 4.1, GCC 4.2, GCC 4.3) because Debian 7 still uses GCC 4.6 on non-x86 systems.
Our only real hardware big-endian system is on Debian 6 and cannot be upgraded. Installing Debian 7 compilers there might be feasible though.

manx

manx

2016-08-24 07:26

administrator   ~0002626

Forum post is at https://forum.openmpt.org/index.php?topic=5708.0 .

manx

manx

2016-09-02 16:08

administrator   ~0002632

Support for VS2008, GCC 4.1, GCC 4.2, GCC 4.3 is gone now (r7005, r7006, r7007, r7009).

manx

manx

2016-09-08 16:15

administrator   ~0002650

GCC 4.7 has severe problems with moderate use of constexpr, thus, to get really usable C++11 support, GCC 4.7 support would also have to be removed.

manx

manx

2016-10-02 08:39

administrator   ~0002684

So far, we have only dropped 4 compilers:

  • MSVC 2008
  • GCC 4.1
  • GCC 4.2
  • GCC 4.3
manx

manx

2016-10-15 09:24

administrator   ~0002697

Last edited: 2016-10-15 09:24

Various C++ features would require support for various different compilers to be removed:

random:
gcc 4.4

nullptr:
gcc 4.4
gcc 4.5

chrono:
vs 2010

enum class:
vs 2010

inttypes:
vs 2010
vs 2012

variadic templates:
vs 2010
vs 2012

default/delete:
vs 2010
vs 2012

template aliases:
gcc 4.4
gcc 4.5
gcc 4.6
vs 2010
vs 2012

noexcept:
gcc 4.4
gcc 4.5
vs 2010
vs 2012
vs 2013

constexpr (c++11):
gcc 4.4
gcc 4.5
gcc 4.6
gcc 4.7
clang 3.0
vs 2010
vs 2012
vs 2013

atomic:
clang 3.0
vs 2010

mutex:
clang 3.0
clang 3.1
vs 2010

thread:
clang 3.0
clang 3.1
clang 3.2
clang 3.3
clang 3.4
clang 3.5
vs 2010

manx

manx

2016-10-17 17:00

administrator   ~0002699

...

type_traits working for array types:
vs 2010
vs 2012
vs 2013

type_traits is_trivially_copyable:
gcc 4.4
gcc 4.5
gcc 4.6
gcc 4.7
gcc 4.8
gcc 4.9
gcc 5.0
clang 3.0
clang 3.1
clang 3.2
clang 3.3
clang 3.4
vs 2010

manx

manx

2017-04-21 12:31

administrator   ~0002980

r8006 to r8014 remove support for GCC 4.4, 4.5, 4.6, 4.7, clang 3.0, 3.1, 3.2, 3.3, vs 2010, 2012, 2013.

This means, we can now start using at least the following C++ features unconditionally (this list is incomplete):

  • random
  • nullptr
  • chrono
  • enum class
  • inttypes
  • variadic templates
  • default/delete
  • template aliases
  • noexcept
  • constexpr (c++11)
  • atomic
  • type_traits working for array types

The following features still require attention (the std:: version is not available for Win32old and Win64old build because of Wine compatibility):

  • mutex (not available in threadless environments like emscripten)

The following features are still not available unconditionally:

  • thread (not available in threadless environments like emscripten)
    • clang 3.4
    • clang 3.5
  • type_traits is_trivially_copyable
    • gcc 4.8
    • gcc 4.9
    • gcc 5.0
    • clang 3.4

Issue History

Date Modified Username Field Change
2016-07-30 09:32 manx New Issue
2016-07-30 09:35 manx Note Added: 0002529
2016-07-30 16:37 Saga Musix Note Added: 0002530
2016-08-04 15:20 harbinger Note Added: 0002539
2016-08-04 15:26 Saga Musix Note Added: 0002540
2016-08-04 15:31 Saga Musix Note Added: 0002541
2016-08-04 16:32 manx Note Added: 0002542
2016-08-04 19:40 manx Note Added: 0002543
2016-08-05 09:30 manx Relationship added parent of 0000846
2016-08-09 09:32 manx Note Added: 0002586
2016-08-14 17:00 manx Note Added: 0002601
2016-08-14 19:32 manx Note Added: 0002602
2016-08-20 10:01 manx Relationship added related to 0000821
2016-08-21 12:55 manx Note Added: 0002622
2016-08-21 13:10 manx Note Added: 0002623
2016-08-24 07:26 manx Note Added: 0002626
2016-08-26 06:54 manx Target Version => OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)
2016-09-02 16:08 manx Note Added: 0002632
2016-09-03 11:13 manx Additional Information Updated
2016-09-08 16:15 manx Note Added: 0002650
2016-10-02 08:39 manx Note Added: 0002684
2016-10-15 09:24 manx Note Added: 0002697
2016-10-15 09:24 manx Note Edited: 0002697
2016-10-17 17:00 manx Note Added: 0002699
2017-02-24 10:29 manx Assigned To => manx
2017-02-24 10:29 manx Status new => assigned
2017-04-21 12:31 manx Note Added: 0002980
2017-04-21 13:57 manx Status assigned => resolved
2017-04-21 13:57 manx Resolution open => fixed
2017-04-21 13:57 manx Fixed in Version => OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)
2018-03-05 09:35 manx Relationship added related to 0001098
2018-12-30 16:51 manx Relationship added related to 0001183