Seriously though - looking how many P2P clients out there have IRC support, how many of them actually have a decent IRC support? Or, while we'r at the topic, how many multi-network IM clients have IRC module, and how many of them actually work? Or, while we'r on the topic, how many BT clients are out there, and how many of them actually work?

I was hanging in #azureus channel today, getting some intel [sic] about Bittorrent protocol and such. In particular, I was looking for info on the 'key' parameter in tracker communication, which was apparently needed by some trackers. It's used to keep track of clients after IP changes, and works somewhat similarly to ed2k userhash, except that it should be re-generated every startup. This is now properly supported in Hydranode. Another thing that came up during discussion was that it's required by Bittorrent netiquette to cap download-rate at 2xuploadrate when upload speed limit is less than 5kb. This is quite similar to ed2k netiquette, so implementing this was trivial.

Yet another interesting thing that came up during discussion was that there are actually more bad BT clients out there than there are good ones. And of-course, it was mentioned that BT support in multi-network applications is notoriously bad - mldonkey and shareaza being examples of that. Ohwell, yet another challenge for Hydranode to prove - that it's actually possible to have good BT implementation in multi-net client. Personally, I think it's doable, but it won't be easy. We still have quite a bit of issues to be resolved before Hydranode's BT implementation can be considered anywhere near good.

I'v been playing around with various versions of MSVC past few days, attempting to restore full MSVC compatibility in Hydranode code. The actual problems were rather trivial, some missing DLLEXPORTS here and some overloaded functions that confused the crap out of MSVC; at the end of the day, I can conclude that we have full compatibility with MSVC.NET 2003, mostly-compatible with MSVC Toolkit 2003 (free commandline tools), and mostly-compatible with MSVC 2005. The problem with MSVC Toolkit is that it lacks some combinations of runtime libraries, namely multi-threaded debug dll, and some more, so we must use explicit runtime-link=static runtime-debugging=off when building with that. As for MSVC 2005, it has introduced DLL versioning, and enforces it quite aggressivly, but I don't know enough yet about the topic to be able to implement the support. Btw, MSVC 2005 is also doing rather aggressive security checking on the code, but that triggers on a lot of valid Hydranode and Boost code as well, and as Boost people generally recommend turning that stuff off, so I did.

There were several reasons for restoring MSVC compatibility. For one, windows people expect to use MSVC for plugin-development and such; secondly, MSVC generates, on average, 4 times smaller code than GCC, and compile times are considerably faster (even without using precompiled headers). The main issue with mingw-gcc is link times, linking hydranode dlls or modules (average 100mb object files and 70mb final dll in debug build) took about a minute with mingw-gcc, but 7 seconds with MSVC. On Linux, it also takes roughly 7 seconds to link that, so it's clearly a mingw-gcc-specific issue. Another thing that MSVC seems good about is release-compilation - 14 minutes, which is roughly same as in debug build; release builds on gcc/linux are well over 20 minutes. In any case, getting Hydranode installed size from 15.0MB to 4.4MB, and installer size from 3MB to 960kb is pretty nice. Memory usage in release build dropped about ten times, from 13MB to 1.3MB, and from the looks of it, it's no longer using any CPU at all. This is what you get for developing on a slow compiler/platform for 1.5 years, and then recompiling the thing with a "real" compiler :)

Madcat, ZzZz

Edit: The memory usage didn't drop ten times, but only about two times. Looking at task-manager while half-asleep isn't such a good idea after-all. Sorry for the confusion.