The test for "is this an S-C Assembler source file" tried to
dereference a null pointer when asked to examine a file with a
zero-length data fork. The test only fires for files with type=INT
and auxType=0, so this is pretty hard to hit. The specific failing
case had a damaged file with the appropriate file type.
Issue #42
The ProDOS code was assuming that the volume directory was 4 blocks
long. Some disks, such as the ProDOS 2.4.2 distribution disk, only
use the first two blocks. CiderPress now scans the volume directory
to determine the actual length.
Fixes issue #32.
VERSION=0/1/2 corresponds, simply, to v0/v1/v2, where v0 was only
used for some older 8-bit Orca/M stuff. v2.1 can be detected by
looking for the optional "tempOrg" field.
Also, allow the disk version number to be set to zero in 2IMG images.
When extracting files, you can ask CiderPress to add a file extension
by checking the "add file extension" box. Whether or not this box
is checked, files that undergo a format conversion (e.g. AWP to RTF,
or SHR to BMP) have a file extension added to identify the file's
new format.
This turned out to be confusing and inconvenient at times, notably
when working with Merlin source files. See issues #10 and #26 on
github for details.
CiderPress no longer adds file extensions to format-converted files
unless the "add file extension" box is checked. (The "Configure for
easy access in Windows" button checks this box for you, so the
default behavior is still "safe".)
Also, fix a minor visual glitch in the extract dialog.
Also, update to version 4.0.3-a3.
AppleWorks 5 added inverse text and MouseText. We can handle inverse
text with RTF features, and convert MouseText to something vaguely
similar in the Unicode symbol set.
32-bit * 32-bit = 32-bit, so disk images with partitions whose size
exceeded the capacity of a 32-bit int were coming out wrong.
Updated version to 4.0.3-a1.
The file viewer was seeing zero-length formatted output and assuming
that it was the result of zero-length input. This is a problem
because the code disables the format options when there's nothing to
format. This resulted in the strange behavior noted in issue #14.
Now the "is source empty" value is passed explicitly, and we display
a different message when the formatter fails.
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.
The field wasn't being initialized, so if you did things in a
certain way (open a .SDK as a ShrinkIt archive, double-click on
the disk image, then view an AppleWorks AWP document), the flag
might be initialized to "false" and you'd lose the formatting.
The code was mis-handling semicolons embedded in macros, treating
them as the start of a comment. It now checks to see if they're
at the start of a line or preceded by a space.
The 1.0 edit control only searched down, so the fact that CP was
misconfiguring the search request didn't matter. This change fixes
the search parameters and enables bi-directional searches.
DiskCopy disk images on HFS volumes, such as the ByteWorks Opus ][
CD-ROM, have resource forks. The double-click handler was screening
out forked files, so double-clicking on one of these disk images
was popping open the file viewer instead of creating a new instance
of CiderPress.
Ideally there would be a preference that allowed you to enable
logging and specify the file's location. That could make remote
debugging of certain problems easier.
With a bit of hex-editing it's possible to embed carriage returns
in REM statements. The reformatter wasn't handling that well. The
new output matches what LIST generates.
The output generated cannot be imported by the text-to-BASIC
importer because it doesn't understand the blank lines. The output
generated before this change didn't work either, though that was a
bit harder to figure out because the CRs are harder to see in Windows
than CRLF.
It should be possible to teach the importer to handle such files,
though I think these files are pretty rare -- I happened to find
them in some Peter Watson freeware.
