In the printer patch there are some conversion tables.

// Various ASCII codepage to unicode maps

static const Bit16u cp437Map[256] = {
0x0000,0x0001,0x0002,0x0003,0x0004,0x0005,0x0006,0x0007,0x0008,0x0009, ...

cp437Map
cp737Map
cp775Map
cp850Map
cp852Map
cp855Map
cp857Map
cp860Map
cp861Map
cp862Map
cp863Map
cp864Map
cp865Map
cp866Map

Maybe these are useful.

Hm yes, they look nice though incomplete and in one direction only.
I assume that most OSes have some way to translate characters/filenames
from their current OS-codepage to unicode, so translation should at
least be possible.

Okay, I digged a bit around and found that the promised solution here does not meet my requirements. I need access to the host file system AND special characters in file names.

Then I decided to patch DosBox source code. A full description is located at http://www.qv90.de?sw&F8=1&CI=1&FI=0.

Hopefully a future release of DOSBox may fix that restriction (which is indeed only Microsoft MS-DOS related).

Regards
Jam

That patch only works for the umlauts, and only for certain codepages
(don't know if the umlauts are even the same for 437 and 850 ones).
And it doesn't look like host-level files with umlauts would be displayed
correctly in dosbox (thus can't be accessed any more).

And the filename character restriction you mention is correct, but dosbox
was limited to a set of characters not because dos couldn't handle them,
but to avoid serious trouble with the host OS (remember it's crossplatform).

The proposed idea from hal should be working, and some test implementation
actually seems to work though i did not really tested it much. Should work
for most codepages and is crossplatform.

To be honest, it was intended as an exploit 😊

It should only clarify that characters in file names has nothing to do with code pages. The code page discussion is totally misleading. There are two issues to take care about with special characters in file names:

1. DOS itself (without the ugly MicroSoft DOS) allows all characters between 128-255 in file name

2. Character conversion from extended ASCII to host file names it difficult (I found no mapping tables). This is the only point where code page conversion arises

So please don't mixup the discussions.

The whole problem ONLY exists because of codepages. Umlauts are not
always at the same cp position, so when the codepage inside dosbox is
changed your translation will mess up that stuff.
And MSDOS is fine with all characters inside names, it's just that they
have the restriction for file creation.

Hi,
I updated the exploit to include a brute force patch regarding Int2138h:

The "Countryinfo" structur is set to german (COUNTRY=049). Date- and time format, currency, decimal seperator and others does now support the german layout.

(Patch available at http://www.qv90.de?sw&F8=1&CI=1&FI=0)

I moved all my patches to one place. Please refer to viewtopic.p...p;start=27

bugs_bugger wrote:

[Überhaupt schlechter Stil, Umlaute in Filenames zu verwenden 😀.]

As written there, it's not recommended to use umlauts (non-us characters) in filenames.

Why do you refer to DOSBox v0.65 instead of 0.70? 😒 😉

Yes I know, but I've a friend using FrameWork IV and he still stick on "Umlaute" in file names 😖

I'm not able to change topic of posting and I thought it was not a good idea to open a new posting...

Do you think it makes more sense to do so?

qv90 wrote:

Do you think it makes more sense to do so?

Nein... 😀