Krzysztof Kowalczyk blog

A list of chm readers/viewers for Windows

2011-12-10T00:47:56Z

I’ve compiled a list of CHM readers for windows. It’s a surprisingly long list.

SumatraPDF 1.9 released

2011-11-24T08:44:29Z

We are pleased to announce 1.9 release of SumatraPDF, a small, fast, free PDF, CHM, DjVu, XPS, CBZ and CBR reader for Windows.

The most significant addition in this release is support for CHM documents. Sumatra is slowly getting support for more and more document formats.

Robert Prouse contributed support for touch gestures (available on Windows 7 or later, if you have the right hardware i.e. touch-enabled screen).

Audio and video files linked from PDF documents are now opened in an external media player.

We’ve also improved support for PDF transparency groups.

App Engine price hike - not so bad after all

2011-10-05T06:13:35Z

This blog is hosted on App Engine. At first it looked that recent App Engine price hike will push my blog from free tier to a paid one.

The increase would come only because of change from charging per cpu hours to charging for instance hours.

However, after making a small change in Application Settings to set Max Idle Instances to 1, I’m back in free tier. I haven’t noticed a performance degradation.

In conclusion, App Engine still seems like a good choice for hosting small to medium sized websites for free.

Introducing Volante - a database for C# (.NET)

2011-09-23T00:12:27Z

Volante is a small, fast, object-oriented, embeddable database designed for seamless integration with C# (and other .NET languages). Today I’ve made a first public release.

Almost every program needs to persist some data. There are many ways to do that: serialize data as XML or JSON, use SQLite etc.

I’ve been recently writing desktop .NET applications in C# and existing (free) options didn’t meet my needs well.

The closest best solution is SQLite, but it doesn’t integrate with C# well: you have to convert your object to/from SQL tables.

If I was the world’s toughest programmer I would write an object-oriented database engine from scratch and it would be designed from the beginning for seamless integration with .NET framework.

Thankfully, I didn’t have to do that. What I needed already existed in the form of Perst project.

There was one wrinkle: while early versions of Perst were under BSD license, with version 2.50 the code was acquired by a company McObject and is now distributed under GPL and those who can’t use GPL can purchase commercial license from McObject.

Not so great for one person who doesn’t yet make money from his software.

I decided to adopt the Perst code base. I picked the latest 2.49 version that was still licensed under BSD (copyright cannot be change retroactively) and I’ve spent the last couple of months writing comprehensive documentation, writing tests, fixing bugs discovered by tests, modernizing the code base.

Today I’ve reached a point where I’m comfortable releasing this code publicly as version 0.9.

I’ve retained the BSD license of early Perst versions so the code is free to use in both open-source and commercial projects.

Volante database serves the same niche as SQLite: an embedded database engine for your desktop C# applications. Like with SQLite, the database is in a single file.

There are significant differences from SQLite.

.NET is an object-oriented framework. Volante is an object-oriented database to offer the best integration with .NET. Volante uses B-Trees to implement indexes, which allows quickly finding objects with desired properties.

Volante is extremely small: Volante.dll is only 180 KB.

I distribute Volante.dll for Microsoft’s .NET (works in .NET 2.0 and later) but it can also be compiled from sources and used under Mono.

I was dogfooding Volante from day one in my three .NET applications and it’s been performing great.

I hope you’ll find it useful too.

SumatraPDF 1.8 released

2011-09-19T02:41:14Z

We are pleased to announce 1.8 release of SumatraPDF, a small, fast, free PDF, DjVu, XPS, CBZ and CBR reader for Windows.

This is a smallish release.

We improved support for PDF form text fields.

We did speed up handling of some types of djvu files.

We’ve made a bunch of minor improvements and bug fixes.

SumatraPDF 1.7 released

2011-07-18T01:28:26Z

SumatraPDF developers are pleased to announce 1.7 release of SumatraPDF, a PDF, DjVu, XPS, CBZ and CBR reader for Windows.

In this release we’ve added user-defined favorites (i.e. bookmarks). You can create one or more favorites for a given file, navigate to a favorite and delete them.

Favorites are accessed either via a menu items in Favorites top-level menu or displayed as a tree in the sidebar.

We’ve improved support for right-to-left languages, like Arabic.

Logical page numbers are displayed and used, if document provides them (such as i, ii, iii, etc.).

We allow to restrict SumatraPDF’s features with more granularity; see this document for more information.

Command-line argument -named-dest now also matches strings in table of contents.

We’ve improved support for EPS files (requires Ghostscript)

Installer is now more robust. Previously an installation could fail if a web browser using Sumatra’s web browser dll was running. Now installer detects this and will ask to close the browser before proceeding.

Until next release.

How to make software crash less

2011-06-30T22:32:59Z

You don’t want your software to crash, do you? This post describes my experiences in making desktop Mac and Windows software crash less.

Know thy crashes

The most important step to fixing your crashes is to know about them.

Given how complex and varied our desktop operating systems are (3 major version of Windows in active use, thousands of minor and major ways that each installation of Windows or Mac can be different) our ability to comprehensively test software is not good.

Sure, if you’re Microsoft or Adobe you can reinvest some of the revenue to hire an army or testers, setup compatibility labs etc. but for a small company or a single developer this is not realistic.

Bugs most often lurk in untested code and even a very good testing effort is unlikely to encounter all the many things that can go wrong in real life.

Get the crash reports automatically

Very few people bother to tell software vendors about crashes. They just shrug and restart. The only realistic way to be informed about crashes is to automatically gather crash reports without user involvement.

This is a proven idea. Microsoft was one of the pioneers of using this technique for Windows OS and they publicly praise it for letting them fix the most frequent crashes and increase stability of Windows. Many clued in organization do it as well: Apple, Mozilla, Google.

Getting the crashes – the mechanics

Regardless of the platform, the solution involves two parts:

a server, which accepts crash reports from the software
code inside the software itself. It gets activated when a crash happens and sends crash report to the server

The server

The server part is simple. You can use any technology to write it, any protocol you want.

Personally I use App Engine, re-use HTTP POST protocol and run on standard HTTP port (80) for maximum compatibility with client-side firewall software.

It’s literally few lines of code to parse incoming POST requests, store them in the database and provide a basic web interface for easy browsing. As an additional bonus, App Engine is free if your traffic is small enough,

