64-bit JNI
in [Java Help]
|
Prev: JSF + XLS ?
Next: What does volatile guarantee?
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 |