Juce 4.1.0 incompatible with windows xp?


#1

From a clean download and a fresh win xp x86 sp3 install, the introjucer and juce demo from juce 4.1.0 do not build with visual studio 2010. I get an error saying the entrypoint procedure X for kernel32.dll is not found (https://support.microsoft.com/en-us/kb/142606). Introjucer from Juce 3.2.0 seems to work.

EDIT: After some tests, this problem starts at version 4.0.1


VST2 XP SP3 compatibility with VS2015
#2

Hi there,

I really hate to be the harbinger of bad news, but unfortunately we don't support Windows XP.

Please update to Windows 7, 8, 8.1, or 10 in order to use JUCE 4.


#3

Alright, I guess that makes sense. Is this written anywhere in the doc?


VST2 XP SP3 compatibility with VS2015
#4

Not explicitly, it seems.

Thanks, I'll see to it that we add a proper "minimum system requirements" section somewhere on the website.

Just out of curiosity: in the year 2016, what is your motivation to use Windows XP as your platform for software development?


VST2 XP SP3 compatibility with VS2015
#5

Speaks for itself, really.


#6

FYI we don't officially support XP, but since it pretty much still works, we're not opposed to making small tweaks to stay compatible with it.

However, we don't have an XP machine and don't test it ourselves, so it's up to you guys to offer change requests for it, which we'll add as long as they seem safe.


#7

I develop on win 10, but wanted to check if my plugins were working on a win xp virtual machine. I got weird errors so decided to build JUCE from scratch to see if that was the problem. And it was. Really not a big deal though, everything works on win 7.


#8

I can build plugins that run on XP SP2 and later on windows 10. Due to changes in the windows 10 SDK it does not work if you build with MSVC2015 even if the platform toolset v140_xp is used. It's something related to dll loading and how system calls are abstracted between versions of windows.

However what does work (at least for me) is building the plugin with MSVC2013. The JUCE codebase itself is totally compatible with XP.

People should really be discouraged from using XP nowadays, but there are quite a few audio people who stick to their OSes as long as possible.


#9

Our plugins also crashed while loading on XP. I don’t have a XP machine to test, but following maybe works. I will add this option to our plugins and see what happens:

  1. Link the CRT statically - in Config Properties / C/C++ / Code Generation / Runtime Library select the non-DLL multi-threaded option, for example /MT in the release build.

  2. Add /Zc:threadSafeInit- (n.b. the trailing - is part of the switch) to the compiler options under Config Properties / C/C++ / Command Line / Additional Options.

See here:


How do you make a Windows XP compatible VST?
#10

Maybe this helps:

  1. Link the CRT statically - in Config Properties / C/C++ / Code Generation / Runtime Library select the non-DLL multi-threaded option, for example /MT in the release build.
  2. Add /Zc:threadSafeInit- (n.b. the trailing - is part of the switch) to the compiler options under Config Properties / C/C++ / Command Line / Additional Options.

#11

Yes this does help! Using visual studio 2015 update 2, the 140_xp toolset and the /Zc:threadSafeInit- I was able to build a plugin that loads on Windows XP. So finally I can erase VS2013. The explanation (by Microsoft) on the thread you linked is rather interesting, so I’ll copy it here as well:

Windows Server 2003 and Windows XP have problems with dynamically loading a DLL (via LoadLibrary) that uses thread-local storage, which is what thread-safe statics use internally to provide efficient execution when the static local has already been initialized. As these systems are out of support, it is extremely unlikely for a patch to be created for those systems to add this support as is present in Vista and newer OSes, and we are reluctant to penalize the performance on in-support OSes to provide this functionality to the old out-of-support ones.

To work around the issue you can use /Zc:threadSafeInit- to disable the thread-safe initialization code and this will avoid the thread-local variable. Of course by doing so the initialization code reverts back to the VS2013 mode and is not thread-safe, so this option is only viable if you don’t rely on the thread-safety of local statics.


How many people are using Visual Studio 2013?
Recent commit breaks compatibilty with OSX target SDK 10.6
#12

For us we have a couple of thousand customer machines in the field using XP many of which wouldn’t support the upgrade to Windows 7 even if the cost wasn’t prohibitive - so its a big deal to us.