In meinem Code habe ich asynchrone E / A mit E / A-Abschluss-Ports und für den Lese- / Schreib-Abschluss Callbacks, bekomme ich ein HANDLE (das kann natürlich ein Socket, Datei-Handle, Named Pipe und so weiter sein). Wenn also in einer solchen Routine etwas nicht stimmt, möchte ich den Fehler überprüfen, aber wissen, ob es ein "Netzwerk" HANDLE [eine SOCKET, also WSAGetLastError ()] oder ein "Nicht-Netzwerk" HANDLE [Named Pipes] ist , Dateien usw., also sollte ich GetLastError ()] aufrufen? Ich benutze dafür eine einfache Flagge, aber sie ist hässlich und unzugänglich. Wenn jemand bestätigen kann, dass WSAGetLastError () nur ein Alias für GetLastError () ist, werde ich nur Letzteres verwenden.
Es scheint so:
Aber kann das jemand bestätigen? MSDN ist zu diesem Thema nicht sehr klar.
Und: wäre es sicher, GetLastError () anstelle von WSAGetLastError () zu verwenden? Ich meine, wenn WSAGetLastError () ist sogar ein Alias von GetLastError () seit Windows95 als jemand behaupten, ich könnte davon ausgehen, dass es für die nächste Version von Windows - aber wir können nicht guten Code auf die Annahme von Dingen :)
Grund hinter zwei ähnlichen Funktionen: Ссылка
Warum existiert die Funktion WSASetLastError, wenn es bereits die vollkommen gute Funktion SetLastError?
gibt?Eigentlich kennst du die Antwort auch, wenn du dich hinsetzt und darüber nachdenkst.
Winsock wurde ursprünglich entwickelt, um auf 16-Bit Windows und 32-Bit Windows ausgeführt zu werden. Beachten Sie, dass die klassischen Winsock-Funktionen auf Fenstermeldungen für asynchrone Benachrichtigungen basieren. In der 16-Bit-Welt gab es keine SetLastError-Funktion. Daher musste Winsock eine eigene Version für die 16-Bit-Implementierung bereitstellen. Und da Quellcode-Kompatibilität wichtig ist, gab es auch eine 32-Bit-Version. Natürlich sieht die 32-Bit-Version im Nachhinein irgendwie dumm aus, wenn Sie die 16-Bit-Version nicht kennen.
Tags und Links windows winapi networking network-programming