Background: A network-based service (tcp+udp, not http) exists with a soon-to-be public published C++ linux client API. This client API Uses normal tcp sockets, udp sockets, C++ namespaces and parts of the stl like std::map and std::vector, and will be published as a set of header files and .a and .lib files to link against.
Questions: Just starting to look into what it would take to port this C++ client API to Windows. Does it make sense to use gcc/g++ under Windows? My first inclination is this wouldn’t work since developers on Windows typically use the Microsoft Visual Studio suite, and they wouldn’t be able to link against the library produced by gcc. Is this a correct assumption, or does gcc provide some nifty switches which produces Microsoft-compiler and Microsoft-linker compatible output files?
As long as the compiler you’re using produces genuine .dll or .lib files, you shouldn’t have an issue linking them with a standard linker in Windows. However, only either unmanaged development (meaning classic Win32 API development) or C++/CLI will be able to link against these .dlls. If you compile to a .dll (not a .lib), you can target this assembly from within a managed context (C#, VB.NET, etc.) using P/Invoke syntax, but if all you’re doing is standard socket read/write operations, you’re probably better off writing a fully-managed implementation in .NET.
In the end it comes down to what audience you want to target: for classic Win32, you’re fine. For managed targets (anything .NET, aside from C++/CLI) then you’re better off writing a managed implementation in C# or VB.NET instead.