A good friend of mine, JP Duplessis and I have been tinkering away on an app for the last 10 years or more, it started out as a replacement for the then cancelled Microsoft Money app. We built it entirely in C#, it started out as WinForms, we ported it to WPF and XAML and then fixed bugs.

The app is really designed for programmers who want to tinker and add stuff. JP added a whole module to help deal with rental properties. The data is stored in sqllite, so it is super easy to extend and add whatever you want.

The surprising thing is how small financial data really is. For a family of 5 with data all the way back to 1997 (which I exported in QFX format from Microsoft Money and my wife’s data from Quicken) the entire database is just over 6 megabytes. In today’s hard drive world, this is miniscule.

So MyMoney.Net loads up the entire database into memory, which means it is super snappy to pivot, slice and dice and jump around your accounts. You might wonder how long it takes to load, ooh, about 1.2 seconds 🙂

So anyway, I hope a few other people can enjoy the app, and contribute on GitHub. I look forward to many interesting pull requests.

A good friend of mine named JP Duplessis joined a startup named Mylio and they built some really amazing photo management software. I’ve been using it for over a year now and I have to say, I really like it.

I was tired of the old Windows Photo Apps that are so, well, um, boring and feature limited and I was tired of my wife losing her MacBook and all her photos on it.

You should have seen the moment when we set it up in my kitchen and I could finally sync photos off her MacBook onto my Windows PC for the first time. I thought I died and went to heaven !!

I then added a bunch of photos from my son who is an avid photographer.He went on a hike in California (which is where he lives) and I would have never seen this photo, not in a million years of begging and pleading for photo backups. He works really hard in a startup and doesn’t have time for facebook. But now, like magic using the Mylio Cloud Sync feature, it pops up on my machine and I can enjoy a whole series of amazing shots of this Tiger Swallowtail butterfly.

So I’m now using Mylio to sync over 60,000 photos across 9 machines (I have a PC, laptop, a PC at work, and a backup NAS drive, my wife has MacBook, iPad, and iPhone, and my son has Android phone and a MacBook running Windows). I hear some users have over 1 million photos and even more machines, and that makes me feel good about the scalability of this app.

Nothing else came even close to “managing” this many photos, and Mylio is incredibly snappy. I can slice and dice and pivot through folders, albums, people, ratings, all to my heart’s content and I’m never waiting for a photo to load or for thumbnails to be generated.This snappiness is probably my favorite feature of the app.Who has time to wait for photos to load, like on all those “cloud” based photo sites?I don’t.

I’ve also used the built in photo editing features, and I love that all edits are non-destructive (they are stored in a separate *.xmp file).So any user can go back and reset the edits and try again to get a better result and as the app improves, even existing edits can look better after a Mylio update.

Of course, most of my photos are huge RAW files from a fancy Canon or Nikon camera and Mylio handles all those natively, no stupid OEM drivers necessary, which is fantastic.They must have done a ton of work to pull that off and I can “share” these as smaller png files on Facebook with a single button click.

So Mylio does everything I need with photos, in a fast, smooth and well-designed user interface.

Have you ever wanted to do something naughty from your lovely well behaved sandboxed WinRT application? Do you need to call some Win32 API that you don’t have permission to do from WinRT?

Well WinRT itself does this using a separate service called the RuntimeBroker. Many WinRT objects use RPC to call into this broker process and do those things that need elevated priviledges.

I built a sample application that shows how to do this. Essentially it goes something like this:

Create a static C++ library containing a MIDL interface and compile it using /winrt to make it a windows runtime (WinRT) interface.

This generates RPC proxy stuff needed to marshal the interface across processes.Compile this into a new C++ DLL called “YourInterface.ProxyStub.dll”.You will register this dll using regsvr32 and this is needed for RPC to work. This proxy stub and the implementing broker dll will need to live in a location your WinRT app can access, like c:\windows\system32.

Next create a Universal C++ DLL called “YourInterfaceBroker.dll” – this will contain the implementation of the interface and is designed to run in the RuntimeBroker process.This DLL will be able to call out to Win32 and do interesting things.

Register the broker using a custom registry script.

