Discussion :

[scalande]

Bonjour, ma question est simple :

J'aimerais savoir comment on peut détecter avec Java si on se trouve sur un Windows 32-bit ou 64-bit.


Un grand merci d'avance !

[adiGuba]

Salut,



Je suppose que System.getProperty("os.arch") devrait renvoyer x86_64...

a++

[scalande]

Ben en fait... j'avais essayé...

Mais chez moi ça renvoie "x86" alors que je suis sur un Windows XP x64

C'est normal?

[scalande]

C'est peut-être juste sous Linux le x86_64
=> http://lopica.sourceforge.net/os.html

[adiGuba]

Que te renvoi la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java -version

Tu utilises peut-être une JVM en 32bits, ce qui expliquerait cela...

a++

[scalande]

Voilà voilà...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

J'imagine que tu vas en déduire que j'utilise un jvm 32 bits.
Alors j'anticipe :
Comment connaître l'architecture du windows, indépendamment de la machine virtuelle utilisée?

Et alors j'ai aussi une autre question.
Supposons que je télécharges une machine virtuelle 64-bit et que je développe sous Eclipse avec cette version.
Si je veux exporter mes fichiers.class vers un WinXP 32 bit, est-ce que je saurai lancer les .class avec une machine virtuelle 32 bit ?

Excuse moi mais je ne maîtrise pas bien le sujet ;-)

Un grand merci pour tout

[adiGuba]

J'imagine que tu vas en déduire que j'utilise un jvm 32 bits.

J'en ai bien peur
Je n'en suis pas sûr mais il me semble que java -version est enrichie de la mention "64 Bits" lorsque c'est le cas...

Comment connaître l'architecture du windows, indépendamment de la machine virtuelle utilisée?

Je pense que ce n'est pas possible sans bidouiller...
Je m'explique : sous Windows 64bits les applications 32bits sont lancés dans un sous-système comparable à un environnement 32bits. Les applis 32bits (comme la JVM 32bits) se croient donc en environnement 32bits...

Si je veux exporter mes fichiers.class vers un WinXP 32 bit, est-ce que je saurai lancer les .class avec une machine virtuelle 32 bit ?

Oui : les fichiers *.class ne sont en aucun cas affectés par ces changements.
Quel que soit le compilateur utilisé, une appli Java fonctionnera "de la même manière" avec une JVM 32bits ou une JVM 64 bits. La seule différence viendra que la version 64 bits pourra bénéficier des avantages de son architecture (par exemple pour les calcul sur les long/double qui tiennent sur 64 bits).

La seule contrainte étant d'avoir une version de la JVM identique ou supérieur au JDK utilisé pour compiler l'appli


Par curiosité : pourquoi as-tu besoin de connaitre cela ?

a++

[scalande]

Merci pour toutes ces explications, ça m'éclaire pas mal.

Ben en fait je réalise un programme Java qui, à certains moments, lance des programmes externes via des getRuntime.exec(****.exe)

Ces programmes sont réalisés en c++ et ont été compilés avec MinGW/MSys (sais pas si tu connais...)

Bref, tout ça pour dire que :
pour que les .exec(***.exe) fonctionnent, il faut qu'une dll "mingwm10.dll" soit présente dans le répertoire WINDOWS/system32

Cependant, j'ai deux versions : mingwm10.dll 64bit et mingwm10.dll 32bit

