Probleme mit NetShareEnum

[CalganX]

Hi,
ich versuche gerade irgendwie alle Freigaben aufzulisten, aber trotzdem macht mir die WinAPI da einen Strich durch die Rechnung. Mit Hilfe der JEDI-Überestzung der lm.h rufe ich su NetShareEnum auf:

Delphi-Quellcode:

NetShareEnum(@sServer[1], 502, @aShareBuffer, MAX_PREFERRED_LENGTH,
          dwEntriesRead, dwEntriesRead, nil);

Dazu folgenden Variablen:

Delphi-Quellcode:

type
  PSHARE_INFO_502 = ^_SHARE_INFO_502;

var
  aShareBuffer, aWorkBuffer: PSHARE_INFO_502;
  dwEntriesRead: Cardinal;

Der Delphi-Compiler wirft mir aber hinter
@aShareBuffer, folgenden Fehler in's Gesicht:

Ausgabe des Compilers

[Fehler] MainUnit.pas(42): Die Typen der tatsächlichen und formalen Var-Parameter müssen übereinstimmen

Mir ist klar, was mir Delphi damit sagen will, aber in meinen Augen ist das alles richtig.

Die Definition der Funktion in den Jedi-Übersetzungen lautet so:

Delphi-Quellcode:

function NetShareEnum(servername: LPTSTR; level: DWORD; var butptr: Pointer;
  prefmaxlen: DWORD; var entriesread: DWORD; var totalentries: DWORD;
  resume_handle: PDWORD): NET_API_STATUS; stdcall;

Wo ist da der Hund begraben?

Chris

[OregonGhost]

Moin.
Also, wenn ich das richtig sehe, ist aShareBuffer ja ein Zeiger, nicht wahr?
Und ein var-Parameter vom Typ Pointer ist dann doch schon von sich aus ein Zeiger auf den Zeiger, oder?
Und folglich übergibst du mit @aShareBuffer einen Zeiger auf einen Zeiger, der aber durch das var nochmal referenziert wird, stimmt's?

Und wenn ich das tatsächlich richtig sehe, musst du einfach mal das @ vor aShareBuffer wegnehmen...

[CalganX]

Hi,
leider der exakt identische Fehler.

Chris

[OregonGhost]

Komisch, bei mir kompiliert das ohne das @...

[CalganX]

Hi,
dann stelle ich jetzt einfach mal die Behauptung auf, dass das daran liegt, dass du D3 hast und ich D7... Das wäre die einfachste Erklärung.
Aber irgendwie muss das doch gehen. Schließlich ist NetUserEnum (zum auflisten von Benutzern auf einem Rechner) nahezu identisch aufgebaut und dort hat es funktioniert. Als letzte Erklärung bliebe mir nur noch, dass es ein kleiner Fehler in der Headerübersetzung ist. Oder hat jemand eine andere Idee oder gar eine Lösung?

Chris

[OregonGhost]

Ich hab's in D4 probiert ;c)
Und extra für dich hab' ich's jetzt auch nochmal in D7Personal probiert und es funktioniert auch. Ich muss dazu sagen, dass ich nicht die Jedi-Header habe, sondern lediglich deine Deklaration inkludiert und wie folgt abgeändert habe:

Delphi-Quellcode:

  function NetShareEnum(servername: LPTSTR; level: DWORD; var butptr: Pointer;
  prefmaxlen: DWORD; var entriesread: DWORD; var totalentries: DWORD;
  resume_handle: PDWORD): Integer; stdcall; external 'netapi32.dll';

Ich habe also den Rückgabewert (der ja egal ist) geändert, weil der andere Typ nicht bekannt ist, und die external-Deklaration hinzugefügt. An der Parametern habe ich nichts gedreht. Und dann habe ich einfach einen untypisierten Pointer übergeben.
So, und jetzt habe ich mal probiert, einen Zeiger auf was anderes zu übergeben, und da bekomme ich denselben Fehler wie du. Also caste ich den Zeiger in einen Pointer, und siehe da, es funktioniert ;c)
Probier' also mal

Code:

Pointer(aShareBuffer)

zu übergeben.

[CalganX]

Hi,
super! Das funktioniert. Hätte man ja fast drauf kommen müssen. *g*

Allerdings werden mir jetzt immer nur die ersten Buchstaben der Ergebnisse angezeigt. Aber allen Anschein nach sind es wirklich die richtigen Freigaben, nur halt nur der 1. Buchstabe. Woran kann das jetzt wieder liegen?
Entweder bin ich heute nicht ganz fit oder ich bin - mal wieder - mit meinem WinAPI-Latein am Ende.

Chris

[OregonGhost]

Benutzt du 9x oder NT?
[Edit]Schon gut, hat sich erledigt, 502 wird von 9x ja gar nicht unterstützt ;c)[/edit]

Aber ich nehme an, du hast drauf geachtet, dass es sich um einen Unicode-String (d.h. WideChar) handelt?

[CalganX]

Hi,
nicht das ich wüsste. Was muss ich denn da spezielles beachten?

Chris

[OregonGhost]

Ich arbeite zu wenig mit Delphi (und mit Unicode (c; ), als dass ich wüsste, wie es Unicode handhabt. Aber WideChars bestehen im allgemeinen aus zwei Byte. Es ist also möglich, dass das jeweils erste Zeichen einen Code hat, der im ersten Byte dem Ascii-Code entspricht, im zweiten jedoch 0 ist. Und 0 ist bei AnsiStrings im allgemeinen das String-Ende-Zeichen. Du kannst mal ausprobieren, den Namen des Shares mit WideCharToString in einen normalen String umzuwandeln und dann schau mal, ob der dann richtig ist.