Skip to main content
Topic: Visual Studio 2013-2017 compatibility notice (Read 18231 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Visual Studio 2013-2017 compatibility notice

Reply #25
Is there a new test case? The original one (VS2013-miscompile-v1.0.zip) seems to be behaving correctly for me with the v141_xp toolset in VS2017.
.

Re: Visual Studio 2013-2017 compatibility notice

Reply #26
As far as I know Peter hasn't tried making a new test case. But we saw a simple DSP component crash the moment it was activated when compiled with dynamic CRT linking. Disabling the devirtualization optimization made things work.

Re: Visual Studio 2013-2017 compatibility notice

Reply #27
Partly I was wondering whether VS2015 Update 3 was said to be OK (previously VS2015 RTM was said to be fine).
.

Re: Visual Studio 2013-2017 compatibility notice

Reply #28
I heard VS 2015 is also affected. You can test with the sample component I made: http://www.saunalahti.fi/~cse/temp/foo_dsp_crash.zip. Contains a VS 2017 compiled binary and sources.

Re: Visual Studio 2013-2017 compatibility notice

Reply #29
foobar2000 core (as for 1.4 alpha) is being developed using VS2017, so if there are any new issues I will be the first to know.

Since foobar2000 still supports Windows versions as old as Windows XP - and that's not expected to change this decade - you should use "Windows XP (v141_xp)" toolchain to compile your components in order to support all systems that foobar2000 runs on, unless you specifically require a newer version of Windows.

Since VS2017 version 15.3, newly created projects get a /permissive- switch:
https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance
You can toggle this in C/C++ => Language => Conformance mode
While strict compliance with C++ standards is a good thing, it rejects various code that all MS compilers from the past 15 years had no problem with, in particular refusing to compile foobar2000 SDK (a fixed version is on its way) and Windows SDK version 7.0 which you're expected to use with the v141_xp toolchain.
Therefore I recommend turning Conformance mode to off when compiling foobar2000 code.

To summarize-
Correct compilation of foobar2000 code with VS2017 requires:
C/C++ => Language => Conformance mode: off
C/C++ =>Command Line => /d2notypeopt
If your component supports Windows XP:
General => Platform Toolset : Visual Studio 2017 - Windows XP (v141_xp)

Re: Visual Studio 2013-2017 compatibility notice

Reply #30
Since foobar2000 still supports Windows versions as old as Windows XP - and that's not expected to change this decade
BTW ffmpeg developers consider dropping WinXP compatibility: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222354.html

P.S. Though according to https://trac.ffmpeg.org/wiki/Downstreams version 3.2 will be supported up to 2022-06? So basically nothing to worry about, sorry.

[added 2017-12-29] P.P.S. WinXP support in ffmpeg was dropped in this commit

Re: Visual Studio 2013-2017 compatibility notice

Reply #31
The recommended compiler options does not include Enable Enhanced Instruction Set: No Enhanced Instructions (i.e. /arch:IA32).
Does it mean that foobar2000 1.4 will require SSE2, so I can safely use it in my components without checking?

Re: Visual Studio 2013-2017 compatibility notice

Reply #32
I just tested on a machine without SSE capability and 1.4 beta 1 crashes instantly. I'm certain this is by mistake as there's no reason to force such requirement.

Re: Visual Studio 2013-2017 compatibility notice

Reply #33
1.4 beta 2 has corrected the mistake and no SSE instructions are required anymore.

Re: Visual Studio 2013-2017 compatibility notice

Reply #34
1.4 beta 2 has corrected ... no SSE instructions are required anymore.
perfect! it works on athlons xp!
Senior QA Engineer


Re: Visual Studio 2013-2017 compatibility notice

Reply #36
Thread unpinned.

New foobar2000 SDK is out, with working VS2017 project files, and everything that you need to know is in the readme.

Re: Visual Studio 2013-2017 compatibility notice

Reply #37
1.4 beta 2 has corrected the mistake and no SSE instructions are required anymore.
Although it seems that built-in visualizations Spectrum, Oscilloscope and Spectrogram still require SSE (2?). On emulated pentium 2 and 3 fb2k 1.4 beta 3 crashes on playback start when any of this visualisations are enabled.

Re: Visual Studio 2013-2017 compatibility notice

Reply #38
Nice find.
The FFT part of visualisation_manager code in foobar2000.exe still gets compiled with SSE - against the settings.
Possibly tied to being a single C file in a project where everything else is C++. Still, the properties say "No Enhanced Instructions (/arch:IA32)", so it's lying.

Follow up-
Apparently VS2017 generates SSE code regardless of settings if you have sin()+cos() in a chain.
This line is enough to trigger the bug-
static void bork(float * out) {out[0] = (float)cos(0);out[1] = (float)sin(0);}
Relevant command-line arguments:
/arch:IA32
/O2 or /Ox  ( no bug with /O1 )
/fp:fast  ( no bug with /fp:precise but it's slow that way )

 

Re: Visual Studio 2013-2017 compatibility notice

Reply #40
Seems like a similar bug. Same optimizer in a newer form in VS2017 after all. In a typical Mozilla fashion their solution seemed to be to fuck everyone who doesn't have a new machine and just require SSE. Peter's solution is to compile the problematic code with /d2SSAOptimizer- parameters to get working code until MS releases a fixed version.

Re: Visual Studio 2013-2017 compatibility notice

Reply #41
...and it seems that libFLAC-fb2k.dll included with 1.4 also doesn't like ancient CPUs. fb2k crashes when adding FLAC file to playlist. Other formats (ogg, mp3) can be played.

Re: Visual Studio 2013-2017 compatibility notice

Reply #42
If I understand correctly, libFLAC-fb2k.dll is built with GCC, so it's not affected by MSVS bugs.

However, FLAC uses -msse2 flag by default (see configure.ac), and it's necessary to pass --disable-sse option to ./configure if you want it to work on older CPUs (it won't disable runtime CPU checks, so libFLAC will stil use SSE-optimized routines if possible).

Re: Visual Studio 2013-2017 compatibility notice

Reply #43
Hi Peter
I've just tried the latest SDK (2018-03-06) with VS 2017 Enterprise and Community editions versions 15.6.2 and 15.6.3 and there are many errors including missing atl header files ie atlapp.h, atlctrls.h and atlcrack.h.

Bearing in mind that I'm a noobie with C++, it could well be me!!


Re: Visual Studio 2013-2017 compatibility notice

Reply #45
I'm taking a second chance on learning c++, visual studio and component development. I don't know if Yirkha's tutorial still applies to the latest sdk and vs 2017. I followed his test project instructions and failed to build the project. These are the last lines of the debug output window:

Code: [Select]
1>Done building project "foobar2000_SDK.vcxproj".
4>------ Build started: Project: foo_whatever, Configuration: Debug Win32 ------
4>stdafx.cpp
4>j:\foobar2000\sdk-2018-03-06\foobar2000\sdk\advconfig.h(251): error C3861: 'get_static_instance': identifier not found
4>j:\foobar2000\sdk-2018-03-06\foobar2000\sdk\advconfig.h(256): note: see reference to class template instantiation 'advconfig_integer_factory_<int_t_>' being compiled
4>j:\foobar2000\sdk-2018-03-06\foobar2000\sdk\advconfig.h(252): error C3861: 'get_static_instance': identifier not found
4>Done building project "foo_whatever.vcxproj" -- FAILED.
========== Build: 3 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I'm late

 
SimplePortal 1.0.0 RC1 © 2008-2018