Can great software live in 130 kilobytes?

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.

SHARE:
TOPICS: Tech Industry
73

[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?

Topic: Tech Industry

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

73 comments
Log in or register to join the discussion
  • Very, very good blog

    And a breath of fresh air in comparison to the controversial ones.
    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.
    Anti_Zealot
    • I think it's already compressed

      The executable is already compressed, but it's still small after you decompress it.

      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.
      george_ou
    • Tight code

      It also shows incredible discipline. The urge to write code using the bloated libraries is a difficult thing to resist especially when you consider what an happen with Visual Studio. I've seen MAKE files especially for VB bigger than the executable size! He does deserve some recognition.
      Xwindowsjunkie
    • Good blog! (rare for Ou)

      Congratulations!
      An_Axe_to_Grind
  • do not use .NOT

    THIS is the kind of software that I have been asking about. Your colleague Carroll is a .NET NUT - he seems to not understand that there are better solutions out there. M$ will lose out too, as they have abandoned all avenues EXCEPT .NOT. Maybe a company like Borland can come in and start taking developers away from M$ by supporting nice, small application development (they have before). .NOT is a plague that continues the commingling of software where you place more and more code into the "Operating System" - which is proprietary - and make it easy to write so-called "lightweight" applications.
    Roger Ramjet
    • Go look at Paint.NET

      http://blogs.zdnet.com/Ou/?p=131

      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.
      george_ou
      • I was just saying . . .

        That Paint.NET program COULD have been written WITHOUT .NET - in some other language. Why use a framework for Internet-enabled applications, when your program never touches the Internet? Its just another (unnecessary) M$ lock-in.
        Roger Ramjet
        • Frameworks are not just for networked apps

          .Net does a lot more than just make an application network enabled. So does Java. You can build a commandline-only application in either one, a desktop GUI application, a daemon/service in them, the list is endless. .Net brings together much of the various Windows APIs in an easy-to-use, logical, and consistent way that gives developers great freedom to build applications very quickly. I suggest you grab a copy of Visual Studio 2005 Express and play with it a bit before critisizing .Net in the future. Find out what it's capabilities and its weak point are, then feel free to critique it, instead of using meaningless jargon like ".NOT".

          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
          Justin James
          • Frameworks

            Frameworks move functionality from the application layer into the operating system layer. This is also called co-mingling! When you WRITE your program to use a framework, it will not function outside of it (unlike writing in a general language like "C", where it can be compiled on many platforms). This means that .NET ties you into using M$ OS.

            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$.
            Roger Ramjet
          • talks about it anyway

            I've used DotGnu and Mono. Mono is especially impressive. You are wrong about it being slow reacting. I've compiled apps on a windows box and scp'ed it to a linux box and it ran almost identically without the need to recompile. Speed differences were negligable. you are completely wrong on this one. Though, Microsoft is in the process of completely changing the language specification of C# in version 3 of the language, to add in the LINQ support. I don't know how long it will take the open source projects to follow along with that one.
            sabayer
        • .net

          .net has nothing to do with the internet except for the fact that there are some classes available that utilize the internet. It's more of a OS API on crack than an "Internet-enabled" framework. Besides your not locked into Microsoft when you use .NET, since the IL is cross platform and one "executable" and be used on many other OSes. The executables are not really executable, they're just data files that can be quickly jitted on demand. As a programmer, I have some issues with it taking over my memory management, just because the average developers are too lazy to use good coding practices, but other than that, I absolutely love the fact that there is a good cross-platform environment like .NET.
          sabayer
  • This is where young' uns can learn from old farts

    Between the bloatware that is M$, and the incredible overhead of OOP (I've seen the calls and stack manipulation generated by encapuslation of C++ classes in the Wintel environment and it isn't pretty), the commercial software of today is just incredibly inefficient.

    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!
    zarchasmpgmr
    • Two things

      One, Ludvig is younger than me.

      Two, click on my link for bloatware and see who's bloated. MS Office or Open Office.
      george_ou
      • Compared to SIAG

        -Both are bloated...

        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?
        Edward Meyers
        • Let's stick to viable alternatives shall we

          Please don't try and tell me those are viable alternatives.
          george_ou
          • Indeed They Are Viable

            MTPaint- Has roughly the same functionality as Paint.Net or MGI PhotoSuite. It is actually a good litle image Editor if you don't need a full blown one like the Gimp, Krita, Corel Paint, or PhotoShop.

            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.
            Edward Meyers
      • He's the exception that proves the rule.

        Ludvig is a rarity amongst the current crop. That does mean there is hope.

        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.)
        zarchasmpgmr
        • Hey

          (Oh, they would be if he worked for a US-based car company.)

          I RESEMBLE that remark! ;)
          Roger Ramjet
          • Sorry...

            My condolences. ;-)
            zarchasmpgmr
    • just of curiosity...

      the incredible overhead of OOP (I've seen the calls and stack manipulation generated by encapuslation of C++ classes in the Wintel environment and it isn't pretty)
      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.
      pphant