When initially opened in Visual Studio 2015 Community Edition, the
project was updated to use the v140_xp toolset. When the program
was run under WinXP it complained about a missing runtime DLL. When
the DLL was provided, it complained about another one (with a
slightly strange name). So I reverted the tools to v120_xp, i.e.
Visual Studio 2013. (I don't know if this works because the tools
are included with VS2015, or because I have VS2013 installed and it
managed to find them.)
Whatever the case, it now builds for me with either IDE, and seems
to work fine on Windows XP, but I'd like to figure out why the XP
build isn't working with the v140_xp tools.
We weren't doing a MOR-to-UNI conversion on the sub-volume name, so
HFS volumes with non-ASCII characters didn't look right.
This also relocates the character-conversion code to a new source
file. It's currently part of the reformat lib, though it arguably
belongs in util (but that would introduce a new dependency
between reformat and util).
This changes the Platform Toolset configuration from "Visual Studio
2013 (v120)" to "Visual Studio 2013 - Windows XP (v120_xp)". Without
this change, executables built by VS2013 will not run on WinXP.
To actually run on WinXP, we also need to install the redistributable
msvcr120.dll and mfc120u.dll, both of which are fairly large. The
installation package has more than doubled in size.
At some point we may want to drop WinXP support -- Microsoft declared
end-of-life on April 8 2014 -- but if the only penalty is a 2MB increase
in installer size, we might as well keep supporting WinXP users.
There's probably some value in using the "secure" versions of the
various string functions, but I don't want to deal with it right
now. We won't use them for the stuff that builds under Linux
anyway (diskimg, nufxlib).
This largely eliminates warnings from VC++.
CiderPress and MDC now compile, and execute far enough to open
their respective "about" boxes, but I doubt they'll do much
more than that.
* Switch from MBCS to UNICODE APIs
Microsoft switched to UTF-16 (by way of UCS-2) a long time ago,
and the support for MBCS seems to be getting phased out. So it's
time to switch to wide strings.
This is a bit awkward for CiderPress because it works with disk
and file archives with 8-bit filenames, and I want NufxLib and
DiskImgLib to continue to work on Linux (which has largely taken
the UTF-8 approach to Unicode). The libraries will continue to
work with 8-bit filenames, with CiderPress/MDC doing the
conversion at the appropriate point.
There were a couple of places where strings from a structure
handed back by one of the libraries were used directly in the UI,
or vice-versa, which is a problem because we have nowhere to
store the result of the conversion. These currently have fixed
place-holder "xyzzy" strings.
All UI strings are now wide.
Various format strings now use "%ls" and "%hs" to explicitly
specify wide and narrow. This doesn't play well with gcc, so
only the Windows-specific parts use those.
* Various updates to vcxproj files
The project-file conversion had some cruft that is now largely
gone. The build now has a common output directory for the EXEs
and libraries, avoiding the old post-build copy steps.
* Added zlib 1.2.8 and nufxlib 2.2.2 source snapshots
The old "prebuilts" directory is now gone. The libraries are now
built as part of building the apps.
I added a minimal set of files for zlib, and a full set for nufxlib.
The Linux-specific nufxlib goodies are included for the benefit of
the Linux utilities, which are currently broken (don't build).
* Replace symbols used for include guards
Symbols with a leading "__" are reserved.
This updates the project files for Visual Studio 2013, and removes
the old Visual Studio 6 (1998) project files. The update tool had
a number of complaints (see UpgradeLog.htm) that may need to be
addressed.
Also, replaced .cvsignore with .gitignore.
Visual Studio reports 1886 build errors, nearly all of them due to
the switch from MBCS to Unicode. The former is no longer
supported "out of the box", and its use is discouraged, so we're
going to bite the bullet and use wide characters in the UI.