If you write in PHP and run on a small VPS, it’ll work just as well.

Client side on Windows in C# apps

In C# I setup a global exception handler (in WPF it means setting up handlers for App.DispatcherUnhandledException and AppDomain.CurrentDomain.UnhandledException).

I then use HttpWebRequest class to send exception message and callstack as HTTP POST (using multipart/form-data).

The code is less than hundred lines and took mere hours to write.

Client side on Windows in C++ apps

In C++ everything is substantially harder. The big picture is similar:

install global handler for unhandled exceptions (with SetUnhandledExceptionFilter())
in that handler generate the crash report and HTTP submit it to the server

The details are substantially more complicated. The code is more than a thousand lines and took me days to perfect.

The biggest issue was that, unlike in C#, you don’t get readable callstack in native code. You need symbols (.pdb files) for that. My solution is convoluted, but works:

during build process, I archive .pdb files on the server (I use S3, but any web server will do)
in the crash handler I download the symbols locally, on demand
I create crash report containing human-readable callstacks of all threads and some other useful information
I HTTP POST it to the server

You can re-use my work. The code is part of my SumatraPDF open-source project. Most of it is in CrashHandler.cpp and, unlike most of Sumatra, is under liberal BSD license.

Client side on Mac OS X

The good thing about Mac is that it already creates human-readable crash reports for you. They are stored in ~/Library/Logs/CrashReporter/ directory.

There’s no need to handle crashes yourself. I just check at startup if there’s a new crash report for my app (the files are named after your application) from a previous run. If there is, I submit it to the server (and delete so that it’s not sent multiple times).

The alternatives

While the general idea is always the same, there are different ways of implementing it.

On Windows a simpler solution is to capture so-called minidumps (using MiniDumpWriteDumpProc() Windows API) instead of going to the trouble of generating human-readable crash reports client side.

I did that too. The problem with that approach is that you have to inspect each crash dump manually in the debugger (e.g. WinDBG). I wrote a python script that automated the process (you can script it by launching cdb debugger with the right parameters and making it run !analyze -v)).

Unfortunately, cdb is buggy and was hanging on some dump files. It’s probably possible to work around with a timeout in the python script, but at that point I stopped caring.

Windows provides native support for minidumps. Google took minidump design and provided cross-platform implementation for Windows, Mac and Linux, as part of breakpad project.

Breakpad is the crash reporting system used by Google for Chrome and Mozilla for Firefox. It contains both client and server parts for native (C/C++ or Objective C) code.

I used it once for a Mac app. For Objective C I prefer the approach described above as it’s simpler to implement, but I’m sure that’s a solid and well tested approach.

On Windows, crash reports from your app are already sent to Microsoft as part of Windows Error Reporting. Apparently, it’s possible to for third party developers to get access to those reports but I never did that, so don’t know what’s involved in the process.

The SumatraPDF experience

So how well does it work in practice?

We’ve implemented the system described here in Sumatra 1.5. Sumatra is a rather complicated piece of C++ code and quite popular (several thousand of downloads per day).

Before 1.5 we had a system where we would save the minidump to a disk and after a crash we would ask the user to report it in our bug tracker and attach minidump to the bug report.

It became obvious that almost no one did that. We’ve only gotten few crash reports from users in few months. Our automated system was sending us tens of crash reports per day.

Once we knew about the problems, we could attempt to fix them. Some problems we could fix just by looking at crash report. Some required writing stress tests to make them easier to reproduce locally. Some of them we can’t fix (e.g. because they are caused by buggy printer drivers or other software that injects buggy dlls into our process).

We do know that we fixed some of the bugs. We can see that a new release generates less crashes and by looking at crash reports we can tell that some crashes that happened frequently in previous releases do not happen anymore.

Building automated crash reporting system was the best investment we could have made for improving reliability of SumatraPDF.

Experience porting 4k lines of C code to go

2011-06-02T06:40:38Z

I’ve been recently interested in Go, a new programming language.

The best way to learn a language is to use it in a small but real project.

I needed a program that generates HTML from textile format. The way of least resistance would be to implement it in Python, as I’ve coded a similar thing in the past. Instead I decided to use this as an opportunity to get more familiar with Go.

The biggest part of the problem was the textile to HTML conversion. There is no existing Go code for that so I decided to port upskirt C library, as it does the job in the most performant way (it has a hand-written, disciplined parser as opposed to most other solutions that just throw cryptic regular expression at the problem).

The bottom line is: porting C code, at least in this case, was fast, boring, mechanical process (and that is a good thing).

Go’s syntax is heavily inspired by C. The differences that I’ve encountered most frequently:

syntax for declaring variables is different (and better)
while keyword is missing, replaced by a more versatile for syntax
function declaration syntax is different

Fortunately, the transformations were simple and mostly mechanical.

It took me just few days to manually translate around 4000 lines of C code into ~3200 lines of Go code.

Saving ~800 lines of code (20%) is good, but the interesting part is: where do the savings come from?

The core parsing/html generating logic didn’t shrink much. The big savings came from the fact that Go has a built-in growable array type and upskirt C code had to spend 924 lines re-implementing that in C.

An unexpected advantage of Go was its safety. The C code implements parsing by partying on char * pointers. Such code is notorious for causing lots of subtle, hard to test for bugs. Go doesn’t allow this kind of pointer arithmetic and instead provides slices, which are a view into an underlaying array.

Slices provide out-of-bounds checks. Just by recoding in Go I found out-of-bounds access bug in the original C code.

Thanks to similarity of Go and C syntax, porting algorithmic code from C is simple.

All things considered, Go is quickly becoming my new preferred language (taking the crown away from Python). It combines the good attributes of Python (lightweight syntax, garbage collection) with good attributes of C (fast execution thanks to compilation to native code and programmer’s control over memory layout) and adds some unique capabilities of its own (concurrency via gorutines and channels).

BTW: if you want markdown implementation for Go, use blackfriday. It’s also direct port of upskirt and I abandoned my port in favor of contributing to blackfriday, since it was slightly ahead and there’s no need for two nearly identical projects.

SumatraPDF 1.6 released

2011-05-31T04:42:25Z

SumatraPDF developers are quite pleased to announce 1.6 release of SumatraPDF, a PDF, XPS, DjVu, CBZ and CBR reader for Windows.

In this release we’ve added support for DjVu file format.

