Refocus on VS2015 .. continued FYI

FYI:
The raft of errors mentioned in the OSX/VS2015 post previously of mine, are being generated in the lib-src\libnyquist part of the build. If I uncomment that part of the Project Solution - then all of those errors go away. So at least I know now what part is causing that problem, and can deal with it when I can.

There are still others, most notably in the lv2 part of the project. So I’ll try turning that off too.

24>LINK : fatal error LNK1104: cannot open file 'lv2.lib'
========== Rebuild All: 20 succeeded, 3 failed, 1 skipped ======

So anyway, for now, it’s not all that difficult to move the whole thing up to VS2015 it seems. A few gotchas’ but that’s to be expected.

The first problem I encountered, related to libnyquist, was it’s falling over the VS file, cstdint.h and it’s declarations. Obviously not including the libnyqist in the Build solved nothing, but it did remove the errors from the output being output by that section. Like 3,750 of them give or take.

The second major source of errors that halt the build are in the lv2 part of the Project. So at this point I’m about ready to call a halt for the day myself - it is Sunday here…

So if my discoveries are of any help - well that’s good.

Thanks.

Would you find it easier to create a page about VS2015 and Audacity on http://wiki.audacityteam.org/wiki/? It might be easier to edit as you go along than a string of forum posts, and there is a talk page for draft or older material and full editing history.

If you go that route you can send me a Private Message and I can give you a Wiki account.


Gale

Gale,
Did you get my PM? re the Wiki. It may be useful.

That snprintf bit has me temporarily stumped. Nothing turns that sucker off.
However, I’m down to only 655 errors, 558 warnings. … :slight_smile:

All but 3 parts building.
It really seems to be a conflict between C and C++ code being mixed together. and who knows what else.

22>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\stdio.h(1925): warning C4005: 'snprintf': macro redefinition
22>  C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\stdio.h(1925): note: command-line arguments:  see previous definition of 'snprintf'
22>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\stdio.h(1927): fatal error C1189: #error:  Macro definition of snprintf conflicts with Standard Library function declaration

and so on ad nauseam …

Yes I got round to that now. A randomly generated password for Rachalmers has been sent to your e-mail address. The password for this new account can be changed on the Change password page upon logging in.

As it is obscure how to create a new page on Wiki, I started a new page for you here: Missing features - Audacity Support.

Have you tried right-click over “Audacity” in Solution Explorer > Properties. Then expand “Configuration Properties” and click “General”. Set “Platform Toolset” to “Visual Studio 2013 (v120)”. At least, that is where you change it in VS2013. It works for others, so they say.


Gale

Thanks, yes, I’m aware of the toolset thing, but it’s the purist approach I’m taking with this. Learning a lot in the process.
Thanks
Robert

Those errors are from some compatibility files that conflict with Microsoft’s own files (IIRC, stdint.h and inttypes.h). Now that MS has them, overriding those existing system header files is asking for trouble. Look for the change “Switch to VS2015 (v140)” change I made for VS2015 support here: https://github.com/henricj/audacity/commits/vs2015
I rebase that tree every once in a while since carrying a bunch of changes way behind HEAD is a pain and (AFAIK) no one else is tracking that branch. It is a little behind the official Audacity master since that tree was broken last I tried to update. Hmmm… It is still borked (as I type this): Travis CI - Test and Deploy with Confidence

I got both x86 and x64 building in VS2015 and the resulting binary works for what I’ve tested. I started trying to get the upstream nyquist to support 64 Windows, but then I ran into a perfectly evil issue with the sockets stuff (winsock uses “SOCKET” instead of “int” and those are different on Windows x64 since “SOCKET” is 64-bits wide whereas “int” is only 32 bits). This couldn’t shouldn’t be relevant for Audacity, but it did get me to make a head-shaped dent in the wall. That incomplete work is here: GitHub - henricj/nyquist: Clone of Nyquist's SVN repository.

I don’t recall if it caused problems with the VS2015 part or only with x64 builds, but the portaudio-v19 project has some command line stuff for building the ASIO and other files and re-linking after the normal MSBuild compile/link. I changed it to use MSBuild for everything. This avoids weird things happening if one, for example, changes build options or preprocessor defines in the UI and then forgets to edit the project file to make the same changes to command-line extra build stuff. It also means that the relevant files are not hidden and show up in the VS Solution Explorer.

