Prev: keyboard hits in a console app
Next: Reading resource files from a jar file
From: Roedy Green on 11 Feb 2010 20:49
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.

--
Roedy Green Canadian Mind Products
http://mindprod.com

Every compilable program in a sense works. The problem is with your unrealistic expections on what it will do.
From: Arne Vajhøj on 11 Feb 2010 21:09
On 11-02-2010 20:49, Roedy Green wrote:
> 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

From: BGB / cr88192 on 12 Feb 2010 11:15

"Roedy Green" <see_website(a)mindprod.com.invalid> wrote in message
news:4ub9n5tlhsuot4tbi39ut1gsnl26amu708(a)4ax.com...
>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...



From: Lothar Kimmeringer on 13 Feb 2010 16:26
Roedy Green wrote:

> 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/viewvc/jcapi/net/sourceforge/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: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
From: Arne Vajhøj on 13 Feb 2010 17:58
On 13-02-2010 16:26, Lothar Kimmeringer wrote:
> Roedy Green wrote:
>> 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.

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

 |  Next  |  Last
Pages: 1 2
Prev: keyboard hits in a console app
Next: Reading resource files from a jar file