Can great software live in 130 kilobytes?
Summary: Unlike many sloppy applications that make a mess of the registry and shared DLL files in Windows, µTorrent didn't even need to be installed! It just ran off of the tiny 100 KB executable and the only install it did was put a desktop shortcut to the executable. Once µTorrent loaded in a matter of milliseconds, it was ready to rock and contained itself in less than 5 megabytes of system memory which is insane by today's standards.
[Upadated 2/1/2006 2:00 AM] A few months ago, I pretty much thought having decent software weighing in at 1 megabyte (let alone 130 kilobytes!) was a pipe dream -- but that's before I got my hands on a copy of µTorrent (a BitTorrent client). When I first downloaded the software back in September 2005 when µTorrent was first released, Ludvig did it by himself in his free time while holding a full time day job, what excuse is there for your entire team working full time? I figured it was probably just a novelty application that weighed in at just over 100 kilobytes (compressed binary). In the era of Java applications that take 100 megabytes of memory for a single application, I'm pretty much relieved anytime I see a native Win32 application that uses less than 20 megabytes of RAM. Anyone who even remotely knows me knows that I really have a low tolerance for bloated software so I figured µTorrent was worth humoring. Little was I prepared to be blown away by a fully functional BitTorrent client that did pretty much everything I needed it to do -- and I haven't even ran in to any obvious bugs these past few months.
Unlike many sloppy applications that make a mess of the registry and shared DLL files in Windows, µTorrent didn't even need to be installed! It just ran off of the tiny 100 KB executable and the only install it did was put a desktop shortcut to the executable. Once µTorrent loaded in a matter of milliseconds, it was ready to rock and contained itself in less than 5 megabytes of system memory which is insane by today's standards. From a features stand point, µTorrent may not have all the features of some of the heavier BitTorrent clients -- but it does have everything that 99% of the population wants.
Although µTorrent is still a small player among Torrent clients from a marketshare standpoint, every person that I have ever recommended the software to has switched to µTorrent because no one likes bloatware. Some Linux vendors like SuSE who distribute their software via the BitTorrent protocol specifically point to µTorrent as a nice little Torrent client to download SuSE Linux. Considering the fact that µTorrent came out of nowhere just last September, it has enjoyed tremendous success and has already been downloaded more than half a million times from the official µTorrent website alone.
I was so fascinated by the software that I decided to contact µTorrent author Ludvig Strigeus from Sweden who works as a programmer for a company in the automotive industry (talent wasted in my opinion) [Updated: Ludvig's boss Colt emailed me to correct me on my tongue-in-cheek "talent wasted" comment. Colt stated "I worked together with Ludvig on projects for Honda Research in Japan as well as with, Ford Motor Company, Renault Cars, SCANIA, Mercedes, BMW, and many other companies. His software in the auto industry is making it possible for advancements in fuel economy and emissions. All of it is having a positive impact on the world and the environment we live in. If that is not a good cause what is?" After a friendly exchange, I accepted his critique. Now my question is; how to we clone (joking) Ludvig so we don't have to fight over his time]. We had a nice conversation over Skype and it turns out that Ludvig had only worked on µTorrent for a few months in his free time after work. Ludvig still prefers the old Microsoft Visual Studio 6.0 because of its low memory foot print and fast user interface and he used it to write µTorrent entirely from scratch with the exception of a basic runtime-library functions. This explains why µTorrent is so tight and works completely independently of any shared DLL files in Windows. I also had the opportunity to clarify the meaning of "µ" in the name which as I suspected represented the scientific SI symbol for "micro" since µTorrent obviously lives up to its name.
In any case, I highly recommend that you give µTorrent a try since it will pretty much run as-is without an installer. I even go as far as keeping a copy on my USB key so that I can run it directly off USB on any computer I use but I usually just copy it to the host machine just to have it there permanently. If anything, this should be a lesson to the software industry as a whole who always give the excuse that it's just too expensive to write good tight code. Now I get to say: Ludvig did it by himself in his free time while holding a full time day job, what excuse is there for your entire team working full time?
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Very, very good blog
I tried utorrent and was not only impressed, but also happy to see that there still exist people resisting today's Java and .NET hypes. I even tried compressing with upx and got an uncompressible executable exception. That's how compact it is. Remarkable work.
Unfortunately, good, solid, tight code requires knowledge and talent. Such a thing is rare indeed. Tools that make the job simple to the point of allowing a lot of untalented people to also produce quick results rather than quality ones are what guarantees jobs. Sad but true.
I would like to point out a little remark: utorrent does use the Windows runtime, which in turn means it will inevitably have to link to a few shared system DLLs. In order to make your message clearer, you should specify that the shared DLLs you are referring to are "abstraction layers" of the likes of MSVBVM60 and mfc420. After reading more carefully, I figured you were probably referring to this kind of libraries.
Good blog, interesting and constructive.
I think it's already compressed
I think you're right; it's a matter of talent and training. Too many programmers take the easy route and do Java or .NET. I will say Paint.NET has made me wonder if managed code is worth while because it is relatively tight for a managed application. While Paint.NET is really good, it isn't anywhere near as tight as uTorrent and they're not even in the same ball park. Paint.NET shows what can be barely tolerable (in bloat and speed) using a very cool programming platform. If you gave me a choice, I'd go with Ludvig's work 10 out of 10 times. If I can't have a choice, something like Paint.NET is ok but ok is pretty impressive for a managed application by my standards.
Tight code
Good blog! (rare for Ou)
do not use .NOT
Go look at Paint.NET
Paint.NET shows you that .NET framework 1.1 or 2.0 is very usable. Sure it isn't in the same league as Ludvig's handy work, but it's workable. I can't say the same for Java though.
I was just saying . . .
Frameworks are not just for networked apps
I'm not saying that .Net and Java are the be-all and end-all, they certainly have their problems (slow execution, code bloat, for starters). But I can think of many reasons right off the top of my head to use .Net to write a desktop application as opposed to C++. Never having to deal with a window handle again and the MFC is one of them. It takes days to do in C++ what it takes 2 minutes to do with .Net, in terms of the GUI end of things.
J.Ja
Frameworks
And DON'T talk about MONO! It is aptly named, as it is sleepy and slow-reacting for long periods of time. It will NEVER be able to provide all of the features of .NET (M$ will make sure by moving the target), and thus NO ONE will use it for mission critical apps. IOW - .NET = monopoly for M$.
talks about it anyway
.net
This is where young' uns can learn from old farts
This is going to sound like one of those "10 miles through the snow, uphill, both ways" stories, but back in the day when you were lucky to have 256K on a IBM System 370/158, you _had_ to optimize for both time and size. And today this is a lost art amongst the majority of programmers. Unfortunately, I think that a lot of the newer stuff that IBM puts out now for z/OS suffers from bloat as well.
More power to Herr Strigius and programmers like him. Take back memory and disk space from bloatware!
Two things
Two, click on my link for bloatware and see who's bloated. MS Office or Open Office.
Compared to SIAG
Even compared to Gnome Office both are Bloated.
SIAG Office for those who have never heard of it is 1.4 MB Office Suite- It has a Word Procesor, Spreadsheet, Animation/Slideshow, and some odds and sods tossed in. http://siag.nu/
Dillo is also impresive for its size (350k) http://www.dillo.org/
Mark Tyler Paint is also impresive for its size http://mtpaint.sourceforge.net (250 Kb although it is 2.9MB for Windows- as it requires GTK which is included in the WIndows download)
Heck there are entire distros based on this stuff. What do you think is included in the 50 MB BBC and sub 50 MB BBC and 2-16 Mb floppy distros?
Let's stick to viable alternatives shall we
Indeed They Are Viable
Dillo does a fine job rendering web pages- It lacks javascript and most plugins- which can be a good thing. The framework is there for plugins, not that many plugins have been written for it though.
Gnome Office is a very viable alternative to MS Office Student, Small Business Editions or the copy of MS Works (Which is bloated trash) that many OEM Machines come with.
SIAG Office again would satisfy the requirements for many people. It has plugins to import MS Word through Word 2000, Excel through Excel 2000, and PowerPoint through PPT 97.
Also I am quite amused- As you claim that MS Office isn't bloated becuase Open Office is. Now that was the funniest thing I have seen in quite sometime. Of Course OO is bloated- It is a 100 MB download, has features in it that are absent from MS Office such as a full blown drawing app with 3D rendering and vectorization routines (It also can export to PDF and Macromedia Flash not to mention the built in Calc and Writer Database functions can double for Crystal Reports), and to top it all off has to carry the weight of Java and it's own widget set.
Furthermore a lot of the start time in OO is due the loading of it's widget set and Java. Open up an instance of OO Write then instead of closing the one instance open up another OO app, like OO Cal,c from the File>New menu without closing OO Write- it should be 1-3 seconds (That's what I get on a modest machine). This is becuase of Java and its widget set. Also tell OO to preload its widget set on start up like MS Office does and again a reduction in start times. Just having OO preload itself on a Windows box and switch over to real Java will improve its performance in Windows.
Really if you tell OO to preload its widgets and use prelink on a Linux box the start times between MS Office and OO Ofice are not that different, assuming you have sufficient memory or have set swapiness correctly- none of that was true in your tests. The worst part was we all told you that over and over and over and over again.
The funniest part in the tests was that in one, the machine only had 128MB of RAM, but KDE and typical vanilla installed Linux services (Such as X, CRON, ALSA, GStreamer, Etc- As a security expert, I am shocked you failed to check which services were running and turn them off, as that is basic Linux security ditto for MS security- turn off unneeded /unwanted services) require 178 MB of RAM without resorting to Swap space, and everyone told you KDE required more memory than any other Window Managers (It's not even the defualt for a lot of distros such as Fedora/RedHat or Ubuntu/Debian). We all told you that even before you did the test.
Then again that doesn't mean that OO is not bloated- becuase it is certainly known to be bloated.
He's the exception that proves the rule.
And I'm glad you heard back from his boss. His talents are not wasted. (Oh, they would be if he worked for a US-based car company.)
Hey
I RESEMBLE that remark! ;)
Sorry...
just of curiosity...
What do you mean by that? Perhaps I didn't get you, but the overhead of C++ compared to C is generally estimated to be inferior to that of C compared to handwritten assembly. Obviously this is dependent on your compiler, and the flavour of C++ you are using, RTTI, exceptions... And in C++ optimization is both a larger and more complicated task than in C.