Back in 2009 I published a set of Extension methods called Generic Extension Methods.  Over the years, hundreds of people have downloaded the source code and made their own projects with it.  Now I’ve refined the extensions and repackaged them under Gateway Programming School.  

There are extension methods for dealing with DBNull, getting/setting values of properties of an unknown typed object, and manipulating text.

Many of the methods exposed back in 2009 are no longer applicable as Microsoft has included many of the methods into the .Net Framework.  This library will grow in the near future as it becomes actively used in the GPS projects.

You can get more info at the Project Site or on GitHub.

So, full disclosure, I’m a Microsoft guy.  I make far more money immersing myself into Windows development than I would in developing for any other platform.  There’s good reason for this, but that’s a topic for a different article.

What are they?

Windows 10 is a general purpose operating system.  You can do just about anything with it.  Want to host a personal website?  Done.  Want to develop for your hobbies?  Done.  Want to do serious work?  Done.  Want to play games?  Done.  Windows 10 is the best iteration of Windows to date and the breadth and depth of usages for Windows 10 is beyond compare.

Android-x86 is an end-user operating system.  You can do many things with it, mostly surrounding social interaction, casual gaming, and light business applications.  It’s also a pretty good platform for general web activities as Chrome on Android is just as good as Chrome on Windows.  What it’s not is a serious OS for developing software or hosting your favorite game server.

If they are so different, why the comparison?

I am limiting this comparison to end-user scenarios: Browsing, casual gaming, and social interaction.  I’m also ignoring hardware specifically designed for Android or Windows 10.  Instead, I’m using a neutral platform, a Dell Inspiron laptop.

All the formalities aside, let’s get started.


Chrome is available for both operating systems.  The experience with Chrome is nearly identical.  As far as performance, Chrome on Android seems faster than it does on Windows.  This is probably because Chrome does all kinds of funky things on Windows to try to be an operating system inside an operating system.  On Android everything is already an OS inside an OS, so Chrome is a lot lighter than it is on Windows.  An Universal Windows App version of Chrome would be way better than the current desktop version and would probably trounce Chrome on Android in performance as UWP apps are typically written in C++ or CSharp, both of which are light-years ahead of Java in performance.

Social Interaction

Now, I’m only going to compare apps, not websites.  Some apps are not available on Windows 10 because their Website performance is so good (generally because the hardware for Windows 10 is 10x faster than Android products).  This is a mistake from my perspective, because websites are much harder to develop (if you want to know why, leave a comment and I’ll explain).

The elephant in the room is the respective Facebook apps.  Here, there’s no comparison.  The Android Facebook app is quite possibly the best app on Android, period.  It’s the most fully featured, usable and well thought out app anywhere.

In comparison, the Facebook UWP app absolutely sucks.  It’s tempermental, lacks features and sometimes won’t do simple things like showing the notifications.  I don’t know if this is intentional, but it sucks.

Facebook has published some interesting apps for managing your Facebook pages and advertising campaigns, but they are only available on Android (maybe iOS, but who cares?).

Next is Twitter.  Unlike Facebook, Twitter seems to keep their Android and UWP apps pretty much synced up in both functionality and performance.  I suspect they are using a common C++ code base which means it’s a lot easier for them to keep things in sync.  It’s also nowhere near as fat as the Facebook app on either platform, but it doesn’t need to be as it’s a much simpler set of functionality.

The final app I’ll compare is IRC Cloud.  Wait, I cannot.  IRC Cloud doesn’t have a UWP app.  Nevermind.  This is another case where the Website is seen as the primary channel for usage and thus a stand-alone USP app is ignored.


When it comes to gaming, Windows 10 absolutely trounces Android.  There’s simply no comparison.  Even limiting yourself to UWP games, they are typically better, more fully featured, and perform better than any equivalent Android app.  Just go to the Windows store.  The highest rated apps are all games, and for good reason.

