Date: Mon, 17 Jun 2002 08:25:51 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: sandmann AT clio DOT rice DOT edu cc: djgpp-workers AT delorie DOT com Subject: Re: Interesting bug (extended characters in file names) In-Reply-To: <10206170031.AA15814@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 16 Jun 2002 sandmann AT clio DOT rice DOT edu wrote: > In my favorites directory, I have several .url files which have been saved > with names containing extended characters. (Registered symbol (R), trademark > TM). From a command line these characters don't display properly. I > cannot copy these files from the command line on Win95 (OK from Win2K) - > this tells me that maybe Windows is just broken ... > > The djgpp images see them but can't get information on them. For example: > > ls (shows them, but characters substituted/truncated in display?) > ls * (gives the name, then ENOENT) One possible reason is that these characters don't belong to the character set supported by the OEM font Windows uses for the DOS box and DOS programs. For example, if you copy a string with these characters into the clipboard, and then paste them into the DOS app, either via the Edit->Paste dialog of the DOS box or by invoking the appropriate Int 2Fh function from the application (Emacs does that), such characters are converted into underscores `_'. I believe Windows tries to convert between the character sets, and replaces those characters it cannot convert with underscores. > Has this been noticed before? I'm not sure if it's something we can work > around, but I thought I would pass it on. Unicode characters? Unicode characters should never be exposed to DOS apps. But it could be that W2K emulation of DOS interrupts feeds us with multibyte characters which our library cannot grok. It might be interesting to see what does `findfirst'/`findnext' return in those cases.