Lastly create a C# Blank Universal WinRT application to test out your new interface, referencing the *.winmd that was generated by step 1.When you instantiate your new runtime class it is loaded into the RuntimeBroker process, and your C# app gets back the client proxy to it so each call to that object is marshalled automatically to the RuntimeBroker.

MIDL Interface Library

In my sample I started with this static C++ library, I added a MIDL file called Microsoft.Service.Sample.idl, this defines the name of the *.winmd so its namespace has to match the filename. I then used the MIDL Tab in the C++ properties to turn on “Enable Windows Runtime” /winrt compile option. The *.winmd file is placed in the project output directory. I built it once and this also generates a dlldata.c and *_i.c and *_p.c files. I added those files to the project. To compile them it is easier if you just turn off the C++ option for precompiled headers. I also added the C++ preprocessor defines: WIN32;_WINDOWS;. So now you have a static library containing the RPC stubs needed later. For the purposes of this sample app I defined the following simple WinRT interface and runtime class:

ProxyStub

I then added a C++ Win32 DLL project called MyService.ProxyStub. This dll has to include the above files again, but this time with the C++ preprocessor definition “REGISTER_PROXY_DLL”, and you need to generate a new GUID for your runtime class id (different from the one in the MIDL file) in a new ProxyEntry.c file as follows:

You’ll also need to add a VC++ Include Directory pointing at your interface static lib directory where the dlldata.c and *_i.c and *_p.c files got generated. You will also need to add the linker input “rpcrt4.lib”. This generates the proxy stub needed for RPC to work. This dll will be registered using regsvr32.

Broker

Next I added a Universal C++ DLL project called “MyServiceBroker”. I added a reference to the static library project, I included #include<ObjIdl.h>in the pch.h file and again added the VC++ include directory where the *_h.h file was generated. I wanted this DLL to work on the IoT SKU of Windows 10, which is why I used Universal DLL, but I want to run this outside an app container so I removed the following from the *.vcxproj file: <AppContainerApplication>true</AppContainerApplication>. I also added the following linker instructions to each <Link> section: <IgnoreSpecificDefaultLibraries>comsuppwd.lib; comsuppw.lib; kernel32.lib; ole32.lib; user32.lib</IgnoreSpecificDefaultLibraries> <AdditionalDependencies>Wlanapi.lib;mincore.lib;onecoreuap.lib; WindowsApp.lib;</AdditionalDependencies>

Lastly I added the a class that implements my new interface as follows:

Setup

First you need to copy your *ProxyStub.dll and your *Broker.dll to a place that the WinRT app can access (like c:\windows\system32) otherwise you will get E_ACCESSDENIED when trying to call object from WinRT.

To register the broker I created a custom registry script containing the following. Notice the GUID used here matches the one I generated for the ProxyEntry.c file earlier.

Running this from administrator command prompt makes it possible for WinRT to construct your runtime class. You may need to take ownership of the WindowsRuntime part of the registry in order to do this. There is a tool floating around called TakeRegistryAdminOwnership.exe that can help with this.

You may also need to install the VC++ debug C++ runtime bits (vcruntime140d.dll and ucrtbased.dll) if you have not already installed that on your test machine. Use depends.exe to find out what else the proxy and broker are dependent on if they still refuse to load.

C# App

To test out my new brokered service I created a blank C# windows application and added a reference to the generated Microsoft.Service.Sample.winmd file, then added the following lines:

var service = new Microsoft.Service.Sample.MyService(); service.DoSomethingFun();

When you run these lines the MyServiceBroker.dll is loaded into the RuntimeBroker.exe process (you can attach to that process using your VS debugger and watch it happen and you can debug your broker that way also). You will see RPC stuff on the stack when the DoSomethingFun call comes in. Don’t worry about terminating the RuntimeBroker.exe process, it will auto-restart.

Callbacks

If you need to have your broker do something async and call back to your C# application later you can easily define a new interface, implement that in C# and pass it to your broker as an argument, then the broker can call that interface. This RPC interface will “timeout” after a minute, so you may need to repeat that process periodically or do a heartbeat kind of thing to keep it alive. You could build a WinRT component project that wraps all this and exposes a new “Client” interface that turns all this callback stuff into C++/CX events so that it is easier to consume in your C# applications. Your “Client” interface could also expose C++/CX properties and events so you have a nice modern interface to your new broker.

