VB6 Syncronous Socket
Date: 03.20.16 - 11:14am
Ok, so sometimes with vb6 you want to do be able to make a server request, and receive the response back simply and inline, even if that hangs your application while its downloading.
(Note this is designed for quick transfers of small data and not file downloads, and I want complete control over all of the data sent so xmlhttp is out)
To have raw data access to what is sent, we typically use the mswinsck.ocx control. Its 122k and requires registration on the system. The part that sucks for my requirement though is that it is designed for async transfers. While this is usually whats appropriate for a GUI app, I need a sync send/recv fairly often.
Programming a synchronous layer on top of the async mswinsck control is not horrible, but it is annoying and can go wrong leaving you with hangs.
Between the size, registration, and having to force fundamentally different behavior upon the control, Its needless extra complexity.
I finally had a little time this weekend, and some appropriate C code in my lap that I decided to just tweak it into a small synchronous send/recv library for vb6.
The example I used is a http request just for demo, but really this is not for http, I would use xmlhttp for that. Its more for communicating with custom protocols text or binary.
Source and compiled versions are included in the github repository.
Thanks to arcomber for his 2012 stackexchange post for the majority of it.
The C dll compresses down to 27k and does not need to be registered in order to use. It can be called simply from a native vb wrapper with the following prototype:
Note: since the c dll really only uses the WinApi, this could be translated directly into a vb6 equivalent so you didnt have the external dll dependency. I found the C code so I just used it as is. If you translate it feel free to mail me and I will include it in the repo it would be a nice addition.
Misc note 2: I was looking at some other languages like D to see how easy they made this same operation. While other languages may look easier, the truth is its just the libraries they have built in that automate more. Even if you dont see it on the surface. And once you create a similar library for your language, that particular difference evaporates. (Not to say other languages dont have definite advantages, they do.)