DLL untersuchen

[Sven Lanoster]

Moin zusammen!

Ich habe eine DLL, die ohne Entwickler, Quellcode,
Schnittstellenbeschreibung oder Header-File daherkommt.

Ich glaube folgendes zu wissen:
- mit D2006 (oder so) erstellt - es steht "FastMM, Borland Edition" drin
- im uses (sic!) steht lmm - keine Ahnung, was das ist
- es wird keine *MM.dll geladen
- es werden Widestrings benutzt
- Aufrufkonvention ist register

Problem: Wie viele Parameter welchen Typs werden erwartet?

Idee: Ich lerne mal eben ASM und steppe lustig mit dem Debugger im
CPU-Fenster durch die DLL. Da muss doch einklich stehen, welche
Parameter die DLL aus den Registern und welche vom Stack holt. Und was
damit gemacht wird. Oder nicht?

Da ich inzwischen weiß, dass ich zu oft am Tag unterbrochen werde, um
sinnvoll im CPU-Fenster zu debuggen ("Ähh, warum zählt der da jetzt 54
zu ebx?"), frage ich hier mal, ist mein Vorhaben grundsätzlich
erfolgversprechend?

Oder verbrate ich unnötig Zeit und es ist unmöglich aus der
Implementierung der DLL auf die Parameter zu schließen?

Gruß,
Sven.

[Peter Below]

Post by Sven Lanoster
Moin zusammen!
Ich habe eine DLL, die ohne Entwickler, Quellcode,
Schnittstellenbeschreibung oder Header-File daherkommt.
- mit D2006 (oder so) erstellt - es steht "FastMM, Borland Edition"
drin - im uses (sic!) steht lmm - keine Ahnung, was das ist
- es wird keine *MM.dll geladen
- es werden Widestrings benutzt
- Aufrufkonvention ist register

register ist schon mal ungewöhnlich für eine DLL, damit ist sie
praktisch mit keiner anderen Sprache als Delphi verwendbar.

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?

Kannst Du nicht rausfinden ohne entsprechende Dokumentation.
Verschwende keine Zeit damit, es ist vermutlich sinnvoller, die
notwendige Funktionalität neu zu implementieren.

Post by Sven Lanoster
Idee: Ich lerne mal eben ASM und steppe lustig mit dem Debugger im
CPU-Fenster durch die DLL. Da muss doch einklich stehen, welche
Parameter die DLL aus den Registern und welche vom Stack holt. Und
was damit gemacht wird. Oder nicht?
Da ich inzwischen weiß, dass ich zu oft am Tag unterbrochen werde, um
sinnvoll im CPU-Fenster zu debuggen ("Ähh, warum zählt der da jetzt
54 zu ebx?"), frage ich hier mal, ist mein Vorhaben grundsätzlich
erfolgversprechend?
Oder verbrate ich unnötig Zeit und es ist unmöglich aus der
Implementierung der DLL auf die Parameter zu schließen?
Gruß,
Sven.

[Sven Lanoster]

Post by Peter Below

Post by Sven Lanoster
- Aufrufkonvention ist register

register ist schon mal ungewöhnlich für eine DLL, damit ist sie
praktisch mit keiner anderen Sprache als Delphi verwendbar.

Alle anderen Aufrufkonventionen führen sofort zu bösen Fehlern. Mit
register bekomme ich dagegen immerhin Datenmüll und Meldungen wie
"unbekannter User" zurück.

Außerdem sind sowohl das Programm als auch die DLL in Delphi
geschrieben, so dass register funktionieren kann. Ich weiß allerdings
nicht, ob der Entwickler sich einfach nicht um die Aufrufkonvention
gekümmert hat, oder ob das eine Art Absicherung sein soll, damit die DLL
nicht von jedem dahergelaufenem Programm benutzt wird.

Post by Peter Below

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?

Kannst Du nicht rausfinden ohne entsprechende Dokumentation.
Verschwende keine Zeit damit, es ist vermutlich sinnvoller, die
notwendige Funktionalität neu zu implementieren.

Das ist genau das, was ich machen soll. :)
Die DLL ist von uns. Leider ist bei einem Unfall der Quellcode und damit
die Doku verloren gegangen. Und der Entwickler dann auch. Alles ziemlich
lange her.

Übrig ist ein Programm beim Kunden, welches nicht geändert werden
kann/darf/soll. Dieses Programm soll sich mit der DLL bei unserem CRM
anmelden und dort etwas abfragen. Die DLL ist also winzig.

Ich muss also eine neue DLL bauen, welche die selbe Schnittstelle hat
wie die alte DLL, damit das Kundenprogramm ungeändert weiterarbeiten kann.

Gruß,
Sven.

[Marc Santhoff]

Post by Sven Lanoster

Post by Peter Below

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?

Kannst Du nicht rausfinden ohne entsprechende Dokumentation.
Verschwende keine Zeit damit, es ist vermutlich sinnvoller, die
notwendige Funktionalität neu zu implementieren.

Das ist genau das, was ich machen soll. :)
Die DLL ist von uns. Leider ist bei einem Unfall der Quellcode und
damit die Doku verloren gegangen. Und der Entwickler dann auch. Alles
ziemlich lange her.
Übrig ist ein Programm beim Kunden, welches nicht geändert werden
kann/darf/soll. Dieses Programm soll sich mit der DLL bei unserem CRM
anmelden und dort etwas abfragen. Die DLL ist also winzig.
Ich muss also eine neue DLL bauen, welche die selbe Schnittstelle hat
wie die alte DLL, damit das Kundenprogramm ungeändert weiterarbeiten kann.

Und die DLL wird nur bei diesem Kunden benutzt?

Wenn zumindest ein Testprogramm noch aufzutreiben wäre, hättest Du es
leicht(er).

Ansosnten: wenn der Kunde über das Problem informiert wäre, könnte er
Dir mit seinem Code helfen. Schließlich muß der die DLL ja irgendwie
eingebunden haben.

Marc

[Sven Lanoster]

Post by Marc Santhoff
Wenn zumindest ein Testprogramm noch aufzutreiben wäre, hättest Du es
leicht(er).

So gute Idee, dass ich das Archiv des Fileservers nach dem Namen der DLL
durchsuchte und tatsächlich fündig wurde.

Ein Java-Programm. Von Java weiß ich nur: "Benutze die
StringBuilder-Klasse!". Vom ASM in die Traufe oder so.

Also mal eben Java lernen: man kann in Java DLLs einbinden, indem man
das Java-Native-Interface benutzt. Und die DLL benutzt tatsächlich eine
JNI.pas. Aber der Funktionsname "Anmelden" wäre so nicht in Ordnung.
Stattdessen müsste er "java_bla_foo_anmelden" (oder so) heißen. Und
tatsächlich gibt es sowas in der DLL. Von mir bisher völlig ignoriert.

Dann schauen wir uns die .class mal im Editor an und finden dort
(sinngemäß, aus dem Kopf): "java_bla_foo_anmelden (java/lang/string):
(java/lang/string)". Volltreffer! Ein String rein und einer raus. Und
was ist ein string in Java? Ein UnicodeString. Und wieso funktioniert
das? Weil die JNI.pas ein wenig Magie betreibt. Dafür werden noch zwei
weitere Parameter übergeben. Einer für die (Java-) Umgebung und einer
auf die Instanz der aufrufenden Java-Klasse.

Der Gedanke, in Delphi ein Testprogramm zu schreiben, welches diese
Schnittstelle bedient, führte unmittelbar zu Unwohlsein und Kopfschmerzen.

Aber ich weiß jetzt, dass die andere Anmelden-Funktion zum arbeiten eine
Zeichenkette braucht und eine zurück liefert. Könnte zumindest so sein.

Also: nichts für ungut. :)

Gruß,
Sven.

[Marc Santhoff]

Post by Sven Lanoster

Post by Marc Santhoff
Wenn zumindest ein Testprogramm noch aufzutreiben wäre, hättest Du
es leicht(er).

So gute Idee, dass ich das Archiv des Fileservers nach dem Namen der
DLL durchsuchte und tatsächlich fündig wurde.
Ein Java-Programm. Von Java weiß ich nur: "Benutze die
StringBuilder-Klasse!". Vom ASM in die Traufe oder so.

JNI hab ich selbst schon benutzt, kam mir nicht so schwierig vor. Ist
aber alles Äonen her, deswegen kann ich erstmal nur sagen: mach dich
nicht selbst irre.

Problem scheint noch zu sein, daß Java in eurer DLL eine
Sonderbehandlung bekommt, das deutet schon auf Allozierungs- oder
andere Probleme hin, Übergabekonvention wahrscheinlich.

Post by Sven Lanoster
Dann schauen wir uns die .class mal im Editor an und finden dort
(java/lang/string)". Volltreffer! Ein String rein und einer raus. Und
was ist ein string in Java? Ein UnicodeString. Und wieso funktioniert
das? Weil die JNI.pas ein wenig Magie betreibt. Dafür werden noch
zwei weitere Parameter übergeben. Einer für die (Java-) Umgebung und
einer auf die Instanz der aufrufenden Java-Klasse.

Das hilft für Java, für den Rest eher nicht. Mit welcher Technik
schreibt denn der/die Kunde(n) ihre Programme?

Post by Sven Lanoster
Der Gedanke, in Delphi ein Testprogramm zu schreiben, welches diese
Schnittstelle bedient, führte unmittelbar zu Unwohlsein und
Kopfschmerzen.

Schreib doch einfach mal eine Test-DLL und teste die mit dem
Java-Testprogramm. Dann übersetze Das nach Object Pascal. Oder so. ;)

Die nächste Keule, die ich tief unten im Keller suchen würde, wären
De-Compiler. Für Java ist das kein besonderes Problem, für Delphi aber
schon.

Ich erinnnere mich an einen Namen DCC(.exe), der das konnte. Muß
so ca. zu Zeiten von Delphi 2 gewesen sein. Das Teil wurde im
akademischen Rahmen von einer Frau geschrieben und war damals zumindest
vorübergehend als Binäres verfügbar, Quelltext nie.

Oder frag Dekompilations-Gurus bzw. Leute, die Delphi gut genug von
innen, also den generierten Code, kennen. Dürfte besser gehen, als wenn
Du ohne Assemblerkenntnisse da rumbastelst.

Marc

[Marc Santhoff]

Post by Marc Santhoff
Ich erinnnere mich an einen Namen DCC(.exe), der das konnte. Muß

Sollte DDC(.ex) heißen...

Marc

[Hans-Peter Diettrich]

Post by Sven Lanoster
Die DLL ist von uns. Leider ist bei einem Unfall der Quellcode und damit
die Doku verloren gegangen. Und der Entwickler dann auch. Alles ziemlich
lange her.

Das erinnert mich an die zahlreichen Bettelbriefe, als ich meinen VB3
Discompiler veröffentlicht hatte ;-)
Die wildeste Erklärung war ein Autounfall, bei dem (angeblich) der
Entwickler mit seinem Auto gegen einen Brückenpfeiler geknallt ist,
woraufhin er und sein Laptop mit dem ganzen Code verbrannt ist. Ich habe
nicht weiter nachgefragt und mir gedacht, daß so viel Phantasie auch
belohnenswert wäre.

BTW für Delphi wollte ich keinen Decompiler entwickeln, um Mißbrauch
erst garnicht zu ermöglichen. Was wäre euch denn so ein Programm bzw.
die Rekonstruktion eurer DLL wert?