When no document is open, we display a list of frequently read document as thumbnails. This functionality is inspired by new tab page in Chrome.

We’ve added support for displaying Postscript documents. This requires recent Ghostscript version to be already installed – we don’t bundle it ourselves.

We’ve added support for displaying a folder containing images: drag the folder to SumatraPDF window

We now support clickable links and a Table of Content for XPS documents.

We’ve added printing progress and allow canceling printing process.

We’ve added Print toolbar button.

Experimental: we’ve added previewing of PDF documents in Windows Vista and 7. This creates thumbnails and displays documents in Explorer’s Preview pane. Needs to be explicitly selected during install process. We’ve had reports that it doesn’t work on 64-bit Windows which is why we call it experimental.

This is how “frequently read” list looks like:

Easy vs. probable or how to make money with software

2011-05-15T00:15:17Z

It it hard to make $1000 a month?

There’s a question on Quora: Is it hard to build, market and maintain a web app that makes at least $1000 a month?

Most of the answers are happily saying “no, it’s not hard at all”, usually justifying it with wishful thinking (“it’s not hard to get 50 people pay you $20 a month”).

Those answers are misleading.

I don’t blame the respondents. They answered the question the way it was asked.

What you ask vs. what you want to know

The problem is that the person who asked the question really wanted to know how probable it is, not how hard. There’s a big difference.

A personal anecdote

Many years ago, in the early days of Palm PDAs I wrote an English dictionary for Palm OS. For more than 2 years I made several thousands dollars per months from it.

Was it hard? Not at all. It took me about 2 weeks to write the first version and there was nothing especially difficult about it – there are thousands of programmers that could have done it.

My website was simplistic, my marketing skills limited to uploading my app to an app store-like website (PalmGear) which handled selling the app.

Nothing I did was difficult. However, my success wasn’t very probable.

I wrote one of the first (if not the first) dictionaries. Things were different in 2001. Today everyone and their mother jumps on building iPhone or Android apps bandwagons but back then I had no competition from known dictionary publishers (publishers are not risk taking, future embracing organizations).

For a while I had the market to myself and that helped to establish my program as one of the most popular programs for Palm OS. Eventually competition arrived and it did have negative effect on my sales, but they had a really hard time catching up with me.

Lesson number 1: timing matters.

Getting timing right is not hard or easy, it’s simply not likely that you’ll get the timing right. If the right timing is obvious, it’ll be obvious for many people and, paradoxically, means it’s too late. If it’s not obvious, there’s a big probability that whatever you think the right timing is, you’re wrong.

The right timing is only obvious in retrospect.

In my case, I didn’t write my dictionary because I thought it’s the right time to do it if I wanted to make money. I was just excited about new technology (Palm Pilots), wanted to write some program for it and a dictionary seemed like a good choice.

Do it once vs. do it many times

Another way to look at it is repeatability.

The easy success of my app wasn’t lost on me. If I could replicate that success several times, I would get quite rich with little effort.

So I’ve made more apps for Palm OS. They were more complex than my dictionary. They took longer to write, but still weren’t hard to write.

I assume that my marketing, sales and other business skills were at least as good as before. And yet, the other apps were all failures.

My first success was easy but it wasn’t easily repeatable.

Many people who answered the Quora question did build successful websites making $1000 or more a month. Does that mean that their experience is good enough to declare that achieving what they did is easy?

No. Just like me, they all have only one or two successful products. If it’s easy, then why don’t they re-invest their capital in making more products? After all, if you have 100 products each making $1000 per month, you’ll make more than a million a year.

The answers are a good example of selection bias. Even if something has 1% probability of happening, if there are 100 people who tried, 1 of them will succeed. Given the popularity of Quora, it’s not hard to find lots of people who tried something with low probability of success and did it successfully. When they see someone asking if doing it was hard, they jump in saying that it wasn’t.

They are truthful and trying to be helpful and encouraging but we don’t get the complete picture because we don’t hear from much bigger number of people who tried and failed.

The successes might have been easy, but they were not likely.

Just ship it

Making software (be it a web site, a mobile app, a desktop app) that makes money is something with low probability of success. It’s not as bad as you think: making money in any self-directed business (as opposed to being employed) has low probability of success.

More importantly: you have the biggest influence on that probability.

The person who asked this question probably won’t be successful. The answer is unknowable and knowing it would not make a difference.

You’ll succeed or you’ll fail but you’ll not ever know it until you’ve tried. Spending any time calculating your chances actually decreases the probability because it takes away time and energy from things that matter.

The single most important thing when building money making software product is this: ship it.

My success might have been accidental, but it wouldn’t have happen if I didn’t write the code, the website, the documentation and made my program available for people to buy.

If the product fails, either improve it or make another one. The more times you try, the more likely you’re to succeed.

When you start getting sales, double down. The unassailable logic of software business is that it’s easier to make a successful product even more successful than to create another one that is just as successful.

Look at any software business. Even the biggest successes, like Microsoft or Google, have only few extremely profitable products and despite having the brightest developers, mountains of money, cross-promotional opportunities, they struggle to create more money making products.

90% of success is showing up - a proof

2011-05-08T01:05:04Z

Woody Allen said that 90% of success is showing up. This article is a proof of that.

In 2007 a Standford professor gave his student a taks: build a Facebook application and get people to use it.

The result? Some applications became so popular that students made good money out of them. Some even turned into companies.

The important part is that none of those student particularly wanted to build that app. It was simply something they were told to do.

The challenge in life is that no one tells us to do things that we’ll own. Sure, at work bosses tell us what to do but the company owns the result of the work and all potential windfalls.

What the article shows that just by doing something and shipping it to the world, we might create an unexpected success.

SumatraPDF 1.5 released

2011-04-24T02:37:04Z

A new version of SumatraPDF, a free, small, fast, open-source PDF reader for Windows, is ready.

What’s new in version 1.5?

We’ve added support for XPS documents.

We’ve also added support for CBZ and CBR files (popular formats for comic book files).

We’ve added File/Save Shortcut menu item to create a shortcut to a specific place in a document.

We’ve added right-click context menu for copying text, link addresses and comments. In browser plugin context menu also has items for saving and printing.

We’ve added folder browsing. Ctrl+Shift+Right opens next PDF in the current folder, Ctrl-Shift+Left opens previous PDF in the current folder. Current folder is the one where currently opened PDF documents is located.

