Re: inconsistent behaviour in windows

From: Philippe Verdy (
Date: Thu Feb 19 2004 - 09:57:29 EST

  • Next message: "Re: Arabic Characters for Kurdish are missing"

    From: "Jon Hanna" <>
    To: "Deepak Chand Rathore" <>
    Cc: <>
    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

    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