It seems that socket handles on Windows, at least under some conditions, may not exactly be handles.
You are not supposed to (for example) call CloseHandle or DuplicateHandle on them, although other windows handle APIs (ReadFile, etc.) will work. The stated reason for this is LSPs (or "Layered Service Providers") which seem to have been designed (and are most actively used) as a malware delivery vector. Sockets are not really sockets, but rather bits of code that get loaded into your address space to intercept all your socket calls. They have been severely deprecated in newer versions of Windows (so much so that you won't quality for the Windows logo program if your system uses them). What I want to know: - are LSPs the only reason that I can't use CloseHandle and DuplicateHandle on socket handles (ie: if there are no LSPs around, will everything be OK)? - how common are LSPs in practice? Another question: does anyone know of a scheme for detecting if a particular HANDLE is a socekt, in a non-destructive way? Doing various WSAIoctl operations on a non-socket will return an "operation not supported" error, but this same error is also returned if the particular socket type (or state) does not support the operation. Final question: it seems that calling closesocket() on non-sockets works correctly. For example, calling CreateEvent() and then closesocket() results in a successful return value from closesocket() and the expected behaviour of the same HANDLE number being reused for the next CreateEvent(). Does anyone have a good reason for why we shouldn't do that? Any input on this topic is highly welcome. Thanks in advance. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list