Most of that is in portaudio-v19.vcxproj (there were some changes to the .filters file as well) and look something like this:

    <UseWdmks>
    </UseWdmks>
    <UseWasapi>true</UseWasapi>
    <UseWmme>true</UseWmme>
    <UseDs>true</UseDs>
    <UseAsioSdk Condition=" '$(ASIOSDK_DIR)' != '' And Exists('$(ASIOSDK_DIR)')">$(ASIOSDK_DIR)</UseAsioSdk>
    <UseJackSdk Condition=" '$(JACKSDK_DIR)' != '' And Exists('$(JACKSDK_DIR)')">$(JACKSDK_DIR)</UseJackSdk>
...
    <SdkPreprocessorDefinitions Condition=" '$(UseWdmks)' != '' ">PA_USE_WDMKS=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
    <SdkPreprocessorDefinitions Condition=" '$(UseWasapi)' != '' ">PA_USE_WASAPI=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
    <SdkPreprocessorDefinitions Condition=" '$(UseWmme)' != '' ">PA_USE_WMME=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
    <SdkPreprocessorDefinitions Condition=" '$(UseDs)' != '' ">PA_USE_DS=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
    <SdkPreprocessorDefinitions Condition=" '$(UseJackSdk)' != '' ">PA_USE_JACK=1;PA_DYNAMIC_JACK=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
    <SdkPreprocessorDefinitions Condition=" '$(UseAsioSdk)' != '' ">PA_USE_ASIO=1;$(SdkPreprocessorDefinitions)</SdkPreprocessorDefinitions>
...
    <ClCompile Include="..\..\..\lib-src\portaudio-v19\src\hostapi\asio\iasiothiscallresolver.cpp">
      <ExcludedFromBuild Condition="'$(UseAsioSdk)'==''">true</ExcludedFromBuild>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(UseAsioSdk)\common;$(UseAsioSdk)\host;$(UseAsioSdk)\host\pc</AdditionalIncludeDirectories>
    </ClCompile>
    <ClCompile Include="..\..\..\lib-src\portaudio-v19\src\hostapi\asio\pa_asio.cpp">
      <ExcludedFromBuild Condition="'$(UseAsioSdk)'==''">true</ExcludedFromBuild>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(UseAsioSdk)\common;$(UseAsioSdk)\host;$(UseAsioSdk)\host\pc</AdditionalIncludeDirectories>
    </ClCompile>
    <ClCompile Include="$(UseAsioSdk)\common\asio.cpp">
      <ExcludedFromBuild Condition="'$(UseAsioSdk)'==''">true</ExcludedFromBuild>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(UseAsioSdk)\common;$(UseAsioSdk)\host;$(UseAsioSdk)\host\pc</AdditionalIncludeDirectories>
    </ClCompile>
    <ClCompile Include="$(UseAsioSdk)\host\asiodrivers.cpp">
      <ExcludedFromBuild Condition="'$(UseAsioSdk)'==''">true</ExcludedFromBuild>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(UseAsioSdk)\common;$(UseAsioSdk)\host;$(UseAsioSdk)\host\pc</AdditionalIncludeDirectories>
    </ClCompile>
    <ClCompile Include="$(UseAsioSdk)\host\pc\asiolist.cpp">
      <ExcludedFromBuild Condition="'$(UseAsioSdk)'==''">true</ExcludedFromBuild>
      <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(UseAsioSdk)\common;$(UseAsioSdk)\host;$(UseAsioSdk)\host\pc</AdditionalIncludeDirectories>
    </ClCompile>

Ok, great. Now - is this to become part of the main git repository? or will it stay on your branch? Could have saved me hours, days even … if I"d known about it :slight_smile:
At the moment, I’m pulling directly from your git repos, via the VS2015 interface. I originally did a git clone, but now can use it directly - so if you make changes, I should see them directly. nice

Thanks for the heads up. Really appreciated.
Robert

Thanks, Henric. Robert had started a page on Audacity Wiki http://wiki.audacityteam.org/wiki/Building_Audacity_on_Visual_Studio_2015 about building with VS2015.

Is what I have written about your fork in the green div at the top of that page accurate?

Are you saying you have produced 64-bit builds of Audacity, or just solved problems building 32-bit builds of Audacity on 64-bit Windows?


Gale

Just having a look through henricj’s code on his github page, shown in the link posted just before, and am really happy to see that I was on the right track. A bit slower getting there but that’s ok. The one part I hadn’t yet looked into was the .vcxproj files. One or two others, but now I know I was on the right track.

Robert

Yes, I believe what you put on that page is correct. The only thing I might hesitate about is that there was a typo in the portaudio-v19 project file where ASIO_SDK was AISO_SDK (or something to that effect) that was fixed in a later commit.

