![]() ![]() That is why it was working in VS2013 but not 2015.īoth VS and wxWidgets trying to solve TLS issues at the same time seems to get bad results. So using VS2015 then compiler TLS is set to 0 at the end (disabled). ![]() So it effectively uses #define wxUSE_COMPILER_TLS 0 for anything other than VS version 11 (VS2012/VS2013) or when using windows SDK71 not SDK81 (which they are related to the use of v110_xp, v120_xp or v140_xp too). * However defining wxUSE_COMPILER_TLS as 2 overrides this safety check, see * as MSVC 11+, unless it's used with the special "_xp" toolset, in which case * XP, as is the case if we're using a compiler which doesn't support XP such * So we disable it unless we can be certain that the code will never run under * to diagnose crashes due to the bugs in Windows TLS support, see #13116. * inside a dynamically loaded DLL under Windows XP, as this can result in hard * Unfortunately we can't use compiler TLS support if the library can be used It's already been stated multiple times that 1.4.0 is the last release to support XP and it's also in the README.md, so it should come as no surprise. So the ability to run future PCSX2 dev builds on XP will disappear soon. ![]() We can use some of the newer API, and the Visual Studio code analysis tools will work. We can move to the newer non-XP compatible toolkits.That'd let people compile everything except SPU2-X without the DirectX SDK installed, some people do seem to have trouble installing the SDK on later Windows OSes. Reduce usage of DirectX SDK headers to only xaudio2.h (EDIT: and whatever that pulls in) for SPU2-X.We can use XAudio 2.8/2.9 for Windows 8, 8.1 and 10 and XAudio 2.7 for Windows 7/Vista, since 2.7 can be buggy (and not because of us) and I don't really know whether my workaround works or not.There are plenty of people asking for help on the forums where the answer is "Install the DirectX redists". No need to install DirectX redists on Windows 8, 8.1 and Windows 10 to run PCSX2.Making changes to either might hurt performance and/or introduce bugs - I don't think either should be changed. 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. 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. 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. 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. care about the scenario described above. Recommended setting: 2 if you want to have maximal performance and don't Default is 1 meaning that compiler TLS is used only if it's 100% safe. set this to 2 to force the use of compiler TLS even under MSW. kind of plugin or because you only target Vista or later systems, you can used in such situation, either because it's not going to be linked from any If you're absolutely sure that your build of wxWidgets is never going to be XP as this triggers a bug in compiler TLS support that results in crashes is used in a dynamically loaded Win32 DLL (i.e. disabled under Windows in wx/msw/chkconf.h as it can't be used if wxWidgets the compiler-provided support as it's simpler and more efficient, but is This is used for wxTLS_XXX() macros implementation and normally should use Enable the use of compiler-specific thread local storage keyword, if any.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |