“Is a URL a URI?”
“Is a URI a URL?”
“What does URL stand for?”
“What does URI stand for?”
“What does URL mean?”

I’ve been asked so many times I’ve lost count and for the sake of my sanity, I’ve decided to explain their distinquishing marks.

URL  – Uniform Resource Locator
URI – Uniform Resource Identifier

Sometimes these achronyms are used interchangably which is almost entirely wrong. Basically a URL is a specific type of URI because it uses specific protocols like http:  ftp: and mailto: URI defines a larger, more generalized superset.

Effectively, URL is no longer a valid in technical conversations or documents and you should use URI regardless of how big a pedant you are. A URI describes both the way you access something and it’s designated location.

You may see some explainations where U is defined as Universal. This is wrong and the author is just confused.

So, let’s call the whole thing off.


Intrigue is curious thing, much as curiosity is intriguing. What drives it? Mostly just needing to know something for no other reason than wanting to know itself – curious indeed. 

So why would I really be bothered to know what WindowsFormsSyncronizationContext does under the hood? Well dear bleader (if someone who write blogs is a blogger, maybe someone who reads blogs is a bleader) I had my suspicions, but I just needed to find out.

SynchronizationContext and it’s derivatives was introduced in .NET 2.0 as simple .NET language construct to allow a non-GUI thread to call methods on a GUI control. Previously, code had to be written to perform the InvokeRequired, BeginInvoke, Invoke dance and as has been discovered, this has problems and  can have you chasing nasty bugs.

In https://davebrooks.wordpress.com/2007/02/12/begininvoke-the-land-of-confusion/ I discussed BeginInvoke for delegates and controls, some issues and how they worked under the hood.

As I said before, I was suspicious that WindowsFormsSynchronizationContext worked pretty much the same way. And Lo, with a bit of windows message spying on a simple test app, my suspicions were confirmed. WindowsFormsSynchronizationContext.Post() and .Send() end up using PostMessage with registered windows messages, presumably using BeginInvoke and Invoke respectively to push the control method call onto the main GUI thread.  However, it does make the code earlier to write and as we all know, less code means less bugs.

Now to find out what happens in the Freemasons. I’m just curious you understand.