WinMerge.exe is ANSI executable which works in all 32-bit Windows systems. It does not have Unicode support.
Internally, it stores only ANSI characters (256 possibilities). If you open an Unicode (65536 possible characters) file, the characters must be converted to the ANSI character set. Conversion can be approximative (accents are lost), or impossible (characters appear as "?").
WinMerge.exe can neither open files when filename is not writeable in the current ANSI set.
WinMergeU.exe is Unicode enabled executable which works in Windows NT4, Windows 2000 and newer systems.
Are you trying to select a directory by clicking on it in the upper part of the Open File dialog ? The Open File dialog will then open it, and you have to push
again to get out.17.1.4. Does WinMerge support merging three files? Sometimes it is called 3-way merge, where one file is ancestor. This would be useful for version control!
Unfortunately not. We acknowledge it would be good feature but have no plans to implement it in near future. This can be somewhat work-arounded using two WinMerge instances.
Not currently. If somebody wants to help/work with cross-platform support (using wxWidgets for example) we are interested of course.
Which kind of CVS integration WinMerge should have? Adding CVS client features to WinMerge is questionable since there are many good CVS clients already. Conflict file resolution is feature we are planning to add in future releases.
MRU is the abbreviation for "Most Recently Used", and means the history lists in Open-dialog thats containing 20 last used files/paths per side.
If you are using WinMerge.exe (not WinMergeU.exe), then your files may be Unicode files. WinMerge.exe cannot handle Unicode files. Please try comparing files with WinMergeU.exe if you have Windows NT4, Windows 2000 or newer Windows version.
Windows registry files (*.reg) are Unicode files (UTF-16 or UCS-2) -- see previous answer.
There is one or more zero-bytes in your file(s). If WinMerge finds zero-bytes from files it detects files as binary files. You can try to remove those zero-bytes from files. Or open files with DisplayBinaryFiles -plugin. DisplayBinaryFiles -plugin allows viewing binary files but does not allow saving changed files.
WinMerge shows current line in editor statusbar. WinMerge cannot show in-editor linenumbers. That is one feature we might consider for future releases.
This is what we call a "lossy" conversion.
For Unicode files (UCS-2, UTF-8), use WinMergeU.exe.
For ANSI files, this is probably due to code-page problem. If "Use codepage info" is selected from , turn that off and see if it helps.
Unfortunately WinMerge 2.0 and 2.2 supports only non-proportional fonts.
When Automatic Rescan is enabled WinMerge delays rescanning while user edits files. So there is no rescanning happening when user types text but shortly after user has finished typing. Without this delaying WinMerge would do rescan after every typed letter and editing files would become slow. This delaying especially improves editing of bigger files which can take several seconds to rescan.
Use -e commandline switch.
Tell program to invoke WinMerge with the /ub option, which tells WinMerge to not add the files to the MRU.
"Perry-style" patches are zip-files containing original and changed files in different directories. WinMerge has internal support (surprise?) for handling these files. Just select zip file in question to left side and right side and WinMerge opens zip files contents to directory compare comparing original and altered files.
Open the file with Windows notepad (eg. Encoding".
-> -> -> . Choose -> , and in the Save As dialog which appears, look at the dropdown list at the very bottom, labelled "If it says "ANSI", the file is (apparently) in the local windows codepage. If the file is entirely in English and normal punctuation, then the file is also in ASCII.
If it says "Unicode", the file is (probably) in the default Windows Unicode encoding "UCS-2LE".
If it says "UTF-8", the file is in the cross-platform Unicode encoding "UTF-8".
If it says "Unicode big endian", the file is in a different Unicode encoding not much used or supported under Windows, probably "UCS-2BE".
No. It may be added in later versions but until then Win32 port of diffutils can be used. Win32 port of diffutils (and patch) can be downloaded from GnuWin32 project from SourceForge: http://sourceforge.net/projects/gnuwin32