From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Feb 19 2004 - 09:57:29 EST
From: "Jon Hanna" <jon@hackcraft.net>
To: "Deepak Chand Rathore" <deepakr@aztec.soft.net>
Cc: <unicode@unicode.org>
Sent: Thursday, February 19, 2004 12:18 PM
Subject: Re: inconsistent behaviour in windows
> > Is there any work around ( microsoft guys) , where all the characters retain
> > their hex values ( \x00 to \xff ) when passed to exe irrespective of the
> > system locale settings ?
>
> Off-the-top-of-my-head ideas:
> 1. Use CreateProcessW (only an option if you can rule out 95/98/ME support)
On Windows 95/98/ME, the CreateProcessW() API would work with the additional
Unicode layer support installed on the system, but it would internally translate
the call into CreateProcessA() by transcoding strings from UTF-16 to the local
Windows "ANSI" codepage (but not the UTF-8 "codepage"), replacing unsupported
characters by question marks.
It's not easy to use CreateProcessA() on Windows 95/98/ME and have it support
passing command lines and environment strings with Unicode support. The executed
application must have a way to get its parameters and environment blocks passed
by another mean. A simple solution for Windows 95/98/ME is to have the
application accept its arguments and environment settings from an external file
or shared resource, by using a specific argument or option to reference it (for
example a "-f params.txt" option or a "@params.txt" parameter). This is also
needed because command lines and environment blocks on 95/98/ME are limited in
length.
This additional supported option could be convenient as well on NT/200/XP to
allow passing more options on command lines or grouping common options in a file
for easier reuse. This is traditionally used quite often to bypass command line
length restrictions that also exist in other OSes, notably for invoking
compilers, linkers, ...
Note that using environment blocks in Windows is deprecated, as it is often
implemented by having it stored in the user's or system's profile, and these
variables pollute all other process invokations, and may be a security issue.
Most of the Unix-Linux environment settings are mapped preferably in the Windows
registry and in configuration files in the user's home directory
("%USER_HOME%\Application Data" on NT/2K/XP) for the user's profile, and/or in
the installation directory for the default profile.
This archive was generated by hypermail 2.1.5 : Thu Feb 19 2004 - 10:41:33 EST