We’ve also fixed handling of large PDF files in browser plugin in FireFox.

SumatraPDF is a creation of SumatraPDF developers.

Let the downloads begin.

SumatraPDF 1.4 released

2011-03-13T00:18:46Z

Good news everyone: a new version of SumatraPDF, a free, small, fast, open-source PDF viewer for Windows, is ready.

What’s new in this version?

We’ve added browser plugin for Firefox/Chrome/Opera (Internet Explorer is not supported).

We’ve added IFilter that enables full-text search of PDF files in Windows Desktop Search (i.e. search from Windows Vista/7’s Start Menu).

Browser plugin and IFilter are not installed by default so you need to use options in the installer and check the appropriate checkboxes. You can uninstall them by re-running the installer and de-selecting the options.

In 1.3 we’ve improved text selection to use left mouse button. The downside of that was that left mouse button couldn’t be used for scrolling when mouse cursor is over text. To compensate for that, in 1.4 you can scroll with right mouse button.

In 1.3 we’ve introduced a new installer. Some of you missed the ability of choosing a custom installation directory that was not implemented in 1.3. We’ve re-introduced support for non-standard installation directory in 1.4.

SumatraPDF focuses on reading PDFs and doesn’t implement some more advanced functionality like filling out forms or making annotations. If you need this functionality, we’ve made it easy to re-open current document via File menu in Adobe Reader (if it’s installed). In 1.4 we also support Foxit and PDF-XChange.

To make SumatraPDF files smaller, we used to compress the executable with mpress. Unfortunately that caused some anti-virus programs to falsely report Sumatra as a virus. We no longer compress the executables that ship with the installer version, so don’t be surprised that the files are now bigger. The portable, .zip version still ships as a single, compressed executable (so don’t be surprised if it’s flagged by some anti-virus software).

We’ve removed -title cmd-line option.

We’ve added support for AES-256 encrypted PDF files, fixed an integer overflow reported by Jeroen van der Gun and and made other fixes and improvements to PDF handling.

If you wonder why we don’t have browser plugin for Internet Explorer, the explanation is simple: no-one has written the necessary code.

SumatraPDF has been brought to you by SumatraPDF developers.

XML is really, really slow

2011-03-11T02:25:56Z

It’s about 8 years late but W3C finally produced a standard for efficient XML representation. They call it somewhat opaquely Efficient XML Interchange (EXI). I guess it sounds better than what we used to call such things back in the day: binary XML (which is a better description what it’s about).

The money quote from the announcement:

They’ve achieved over 100-fold performance improvements…

One way to interpret this is: wow, those guys are really smart.

There is much simpler explanation: XML is really, really slow.

Speed comes from architecture

I’m somewhat performance oriented in my programming work. One of the reasons I disliked the popularity of XML was that I saw how often it blinded people to engineering realities. Choosing XML was often a reason for dramatic performance issues that then had to be heroically recovered.

Those performance problems were, however, mostly self inflicted. XML is only one of the possible ways to store or exchange data but it certainly is one of the slowest.

You cannot get 100x speed up over technology that wasn’t incredibly inefficient to begin with.

Sometimes you don’t have the choice (when you have to inter-operate with systems that only offer XML) but I’ve seen many cases where people did have the choice and made the wrong one.

XML isn’t such a hot buzzword anymore so I don’t see that problem as often but I still do see it.

For example, more than one text editor decided to store the syntax highlighter definitions as XML while it can be trivially stored in simple text format that can be parsed much faster, using less memory and, as a bonus, can actually be edited by human beings.

A bigger point is: speed comes from architecture. It’s not that choosing the right architecture will make you dramatically better but choosing the wrong architecture will make you dramatically worse.

Choosing XML over more efficient ways of storing data is just one, but particularly frequent, example of that rule.

Binary XML (EXI) is too little too late

As to the standard itself: don’t pay attention to it. It’s too little, way too late.

About 8 years ago I did my small part in expanding XML capabilities of SQL Server. At the time XML was hot so Oracle, Microsoft, IBM raced to add native XML handling to their databases. It was going to be the next big thing. Possibly even bigger than big.

Trust me, the ridiculous inefficiency of XML wasn’t lost on developers working on XML technologies 8 years ago. Coming up with a more efficient binary XML format is easy. Microsoft had its version (if not several of them) and other companies had theirs.

The real problem was: politics prevented people agreeing on a standard so no standard emerged.

There was an eruption of creating standards based on XML (SOAP, XML Schema, XQuery). If you don’t know what those terms mean it’s because they all failed (despite the fact that everyone was convinced they’re going to be the next big thing).

In hindsight it was a terrible mistake to work on those big standards of speculative value but not solve a real problem people already had: an efficient, binary, standard format for storing XML.

If W3C came up with EXI 8 years ago, maybe people wouldn’t feel the need to invent Protocol Buffers or Thrift and it would have won.

But solving this problem today is almost comically late. It has no chance of adoption.

If you’re planning to use a custom, binary way of storing XML, using EXI is probably better but there’s no way EXI will become so universally supported as XML and universal support (in software libraries, books etc.) is really the main thing XML has going for it (speed or human-readable syntax, on the other hand, are not XML’s strengths).

My social marketing failure

2011-02-08T23:00:09Z

Me, a social marketer

Four months ago I started an experiment in social marketing of SumatraPDF, my free PDF viewer for Windows.

Let me rephrase that without the buzzwords: four months ago I added Google buzz, tweet and Facebook like buttons to Sumatra’s web pages:

This is a reflection on changing habits of how people share what they find on the web. Blogs used to be the medium to write about products and services people found useful. Blogs are still going strong but tweeting/buzzing/liking is much easier than writing a blog post so it became a dominant way of sharing cool finds.

It took me about an hour to add the 3 most popular buttons, so there was no reason not to try it.

A button promotes a given page (as identified by a url). In case of Sumatra, they promote the main (landing) page.

When I installed the buttons on 9-19-2010, I already had 529 Buzz posts (a suspiciously large number), 44 tweets and 16 Facebook likes (those services track number of mentions for a given page even if they originate from other places which gave me a jump start).

Me, a failed social marketer

As far as I can tell, it was a dismal failure.

The purpose of marketing is to make people more aware of your software. The theory is that a tweet or a like shows up on people’s twitter or facebook streams whcih leads them to click on the link and visit your website.

