Re: _stprintf

Some versions of Windows implement DBCS, apparently the Japanese version of Windows had
this support, but it is not documented as far as I can tell.
joe

On Tue, 8 Aug 2006 12:57:43 +0900, "Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote:

I think my reply got lost or maybe accidentally sent personally to Dr.
Newcomer, sorry.

"Since you can't use any multibyte encoding in CreateFile,"

I am astounded to see that assertion.

CreateFile has created Japanese filenames since Windows 95 and NT 3.1
(though not in some foreign versions of those operating systems).

OpenFile created Japanese filenames in Windows 3.1, MS-DOS, etc. (though not
in some foreign versions of those operating systems).

On FAT12, FAT16, and NTFS.


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:nnidd2dckt42edmn498eemd3idlg53cpjb@xxxxxxxxxx
But the limit is MAX_PATH characters. THat's what we've been discussing.
In Unicode
mode, the limit is MAX_PATH characters, which would occupy 2*MAX_PATH
bytes. That is,
MAX_PATH TCHARs, and therefore their comment is completely CONSISTENT with
the fact that a
'character' is a 'TCHAR'. Since you can't use any multibyte encoding in
CreateFile, I
don't see where there is any problem here. 'character', in nearly every
context we've
discussed, means 'TCHAR'.

This also means that if you are using Unicode to represent Kanji, then you
should be able
to use MAX_PATH Kanji characters to name a file.
joe

On Thu, 3 Aug 2006 17:13:52 +0900, "Norman Diamond"
<ndiamond@xxxxxxxxxxxxxxxx> wrote:

"Mihai N." <nmihai_year_2000@xxxxxxxxx> wrote in message
news:Xns9813EB11E9700MihaiN@xxxxxxxxxxxxxxxx
The one for which Microsoft sent personal e-mail was CreateFile.
Microsoft assured me that even the ANSI version (CreateFileA) uses
Unicode internally and MAX_PATH is the limit on the number of
characters
internally, so if an ANSI application needs more than MAX_PATH bytes to
specify a usable filename then it can indeed do so. I've been a bit
negligent in not writing a test program to test this answer yet.

But CreateFile does not take a number of chars as parameter.

So what? Where we intuitively think that the stated limit of MAX_PATH
characters means MAX_PATH chars in ANSI, Microsoft informed me that the
limit really is MAX_PATH characters even if it takes twice that many
bytes.
You asked for examples of cases where we had been wrong in nearly always
assuming that MSDN's statements about characters meant TCHARs, and this is
a
big example.

What I suspect is happening is that the MAX_PATH is the limit if you
don't
use "\\?\" and is there both in the W and A versions.
And since the A version does a conversion to Unicode and calls the W
one,
the limit is probably there and expressed in utf16 code units, indeed.

You suspect that Microsoft's e-mail to me was accurate, and as mentioned,
I
have the same impression. Though they send a lot of unbelievable e-mails,
they send some believable e-mails too and this was one.

Interesting for some week-end experiments :-)

Yup. By the way, considering that VFAT can store a filename consisting of
around 250 Kanji, one weekend experiment would be to try opening the file
under Windows 98 (Japanese version of course). But really I'll consider
it
close enough if it works under Windows 2000, XP, 2003, and Vista beta. I
haven't had time to test it and I do believe that mail.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Unicode Support
    ... >> (I know this is a poor example, but think about other languages, eg ... First things first, when you register your RosAsm windows classes, you ... the messages with ANSI / UNICODE parameters in ANSI or UNICODE form... ... with their alphabet characters, as with the numbers and punctuation...so, ...
    (alt.lang.asm)
  • Re: Filename Encoding Help
    ... I suggest UTF-8, it's the most efficient for regular text, and it's the default for all methods reading and writing text files in .NET. ... UTF-16 but I am not sure what Windows Vista does. ... UTF-8 can represent the full Unicode spectrum, but many characters wind up encoded in just one or two bytes. ...
    (microsoft.public.dotnet.framework)
  • Re: Using Japanese text with Delphi
    ... on it and enter something in Japanese. ... correctly input, show, read and write Japanese characters. ... You have to go to Unicode, because then your characters will appear ... The Tnt Unicode controls are just about the only Delphi controls which can ...
    (borland.public.delphi.non-technical)
  • =?utf-8?B?UmU6IM6lzqDOn86azpXOmc6czpXOnc6fzp0gKFNVQkpFQ1Qp?=
    ... See this article about a similar problem with Japanese ... Japanese Characters in the Subject Line of E-Mail Message Appear As ... > Subject line as the operating system fully support Unicode. ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: _mbslen vs strlen
    ... My Windows application was unicode ... The length in characters, ... C++ on Linux has wide character characters as well as single byte ...
    (comp.os.linux.development.apps)