OpenNetworkConnectionUDP()

[hardfalcon]

@Danilo: das Argument, dass man lieber PB-Code anstatt von ASM-Code für PB-Procs nehmen sollte, leuchtet natürlich ein. (Warum zum Teufel bin ich da noch nicht drauf gekommen?)
Aber Deems optimierte Libs finde ich nicht bedenklich: wenn man diese Fehlerquelle ausgrenzen will, richtet man sich PB zweimal auf dem PC ein: einmal ungepacht, und einmal mit Deems Libs. Normal entwickeln tut man mit der ungepatchten Installation, und das Endprogramm kompiliert man dann mit der optimierten PB-Version, damit es schneller làuft. Wenn es später Bugs im Programm geben sollte, kann man das Programm ja immer noch mit dem original-PB kompilieren...

[Deeem2031]

ich warte bei jedem asm code den ich bisher postete, darauf dass ihn wer überprüft und mich auf eventuelle fehler bzw verbesserungen hinweist. siehe meinen kommentar zu meinem code hier. du bist einer der hauptkandidaten auf die ich zählte und kommst mir jetzt so, vielen dank! solltest dir an die eigene nase fassen, wenn du anstatt einer korrektur, nur einen blöden hochnäsigen kommentar über hast, aber mir vorwirfst die pb-user mit bugs sitzen zu lassen.

und wo da der fehler ist, sehe ich nicht, da die struktur WSADATA 400 Bytes groß ist.

Okok, will mal nicht so sein. Ein Beispielcode der das Problem verdeutlicht:

Code: Alles auswählen

Procedure OpenNetworkConnectionUDP(ServerName$, Port.l) 
  !Conn equ Esp+8 
  !Wsa  equ Esp+24 
  !Sock equ Esp+424 
  
  WsaData.WSADATA 
  Connection.SOCKADDR_IN 
    
  ;Dein Code ändert ja irgendwas an Sock:
  !MOV dword[Sock], 0 ;Die Konstante ist nicht so wichtig 
  
  ;Der Rest des Codes ist für das Beispiel irrelevant, da er nicht Esp beeinflusst
    
  ;;;;;;;;;;;;; 
  !Restore Conn 
  !Restore Wsa 
  !Restore Sock 
EndProcedure

!MOV Edi, 12345
OpenNetworkConnectionUDP(ServerName$, Port.l) 
!MOV dword[v_test], Edi
Debug test

Du definierst dein "Sock" an der Position an der (wenn mans mit dem orginalen PB (ohne Optimierer etc.) compilert) Edi gespeichert wird. Man muss dazu nämlich wissen, das sich der Stack (Esp) "verkleinert" und nicht vergrößert wenn man etwas darauf pusht. Du musst also entweder noch eine Variable Sock.l in der Procedure definieren. Oder diese von Hand pushen.
Wenn du keine anderen Proceduren aufrufen und nichts Pushen/Popen würdest, könntest du die Variable sogar als Esp-4 definieren. Ist allerdings nicht zu empfehlen, bzw. nur bei sehr kleinen und zeitkritischen Proceduren ratsam.

Und reg' Dich nicht wegen Deeem auf - ich halte seine Library-Hacks
für schlimmer. Die kann auch niemand einsetzen, da man damit
keine Garantie mehr hat das PB ordentlich läuft.

Man braucht keine Garantie damit man mit Purebasic arbeiten kann.
Außerdem ist die "Garantie" von Purebasic sowieso etwas fragwürdig, wenn nach mehreren Monaten, wenn nicht sogar Jahren Bugs immernoch nicht geflickt wurden

Könnten ja Bugs drin sein - womit man gegenüber Fantaisie Software
jeden Anspruch auf ein korrekt laufendes PureBasic verliert.

Wie man an meiner Signatur sieht, sind auch Bugs drin (gewesen). Wer die Libs benutzt muss nunmal damit rechnen. Ich selber benutzte die Libs auch nicht ständig. Das Risiko das Bugs durch die Libs entstehen ist einfach zu groß, als würde ich sie auch beim entwickeln der Programme benutzen.

Als nächstes wird der Compiler von PB-Usern hier auch noch
ersetzt oder gepatcht, da bin ich mir schon fast sicher.

Wenn das so einfach wäre hatte ichs schon längst gemacht, aber leider ist der CompilerCode nicht so schön übersichtlich, wie die von ihm erstellten Codes (Für alle dies nicht verstanden haben: Der Asm-Code von Purebasic-Programmen ist durch die wenigen Optimierungen des Compilers sehr viel besser lesbar als der Asm-Code, der von "guten" Compilern ausgespuckt wird)

[MLK]

hatte mich schon gewundert warum es läuft, obwohl ich sock.l nicht deklariere. danke für die aufklärung, auch wenn ich sie mir auf einem anderen wege gewünscht hätte.

[Deeem2031]

Da fällt mir noch was dazu ein:

Als nächstes wird der Compiler von PB-Usern hier auch noch
ersetzt oder gepatcht, da bin ich mir schon fast sicher.

jaPBe "patcht" den Compiler doch schon seit längerer Zeit. Patcher für den Compiler gibts also schon längst