Post by Sven Lanoster
Übrig ist ein Programm beim Kunden, welches nicht geändert werden
kann/darf/soll. Dieses Programm soll sich mit der DLL bei unserem CRM
anmelden und dort etwas abfragen. Die DLL ist also winzig.
Ich muss also eine neue DLL bauen, welche die selbe Schnittstelle hat
wie die alte DLL, damit das Kundenprogramm ungeändert weiterarbeiten kann.

Sollten dann die Aufrufe nicht im Programm des Kunden drinstehen? Eine
entsprechende Nachfrage ist zwar peinlich, dürfte aber am schnellsten
zum Erfolg führen - der Kunde dürfte ja auch daran interessiert sein,
daß seine Programm weiterhin läuft.

DoDi

[Hans-Peter Diettrich]

Post by Sven Lanoster
Moin zusammen!
Ich habe eine DLL, die ohne Entwickler, Quellcode,
Schnittstellenbeschreibung oder Header-File daherkommt.
- mit D2006 (oder so) erstellt - es steht "FastMM, Borland Edition" drin
- im uses (sic!) steht lmm - keine Ahnung, was das ist
- es wird keine *MM.dll geladen
- es werden Widestrings benutzt
- Aufrufkonvention ist register

Das ist etwas verwirrend. Von welchen "uses" redest Du da? Woher weißt
Du, welche DLLs geladen oder benutzt werden?

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?

Woher kennst Du die Namen der Prozeduren, die aufgerufen werden sollen?

Post by Sven Lanoster
Idee: Ich lerne mal eben ASM und steppe lustig mit dem Debugger im
CPU-Fenster durch die DLL. Da muss doch einklich stehen, welche
Parameter die DLL aus den Registern und welche vom Stack holt. Und was
damit gemacht wird. Oder nicht?

Wie willst Du eine Prozedur aufrufen, ohne zu wissen, welche Parameter
vor dem Aufruf in den Stack gelegt werden müssen?

