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