Alex Kelly showed me this really cool project by Nathaniel Elijah where he used a software defined radio to decode the power data from an Efergy power monitor. So I had some fun adding an AllJoyn wrapper on that so that my Raspberry Pi can act as an Alljoyn sensor which I can then easily connect to using my PC where I can grab the data and have fun with it in C#.

I had some fun over the Christmas holiday playing with my new toy,Magic LED Lights. These are controlled from your phone using Bluetooth Low Energy. But as is often the case there was no Windows Phone app for these, so hey, it was the holidays, I had some time, so I built one. Actually, I built aWindows Phone appand aWindows 8 app. It is implemented in C# and most of the code is shared between the two apps.

Of course, this is just the beginning. Imagine the lights turn on when I walk into my office. Or the XBox controls the lights so they turn red when I get shot in Halo. There are many fun applications of this really simple but very cool new tool.

As XML has exploded across the planet I continue to get many requests for improvements to my XML Notepad of 2007. The tool has been downloaded over a million times, so I figured it’s time to show it some love and fix some bugs. In the process I updated it to NET 4.0 using VS 2013. I was amazed how everything from back then still works, including the Unit Tests. That is pretty amazing platform compatibility. Windows is a great platform and Visual Studio is still best of breed for software development, and I still love C#.

I built a simple app called Seismograph to visualize the accelerometer data on my phone. The reason I built this is because I wanted a simple way to check the vibration of the motors on my quadrocopter. I saw some really nice apps for android, but all the windows phone accelerometer apps were crap. So I built my own 🙂

I then ported this Seismograph for Windows RT so I could also run it on my Surface device. When I did that port I discovered that the same approach to graphing the data didn’t work well on a bigger screen, it slowed down way too much. So I had to re-implement the scrolling graph control. Previously I was building a new PathFigure with the new points scaled to fit the screen, and so each frame was a new Path object and that’s how it would scroll across the screen. Turns out the performance is a lot better if I reuse the PathFigure and only add to the Path object and never remove any points, and rarely re-scale the points. But in order to scroll then I needed to adjust the canvas position of the path to the left, well turns out I can do the scrolling at a higher rate than the point adding which results in a very smooth scroll which looks great. The problem is I would run out of memory if I never removed points, so what I do is cycle two Path objects, when one is completely offscreen on the left, I recycle it and use it on the right, and this is how I get really nice performance on the Surface. So I back ported that to the phone and it looks great there too.

Privacy Policy

The app records the accelerometer sensor data so that you can choose to save it locally on your device either in a bitmap image or in an XML file. The app does not send your data anywhere else, so the data is not shared with anyone. You can choose to send the bitmap image or the XML file to someone else, but that is up to you. The app does not even know if you have shared your data with anyone.

UPDATE: Microsoft made me change the name of my app from “Outlook Sync” to “Sync for Outlook”. In order to get this new version which has some other fixes as well, please uninstall “Outlook Sync” and install the new version below, thanks.

So a friend of mine was thinking of ditching is iPhone and trying Windows Phone, but couldn’t find a way to sync his PC Outlook Contacts with Windows Phone without pushing everything up to outlook.com. He didn’t want to do that. He came to me and asked why Apple can sync Outlook directly but Microsoft’s own Windows Phone can’t? Well, I took it as a challenge J

Turns out it is not that hard to do. First you will need to install the Phone App, the following link will take you to the app store:

This is a Click Once app what should work on Windows 7 or Windows 8 and on Windows 8 you will see the following popup from Windows:

click More Info and you will see the following:

Click Run Anyway and after the app launches you will see this Firewall alert. The app needs to be able to receive requests to sync from your Phone over wifi, so checking both boxes on this alert will allow that to happen:

Now when you launch the Phone version of the app it will connect to your PC over wifi and you should see the following:

If this is your phone, click “Sync this phone” to give it permission to push your Outlook Contacts info to your phone. Now on your phone you should see a report showing what was updated, here we see we received 4 new contacts, 2 were updated, and 2 were deleted.