Post by Sven Lanoster
Da ich inzwischen weiß, dass ich zu oft am Tag unterbrochen werde, um
sinnvoll im CPU-Fenster zu debuggen ("Ähh, warum zählt der da jetzt 54
zu ebx?"), frage ich hier mal, ist mein Vorhaben grundsätzlich
erfolgversprechend?

Kommt drauf an, wieviel Zeit in die Forschungsarbeiten gesteckt werden kann.

Post by Sven Lanoster
Oder verbrate ich unnötig Zeit und es ist unmöglich aus der
Implementierung der DLL auf die Parameter zu schließen?

Ich würde einen Disassembler oder Decompiler benutzen, um mehr über die
DLL zu erfahren. Kennst Du IDA?

Wenn es eine Delphi DLL ist, könnte alles Wissenswerte in der
enthaltenen TypInfo drinstehen, bei einer C++ DLL in den mangled names.
Wenn die DLL objekt-orientiert ist (Klassen definiert), dann kommt man
ohne minimale Kenntnis dieser Klassen nicht weit, d.h. beim Durchsteppen
könnte schon beim ersten Aufruf einer Methode alles crashen.

DoDi

[Sven Lanoster]

Post by Hans-Peter Diettrich

Post by Sven Lanoster
Ich habe eine DLL, die ohne Entwickler, Quellcode,
Schnittstellenbeschreibung oder Header-File daherkommt.
- mit D2006 (oder so) erstellt - es steht "FastMM, Borland Edition" drin
- im uses (sic!) steht lmm - keine Ahnung, was das ist
- es wird keine *MM.dll geladen
- es werden Widestrings benutzt
- Aufrufkonvention ist register

Das ist etwas verwirrend. Von welchen "uses" redest Du da? Woher weißt
Du, welche DLLs geladen oder benutzt werden?

Ausführbarer Code unter Windows ist im PE-Format. Siehe zum Beispiel:
http://imgur.com/a/t33Rr#2vWH5
Da steht drin, welche DLLs geladen werden. Das ist einfach. Der
Dependency-Walker ist ein nettes Tool, um sich einen ersten Überblick zu
verschaffen.
Das Uses ist etwas komplizierter, steht aber natürlich auch in der DLL.
Um es mir etwas leichter zu machen, habe ich dafür DeDe benutzt, der
listet das recht übersichtlich auf.
Problematisch sind dann nur noch Funktionalitäten, die per
Ole/COM/ActiveX per später Bindung zur Laufzeit nachgeladen werden. Aber
die sind mir bekannt und zur Ermittlung der Schnittstelle egal.

Post by Hans-Peter Diettrich

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?

Woher kennst Du die Namen der Prozeduren, die aufgerufen werden sollen?

Mach mal eine DLL in einem robusten Texteditor auf (zum Beispiel
Notepad++). Die Namen der exportierten Funktionen stehen im Klartext
drin. Mit Pech sind sie mangled, aber ich habe an der Stelle Glück.

Post by Hans-Peter Diettrich

Post by Sven Lanoster
Idee: Ich lerne mal eben ASM und steppe lustig mit dem Debugger im
CPU-Fenster durch die DLL. Da muss doch einklich stehen, welche
Parameter die DLL aus den Registern und welche vom Stack holt. Und was
damit gemacht wird. Oder nicht?

Wie willst Du eine Prozedur aufrufen, ohne zu wissen, welche Parameter
vor dem Aufruf in den Stack gelegt werden müssen?

Ich weiß ja, was die DLL machen soll. Also so ungefähr sind die
Parameter bekannt.
Es gibt eine Funktion namens "Anmelden". Die wird vermutlich den User
und das Passwort brauchen. Vielleicht noch den Server und die Datenbank.
Und dann entweder einen Boolean oder ein Anmelde-Token zurückliefern. Da
kann man ja einfach mal raten:

function Anmelden(aUser, aPass: Widestring): Widestring; external ...

Zugegeben, so funktioniert es nicht. Im result stehen chinesische
Sonderzeichen und am Ende meiner ButtonClick-Testroutine ist der
Heap/Stack im Eimer. Aber immerhin, ich denke, ich bin nah dran.

Post by Hans-Peter Diettrich

Post by Sven Lanoster
Da ich inzwischen weiß, dass ich zu oft am Tag unterbrochen werde, um
sinnvoll im CPU-Fenster zu debuggen ("Ähh, warum zählt der da jetzt 54
zu ebx?"), frage ich hier mal, ist mein Vorhaben grundsätzlich
erfolgversprechend?

Kommt drauf an, wieviel Zeit in die Forschungsarbeiten gesteckt werden kann.

Die Alternative wäre, das Programm des Kunden, welches unsere DLL
verwenden will, neu schreiben zu lassen. Und das läge wohl so im unteren
sechsstelligen Eurobereich. Also ein Paar Tage habe ich wohl.

Post by Hans-Peter Diettrich

Post by Sven Lanoster
Oder verbrate ich unnötig Zeit und es ist unmöglich aus der
Implementierung der DLL auf die Parameter zu schließen?

Ich würde einen Disassembler oder Decompiler benutzen, um mehr über die
DLL zu erfahren. Kennst Du IDA?

Ja, IDA habe ich auch versucht. Der erzeugt jede Menge ASM der benutzten
Bibliotheken (Classes, ComCtrls, etc.) aber leider nicht der
exportierten Funktionen. Oder ich bin zu doof, das Tool korrekt zu
benutzen.

Post by Hans-Peter Diettrich
Wenn es eine Delphi DLL ist, könnte alles Wissenswerte in der
enthaltenen TypInfo drinstehen, bei einer C++ DLL in den mangled names.
Wenn die DLL objekt-orientiert ist (Klassen definiert), dann kommt man
ohne minimale Kenntnis dieser Klassen nicht weit, d.h. beim Durchsteppen
könnte schon beim ersten Aufruf einer Methode alles crashen.

Es ist eine Delphi-DLL. Die benutzten Units, Typen, Klassen und
Bibliotheken habe ich (und kenne ich). Und klar knallt es bei meinen
Experimenten immer mal spektakulär. Aber ich habe das Gefühl, dass ich
nah dran bin.

Ich muss jetzt "nur noch" herausfinden, wieviele Parameter rein gehen
(und ob das alles Widestrings sind) und was zurückkommt (Widestring oder
Boolean). Das sollte man doch anhand dessen erkennen können, was die DLL
macht. Dummerweise ist ASM so elend kleinschrittig, dass ich jedesmal
den Faden verliere und alles was dann kommt nur noch Addition und
Multiplikation irgendwelcher Speicherinhalte ist.

Gruß,
Sven.

[Hans-Peter Diettrich]

Post by Sven Lanoster
Das Uses ist etwas komplizierter, steht aber natürlich auch in der DLL.
Um es mir etwas leichter zu machen, habe ich dafür DeDe benutzt, der
listet das recht übersichtlich auf.

Ja, DeDe habe ich auch schon benutzt, sehr nett :-)

Post by Sven Lanoster
Mach mal eine DLL in einem robusten Texteditor auf (zum Beispiel
Notepad++). Die Namen der exportierten Funktionen stehen im Klartext
drin. Mit Pech sind sie mangled, aber ich habe an der Stelle Glück.

Mangled wäre eher der Glücksfall, da der Name dann genau die gesuchten
Informationen enthält.

Post by Sven Lanoster
Ja, IDA habe ich auch versucht. Der erzeugt jede Menge ASM der benutzten
Bibliotheken (Classes, ComCtrls, etc.) aber leider nicht der
exportierten Funktionen. Oder ich bin zu doof, das Tool korrekt zu
benutzen.

Einfach ist es nicht, das weiß ich von eigenen IDA Sessions. Aber im
Vergleich zu den von Windows intern verwendeten Aufrufkonventionen
sollte es doch relativ einfach sein, die Verwendung der übergebenen
Parameter im weiteren Code auszuknobeln. Für Windows hatte ich mir einen
eigenen Disassembler geschrieben, um all den Tricks und Verschleierungen
auf die Schliche zu kommen, die (zumindest 1994) im Systemcode verwendet
wurden. Und für C hatte ich schon in den 80ern einen sehr gut
funktionierenden Decompiler. Aber C ist ja auch so einfach gestrickt,
nicht viel mehr als ein High-Level Assembler, danach habe ich mich
wieder anspruchsvolleren Herausforderungen zugewandt ;-)