From a social perspective, the XBOX apps on Windows and Android echo the gaming experience overall.  The XBOX app built into Windows 10 is phenomenal.  Every little bit of social interaction available on XBOX is here.  You can even broadcast your Windows 10 gaming sessions to your channel, just like you can on the XBOX One.  The XBOX One app for Android is essentially a remote control with a few simple features that don’t do much.

Even when Android and Windows both have the same game, the Windows version is typically better.  Remember that 10x more powerful hardware thing?  That makes a big difference for publishers when deciding what type of games and how to code them.  Many, many, many games on Android are built with Unity, and if you build a game with Unity, it’s a no brainer to target UWP, XBOX One, and Android in one fell swoop.  Android x86 narrows the gap a bit, but Windows 10’s graphics drivers are so good, that you still get a better gaming experience on Windows 10.


It’s a tie.  You really have to decide what your main usage for a computer is to decide which way to go.  If browsing the web and reading email is your thing, then you can’t go wrong with either Android or Windows 10.  If you want native apps for social media, then Android trounces Windows 10, unless you limit your social media experience to Twitter, at which point it’s a tie.  Finally, Windows 10 owns gaming.  There’s really nothing else to say about that.

Of course, there’s some philosophical differences when choosing between Windows 10 and Android x86.  If you’re a Microsoft Guy, you cannot go wrong with Windows 10.  There’s nothing about Android apps that either isn’t matched in a UWP app, or a website.  If you have needs beyond those covered here, you’re probably going to be better off with Windows 10.

If you are an Open-Source, or anti-Microsoft Guy, then Android-x86 is for you.  You’ll be more than satisfied with the apps available through the Google Play Store, and most really benefit from the faster hardware.  If you’re a power user in this category you’ll probably dual boot Android and a more traditional GNU/Linux system such as an Ubuntu variant.

Android-x86 is what Chromebook should have been.

So, my love-hate relationship with Android is turning to pure love on this laptop.  The hate part is on phones and tablets where typing is an excercise in absolute frustration.  But when you have a REAL keyboard, Android shines.

As far as GNU/Linux distros go, Android actually has high-quality apps.  The same cannot be said for traditional GNU/Linux distros.  The one type of app that’s sorely missing from Android is a serious IDE.  There are some toy IDEs available in Play Store, but they don’t even come close to the usefulness of Visual Studio or Eclipse.

I’ve run a bunch of apps and so far they seem to work fine:

  • Play Store
  • Facebook
  • Google
  • Twitter
  • WordPress (I’m typing this in it right now)
  • Chrome
  • Outlook
  • GMail
  • Microsoft RD Client
  • TeamViewer
  • Microsoft Groove (by far the best music subscription service)

As a matter of fact, I haven’t run across an app that won’t run, though I haven’t tried any games (I’m not a big gamer, especially the casual games that many people seem to love on Android).

Now, Kubuntu is also installed on this laptop (I had to, see my previous post about getting Android x86 installed).  I cannot see using it for anything other than an IDE host.  My main system had a hardware failure (the controller on my Intel 910 PCIe IDE died) and until the replacement arrives, I’m stuck without a computer to work on my projects.

Unfortuantely, this laptop is not a touchscreen hybrid or anything; you have to use a mouse to click things.  I’m not sure that’s entirely a bad thing, but when I’m feeling lazy a touch screen would be nice.  I may try to get my hands on an Acer Aspire R7 to install this on.

My favorite part of Android x86 is how good (awesome) text looks.  Fonts are clear, sharp and large.  I think in the desktop world we get so caught up in cramming stuff on the screen that mobile-centric operating systems seem alien because of their much better layout and whitespace usage.  Having to use your thumb on things means lots of space around clickable elements.  This forces the programmer to spend more time refining the user experience and it really pays off.  As I’m getting older (old?) my eyes are going bad.  I use an LG V10 T-Mobile phone, which is pretty big (not phablet big, but close).  Even still, I have to use the next-to-highest font size setting to see it when I wake up in the morning.  I’m so accustomed to Android apps being displayed with large text that I’m using a fairly high font setting on this laptop.