You can track the effectiveness of such marketing by counting how many people come to your website from twitter.com or Facebook.com (I do it with Google Analytics).

The results are terrible. In the last month, I got 82 visits from facebook.com (out of 350.000 pageviews), which makes it 116th referal source. Inexplicably twitter.com doesn’t even show up in the list of first 500 referal sources.

In those four months I got 314 facebook likes (78 per month) and 29 tweets (7 per month).

To give some perspective: before installing those buttons Sumatra averaged around 4.000 downloads a day and getting more than 300.000 page views a month.

That means that insignificant number of the people downloading the software or visiting SumatraPDF website use the tweet or like buttons.

I also know from monitoring twitter for mentions of Sumatra that people tweet about it on their own.

Incremental traffic from Twitter or Facebook to my website is negligible.

Why so failure?

I didn’t expect miracles but I also didn’t expect such a massive failure.

One possibility is that I horribly botched interpretation of the results.

Another possibility is that those things don’t work well for software. Unlike a cute picture or a blog post, software cannot be evaluated by just looking at the website. You need to use it for a while to decide if it’s good or not so it doesn’t lend itself to impulsive tweets of admiration.

On the other hand, I’ve seen web pages for software that I’m pretty sure is less popular than Sumatra and had way more than my measly 44 tweets.

SumatraPDF 1.3 released

2011-02-07T21:26:41Z

SumatraPDF team is happy to announce a 1.3 release of our free, small, fast, open source PDF reader for Windows.

Sumatra was capable of text selection for some time but this feature was hard to discover (you had to press Ctrl and select the area with a mouse). We improved text selection and copying by emulating the way a browser (and Adobe Reader) work: just select text with a mouse and use Ctrl-C to copy it to a clipboard.

Shift + Left Mouse now scrolls the document and Ctrl + Left mouse continues to create a rectangular selection (for copying images).

We added more keyboard and mouse shortcuts:

'c’ shortcut toggles continuous mode
'+’ / '*’ on the numeric keyboard now do zoom and rotation
back/forward mouse buttons for back/forward navigation

We added toolbar icons for Fit Page and Fit Width and updated the look of toolbar icons

In version 1.2 we introduced a new full screen mode and made it the default full screen mode. Old mode was still available but not easily discoverable. To make it more discoverable we’ve added View/Presentation menu item for new full screen mode and View/Fullscreen menu item for the old full screen mode.

We rewrote the installer

We improved zoom performance and fixed crashiness caused by high zoom levels.

We improved searching for text to use less memory.

We improved printing.

We’ve updated translations contributed by our translators

We updated to latest mupdf code for various improvements and bugfixes.

We now use libjpeg-turbo library instead of libjpeg, for faster decoding of some PDFs.

We updated openjpeg library to version 1.4 and freetype to version 2.4.4.

We fixed 2 integer overflows reported by Stefan Cornelius from Secunia Research.

Writing a custom installer for Windows software

2011-02-06T22:43:27Z

A tale of 2 installers

For version 1.3 of SumatraPDF I’ve created a new installer.

The old installer:

New installer:

This post explains why I spent the time rewriting perfectly functional installer.

How people write installers

If you write Windows software, you need to provide an installer. Almost all installers are created by a tool (e.g. WiX, Nsis, Inno Setup and many others).

Apparently people think that writing an installer is so difficult that it has to be simplified with a tool.

I’m here to advocate another way: write your own installers, people.

It’s not that hard.

As everyone else, I did my installers with a tool. NSIS was my weapon of choice: it’s free, (relatively) easy to learn, (relatively well) documented and since other people used it, there are examples to learn from.

I used it in SumatraPDF, OpenDNS client and was reasonably happy with it. However, it wasn’t all roses.

NSIS is great if you don’t try to do anything that it doesn’t support out of the box. Once you stray outside the box, it’s hours spent trying to find an existing NSIS code to do what you want and if you’re unsuccessful, learning how to write code in NSIS’ awful macro language or write extension dlls.

Two issues I ran into were:

since you can’t overwrite an executable file of a running program, it’s a good idea to kill running instance of the program in the installer, to avoid a failure in the middle of installation. There’s no built-in functionality to kill processes in NSIS. After spending way too much time trying to find an existing solution, I ended up writing an extension dll with necessary support command.
for my .NET app I had to install .NET 4.0 runtime if it wasn’t already installed. Doing that in C code is simple: check registry keys to determine if .NET runtime is installed and execute the installer if it isn’t. This is a common problem and I found several solutions on the net but each one was slightly different, since I’m not proficient in NSIS macro language they were not easy to tweak for my purpose and they were all outdated (e.g. showing how to install .NET 2.0 while I needed .NET 4.0).

I realized that an installer doesn’t do anything complicated: it shows a window, writes a few registry keys a copies a few files. I figured that writing installer in C++ from scratch wouldn’t take more time that I’ve spent in total learning about NSIS.

I was right: it took me 9 days to write shippable version of Sumatra’s custom installer. Most of it was support code so writing future installers for my other software will be even faster since I’ll reuse most of the code.

Why write custom installer?

I already had a functioning installer so why fix something that isn’t broken? For me, the reasons where:

provide a better user experience
no frustration due to NSIS limitations

Installer is the first thing a potential user of your application sees. What will be his first experience with your app?

Will it be terrible, like those installers that take half an hour to unpack a few files?

Will it be boring, just like most other installers?

Or will it be remarkable, unique, extra pleasant? An experience worth talking about to others?

Writer Joe Konrath stress the importance of a good book cover. An installer is the equivalent of a great book cover.

Writing a custom installer doesn’t guarantee it’ll be exceptional, but using NSIS guarantees that it’ll be boring, just like every other installer created with NSIS.

In SumatraPDF’s case, I’ve made an usability improvement: installation is a one-click affair (old installer required a few clicks).

On the whimsicality front, I’ve added a small startup animation, which shows the program letters one by one. It’s only a small thing, I haven’t spent much time on it, but the possibilities for interesting animations are endless: scrolling text, 3d objects rotating, fireworks, star fields etc. Old school demos and processing are a rich source of inspiration for possible effects.

If you want to learn how a custom installer is done, the source is out there…

Using Quora for customer support

2010-12-26T22:36:40Z

I was reading Scoble’s post about Quora being a blogging innovation and I got this idea: how about using Quora for customer support?