DoDi

[Sven Lanoster]

Post by Sven Lanoster
Ich habe eine DLL, die ohne Entwickler, Quellcode,
Schnittstellenbeschreibung oder Header-File daherkommt.
- mit D2006 (oder so) erstellt - es steht "FastMM, Borland Edition" drin
- es wird keine *MM.dll geladen

Es wird kein spezieller Memory-Manager benutzt.

Post by Sven Lanoster
- im uses (sic!) steht lmm - keine Ahnung, was das ist

Vermutlich die Import-Unit für den Microsoft Input-Method-Manager.
Jedenfalls kein Memory-Manager, also uninteressant.

Post by Sven Lanoster
- es werden Widestrings benutzt

Ja, aber nur intern. Nicht in der Schnittstelle. :(

Post by Sven Lanoster
- Aufrufkonvention ist register

Jup.

Post by Sven Lanoster
Problem: Wie viele Parameter welchen Typs werden erwartet?
Idee: Ich lerne mal eben ASM und steppe lustig mit dem Debugger im
CPU-Fenster durch die DLL. Da muss doch einklich stehen, welche
Parameter die DLL aus den Registern und welche vom Stack holt. Und was
damit gemacht wird. Oder nicht?

Grundsätzlich vermutlich schon. Aber hör auf das, was Peter Below sagte:
"Ohne Dokumentation wird das nichts!" (nicht wörtlich zitiert). Er hat
recht.

Post by Sven Lanoster
Da ich inzwischen weiß, dass ich zu oft am Tag unterbrochen werde, um
sinnvoll im CPU-Fenster zu debuggen ("Ähh, warum zählt der da jetzt 54
zu ebx?"), frage ich hier mal, ist mein Vorhaben grundsätzlich
erfolgversprechend?

Nein, ist es nicht. Du schreibst doch selbst, dass du zu blöd dazu bist.
Lass es sein, das CPU-Fenster ist nicht deins, das bringt dich nicht
weiter. Wer minutenlang über den tieferen Sinn von "XOR ebx, ebx; JZ
..." grübeln muss, sollte es lieber bleiben lassen.

Post by Sven Lanoster
Oder verbrate ich unnötig Zeit und es ist unmöglich aus der
Implementierung der DLL auf die Parameter zu schließen?

Unmöglich ist es bestimmt nicht. Schneller geht es, wenn Du mehr Infos
bekommst. Kollegen fragen, sich auslachen lassen, wenn man den Wunsch
äußert, das E-Mail-Archiv der Jahre 2005-2010 nach dem Namen der DLL
durchsuchen zu wollen. Oder im Archiv des Fileservers wühlen.

Und wenn man dann endlich weiß, dass zum Anmelden ein Anmeldetoken
benutzt wird, welches User/pass/server/DB-Name in einem String enthält
und man dann ein Sitzungs-Token zurückbekommt, welches wieder ein String
ist, dann kann man ja einfach mal durchprobieren:

function Anmelden(aInput: Widestring): Widestring; external...
*BOOM*
function Anmelden(aInput: shortstring): shortstring; external...
*BOOM*
procedure Anmelden(aInput: PChar; oBuffer: PCHar; aLen: integer): integer;
*BOOM*
function Anmelden(aInput: Unicodestring): Unicodestring; external...
*BOOM*
function Anmelden(aInput: Ansistring): Ansistring; external...

Nanu, so ruhig?
Tatsache, so funktioniert das. Ich kann das Result sogar zum Abmelden
benutzen. Und das alles ohne MM. *staun*

Zugegeben, mein Testprogramm enthält nur den einen ButtonClick. Und nach
An-/Abmelden beendet es sich und wird von Windows aus dem Speicher
geräumt. Da können keine großen Folgeschäden enstehen.

Wieso funktioniert das seit vielen Jahren auf dem Echtsystem des Kunden?

Die DLL muss den Speicher für den zurückzugebenen Ansistring selbst
anfordern. Die Funktion, die das tut, wird beendet, bevor die aufrufende
Methode beendet ist. Kann den also nicht freigeben. Die aufrufende
Methode darf den nicht freigeben, weil ihr MM den Speicher nicht
angefordert hat. Das sollte dann doch auch knallen, oder?

War der Entwickler ein Genie, weil er den RefCount im Ansistring
geschickt so manipuliert, dass die DLL den später freigibt? Zum
Beispiel, indem alle results in eine Stringlist geworfen werden. Und
wenn die beim Entladen der DLL freigegeben wird, haben wir das selbe
Ergebnis wie ganz ohne: der Speicher bleibt in der Laufzeit der DLL am
Leben.

Oder war der Entwickler ein Vollpfosten, da er dachte: "Solange der
Anwender nicht von Meldungen abgelenkt wird, ist alles in Ordnung"?

Vermutlich bin am Ende ich der Vollpfosten, da ich jetzt eine neue DLL
entwickel, welche als Schnittstelle einen Ansistring als result hat. *seufz*

Gruß,
Ingrid.