You're already linking against far larger libraries that you probably don't understand completely anyway! For example, glibc... So I don't think this is a valid excuse against the "HTTPS Everywhere" initiative.
That's not always true, especially if you're working in an embedded environment or you have other needs (business or legal requirements, even just preferences) to control the libraries you link with.
In the case of this video series, I won't be using any C runtime library functionality at all -- just Windows API calls. Of course, there's always the operating system, which is big and opaque. IMO, there's a difference between interfacing with the platform and dragging in a bunch of other people's code. That's a personal call: it's not a clear cut line, obviously.
Speaking personally, I more or less know, in general (and for Windows, in specific) how operating systems work. I don't have a strong understanding of encryption, which is heavily mathematical. In the case of OpenSSL, I am not likely to understand what it's doing. In the case of message queues, threads and blitting bitmaps, there's not much mystery there.
Also, the comments I'm making are specifically about this project, not generally about how I think everyone should work. It's clear that this is an art project and not industrial software.
I don't think I disagree with you in principle, but since you are linking in the windows socket library already, isn't there built in support for SSL (`WSASetSocketSecurity()`, etc)?
