Discussion :

[Captain'Flam]

Bonjour,

un probl�me bien complexe m'am�ne vers vous... je vais essayer d'�tre clair :

J'ai du code C bien propre et standard qui peut �tre compil� sous Windows (par Visual Studio 10) et sous Linux (par gcc).
Les fichiers de projets (.sln et .vxproj pour Visual et makefile pour gcc) sont g�n�r�s avec CMake (il y a un beau CMakeLists.txt qui vient avec).
Par ailleurs, depuis le code C, j'invoque du code java qui s'ex�cute via la JNI (et la jvm.dll qui va avec)
Jusque l�, tout va bien...

Nouvelle donne : on veut maintenant faire fonctionner tout �a en 64 bits.

Sous Windows, gr�ce � CMake, il est facile de g�n�rer un projet "Visual Studio 10 Win64".
Donc aucun probl�me pour compiler en 64 bits (apr�s quelques ajustements du code).

Mais l'ex�cution commence directement par l'erreur 0xC000007B (pas tr�s limpide ).

Une petite recherche sur les fora m'apprend que c'est simplement parce qu'il continue � charger la version 32 bits de jvm.dll.
C'est � cause de ma variable path, qui contient un chemin vers elle.
Je la change (ma variable path) et la faisant commencer par le chemin de la version 64 bits (que j'ai install�e) et tout fonctionne !

Le probl�me c'est que je veux pouvoir passer de la version 32 bits � la version 64 bits sans avoir � �diter path � la main.
La solution me semblait �tre d'ajouter un truc du genre "set path=c:\java64;%path%" dans le menu Propri�t�s/Ev�nement de build/Ev�nement post-build/Ligne de commande de Visual.
Malheureusement, �a ne change que le path d'un process temporaire, et pas celui dans lequel va s'ex�cuter mon application...

Et c'est l�, que vous, les experts, entrez en sc�ne !
Y a-t-il un moyen de faire ce que je veux ?
Attention, je ne parle pas de lancer mon application depuis un shell ou un script. Dans ce cas, je modifie mon path depuis le script avant de lancer l'appli.
Je parle bien de lancer l'appli depuis l'environnement de Visual Studio pour pouvoir ex�cuter mon code en pas � pas.

Merci de m'avoir lu jusque l� et d'avance pour vos r�ponses...

[bacelar]

L'embarra du choix :
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

[Captain'Flam]

Merci grandement !
Mais ma joie fut de courte dur�e... la solution n'est pas l�...

En effet, jvm.dll se trouve dans une arborescence de dossiers cr��s par l'installateur java.
Elle m�me s'attend � trouver d'autres dll dans cette arborescence.

Donc, m�me si je copie la dll 64 bits � c�t� de l'exe (ce que j'ai fait au d�but), il ira chercher ses d�pendances dans le dossier indiqu� dans $path qui contient la version 32 bits.
Je ne peux pas non plus tout balancer dans le dossier syst�me...

Conclusion, je n'ai pas le choix, le chemin de la dll 64 bits doit �tre dans le path !

[M�dinoc]

Dans ce cas, � moins de faire un Launcher qui change le path "� la main" programmatiquement, tu peux utiliser la solution suppos�e marcher sous Windows: Installer les deux versions de Java dans Program Files!

La version 32 bits dans C:\Program Files (x86)\Java\blabla, la version 64 bits dans C:\Program Files\Java\blabla, et tu rajoutes C:\Program Files\Java\blabla dans le path une bonne fois pour toutes. La redirection automatique pour les processus 32 bits est cens�e faire le reste.

[Captain'Flam]

Merci M�dinoc !

En effet, j'avais � faire un launcher, mais il y avait trop de contraintes pour le reste du projet...
(le mode 64bits est une "cerise sur le g�teau" : �a ne doit pas (trop) perturber le projet)

La solution "Program Files" / "Program Files (x86)" est assez tentante (je n'y avais pas pens� du tout) mais pas tr�s portable dans le monde Linux...
En plus, il n'y pas moyen de garantir que toutes les machines auront

Sinon, je pensais � une autre solution : Y a-t-il un moyen d'emp�cher l'exe g�n�r� par Visual de charger les DLL au lancement ?

S'il est possible de ne charger les DLL qu'� la premi�re utilisation (une sorte de mode "lazy"), j'aurais eu le temps de modifier le path...

[M�dinoc]

Tout-�-fait, il y a une option "delay-loaded DLLs" quelque part dans les options d'�dition de liens.
Et en cas d'�chec, c'est une exception Win32 qui est lev�e lors de la tentative d'appel plut�t qu'une erreur irr�cup�rable qui emp�che le lancement du processus.