Strings in Delphi in DLL

[Blatt]

Hi,
ich wollte in einer DLL String-Typen benutzen, aber irgendwie läuft da was schief.

Die Funktion erwartet einen PChar-Parameter und soll zur einfacheren Bearbeitung Delphi-Strings benutzen, da ich z.B. unter anderem Copy und Pos verwende.
Teilweise funktioniert das (da kann ich mir dann den einen oder anderen String ausgeben lassen) und mitten in der Funktion stürzt das Programm dann ab.
Das mit ShareMem bei String-Benutzung habe ich nicht so ganz verstanden und ich dachte, das sei auch nur notwendig, wenn man entweder einen String entgegen nimmt oder zurück gibt..
Bräuchte Hilfe..

[DeddyH]

Wie wäre es denn mit etwas Quelltext (am Besten mit Markierung der Zeile, die den Fehler verursacht)?

[Blatt]

Ich habe den Code mittlerweile geändert, aber den Fehler gerade rekonstruiert:

Delphi-Quellcode:

type
  Pfoo = ^foo;
  foo = record
    other: Word;
    buf: Array of Char;
  end;

procedure test(buf: PChar);
var
  bar: Pfoo;
  lol: string;
begin
  bar := Pfoo(buf);
  lol  := String(@bar.buf);
  lol  := Parse(':', lol, 2);
  if Parse(' ', lol, 1) = 'hello' then
    MessageBox(0,0,0,0);
  MessageBox(0,PChar(lol), PChar(Parse(' ', lol, 1)),0);
end;

Wenn buf gleich 'x:hello' ist, erscheint die erste MessageBox nicht (die zweite zeigt 'hello' und '' im Title an), da Parse '' zurückgibt, wobei es eigentlich 'hello' sein sollte. Und wenn buf gleich 'x:hello 3' ist, stürzt das Programm ab.

Parse ist von hier:
http://www.delphipraxis.net/151836-s...r-zaehlen.html

[DeddyH]

Ich verstehe nicht ganz, wieso Du einen Record nach PChar castest. Wenn Du die Word im Record brauchst, wäre es doch IMO sinnvoll, eine Unit mit der Record-Deklaration zu erstellen und diese in der DLL und dem Programm einzubinden.

[Blatt]

buf ist ein Buffer für Nachrichten über Winsock.
Ich gucke gerade, ob ich den Fehler auch in einer Standalone-Dll rekonstruieren kann.

Seltsamerweise funktioniert es gerade, wenn ich String(PChar(@bar.buf)) schreibe.
Soweit ich mich erinnere, hatte ich das davor schonmal, ohne dass es funktionierte..

[himitsu]

PS: ein Delphi-String ist auch nur ein aufgemotztes dynamisches Array ... also sollte man, bei Übergabe von dynamischen Arrays ebenfalls ShareMem einsetzen.

ShareMem sollte immer eingesetzt werden, wenn Speicher, der über den Delphi-Speichermanager läuft, über Modulgrenzen hinweg verwendet/verändert wird.

Bei diesen delphieigenen Typen, welche automatisch verwaltet werden, kann man nie genau sagen wann ein verändernder Zugriff auftreten kann, also sollte man immer ShareMem einsetzen.



Und das mit dem PChar<>Record versteh ich auch nicht,
außerdem fehlt auch noch der Zugriff auf Seite der EXE, welchen du uns vorenthältst.



Wenn Strings/DynArray nur innerhalb einer EXE oder DLL verwendet werden, aber nicht über die Modulgrenzen hinweg genutzt werden (z.B. nicht als Parameter übergeben),
dann muß ShareMem nicht verwendet werden.

ShareMem ist halt nötig, wenn Beide Resourcen (in diesem Fall den Speichermanager) gemeinsam verwenden wollen.

[Blatt]

Zitat:

außerdem fehlt auch noch der Zugriff auf Seite der EXE, welchen du uns vorenthältst.

Ne, das ist einfach nur eine Nachricht über Winsock, die halt so wie das Record aussieht, zuerst ein Word, dann ein Nullterminierter String.

Ich möchte diesen String halt als Delphi-String haben. Die Adresse ist [Winsock-buf-ptr] + OffsetOf(Record-buf), deswegen -- bar := Pfoo(buf); lol := String(PChar(@bar.buf)); --


Und weil das mit den Strings nicht funktionierte, habe ich das jetzt mit PChars gemacht.
Und ein PChar zeigt bei 'hello 3' auf das '3' -- MessageBox(0,numberptr,0,0); -- funktioniert also.
Bei -- MessageBox(0,PChar(StrToInt(String(numberptr))),0, 0); -- stürzt das Programm allerdings ab..




