In 10 years there was no active development on DOS. Although it
turned out to still work, the FPS was very bad. There is little
interest in the current community to look into this.
Further more, we like to switch to c++11 functions for threads,
which are not implemented by DJGPP, the only current compiler
for DOS.
Additionally, DOS is the only platform which does not support
networking. It is the reason we have tons of #ifdefs to support
disabling networking.
By removing DOS support, we can both use c++11 functions for threads,
and remove all the code related to disabling network. Sadly, this
means we have to see DOS go.
Of course, if you feel up for the task, simply revert this commit,
and implement stub c++11 functions for threads and stub functions
for networking. We are more than happy to accept such Pull Request.
GetAircraftFlightLevel<Aircraft> is only used in static functions
inside aircraft_cmd.cpp. With GCC, Clang and MSVC this is not an
issue, but on ICC fails linking, because it doesn't find this
version of this template. Possibly these two pieces of information
are linked.
Explicit defining the function fixes the issue.
It is only an error if the invalid result is actually used. This will be silently ignored at the moment.
It is still an error if a duplicate cargo type is returned.
Currently this can only be triggered by NewGRF house tiles querying for cargo acceptance history
of nearby stations (var 0x64) with a tile offset, and providing an offset that happens to point
to an industry tile. This serves no useful purpose.
_current_company is not currently logged anywhere in the crashlog.
_local_company is logged, despite being much less useful than
_current_company.
This change logs _current_company alongside _local_company.
If it was compiled with MingW, both / and \ were accepted as
path separator. On MSVC, only \ was. This is an unexpected
difference between binaries for the same platform. Remove this
discrepancy by accepting both / and \ on all platforms.
config.lib happens to set GLOBAL_DATA_DIR in case it is not DOS
and not OS2, but this kind of deduction is annoying to maintain.
It is better to just check if the define you want to use is set,
and leave it to config.lib to set it or not depending on the OS.
By naming it in a different way, things get a bit confusing.
Especially if we are switching to CMake, which autodetects these
things, we need to use the name the authors of ICU gave it; not
our interpertation of that name.
By naming it in a different way, things get a bit confusing.
Especially if we are switching to CMake, which autodetects these
things, we need to use the name the authors of ICU gave it; not
our interpertation of that name.
It is the only library we use that calls itself with 'lib' in the
name. This might be confusing, but with the arrival of cmake a lot
of these things are automated. And detection will find 'liblzma',
not 'lzma', like with 'lzo', 'zlib', ..