Building wxWidgets for XP

The official Audacity download has an exe built for XP (subsystem 5.01), but it uses wxWidgets DLLs built for Vista and later (subsystem 6.00). Presumably, the 2.1.2 wx DLLs were built with the default VS2013 C++ configuration, v120 whereas the Audacity was built with v120_xp. If so, then they were likely built with different SDKs. Mixing such things is not, to the best of my understanding, something supported by Microsoft.

One way to avoid this problem is to build wxWidgets with the v120_xp configuration. A diff against wxWidgets v3.1.0 can be found here: props.diff. The build system is different for earlier versions wxWidgets, so the change isn’t as localized, but the idea is the same: the "v120"s need to become "v120_xp"s.

Alternately, one could drop XP support.

Here’s truncated dumpbin output from some of the files in the 2.1.2 download (note the “subsystem version”):

audacity-win-2.1.2\Audacity>dumpbin /headers audacity.exe
Microsoft (R) COFF/PE Dumper Version 14.00.23918.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file audacity.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               5 number of sections
        5691052F time date stamp Sat Jan  9 06:03:43 2016
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             103 characteristics
                   Relocations stripped
                   Executable
                   32 bit word machine

OPTIONAL HEADER VALUES
             10B magic # (PE32)
           12.00 linker version
          48D400 size of code
          49B200 size of initialized data
               0 size of uninitialized data
          425600 entry point (00825600)
            1000 base of code
          48F000 base of data
          400000 image base (00400000 to 00D2BFFF)
            1000 section alignment
             200 file alignment
            5.01 operating system version
            0.00 image version
            5.01 subsystem version



audacity-win-2.1.2\Audacity>dumpbin /headers wxmsw30u_core_vc_custom.dll
Microsoft (R) COFF/PE Dumper Version 14.00.23918.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file wxmsw30u_core_vc_custom.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
             14C machine (x86)
               5 number of sections
        5679D100 time date stamp Tue Dec 22 15:38:56 2015
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
            2102 characteristics
                   Executable
                   32 bit word machine
                   DLL

OPTIONAL HEADER VALUES
             10B magic # (PE32)
           12.00 linker version
          22EC00 size of code
          223000 size of initialized data
               0 size of uninitialized data
          1FF64D entry point (101FF64D)
            1000 base of code
          230000 base of data
        10000000 image base (10000000 to 10454FFF)
            1000 section alignment
             200 file alignment
            6.00 operating system version
            0.00 image version
            6.00 subsystem version

Yes you are correct, the Audacity Platform Toolset is “Windows XP (v120_xp)” and the Platform Toolset for the wxWidgets projects is the default “Visual Studio 2013 (v120)” .

Both the wxWidgets DLL’s and Audacity are built on the same machine with Visual Studio 2013 and so I assume the same SDK.

Alright I will ask about this. Have you found problems in Audacity on XP? I am not aware of any, though I rarely use Audacity on XP. Another argument states that it if it is working now, which it is on Vista and later, don’t fix it.

The plan is to make the next 2.1.3 release of Audacity the final one for XP. So if rebuilding the Widgets DLL’s as version 5 is not harmful, it may be good to make that change in 2.1.3-alpha so that it gets plenty of testing.

Thanks,


Gale

I was writing at the same time as Gale, but my question is basically the same - have you found an actual “problem” (something that doesn’t work), or are you just saying that it’s “unsupported by Microsoft”?

One of the changes from v120 to v120_xp is to get the includes and libraries from a version of the Windows 7 SDK (since that is the last version of the Windows SDK that includes support for targeting Windows XP). You can see what you have installed in C:\Program Files (x86)\Microsoft SDKs\Windows and C:\Program Files (x86)\Windows Kits. The v120_xp flag causes it to build with the stuff in the Windows\7.1A directory.

The paths can be see in a project’s properties under “VC++ Directories”. Clicking the drop-box icon to the right of the text field and selecting “Edit” will show what those variables resolve to. On my box with the v120_xp platform toolset selected, I get “$(VC_IncludePath);$(WindowsSdk_71A_IncludePath);” for the “Include Directories”, which resolves to:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\include

Using the v120 platform toolset, I get “$(VC_IncludePath);$(WindowsSDK_IncludePath);”, which resolves to:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include
C:\Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt

The library paths are also different.

Note that the feature that shows the actual evaluated paths when bringing up the edit dialog is new in VS2015.

No, I’m not aware of any specific problems and I don’t have a test XP box set up. The likely issues would be along the lines of API calls that are missing or possibly missing bug work-arounds that were in the earlier SDK’s headers or libraries that are not present in the later SDKs. If there are any problems, they may be subtle, and I would guess more likely to cause trouble on XP than on Vista+.

The C++ compiler stays the same between v120 and v120_xp, so the change is not as drastic as it might seem.

The props.diff is only for v3.1.0, but it is simple enough to make the change when building v3.0.2: Group select the relevant projects in the wxWidget’s solution explorer, bring up the project properties, then change the Platform Toolset for “DLL Release” / Win32 from v120 to v120_xp (all the selected projects should be C++ projects for the “Platform Toolset” setting to show up in the properties). Since v3.1.0 tries to include WinRT support based solely on the VC++ version, one might also need something like what is in the props.diff:

-#if defined(_MSC_VER) && _MSC_VER >= 1700 
+#if defined(_MSC_VER) && _MSC_VER >= 1700 && !defined(_USING_V110_SDK71_)
      #define wxUSE_WINRT 1 
  #else 
      #define wxUSE_WINRT 0

I’m building Audacity and wxWidgets v3.1.0 with v140_xp for Release/Win32 (and v140 for everything else) and everything seems to run okay. For Audacity and wxWidgets v3.0.2, I had all but Audacity Release/Win32 set up for v120, so there was a mismatch between Audacity’s v120_xp and wxWidget’s v120. It was when I started looking at that mismatch that I thought I’d check what had been done with the official build. That’s what led to this thread.

The latter, that it is unsupported. The closest I could find online was this (second hand and related to v110/v110_xp): c++ - vs2012 toolset compatibility - Stack Overflow

In addition to the v120 to v120_xp change, the Linker->System option “SubSystem” should be set to “Windows” for the Release/Win32 DLL projects. Leaving it blank leads to a number of linker warnings telling one to not leave it blank (MSB8030).