Assign correct values to OS-related properties

[dmik]

Currently, many properties, such as os.name and file.encoding contain Windows values (i.e. Windows 2000 and Cp1251) which is not correct on OS/2 and needs to be fixed.

[dmik]

I changed the code to correctly report the following properties:

os.name ("OS/2")
os.version (OS/2 major.minor)
sun.os.patch.level (OS/2 revision)
sun.desktop ("pm")

I also fixed Odin32 (GetUserName?()) so that user.name is returned correctly.

For user.home, I first use the %HOME% environment variable and then fall back to the Windows way (which first reads the registry or the special shell function for the location of the user's Desktop folder and then takes its parent) as this makes much more sense since many other OS/2 apps already use %HOME% and eCS even defines it during installation.

As for file.encoding, I simply return what DosQueryCp? returns. This needs to be verified later (i.e. how exactly this property it used across JDK, whether we have necessary codecs for all values DosQueryCp? may return and so on). The exact purpose of sun.jnu.encoding (which appears to be some encoding used internally) is not yet known to me, so I return the Windows current locale's code page for it so far. Needs to be checked later as well.

[dmik]

According to this guide, ​http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html the majority of known encodings is supported so I suspect this fully covers what DosQueryCp?() may return. We will deal with it if/when we find a case that breaks this.

[dmik]

As far as I understood, "sun.jni.encoding", as opposed to "file.encoding" used for file I/O, is used when it is necessary to pass a string from Java to the underlying OS API and vice versa. I need to check what encoding Win32 APIs in Odin expect from the user -- Windows ANSI or OEM encoding (surprise, but in some locales these two differ: for example, in .ru, windows-1251 isused for ANSI, while IBM666 is used for OEM).

[dmik]

I mean, these ANSI/OEM encodings differ in a real Windows installation.

[dmik]

Did some testing and got strange rather strange results. Given the simple MessageBox?() function, it turns out that, for the Russian locale, it expects the window title bar to be in IBM866 and the message text itself -- in windows-1251. On the second thought, it's not really too strange since the message text is drawn by Odin on its own (and hence the ANSI encoding is expected) while the title bar is drawn by the system (using the OS/2 encoding which is IBM866 here). Anyway, this is a task for Odin. Created ​http://svn.netlabs.org/odin32/ticket/12 for that.

[dmik]

BTW, "sun.jni.encoding" is also used by the Java launcher code (java.exe and all friends) to interpret the command line arguments. I would really like that we had a single encoding for everything (to avoid this GUI/console mess that is present on Windows) but I'm not sure that this is possible since Odin also has to run binary code that expects such behavior. We'll decide after the Odin ticket is closed.

[dmik]

In r21464, I solved issue 3 by providing special versions of argc and argv, called __argcA and __argvA, which are exported from KERNEL32.DLL (and available at the source level if you include windows.h). These variables represent the command line arguments in the ANSI encoding (as opposed to argc and argv which are always in OEM from the Windows point of view).

Note that these variables are valid only after WinMain?() is entered and must not be used if WinMain?() is not used. The common technique to implement the windows behavior for Win32 applications that don't parse the lpCommandLine parameter of WinMain?() but rather use the standard argc and argv variables is as follows:

#include <windows.h>

#ifndef _MSC_VER

#include <odinlx.h>

int _main(int argc, char **argv);

int WIN32API WinMain(HANDLE hInstance,
                     HANDLE hPrevInstance,
                     LPSTR  lpCmdLine,
                     int    nCmdShow)
{
    return _main(__argcA, __argvA);
}

int main(int argc, char **argv)
{
    EnableSEH();
    RegisterLxExe(WinMain, NULL);
}

#else
#define _main main
#endif

int _main(int argc, char **argv)
{
    // do something with argv which is already in ANSI here
}

This basically corresponds to the RegisterLxExe?() usage pattern anyway; the only difference is using these __argcA and __argvA in WinMain?() instead of real argc and argv.

Note that __argcA is in fact the same value as argc (the number of arguments doesn't change after the codepage conversion), it is there just for clarity.

This pattern may be also found in the testapp/encodings test case. Now, the functionality of this test case on both the native Windows machine and on OS/2 under Odin is the same so I consider this ticket as done.

[dmik]

Oops, wrong ticket...

[dmik]

The Odin's ticket 12 is done. We will fix the ANSI/OEM command line encoding problem using __argvA that I added to Odin within that ticket and that contains the command line arguments nicely converted from OEM to ANSI for us so they will meet the expectations of Win32 APIs w/o any modification. This way, "file.encoding" will stay OEM because it is used for file I/O so must match the system OS/2 encoding and "sun.jni.encoding" will stay ANSI as it is used for the API calls and must match what Windows needs.

[dmik]

The command line encoding problem was solved in r167. This all looks satisfactory now.