中国DOS联盟

How to solve the garbled code problem in the dir list under DOS? Is it related to TW?

Help take a look! Thanks!

G:\Documents and Settings\Administrator\Templates
G:\Documents and Settings\Administrator\「Start」Menu
G:\Documents and Settings\Administrator\Desktop
D:\__
D:\Program Files\Avira\_____
D:\Program Files\_____\Skin
D:\Program Files\_____\Agent\DefHead
D:\Program Files\____\ls
D:\Program Files\___\0
D:\Program Files\___\DataCache
D:\Program Files\___\Dll
D:\Program Files\___\Images
D:\Program Files\___\Resource
D:\Program Files\___\Robot
D:\Program Files\___\Rss
D:\Program Files\___\Sound
D:\Program Files\___\WelcomeVisitor
D:\Program Files\____\Examples
D:\Program Files\____\WCe300arm
D:\Program Files\____\WCe420arm
D:\Program Files\____\WCe420x86
D:\Program Files\____\WCe421arm
D:\Program Files\_________\Projects

It's really about TW!
Can you recommend a replacement for TW?

Last edited by terse on 2007-4-30 at 01:43 AM ]

It shouldn't be like this. What are your software and hardware environments? Have you loaded long filename support like DOSLFN? And is this DOS pure DOS or DOS under a window? The background information provided in the question is too little.

The reply from Xie Benshi! The above list is what I saved when searching!
I'm using GRUB to boot the img image, which is for pure DOS use TW; running in the virtual memory disk, loading as follows: (also loaded IFS)
@ECHO OFF
mem /c|find /i "TW">nul
if not errorlevel 1 goto Ctw
lh tw /np N3 >nul
:Ctw
mem /c|find /i "CTMOUSE">nul
if not errorlevel 1 goto CLIP
lh CTMOUSE >nul
:CLIP
mem /c|find /i "MOUSCLIP">nul
if not errorlevel 1 goto DKEY
lh MOUSCLIP >nul
:DKEY
mem /c|find /i "DOSKEY">nul
if not errorlevel 1 goto LFN
lh DOSKEY >nul
:LFN
mem /c|find /i "DOSLFN">nul
if not errorlevel 1 goto EXIT
lh DOSLFN /z:Cp936uni.tbl >nul
goto EXIT
:EXIT
Yesterday in the same environment, without loading any software, I used CCDOS, and there was no above situation! So it's said to be the matter of TW!

Last edited by terse on 2007-4-30 at 09:44 AM ]

Probably because "IFS is also loaded" : Some Chinese character systems conflict with IFS.

Originally posted by 本是 at 2007-4-30 10:42:
Maybe because "another IFS is loaded": Some Chinese character systems conflict with IFS.

If it is really like this! Besides TW, what are the suitable alternatives? CCDOS seems a bit large! Registration is also not good!

Have you tried other Chinese character systems such as Hanwang HW Chinese characters, UCDOS, 2.13L, AW97, etc.? At the same time, have you tried switching memory drivers such as EMM386, QEMM, UMBPCI, etc.?

Originally posted by Ben Shi at 2007-4-30 21:17:
Have you ever tried other Chinese character systems such as HanWang HW Chinese characters, UCDOS, 2.13L, AW97, etc.?
At the same time, have you ever switched to use memory drivers such as EMM386, QEMM, UMBPCI, etc.?

I haven't tried other Chinese character systems such as HanWang HW Chinese characters, UCDOS, 2.13L, AW97, etc.!
I am using JEMM386 and the latest UMBPCI. I don't know if it has any impact!
I will report back after replacing JEMM386.

Last edited by terse on 2007-4-30 at 09:30 PM ]

Changed to another version of TW, and it actually displays normally. It seems to be an issue with the version. However, there is something wrong with IFS. Sometimes it can't load! I'll take a look again.

Today, I changed the original "lh DOSLFN /z:Cp936uni.tbl >nul" to "lh DOSLFN >nul", and everything is normal! Switching back to the original TW also has no garbled code phenomenon! Why is it okay with "lh DOSLFN >nul" like this?