64-bit JNI

[Roedy Green]

I have had some requests to provide 64-bit versions of my JNI.

I wondered if anyone has any pearls to share about the process.

One puzzle, what sort of naming convention do you use to keep track of
the 32 and 64-bit version of a DLL? I would think you need to create
a new extension for 64-bit DLLs, e.g. *.DLL64 for loadLibrary to
automatically select the correct version.

What does Microsoft do?

Is there only one flavour of 64-bit windows app, or are their
Intel/AMD subflavours?

Obviously I could research this on my own, but I thought the
discussion would be of general interest.

 

[Arne Vajhøj]

I have had some requests to provide 64-bit versions of my JNI.

I wondered if anyone has any pearls to share about the process.

One puzzle, what sort of naming convention do you use to keep track of
the 32 and 64-bit version of a DLL? I would think you need to create
a new extension for 64-bit DLLs, e.g. *.DLL64 for loadLibrary to
automatically select the correct version.

Both 32 bit and 64 bit DLL's use the .dll extension.

I would expect that the most used approach to be:
- one version per distribution
with the second most used approach of:
- multiple DLL's in different directories
- have the user either set path to the correct directory
or copy the correct dll to the directory in path

What does Microsoft do?

Two versions of the distribution.

Is there only one flavour of 64-bit windows app, or are their
Intel/AMD subflavours?

Only one.

Arne

 

[BGB / cr88192]

I have had some requests to provide 64-bit versions of my JNI.

I wondered if anyone has any pearls to share about the process.

One puzzle, what sort of naming convention do you use to keep track of
the 32 and 64-bit version of a DLL? I would think you need to create
a new extension for 64-bit DLLs, e.g. *.DLL64 for loadLibrary to
automatically select the correct version.

one option myself (and a few others have used) at times is to make DLL's
with an arch suffix on the DLL base:
foox86.dll
foox64.dll
fooppc.dll
....

if done on a larger scale, it could allow multiple versions of an app to
easily "co-exist" as each EXE/DLL will depend on the particular DLL version
it needs.

the big downside is that it is a big hassle and meshes poorly with typical
build technologies...


foo.x86.dll
could also work, only that a little more care is needed with this convention
(some pieces of code floating around tend to rip-out extensions starting
from the start of a string rather than the end...).

What does Microsoft do?

typically, they create different builds for each arch.

for necessarily multi-arch projects (such as Windows), they put different
files in different directories, such as internally having a separate
"system32" directory for 32 and 64-bit apps, ...


so, an app using this strategy could have:
AppDir/Bins-x86
AppDir/Bins-x64
AppDir/Libs-x86
AppDir/Libs-x64
....

however, much like the prior strategy, this is also a big hassle (and it
doesn't help that, AFAICT, one can't just add directories to the LoadLibrary
search path, which would have been rather useful in a few cases).

granted, for some uses I have written a custom DLL loader, which does have a
few merits here (and also a few notable costs, mostly WRT OS and debugger
visibility, and as such I typically don't use this as a "general" DLL
loading strategy on Windows...).

Is there only one flavour of 64-bit windows app, or are their
Intel/AMD subflavours?

luckily, x86-64 is (mostly) the same between the 2 archs (the differences
are few and minor enough to where most code would unlikely ever notice...).
granted, this is also the case with 32-bit x86 as well.

it is always possible that one could produce vendor-specific code, but as a
general rule, compilers tend not to do this without explicit switches (if
they support these vendor-specific features at all).

so, they are the same arch, even despite the branding differences, ...


this is, after all, why most call it x86-64 or x64, rather than AMD64 and
EM64T...

Obviously I could research this on my own, but I thought the
discussion would be of general interest.

who knows...

 

[Lothar Kimmeringer]

I have had some requests to provide 64-bit versions of my JNI.

I wondered if anyone has any pearls to share about the process.

One puzzle, what sort of naming convention do you use to keep track of
the 32 and 64-bit version of a DLL?

In JCapi I solved it by loading DLLs with different names:
You can have a look at
http://jcapi.cvs.sourceforge.net/vi...ge/jcapi/Jcapi.java?revision=1.19&view=markup
There are System-properties allowing you to find out what
architecture you're running on but I did a different approach
simply trying to read in the 32-bit library and retry it
with the 64 bit version if the first try fails.

I did a different way when compiling my 64 bit version of
the Windows Server Wrapper at
http://sourceforge.net/projects/wrapper/develop
There I compiled the DLL for 32 and 64 Bit using the same
name and placed them in two different directories named
like the result of %PROCESSOR_ARCHITECTURE%. The startup-
script extends the PATH-variable e.g. like this
set PATH=libs\shared\win\%PROCESSOR_ARCHITECTURE%;%PATH%
letting the loadLibrary-method search for the corresponding
shared library.

What does Microsoft do?

Much more complicated. There are x-86 directories containing
the 32-bit DLLs. If a 32 bit application starts these
other directories are mapped to the expected old name.

Is there only one flavour of 64-bit windows app, or are their
Intel/AMD subflavours?

Not sure what you mean, but Intel has two different 64-bit
platforms. IA64 (Itellium) mainly (but nowerdays seldom)
used in servers and AMD64-compatibles. Core2-CPUs are
AMD64-compatible which is the value being returned by
the environment variable PROCESSOR_ARCHITECTURE.

Obviously I could research this on my own, but I thought the
discussion would be of general interest.

If you are using the free version of Visual Studio you
can't create 64-bit DLLs. You have to buy a "full" version
of Visual Studio. But you might try out other compilers
like gcc.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Arne Vajhøj]

Not sure what you mean, but Intel has two different 64-bit
platforms. IA64 (Itellium) mainly (but nowerdays seldom)
used in servers and AMD64-compatibles. Core2-CPUs are
AMD64-compatible which is the value being returned by
the environment variable PROCESSOR_ARCHITECTURE.

Besides the many very good points in your post, then
I will note that IA-64 is Itanium not Itellium (some
call it Itanic, but that is another story).

Arne