Re: encapsulating directory operations

"David Brown" <david.brown@hesbynett.no> wrote in message
news:101poqm$t350$1@dont-email.me...

On 04/06/2025 11:23, Paul Edwards wrote:

>
And I know what you're thinking - all the data is in EBCDIC.
There are no other EBCDIC systems I could possibly jump to.
We would need an 80386 EBCDIC version of Win32 in order
for this to be remotely possible - which doesn't exist, and likely
never will exist.
>
For it to exist it would need some sort of pseudo-bios concept
that allowed charset conversion. And no such thing exists as far
as I am aware!

>
You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
/that/ might be) to use data using EBCDIC character encoding.  It is no
different from working with any other character encoding - ASCII, UTF-8,
different 8-bit code pages, or whatever.  If the data is just passing
through your code, read it in and pass it out without a care.  If you
need to convert it or mix it with some other encoding, work with a
common encoding - UTF-8 is normally the right choice.

If I have existing C code that does:

fopen("test1.dat", "rb");
fread into buf
if (memcmp(buf + 5, "XYZ", 3) == 0)

and test1.dat is in EBCDIC, the above program on the 80386
has been compiled with EBCDIC strings, so it works, and then
now you do:

printf("It matches!\n");

where do you expect those characters in the printf string - all
currently EBCDIC - to be translated to ASCII on a modern
Windows 10/11 system?

And how do you expect Windows 10/11 to find "test1.dat" -
all EBCDIC on its current ASCII filesystem?

And I would want the data to remain in EBCDIC for
easy transportation, so if I do:

fopen("output.txt", "w")
I expect that file to remain in EBCDIC, so that it can be
opened with "rb" by zip.


You could indeed statically link a C library that takes care
of all that - with EBCDIC to ASCII conversion happening
on just filenames and the stdin/stdout/stderr streams.

Or you could have a dynamic C library and OS (possibly
combined) that sits between your app and the Windows OS
so that things are more reasonable.

And either way, you will need the supporting 80386 EBCDIC
Win32 toolchain to make it work. You would need someone
(or some people) really bloody-minded to sit down and
assemble all the required infrastructure over years, indeed
decades, to make it all work.

Fortunately the internet is big enough to find all the required
people to make it happen.

BFN. Paul.