If you sell software or give it away for free or provide a service, it’s a good idea to have a way to communicate with your users, to get bug reports, ideas for new features, answer questions etc.

There are many ways of doing that: e-mail groups, forum software like phpBB or Vanilla or my own fofou, bug trackers, UserVoice etc.

Creatively used Quora could fulfill this purpose as well. I envision creating a topic for your product e.g. since I work on SumatraPDF, the topic could be “SumatraPDF official support forum”.

People would have to tag their questions with this topic. Quora has pretty good capabilities for browsing/monitoring e.g. people could watch the forum to see all new questions.

Unsurprisingly, Quora uses itself as its user feedback mechanism so it looks like it just might work.

Which technology for writing desktop software?

2010-12-06T07:20:58Z

This post is inspired by a question posted on JoelOnSoftware software business forum.

To paraphrase: “I’m a one person coding machine. I want to write small, consumer oriented desktop software. Which technology should I use? Should I write cross-platform code or stick with one platform?”

It is a good question because the amount of available technologies is vast: C/C++, .NET, Java, Adobe Air, Cocoa with Objective-C, QT, wxWidgets and many more lesser known technologies.

I have an answer.

Don’t write cross-platform code

The logic behind writing cross-platform code is deceptively attractive: if I target both Mac and Windows, I’ll sell twice as many copies of my software.

However, at the beginning your biggest problem is that your idea hasn’t been tested with the market. Writing for a single platform is faster so you’ll find out sooner if your software is a hit or a flop.

If it’s a flop, the effort of supporting two platforms was lot.

If it’s a success: congratulation, you now have the money to invest in supporting the other platform and a much higher chance that the result will be successful as well.

Don’t delude yourself that a cross-platform toolkit will allow you to ship a cross-platform as fast as shipping a single-platform code. Life is not as simple as that.

Today Qt is the best cross-platform toolkit, a truly impressive piece of work. It is, however, limited by its legacy. Qt requires you to use C++. You’ll be much more productive using C# with WPF on Windows or Objective C with Coca on Mac.

Writing code takes only a fraction of time and effort needed to ship an application to end users. Other activities that you’ll need to do that also require doubling the time and effort:

testing the code on both platforms
writing documentation and marketing materials for 2 platforms
learning how to market to both Windows and Mac users
learning to become an expert user of both OSes to help your users when inevitable support requests come in

What you need from a platform

Sometimes platform are chosen based on vague understanding of what they provide. I see no end of people who e.g. will blindly suggest Adobe Air just because it’s marketed as allowing cross-platform development and happens to get lots of buzz recently, without considering if the technical limitations of Air would even make a given application possible to write.

Here are things to consider when choosing a platform for your software.

Is it capable enough?

Adobe Air might be a great technology for some applications. If you’re building a Twitter client, it’ll do just fine. If you’re building a novel compression engine, it’s not appropriate.

By their nature, cross platform toolkits tend to target the lowest common denominator and don’t support important platform-specific features. Those fancy Core Animation transitions in your Mac app? You probably won’t get that from Java or Air or Qt. Support for Windows 7 task bar integration? Probably not there either.

Is it documented well?

This is not only about documentation that comes in the box but also about the availability of greater ecosystem. You’ll run into problems, bugs, things you don’t understand. It’s important to resolve those issues quickly.

Mainstream technologies like Java or .NET are documented in books from respected publishers, numerous blog posts and have communities where you can show up, ask a question and get an answer quickly. There’s much less of that for e.g Adobe Air or Clojure.

Are there third-party libraries available?

You don’t want to write a zip compression or http client from scratch. Availability of 3rd party libraries that you can drop in your code and save tons of time is important. In that respect Java and .NET are unmatched. There’s lots of C/C++ libraries out there, but integrating them in your project will be harder.

Are other programs like the one you’re thinking about implemented with that toolkit?

Can you write a great text editor in Air? I don’t know, I haven’t seen one.

The fact that Microsoft used .NET/WPF for writing editor in Visual Studio or that Eclipse is written in Java is a proof that a complex text editor can be written in those technologies.

Do you know it well?