Ich versuche gerade den Fehler in einer Standalone-Dll zu bekommen (also ohne den Client und die Winsock-Nachrichten):

Delphi-Quellcode:

procedure test(buf: PChar);
var
  bar: Pfoo;
  lol: string;
begin
  bar := Pfoo(buf);
  lol := String(PChar(@bar.buf));
  lol := Parse(':', lol, 2);
  if Parse(' ', lol, 1) = 'hello' then
    MessageBox(0,'','',0);
  MessageBox(0,PChar(lol), PChar(Parse(' ', lol, 1)),0);
end;

procedure main(reason: dword);
var
  x: Pointer;
  a: Pfoo;
  l:integer;
begin
  case reason of
    1234:
    begin
      l:=Length('');
      GetMem(x, 8);
      a := x;
      a.other := 2;
      Move('hello', a.buf, 6);

      test(PChar(x));
    end;
  end;
end;

begin
  DLLProc := @main;
  main(1234);
end.

Und da ist jetzt das Problem, dass bei -- lol := Parse(':', lol, 2); -- kein leerer String, sondern 0 zurückgegeben wird.
Deswegen kommt bei -- if S[Length(S)] <> Char then -- (aus der Parse-Funktion), aufgerufen durch -- if Parse(' ', lol, 1) = 'hello' then --, ein Fehler, da S = 0/nil ist.
Aber das ist glaub ich wieder ein anderer Fehler.....



Ist auch egal, ich beschreibe das alles viel zu schlecht, muss ich halt gucken, was ich mache
Danke für eure Hilfe!

[kschit]

Also, wenn Du mit DLL's arbeitest, die an eine andere DLL übergibst und wieder was zurückbekommst solltest Du dringend FastMM oder ShareMemory verwenden. Einfach die Beispiele bei FastMM anschauen!!! Ist auch mein persönlicher Favorit!

Bei FastMM darauf achten, dass in der inc-Datei die Einstellungen für Shared DLLs eingeschalten sind!!!

Dann kannst Du auch beliebig Strings zwischen den beiden Teilen verarbeiten.

In den älteren Delphi-Versionen wird kein gutes Memory-Managment was die Arbeit mit DLL's anbelangt verwendet. Da wird ein String zwar definiert, ist dann aber nur eine Speicheradresse, die übergeben wird. Die kennt aber die DLL nicht.

Klaus

[Blatt]

Ne ^^ (aber vielen Dank für die Information)
War 'ne miese Beschreibung meines Problems, sorry..
Die Dll kommt in einen Prozess und die Funktion wird nach recv aufgerufen.
Da sieht der Buffer dann halt so aus wie das Record.
Und die Nachricht, die in dem Buffer nach dem recv (Buffer sieht dann z.B. so aus: 02 00 'h' 'i' 00 | Word und String-'\0') steht, möchte ich in einem Delphi-String haben.

[himitsu]

Man kann nicht einfach so einen Record via Socked verschicken, in welchem solche dynamische Elemente (DynArray, String, Objekt usw.) enthalten sind.

Im Record liegt von dem dynArray nur ein Zeiger, die Arraydaten verstecken sich wo anders und werden nicht mit verschickt.

Zitat:

GetMem(x, 8);

Für derartige Records reserviert man besser über New und Dispose den Speicher.
Nicht über GetMem/GetMemory und gibt sie erst ggarnicht über FreeMem wieder frei.

Move('hello', a.buf, 6); .
Ab Delphi 2009 tritt man mit der festen 6 in ein schönes Unicode-Fettnäpfchen.
Außerdem hast du vergessen für das dynamische Array vergessen Speicher zu reservieren > SetLength.
Und das Move überschreibt hier den internen Zeiger und schreibt nicht in den Datenbereich des Arrays.

Delphi-Quellcode:

foo = record
  other: Word;
  buf: Array[0..0] of AnsiChar;
end;

- Ansi zur Vorsorge wegen eventuellem Unicode-Compiler
- über GetMem dann genügend Speicher für den gesamten Text reservieren.

Delphi-Quellcode:

Text := 'hello';  // Text = AnsiString
GetMem(a, 2{other} + Length(Text) + 1{#0});  //a := GetMemory(2{other} + Length(Text) + 1{#0});
a.other := 2;
Move(Text[1], a.buf[0], Length(Text) + 1);

Da in diesem Beispiel ein statisches Array verwendet wird, könnte man hier die [0] zwar weglassen, aber zur Sicherheit macht es sich mit [0] besser und vom Compilat her ist das Ergebnis so oder so gleich.