Port HPI

[dmik]

HPI (I believe) stands for Hardware Platform Interface and in case of JDK this encapsulates platform-specific memory management, threading and other basic things and exposes it the platform-neutral way.

[dmik]

Finished porting HPI. Some remarks:

• We are using the Windows HPI code so far which mainly consists of LIBC calls (which I ported to EMX/kLIBC that we now use as a C runtime library for the project) and a few native Windows API calls (some of which I replaced with the OS/2 API calls because otherwise it would not work).
• I created os2wrap2.h in Odin SDK which allows us to use OS/2 APIs from Windows source files (which use the Windows API a lot). This file renames OS/2 type and constant definitions which clash with the Windows typedefs and otherwise could not be used. This gives us a relative freedom.
• The HPI code is not fully tested on OS/2 (yet). This will be done when porting other JDK parts that use it.

Note that the fact that we are using kLIBC may be a potential problem because in the real Windows world there is a certain amount of correlation between the usual C runtime (MSVCRT) and Win32 API. For example, the C file descriptor may be turned into a Win32 file HANDLE while the kLIBC file descriptor (which is in fact a raw HFILE value except for the socket file descriptors) may not. Another problem is that we have to start/stop threads with Win32's CreateThread?()/ExitThread?() instead of _beginthread()/_endthread() thus bypassing kLIBC thread initialization and termination which may have various side effects. We will see later how dangerous all this is.

There is actually no real alternative to kLIBC ATM -- the provided
MSVCRT port is not complete. If things go wrong we will probably have to hack into kLIBC as an option.