As for 64-bit: yes, they are x64-targeted builds of Audacity that run as 64-bit processes and worked well enough for me to do my “rand()” ranting related testing back in February. Both the x64 release and debug builds worked fine for what I tested. Unfortunately, the gigantic change for 64-bit support is a) indeed gigantic (particularly in some libraries) and b) includes things that it turned out weren’t necessary. The first thing that comes to mind is that one shouldn’t mix Unicode and Multi-byte projects (not that MBCS should be used anymore); given that they are mixed, it is safer to use directly use the *A and *W variants of calls and structs and char/wchar_t (instead of TCHAR). That way, the code always means the same thing, regardless of the Unicode/MBCS settings. I tried to change things to always specify the types explicitly. However, it turned out that those changes were probably not required for x64 to not blow up when run.

Note that I used the v140_xp build only for Win32/Release and v140 for everything else. I figured there were never all that many WinXP x64 installs to begin with, and the folks asking for that kind of bleeding edge trouble would not be the ones sticking on XPx64 when later versions of Windows became available. wxWidgets’s master branch–and then wxWidgets 3.1.0 when it was released–were used since that’s when they added VS2015 support.

Be aware that the vs2015 branch adds a .gitattributes to specify EOL behavior. I’m no git expert, but I was having trouble between Windows and Ubuntu when testing. That does mean there are some EOL differences between master (which is identical to the official Audacity master branch) and the vs2015 branch. (Stuff like “git merge --strategy=recursive --strategy-option=renormalize master” seems to sort it out properly.)

One good thing about some of the changes: MS has been trying improve their standards support and many changes remove work-arounds for previous MSisms that are now no longer needed (e.g., they now provide stdint.h and inttypes.h).

TL;DR: Yes Audacity x64 platform binaries run, but some of the changes in the x64 commit are not required and others are quite intrusive (e.g., libnyquist).

You’re welcome.

It seemed responsible to pursue upstream library changes before pushing things further in Audacity (which lead to the aforementioned wall dent). Also, since my goals at the outset were more focused on exploring VS2015’s x64 than directly producing pull-request appropriate changes, there is a bit of work to disentangle required changes from unrelated or needless changes (one of the steps I took to identify x64 issues was have the compiler barf on every implicit integer conversion that involved a pointer and then fix them; some of those changes would fix trouble, but some would not). When I brought this stuff up before things got a bit sidetracked (also, Audacity 2.1.2 was pending and wxWidgets did not yet support VS2015).

The changes needed to get 32-bit VS2015 builds working should not be too hard to get into pull-request suitable form. If VS2013 provides stdint.h and inttypes.h, then deleting the local versions would be enough; if not, then moving them might be more appropriate than what the vs2015 branch does.

I’ve been merging/pushing Audacity master branch changes about once a week, but I’ll avoid doing the “git rebase -X ignore-space-at-eol master” thing if others are tracking this. I’ll hold off doing so again until travis is happy (I saw the same problem with Visual Studio).

It’s looking good for 32bit VS2015. That’s actually working here. Lots of “Warnings” to wade through - but if you are still making corrections/additions and plan on then merging it with the Audacity Master, then I won’t pursue my version here much further. No point in us both doing the same thing and you are way way ahead of me on this. I only started looking at the code a week or so ago.
x64 builds will be nice, and it does that as well, although I initially forgot to build an x64 wxWidgets… Doing a 'git ‘pull’ on wxWidgets is showing quite a few changes too, which is interesting.
I’m not too sure how that relates to those early Audacity patches of wxWidgets-3.0 as I haven’t had a look yet. I commented out the bit of code in Audacity and haven’t got back to it. So a build just now for the x64 version shows 0 errors and 17 warnings. For the DLL Debug. For the DLL Release, x64, 0 errors, 18 warnings.

I like your ideas in paragraph 1 above. Good planning. So with 32bit VS2015 pretty much there then it’s well on the way. A 64bit release will make a lot of people happy, and that too is as good as working.

Which leaves me to ask, as you merge with the master on a regular basis - I’m wondering if I should leave this VS2015 version alone for now, as you are obviously well ahead on it, and go back to working on the OSX 10.11.4/10.11SDK version, where I started … hmmm. Although I’ll still keep digging away at all those “warnings” that show up, but again at the risk of them being fixed in part by changes in the master anyway.

