Firon Posted October 14, 2007 Report Posted October 14, 2007 We would like to switch to MSVC2005 to avoid various compiler bugs in MSVC6 (our current compiler). These bugs cause crash issues and other strange problems that require a significant amount of development time to work around, time which could be spent fixing other problems and implementing various improvements.However, if we do this, µTorrent's filesize would increase 40-50k (packed). I'm making this post to hear your input on whether you guys would mind the size increase. The memory footprint and CPU usage would not change by any noticeable amount (either increase or decrease).We are also considering switching to an SSL library instead of using the built-in Windows functions. This would allow more parallel connections to a single server (wininet limits you to 2 at once to a particular server), avoid the annoying SSL certificate errors you sometimes get, and also allow the WebUI and embedded tracker to work over SSL without needing stunnel. This would also increase filesize anywhere from 30 to 50k. The memory footprint and CPU usage should also not be noticeably different.We will of course still strive to keep it as small as possible, as well as keep memory and CPU usage low.
TheBear Posted October 14, 2007 Report Posted October 14, 2007 I have no problems with these proposed changes.
Garugaga Posted October 14, 2007 Report Posted October 14, 2007 I don't think that file size is really a big deal. In these day of multi-megabit connections the changes would only cost a few seconds wait at the very most. I am all for the proposed changes.
hermanm Posted October 14, 2007 Report Posted October 14, 2007 Consider offering a torrent version of the download since most of us already have uTorrent. Hopefully, the increased file size will have less impact on your web server and we can all share in the bandwidth demands.
Honeyfrog Posted October 14, 2007 Report Posted October 14, 2007 100k is an almost negligible amount of data, but when five or six orders of magnitude are involved, it becomes a server issue. E.g., if 100,000 people downloaded 100kb, that'd be 9.5gb....if uTorrent is becoming truly insanely popular (I have no idea how many thousands of each release are downloaded), you may wish to implement an Azureus-style torrent updating scheme so the distributed user-base can carry the load rather than your own bandwidth.
krist0v Posted October 14, 2007 Report Posted October 14, 2007 Compared to other programs that see huge size increases for each new version, having a ~+100K for uT seems more than acceptable, especially if they allow you to deliver new features/improvements ;-)Keep up your good workChris
Switeck Posted October 15, 2007 Report Posted October 15, 2007 µTorrent has been kept ridiculously small for some time....There is no reason to keep doing so if it gets in the way of bug fixing and adding of very useful features.Even if µTorrent "bloats" to 1 MegaBYTE in size, it still would be the smallest feature-packed BitTorrent client. (There are smaller, but they lack features.)
Firon Posted October 15, 2007 Author Report Posted October 15, 2007 Millions, not thousands.We're going to switch to torrent-based upgrades for 1.8, but we still need to do one last release with plain old downloads for obvious reasons.
Ryan Norton Posted October 15, 2007 Report Posted October 15, 2007 Hopefully this doesn't convince people otherwise, as we are very focused on keeping it small - a lot of work has been done on 1.8 to remove some of the code bloat from 1.7, so despite having a lot of huge new features (some unannounced) it should be very similar in size; at least for now the goal is still to keep it as small as possible.
Lord Alderaan Posted October 15, 2007 Report Posted October 15, 2007 Although the very small packed download size is a fun extra (that speaks directly to the less computer savvy amongst us) it has always really been about the memory footprint and the resource consumption that gave µtorrent its sleek reputation. I think keeping the packed size small should be a consideration, yes. But it should be secondary to most other aspects of the program (which includes stability).So a different packer wouldn't really matter in that aspect. Besides a 300kb download is still relatively small compared to the size of the torrents that will be downloaded using µtorrent.What is the impact of the SLL library on the memory footprint. And will it make running µTorrent (all things considered) on slow machines and old windows versions more problematic or is the effect negligible?I myself don't mind much because I run µtorrent on the background of a powerful machine and it has virtually no inpact on any of the main applications. Even if you doubled the CPU usage I don't think I'd notice. But I think the above questions are the most relevant to the people who really value the sleekness of µtorrent above all else.
Firon Posted October 15, 2007 Author Report Posted October 15, 2007 If we changed, we'd use MSVC2005 (instead of 2008) to keep compatibility with Windows 9x.The memory footprint and CPU usage would be essentially identical. (maybe an increase of 50kB of RAM usage, lol).
Saribro Posted October 15, 2007 Report Posted October 15, 2007 I think keeping the packed size small should be a consideration, yes. But it should be secondary to most other aspects of the program (which includes stability).That's pretty much my sentiment too. In the end, we're still talking about a full-featured client, compatible over multiple generations of Windows (and some other OSes, with help), in less than 512kiB... .The ~45k for the sake of stability/reliability/maintainability is a no brainer. Balancing size/features could be a little trickier, but considering past evolution of µTorrent, I'm confident it'll be allright. You can always cut µTris out again if need be ;p.
war59312 Posted October 16, 2007 Report Posted October 16, 2007 If we changed, we'd use MSVC2005 (instead of 2008) to keep compatibility with Windows 9x.I vote YES, go for it.Why do you care about 9x support anymore? Seeing as even Microsoft no longer supports it. Just wondering.
Honeyfrog Posted October 16, 2007 Report Posted October 16, 2007 Because junker computers with obsolete OSs are fantastic dedicated platforms.
Lord Alderaan Posted October 16, 2007 Report Posted October 16, 2007 Yeah.About to throw away your old Pentium? Wait!! Install '98. Install µtorrent. Hook up a larger HD or a couple extra small HDs and you have you low power consumption, low noise (hopefully... dust it out for gods sake!), dedicated 24/7 BitTorrent machine.
Firon Posted October 16, 2007 Author Report Posted October 16, 2007 Because we still wanna keep support for it.Estimates are that it's <1% of the userbase, but.. still, why not? By compiling the latest build of µTorrent with MSVC2005, the filesize increase after packing was 37kB. It's being tested now to ensure it works properly on 9x/ME/NT.
Ultima Posted October 17, 2007 Report Posted October 17, 2007 "Why not" indeed; there's nothing much to be gained by dropping support for them.
SEtx Posted October 18, 2007 Report Posted October 18, 2007 Personally I don't like the code produced by MSVC2005/MSVC2008 (prefer MSVC2003 one). But of cource it will be way better than MSVC6 with its bugs.If you'd use only simple standard library functions like strcpy, strcmp and instead of complex functions like stricmp, fopen use WinAPI equivalents - it's possible to strip CRT startup, so your compiled size will not increase significantly and exe will not depend on any additional dll. (Easy to do on MSVC2003, a little tricky on MSVC2005/MSVC2008.)If you'd link with MSVC2005 CRT in dll like you do it now... well, it'll be not good at all since, unlike msvcrt.dll, msvcr80.dll is not installed with windows and users will have to find it themselves.If you'll decide to go with MSVC2005 and not MSVC2003/MSVC2008 - disable there code optimization for Pentium4 (default behaviour), since it's not optimal for both older and newer processors.At last, a little request - please, publish uncompressed version as well as upx'ed. (Uncompressed version is more memory-efficient at runtime.) It's not hard to unpack it, but this way you lose digital signature.
dAbReAkA Posted October 18, 2007 Report Posted October 18, 2007 why cant we have several versions (released at a more "hidden" place for advanced users..)
Alpha-Toxic Posted October 18, 2007 Report Posted October 18, 2007 1. For me the "smallness" of uT was never about the filesize, but the cpu/memory footprint.2. Wu use uT to move around TBs of data, bitching about 100k would be idiotic...Still, keeping the program relatively small is a good idea for portability, but the current filesize is so small that I don't see how you can break that unless you start putting porn pics in the exe
Firon Posted October 19, 2007 Author Report Posted October 19, 2007 If you'd link with MSVC2005 CRT in dll like you do it now... well, it'll be not good at all since, unlike msvcrt.dll, msvcr80.dll is not installed with windows and users will have to find it themselves.It's statically compiled into the EXE.
Ryan Norton Posted November 6, 2007 Report Posted November 6, 2007 FYI we were able to use the same CRT as we did before only compiled with MSVC2005, so there is no increase in size making this issue rather moot at this point .
Firon Posted November 7, 2007 Author Report Posted November 7, 2007 Well, now the only possible potential size increase would be the changed SSL lib.
jadedknight Posted November 7, 2007 Report Posted November 7, 2007 If anyone seriously says no to this your stupid. I say yes, go right ahead
Recommended Posts
Archived
This topic is now archived and is closed to further replies.