Changeset 294
- Timestamp:
- Jun 16, 2011, 1:35:55 PM (14 years ago)
- Location:
- trunk
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/README.OS2
r290 r294 249 249 CURRENT LIMITATIONS 250 250 251 1. OpenJDK will not work correctly under the OS/2 SMP kernel (Java process 251 1. Due to the way how importing from DLLs works in OS/2, it is not possible to 252 have two applications using the same OpenJDK installation but different JVM 253 types (client or server) running at the same time. 254 255 2. OpenJDK will not work correctly under the OS/2 SMP kernel (Java process 252 256 hangs are very likely). This is a known problem of Odin32 which will be 253 257 addressed in further releases. The workaround is to use the OS/2 UNI or 254 258 Warp4 kernel instead. 255 259 256 2. The com.sun.tools.attach package (API to attach to a Java virtual machine)260 3. The com.sun.tools.attach package (API to attach to a Java virtual machine) 257 261 is missing. 258 262 -
trunk/openjdk/jdk/src/windows/bin/java_md.c
r278 r294 26 26 #ifdef __WIN32OS2__ 27 27 #define INCL_DOSMISC 28 #define INCL_DOSMODULEMGR 28 29 #include <os2wrap2.h> 29 30 #endif … … 231 232 } 232 233 233 #if __WIN32OS2__ 234 #ifdef __WIN32OS2__ 235 /* 236 * Native OS/2 LX DLLs support importing functions from other DLLs using 237 * relocation fixup records which differs from the Win32 PE format that does 238 * this through the IAT (import address table - a table of function 239 * pointers). As a result, if DLL_A imports something from DLL_B, then when 240 * DLL_A is loaded by a process, it will load a particular version of DLL_B 241 * to call its functions and all other processes that load DLL_A will get 242 * the same calls to that particular version of DLL_B (from within DLL_A) 243 * even though they supply their own version of DLL_B. In case of Java this 244 * means that if there is a Java process using e.g. server/JVM.DLL and 245 * another process is requesting client/JVM.DLL, this second process will 246 * eventually crash because all Java DLLs statically linked to JVM.DLL (e.g. 247 * JVERIFY.DLL, JZIP.DLL) which it loads later will be calling functions 248 * from server/JVM.DLL but that DLL is *not* initialized within this process 249 * (no surprise, it loaded and initialized client/JVM.DLL instead). In order 250 * to avoid such crashes we have to give a corresponding error message and 251 * terminate, there is no other solution so far. 252 */ 253 { 254 /* Try to load JVM.DLL by name -- if successful, it will give us the DLL 255 * that will be used by JVERIFY/JZIP and others with static linking. */ 256 jboolean ok = JNI_TRUE; 257 os2_CHAR buf[os2_CCHMAXPATH]; 258 os2_HMODULE hmod = 0; 259 os2_APIRET arc = DosLoadModule(buf, sizeof(buf), "JVM", &hmod); 260 if (arc == os2_NO_ERROR) { 261 /* success, check if it's the same DLL as we loaded above (we use 262 * DosLoadModule to get the OS/2 DLL handle (which differs from the 263 * Win32 one) instead of DosQueryModuleName to avoid string 264 * comparison problems such as separators, case etc.)*/ 265 os2_HMODULE hmod2 = 0; 266 arc = DosLoadModule(buf, sizeof(buf), jvmpath, &hmod2); 267 if (arc == os2_NO_ERROR) { 268 if (hmod != hmod2) { 269 ok = JNI_FALSE; 270 ReportErrorMessage2("Error: %s: this JVM conflicts with " 271 "a different type of JVM loaded by " 272 "another process. You may only use one " 273 "JVM type of a given Java installation " 274 "at a time", (char *)jvmpath, JNI_TRUE); 275 } 276 DosFreeModule(hmod2); 277 } 278 DosFreeModule(hmod); 279 } 280 if (!ok) 281 return JNI_FALSE; 282 } 283 234 284 /* 235 285 * Add the JRE bin path to BEGINLIBPATH to make sure that other DLLs 236 286 * statically linked to the various JRE DLLs (so that they refer to them by 237 287 * name in the import tables) are able to find it. This is necessary because 238 * on OS/2, loading a DLL by full path does NOT make it available forother288 * on OS/2, loading a DLL by full path does NOT make it available to other 239 289 * DLLs by name -- a normal procedure of searching it in LIBPATH and 240 290 * BEGINLIBPATH/ENDLIBPATH is always performed in this case. … … 316 366 { 317 367 EnableSEH(); 318 return RegisterLxExe( WinMain, NULL);368 return RegisterLxExe((WINMAIN)WinMain, NULL); 319 369 } 320 370
Note:
See TracChangeset
for help on using the changeset viewer.