EBCDIC is not being displayed correctly

General questions about using ExamDiff Pro, ideas for new features, bug reports, and usage tips.
David B. Trout
Full Member
Posts: 28
Joined: Wed Jan 06, 2010 4:21 am

Re: EBCDIC is not being displayed correctly

Post by David B. Trout »

.
Just in case you're interested, here's an updated .zip file containing all three EBCDIC code pages: 37, 500 and 1047 too:
.
cp037-cp500-cp1047.zip
(1.89 KiB) Downloaded 252 times
.
Thanks.
"Fish" (David B. Trout)
"Programming today is a race between
software engineers striving to build bigger
and better idiot-proof programs, and the
Universe trying to produce bigger and better
idiots. So far, the Universe is winning"
- Rich Cook
User avatar
psguru
Site Admin
Posts: 2228
Joined: Sat May 15, 2004 4:23 pm
Location: California
Contact:

Re: EBCDIC is not being displayed correctly

Post by psguru »

Sounds good. If we decide to go with this approach, (1) it will be done in the next version (15) and (2) the existing EBCDIC support in binary comparison will go away, for obvious reasons.
psguru
PrestoSoft
JeremyNicoll
Expert Member
Posts: 108
Joined: Sun May 02, 2010 12:00 pm
Location: Edinburgh

Re: EBCDIC is not being displayed correctly

Post by JeremyNicoll »

psguru wrote: Fri Feb 24, 2023 11:30 am ... and (2) the existing EBCDIC support in binary comparison will go away, for obvious reasons.
It's not obvious to me. EBCDIC files are not all just text - yes those containing programme source (of one sort or another) are, but object code, load modules, snap dumps etc are not.

There's still a need for files subject to binary compares to have those bytes that might represent strings of printable characters displayed as those, eg if one was looking for differences in literals (eg message texts) stored within a load module.
JeremyNicoll
Expert Member
Posts: 108
Joined: Sun May 02, 2010 12:00 pm
Location: Edinburgh

Re: EBCDIC is not being displayed correctly

Post by JeremyNicoll »

psguru wrote: Fri Feb 24, 2023 9:58 am Thanks. We were thinking about these code pages... Here's an idea: why should EBCDIC files treated as second-class citizens and compared as binary files? Or, for that matter, any other non-Unicode (ANSI) code pages? So one potential approach would be to have an option in EDP to define the default code page (with the default set to the Windows system page, typically 1252 in the US). This would allow, e.g, EBCDIC files to be opened and saved as text files, not as binary. Of course, with the option set to, say, page 37, this will make all "regular" text files look like garbage.

Another (perhaps a future) approach is to specify file's code page in the File Open dialog, to override the default setting. This way you could compare EBCDIC files by setting the page to 37/500 just for them.
It's not just EBCDIC files; what about the difference between ANSII and "DOS" (OEM?) code pages - eg suppose you issue a DIR command in a cmd.exe terminal window and some of the filenames have foreign characters - they'll /look/ ok. Redirect that output into a .txt file, make a copy of that file, then compare them in EDP. When it says they're the same, choose "show files anyway". The glyphs shown for the foreign characters are likely to be "wrong". Eg for a filename "Potato rösti - a simple skills test.txt", the "ö" is shown as a sexed closing double quote in EDP (and Notepad etc). [Though maybe that's not true in recent versions of EDP, for various reasons I'm still using v9.0.1.1.] Maybe it'd be useful to be able to change the display codepage for one or both (or all three) views in EDP via the view context menu?

Regarding frequent comparisons of files whose display shouldn't be done with a Windows-default codepage, I would find it clumsy to have to specify the override codepage every time I ran a compare. I think I might want to be able to specify (say) one or more partial filepaths (eg "C:\z-OS\;E:\Project390\;F:\zWork\") for which the default codepage should be <something>.
User avatar
psguru
Site Admin
Posts: 2228
Joined: Sat May 15, 2004 4:23 pm
Location: California
Contact:

Re: EBCDIC is not being displayed correctly

Post by psguru »

OK, in light of what was said, here's the plan. We'll delay the input file code page (and default page) implementation to a future version.

For this version (14, now in Beta), we'll try and make the following change to binary comparison: instead of the current Binary Options | Character Set, we'll have a single combo box with all single-byte code pages that your Windows has installed on it. The default will be set to the current system page (the one defined in Windows Region settings, Administrative | Change System Local). For US Windows this will likely be code page 1252 (ANSI Latin 1). This will correspond to the current ASCII option on this options page. You will be able to select another page, such as 37 (IBM EBCDIC - U.S./Canada), 500 (IBM EBCDIC - International), or anything else installed on your system.

We'll also remove "Show extended chars (128-255)" (they will always be shown), since we can't have ASCII-centric options anymore. The "Show control characters (0-31)" option will remain. As a result, the only there will be two controls: the code page combo and the "Show control characters" option.

Note that this affects only the right sides of the binary comparison views.
psguru
PrestoSoft
User avatar
psguru
Site Admin
Posts: 2228
Joined: Sat May 15, 2004 4:23 pm
Location: California
Contact:

Re: EBCDIC is not being displayed correctly

Post by psguru »

The following have been included in the latest Beta 14.0 build:
  • New: Ability to switch between different code pages to display byte codes in binary comparison
  • Improvement: The width of the address column in binary comparison views is based on file sizes
psguru
PrestoSoft
JeremyNicoll
Expert Member
Posts: 108
Joined: Sun May 02, 2010 12:00 pm
Location: Edinburgh

Re: EBCDIC is not being displayed correctly

Post by JeremyNicoll »

Thank-you!
MSpagni
Expert Member
Posts: 537
Joined: Mon Mar 30, 2009 12:53 am
Location: Italy

Re: EBCDIC is not being displayed correctly

Post by MSpagni »

psguru wrote: Mon Mar 06, 2023 1:03 pm Improvement: The width of the address column in binary comparison views is based on file sizes
Ditto. :D
Post Reply