Aufruf externes Programm auf x64 OS/DOMINO schlägt fehl

[nespresso]

Guten Morgen, frisch für eine neue Denksportaufgabe?
Also eines vorweg, ich habe mit Entwicklung nichts am Hut.

Wir haben in einem Programm einen Aufruf einer DLL implementiert, was auf 8.0.2FP auf 32bit Windows einwandfrei funktioniert.
Nun haben wir die Plattform gewechselt auf Windows 2008 R2 64bit und Domino 8.5.3FP1 64bit
Wenn wir nun die selbe Funktion aufrufen erscheint Error Loading DLL. Dabei spielt es keine Rolle ob diese DLL oder das Verzeichnis überhaupt vorhanden ist, es kommt immer die selbe Meldung. Zugriff auf das entsprechende Verzeichnis haben wir via Agent, der ein Testfile ablegt schon getestet und das geht.

Sorry für meine dilettantische Art im Entwicklerforum zu posten, aber vielleicht hatte schon jemand ähnliche Probleme und weiss eine Lösung?

Merci und Gruss
Uwe

[Thomas Schulte]

32 Bit /64 Bit Unterschied? Welche DLL? in welchem Programm Implementiert?

Wie sagt Nummer 5 so schön ...
Brauche Input, mehr Input.

[nespresso]

Die DLL ist definitv 32bit, aber das sollte m.E. kein Thema sein. Wir haben viele 32bitter die auf 64 OS problemlos laufen.


*glühbirne* Könnte es sein, dass Domino, da 64bit ein Problem mit dem Aufruf einer 32bit DLL hat?

[Thomas Schulte]

Nein Domino hat damit normalerweise keine Probleme. Aber, es könnte schlicht und einfach sein,das die DLL nicht sauber regiestriert ist, oder im falschen Pfad liegt.

Deswegen die Frage nach, welche DLL, welches Programm?

[nespresso]

Die Registrierung einer DLL ist doch eigentlich nur dazu da, dass jedes Programm weiss wo diese zu finden ist, oder?
Mit regsvr32 wird doch nur ein Regitry Eintrag erzeugt, in dem steht wo die DLL liegt.
Der Agent hat in den Declarations den Pfad zur DLL hinterlegt, somit sollte das doch gehen....?

[m3]

LO47066: "EXTERNAL FUNCTION NOT FOUND." ERROR FROM LOTUSSCRIPT AGENT USING SOME DLL FUNCTIONS IN DOMINO 64-BIT

bzw. ein Regression Bug

[m3]

Lass Dir mal vom Coder sagen, ob die DLL direkt aufgerufen wird, oder als COM Objekt.

[Thomas Schulte]

Martin das ist jetzt nicht Ernst oder? IBM stiehlt sich einfach aus der Verantwortung, nach dem Motto, ja wir haben Scheiße gebaut aber das macht nix? Und nein wir haben auch keine Lust das zu korrigieren.
Wie Krank ist das denn? Das ist ja noch schlimmer als"No plans to fix in this codestream".

[nespresso]

Die DLL wird direkt aufgerufen, also eine Funktion innerhalb der DLL. Mich beschleicht aber das Gefühl, dass selbst schon der Aufruf nicht funktioniert. Da die Fehlermeldung nicht der entspricht, die in den Links angegeben ist.
Könnte es eventuell sein, dass durch die DLL noch weitere aufgerufen werden, die eventuell dann doch nicht da sind wo sie sein sollten und der Fehler daher kommt?

[m3]

Thomas, so wie ich das lese, ist die LO47066 ueberholt, weil der SPR OIHZ7YKMY2 wurde ja fixed, war nur bei meiner Suche der erste Treffer.

Nachdem das in gefixed wurde, wuerde ich wenn, dann eher auf einen Regression Bug tippen.

@nespresso: Ja, das kann sein.

[nespresso]

Scheint so, als kann eine 32bit DLL nicht von einer 64bit Anwendung ( hier Domino ) geladen werden. Zumindest deuten weitere Recherchen im Web darauf hin.

Wenn ich mit Dependency Walker die DLL im produktiven Kontext aufrufe, erhalte ich eine Fehlermeldung
Error: Modules with different CPU types were found.
Man sieht alle abhängigen DLL's in rot mit x64 und die fragliche hat x86

[Ralf_M_Petter]

natürlich ist es so, dass man in einem 64 bit Programm keine 32 bit dll aufrufen kann. Wie soll das auch gehen, wenn das 64 bit Programm einen 64 bit Zeiger übergibt die 32 bit Dll aber nur was mit 32 bittigen Zeigern anfangen kann. Das ist doch auch der Grund warum 64 bit Browser kaum jemand verwendet, da die ganzen Plugins wie Flash und Konsorten dann da nicht laufen.

Die 32 bit Kompatibilität in Windows 64 bezieht sich darauf, dass 32 bit Programme laufen und praktisch alle Betriebssystembibliotheken sowohl in 64 bit als auch in 32 bit vorhanden sind.

Die Lösung ist übrigens ziemlich einfach. Der Entwickler muss nur seine DLL als 64 bit neu kompilieren.

[Hatschi]

Wir hatten das Problem nur in umgekehrter Richtung.
Ein Script sollte auf Notes (32-Bit) per COM zugreifen. Startet man das Script einfach, war Notes nicht sichtbar. Erst nachdem es mit
c:\windows\syswow64\cscript "C:\temp\test.vbs"
im 32-Bit Modus gestartet wurde, funktionierte es.

Insofern kann ich Nespresso nur zustimmen das es Kommunikationsprobleme zwischen 32- und 64-Bit Anwendungen gibt. Vielleicht kannst du dir ja mit einem ähnlichen Konstrukt helfen.

Bernd