How to force dosemu to output in "transparent" mode?
Brought to you by:
bartoldeman
Could someone give me some hint how to get dosemu to
not translate or otherwise tinker with what is output
to the screen? In particular, I am trying to run dosemu
under a terminal emulator (mlterm in Big5 mode). The
DOS program to test-run is a legacy app outputting
Chinese, and dosemu is clobbering halves of all
characters having the 8th bit set.
The program should be run under a terminal emulator; I
can't run it in console mode or remote X, because
ultimately this will be able to serve modem dial-up.
I tried to tinker with -I, but does not seem to have
any effect. Has anyone tried something similar before?
Logged In: YES
user_id=501371
Doesnt it have any similarities with this:
http://sourceforge.net/tracker/index.php?func=detail&aid=691303&group_id=49784&atid=457447
Please try the fix from there.
Logged In: YES
user_id=11986
I just tried the developer's snapshot, which contains the patch.
If I set both $_external_char_set and $_internal_char_set to
"cp437" (not the real charset, but it should do), I can now
type Chinese and see Chinese on the command line. However,
the DOS program do not seem to get the characters (if this
makes sense at all).
For example, if I type "echo 一" (0xa4 0x40) on the command
line, all I get back is a "@" (0x40). If I type "echo 四"
(0xa5 0x7c), I get nothing back, which I assume is the
result of command.com seeing the character changed into a
"|" (0x7c).
Similarly, I can call up my legacy app, and see the Chinese
characters. However, if I type Chinese into the app, I may
get back what I type, or I may get back just some random
symbols.
Logged In: YES
user_id=11986
I found that, in command.com, I can quote the characters and
then most will be seen correctly. However, some characters
are still corrupted. For example, 0xadd3 becomes 0xad60, and
0xb37e becomes 0x20 0x7c 0x7e (three characters... why
three?...) These corruptions , unlike the corruptions which
occur when I do not quote the characters, occur as soon as I
type characters.
Logged In: YES
user_id=501371
Well, of course you understand that noone uses
a chineese charset here, so reproducing the
problem is hard (but I use koi8-r, which is also
8-bit, and there seems to be no problems).
Generic question: have you set $_internal_charset
and $_external_charset properly?
Also, if it looks like a DOS or command.com's
problem to you, you may want to try other DOS and
other command.com and see if it helps.
Logged In: YES
user_id=11986
Yes, I realize no one uses a Chinese charset here. As to why
the patch would work for Russian but not Chinese, I am
puzzled too.
I set both my $_external_charset and $_internal_charset to
cp437. Of course this is wrong, but there is no setting for
a Chinese charset (e.g., cp932), and I figured that the
display should be correct as long as I tell dosemu that the
internal charset matches the external charset. I don't know
if this assumption is flawed or not.
(Also, historically, Chinese programs usually run also in
the cp437 charset. A "plugin" to the screen i/o routines in
BIOS, so to speak, will convert what whatever is output into
Chinese characters, so historically speaking running dosemu
under a Chinese terminal emulator quite accurately mimics
how such programs have been running in "real" dos.)
I'll try to use another DOS later to see if there is any
difference.
Is this still a problem?