Changed the two IsWin9x() functions to always return false.
Eventually we'll want to roll this up, removing the Win9x branch
of the code that called these.
This updates GenericEntry's filename handling to be more careful
about Mac OS Roman vs. Unicode. Most of the work is still done with
a CP-1252 conversion instead of MOR, but we now do a proper
conversion on the "display name", so we see the right thing in the
content list and file viewer.
Copy & paste, disk-to-file-archive, and file-archive-to-disk
conversions should work (correctly) as before. Extracted files will
still have "_" or "%AA" instead of a Unicode TRADE MARK SIGN, but
that's fine for now -- we can extract and re-add the files losslessly.
The filenames are now stored in CStrings rather than WCHAR*.
Also, fixed a bad initializer in the file-archive-to-disk conversion
dialog.
Most of this change is a conversion of the old FileDetails struct
into a new LocalFileDetails class. The new class keeps the
members private, and keeps the Unicode and MOR representations of
the string separate.
The NuFX and DiskImg libraries don't support UTF-16 filenames,
so we stil can't add files with non-CP-1252 filenames, but we're
a step closer.
Also, update NufxLib with a couple of fixes from the main project.
Also, fix handling of "%00" when adding files.
Also, mark most of the A2FileDOS fields private. Not sure why
they weren't.
Officially the \u value is signed 16-bit decimal, but we were treating
it as unsigned. The Windows parsers handled it anyway, but it's best
to do what the spec says.
This tweaks the output for AWGS and Teach Text to convert from Mac
OS Roman to Unicode, rather than Windows code page 1252.
It would be slightly more efficient (and possibly a bit more legible
in the RTF file) if we left the "good" conversions alone, e.g.
continue to use the CP1252 character for "E with acute", instead of
converting to U+00C9. That might leave us at the mercy of the code
page converter in some random RTF reader, though, so it's probably
best to just use the official Unicode values.
The file extraction dialog allows you to select file parts, so you
can choose to exclude resource forks or just extract disk images. If
you don't choose any parts, nothing will extract, and you get a
confusingly generic message about nothing matching the criteria.
This adds a specific error message for the case where no parts are
selected.
DeployMaster can detect whether or not CiderPress is currently
running by checking for the presence of a window with a specific class
name. The default class name is generated differently each time, so
we need to set a custom class name.
Also, bumped version to 4.0.0d2.
The static analyzer was annoyed that the return value from calls to
CString::LoadString() was being ignored. This adds a wrapper
function that checks the value and logs a failure message if the
string can't be found.
For some reason there was a "minimum version" with no "subsystem".
I'm not really sure what this is all about, but all the other
projects have this value, and it seems happier now.
The DeployMaster installer issue prevents the user from seeing more
than nine of the 18 file extensions that CiderPress wants to handle,
and I don't want to go stomping on file associations without some
way to disable the behavior. So this returns to the previous behavior,
where CiderPress directly manages the file associations.
The CiderPress app is not able to modify HKEY_LOCAL_MACHINE (which
it used to do via HKEY_CLASSES_ROOT) on recent versions of Windows --
tested in Win7, but it probably broke with Vista. So now we do
everything in HKEY_CURRENT_USER. This works, more or less.
We're not looking at the Windows shell overrides, which are made
in yet another set of registry entries, so there are multiple
reasons why the values reported by the Edit Associations dialog may
now be inaccurate. I still favor eliminating the dialog as a
long-term strategy.
I took the opportunity to do some code cleanup in the registry code.
I also added calls to SHChangeNotify() to tell the Windows shell when
file associations change, so Windows Explorer windows get updated
promptly.
The Gutenberg_Jr1_f1.dsk image wasn't recognized, so I fiddled with
the code a bit. Still doesn't look quite right, and I don't really
know anything about Gutenberg disks, so I'm leaving the new version
disabled for the moment.
This ports the contents of ReadMe.htm to Markdown, splitting the Linux
information out into a separate file. Specific instructions for
building the Linux utilities are now included.
Many updates to format strings, largely as a result of changing
various "long" variables to uint32_t.
Fixed the diskimg debug macros for gcc, which requires an extra
"##" to remove the "," when there are no arguments. (Apparently
Visual Studio just strips this away for you.)
Stripped out a couple of dead variables spotted by gcc. Return
the actual error in a couple of HFS file functions.
In the past, CiderPress managed its own file associations. This is
the feature that launches CiderPress when you double-click on a ".shk"
file. The installer ran "CiderPress -install" and "-uninstall" during
installation and removal to give CP a chance to establish and clean
up the necessary registry entries.
The code built with VS6 works fine. The code built with VS2013 fails
with an access denied error. It appears there have been some access
policy changes, and the older code is getting "grandfathered in". This
is really something that the installer ought to be handling, though,
so rather than figure out how to fix CiderPress, I'm removing the
file type association code from CiderPress and letting DeployMaster
handle it.
This may be slightly less convenient for anyone who had reason to
change type associations frequently. Modern versions of Windows have
relatively easy to use control panel UIs for adjusting types, and
the "advanced installation" feature of DeployMaster allows you to
un-check the types that you don't want to have associated with
CiderPress.
(...with one minor hitch: DeployMaster 4.2.2 only shows the first 9
associations, and CiderPress has 18.)
This change renders most of the registry-handling code obsolete, as
well as the "-install" / "-uninstall" handling. I'm 99% sure I want
to go this way, but I'm keeping things #ifdefed rather than deleted
for the moment.
Some of the code was mis-handling wide character filenames.
A direct copy & paste should be using the 8-bit form of the filename,
but that's a deeper fix.
Also, changed some types to use explicit integer width specifiers.
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.
The original version of CiderPress used a WinHelp help file, built
with an application called HelpMatic Pro. This app used a proprietary
format, and had no facility for exporting to "raw" HPJ + RTF files, so
I decompiled the HLP and imported it into HelpScribble.
Using HelpScribble, I cleaned up the help file formatting a little,
fixed up the table of contents, and exported as "raw" HtmlHelp (HHP,
HHK, HHC, and a whole bunch of HTML). I also split the pop-up help
text, which isn't supported by HelpScribble, into a separate text file
that Microsoft's HTML Help Workshop understands.
I'm checking in the files that HTML Help Workshop needs to generate a
CHM, so anyone can update the help text. I'm also checking in the CHM
file, rather than adding the help workshop to the build, so that it's
not necessary to download and configure the help workshop to build
CiderPress.
This change adds all of the updated help, but only updates the Help and
question mark button actions for one specific dialog. A subsequent
change will update the rest of the dialogs.
This change is essentially upgrading us from a totally obsolete help
system to a nearly-obsolete help system, but the systems are similar
enough to make this a useful half-step on the way to something else.
The code will centralize help activation in a pair of functions in the
main app class, so any future improvements should be more limited in
scope.
This also adds a build step to copy the CHM to the execution directory.
The NufxLib and diskimg libraries want narrow strings for certain
things, notably for the "storage name", i.e. how the name will appear
on the disk image or in the file archive. We need to convert from
Windows UTF-16 to an Apple II filesystem-specific 8-bit character
representation.
We used to just pass narrow strings all the way through, so we didn't
need any intermediate storage to hold the conversion. Now we do. In
some cases there's nowhere good to put it. The initial UTF-16
conversion changes just dropped in some place-holder strings.
This corrects the behavior, though in a couple of cases we're adding
kluges on top of code that was already badly bent from its original
intent (as initially conceived, CiderPress wasn't going to handle disk
images, just ShrinkIt archives). It's not pretty, but it should work
for now.
This adds a replacement for the SelectFilesDialog class. It has
been updated to use Explorer-style dialogs, which are a bit nicer
than the old-style dialogs. Hopefully this will eliminate some of the
brain damage, like the disappearing Accept button.
This change only updates MDC. A second change will update the main
app and remove the old code.
Also, updated the MDC version to 3.0.0, and changed the web site
linked in the Help menu from faddensoft.com to a2ciderpress.com.
Focusing on the diskimg library this time, which deals with a lot of
filesystem structures that have specific widths.
This is still a bit lax in places, e.g. using "long" for lengths.
Should either specify a bit width or use di_off_t.
Also, added "override" keyword where appropriate.
Also, bumped library version to 5.0.0.
The OpenImage method had an overload that took void*. This turns out
to be a bad idea, because void* matches any pointer type that didn't
match something else. So the WCHAR* filenames were going to the "open
from buffer" method rather than the "open from file" variant.
A less important issue is whether open-from-buffer should take a const
or non-const pointer. If the "readOnly" boolean flag is not set, then
the contents can be altered and const is inappropriate. The best course
seems to be to drop the boolean flag as an argument, and just have two
different methods.