Là, je suis en train de créer un "installer" automatique de mon programme (qui risque d'être lancé sur 32 et 64 bit). Et je voudrais savoir quelle version de mingwm10.dll je dois copier dans system32...

Tu vois ?

Ce ne serais pas très propre mais normalement, dans les architectures 64bit, il existe un répertoire :
C:\WINDOWS\SysWOW64

Je pourrais peut-être me baser sur l'existence de ce répertoire pour savoir si oui ou non je suis sur 64bit...

Qu'en penses-tu?

[OButterlin]

Oui : les fichiers *.class ne sont en aucun cas affectés par ces changements.
Quel que soit le compilateur utilisé, une appli Java fonctionnera "de la même manière" avec une JVM 32bits ou une JVM 64 bits. La seule différence viendra que la version 64 bits pourra bénéficier des avantages de son architecture (par exemple pour les calcul sur les long/double qui tiennent sur 64 bits).

Juste un petit bémol sur la compatibilité "garantie" entre les 2 architectures... ce n'est hélas pas vrai si tu utilises JNI (mais d'un autre côté, c'est compréhensible)

[adiGuba]

Je pourrais peut-être me baser sur l'existence de ce répertoire pour savoir si oui ou non je suis sur 64bit...

Je ne connais pas le fonctionnement exact de Windows 64bits, mais puisqu'il conserve une compatibilité 32bits je suppose que system32 ne doit contenir que les versions 32bits, et "SysWOW64" les versions 64bits.

Donc le mieux serait de copier mingwm10.dll 32bit dans system32 dans tous les cas (cela permettrait de ne pas avoir d'erreur si tu lances une appli 32bits sur un 64bits), et de copier mingwm10.dll 64bit si le répertoire "SysWOW64" existe...

Bien sûr à condition que les appli utilisent bien ces répertoires selon le mode 32/64bits (ce que j'ignore).

Tout cela rend ton application inutilisable sur d'autres OS, mais je ne pense pas que cela te pose problème...


A noter que tu pourrais vérifier la variable d'environnement PROCESSOR_ARCHITECTURE via System.getenv(), bien que je pense qu'elle retourne x86 pour une appli 32 bits...

Juste un petit bémol sur la compatibilité "garantie" entre les 2 architectures... ce n'est hélas pas vrai si tu utilises JNI (mais d'un autre côté, c'est compréhensible)

C'est surtout normal puisque JNI utilise du code natif qui doit être compilé pour la machine cible selon l'OS et l'architecture...

a++

[scalande]

Je ne connais pas le fonctionnement exact de Windows 64bits, mais puisqu'il conserve une compatibilité 32bits je suppose que system32 ne doit contenir que les versions 32bits, et "SysWOW64" les versions 64bits.

Je pense que c'est légèrement plus compliqué. Regarde ce que j'ai trouvé sur le net :

http://ubuntuforums.org/showthread.php?t=473546

I’ve had a 64 bit Windows 2003 Server for a couple of months and I’ve just noticed something.

The SysWOW64 and System32 directories.

I assumed that System32 had 32 bit libraries, and SysWOW64 had 64 bit libraries. Safe assumption, right?

But no!

According to Wikipedia:

"The operating system uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backwards compatibility reasons as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WOW64 redirects requests for DLLs from that directory to %SystemRoot%\sysWOW64, which contains legacy libraries and executables."

Well, that’s consistent, and not back to front at all!!!

I’m not bashing, just surprised... What’s the Linux way?

Donc... Si ma logique est bonne...
Si "WOW64" existe... c'est que c'est un Windows 64 bit. Dans ce cas je mets la version 64bit du dll dans system32 et s'il n'existe pas, je mets la version 32 bit !



lol

[scalande]

A noter que tu pourrais vérifier la variable d'environnement PROCESSOR_ARCHITECTURE via System.getenv(), bien que je pense qu'elle retourne x86 pour une appli 32 bits...

Ah oui, ben ça ça donne x86 que ce soit sur Win32 ou Win64 (j'ai les deux à disposition ) mais tous les deux avec la jvm 32 bit

[adiGuba]

Je pense que c'est légèrement plus compliqué.

C'est bien tordu tout cela

Ah oui, ben ça ça donne x86 que ce soit sur Win32 ou Win64 (j'ai les deux à disposition ) mais tous les deux avec la jvm 32 bit

Ca je m'en doutais un peu : une appli 32bits tourne sous un sous-système 32 bits...

a++

[scalande]

finalement... je me rends compte que c'est impossible de copier un fichier dans le répertoire system32...

Donc je change d'option :

je vais mettre des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Runtime r = Runtime.getRuntime();
r.loadLibrary("mingwm10");

dans mon code avant de faire les .exec()

et je vais juste, à l'installation, choisir la bonne version du dll et la placer dans le même répertoire que le package qui lance les .exec (au lieu du répertoire system32)


Merci pour tout !

A bientôt!