Learning a new technology is hard. Even switching to a similar platforms (e.g. from Java to C#) requires a large amount of effort and time. All else being equal, use the technology you already know.

Now for a final verdict.

Cocoa is for Mac

There really is no contest: for writing Mac software use Cocoa with Objective-C. While Java or C# are more productive than Objective-C, you can’t beat the combination of tool support (XCode, especially in version 4, is doing a lot to help you program in Objective-C), documentation, community. It’s also the most capable, being the native language of the platform.

.NET and WPF is for Windows

While Java is close to C# in productivity, documentation and availability of 3rd party libraries, .NET wins by having WPF, better integration with Windows and being better optimized for desktop apps.

WPF is what seals the deal: there’s nothing even remotely as good in Java land for writing UI code.

Unsurprisingly, .NET is more capable than Java when it comes to all the little things you need to do to integrate with the OS really well. Things like support for Win 7 taskbar, reading/writing registry etc. I’m sure all that can eventually be achieved with Java, but .NET already has everything you can possibly need to make your app a good citizen in Windows.

Finally, Java platform is mostly used on servers and optimized for that. In that context, it’s much more important that an app runs fast in a stead state than to have short startup time.

On desktop, things like startup time matters and Microsoft cares about minimizing that, since their own apps are increasingly using .NET. Your apps get the benefit of Microsoft’s work on optimizing startup time.

What if you absolutely must target both platforms?

What if your startup idea requires multi-platform support and you just got few millions in funding?

It’s still better to hire two competent programmers, each an expert in writing software for one platform.

I’ve seen very few successful products that target both Windows and Mac. I exclude titans like Microsoft or Adobe, who have extremely complex application and infinite amounts of cash to pour into development.

Within the confines of small company, at best you might succeed despite sucking, like Libox (their Mac application doesn’t even respect Cmd-Q). All the runaway successes that come to my mind, like Evernote or Dropbox, did invest in a native clients for each platform they support, because their apps are their core differentiator (there are tens of note-taking applications out there or apps that allow to backup or share files in some way).

SumatraPDF 1.2 released

2010-12-04T07:04:17Z

SumatraPDF team is happy to announce 1.2 release.

Changes in this relase:

improved printing: faster and uses less resources
add Ctrl-Y as a shortcut for Custom Zoom
add Ctrl-A as a shortcut for Select All Text
improved full screen mode
open embedded PDF documents
allow saving PDF document attachements to disk
latest fixes and improvements to PDF rendering from mupdf project

Contributors to this release:

Simon Bünzli (zeniko)
William Blum
Krzysztof Kowalczyk

As always, it’s available from here

Using averages - a common performance measurement mistake

2010-11-25T06:06:05Z

Summary: when people want to get a more accurate result when benchmarking a performance of given piece of code they often run the same test multiple times and use an average as a final benchmark result. It’s a mistake: using the time of the fastest run is more accurate.

By definition, a performance test must be deterministic: given the same inputs it’ll execute exactly the same number of machine instructions, read and write the same amount of data to/from disk etc. If it isn’t deterministic, benchmarking it is pointless.

We all know, however, that execution time is not deterministic. Why is that?

Multi-tasking nature of the operating system is to blame. Your code is only one of the many processes that compete for fixed resources like cpu time and i/o bandwidth. Operating system will interrupt your program and start executing some other code, at random times and for unpredictable amount of time.

If you measure just the time of execution, like most benchmarking methods do, it’ll include not only the execution time of your code but also of other programs executed by operating system during that particular test run.

The same applies to other shared resources like a hard-drive: the benchmarked program asks the OS to read a piece of data from disk but so do other programs. The OS decides who gets to do I/O first in an unpredictable and unaccountable way.

You have little control over that behavior. You can think of execution time of your test as consisting of 2 components:

the deterministic execution time of only your code, which would happen if your process had exclusive access to all resources like cpu and hard-drive
random, unpredictable execution time of all other programs that OS decided to run during that particular test run

In other words, the benchmarked time is: the time your’re interested in + a random overhead attributable to other processes.

This model explains why you should use the time of the fastest test run: it’s the best approximation of the running time that is attributable only to your code (and with the smallest part attributable to other random processes).

Other coping mechanisms when doing performance tests involve trying to minimize the random component by shutting down as many processes as possible, so that less things will get in the way.

8 habits for becoming a better programmer

2010-11-06T01:21:53Z

This post is inspired by a question “What habits made you a better programmer”.

All the habits described below stem from one realization: I’m too stupid to write bug free code so I need ways to compensate for my inevitable human fallibility.

Code reviews

I welcome code reviews because a second pair of eyes might spot mistakes I’ve made.

Some people can’t stand their code being criticized. I avoid bruised ego by assuming from the start that I’m too stupid to write correct code.

Using good tools

I seek out and use tools that help me find bugs automatically and tools that help me understand my code better. Those tools include:

static code checkers like clang analyzer or cppcheck or pychecker
Valgrind
memory and cpu profilers
debuggers
Source Insight (a text editor)

Automated testing and continuous builds

Continuous build quickly alerts to mistakes that break the build.

Automated tests (unit tests, system tests) increase my confidence in the correctness of the code and catch mistakes that cause regressions.

Stepping through all new code in the debugger

I see a lot of macho anti-debugger posturing. The reasoning is: good debuggers make it too easy to fix problems which makes you a sloppier programmer. But this reasoning applies to unit tests as well (although I don’t see anyone criticizing unit tests for that reason).

Stepping through newly written code in the debugger to double-check that it behaves the way I expect is just another way to compensate for the inevitability of writing buggy code.

Avoiding complexity

Unnecessary, productivity sapping complexity is something that no one would defend but popularity of C++ or boost shows that a definition of unnecessary complexity is different for different people.

My bar for calling something complex is lower that many. I stay away from complexity, both self-inflicted (like trying to be too clever when implementing something, using multithreading when it’s not absolutely necessary) or inflicted by the tool (e.g. advanced features of C++).

Diagnostic code built into apps

I add diagnostics to my code. Logging, asserts in debug builds, crash dump submission to my site for analyzing crashes that happen in the wild. They all help to figure out the inevitable problems that you don’t see in testing on your machine but happen on user’s computers due to different configurations.

Writing readable code

No one has writing unreadable code as a goal but it does happen because writing readable code is harder and requires more care and attention that just writing some code that works.

Readable code is important because I know that bugs will happen despite my best efforts to prevent it. To fix them I will have to read my own code long after I wrote it. Therefore I try to make my code as readable as possible for my future self. The specific techniques involve:

balanced commenting. Not too much (so that it doesn’t detract from the code itself) but also not too little so that non-obvious decisions that are not captured in the code are explained.
no cryptic names for variables or functions
no long functions with complex logic
taking the time to make the code look consistent

Re-use high-quality code

It’s much better if other people sweat writing code and fixing bugs. I look for high quality, reputable code and use it whenever I can e.g. I will use SQLite rather than writing my own persistence layer.

Simple duplicate post detection for your blog, forum or commenting software

2010-10-27T04:25:39Z

Mistakes happen

I was reading scripting.com the other day and some article had 3 identical comments from the same person.

A mistake, obviously.

What is less obvious, at least to the authors of that commenting system, is that such mistakes can be easily prevented with a bit of programming.

I know it’s easy because I’ve implemented it in a few lines of python in software running this blog and in my forum software. They run on App Engine but the technique applies to any web development platform.

Duplication detection, the easy way

The idea is simple: before inserting an article/post/comment into a database, check if an entry with exactly the same content already exists. In most storage systems (like SQL database) doing this against large text column is difficult and slow. To make it easy and fast we can calculate SHA1 hash of the text, store it as part of the data describing the post and check for duplicate hash.

SHA1 keys are short. They are a perfect match for key-value stores. With a proper index they’re also very fast to check for in a SQL database.

For added robustness you can trim whitespace from the beginning and end of text before calculating the hash.

This method doesn’t prevent malicious people (it only takes changing one character to change the hash) but it does fix the common problem of people submitting the same content twice because due to network connection problems they were not properly notified that the post has been successfully submitted. It happens more often that you might think.

Using other hash function, like MD5, will work too. SHA1 has better properties but if your programming language provides MD5 but not SHA1, use MD5.

Value your time

2010-10-24T23:40:38Z

A common question on the internet: I want to host a website. Which low cost VPS should I use? Linode ($20/month for the cheapest plan)? Slicehost (also $20/moth for the cheapest plan)? Something else?

A helpful, albeit misguided, answer would weight various pros and cons of many services, compare prices, do rigorous processor and I/O benchmarks etc.

A much better answer is: stop wasting your time (and money) trying to optimize inconsequential parts of your business.

Your time is worth a lot. For the purpose of this discussion let’s say it’s $50/hour (a not so great salary of a good software developer).

VPS hosting is a mature, competitive business. You can reject all plans that are too good to be true (e.g. unlimited bandwidth for $5/month) because they are scams. That leaves a number of roughly equivalent plans. Pick one and move on to more important things.

If a competitive plan costs $20/month, let’s be unrealistic and assume you’ll be able to find an equivalent service that is 25% ($5) cheaper. One hour spent trying to find such a plan would cost you 10 months of savings on such a hypothetical service.

Too many of us are obsessed with getting the best possible sticker price without considering the total cost, which includes additional time spent researching the options.

If you’re Google or Amazon, running thousands of servers, squeezing the best possible value out of each server is worth the time because a minor saving gets multiplied. If you’re choosing a single, low priced commodity among many similar options, you’ll be better of just picking one with minimal amount of research (the good stuff comes at the top anyway) than spending unbound amount of time comparing options in hopes of finding the best possible value.

Startup management lessons from "The Social Network"

2010-10-03T21:14:27Z

The movie The Social Network is centered around a lawsuit that three founders of ConnectU, a social network in the making, mount against Mark Zuckerberg, the founder of competing social network, Facebook.

If you look at at the movie via proper lenses, it can be a lesson about software startup business mistakes. Mistakes that ConnectU founders made managing their project. Mistakes that you can avoid in your own startup.

The relevant facts are:

three Harvard students start working on an idea for social networking website exclusive to Harvard students in December 2002
neither of them is a programmer, so they hire fellow Harvard student to work on it in January 2003. He leaves the project in spring 2003 after graduating and getting a job at Google
they hire another Harvard student to continue coding. He works during summer and fall, gets paid $400 for the work but leaves the project for personal reasons. He recommends Zuckerberg, also a Harvard student, for his replacement
they talk to Zuckerberg on November 30, 2003 and he agrees to continue the project for equity stake. No formal contract is signed
for the next 2 months (December 2003 and January 2004) Zuckerberg pretends to work on ConnectU website but in reality he’s working on his own similar website instead. He registers the original thefacebook.com domain name on January 14 and launches the website on February 4th, 2004
ConnectU website finally launches 4 months later, on May 21, 2004

There are several mistakes that ConnectU founders made managing their startup.

Not using written contracts when hiring people.

The agreement between ConnectU founders and Zuckerberg was oral. If you hire people to work on your idea on a contract basis, write a contract. It should spell what the contractor is supposed to do and how much he will be paid for it. It’s business 101.

You can even add a reasonable non-compete clause so that they can’t just learn everything about your business and start a competing one, like Zuckerberg did.

Underestimating the value of good programmers

It took ConnectU 17 months to launch their website. At least 3 programmers worked on it (2 programmers before Zuckerberg and at least one after) and the 3 founders presumably did something productive as well.

Zuckerberg launched his website in 2 months, with code written all by himself (although he did have a non-technical co-founder). He was 8x as effective as ConnectU programmers.

Not growing fast enough

There are some businesses that can grow slowly and organically. There are some that have to grow fast at any price. The wisdom is to know what kind of a business you’re in.

Social networking websites are in the “grow fast at any price” category but ConnectU founders didn’t act like they understood that. Facebook was launched in 2 months which demonstrates Zuckerberg’s urgency and dedication to the idea at the exclusivity of other things. As soon as he secured funding, Zuckerberg started to aggressively hire more people to work on it, which is exactly what you need to do in such a situation.

ConnectU founders pursued other time-consuming activities during that time (they were training as rowers for Olympics) and dragged their feet hiring talent necessary to implement their idea.

Not supervising the work and not firing ineffective employees

Zuckerberg was able to string them along for 2 months by making excuses via e-mail. During that time he didn’t deliver any code.

Sure, Zuckerberg won’t win Gentlemen Of The Year award but if you’re mis-managing your employees so badly, you only have yourself to blame. After a month of no results they should have just fired Zuckerberg and hire a more dependable programmer.

Not paying your programmers well

We don’t have enough facts to say why ConnectU had such a hard time finding effective programmers for their project but it’s telling that they paid the second programmer $400 for several months of work.

A fair market rate would be more like $5000 per month. If you’re serious about your idea, you need to be realistic about how much you need to pay your crucial employees.

Treating programmers as replaceable cogs

In rare cases you can but programming is hard, good programmers are rare and good code is crucial element of software startups. The visible product might be a website, but what software startups really produce is code behind those html pages.

ConnectU founders seemingly treated programmers as hired guns that can be replaced at any time.

What Facebook and other technology companies do is hiring the best and retaining them for as long as they can.

Paying in equity

It’s unclear if ConnectU founders had funds to pay in cash for programmers but from the point of view of the startup founder, paying in equity should be done only if you have no other options.

It didn’t bite ConnectU founders because they failed but if they were successful, they would pay disproportional amount of money for the initial work.

In all fairness, this is one mistake that Zuckerberg also made. He founded Facebook with his friend Eduardo, with 70-30 split, with no vesting provision.

Eduardo put a minuscule amount of money ($1000 initially and later added $18000) but other than that he doesn’t seem to have done much work on Facebook. The idea was Zuckerberg’s. The code was Zuckerberg’s. Eduardo was a business guy at a time when there was no business to do. He wasn’t interested in the project enough to work on it during a crucial time after launch, in summer 2004, when he opted to do an internship in New York instead of working with Zuckerberg on Facebook in California.

Despite contributing very little, Eduardo ended up with 5% of Facebook (worth more than $billion). Good for Eduardo but sucks for Zuckerberg.

Zuckerberg could have done it all by himself but at the very least there should be a clause stipulating vesting schedule of, say, 4 years, saying that if a person stops working on the startup, like Eduardo did, he’s only entitled to the vested part. Since Eduardo stopped working about 6 months in, he would only get 1/8 of 30% (3.75%) and the rest would go to other founders.

What you don’t know you don’t know will hurt you

It all shows that even Harvard hot-shots are not immune to youthful business naiveté. The above mistakes are pretty basic but they still might bite inexperienced people, regardless of how intelligent they are in general.