YAXBPC v2.3.3

Some UI tweaks, some setting system (save/load) improvements, and misc.

YAXBPC v2.3.2

This release brings the following changes:

• Added an option to save source/target/output forms in Create Patch tab.
• Added option to skip alternative scripts when creating patches.
• Temporary filenames switched to .tmp to avoid the tiny risk of destroying YAXBPC's own files.

YAXBPC v2.3.1

After a few hours trying to get a clear answer why xdelta3 has problems with some (not all) unicode filenames in Windows but works perfectly in Linux with any filenames, I found the elephant in the room: xdelta3 doesn't have proper unicode support.

In Linux, Unix, Mac OS, and the like, command-line options (filenames included) are passed to xdelta3 in UTF-8 encoding (byte array). xdelta3 receives them as is, uses them as is to access files, stores them as is in vcdiff file header, loads them from vcdiff file header as is, displays them as is. The filenames are not transformed/encoded/decoded/whatever-ed at all. UTF-8 is an Unicode encoding, supporting all characters. So, everything works fine, unicode or ascii or whatever. Nothing special is required. You can say it just happens to work.

In Windows, command-line options are passed to xdelta3's main (int argc, char **argv) in Microsoft Windows Codepage 1252 (also byte array). xdelta3 also receives/blablah-s them as is. The filenames are not transformed/etc-ed at all. However, cp1252 only supports a small set of character (see here http://www.ascii.ca/cp1252.htm ). All characters in path/filename not supported in cp1252 will become either question marks (?) or equivalent cp1252 character if available (like full-width ＜＞：＂／＼｜？＊ becomes ascii <>:"/\|?*). Unicode filenames are doomed.

For Unicode support in Windows, xdelta3 needs a new wmain(int, wchar_t**) to receive command-line options as wide char (UTF-16), and then uses the unicode versions of IO API like CreateFileW, etc. This has been requested years ago here jmacd/xdelta#89

It is (not) funny that I have already seen it and then forgotten it completely.
Oh well.

This release brings the following change:

• Applying the you-know-what workaround whenever there're any non-cp1252 characters, not only ＜＞：＂／＼｜？＊, in filenames, to improve Unicode support in Windows.

YAXBPC v2.3.0

This release brings the following changes:

• Linux scripts now properly run on FreeBSD and other Linux-like and Unix-like OS. Previously, the bundled Linux binaries had been be used by default without checking if they can really run, so patch would only work if the platform is Linux on x86 or x86_64 or FreeBSD with full Linux compatibility and wouldn't work on a default FreeBSD instalation, with or without xdelta3 package. Now they're only used in Linux on x86 or x86_64. In other cases, the system's xdelta3 binary is used. This has been tested on FreeBSD 10.3.
• Mac script now only runs xdelta3_mac on OSX 64-bit. Because it's a 64-bit binary and so won't run on 32-bit OSX. The last 32-bit OSX version is 10.6 (Snow Leopard) is already quite old, but Apple still supports it. If you're still on these old systems, please install xdelta3 package.
• All scripts: do not move old files if do_not_move_old_file.txt exists in patch directory. Use this if you don't want the patch to move your files.

YAXBPC v2.2.3

This is a minor maintenance release. If you're on any version older than v2.2.2, you're strongly recommended to update to this.

Changes from v2.2.2

• Added version info in how_to_apply_this_patch.txt to track usages. I should have done this since the first release.
• Added an unimportant and mostly useless option to force YAXBPC to always make temporary copies of source files when creating/applying patch (the trick mentioned below). It will do it when needed, normally. This option might be useful when your files have weird characters in their names.

Changes from v2.1.0:

• Trick to handle files with any of ＜＞：＂／＼｜？＊ in filename as xdelta3 in Windows can't access them.
• PowerShell applying script as the default code path in Windows for better stability and compatibility.

YAXBPC v2.2.2

Changes from v2.1.0:

• Trick to handle files with any of ＜＞：＂／＼｜？＊ in filename as xdelta3 in Windows can't access them.
• PowerShell applying script as the default code path in Windows for better stability and compatibility.

See changelog of beta versions or commit messages for detail.

YAXBPC v2.2.1-beta

This version brings a new enhancement: PowerShell applying script as the default code path in Windows.

PowerShell is installed by default in Windows 7 and later. It has native Unicode support and should work in a more consistent and reliable way than normal Windows shell.

Users should still run apply_patch_windows.bat as usual. If PowerShell is installed (in default location), it will switch to the subscript. Otherwise, the normal legacy code path is used.

Incidently, this makes the main applying script with non-ascii filenames work in Windows XP and Vista. This never happened before as cmd.exe stops executing script when the codepage is 65001 (utf-8), which is required. Note that PowerShell must be installed manually in these operating systems.

The downside is that the patch will be a bit slower, as PowerShell's initialization can take up to a few seconds.

Other changes are some improvements to the trick in v2.2.0-beta and some UI tweaks.

YAXBPC v2.2.0-beta

xdelta3 in Windows, as of v3.0.11, can't access any file with any of ＜＞：＂／＼｜？＊ in filename. Even though these are full-width (fixed-width) characters, not the forbidden ASCII ones, so valid for filenames.
This test release pulls a simple trick to handle these files.

YAXBPC v2.1.0

This is a bugfix release:

• Fixed a bug that might break Windows script with ASCII filenames. This bug appeared in v2.0.0.
• Users now can drag and drop source file on applying scripts to apply patch. Source file can be anywhere, unrelated to the patch's location.
• Misc bugs.

YAXBPC v2.0.0 (DO NOT USE)

First release after two whole years...

• The experimental long path support for Windows 7 and earlier is removed. Getting that support was fun and very educational but it is practically useless and overcomplicated the codebase.
• Linux & Mac scripts: sh support is returned.
• Applying patch: allow users to specify only the delta file; source file and target file are optional (only works with some delta files which are created with this usage in mind).
• Better error handling.
• Funny mode is more fun and less trolling.
• Various bugfixes and tweaks.