… and for what it’s worth just now, a x64 build of Audacity Debug shows 0 errors, and 837 warnings :slight_smile:
and Audacity x64 runs - apparently - fine. Although I haven’t done any testing at all on it … but it runs. Nice one.

interesting stuff
Robert

Out of interest, yesterdays update/merge of henricj’s repo to the Master, doesn’t yet compile cleanly on VC2015. It’s almost there. There are 101 Errors - every single one Error C1189, and found in 4 components. libnyquist, nibnyquist, libsndfile, lv2 and the last error a LINK error in Audacity because it can’t find the others.
There are 769 Warnings. Some related to C1189, most not.
The details of compiling with VS2015 are to be found on henricj’s github site.
But then I guess you all know this.
Robert

Errr… what errors? Are you talking about some of my repo’s changes in your tree or my fork being borked (it compiles for me w/ VS2015 Update 2)?

Most of the warnings should be about possible integer truncation issues (e.g., a size_t assigned to an int).

It seems reasonable to distinguish between warnings about things that are already present in the tree that are showing up with VS2015 because the warning defaults have changed (or because the new compiler is more capable of detecting things) and warnings related to what has actually changed. I’m not suggesting that warnings be ignored, but that they be triaged appropriately (the point is to fix the problems that cause the warnings, not to keep the build output short by using a compiler version or configuration that hides them). Well, within reason: mandating gcc with -Wall -Wextra -Wpedantic -Werror on an existing codebase can be used to encourage people to seek alternate employment.

For moving forwards, what will be the earliest supported version of Visual Studio? The way I made the changes in my tree, only VS2015 will work. To support building with both v120 and v140, it seems simplest to have separate v120 and v140 solution and project files. One can do that by hand or use CMake or such. Alternately, wxWidgets includes a file called “wx_config.props” from their .vcxproj files that sets the toolset to the latest version supported by the running Visual Studio:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="Configuration">
    <UseOfMfc>false</UseOfMfc>
    <CharacterSet>Unicode</CharacterSet>
   <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '10.0'">v100</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '11.0'">v110</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '12.0'">v120</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '14.0'">v140</PlatformToolset>
  </PropertyGroup>
</Project>

This avoids having duplicate project files and having to manually keep them in sync, but folks should probably be comfortable with VS project files that have non-default things in them. I’ve never had a problem with Visual Studio getting confused by customized project files, but developers can get thrown for a loop if Visual Studio doesn’t behave the way they expect (e.g., in the case above, if a developer tries to set the character set or platform toolset in the project configuration UI, they may be in for a surprise).

It would have been much easier had Microsoft’s 64-bit API used 64-bit longs like just about everybody else…

I like the wxWidgets idea. vs10, vs11, 12 13 14 etc. Keeps it all together on the front end and makes it easy to manage. Anyone wanting to do a specific compile is going to look at what’s needed. Or they should.

For moving forwards, what will be the earliest supported version of Visual Studio? The way I made the changes in my tree, only VS2015 will work. To support building with both v120 and v140, it seems simplest to have separate v120 and v140 solution and project files. One can do that by hand or use CMake or such. Alternately, wxWidgets includes a file called “wx_config.props” from their .vcxproj files that sets the toolset to the latest version supported by the running Visual Studio:

ah yes, the joys of using Microsoft for anything …

It would have been much easier had Microsoft’s 64-bit API used 64-bit longs like just about everybody else…

although Apple of course have their little crazies. As does just about everyone else. Standards are wonderful things. So many to choose from…

but that they be triaged appropriately (the point is to fix the problems that cause the warnings, not to keep the build output short by using a compiler version or configuration that hides them)

Totally agree, which is what I have started to do, but, see point 1. just below.

