Just a bit of advice: I would setup your network code to be as event-driven as possible. Since you're assuming the socket has a minimum version of 2.0 you should be able to setup a non-blocking socket function quite easily.
If you want cross platform, one method might be to have a thread class that is system specific, but use the select method (which I'm sure is universal for standardized socket libraries on linux, unix, and mac).
Even if you only have 2 people chatting, it is worth making the effort to do the above.
Have some OS class that does all of your OS specific initialization which will include you starting and shutting down OS specific stuff (WSAStartup and include the function to release the library handle!)
Then build your network classes with client and server classes. Track all of your system variables and make sure your Network Manager class shuts everything down properly.
It might seem like I'm having a dig but I'm not: I think you have to get into the routine of seeing where to encapsulate functionality and especially where centralized flow control can and should be used: as a rule of thumb any system resource should be tracked by specific manager classes as well as OS classes. When you do something to an object, post an event message that any class can subscribe to. If something is destroyed one class can get messages and update things like pointer lists and so on.
Like I said, it might not be what you want to hear, but if you do this most of your problems will be solved when you think about the design and do so in a way that is optimal for what you want to do.