Discussion :

[Négrier]

Contexte :

• Windows: Seven/64 bits
• Delphi: XE7 Entreprise
• Gcc : x86_64-7.3.0
• Scilab : version 6.0. 1/64bits

Je suis confronté au problème suivant :

• J’ai une DLL « FrontalScilab » (WIN64, codée en C++) qui exporte une fonction « _lancerSCILAB » capable de charger puis de lancer le « moteur » Scilab, et de lui faire exécuter un JOB.
• J’ai une application « Client_Exe601x64.exe » qui est une application console WIN 64 (codée en C++) qui charge la DLL « Frontal Scilab » et appelle « _lancerScilab »
• J’ai une application « ScilabExe.exe » qui est une application console WIN 64 (codée en Delphi) qui charge la DLL « Frontal Scilab » et appelle « _lancerScilab »

1. Lorsque j’exécute « Client_Exe601x64.exe » tout se passe bien.
2. Lorsque j’exécute « ScilabExe.exe » j’obtiens une exception « EInvalidOp » lors du démarrage du « moteur » Scilab

Voir l’illustration ci-dessous.



J’ai pu développer l’ensemble logiciel équivalent en WIN 32 sans que cela pose le moindre problème (Frontal Scilab en C++ et Application cliente en Delphi)


Il n’y a strictement aucune différence entre les deux applications consoles, j’aimerais donc comprendre ce que rajoute/ ou enlève le compilateur Delphi et qui conduit
à cette levée d’exception.

Après avoir soumis le sujet dans le Forum Scilab, j'ai procédé à une simplification importante pour me ramener à la situation courante où deux applications consoles
très épurées et strictement identiques (l'une en C++ l'autre en Delphi) ne se comportent pas de la même façon lors de l'utilisation d'une DLL codée en C++.

Bien entendu comme je l'ai expérimenté depuis longtemps en WIN 32 il est très satisfaisant de pouvoir disposer des capacités de calcul de Scilab
dans une fenêtre d'application Delphi


Code source de la DLL

Code c++ :

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
#include <stdio.h>
#include "call_scilab.h" /* Provide functions to call Scilab engine */
 
#if defined(__cplusplus)
#define FRONTAL_EXPORT extern "C" __declspec( dllexport ) 
#else
#define FRONTAL_EXPORT __declspec( dllexport )  
#endif
 
FRONTAL_EXPORT int __cdecl _lancerSCILAB(int * numErr)
{
 
 printf("Je suis dans la DLL FrontalScilab C++\n");
 printf("Je lance ""_lancerSCILAB""\n");
 if ( StartScilab(getenv("SCI"),NULL,0) == FALSE )  {
   fprintf(stderr,"Error while calling StartScilab\n");
   return -1;
 }
 printf("Envoi du job : ""disp([1,2;3,4]*inv([1,2;3,4]))"" vers Scilab\n");
 SendScilabJob("disp([1,2;3,4]*inv([1,2;3,4]));");  
 printf("Je sors de ""_lancerSCILAB""\n");
 return 0;
}

Code source de l'application « Client_Exe601x64.exe » en C++

Code c++ :

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
27
28
29
#include <windows.h>
#include <stdio.h>
typedef   int __cdecl (* tLanceScilab)(int * numErr);
 
 
int  main(void)
{
	printf("\nApplication(EXE) C++ cliente de la DLL ""FrontalScilab"" en C++\n");
	int numErr;
	HINSTANCE h = LoadLibrary("C:\\Temp\\Exe-Dll-Scilab\\FrontalScilab_601x64.dll");
	if (h==0) printf("Echec du chargement de la DLL\n");
	if (h!=0) {
		tLanceScilab lance;
		lance  = (tLanceScilab)GetProcAddress(h, "_lancerSCILAB");
 
		if (lance) {
			if (lance(&numErr)==0) {
				printf("Terminaison normale de l'appel ""_lancerSCILAB""" );
			}
			else {
				printf("Echec dans ""_lancerSCILAB"", num erreur = %3d", numErr);
			}
		}
		else {
			printf("Fonction inconnue dans la dll : ""_lancerSCILAB""");
		}
		FreeLibrary(h);
	}
}