The new contacts will show up in your People Hub:

and you can edit these contacts or delete them and the sync will pick up your changes and push that back to Outlook. These contacts are associated with the “Outlook Sync” app, notice the account is named “Outlook Sync” below. This means if you uninstall the app on the phone all the contacts it has downloaded to your phone that are not associated with any other account will be removed, leaving your phone in the same state it was in before you started which is nice and friendly.

Have you ever wanted to control your PC using your Windows Phone? Well it turns out to be surprisingly simple to do. I found some sample code on MSDN that plays tic-tac-toe and so I took that and made some simple changes.

I received an email from a friend asking for help figuring out a fun math problem. He works for FIRST and the problem is figuring out how to match up over 400 teams in Washington State with 5 separate event locations, minimizing the driving distance for each of those teams. Each event was happening on the same day, and each team gets to compete at only one of these events.

So I quickly cranked out a nice little Silverlight Application to do the job. And I hooked up to the BING Mapping API to calculate the actual driving distances from each team to each event location. Silverlight and BING worked beautifully together. So far so good, but now for the hard part. How do you calculate the optimal assignment of teams to events that results in minimal total driving distance? I hacked out a brute force solution that first assigned every team to their closest venue, but then there were additional constraints that got more interesting. Each event has a minimum and maximum capacity, so if an event was over populated, some teams had to move to the second or third closest venue. This wasn’t too hard to code, but I quickly realized, the solution I was getting was not necessarily the best. For example, in the diagram below, let’s say the maximum capacity for each event is 3 teams, which means team “i” needs drive all the way to “C”. Clearly this is silly.

It is better to move “c” to “B” and “f” to “C”, making room for “i” to join “A”, like this:

But this is a tricky “ripple” effect that is hard to find programmatically without having to essentially search all combinations of teams to events, but then I quickly realized it would take about 100 years to execute that kind of exhaustive search on my machine because 400 factorial is a large number.

So this is when I contacted Microsoft Research. Lev Nachmanson works there and is a good friend of mine and a powerful magician when it comes to mathematics. So I presented the problem to him, and he said he’d think about it.

In a short while I got an email back saying he had a solution. He explained it to me over the phone, I implemented it, and it worked, finding the solution in less than a second. I was very impressed, but I also a bit skeptical. I couldn’t believe it could be so simple. I went to his office to get a better understanding of how it worked.

This is how he explained it to me. The global task is to drive to the minimum the sum of the distances from teams to the events they are assigned to. To initialize a solution assign each team to their closest event, but then think of the remaining optimization problem as a type of traffic flow problem. We will be shifting the teams between the events, so we need to consider a graph for doing this. The edges of this graph are AB, AC, and BC. (It is called a complete graph.) For example, above we moved “c” along edge AB, “f” along BC and “i” along AC. To find a solution we need to consider all paths on the complete graph that don’t repeat an edge. A path can be a cycle, like ABCA, but every edge in it should appear at most once.

To run one iteration, take a path as described above, then take the first edge of the path and shift a team along it such that shifting it along this edge “makes the least damage”. Here the total sum can even grow. Take the second edge and do the same, and do it for every edge of the path. When we are done with the path, look at the total sum. If we are lucky and it went down, we accept the move, otherwise, we discard it. When no path gives us a gain we are done!

Then how many possible paths do we have? Well in this case with 3 events there is AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA, CBA, CAB plus all the cyclic versions of these: ABA, ACA, BAB, BCB, CAC, CBC, ABCA, ACBA, BACB, BCAB, CBAC, CABC, a total of 24. It is not a huge amount of paths. The last thing to do for running the algorithm fast is to know how efficiently to find a team which can be shifted along an edge with the minimal damage. The best data structure for this is a priority queue.

The end result was that on my desktop machine I could use this algorithm to find the optimal solution in sub-second times, which is fantastic. Super thanks to Lev! I just love it when a nice elegant algorithm makes software work really well. As I like to say, “there’s genius in simplicity”.

Posts navigation

Simplicity is not the opposite of complexity. Simplicity is too often an excuse for being simplistic. The world doesn't need any more stupid software. The opposite of complexity is beautiful, elegant design.