Opened 14 years ago
Closed 13 years ago
#24 closed enhancement (fixed)
Change calling convention from _stdcall to _System
Reported by: | Silvan Scherrer | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | GA2 |
Component: | general | Version: | |
Severity: | medium | Keywords: | |
Cc: |
Description (last modified by )
this will give the advantage to integrate java to oo.org
Change History (3)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Milestone: | Enhanced → GA2 |
Severity: | → medium |
Summary: | integrate Java to oo.org → Change calling convention from _stdcall to _System |
comment:2 by , 13 years ago
One thing I was curious about is how could Innotek Java work with this native IBM Java code that uses the _System cconv on OS/2. However a closer look shows that there is a special wrapper DLL, J2WIN.DLL, which intercepts Win32 LoadLibrary() and a bunch of other APIs to provide special _System stubs that call the relevant JVM entry points in the Win32 JVM.DLL (having the stdcall cconv) when Java loads JNI DLLs.
This means that we have a good chance that TCP/IP (and other native OS/2 JNI DLLs) will work if we change cconv to _System.
I'm currently rebuilding Java after making this change to see how it will work.
comment:3 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The cconv switch is done in r339.
My tests show that everything works, including the LVMGUI and TCP/IP configuration applications.
This also means that OpenJDK may be made a default JVM in OS/2.
Note also that this change breaks the ability to load Win32 JNI DLLs but I don't think that we actually need this; these DLLs will most likely not work as they are normally done for something present in Java itself and most likely our Odin (existing mainly for Java) doesn't implement the respective Win32 APIs either.
We may look at enabling this support later if needed.
also some older dlls used in TCP/IP config might start to work then