As you may know, I have a Windows RT Tablet
and since the update to Windows 8.1, I'm very happy with it. My only main concern is a bit the lack of apps for it, although that situation seems to get better every day.
Last weekend, I had a small problem which a small app could have solved for me, but on the Windows Store, I could not find any app doing this. Being a programmer, I decided to write that app myself. I even have a Windows Store developer account, so I would be able to publish that app then for free, for others. C++ being my favorite programming language (although I'm also very fluent in C#, which would be the second option here), I decided to start writing that app using the new Windows API, or 'Windows API for Windows Runtime apps'
, how it seems to be called now. I've developed a handful of Windows Store apps already, so I knew that it would be no picnic, but this time, the design of the API stopped me from being able to create that app at all. Or to make it more clear:
Microsoft! Developing for your new Windows API sucks!
And here is why:
First, not to be unfair, there are also good sides.
- Microsofts developer support is great. Apple and Google for example should learn something from this. And the documentation is supberb. Ask something on the forum, and you usually get a useful answer. Sometimes even from a Microsoft employee. They even give useful answers via mail, and that usually quite quickly.
- The developer tools, the app submission process and the user interface and statistics tools of the Windows Store are great. No other app stores compare to this.
- Some parts of the new API are thought through, and very nice. C++/CX is IMO unnecessary, but has some useful features, at least. Combined with VisualStudio, it's a very nice experience.
But the bad sides are sometimes a real show stopper:
- The API is cluttered with arbitrary limits. For example context menus are limited to have only 6 items. 6. Seriously. How are people supposed to create complex apps with only 6 commands per menu?
- Another show stopper is the file access sandbox: You can only open files previously selected by the user, or in a folder selected by the user. What's with files referenced by that selected file? No chance to access that. And even if your app can live with that, if you want to access a file later again, you are limited to 1000 tokens (future access list). This seems to be much, but it is another senseless arbitrary limit, and it stopped me from finishing my app, which needed about 10 times more.
- Debugging threaded C++ code is horrible. If something goes wrong, you usually only get a "WinRT originate error", with a memory pointer address. Nothing more. Good luck finding your problem. It wouldn't be that bad if the next point wouldn't be there:
- You need to create a thread for everything. Want to open a file? Create a new thread. Copy something from the clipboard? New thread. Show the user a message box? Thread. Context menu? Thread. I know the reasons behind this and that in a newer C++/CX, there is even the 'await' keyword. But really. This makes the code so much more a pain in the ass. Did the designer of that API ever try to create a serious app using this on his own? I bet not.
- Exceptions everywhere. Everything throws exceptions, when something isn't as expected. And a lot of stuff won't be expected. ("Not allowed in this context" What!?). Most possible thrown exceptions do not even seem to be documented. Good luck publishing a stable app which won't crash.
- You are forced to use XAML or C++ created XAML elements for doing user interface stuff. Unfortunately, XAML and its themes and styles are a big un-debugable clusterfuck. When something is wrong, your app fails, and good luck finding your problem in all the styles and XAML files. Also, overriding stuff is very difficult. Microsoft seems to have noticed that, because they provided a tool named 'Blend' so you can try to edit your stuff easier. I'm still undecided if I love or hate Blend.
- There is no way to overwrite drawing of a control. Really. Owner drawn controls? Nope. You can implement your own DirectDraw 2D drawing engine, which I even did - took about 3000 lines of complicated code - and it works, but seriously?
So in short: The API works, but - IMO - it is only usable for creating toy apps. Maybe one reason why there aren't that many Windows Store apps is that it might be a bit too complicated or sometimes - like in my case - even impossible to implement your idea for an app. If you want to do some serious app, then this is sometimes simply not possible. The API is young, so I hope Microsoft will make some changes to it - That's why I wrote this blog post. I know a few Microsofties read this blog :)