Code source de l'application « ScilabExe.exe » en Delphi

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
program ScilabExe;
 
{$APPTYPE CONSOLE}
{$R *.res}
 
uses
  System.SysUtils,
  windows;
 
procedure lancerScilab;
type
  tLance = function(var numErr: integer): integer; cdecl;
 
var
  h: THandle;
  lance: tLance;
  path1: string;
  numErr: integer;
begin
  writeln('');
  writeln('Application(EXE) DELPHI cliente de la DLL "FrontalScilab" en C++');
  writeln('');
  path1 := 'C:\Temp\Exe-Dll-Scilab\FrontalScilab_601x64.dll';
  h := LoadLibrary(PChar(path1));
  try
    if h = 0 then
    begin
      writeln('Echec du chargement de la DLL : "' + path1 + '"');
      exit;
    end;
    lance := GetProcAddress(h, '_lancerSCILAB');
    if not assigned(lance) then
    begin
      numErr := 200;
      writeln('Fonction inconnue dans la dll : "_lancerSCILAB"');
      exit;
    end;
    if lance(numErr) <> 0 then
      writeln('Echec dans "_lancerSCILAB", num erreur = ', intToStr(numErr))
    else
      writeln('Terminaison normale de l''appel "_lancerSCILAB"' );
  finally
    FreeLibrary(h);
  end;
end;
 
procedure attendre;
begin
  writeln('pause : appuyez sur la touche "Entree" pour continuer...');
  readln;
end;
 
begin
  try
    lancerScilab;
  except
    on E: Exception do
      writeln(E.ClassName, ': ', E.Message);
  end;
 
end.

[anapurna]

salut

l'erreur qui me vient a l'esprit c'est les declaration de type
sont il les meme en 64 et en 32 ?

[Négrier]

Client Delphi Win 64 :

1. le chargement de la DLL se passe bien
2. c'est l'instruction

   Code :

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

    StartScilab(getenv("SCI"),NULL,0)

   qui se passe mal et elle n'implique pas les paramètres fournis à la fonction "_lancerSCILAB" de la DLL.

J'ai d'ailleurs corrigé la coquille sur mon message initial. Dans le code de l'application cliente en Delphi il faut :

Code :

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

type tLance = function(var numErr: integer): integer; cdecl;

et pas

Code :

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

type tLance = function(var numErr: integer): integer; stdcall;

Pour coller à l"export de la DLL C++

Code c++ :

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

  FRONTAL_EXPORT int __cdecl _lancerSCILAB(int * numErr)

mai ça ne change pas le comportement

Mais effectivement il doit se passer quelque chose au niveau de la mémoire allouée d'une certaine façon par l'exe Delphi.
Le "StartScilab" de la DLL "FrontalScilab" entraine le chargement de librairies dynamiques présentes dans l'environnement Scilab et c'est là qu'il
y a sans doute un conflit.

En dehors de l'aspect "Scilab" de mon problème, c'est surtout la différence de comportement entre les deux exécutables qui me préoccupe et devrait, à mon sens,
intéresser la communauté "Delphi".

[Paul TOTH]

je suppose sur l'int C++ en 64bits est sur 64bits

sous Delphi Integer reste en 32 bits, il faut utiliser Int64 ou NativeInt

[Négrier]

J'ai fait le test avec

Code :

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

tLance = function(var numErr: int64): int64; stdcall;

mais le problème reste entier, sans intention de mauvais jeu de mot !

En fait je peux faire tout ce que je veux dans cette DLL C++ et l'appeler depuis l'exécutable Delphi, à part lancer SCILAB !

N.B. Dans "l'ensemble" SCILAB de nombreuses librairies sont issues de la compilation de code en langage FORTRAN.

[anapurna]

salut


quel type est h?
voir ce que sizeof (h) renvoie.
Assure-toi que c'est 8 ($100400000 apparaîtra comme $00400000 dans une variable 32 bits, ce qui peut causer une certaine confusion)

prefere HMODULE à Thandle de cette façon tu est deja plus coherent dans le choix de tes types

[Négrier]

Bonjour,

j'ai changé la déclaration de h :

h:HMODULE

