Monthly Archives: January 2013

Using SQLite for your Windows RT Apps

If your app needs to save user settings or application data between runs SQLite can help you. Even if you want to simply deploy a well-structured app-level read-only configuration along with your binaries, the power and ease of SQLite is hard to beat.

Bringing SQLite into your App

You’d need to download the SQLite source code from here. The download contains 4 files, but you only need 3.


  • shell.c – used for compiling a binary to interact with SQLite. (you do not need this one)
  • sqlite3.c – source code for SQLite.  Yes 1 huge c file.
  • sqlite3.h – header file
  • sqlite3ext.h – 2nd header file

You only need the last 3 files in your project.


To make sure your sqlite3.c compiles in your WinRT project you need to make the following changes to the properties of this file in your Visual Studio solution. Don’t forget to do this for All configurations and for All platforms, otherwise you will encounter errors when switching between Debug and Release or when switching to target your Surface.

  1. Disable WinRT Flag.  Select properties of the sqlite3.c file.  Go to Configuration Properties -> General and switch Consume Windows Runtime Extensions to No.
  2. Set a compilation flag. Go to the Preprocessor section and insert a SQLITE_OS_WINRT directive.
  3. Disable Precompiled Headers: Go to the Precompiled Headers section and select Not Using Precompiled Headers in the Precompiled Header value.

Now try compiling your project. It should work.


To use SQLite code from your C++ code base you can simply start calling exported functions. To learn about their API, look at the docs. This can help you get started: The docs suggest that you add a special handling for the temp directory from within your WinRT Code. Refer to this doc for more info:

You can also wrap SQLite functions in a proper WinRT wrapper which would be accessible to C# code. You can download wrappers from here. Just be careful, the developer left this line of code there, which I think should be changed:

int ColumnAsDoubleAt(int index)
return sqlite3_column_double(stmt, index);

IMHO, The function should return a double. Even the compiler thinks so. It gives you a warning.

In the next post, I will discuss various uses of SQLite in my App. You can get a sneak peak here.

News, the way you want it

During development of my offline reader, I wanted the news articles to appear cleanly formatted, without providers’ headings, formats, ads, comments, etc.  If you have an iPhone, you are, probably, familiar with an app called InstaPaper which does that for you.

So, for my app, I was looking for a web-based REST API which can take a URL of a news article and returns a nicely formatted string representing the article text with minimal amount of extra shmutz. I reached out to InstaPaper, but they could not accommodate my request, because their infrastructure is not yet scalable enough to handle many generic requests.  They did suggest a great tool called DiffBot instead. Go ahead try it, it’s really cool.  You get back a nice JSON-formatted response, which you can parse and present the way you want.  Their prices start at 20/month, so I have yet to consider it.  But their API is clean and they do an awesome job at parsing.

I also found another tool which I recently incorporated into the codebase.  Readibility provides a similar API to DiffBot and I did not have to pay for it yet.  So for now, I am using them.


What is Runtime Broker and why does it eat memory for lunch?

It started happening soon after I got my Surface.  I started noticing that it would slow down considerably.  I began rebooting it just to get it back to its happy, snappy state.  I decided to dig a little deeper.  Because WinRT is, basically, Window 8 compiled for the ARM processor, I can use familiar Windows tools, like Task Manager to look under the hood.

I sorted by Memory in descending order like this:


and noticed that the top offender was a process called “Runtime Broker”.  I started a thread about this on the forums and soon learned that the Runtime Broker process is responsible for ensuring that the new Windows Store Apps behave.  But there was no explanation as to why its memory consumption grows over time.  Someone mentioned that  a misbehaving app can cause the Runtime Broker process to bloat, but there was no indication as to which app that was.

Recently, my thread was updated with a more detailed information.  Apparently, one of the early-released clock apps has a bug which causes Runtime Broker to grow in size like that, and it does not only affect Surface, it affects any Windows 8 PC running the rogue clock app.

So uninstalling the app worked. My Broker Manager never grows beyond its normal memory size of under 10MB and Surface runs well. But can we really blame the App Developer for this? The answer is a definite No. AFAIK a good operating system isolates processes in such a way that one process cannot cause others to suffer. But this is exactly what’s happening here. I am not sure whether Microsoft knew about this problem before they released Windows 8, but if they did, they should have been a lot more vigilant in their App approval process in order to block any such rogue app from making it into the Windows Store. This is a serious FAIL on Microsoft part. It shows that not only were they in a hurry to release Windows 8 and in haste missed a few critical issues, but they also were or are very lax in their app approval process, as they a aim for quantity, not quality of the app. This is not going to help them in the long run. I hope they adjust their strategy, at least on the app approval part.

My Support Thread:

Similar Thread:

PS.  I ended up in this situation because Windows 8 does not display a clock in it’s Modern Start menu, a normal main window when running Windows on a tablet.  I referred to this as a major omission in my earlier blog. This is, IMHO, a big deal