So interestingly, coming back to what to support in terms of versions used to build. The cleanest solution is probable the wxWidget method. That way, a person wanting to build, is going to have the same options in wxWidgets and Audacity, at the beginning. Simplifying the whole process really. I think anyway.
Of course the end result is a program with two builds ideally. One for x32 bit Windows systems, (rapidly fading from use), and one for x64 systems, now the defacto “standard” - there’s those standards again! The END USER, lets not forget them, then has the choice. They don’t care how it was built, so long as it runs on their system.
Now I have, myself, two possible directions of progress here.

  1. Do I leave the VS2015 tree alone now, and leave it in your very capable hands. There’s little point as I see it in me chasing out those Warnings, when your work will probably clear most of them anyway as you refine your own tree. Then any pull on my part will simple overwrite what I have done here. Not to mention the duplication of effort. So I will probably leave it alone now, as it works. Although if you tell me that pursuing the Warnings is not high on your list, I might crack on with it anyway?.
    or
  2. Do I go back to my first love, OSX, and continue the rather hopeless task of trying to make it all work in the XCode 10.11+10.11SDK - and try and ensure that it’s transparent enough - if I get it that far, to transition smoothly to the next releases - coming soon to an Apple store near you.!
    At present, it’s build-able apparently with previous SDKs, a bit like Windows and earlier VSxxxx versions, but like the VS2015 exercise, I would like to see it come off the command line, nice and easy as it is, and onto the GUI, using the latest tools. I haven’t spent a lot of time on it at the moment. The command line build is still failing using the latest SDK but I know about all that. and of course the XCode gui interface build is not even getting started, although it tries valiantly. So I’ll probably continue pursuing that course just out of interest. Unless I discover of course, that someone on the actual team is/has doing/done it already.

Robert

The main complication here is testing multiple versions. I have VS2013 and VS2015 readily available. I can probably dig up VS2012 and perhaps even earlier to test with, but at some point one needs to decide what should be supported (and there is a limit to the Visual Studio bloat that will fit on my laptop’s SSD). This ties into changes that may require #if _MSC_VER > x or #if _MSC_VER < y treatment as well. One can leave in unsupported cruft and hope that it works, but one also needs to have supported platforms so one knows what must be tested.

Yes, an auto-configuring .props file is probably is the best way to handle this.

I’m not sure how fast 32-bit Windows is fading. Many of those low-cost 2-in-1 Windows systems are using 32-bit Windows 10; it saves disk space compared to x64 and they typically only have 32GB of storage. Besides, there are still plenty of 32-bit WinXP boxes out there (ouch…).

My suggestion would be to support VS2013/v120 and VS2015/v140_xp for development. A 64-bit VS2015/v140 build would be a separate project after integrating 32-bit VS2015 support. Such a proposed audacity_config.props could already include a check for 64-bit builds, but putting all the other required changes into the same pull request would make for one monstrous pull request

I’d suggest breaking things down this way:

  1. Create a minimal pull request to add 32-bit VS2015 support using a .props file. The project files all get modified to include the new .props file and a VS2015 .sln file. stdint.h and inttypes.h need to be dealt with (the best way to do so is TBD). There would also be some #if changes, I think. (Do the portaudio-v19 project changes deserve their own pull request? This would replace the second compile/link batch file with MSBuild conditionals.)
  2. Create pull requests for fixing any new 32-bit VS2015 warnings (i.e., ones not produced by VS2013). Trivial ones would have been dealt with in the previous step.
  3. Create pull requests for resolving VS2015 issues in the code. This includes things like not using “long” to try to store pointers. This is “wrong” on all platforms and various compiler flag can probably be used to create warnings on all the platforms, but should only cause runtime trouble for x64 Windows builds. My preference is to use the standard types, and add compatibility gunk where required (e.g., an “intptr_t” is for storing a pointer in an integer, not some custom “audacity_intptr_t”). This would probably result in a number of pull requests along the lines of “Use intptr_t instead of long” and “Don’t try to store size_t in an int”, instead of a single massive “Make Windows x64 work”.
  4. Create a pull request to add the x64 platform to the VS2015 solution and project files.

That is a bunch of work and while I can certainly start down that path, I’d like to have some “buy in” from the Audacity team that this is the way to go before wasting anyone’s time. An official, “these will be the supported versions of Visual Studio,” statement would be particularly desirable. Some of the changes in the second step will probably require non-trivial changes to some of the third-party libraries. That carrying such changes in the Audacity tree is worth it for Windows x64 support is not for me to decide (I did feed what I think are the minimal x64 changes to the nyquist maintainer a few weeks ago). Fixing “safe” warnings in the third-party libraries is another policy matter. One can live with such warnings, suppress them on a per-project basis, or fix them and carry the resulting diff while trying to get such changes integrated into the upstream distribution.

Removing compatibility gunk related to old versions of Visual Studio is another point where some guidance would be appreciated. Maintaining existing complex #if/#else trees around for the benefit of unsupported compilers while modifying those structures anyway seems undesirable. I’m not sure how much there is to worry about, but I know there are some. Making sure that VS2013 and VS2015 work is much simpler than adding support for a new MS compiler while trying to make sure that nothing changes for older, unsupported MS compilers. The former would be tested by the relevant compilers; the latter requires the programmer to correctly emulate the old preprocessors in his or her head.