mais j'ai toujours le même comportement

[ShaiLeTroll]

En 64 Bits, les conventions d'appel n'existe plus, stdcall, cdecl ... le compilateur s'en fout, tout c'est en fastcall.

En C++ sur Windows
le int est un synonyme de "long int" (Integer)
"unsigned long int" (Cardinal) c'est pareil que "unsigned int"
C'est valable pour 32Bits et 64Bits pour un compilateur C++ Windows

Le 64 Bit c'est "long long int" (Delphi Int64, BCB __int64 et int64_t) et "unsigned long long int" (NativeUInt en 64)

Avec RAD Studio, on s'éclate car on a un C++ multiplateforme

Dans le modèle de données "ILP32" de Win32, int (et long) et les pointeurs ont une longueur de 32 bits. Vous pouvez utiliser unsigned int à la place de size_t, même s'il n'est pas portable.

Win64 est un modèle de données "LLP64" : long long et les pointeurs ont une longueur de 64 bits, alors que int et long ont toujours une longueur de 32 bits. Par conséquent, vous devez utiliser size_t.

Manquerait plus que l'on s'intéresse à Linux ou Mac OS X qui utilise un modèle LP64, le int reste 32 mais le long int devient 64 mais comme on parle de "int" le problème ne se pose pas

[anapurna]

salut

StartScilab(getenv("SCI"),NULL,0)

ce n'est pas plutot

StartScilab(getenv("SCI"),NIL,0)

en delphi ?

autre question que retourne

Code :

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

getenv("SCI")

?

[ShaiLeTroll]

"lancerSCILAB" est un wrapper écrit en C++ de "StartScilab", donc le NULL c'est bien le pointeur nul

la balise code a fait mis à anapurna sur une fausse piste du NULL mais le getenv semble intéressant
J'ai un souvenir d'un getenv récalcitrant en C++ Builder dans une DLL

Pour éviter les confusions, utiliser CODE=C++, cela ajoute "Code C++" au dessus de la section de code, cela change aussi la gestion de la coloration syntaxique

Code c++ :

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

StartScilab(getenv("SCI"),NULL,0)

et pour delphi juste CODE

Code :

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

if lance(numErr) <> 0 then

Et par purisme

Pour coller à l"export de la DLL C++

Code c++ :

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

FRONTAL_EXPORT int __cdecl _lancerSCILAB(int * numErr)

alors

Code :

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

  TLanceSCILABProc = function(numErr: PInteger): Integer; cdecl;

Sinon pour complèter le propos d'Anapurna sur le Null en Delphi
Null = Type Variant, une structure complexe sur 16 octets, ça contient plein de zéro normalement
nil = Pointeur nul donc le NULL du C++

[Négrier]

Le code

Code :

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

StartScilab(getenv("SCI"),NULL,0)

est du coté de la DLL dont le source est codé en C++ et il faut bien un "NULL".


L'expression

Code :

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

getenv("SCI")

renvoie le chemin de l'installation Scilab sur le poste où se trouvent mon exécutable Delphi et ma DLL C++ (ce chemin est L:\INSTALL\scilab61\bin dans mon cas).
Lors de l'appel à "StartScilab" des librairies de l'environnement Scilab sont chargées en fonction des calculs que l'on demande...y compris la JVM si on fait du graphisme.

N.B. Scilab est un logiciel Open libre

Scilab est régi par la licence CeCILL (compatible GPL) respectant les principes de diffusion des logiciels libres

et il ne peut donc pas y avoir de problème de chargement de licence(s).

Pour mémoire :

• tout se passe bien en 32 bits (avec toutes les versions de Scilab) ;
• par contre j'ai le même plantage sur toutes les versions 64 bits.

Je peux encore fonctionner avec les versions 32 bits pour le moment mais les versions 64 bits de Scilab sont annoncées comme plus performantes, ce qui explique qu'on veuille les utiliser.

[Négrier]

Désolé je n'avais pas vu le message de ShaiLe Troll de 17h17

[anapurna]

salut

ah ok effectivement je me suis fourvoyé dans les meandre de son code

bon donc retour au debut du probleme

[ShaiLeTroll]

