© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
UPnP_COM is the COM (so Win-specific) interface which is the "horrible" code Razzloss has seen before. it can definitely not be ported; moreover, it is still partial, it implements the bare minimum interfaces and that is why it fails in cases where routers take a bit longer than usual to respond, or when the Windows service is inexplicably "busy".
regardless if we use the COM interface or MiniUPnP, the GUI freezes for a couple of seconds at startup, which is annoying. since moving to the dcpp lib has been mentioned, would it be acceptable to create an UPnPManager class that would run in its own thread? it would also handle fallbacks to a different UPnP lib when one fails; at the moment, it is the code responsible for the main window GUI that handles this, which feels odd.
in that case, UPnP_COM can remain in win32/, and the win32 code can call dcpp::UPnPManager and tell it that the UPnP_COM interface is also available should it be needed (in most cases, MiniUPnP should work so UPnP_COM shouldn't even be needed).
about compiling MiniUPnPc for dynamic linking, it is quite easy, just one flag ("STATICLIB") to toggle. then again i haven't tried it on Linux but it can't be too hard...