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 :)
nine comments, already:
Had a similar experience. Cool to read something like this – just as I would have written it. Hope Microsoft will listen.
Boran - 06 06 14 - 05:07
After a year of iOS development, it is just as bad. The “Crash and throw a memory pointer.” Is every crash in iOS. It sucks.
Andy - 06 06 14 - 06:51
I would never even consider owning OR programming for a Microsoft tablet device, because of something I learned twenty-five years ago: MICROSOFT SUCKS!
Xetnert - 07 06 14 - 01:42
Andy, set a global exception breakpoint and you will see where stuff actually crashed
Tom Wilson () - 07 06 14 - 05:02
I understand why Microsoft is pushing everything towards C#, but at the same time it also feels like they’re trying to kill off every other “legacy” language binding. A sad trend.
KIENI - 11 06 14 - 12:46
Same experience here. I am developing a medical imaging software using C++/xaml/DirectX. I am ok to do everything in thread. But debugging is a pain in XXX. There are usually 30+ threads running. When a crash occurs, you have to browse through every one of them to find out which one has useful stack information. Most of the time, I found nothing: none of the thread has anything useful in the stack that can help me to analyze the issue.
Villager West - 10 09 15 - 16:29
While I agree with most of your points, your arguments about threads are wrong. Making things asynchronous does not necessary mean creating new threads. For example wen reading a file with an async method, there is no new thread created, just the IO completion port is put to use.
And if you think using the async keyword is pain, do you really suggest that using callback would be less pain? Really?
Igor Kulman () (link) - 20 01 16 - 11:44
Ingo, it seems you never had to code an app with that API which has to write non-trivial files. For example with lots of seeks and referencing or merging other files into a single one. That’s simple hell with that one.
niko - 20 01 16 - 11:51
The API itself is just bastardized in the name of security (even on the C# side of things). What if you want to shell another executable? Nope. What if you use an ODBC driver to connect to an obscure database platform. Nope. What if you need to PInvoke a native call to work with custom hardware (on a desktop). Nope.
Everything you could do in most programming languages for the last 25 years is locked down. Sure, they’re are some handy API’s but you don’t see useful software coming out of the app store because some of that software simply can’t be written for it without jumping through hoops if it’s even possible (imagine a consumer backup product that wants to leverage scheduling tasks via the Windows scheduler?... nope). Maybe you want to write an app that has a service that supports it, something that needs to be running 24/7. Nope (you can’t write it and distribute it through the store anyway).
These are the reasons the store is failing on the desktop side anyway.
John - 04 03 16 - 14:52