And it rocks.

In another post I’ll compare and contrast Windows 10 versus Android x86.

Thanks for reading!

Wew… I’m glad that’s done.

My main laptop died last week and I replaced it with a desktop to get more bang-for-the-buck.

The desktop is great… I love it. But it’s stuck at my desk. I’ve been used to having a laptop to code on in the living room. Now it’s gone and I’m lost.

The solution is a laptop running TeamViewer. I bought a used Dell Inspiron with Windows 10 on it. Unfortunately, it’s a rather low-end model that’s 6 years old. All I bought it for was TeamViewer. Windows 10 was overkill.

So, I tried a few Live CD’s of various flavors of GNU/Linux. Then I ran across Android-X86. Oh? What’s this?

Android-X86 is a port to standard PC hard of Android. It’s very, very compatible with the Android you know and love on your phone and/or tablet. It even has an ARM emulation layer for running apps built on native code.

Installing Android-x86 should be easy. The ISO has a Live CD as well as an installation profile. Running the Live CD is pointless, you cannot persist any of your settings. Installing to a HD is your only real choice. And this is where it falls on its face.

When you install it using the wizard, you try to configure the machine with all the standard (and recommended) configuration options:

  1. Blow away any existing partitions with the installer’s partition manager.
  2. Create a 100MiB partition for the boot stuff.
  3. Create a partition for everything else using the remaining space.
  4. Tell the installer to use the big partition you just made.
  5. Let the installer load GRUB onto the machine.
  6. Let the installer complete storing files.

Voila!  Right????


First, GRUB never gets set up correctly.  When you reboot the bios finds the GRUB system on the partition table and tries to load it.  Nothing. Ever. Happens.

So, I boot up using GPARTED live CD.  Tell it to find other operating systems.  Nothing.  Edit an existing entry and point it at Android-x86.  Nothing.

I did a LOT of digging in Google and Bing.  Nothing worked.  So I decided to scrap android and go with Kubuntu.  This made my heart hurt.

I installed Kubuntu and after noticing that GRUB installed fine, I decided to search the web and see if I could reuse the same GRUB to launch Android-x86.

Aha!  I found explicit instructions for downloading Android-X86 from an RPM onto Ubuntu.  I got excited!  I followed the instructions and soon Android was on the system.

I reboot, select Android-x86 from GRUB.  It boots!  I’m giddy.  Then, nothing.  I just sits there trying to find the OS.  Turns out Kubuntu mounts to a virtual file system on a big partition on the HD.  Android-X86, expecting a real partition, simply cannot read it.  Never fear!  Partition Management is Here!

I resize the virtual partition, which allowed me to resize the real partition.  I set up a new partition for Android.  I copy over the Android-x86 folder from the RPM install.  I reboot.

It worked!  Hallelujah!

Moral of the Story?  Most GNU/Linux distributions (even Android) simply suck at installation.  Always have.  Will they always?  Ubuntu is one of the few that get it right.  Fortunately Kubuntu saved the day for me and gave me the tools to install Android-x86.  But, you need perseverance, patience and a little luck.

Infrastructure is hard.

When you’re developing a new app, it is often daunting to decide how you’re going to structure the app.

The MVC design pattern is a well tested, and time-honored, architecture for applications of all types.

In the last few years the pattern has gained recognition through Microsoft’s ASP.NET. this is not the only technique for creating an MVC application. The MVC pattern can be implemented in any object-oriented programming language.

Today I bring you SimpleMVC. SimpleMVC is a new package for C sharp developers that provides an API they can use to create great MVC based applications. SimpleMVC uses an asynchronous programming model to allow for usage in any kind of application such as WPF, ASP.Net WinForms and even Unity or Xamarin.

MVC is not a flavor of the month. Unlike MVVM, it is capable of creating applications that are cross-platform as well as cross UI technology. Models, View definitions, and Controllers are each encapsulated so that they can be reused across different applications that need the same business logic.

