Discussion :

[papaella]

Bonjour à la communauté.

Suite à de nombreuses recherches infructueuses, je me suis obligé à poster mon problème. C’est la première fois que je fais appel à vous, car je ne trouve aucune solution...

Je vais essayer de présenter mon projet le plus simplement possible...

J’ai créé un code JAVA basé sur un modèle mathématique (méthode de koutrouvelis) permettant d’estimer les paramètres d’une loi alpha stable.
La méthode que j’ai ainsi codée fait appel à des fonctions provenant d’une DLL.

Cette DLL, codée en c++, était initialement utilisée pour un projet similaire, mais codé sous Excel/VBA. (Déjà je ne sais pas si cela à une quelconque importance dans l’appel des fonctions... ?)

PS : Je ne connais strictement rien à c++ ni aux DLL.

Mon environnement de travail :
- Windows 10 pro
- 64bits
- Logiciel utilisé : Netbeans
- Compileur : JAVA SE/jdk 1.8
- Librairie particulière utilisées : JNative / ssj-2.5
- La DLL est placée dans le system32 de Windows

Et voici les erreurs donner en retour de java :

run:
java.lang.UnsatisfiedLinkError: C:\Windows\System32\Stable.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1847)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1119)
at launcher.Runner.<clinit>(Runner.java:30)
Exception in thread "main" Java Result: 1
BUILD SUCCESSFUL (total time: 0 seconds)

Le retour montre clairement que l’erreur provient de l’incapacité à lire la DLL car c’est une 32bits et mon système est en 64.

Or j’ai cherché à recompiler cette DLL en c++, mais rien à faire ! cela ne fonctionne pas. (Même avec des forums dédiés aux DLL, mes connaissances en c++ ne le permettent simplement pas…)

Une âme charitable pourrait-elle me conseiller ? me proposer une solution de compilation en 64bits pour cette DLL ? Une autre approche ? Des remarques ?

Merci à tous !

[bacelar]

Le texte d'explication ne semble pas vraiment correspondre aux sources (mention de .xla inexistant, etc...).
Peut-être des modifications dans la source qui n'ont pas été répercutées dans la présentation.

Il s'agit d'une "simple" Dll codée en C++, exportant une API C.
C'est la combinaison/configuration la plus courante des Dll.
Le VB (.bas) n'est qu'un simple wrapper autour de cette Dll exportant une API C.

Effectivement, charger un code binaire 32bits dans un processus 64bits, ça le fait pas trop.

Mais, sauf erreur de ma part, il est tout à fait possible d'avoir un JRE 32bits sur un OS 64bits.

Donc, charger cette Dll dans un JRE 32bits ne devrait pas poser de problème.


Recompiler le code pour du 64bits est une option. Mais il faut vérifier que ce code soit "64bits aware", et au vue du code quelque peu archaïque, c'est loin d'être évidant.

Le code source contient des indices sur le fait qu'il a été conçu pour être compilable qu'avec VC++.
Mais le fichier projet ou le fichier solution de Visual Studio n'a pas été fourni.

Il vous faudra donc, soit adapter le code source à votre IDE C++, soit utiliser Visual Studio en créant un projet type Dll et entièrement le configurer pour faire le travail.
Pour l'option Visual Studio, c'est pas très complexe mais cela ne s'improvise pas.
Regardez un tutoriel sur comment faire une Dll en C++ avec Visual Studio exportant un API C.
C'est pas compliqué mais faut avoir quelques notions en C et en C++.

P.S.:

- La DLL est placée dans le system32 de Windows

Ce n'est pas bien, "system32" n'est pas un dépotoir.
https://www.chilkatsoft.com/java-loa...ry-windows.asp

[Médinoc]

Le code est primitif et ressemble plus à du C qu'à du C++ dans pas mal de cas, mais ne semble pas avoir de conversions entre pointeurs et types entiers, donc il devrait continuer à marcher tant que la taille des tableaux utilisés tient dans un int 32 bits.

[papaella]

Merci pour vos réponses qui m'aide déjà à bien comprendre le fonctionnement.

J'ai effectivement vite compris que la compatibilité était le réel problème.
Comme j'aimerais savoir si mon code fonctionne je passe pour le moment l'étape de la recompilation de la librairie.
Bizarrement je n'avais pas du tout pensais à lancer mon code avec une JRE 32bit.. ça semble pourtant évident.