CeCILL
Tient c'est rare ça, quand j'ai filé un jour un source à un pote faisant un stage au CNRS, il m'a dit d'utiliser la CeCILL-C pour ma petite Lib Delphi, c'est ce que j'ai fait même si ne comprends rien du tout en terme de Licence.

un sujet sur getenv
Faudrait être sur que cela ne passe pas le chemin de BCB, j'ai le cas, je crois en déboguant une DLL BCB, cela passait le chemin de BCBet non le chemin de l'exe appelant

[Négrier]

-J'utilise le gcc x86_64-7.3.0 (pas de BCB ni de VS)
-Je me suis fait mon propre environnement de dev C++ en Delphi. Sans doute pas top au niveau ergonomie mais adapté à moi-même - il ne fait que
faciliter la création du Makefile...

-Je ne pense pas avoir de souci au niveau du getEnv : mon code fonctionne bien en Win32 - avec un chemin vers l'installation Scilab adaptée Win32 ou Win64.

Si je reviens à mon mail initial ce qui me perturbe beaucoup c'est que le programme console C++ est vraiment identique à celui en Delphi (normal car je les ai
réduit à la plus simple expression pour que ce soit le cas) si encore il y avait des FORM ou du graphisme...mais ça n'est pas le cas.

[Paul TOTH]

est-ce que tu peux ajouter "_control87(MCW_EM, MCW_EM);" dans _lancerSCILAB ?

ça me fait penser à OpenGL en fait

https://www.opengl.org/discussion_bo...int-Exceptions

[Négrier]

Après modification du code C++ de la DLL :

Code C++ :

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
#include <float.h>
FRONTAL_EXPORT int __stdcall _lancerSCILAB(int * numErr)
{
 printf("Je suis dans la DLL FrontalScilab C++\n");
 printf("Je lance ""_control87(_MCW_EM, _MCW_EM)""\n");
 _control87(_MCW_EM, _MCW_EM); 
 printf("Je lance ""_lancerSCILAB""\n");
 if ( StartScilab(getenv("SCI"),NULL,0) == FALSE )  {
   fprintf(stderr,"Error while calling StartScilab\n");
   return -1;
 }
 printf("Envoi du job : ""disp([1,2;3,4]*inv([1,2;3,4]))"" vers Scilab\n");
 SendScilabJob("disp([1,2;3,4]*inv([1,2;3,4]));");  
 printf("Je sors de ""_lancerSCILAB""\n");
 return 0;
}

Notez l'utilisation de "_MCW_EM" au lieu de "MCW_EM"

J'obtiens l'exécution suivante :



Incroyable, non ?

Merci à tous en particulier à Paul

Je crois que cette solution pourrait servir à d'autres développeurs tombant dans ce piège diabolique.

Je continue à faire mes tests et clos la discussion au plus vite.

[ShaiLeTroll]

ça me fait penser à OpenGL en fait

https://www.opengl.org/discussion_bo...int-Exceptions

C'est ce qe l'on lit dans Set8087CW

Lors de l'utilisation de OpenGL pour effectuer le rendu des graphiques 3D, nous vous recommandons de désactiver toutes les exceptions de virgule flottante pour des raisons de performances. Pour ce faire, appelez Set8087CW(0x133f) dans l'événement OnCreate de votre fiche principale avant d'appeler une fonction OpenGL.

Voir aussi System.Math.SetFPUExceptionMask et exDenormalized ?


Est-ce que sans utiliser __control87 dans la DLL mais en changeant le mode CPU dans DELPHI cela joue aussi ?

?

[Négrier]

Je n'ai pas réussi à faire fonctionner le tout en :

commentant dans le code de la DLL

Code C++ :

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

//_control87(_MCW_EM, _MCW_EM);

et en rajoutant dans le code de l'EXE Delphi avant le

Code :

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

if lance(numErr) <> 0 then

,

• soit

  Code :

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

  System.Set8087CW($133f)

• soit

  Code :

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

  System.Math.SetFPUExceptionMask

[ShaiLeTroll]

et en rajoutant dans le code de l'EXE Delphi avant le if lance(numErr) <> 0 then

je l'aurais mis avant le LoadLibrary