SimpleMVC uses an Adapter pattern to allow models to be transported across not only platforms but data access types. Because of this you could use MS Sql Server, Oracle, or even simple mock Frameworks to provide data to your application all without changing a single line of code in the controller the model or the View.  To accomplish this I also created SimpleDI or Simple Dependency Injection.

SimpleDI allows you to create object definitions in any way you decide to define the dependency.  For example you may use the built-in JSON formatted dependency definition or you may create a hard-coded dependency definition.

All of this is about flexibility.


The combination of SimpleDI an SimpleMVC allow you to create cross-platform, cross-application, and cross-technology implementations of applications that will grow with you as you need them to grow.


So lately at work I’ve been doing a lot of scripting. My supervisor has challenged me with automating everything we do with deployment of our applications and our AWS environment.

So, I’ve been using PowerShell….alot.

Some of the things I’ve done with PS:

1) Create a script to generate a new AWS Elastic Load Balancer
2) Create a script to generate a new AWS EC2 Instance and install SQL Server 2014 on it.
3) Create a script to build our source code with msbuild and octopack and then upload the resulting nupkg to our Nexus repository.
4) Download and install Chocolatey and have it automatically install one of our apps.

These things are all extremely useful! More scripts will be generated, especially as we move to AWS Cloud 2.0!

I’ve been working very hard on WorldBankBBS lately.  I’ve added a lot of features, and a lot more are coming soon.

Right now, you can use these features:

  1. Subboards with full screen editor
  2. IRC Gateway
  3. BBS Gateway
  4. Question & Answer FAQ System
  5. Full system search engine

To connection, simply navigate to and select the terminal emulation you prefer!

I’ve spent the last few weeks laid up with knee surgery.  In that time I’ve revisited some hobby stuff including WorldBankBBS.  Testing with Synchterm normally goes well, but when testing at 2400 baud it’s not entirely accurate.

The solution is to use WinVICE (the Versatile Commodore Emulator) to actually emulate a Commodore 64 connecting to the BBS.  To make that work, you need another program called TCPSER.  This program is a GNU/Linux native app and requires Cygwin to run on Windows.  There is a Java port called TCPSER4J, and it works fine, but you get all of the problems of having Java installed on your system.

One of the things that is a big bonus of porting TCPSER4J to C# is that it allows the application to be run as a Windows Service which ensures you always have it running.

You can check out the code at and you can check out the project at where you can download the installer.


An extension method that will be making its way into the Generic Extension Methods library is one I want to share tonight.  It’s for projecting an action N times.  Why such a method doesn’t already exist baffles me!

        public static T Project<T>(this T projected, int n, Action<T> action)


            for (int i = 0; i < n; ++i) action(projected);

            return projected;


Usage could not be simpler, any object can be projected to the specified action any number of times.

        public static int Method()


            var value = 1;

            return value.Project(10, i => i*=i);



The projection in this case yields 10^10 as the answer.  Overly simplistic example, but makes the point succinctly.

I have been working on a very interesting project lately for work. It’s a set of plugins for IE and Chrome to capture visited URLs and report them to a central server so that a remote service can be paused while the user is visiting a page in a blacklist.

To accomplish this, there is a browser helper object written Visual C++. BHO component should not be written in .net code despite the examples on the web. This is because the browser liberally shuts down COM containers which can leave the CLR in an unstable state. Trust me on this one, just bite the bullet and write your BHOs in C++.

For Chrome, things are even more convoluted. You must create a plugin in JavaScript. The manifest must declare both a background page/js and an event js file. The event js has access to the DOM, so any manipulation must be done there. The event then uses internal messaging to talk to the background js. Finally, the background js uses native messaging to talk to a command line app written in C# that accepts communications via standard in. The C# app then calls a WCF service that aggregates all of the data collected by the IE and Chrome plugins.

Did I mention that the BHO hosts its own CLR to communicate with the WCF service, too?

The WCF service is hosted in a Windows Service which also contains a cache that the WCF service populates. Once a page transaction is comple, the cache attempts to send the page data to a webapi on a central server.