Zitat von
jim_raynor:
Bin mir jetzt nicht sicher, aber theoretisch sind Dynamische Arrays genau wie Strings zu benutzen. Bei Strings musst du die
Unit Sharemem (oder ein gleichwertiger Ersatz) sowohl in dem Programm als auch in der
DLL einbinden.
Jupp, so ist es nicht nur mit Strings, sondern auch mit dynamischen Arrays. Zusätzlich muss die
DL BorlandMM.dll mit dem Projekt ausgeliefert werden, sonst versucht ShareMem vergeblich die
DLL zu laden.
In C werden dynamische Arrays als einfacher Pointer deklariert. Dieser zeigt auf das erste Element, mit malloc schnappt man sich dann seinen Speicher und gut iss. Das geht wunderbar, weil man in C Pointer genauso dereferenzieren kann wie ein Array, und der Compiler sorgt gleich dafür, daß die OFfsets stimmen, sollte es mal kein "array of Byte" sein. Dynamische Arrays (und alle dynamischen Sachen) sind unter Delphi allerdings eine Sache für sich und sind ohne Weiteres nicht mit dem Rest der Welt kompatibel, es sei denn man fummelt sich selbst durch die
RTL und schaut, wo man denn seine Referenzzähler erhöht und erniedrigt.
@egal: Wenn es also eine
DLL sein soll, die auch mit C und anderen Sprachen benutzbar sein soll:
- verzichte auf Strings und dynamische Arrays! PChar und Pointer auf den jeweiligen Datentyp sind zwar unter Delphi ein wenig umständlicher zu bedienen ("ein wenig" meine ich aber wirklich so, denn so sehr viel komplizierter wird's nicht), dafür funktioniert es aber mit jeder anderen Sprache auch.
- deklariere exportierte Funktionen unbedingt als stdcall oder als cdecl (letzteres ist die normale Calling Convention von C, möglicherweise wird sie aber von anderen Sprachen nicht unterstützt (VisualBasic?
), erstere sollte mit allen Sprachen funktionieren, die die Windows-
API benutzen können)