I haven’t had the “pleasure” of dealing with XCode myself. There have been some rants I’ve run into about their poor backward compatibility support. Is it really that bad? Most people seem to be complaining that one might accidentally use an API not present on an earlier platform, but it seems it should be pretty simple to examine the resulting binary for weak symbols (“objdump” shows them as “w” symbols, no?).

As for where you should focus your efforts, I would think that the next thing do would be to wait to get some feedback from the Audacity folks. I can add you as a committer to my GitHub fork if you want to take a stab at fixing warnings and such. I don’t have a Mac to test on so I have no idea if my fork has broken anything there (I do occasionally test it on Ubuntu).

I think I can create a pull request for the minimal, 32-bit VS2015 support in a day or two along the lines describe above, if that is the direction the Audacity folks would like things to move.

The points you make above, 1, 2, 3 and 4 are very valid. And yes, it’s a bunch of work. That’s for sure.
I’m beginning to think that the “supported compilers” could well be narrowed down a bit in any case.
As for this (our) focus area, probably reducing the list to VS2013, and VS2015 builds for Windows platforms would work as I think you suggest. That’s practically everything working for the VS2013 and prior people - come on guys, upgrade even… - and the newer build dragging their feet into the 21st century with VS2015. Keeping in mind that VS2015 is actually VS2014 ??? Very strange. But I guess if you are going from Windows 8 to windows 10, a Release Number jump is now the new black… Who knows.

So long as a binary can be compiled for each of the (windows) platforms, users will be happy.
Win-32: Windows 98 up to Windows 10
Win-64: Windows 8 and above
I mean there has to be a cut off point somewhere, otherwise programmers are still trying to compile versions for the 6 Windows 98 users left…

and why would one stick with the old compilers when VS2015 Community is free, along with the SDK’s etc. Free as. I fail to see the reasoning. Any programmer worth their salt will surely want to update to the latest gear. Maybe that’s just me?
Especially considering as VS2015 builds for either 32 or 64.
So it’s down to the source code again, to put in the switches.

Now, I had a look this morning. Pulled a fresh copy from your github repo, and build the x64 Debug version. I started at the top of the list of Warnings, and went hunting.
It’s painstaking, but not difficult. I started by watching for the platform and inserting _int64 where it may work better. It certainly stops the warnings in those 2 sections.

Example.
Beginning line 36 in id3tag.h, for this one. Removed the first warnings. Using a couple of handy defines in case I need them later. (code from Stackexchange)

typedef unsigned char id3_byte_t;
// Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

// Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

//typedef unsigned long id3_length_t;

… and because there are also declarations in the .c files - like as in file.c

Beginning line 213

 /* check for duplication/overlap */
  {
	  // Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
	  _int64 begin1, end1, begin2, end2;
#else
#define ENVIRONMENT32
	  unsigned long begin1, end1, begin2, end2;
#endif
#endif

	  // Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
	  _int64 begin1, end1, begin2, end2;
#else
#define ENVIRONMENT32
	  unsigned long begin1, end1, begin2, end2;
#endif
#endif
    //unsigned long begin1, end1, begin2, end2;

So it looks like working through the .c files may be the big mission for this. I can’t see any other way of getting around - globally in a .h file, the problem of declarations in the .c files. Maybe I’m wrong.
anyway, we’ll see what happens. I am happy enough at the moment to just potter along here. I may put this all into my own repo, rather than get involved with commits to the master.

Robert

What about Mac OS X and Linux?

The next release will probably be the final release that officially supports Windows XP and Snow Leopard.

Thanks Steve. Yes, I haven’t forgotten OSX and Linux :slight_smile: I’m looking at OSX here as well. Just been working along on VS2015 and talking to henricj about it all. He has a good handle on the VS2015 stuff, and it compiles now for x32, and x64, both Debug and Release, on Windows 10. Well probably others as well, but that I don’t know… But, I don’t think he is ready to commit it yet until he’s talked to you guys. Although he may have done that already - given the time zone differences we are dealing with. Also there are a lot of Warning messages to deal with yet as well - 807 as I look at my monitor now. All of them clashes between various levels of C/C++ and what ever some of it is.

So actual development on OSX is interesting. The command line build although not working with 10.11.4 and 10.11SDK can probably be done. Building it in the XCode IDE/GUI is another matter, but I will keep exploring that option myself, just out of interest. If it can’t be done, it’ll take me a week or so, if it’s absolutely impossible, perhaps then a month…

Nice to hear that XP and Snow Leopard are planning a retirement party -

Robert