|
![](/i/fill.gif) |
In article <3f21a958$1@news.povray.org>, tho### [at] trf de says...
> I am still undecided whether I should recommend some sleep or you are on
> drugs. There is neither head nor tail to what you are writing. I don't
> even know how to respond to this in a meaningful way!?! :-(
>
Ok.. Then let me try again...
I could make a file with the same name as flyer_2000 is talking about on
my windows machine. It would look different in a DOS window, since
Windows doesn't use the OEM terminal font in most programs, even for
dealing with filenames. However, the file system would have absolutely no
problem with it and 'in windows' it would have the proper accented
character. This does not make it a unicode name. I am not sure what the
technical name for a character set that has exactly 255 characters is,
but it isn't exactly ASCII and it also isn't Unicode.
So I am unclear about exactly 'which' OS you seem to think would have a
problem here? Windows will accept the name, I am fairly sure Unix based
systems would, maybe Mac 'might' have a problem, but the only 'real'
issue is the font used to display the names, which differs between a DOS
window and Windows, but 'should' be the same under most GUI environments.
If you still don't believe me, then consider that these sorts of
characters have also been used in text documents since before Windows 3.1
and on 9x systems you have to install Unicode support separately, because
it is not a native part of the OS. If such file names and characters can
only happen with Unicode, then how they heck do you explain them existing
before Unicode was available?
So again. Exactly 'which' OS are you saying is not capable of using this
particular set of files? You are the one that assumed he was talking
about unicode and brought that into the discussion, but such a name is
not unicode.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
![](/i/fill.gif) |