Bacelar :

Donc, charger cette Dll dans un JRE 32bits ne devrait pas poser de problème.

J'ai donc suivi ton conseil est j'ai installer le jdk1.8.0_121 (version 32bit de java).
Netbeans semble vouloir lancer mon code sur la Plateforme 32bit et mon programme réussi bien a ouvrir le contenue de la DLL.
C'est donc un grand pas en avant!

En revanche une autre erreur survient lors de l'appel de la première fonction:

Erreur:

Code :

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

1
2
3
4
5
6
7
 
Exception in thread "main" java.lang.UnsatisfiedLinkError: launcher.Runner.al(JD)D
	at launcher.Runner.al(Native Method)
	at launcher.Runner.Alph(Runner.java:116)
	at launcher.launcher.main(launcher.java:21)
C:\Users\Laurent\AppData\Local\NetBeans\Cache\8.2\executor-snippets\run.xml:53: Java returned: 1
BUILD FAILED (total time: 2 seconds)

D’après ce que j'ai lu sur pas mal de forum, cela pourrait provenir d'une mauvaise définition de la fonction dans la DLL, mais comme vous l'avez tous deux mentionné, VBA comme mon code java ne sont que des wrapper.. cela ne devrais donc pas provenir de là?!

Une autre possibilité et que je fait mal appel à mes fonctions ou à ma dll.. et j'avoue que cette partie reste flou car la DLL s'ouvre!?

Voici mon procédé:
La class ou je défini les fonctions de la librairie:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
public class Runner {
 
    public static native double al(long a, double b);
    ...
    ...
 
 
 
    static {
        System.loadLibrary("Stable");
    }
 
   ...
   ... 
 
   public double Alph(double[] x){
       double Var = 0;
       double[] Tab1 = null;
       Tab1 = new double[x.length-1];
       for(int i = 0; i <x.length-1; i++){
           Tab1[i] = x[i+1];            
       } 
       Var = al(x.length,Tab1[0]);    //appel de la fonction (erreur sur l'appel)
       return Var;
    }

Cela semble t'il correct?

Ce n'est pas bien, "system32" n'est pas un dépotoir.

C'est noté. J'ai placé la DLL dans le bin du jre comme mentionné dans le tuto.


Médinoc:

il devrait continuer à marcher tant que la taille des tableaux utilisés tient dans un int 32 bits.

J'utilise un échantillon de données de 30 valeurs. La taille du tableau est donc faible pour le moment..

Merci pour votre aide.

[bacelar]

Là, c'est un peu le brouillard.
JNI, c'est très très loin pour moi.

Je pense qu'on pourra commencer une stratégie de wrapping pour bien vérifier le pont entre la Dll C et JNI.

La stratégie consiste à faire une simple Dll en utilisant juste les exemples comme :
http://jmdoudoux.developpez.com/cour...ap-jni.php#jni

Une fois cette Dll créée et utilisée, vous changez le code de cette Dll pour qu'elle appelle la Dll C initiale.

J'ai des appréhensions sur des problématiques de convention d'appel entre la Dll C et ce qu'attend JNI (qui était, dans mes souvenirs, très psychorigide).

[papaella]

J'ai suivi votre tuto pour le wrapper.
- Création du fichier header en .h avec l'invite de commande et les differents PATH etc..

La ou ça pause problème et lors de la création du fichier .c. Je suis partie du principe qu'il fallait recompiler la totalité du code C provenant de Code-Source.com .
J'ai donc ajouté tous les fichiers d’en tête et mon header créer initialement à un projet C/C++ pour DLL sur netbeans.
J'ai ajouté les différents path pour les 'includes' (MinGw et le jdk).
Le problème est que l'IDE me montre des erreurs. (cf. fichier pdf en pièce-jointe)
- il ne veut pas prendre en compte le point virgule, le ":" après public ou encore ne veux pas définir la variable Lserie..
et cela dans plusieurs fichiers .h

messages d'erreur:

Unexpected token: :

Unexpected token: ;

Unable to resolve identifier Lserie.

Déjà est-ce bien la bonne méthode que j'utilise pour le JNI, à savoir, faut-il recompiler le code source en totalité ?

Merci.