🚀 go-pugleaf

Remy Lebeau (TeamB) wrote:

>> Would it cause run-time conflicts if he used the 2
>> winsocks in different modules?
>
>It would cause compile-time conflicts.  #define statements are global in
>nature.  winsock2.h disables winsock.h via a #define, so if one module
>includes winsock2.h first, the other module will likely fail to compile
>since winsock.h will be disabled from declaring anything that the module is
>using.

Sorry, in my world, different modules produce different OBJs
So a module that includes <Indy> and uses Indy functions should
compile, and a module that contains <winsock> and calls naked sock
functions should compile. The linker should be able to combine them.
But I wonder how it would decide which Sock.DLL to bind each obj to.
That's probably the problem with that.

>> Write Indy code in one, and Winsock code in another?
>
>The only reliable way I know to do that is to put each module into its own
>separate DLL.

Yeah, that'd work.

'Course, it'd be easier for the OP to just use the winsock2 functions.
Or the Indy functions as you mentioned.

Only things I think I saw missing from winsock2 were ip-multicast and
SO_SYNCxxx and "other NT specific options"..