Anwendung stützt ab wenn DELPHI deinstalliert wird

[jaenicke]

Zitat von himitsu:

'ne 32 Bit-DLL in einer 64 Bit-Anwendung läuft nicht unbedingt so gut.

An eine 64-Bit Anwendung hatte ich nicht gedacht. Aber eigentlich hätte ich das schon daran sehen müssen, dass nach der DLL im System32 Verzeichnis gesucht wurde.

Ja, dann müssen die DLLs dazu passen, ja.

[Assarbad]

Zitat von jaenicke:

An eine 64-Bit Anwendung hatte ich nicht gedacht.

Dazu gibt es ja das Hive-Mind (also uns alle zusammen). Mir war das so gut wie klar als ich den Fehlercode in der ntstatus.h nachgeguckt hatte und es STATUS_INVALID_IMAGE_FORMAT war. Den hatte ich früher schon gesehen und der kommt immer mal wieder (es gibt davon auch eine Win32-Variante), aber ich hatte noch nie ein wirklich beschädigtes Image. Mach auch keinen Sinn. Wenn nur Delphi deinstalliert wurde, aber die Anwendung nicht angetastet wird, bleiben nur noch Abhängigkeiten. Da dieser Fehler ganz offensichtlich vom Loader kommt (sonst wäre es kein nativer Fehlercode ala NTSTATUS), muß das auch schon während des Ladens passieren und somit war der Fall relativ klar.

Aber irgendwie scheint mir, bernhard_LA ist nicht sehr offen für unseren Input

[bernhard_LA]

ich habe eine Installation meiner Software auf meinem Entwicklungssystem (incl. Delphi in einem anderen Ordner) ,
Jonny Walker moniert auch hier das Fast MM4 debug.dll und dir Borland Memory Manger DLL in der falschen CPU version vorhanden sind ... nur läuft meine Anwendung hier ohne Probleme.


Akutell versuche ich jetzt beide dlls als x64 Bit Version neu zu erstellen ( die Projekte gibt es im FASTMM4 Ordner)

[jaenicke]

Brauchst du denn Sharemem? Und FastMM im Full Debug Mode?
Beide sind eigentlich in der Regel in der Releaseversion überflüssig (wenn man nicht Schweinereien mit Stringparametern o.ä. in DLLs macht, dann braucht man Sharemem natürlich, aber dann sollte man eher die Schnittstelle sauber machen...).

[bernhard_LA]

FastDebugModeDLL habe ich in X64 jetzt auch schon entfernt,

sharemem ist halt in vielen DLLS enthalten wegen der String Übergabe ... bin mir nicht sicher ob ich so schnell auf
borland memory manger dll verzichten kann müsste die ganzen includes überarbeiten
suche die schnellste Lösung für mein Problem

[bernhard_LA]

problem gelöst Anwendung spielt :


BorlandDLL aus fastMM4 Versichnis (sourge forge) im x64 Bit Mode erstellt .... dann geht jetzt

[himitsu]

Die Unit SimpleShareMem in alle DPRs der DLLs und EXE an erster Stelle eintragen.
Fertig.


Die neue borlndmm.dll (die mit dem FastMM drin) ist nur ein Kompatibilitätsupgrade für alte Programme, also für den Austausch der borlndmm.dll mit dem alten BorlandMM drin.
Dort werden alle Speicheranfragen immer über diese zusätzliche DLL behandelt.

FastMM kann aber mehr:
Man kann diesem über ShareMemoryManager sagen, daß er sich verteilen/sharen soll.
- also entweder er Findet einen anderen FastMM in einer anderen DLL/EXE und verbindet sich dann dort hin (innerhalb des eigenen Prozessraums)
- oder er ist der Erste und bietet sich anderen FastMMs an

Delphi-Quellcode:

{Searches the current process for a shared memory manager. If no memory has
 been allocated using this memory manager it will switch to using the shared
 memory manager instead. Returns true if another memory manager was found and
 this module is now sharing it.}
function AttemptToUseSharedMemoryManager: Boolean;

{Makes this memory manager available for sharing to other modules in the
 current process. Only one memory manager may be shared per process, so this
 function may fail.}
function ShareMemoryManager: Boolean;

SimpleShareMem braucht keine DLL mehr, da hier der FastMM der ersten statisch geladene DLL verwendet wird.
Oder der FastMM der EXE, wenn alle DLLs dynamisch geladen werden.
Halt immer der er FastMM, welcher für das Sharing aktiviert wurde.