From around 1995 until 2010 there was really only one operating system for client
computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today:
3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now
most of these weren’t “client computing”, they were relatively dumb terminal technologies
that provided access to a server (back then called a mainframe or minicomputer). Very
much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows,
iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995
technologies went away, they are just mostly emulated in Windows. What is interesting
though, is that most of today’s client computing technologies do actually
enable smart client software development. This includes the browser which can be
used as a smart client technology via JavaScript development, even though the majority of
browser “apps” are actually just colorful versions of 1990-era terminal-based computing
where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened
the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for
other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with
SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools
fell by the wayside (not that they went away, they just stopped being mainstream).
This was because they couldn’t compete with Microsoft’s dev tools, which were always
in sync with the platform in a way that was probably too expensive for third parties
to match.

I think it is notable that our return to client computing chaos (or pluralism?) today
has already led to numerous third party dev tool vendors that sell dev tools for
other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious
that Windows would become a dominant platform, and I tended to argue against using
third party dev tools because I thought they’d have a rough go of it. As cool as Delphi
was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the
foreseeable future. It is hard to imagine Windows returning to its monopoly status,
but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate
desktop computing environment either.

As a result we business developers need some way to build software independently of
any particular platform or OS vendor, because we must assume all our business software
will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably
convinced that building smart client software (at least for business) means using
third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate
toward a combination of Xamarin and Microsoft
.NET as a way to use my C# and .NET knowledge across all platforms. I get to develop
in Visual Studio on Windows where I’m most comfortable, and my resulting software
runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as
a developer the question isn’t which platform to target, it is which third party dev
tool reaches all platforms with a solid strategy that will stand out and thrive over
the next many years.

Third Party Dev Tools Strike Backhttp://www.lhotka.net/weblog/PermaLink,guid,48ba54b3-eab6-493a-aa85-c064155d1d29.aspxhttp://www.lhotka.net/weblog/ThirdPartyDevToolsStrikeBack.aspx
Mon, 14 Jul 2014 19:00:31 GMT<p>
From around 1995 until 2010 there was really only one operating system for client
computing: Windows.
</p>
<p>
Prior to 1995 there were a lot of options, though most not recognizable to users today:
3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now
most of these weren’t “client computing”, they were relatively dumb terminal technologies
that provided access to a server (back then called a mainframe or minicomputer). Very
much like today’s web browser (sans JavaScript).
</p>
<p>
Today we’ve returned to a chaotic landscape of client computing: browsers, Windows,
iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995
technologies went away, they are just mostly emulated in Windows. What is interesting
though, is that most of <em>today’s</em> client computing technologies do actually
enable smart client software development. This includes the browser which <em>can</em> be
used as a smart client technology via JavaScript development, even though the <em>majority</em> of
browser “apps” are actually just colorful versions of 1990-era terminal-based computing
where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.
</p>
<p>
What is interesting about this return to client-side chaos is that it has reopened
the door for third party developer tools as a niche market.
</p>
<p>
In the early 1990’s there were quite a number of companies selling developer tools <em>for
other company’s platforms</em>. Borland with C++, Delphi and TurboPascal, Gupta with
SqlWindows, Powerbuilder, and a lot more.
</p>
<p>
When Windows became the dominant client computing platform most of these dev tools
fell by the wayside (not that they went away, they just stopped being mainstream).
This was because they couldn’t compete with Microsoft’s dev tools, which were always
in sync with the platform in a way that was probably too expensive for third parties
to match.
</p>
<p>
I think it is notable that our return to client computing chaos (or pluralism?) today
has already led to numerous third party dev tool vendors that sell dev tools <em>for
other company’s platforms.</em> Xamarin, PhoneGap, Telerik’s tools, and a lot more.
</p>
<p>
What is different to me is that in the early 1990’s I thought it was pretty obvious
that Windows would become a dominant platform, and I tended to argue against using
third party dev tools because I thought they’d have a rough go of it. As cool as Delphi
was, I always recommended VB.
</p>
<p>
Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the
foreseeable future. It is hard to imagine Windows returning to its monopoly status,
but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate
desktop computing environment either.
</p>
<p>
As a result we business developers need some way to build software independently of
any particular platform or OS vendor, because we must assume all our business software
will need to run on multiple platforms and OSes.
</p>
<p>
So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably
convinced that building smart client software (at least for business) means using
third party dev tools from vendors that aren’t tied to any one platform.
</p>
<p>
Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate
toward a combination of <a href="http://www.xamarin.com">Xamarin</a> and Microsoft
.NET as a way to use my C# and .NET knowledge across all platforms. I get to develop
in Visual Studio on Windows where I’m most comfortable, and my resulting software
runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.
</p>
<p>
As far into the future as I can see there’s no obvious platform/OS “winner”, so as
a developer the question isn’t which platform to target, it is which third party dev
tool reaches all platforms with a solid strategy that will stand out and thrive over
the next many years.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=48ba54b3-eab6-493a-aa85-c064155d1d29" />AndroidiOSWindows PhoneWinRTXamarinhttp://www.lhotka.net/weblog/Trackback.aspx?guid=ecfe3675-2157-4e28-9ffd-cedc149c7cc3http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,ecfe3675-2157-4e28-9ffd-cedc149c7cc3.aspxRockford Lhotka

There’s been a lot of exciting change in cross-platform development for C# developers
over the past few months. Microsoft introduced the Universal
Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows
Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called
a Shared Project. With the Shared
Project Reference Manager add-in for VS13 you can reference these shared projects
from any project, not just Universal App projects.

As a result, you can build a solution like this one:

This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based
on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI
code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically
no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project.
In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own
thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough
in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services.
All that code is in the NonUICode.Shared project so it can be maintained just one
time. The service calls use HttpClient, which is reasonably common across all the
UI platforms, and for the few differences I’m using #if statements to accommodate
the per-platform code. For example, here’s a bit of code from a shared viewmodel class:

The overall result is that with reasonable effort you can create an app that spans
every type of smart client technology available today; from Windows Forms up to iOS.
These apps can share all your business and service client code, and can often share
a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it
is a lot easier to create and maintain the shared business and service client
code than if you try to build that code by hand)

Sharing Code from WinForms to iOShttp://www.lhotka.net/weblog/PermaLink,guid,ecfe3675-2157-4e28-9ffd-cedc149c7cc3.aspxhttp://www.lhotka.net/weblog/SharingCodeFromWinFormsToIOS.aspx
Tue, 01 Jul 2014 21:32:53 GMT<p>
There’s been a lot of exciting change in cross-platform development for C# developers
over the past few months. Microsoft introduced the <a href="http://msdn.microsoft.com/en-us/library/windows/apps/dn609832.aspx">Universal
Apps</a> concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced <a href="http://xamarin.com/forms">Xamarin.Forms</a> (Windows
Phone 8, Android, and iOS).
</p>
<p>
Beneath the Universal App support in Visual Studio 2013 is a broader concept called
a Shared Project. With the <a href="http://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450">Shared
Project Reference Manager</a> add-in for VS13 you can reference these shared projects
from any project, not just Universal App projects.
</p>
<p>
As a result, you can build a solution like this one:
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/SharingCodefromWinFormstoiOS_E8B4/SharedCodeSolution_2.jpg"><img title="SharedCodeSolution" style="border-left-width: 0px; border-right-width: 0px; border-bottom-width: 0px; display: inline; border-top-width: 0px" border="0" alt="SharedCodeSolution" src="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/SharingCodefromWinFormstoiOS_E8B4/SharedCodeSolution_thumb.jpg" width="244" height="185" /></a>
</p>
<p>
This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based
on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI
code from the NonUICode.Shared project.
</p>
<p>
In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically
no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project.
In the WinRTApp all the UI code is in the HubApp1.Shared project.
</p>
<p>
The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own
thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough
in common with WinRT or Xamarin.Forms for sharing.
</p>
<p>
<em>None</em> of the UI projects contain any business logic or logic to call services.
All that code is in the NonUICode.Shared project so it can be maintained just one
time. The service calls use HttpClient, which is reasonably common across all the
UI platforms, and for the few differences I’m using #if statements to accommodate
the per-platform code. For example, here’s a bit of code from a shared viewmodel class:&#160;
</p>
<pre style="font-size: 13px; font-family: consolas; background: white; color: black">&#160;&#160;&#160; <span style="color: blue">public</span>&#160;<span style="color: blue">async</span>&#160;<span style="color: #2b91af">Task</span> SaveData()<br />
&#160;&#160;&#160; {<br />
&#160;&#160;&#160;&#160;&#160; <span style="color: blue">if</span> (<span style="color: blue">this</span>.IsDataLoaded)<br />
&#160;&#160;&#160;&#160;&#160; {<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">var</span> webClient
= <span style="color: blue">new</span>&#160;<span style="color: #2b91af">HttpClient</span>();<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">var</span> data
= <span style="color: #2b91af">JsonConvert</span>.SerializeObject(<span style="color: blue">this</span>.Speaker);<br />
<span style="color: blue">#if</span> ANDROID || __ANDROID__ || __IOS__<br />
<span style="color: gray">&#160;&#160;&#160;&#160;&#160;&#160;&#160; var content =
new StringContent(data, System.Text.Encoding.UTF8, &quot;application/json&quot;);</span>
<br />
<span style="color: blue">#else</span>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">var</span> content
= <span style="color: blue">new</span>&#160;<span style="color: #2b91af">HttpStringContent</span>(data);<br />
<span style="color: blue">#endif</span>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">var</span> urlString
= apiSpeakerUrl + <span style="color: #a31515">@&quot;/&quot;</span> + <span style="color: blue">this</span>.Speaker.Id.ToString();<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">var</span> response
= <span style="color: blue">await</span> webClient.PutAsync(<span style="color: blue">new</span>&#160;<span style="color: #2b91af">Uri</span>(urlString),
content);<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">if</span> (!response.IsSuccessStatusCode)<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <span style="color: blue">throw</span>&#160;<span style="color: blue">new</span>&#160;<span style="color: #2b91af">Exception</span>(<span style="color: #a31515">&quot;SaveData
failed&quot;</span>);<br />
&#160;&#160;&#160;&#160;&#160; }<br />
&#160;&#160;&#160; }<br />
</pre>
<p>
The overall result is that with reasonable effort you can create an app that spans
every type of smart client technology available today; from Windows Forms up to iOS.
These apps can share all your business and service client code, and can often share
a lot of UI code.
</p>
<p>
(fwiw, if you build your business logic with <a href="http://cslanet.com">CSLA .NET</a> it
is a <em>lot</em> easier to create and maintain the shared business and service client
code than if you try to build that code by hand)
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=ecfe3675-2157-4e28-9ffd-cedc149c7cc3" />CSLA .NETWinRTWP8Xamarinhttp://www.lhotka.net/weblog/Trackback.aspx?guid=f2d52dc1-35f5-4aea-a372-49c3e80e3131http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,f2d52dc1-35f5-4aea-a372-49c3e80e3131.aspxRockford Lhotka

This
release adds the following key features:

Support for iOS

Support for WinRT on Windows Phone 8.1

Support for Universal Apps that target WinRT on Windows 8.1 and Windows Phone 8.1

A new HttpProxy/Host data portal channel that doesn't rely on WCF

A new BrokeredProxy/Host data portal channel that allows a WinRT (Win8) app to call
a local data portal running in full .NET

You can download the msi installer from the release
page, or better yet add references to the framework via
NuGet.

Version 4.5.600 includes support for iOS (via Xamarin) and for WinRT on Windows Phone
8.1 in the WinRT.Phone project. This also means you can use the new Universal solution/project
type to build WinRT apps for Windows 8.1 and Windows Phone 8.1.

This prerelease also includes the new HttpProxy/Host and BrokeredProxy/Host data portal
channels.

The Http data portal channel allows you to host the data portal server directly in
ASP.NET MVC 4 or MVC 5 without the need for WCF. It relies only on the HttpClient
library to invoke the server, so the client has no dependency on WCF - important for
the new Windows Phone 8.1 programming model where WCF doesn't exist.

The Brokered data portal channel allows you to host the data portal server in .NET
as a brokered assembly, thus available to a WinRT client app. This means you can build
a WinRT app that makes data portal calls, where the "server-side" code is
also running on the client device, but has access to full .NET. This will only work
on Intel-based devices where full .NET assemblies can be deployed. It will only work
with side-loaded apps, not apps from the Windows Store.

CSLA 4 version 4.5.600 release with iOS supporthttp://www.lhotka.net/weblog/PermaLink,guid,f2d52dc1-35f5-4aea-a372-49c3e80e3131.aspxhttp://www.lhotka.net/weblog/CSLA4Version45600ReleaseWithIOSSupport.aspx
Wed, 18 Jun 2014 20:34:52 GMT<p>
<a href="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/CSLA4version4.5.600releasewithiOSsupport_DB1C/csla%20win8_full_2.png"><img title="csla win8_full" style="border-top: 0px; border-right: 0px; border-bottom: 0px; margin-left: 0px; border-left: 0px; display: inline; margin-right: 0px" border="0" alt="csla win8_full" src="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/CSLA4version4.5.600releasewithiOSsupport_DB1C/csla%20win8_full_thumb.png" width="240" align="right" height="160" /></a> This
release adds the following key features:
</p>
<ol>
<li>
Support for iOS
</li>
<li>
Support for WinRT on Windows Phone 8.1
</li>
<li>
Support for Universal Apps that target WinRT on Windows 8.1 and Windows Phone 8.1
</li>
<li>
A new HttpProxy/Host data portal channel that doesn't rely on WCF
</li>
<li>
A new BrokeredProxy/Host data portal channel that allows a WinRT (Win8) app to call
a local data portal running in full .NET
</li>
</ol>
<p>
Here is the <a href="https://github.com/MarimerLLC/csla/issues?milestone=8&amp;page=1&amp;state=closed">version
4.5.600 change log</a>.
</p>
<p>
You can download the msi installer from the <a href="https://github.com/MarimerLLC/csla/releases/tag/v4.5.600">release
page</a>, or better yet add references to the framework <a href="http://www.nuget.org/packages?q=csla">via
NuGet</a>.
</p>
<p>
Version 4.5.600 includes support for iOS (via Xamarin) and for WinRT on Windows Phone
8.1 in the WinRT.Phone project. This also means you can use the new Universal solution/project
type to build WinRT apps for Windows 8.1 and Windows Phone 8.1.
</p>
<p>
This prerelease also includes the new HttpProxy/Host and BrokeredProxy/Host data portal
channels.
</p>
<p>
The Http data portal channel allows you to host the data portal server directly in
ASP.NET MVC 4 or MVC 5 without the need for WCF. It relies only on the HttpClient
library to invoke the server, so the client has no dependency on WCF - important for
the new Windows Phone 8.1 programming model where WCF doesn't exist.
</p>
<p>
The Brokered data portal channel allows you to host the data portal server in .NET
as a brokered assembly, thus available to a WinRT client app. This means you can build
a WinRT app that makes data portal calls, where the &quot;server-side&quot; code is
also running on the client device, but has access to full .NET. This will only work
on Intel-based devices where full .NET assemblies can be deployed. It will only work
with side-loaded apps, not apps from the Windows Store.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=f2d52dc1-35f5-4aea-a372-49c3e80e3131" />CSLA .NETWinRTWP8Xamarinhttp://www.lhotka.net/weblog/Trackback.aspx?guid=39fa911a-c3c2-473f-9050-055bec37fa7ahttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,39fa911a-c3c2-473f-9050-055bec37fa7a.aspxRockford Lhotka

As well all know, portable class libraries are pretty cool, but are restricted by
the “lowest common denominator” effect.

For example, CSLA .NET supports the use of DataAnnotations along with the richer CSLA
rules engine.

In trying to create one of the new “Universal PCL” assemblies to support WinRT on
Win8 and WP8 I ran into the fact that WP8 doesn’t support DataAnnotations.

“No problem” I thought, “we already have our own implementation for WP8 Silverlight,
for Android, and for iOS. I’ll just use that code.”

Which worked insofar as that I have a Universal PCL Csla.dll that builds.

But it doesn’t work because I can’t actually use that Csla.dll from WinRT on Win8
because that WinRT already has DataAnnotations and so there are type collisions.

As a result it isn’t clear to me that I can actually create a Universal PCL for CSLA
– at least not one that supports DataAnnotations across all platforms like I’m able
to do if I create one assembly per target platform (like I’ve been doing since 2007
with Silverlight 2).

I guess this makes sense. The guidance around creating a PCL is that you have code
that is simple enough that it doesn’t include any platform-specific implementations
that would be solved easily using #if directives. The internal implementation of some
parts of CSLA is far from simple, and we do use #if directives to optimize for and/or
leverage features of each of the 9 platforms currently supported by CSLA (yes, we
really provide business code portability across NINE different platforms).

My personal feeling is that I’d rather support all 9 platforms as efficiently as possible,
rather than compromise one or more of them just to use a fancy and optional new concept
like the Universal PCL.

(of course if Microsoft and Xamarin add DataAnnotations to Windows Phone 8.1, Android,
and iOS then I wouldn’t need to implement it in CSLA and that would also solve this
problem – so maybe someday :) )

Limitations of Portable Class Librarieshttp://www.lhotka.net/weblog/PermaLink,guid,39fa911a-c3c2-473f-9050-055bec37fa7a.aspxhttp://www.lhotka.net/weblog/LimitationsOfPortableClassLibraries.aspx
Mon, 28 Apr 2014 20:07:47 GMT<p>
As well all know, portable class libraries are pretty cool, but are restricted by
the “lowest common denominator” effect.
</p>
<p>
For example, CSLA .NET supports the use of DataAnnotations along with the richer CSLA
rules engine.
</p>
<p>
In trying to create one of the new “Universal PCL” assemblies to support WinRT on
Win8 and WP8 I ran into the fact that WP8 doesn’t support DataAnnotations.
</p>
<p>
“No problem” I thought, “we already have our own implementation for WP8 Silverlight,
for Android, and for iOS. I’ll just use that code.”
</p>
<p>
Which worked insofar as that I have a Universal PCL Csla.dll that builds.
</p>
<p>
But it doesn’t work because I can’t actually use that Csla.dll from WinRT on Win8
because <em>that</em> WinRT already has DataAnnotations and so there are type collisions.
</p>
<p>
As a result it isn’t clear to me that I can actually create a Universal PCL for CSLA
– at least not one that supports DataAnnotations across all platforms like I’m able
to do if I create one assembly per target platform (like I’ve been doing since 2007
with Silverlight 2).
</p>
<p>
I guess this makes sense. The guidance around creating a PCL is that you have code
that is simple enough that it doesn’t include any platform-specific implementations
that would be solved easily using #if directives. The internal implementation of some
parts of CSLA is far from simple, and we do use #if directives to optimize for and/or
leverage features of each of the 9 platforms currently supported by CSLA (yes, we
really provide business code portability across NINE different platforms).
</p>
<p>
My personal feeling is that I’d rather support all 9 platforms as efficiently as possible,
rather than compromise one or more of them just to use a fancy and optional new concept
like the Universal PCL.
</p>
<p>
(of course if Microsoft and Xamarin add DataAnnotations to Windows Phone 8.1, Android,
and iOS then I wouldn’t need to implement it in CSLA and that would also solve this
problem – so maybe someday :) )
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=39fa911a-c3c2-473f-9050-055bec37fa7a" />CSLA .NETWindows PhoneWinRTXamarinhttp://www.lhotka.net/weblog/Trackback.aspx?guid=bbcfb607-1861-4686-a485-a59e34e0dfechttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,bbcfb607-1861-4686-a485-a59e34e0dfec.aspxRockford Lhotka

That might be ok, though I’ve long since adapted to the start screen so I’m not sure
I care at all.

What I do care about are much more real challenges when working in the ‘modern’
or WinRT (Windows Runtime or Windows Store) side of the operating system.

My top list:

The file save/open dialogs don’t sort or filter items and so are almost useless if
you have a lot of files

The file save/open dialogs (and OneNote app) often don’t show the full filename or
properties of files, making similar files hard to distinguish – again making these
core aspects of the OS extremely challenging if not useless

The OneDrive app doesn’t let me access folders shared to me by other people – a feature
I use constantly, and so spend more time in the web UI than the app

Unpredictability and lack of control about how WinRT apps display side-by-side is
a continual thorn in my side – I launch an app in one monitor and it messes up the
display in another monitor? Seriously?!?!

The Calendar app is lame at best. It has some good features, but wastes amazing amounts
of space and lacks simple bits of functionality like copying an item or moving an
item from one calendar to another. Hopefully it turns into something more like the
Windows Phone 8.1 calendar

There’s no way to schedule Lync meetings using the Lync app – how lame is that???

I’ve tried nearly all the file manager apps out there, and some are not bad, but what
I _don’t_ understand is why the OneDrive app (which already does OneDrive and local
PC stuff) doesn’t just handle things like removable and network drives so it would
literally be the “one drive” app

I want a notification summary screen like we now have in Windows Phone 8.1 - _that_
is a useful feature!

I guess what I’m getting at is that I understand that Microsoft feels like they need
to add back the Start menu to lure stubborn people into using Win8. BUT what I’m afraid
will happen is that they’ll lure people into the WinRT world only to have those people
suffer the same day-to-day frustrations I already suffer because these core fit-and-finish
capabilities aren’t implemented or complete.

Personally I think it would be better to make the WinRT platform so nice and compelling
and fun to use that people will _choose_ to use it over the legacy Desktop with or
without cosmetic stuff like a Start menu.

Return of the Start menu is low priority to mehttp://www.lhotka.net/weblog/PermaLink,guid,bbcfb607-1861-4686-a485-a59e34e0dfec.aspxhttp://www.lhotka.net/weblog/ReturnOfTheStartMenuIsLowPriorityToMe.aspx
Thu, 24 Apr 2014 15:58:09 GMT<p>
Ho hum. Microsoft is going to <a href="http://techcrunch.com/2014/04/23/the-start-menu-may-return-to-windows-in-august/?ncid=rss">bring
back the start menu in Windows 8</a> – presumably in August.<a href="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/ReturnoftheStartmenuislowprioritytome_9A3A/Windows-8-logo_2.jpg"><img title="Windows-8-logo" style="border-top: 0px; border-right: 0px; border-bottom: 0px; margin-left: 0px; border-left: 0px; display: inline; margin-right: 0px" border="0" alt="Windows-8-logo" src="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/ReturnoftheStartmenuislowprioritytome_9A3A/Windows-8-logo_thumb.jpg" width="128" align="right" height="91" /></a>
</p>
<p>
That might be ok, though I’ve long since adapted to the start screen so I’m not sure
I care at all.
</p>
<p>
What I <em>do</em> care about are much more real challenges when working in the ‘modern’
or WinRT (Windows Runtime or Windows Store) side of the operating system.
</p>
<p>
My top list:
</p>
<ol>
<li>
The file save/open dialogs don’t sort or filter items and so are almost useless if
you have a lot of files</li>
<li>
The file save/open dialogs (and OneNote app) often don’t show the full filename or
properties of files, making similar files hard to distinguish – again making these
core aspects of the OS extremely challenging if not useless</li>
<li>
The OneDrive app doesn’t let me access folders shared to me by other people – a feature
I use constantly, and so spend more time in the web UI than the app</li>
<li>
Unpredictability and lack of control about how WinRT apps display side-by-side is
a continual thorn in my side – I launch an app in one monitor and it messes up the
display in another monitor? Seriously?!?!</li>
<li>
The Calendar app is lame at best. It has some good features, but wastes amazing amounts
of space and lacks simple bits of functionality like copying an item or moving an
item from one calendar to another. Hopefully it turns into something more like the
Windows Phone 8.1 calendar</li>
<li>
There’s no way to schedule Lync meetings using the Lync app – how lame is that???</li>
<li>
I’ve tried nearly all the file manager apps out there, and some are not bad, but what
I _don’t_ understand is why the OneDrive app (which already does OneDrive and local
PC stuff) doesn’t just handle things like removable and network drives so it would
literally be the “one drive” app</li>
<li>
I want a notification summary screen like we now have in Windows Phone 8.1 - _that_
is a useful feature!</li>
</ol>
<p>
I guess what I’m getting at is that I understand that Microsoft feels like they need
to add back the Start menu to lure stubborn people into using Win8. BUT what I’m afraid
will happen is that they’ll lure people into the WinRT world only to have those people
suffer the same day-to-day frustrations I already suffer because these core fit-and-finish
capabilities aren’t implemented or complete.
</p>
<p>
Personally I think it would be better to make the WinRT platform so nice and compelling
and fun to use that people will _choose_ to use it over the legacy Desktop with or
without cosmetic stuff like a Start menu.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=bbcfb607-1861-4686-a485-a59e34e0dfec" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=3a6efc45-380d-4b21-aa4c-09f536cd9aedhttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,3a6efc45-380d-4b21-aa4c-09f536cd9aed.aspxRockford Lhotka

Microsoft has substantially improved the story around side loading of Windows 8 WinRT
(Windows Runtime or Windows Store) apps for the enterprise and business environments.

Microsoft has now radically changed the cost of step 1. This
blog post from Microsoft contains the following statement:

Enterprise Sideloading– In May, we will grant Enterprise Sideloading rights
to organizations in certain Volume License programs, regardless of what product they
purchase, at no additional cost. Other customers who want to deploy custom line-of-business
Windows 8.1 apps can purchase Enterprise Sideloading rights for an unlimited number
of devices through Volume Licensing at approximately $100. For additional information
on sideloading licensing, review the Windows
Volume Licensing Guide.

Basically what this means is the following (as I understand it):

For developers/testers things are unchanged – you still use a free dev unlock key
to install apps for development and testing.

For organizations with an Enterprise Agreement (EA) you’ll be able to get a side loading
unlock key that you can use on all your Windows 8 Pro and Windows 8 Enterprise devices,
regardless of whether they are domain joined or not. As before, you can also get ‘companion
device’ keys to unlock Windows RT devices if you have a Windows 8 Enterprise device
too.

For smaller organizations that don’t have an EA you might have (or can get) one of
a number of ‘Open’ or ‘Select’ license agreements with Microsoft. Once you have one
of these you can buy a side loading key for around $100 that will unlock any number
of Windows 8 Pro or Windows 8 Enterprise devices.

When compared to the old model of buying keys for $30/device this is a major change
in the right direction. For a maximum of around $100 virtually every organization
(small to huge) can get a side loading unlock key for all their devices.

Now this still doesn’t address the need to actually install your apps onto your devices.

Microsoft offers InTune, which is a full MDM (mobile device management) product. If
you find the value proposition of an MDM compelling then InTune is probably the right
answer for you – though there’s a per device/per month cost (ranging from $6/device/month
to $11/device/month) so you don’t get MDM for free of course.

I’ve
been coordinating an open source project called OrgPortal that
you can use to (relatively) easily create an app store for your organization.

There’s another open source project called CompanyStore that
is very similar.

Alternately you can have your users manually run a PowerShell to install and update
each app manually over time.

I think Microsoft has taken a substantial step in the right direction with the changes
to the cost and availability of side loading keys. Couple this with the increasing
maturity of projects like OrgPortal and CompanyStore and I think we’re getting to
the point where WinRT is something to consider for business app development.

Windows 8 side loading improvementshttp://www.lhotka.net/weblog/PermaLink,guid,3a6efc45-380d-4b21-aa4c-09f536cd9aed.aspxhttp://www.lhotka.net/weblog/Windows8SideLoadingImprovements.aspx
Thu, 03 Apr 2014 06:43:38 GMT<p>
Microsoft has substantially improved the story around side loading of Windows 8 WinRT
(Windows Runtime or Windows Store) apps for the enterprise and business environments.
</p>
<p>
I’ve <a href="http://www.lhotka.net/weblog/Windows8WinRTLicensingIdeas.aspx">blogged
pretty extensively</a> in the past about the costs of the two steps necessary to side
load apps:
</p>
<ol>
<li>
Unlock your devices for side loading
</li>
<li>
Actually side load (install) your various business apps
</li>
</ol>
<p>
Microsoft has now radically changed the cost of step 1. <a href="http://blogs.windows.com/windows/b/business/archive/2014/04/02/building-the-mobile-workplace-with-windows-and-windows-phone.aspx">This
blog post</a> from Microsoft contains the following statement:
</p>
<blockquote>
<p>
<em><b>Enterprise Sideloading</b>– In May, we will grant Enterprise Sideloading rights
to organizations in certain Volume License programs, regardless of what product they
purchase, at no additional cost. Other customers who want to deploy custom line-of-business
Windows 8.1 apps can purchase Enterprise Sideloading rights for an unlimited number
of devices through Volume Licensing at approximately $100. For additional information
on sideloading licensing, review the </em><a href="http://download.microsoft.com/download/9/4/3/9439A928-A0D1-44C2-A099-26A59AE0543B/Windows_8-1_Licensing_Guide.pdf"><em>Windows
Volume Licensing Guide</em></a><em>.</em>
</p>
</blockquote>
<p>
Basically what this means is the following (as I understand it):
</p>
<p>
For developers/testers things are unchanged – you still use a free dev unlock key
to install apps for development and testing.
</p>
<p>
For organizations with an Enterprise Agreement (EA) you’ll be able to get a side loading
unlock key that you can use on all your Windows 8 Pro and Windows 8 Enterprise devices,
regardless of whether they are domain joined or not. As before, you can also get ‘companion
device’ keys to unlock Windows RT devices if you have a Windows 8 Enterprise device
too.
</p>
<p>
For smaller organizations that don’t have an EA you might have (or can get) one of
a number of ‘Open’ or ‘Select’ license agreements with Microsoft. Once you have one
of these you can buy a side loading key for around $100 that will unlock any number
of Windows 8 Pro or Windows 8 Enterprise devices.
</p>
<p>
When compared to the old model of buying keys for $30/device this is a major change
in the right direction. For a maximum of around $100 virtually every organization
(small to huge) can get a side loading unlock key for all their devices.
</p>
<p>
Now this still doesn’t address the need to actually install your apps onto your devices.
</p>
<p>
Microsoft offers InTune, which is a full MDM (mobile device management) product. If
you find the value proposition of an MDM compelling then InTune is probably the right
answer for you – though there’s a per device/per month cost (ranging from $6/device/month
to $11/device/month) so you don’t get MDM for free of course.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/Windows8sideloadingimprovements_14DA4/Screenshot%20(5)_2.png"><img title="Screenshot (5)" style="border-top: 0px; border-right: 0px; border-bottom: 0px; margin: 5px; border-left: 0px; display: inline" border="0" alt="Screenshot (5)" src="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/Windows8sideloadingimprovements_14DA4/Screenshot%20(5)_thumb.png" width="240" align="right" height="135" /></a>I’ve
been coordinating an open source project called <a href="http://github.com/magenic/orgportal">OrgPortal</a> that
you can use to (relatively) easily create an app store for your organization.
</p>
<p>
There’s another open source project called <a href="http://companystore.codeplex.com">CompanyStore</a> that
is very similar.
</p>
<p>
Alternately you can have your users manually run a PowerShell to install and update
each app manually over time.
</p>
<p>
I think Microsoft has taken a substantial step in the right direction with the changes
to the cost and availability of side loading keys. Couple this with the increasing
maturity of projects like OrgPortal and CompanyStore and I think we’re getting to
the point where WinRT is something to consider for business app development.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=3a6efc45-380d-4b21-aa4c-09f536cd9aed" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=a77535fb-0ec1-4810-a863-082a53847324http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,a77535fb-0ec1-4810-a863-082a53847324.aspxRockford Lhotka

In my last post my focus was on listing the
numerous WinRT apps I use on a regular basis – many of which, if I couldn’t get
them on Win8 would drive me to carry an iPad. I’m personally not just a software developer,
I’m a user of computing as well.

One line, a sensation-maker, in my post was that I think Windows developers who aren’t
using WinRT apps are doing their ultimate users a disservice. This doesn’t apply to
web developers or other people who aren’t developing actual Windows applications,
but it surely applies to people living today in the legacy WPF, SL, and Windows Forms
technologies.

The thing is, I made no effort to describe why I believe that to be true,
because the focus of that post was to list useful apps.

So what did I mean by that comment?

Here’s the thing. As someone who does use a lot of WinRT apps I can say that
a lot of them suck. I’ve divided the suckage into three categories.

Some apps are obviously built by pure mobile developers, who have
no comprehension of keyboard/mouse or productivity on anything but a tablet. So their
apps are sometimes pretty good on a tablet, but are virtually useless on a laptop
or desktop. Because I use all three types of device with pretty much every app, I
find that these mobile-only or mobile-first apps just suck. I might use them
on my tablet, but they are always pretty secondary to more complete apps because they
aren’t universal.

Other apps are obviously built by pure desktop developers, who have
no comprehension of touch. These apps often work pretty well with keyboard/mouse,
but are awkward to use with touch. Technically they work on my tablet, but
they aren’t fun or efficient, and so I consider them to suck.

The third group of sucky apps are built by people with no WinRT user experience.
These apps might, in theory, work pretty well with touch and/or keyboard and mouse,
but they miss the point of all the cool WinRT features. They don’t use AppBars or
the Share charm or Settings or Search correctly. They don’t use dialogs correctly,
they don’t use navigation correctly. I’m sure the authors of these apps often think
they are being clever by inventing their own techniques, but as a user their
apps just suck because they don’t work right.

In short, sucky apps come from three sources:

Mobile developers who don’t consider laptop/desktop device scenarios

Desktop developers who don’t consider tablet scenarios

Developers who are ignorant about the WinRT environment and don’t understand how it
works

So as a developer, if you plan to ever build WinRT apps and you aren’t using WinRT
then you are pretty much guaranteed to fall into category 3, and very possibly 1 and/or
2.

Hence, if you are a smart client developer – unless you are planning to retire on
WPF (which is fine) or switch to the iPad/Android world, you are doing yourself and
your users a disservice if you aren’t actually using and learning “the WinRT way”.

Update:

Jason Bock mentioned something to me that got me thinking. I base all of this on one
core assumption:

Win32 has no long-term future as a mainstream technology.

To be clear, I am 100% sure Win32 will be around for the next 20-30 years, just like
mainframes and minicomputers are still with us – usually hidden behind the scenes
or in a terminal window, but still here. I don’t think anyone would call them “mainstream”
though. Nobody ever mentions IBM in the same breath as Microsoft/Apple/Google/Samsung.

Now if you think Microsoft will back off from WinRT, and by some miracle Apple and
Google and Samsung will just completely fail to adapt iOS, Android, or ChromeOS to
the enterprise, then you can imagine yourself still doing Win32 as a mainstream technology
in 5-7 years.

I personally can’t imagine that happening. I think 5 years from now Win32 will be
pretty much what we think of as VB6 today. Something that runs a ton of software,
and something that people still do, but not something that would be considered mainstream
or vibrant.

For my part, I think that if Microsoft does back off WinRT to try and rejuvenate
Win32 … well … that’ll be the opening one or more competitors needs to swoop in and
take the enterprise desktop.

Defining disservicehttp://www.lhotka.net/weblog/PermaLink,guid,a77535fb-0ec1-4810-a863-082a53847324.aspxhttp://www.lhotka.net/weblog/DefiningDisservice.aspx
Mon, 03 Mar 2014 04:55:12 GMT<p>
In my last post my focus was on listing <a href="http://www.lhotka.net/weblog/TopWin8WinRTApps.aspx">the
numerous WinRT apps I use</a> on a regular basis – many of which, if I couldn’t get
them on Win8 would drive me to carry an iPad. I’m personally not just a software developer,
I’m a <em>user</em> of computing as well.
</p>
<p>
One line, a sensation-maker, in my post was that I think Windows developers who aren’t
using WinRT apps are doing their ultimate users a disservice. This doesn’t apply to
web developers or other people who aren’t developing actual Windows applications,
but it surely applies to people living today in the legacy WPF, SL, and Windows Forms
technologies.
</p>
<p>
The thing is, I made no effort to describe <em>why</em> I believe that to be true,
because the focus of that post was to list useful apps.
</p>
<p>
So what <em>did </em>I mean by that comment?
</p>
<p>
Here’s the thing. As someone who <em>does</em> use a lot of WinRT apps I can say that
a lot of them suck. I’ve divided the suckage into three categories.
</p>
<p>
Some apps are obviously <strong>built by pure mobile developers</strong>, who have
no comprehension of keyboard/mouse or productivity on anything but a tablet. So their
apps are sometimes pretty good on a tablet, but are virtually useless on a laptop
or desktop. Because I use all three types of device with pretty much every app, I
find that these mobile-only or mobile-first apps just suck. I <em>might</em> use them
on my tablet, but they are always pretty secondary to more complete apps because they
aren’t universal.
</p>
<p>
Other apps are obviously built by <strong>pure desktop developers</strong>, who have
no comprehension of touch. These apps often work pretty well with keyboard/mouse,
but are awkward to use with touch. Technically they <em>work</em> on my tablet, but
they aren’t fun or efficient, and so I consider them to suck.
</p>
<p>
The third group of sucky apps are built by <strong>people with no WinRT user experience</strong>.
These apps might, in theory, work pretty well with touch and/or keyboard and mouse,
but they miss the point of all the cool WinRT features. They don’t use AppBars or
the Share charm or Settings or Search correctly. They don’t use dialogs correctly,
they don’t use navigation correctly. I’m sure the authors of these apps often think
they are being clever by inventing their own techniques, but as a <em>user</em> their
apps just suck because they don’t work right.
</p>
<p>
In short, sucky apps come from three sources:
</p>
<ol>
<li>
Mobile developers who don’t consider laptop/desktop device scenarios
</li>
<li>
Desktop developers who don’t consider tablet scenarios
</li>
<li>
Developers who are ignorant about the WinRT environment and don’t understand how it
works
</li>
</ol>
<p>
So as a developer, if you plan to ever build WinRT apps and you aren’t using WinRT
then you are pretty much guaranteed to fall into category 3, and very possibly 1 and/or
2.
</p>
<p>
Hence, if you are a smart client developer – unless you are planning to retire on
WPF (which is fine) or switch to the iPad/Android world, you are doing yourself and
your users a disservice if you aren’t actually using and learning “the WinRT way”.
</p>
<p>
<strong>Update:</strong>
</p>
<p>
Jason Bock mentioned something to me that got me thinking. I base all of this on one
core assumption:
</p>
<blockquote>
<p>
<em>Win32 has no long-term future as a mainstream technology.</em>
</p>
</blockquote>
<p>
To be clear, I am 100% sure Win32 will be around for the next 20-30 years, just like
mainframes and minicomputers are still with us – usually hidden behind the scenes
or in a terminal window, but still here. I don’t think anyone would call them “mainstream”
though. Nobody ever mentions IBM in the same breath as Microsoft/Apple/Google/Samsung.
</p>
<p>
Now if you think Microsoft will back off from WinRT, and by some miracle Apple and
Google and Samsung will just completely fail to adapt iOS, Android, or ChromeOS to
the enterprise, then you can imagine yourself still doing Win32 as a mainstream technology
in 5-7 years.
</p>
<p>
I personally can’t imagine that happening. I think 5 years from now Win32 will be
pretty much what we think of as VB6 today. Something that runs a ton of software,
and something that people still do, but not something that would be considered mainstream
or vibrant.
</p>
<p>
For my part, I think that if Microsoft <em>does</em> back off WinRT to try and rejuvenate
Win32 … well … that’ll be the opening one or more competitors needs to swoop in and
take the enterprise desktop.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=a77535fb-0ec1-4810-a863-082a53847324" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=20518398-080a-4efe-bb8a-4832596f7cechttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,20518398-080a-4efe-bb8a-4832596f7cec.aspxRockford Lhotka

I
thought I’d post a list of the top Windows 8 WinRT (windows store) apps that I use
all the time.

I know a lot of people who are running Win8 and treating it like Win7 – never leaving
the legacy Desktop if at all possible. I think those people are doing themselves a
disservice, and in the long run if they are developers then they are doing their users
a disservice. I say this because I view the Desktop today in the same light I viewed
green screen terminals in the early 1990s – a necessary evil that will ultimately
fade into the mists of time (except for those poor users who will forever be stuck
using legacy apps).

So these are the apps that, if they didn’t run on Win8, would probably drive me to
get an iPad or Android tablet (except that because they are on Win8 I can
use them on my tablet AND on my desktop, which is extremely nice). For the
most part these are pinned on my start screen on my tablet and desktop. I’ve bolded
the WinRT apps and left the legacy Desktop apps unbolded so it is clear just how much
I use WinRT.

Productivity:

Mail, Calendar, People – the standard apps/hubs that come with Win8
– they started out bad, but have become quite good

Outlook (desktop) – I only use this to schedule Lync meetings anymore, but can’t live
without it until there’s an alternative way to schedule a Lync meeting

Yahoo Mail – I use yahoo as my spam dump, but occasionally scan through
to see if anything real creeps into that mail box

Project Siena – has the potential to be the “VB” of WinRT if they
continue to evolve this tool – there’s no faster way to build simple WinRT business
apps

Chrome (desktop) – for when IE11 doesn’t meet my needs

Top Win8/WinRT appshttp://www.lhotka.net/weblog/PermaLink,guid,20518398-080a-4efe-bb8a-4832596f7cec.aspxhttp://www.lhotka.net/weblog/TopWin8WinRTApps.aspx
Wed, 26 Feb 2014 17:28:46 GMT<p>
<a href="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/TopWin8WinRTapps_A16D/New%20Skitch_2.jpg"><img title="New Skitch" style="border-top: 0px; border-right: 0px; border-bottom: 0px; margin: 5px; border-left: 0px; display: inline" border="0" alt="New Skitch" src="http://www.lhotka.net/weblog/content/binary/WindowsLiveWriter/TopWin8WinRTapps_A16D/New%20Skitch_thumb.jpg" width="240" align="right" height="150" /></a> I
thought I’d post a list of the top Windows 8 WinRT (windows store) apps that I use
all the time.
</p>
<p>
I know a lot of people who are running Win8 and treating it like Win7 – never leaving
the legacy Desktop if at all possible. I think those people are doing themselves a
disservice, and in the long run if they are developers then they are doing their users
a disservice. I say this because I view the Desktop today in the same light I viewed
green screen terminals in the early 1990s – a necessary evil that will ultimately
fade into the mists of time (except for those poor users who will forever be stuck
using legacy apps).
</p>
<p>
So these are the apps that, if they didn’t run on Win8, would probably drive me to
get an iPad or Android tablet (except that because they <em>are</em> on Win8 I can
use them on my tablet AND on my desktop, which is <em>extremely</em> nice). For the
most part these are pinned on my start screen on my tablet and desktop. I’ve bolded
the WinRT apps and left the legacy Desktop apps unbolded so it is clear just how much
I use WinRT.
</p>
<p>
Productivity:
</p>
<ul>
<li>
<strong>Mail, Calendar, People</strong> – the standard apps/hubs that come with Win8
– they started out bad, but have become quite good</li>
<li>
Outlook (desktop) – I only use this to schedule Lync meetings anymore, but can’t live
without it until there’s an alternative way to schedule a Lync meeting</li>
<li>
<strong>Yahoo Mail </strong>– I use yahoo as my spam dump, but occasionally scan through
to see if anything real creeps into that mail box</li>
<li>
<strong>OneNote </strong>– they’ve really made this app nice for keyboard/mouse and
touch and pen users – indispensible!</li>
<li>
<strong>Skitch Touch </strong>– nice, easy to use graphic editor – I use it to crop/annotate
quick screen grabs for the most part</li>
<li>
<strong>Healthvault </strong>– keep track of my blood pressure and weight, important
given my recent health issues, and it works on WP8 too</li>
<li>
<strong>qool </strong>– a very simple to-do tracker, which works for me because it
is low-friction, but I wish it worked on WP8 too</li>
<li>
<strong>MyTrips </strong>– I travel a lot and rely on Tripit.com to keep me sane;
MyTrips is on Win8 and WP8 and is better than the “official” Tripit app</li>
<li>
Office (desktop) – I <em>so</em> wish there was a WinRT version of Office, but in
the meantime I can’t live without the legacy Desktop version</li>
<li>
Live Writer (desktop) – still the best way I know to author blog posts</li>
</ul>
<p>
News, weather, etc:
</p>
<ul>
<li>
<strong>Nextgen Reader </strong>– RSS reader that also runs (and syncs) to my WP8
phone</li>
<li>
<strong>Bing News, Bing Weather </strong>– nice apps, consistent on WP8 (finally),
and keep me up to date with the world</li>
<li>
<strong>MyRadar </strong>– consistent with WP8 and the fastest way to get weather
radar on any device – I love this app!</li>
<li>
<strong>Reading List </strong>– keeps a list of articles/posts/URLs that I want to
review or use later</li>
<li>
<strong>Flipboard </strong>– I use this only on my tablet because it is only fun with
touch, but it presents a visually pleasing way to browse facebook/twitter/other web
info</li>
</ul>
<p>
Finance:
</p>
<ul>
<li>
<strong>Bing Finance </strong>– keep track of the market and business news</li>
<li>
<strong>Mint </strong>– keep track of family finances – mostly just trying it out
(and it is really nice), because I’m already a Quicken user</li>
<li>
Quicken (desktop) – keep track of family and business finances, but I wish there was
a WinRT version more like Mint – my problem is that Mint can’t do small business stuff,
so I need Quicken</li>
</ul>
<p>
Social:
</p>
<ul>
<li>
Lync (desktop) – I mostly use the Desktop version, though the WinRT app is slowly
catching up and I do look forward to being able to use it</li>
<li>
<strong>Twitter </strong>– the official twitter app, I’m sure there are better ones,
but I’m not a heavy twitter user so this is fine</li>
<li>
<strong>Skype </strong>– I use the WinRT app, but sometimes I also use the Desktop
app – but the WinRT app is catching up fast, which makes me happy</li>
<li>
<strong>Facebook </strong>– sure I can get there via the web, but I do like the app</li>
<li>
<strong>Yammer </strong>– I mostly use the web because the yammer app is pretty poor,
but it works as a share target; the WP8 app is better</li>
<li>
<strong>Reddit </strong>by samrad – I’m not a big reddit user, but this is a nicely
designed app that is fun to use</li>
<li>
<strong>IE11 </strong>– for LinkedIn, because they don’t have an app yet; and for
yammer because the WinRT yammer app is too limited</li>
</ul>
<p>
Media:
</p>
<ul>
<li>
<strong>Xbox Music </strong>– I have a subscription to the service, and love the access
to so much music on my tablet/PC/phone</li>
<li>
<strong>Xbox Video </strong>– I’ve purchased a few movies to watch on the airplane
on my Surface, and we also watch them on the TV through the Xbox</li>
<li>
<strong>Netflix </strong>– we cut the cable a couple years ago and rely on Netflix/Hulu/Amazon
for almost all media, so this app is indispensible</li>
<li>
<strong>Hulu Plus </strong>– see my notes on Netflix – indispensible</li>
<li>
<strong>IE11 </strong>– I wish, oh do I wish, that Amazon had streaming video app,
but as it is I’m stuck using IE to watch Amazon video</li>
<li>
<strong>MetroTube </strong>– very nice youtube app; another is MegaTube, but personally
I prefer MetroTube</li>
<li>
Zune (desktop) – my Xbox Music subscription provides me with 10 free songs each month,
and the old Zune app is the only way to use those 10 credits to ‘purchase’ the tracks</li>
<li>
<strong>Comics </strong>– the Comixology app is really nice; I know, as an adult I
shouldn’t read comics, but I’m an uber-geek so I do, and this app is a really nice
way to read them</li>
<li>
<strong>Kindle </strong>– I mostly use a real Kindle because I don’t like reading
on a glossy screen, but if I’m caught without my Kindle I’ll read on my Surface or
phone</li>
<li>
<strong>VEVO </strong>– I remember the days when MTV used to be about music videos,
and VEVO is much like MTV from 1985 – happiness!</li>
</ul>
<p>
Utilities:
</p>
<ul>
<li>
<strong>Clipboard </strong>– this is an app that allows you to Share from any app
into the Windows clipboard, and I use it constantly – couldn’t live without it</li>
<li>
<strong>File Manager HD </strong>– the best file manager app I’ve found so far – local
and remote file access, quite nice</li>
<li>
<strong>OneDrive</strong>/SkyDrive – slightly faster than File Manager HD for OneDrive
access, but otherwise a duplicate</li>
<li>
<strong>Dropbox </strong>– gives access to shared folders and other advanced features
not in File Manager HD</li>
<li>
<strong>Box </strong>– really a duplicate of File Manager HD</li>
<li>
<strong>Remote Desktop </strong>– the WinRT Microsoft RDP client is nice, and I use
it daily</li>
<li>
<strong>TeamViewer </strong>– I sometimes use TeamViewer to connect to my desktop
when I’m on the road; not as fast/smooth as RDP, but it gets through firewalls and
NAT routers better</li>
</ul>
<p>
Photos:
</p>
<ul>
<li>
<strong>Photos </strong>– I do use this app, but it was far better in Win8 than it
is in 8.1 – they really crippled it…</li>
<li>
Live Photo Gallery (desktop) – The only way to get at the thousands of photos on my
server, and remains far, far more powerful than the built-in Photos app</li>
</ul>
<p>
Gaming:
</p>
<ul>
<li>
Steam (desktop) – so I can get at all the games I’ve purchased via Steam</li>
<li>
Origin (desktop) – so I can play Battlefield 4 and (soon) TitanFall</li>
<li>
<strong>Wordament </strong>– my favorite casual game</li>
<li>
<strong>Halo Spartan Assault </strong>– so nicely done, and fun to play</li>
</ul>
<p>
Shopping:
</p>
<ul>
<li>
<strong>Amazon </strong>– of course! I do more shopping on Amazon than pretty much
anywhere else</li>
<li>
<strong>Zappos.com </strong>– I’m not a small man, and zappos always has shoes that
fit, and their service is excellent</li>
<li>
<strong>NewEgg </strong>– I go back and forth between their app and their web site,
but the app is pretty decent</li>
</ul>
<p>
Development:
</p>
<ul>
<li>
Visual Studio (desktop) – of course</li>
<li>
Blend (desktop) – of course</li>
<li>
Xamarin Tools (desktop) – build iOS and Android apps with C#, what more could you
want???</li>
<li>
GitHub for Windows (desktop) – nice way to interact with github and Visual Studio
Online repositories</li>
<li>
TortoiseGit (desktop) – I used TortoiseCvs, then TortoiseSvn, so it is natural that
I’d use TortoiseGit more than any other git client</li>
<li>
<strong>Windows 8 Dev Icons </strong>– provides useful icons with code snippets to
access them</li>
<li>
<strong>Xaml Candy </strong>– provides useful code snippets for common XAML elements</li>
<li>
<strong>Samples Browser </strong>– browse Microsoft samples</li>
<li>
<strong>Code Writer </strong>– a nice WinRT text/code editor for numerous file formats</li>
<li>
<strong>Project Spark </strong>– so much fun to build WinRT and Xbox games</li>
<li>
<strong>Project Siena </strong>– has the potential to be the “VB” of WinRT if they
continue to evolve this tool – there’s no faster way to build simple WinRT business
apps</li>
<li>
Chrome (desktop) – for when IE11 doesn’t meet my needs</li>
</ul>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=20518398-080a-4efe-bb8a-4832596f7cec" />Windows 8WinRTWP8http://www.lhotka.net/weblog/Trackback.aspx?guid=860e6ea5-1ad4-41ed-8f14-84fa5d2d3eb0http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,860e6ea5-1ad4-41ed-8f14-84fa5d2d3eb0.aspxRockford Lhotka

The short answer to the question of whether the Microsoft .NET Framework (and its
related tools and technologies) has a future is of course, don’t be silly.

The reality is that successful technologies take years, usually decades, perhaps longer,
to fade away. Most people would be shocked at how much of the world runs on RPG, COBOL,
FORTRAN, C, and C++ – all languages that became obsolete decades ago. Software written
in these languages runs on mainframes and minicomputers (also obsolete decades ago)
as well as more modern hardware in some cases. Of course in reality mainframes and
minicomputers are still manufactured, so perhaps they aren’t technically “obsolete”
except in our minds.

It is reasonable to assume that .NET (and Java) along with their primary platforms
(Windows and Unix/Linux) will follow those older languages into the misty twilight
of time. And that such a thing will take years, most likely decades, perhaps longer,
to occur.

I think it is critical to understand that point, because if you’ve built and bet your
career on .NET or Java it is good to know that nothing is really forcing you
to give them up. Although your chosen technology is already losing (or has lost) its
trendiness, and will eventually become extremely obscure, it is a pretty safe bet
that you’ll always have work. Even better, odds are good that your skills will become
sharply more valuable over time as knowledgeable .NET/Java resources become more rare.

Alternately you may choose some trendier alternative; the only seemingly viable candidate
being JavaScript or its spawn such as CoffeeScript or TypeScript.

How will this fading of .NET/Java technology relevance occur?

To answer I’ll subdivide the software world into two parts: client devices and servers.

Consumer Apps

Consumer apps are driven by a set of economic factors that make it well worth the
investment to build native apps for every platform. In this environment Objective
C, Java, and .NET (along with C++) all have a bright future.

Perhaps JavaScript will become a contender here, but that presupposes Apple,
Google, and Microsoft work to make that possible by undermining their existing proprietary
development tooling. There are some strong economic reasons why none of them would
want every app on the planet to run equally on every vendor’s device, so this seems
unlikely. That said, for reasons I can’t fathom, Microsoft is doing their best to
make sure JavaScript really does work well on Windows 8, so perhaps Apple will follow
suit and encourage their developers to abandon Objective C in favor of cross-platform
JavaScript?

Google already loves the idea of JavaScript and would clearly prefer if we all just
wrote every app in JavaScript for Chrome on Android, iOS, and Windows. The only question
in my mind is how they will work advertising into all of our Chrome apps in the future?

My interest doesn’t really lie in the consumer app space, as I think relatively few
people are going to get rich building casual games, fart apps, metro transit mapping
apps, and so forth. From a commercial perspective there is some money to be made building
apps for corporations, such as banking apps, brochure-ware apps, travel apps, etc.
But even that is a niche market compared to the business app space.

Business Apps

Business apps (apps for use by a business’s employees) are driven by an important
economic factor called a natural monopoly. Businesses want software that is built
and maintained as cheaply as possible. Rewriting the same app several times to get
a “native experience” on numerous operating systems has never been viable, and I can’t
see where IT budgets will be expanding to enable such waste in the near future. In
other words, businesses are almost certain to continue to build business apps in a
single language for a single client platform. For a couple decades this has been Windows,
with only a small number of language/tool combinations considered viable (VB, PowerBuilder,
.NET).

But today businesses are confronted with pressure to write apps that work on the iPad
as well as Windows (and outside the US on Android). The only two options available
are to write the app 3+ times or to find some cross-platform technology, such as JavaScript.

The natural monopoly concept creates some tension here.

A business might insist on supporting just one platform, probably Windows. A couple
years ago I thought Microsoft’s Windows 8 strategy was to make it realistic for businesses
to choose Windows and .NET as this single platform. Sadly they’ve created a side
loading cost model that basically blocks WinRT business app deployment, making
Windows far less interesting in terms of being the single platform. The only thing
Windows has going for it is Microsoft’s legacy monopoly, which will carry
them for years, but (barring business-friendly changes to WinRT licensing) is doomed
to erode.

You can probably tell I think Microsoft has royally screwed themselves over with their
current Windows 8 business app “strategy”. I’ve been one of the loudest and most consistent
voices on this issue for the past couple years, but Microsoft appears oblivious to
the problem and has shown no signs of even recognizing the problem much less looking
at solutions. I’ve come to the conclusion that they expect .NET on the client
to fade away, and for Windows to compete as just one of several platforms that can
run JavaScript apps. In other words I’ve come to the conclusion that Microsoft is willingly
giving up on any sort of technology lock-in or differentiation of the Windows
client in terms of business app development. They want us to write cross-platform
JavaScript apps, and they simply hope that businesses and end users will choose Windows
for other reasons than because the apps only run on Windows.

Perhaps a business would settle on iOS or Android as the “one client platform”, but
that poses serious challenges given that virtually all businesses have massive legacies
of Windows apps. The only realistic way to switch clients to iOS or Android is to
run all those Windows apps on Citrix servers (or equivalent), and to ensure that the
client devices have keyboards and mice so users can actually interact with the legacy
Windows apps for the next several years/decades. Android probably has a leg up here
because most Android devices have USB ports for keyboards/mice, but really neither
iOS nor Android have the peripheral or multi-monitor support necessary to truly replace
legacy Windows (Win32/.NET).

This leaves us with the idea that businesses won’t choose one platform in
the traditional sense, but rather will choose a more abstract runtime: namely JavaScript
running in a browser DOM (real or simulated). Today this is pretty hard because of
differences between browsers and between browsers on different platforms. JavaScript
libraries such as jquery, angular, and many others seek to abstract away those differences,
but there’s no doubt that building a JavaScript client app costs more today than building
the same app in .NET or some other more mature/consistent technology.

At the same time, only JavaScript really offers any hope of building a client app
codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and
PCs. So though it may be more expensive than just writing a .NET app for Windows,
JavaScript might be cheaper than rewriting the app 3+ times for iOS, Android,
and Windows. And there’s always hope that JavaScript (or its offspring like CoffeScript
or TypeScript) will rapidly mature enough to make this “platform” more cost-effective.

I look at JavaScript today much like Visual Basic 3 in the early 1990s (or C in the
late 1980s). It is typeless and primitive compared to modern C#/VB or Java. To overcome
this it relies on tons of external components (VB had its component model, JavaScript
has myriad open source libraries). These third party components change rapidly and
with little or no cross-coordination, meaning that you are lucky if you have a stable
development target for a few weeks (as opposed to .NET or Java where you could have
a stable target for months or years). As a result a lot of the development practices
we’ve learned and mastered over the past 20 years are no longer relevant, and new
practices must be devised, refined, and taught.

Also we must recognize that JavaScript apps never go into a pure maintenance
mode. Browsers and underlying operating systems, along with the numerous open source
libraries you must use, are constantly versioning and changing, so you can never stop
updating your app codebase to accommodate this changing landscape. If you do stop,
you’ll end up where so many businesses are today: trapped on IE6 and Windows XP because
nothing they wrote for IE6 can run on any modern browser. We know that is
a doomed strategy, so we therefore know that JavaScript apps will require continual
rewrites to keep them functional over time.

What I’m getting at here is that businesses have an extremely ugly choice on the client:

Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android

Absorb the up-front and ongoing cost of building and maintaining apps in cross-platform
JavaScript

Select one platform (almost certainly Windows) on which to write all client apps,
and require users to use that platform

I think I’ve listed those in order from most to least expensive, though numbers
1 and 2 could be reversed in some cases. I think in all cases it is far cheaper for
businesses to do what Delta
recently did and just issue Windows devices to their employees, thus allowing
them to write, maintain, and support apps on a single, predictable platform.

The thing is that businesses are run by humans, and humans are often highly irrational.
People are foolishly enamored of BYOD (bring your own device), which might feel
good, but is ultimately expensive and highly problematic. And executives are
often the drivers for alternate platforms because they like their cool new gadgets;
oblivious to the reality that supporting their latest tech fad (iPad, Android, whatever)
might cost the business many thousands (often easily 100’s of thousands) of dollars
each year in software development, maintenance, and support costs.

Of course I work for a software development consulting company. Like all such companies
we effectively charge by the hour. So from my perspective I’d really prefer if everyone did decide
to write all their apps 3+ times, or write them in cross-platform JavaScript. That’s
just more work for us, even if objectively it is pretty damn stupid from the perspective
of our customers’ software budgets.

Server Software

Servers are a bit simpler than client devices.

The primary technologies used today on servers are .NET and Java. Though as I pointed
out at the start of this post, you shouldn’t discount the amount of COBOL, RPG, FORTRAN,
and other legacy languages/tools/platforms that make our world function.

Although JavaScript has a nescient presence on the server via tools like node.js,
I don’t think any responsible business decision maker is looking at moving away from
existing server platform tools in the foreseeable future.

In other words the current 60/40 split (or 50/50, depending on whose numbers you believe)
between .NET and Java on the server isn’t likely to change any time soon.

Personally I am loath to give up the idea of a common technology platform
between client and server – something provided by VB in the 1990s and .NET over the
past 13 years. So if we really do end up writing all our client software in JavaScript
I’ll be a strong advocate for things like node.js on the server.

In the mid-1990s it was pretty common to write “middle tier” software in C++ and “client
tier” software in PowerBuilder or VB. Having observed such projects and the attendant
complexity of having a middle tier dev team who theoretically coordinated with the
client dev team, I can say that this isn’t a desirable model. I can’t support the
idea of a middle tier in .NET and a client tier in JavaScript, because I can’t see
how team dynamics and inter-personal communication capabilities have changed enough
(or at all) over the past 15 years such that we should expect any better outcome now
than we got back then.

So from a server software perspective I think .NET and Java have a perfectly fine
future, because the server-side JavaScript concept is even less mature than client-side
JavaScript.

At the same time, I really hope that (if we move to JavaScript on the client) JavaScript
matures rapidly on both client and server, eliminating the need for .NET/Java on the
server as well as the client.

Conclusion

In the early 1990s I was a VB expert. In fact, I was one of the world’s leading VB
champions through the 1990s. So if we are going to select JavaScript as the “one technology
to rule them all” I guess I’m OK with going back to something like that world.

I’m not totally OK with it, because I rather enjoy modern C#/VB and .NET.
And yes, I could easily ride out the rest of my career on .NET, there’s no doubt in
my mind. But I have never in my career been a legacy platform developer, and I can’t
imagine working in a stagnant and increasingly irrelevant technology, so I doubt I’ll
make that choice – stable though it might be.

Fwiw, I do still think Microsoft has a chance to make Windows 8, WinRT, and .NET a
viable business app development target into the future. But their time is running
out, and as I said earlier they seem oblivious to the danger (or are perhaps embracing
the loss of Windows as the primary app dev target on the client). I would like to
see Microsoft wake up and get a clue, resulting in WinRT and .NET being a viable future
for business app dev.

Failing that however, we all need to start putting increasing pressure on vendors
(commercial and open source) to mature JavaScript, its related libraries and tools,
and its offspring such as TypeScript – on both client and server. The status of JavaScript
today is too primitive to replace .NET/Java, and if we’re to go down this road a lot
of money and effort needs to be expended rapidly to create a stable, predictable,
and productive enterprise-level JavaScript app dev platform.

Does .NET Have A Future?http://www.lhotka.net/weblog/PermaLink,guid,860e6ea5-1ad4-41ed-8f14-84fa5d2d3eb0.aspxhttp://www.lhotka.net/weblog/DoesNETHaveAFuture.aspx
Tue, 08 Oct 2013 03:24:20 GMT<p>
The short answer to the question of whether the Microsoft .NET Framework (and its
related tools and technologies) has a future is <em>of course, don’t be silly</em>.
</p>
<p>
The reality is that successful technologies take years, usually decades, perhaps longer,
to fade away. Most people would be shocked at how much of the world runs on RPG, COBOL,
FORTRAN, C, and C++ – all languages that became obsolete decades ago. Software written
in these languages runs on mainframes and minicomputers (also obsolete decades ago)
as well as more modern hardware in some cases. Of course in reality mainframes and
minicomputers are still manufactured, so perhaps they aren’t technically “obsolete”
except in our minds.
</p>
<p>
It is reasonable to assume that .NET (and Java) along with their primary platforms
(Windows and Unix/Linux) will follow those older languages into the misty twilight
of time. And that such a thing will take years, most likely decades, perhaps longer,
to occur.
</p>
<p>
I think it is critical to understand that point, because if you’ve built and bet your
career on .NET or Java it is good to know that nothing is really <em>forcing</em> you
to give them up. Although your chosen technology is already losing (or has lost) its
trendiness, and will eventually become extremely obscure, it is a pretty safe bet
that you’ll always have work. Even better, odds are good that your skills will become
sharply more valuable over time as knowledgeable .NET/Java resources become more rare.
</p>
<p>
Alternately you may choose some trendier alternative; the only seemingly viable candidate
being JavaScript or its spawn such as <a href="http://coffeescript.org/">CoffeeScript</a> or <a href="http://www.typescriptlang.org/">TypeScript</a>.
</p>
<p>
How will this fading of .NET/Java technology relevance occur?
</p>
<p>
To answer I’ll subdivide the software world into two parts: client devices and servers.
</p>
<h3>Client Devices
</h3>
<p>
On client devices (PCs, laptops, ultrabooks, tablets, phones, etc.) I feel the need
to further split into two parts: consumer apps and business apps. Yes, I know that
people seem to think there’s no difference, but as I’ve said before, I think there’s
an <a href="http://www.lhotka.net/weblog/ConsumerVsBusinessApps.aspx">important economic
distinction between the consumer and business apps</a>.
</p>
<h4>Consumer Apps
</h4>
<p>
Consumer apps are driven by a set of economic factors that make it well worth the
investment to build native apps for every platform. In this environment Objective
C, Java, and .NET (along with C++) all have a bright future.
</p>
<p>
<em>Perhaps</em> JavaScript will become a contender here, but that presupposes Apple,
Google, and Microsoft work to make that possible by undermining their existing proprietary
development tooling. There are some strong economic reasons why none of them would
want every app on the planet to run equally on every vendor’s device, so this seems
unlikely. That said, for reasons I can’t fathom, Microsoft is doing their best to
make sure JavaScript really does work well on Windows 8, so perhaps Apple will follow
suit and encourage their developers to abandon Objective C in favor of cross-platform
JavaScript?
</p>
<p>
Google already loves the idea of JavaScript and would clearly prefer if we all just
wrote every app in JavaScript for Chrome on Android, iOS, and Windows. The only question
in my mind is how they will work advertising into all of our Chrome apps in the future?
</p>
<p>
My interest doesn’t really lie in the consumer app space, as I think relatively few
people are going to get rich building casual games, fart apps, metro transit mapping
apps, and so forth. From a commercial perspective there is some money to be made building
apps for corporations, such as banking apps, brochure-ware apps, travel apps, etc.
But even that is a niche market compared to the business app space.
</p>
<h4>Business Apps
</h4>
<p>
Business apps (apps for use by a business’s employees) are driven by an important
economic factor called a natural monopoly. Businesses want software that is built
and maintained as cheaply as possible. Rewriting the same app several times to get
a “native experience” on numerous operating systems has never been viable, and I can’t
see where IT budgets will be expanding to enable such waste in the near future. In
other words, businesses are almost certain to continue to build business apps in a
single language for a single client platform. For a couple decades this has been Windows,
with only a small number of language/tool combinations considered viable (VB, PowerBuilder,
.NET).
</p>
<p>
But today businesses are confronted with pressure to write apps that work on the iPad
as well as Windows (and outside the US on Android). The only two options available
are to write the app 3+ times or to find some cross-platform technology, such as JavaScript.
</p>
<p>
The natural monopoly concept creates some tension here.
</p>
<p>
A business might insist on supporting just one platform, probably Windows. A couple
years ago I thought Microsoft’s Windows 8 strategy was to make it realistic for businesses
to choose Windows and .NET as this single platform. Sadly they’ve created a <a href="http://www.lhotka.net/weblog/Windows8WinRTLicensingIdeas.aspx">side
loading cost model</a> that basically blocks WinRT business app deployment, making
Windows far less interesting in terms of being the single platform. The only thing
Windows has going for it is Microsoft’s legacy monopoly, which <em>will</em> carry
them for years, but (barring business-friendly changes to WinRT licensing) is doomed
to erode.
</p>
<blockquote>
<p>
You can probably tell I think Microsoft has royally screwed themselves over with their
current Windows 8 business app “strategy”. I’ve been one of the loudest and most consistent
voices on this issue for the past couple years, but Microsoft appears oblivious to
the problem and has shown no signs of even recognizing the problem much less looking
at solutions. I’ve come to the conclusion that they <em>expect</em> .NET on the client
to fade away, and for Windows to compete as just one of several platforms that can
run JavaScript apps. In other words I’ve come to the conclusion that Microsoft is <em>willingly
giving up</em> on any sort of technology lock-in or differentiation of the Windows
client in terms of business app development. They <em>want</em> us to write cross-platform
JavaScript apps, and they simply hope that businesses and end users will choose Windows
for other reasons than because the apps only run on Windows.
</p>
</blockquote>
<p>
Perhaps a business would settle on iOS or Android as the “one client platform”, but
that poses serious challenges given that virtually all businesses have massive legacies
of Windows apps. The only realistic way to switch clients to iOS or Android is to
run all those Windows apps on Citrix servers (or equivalent), and to ensure that the
client devices have keyboards and mice so users can actually interact with the legacy
Windows apps for the next several years/decades. Android probably has a leg up here
because most Android devices have USB ports for keyboards/mice, but really neither
iOS nor Android have the peripheral or multi-monitor support necessary to truly replace
legacy Windows (Win32/.NET).
</p>
<p>
This leaves us with the idea that businesses <em>won’t</em> choose one platform in
the traditional sense, but rather will choose a more abstract runtime: namely JavaScript
running in a browser DOM (real or simulated). Today this is pretty hard because of
differences between browsers and between browsers on different platforms. JavaScript
libraries such as jquery, angular, and many others seek to abstract away those differences,
but there’s no doubt that building a JavaScript client app costs more today than building
the same app in .NET or some other more mature/consistent technology.
</p>
<p>
At the same time, only JavaScript really offers any hope of building a client app
codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and
PCs. So though it may be more expensive than just writing a .NET app for Windows,
JavaScript <em>might</em> be cheaper than rewriting the app 3+ times for iOS, Android,
and Windows. And there’s always hope that JavaScript (or its offspring like CoffeScript
or TypeScript) will rapidly mature enough to make this “platform” more cost-effective.
</p>
<p>
I look at JavaScript today much like Visual Basic 3 in the early 1990s (or C in the
late 1980s). It is typeless and primitive compared to modern C#/VB or Java. To overcome
this it relies on tons of external components (VB had its component model, JavaScript
has myriad open source libraries). These third party components change rapidly and
with little or no cross-coordination, meaning that you are lucky if you have a stable
development target for a few weeks (as opposed to .NET or Java where you could have
a stable target for months or years). As a result a lot of the development practices
we’ve learned and mastered over the past 20 years are no longer relevant, and new
practices must be devised, refined, and taught.
</p>
<p>
Also we must recognize that JavaScript apps <em>never</em> go into a pure maintenance
mode. Browsers and underlying operating systems, along with the numerous open source
libraries you must use, are constantly versioning and changing, so you can never stop
updating your app codebase to accommodate this changing landscape. If you do stop,
you’ll end up where so many businesses are today: trapped on IE6 and Windows XP because
nothing they wrote for IE6 can run on any modern browser. We <em>know</em> that is
a doomed strategy, so we therefore know that JavaScript apps will require continual
rewrites to keep them functional over time.
</p>
<p>
What I’m getting at here is that businesses have an extremely ugly choice on the client:
</p>
<ol>
<li>
Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android</li>
<li>
Absorb the up-front and ongoing cost of building and maintaining apps in cross-platform
JavaScript</li>
<li>
Select one platform (almost certainly Windows) on which to write all client apps,
and require users to use that platform</li>
</ol>
<p>
I <em>think</em> I’ve listed those in order from most to least expensive, though numbers
1 and 2 could be reversed in some cases. I think in all cases it is far cheaper for
businesses to do what <a href="http://finance.yahoo.com/news/delta-equip-11-000-pilots-150000465.html">Delta
recently did</a> and just issue Windows devices to their employees, thus allowing
them to write, maintain, and support apps on a single, predictable platform.
</p>
<p>
The thing is that businesses are run by humans, and humans are often highly irrational.
People are foolishly enamored of BYOD (bring your own device), which might <em>feel
good</em>, but is ultimately expensive and highly problematic. And executives are
often the drivers for alternate platforms because they like their cool new gadgets;
oblivious to the reality that supporting their latest tech fad (iPad, Android, whatever)
might cost the business many thousands (often easily 100’s of thousands) of dollars
each year in software development, maintenance, and support costs.
</p>
<p>
Of course I work for a software development consulting company. Like all such companies
we effectively charge by the hour. So from my perspective I’d really prefer if everyone <em>did</em> decide
to write all their apps 3+ times, or write them in cross-platform JavaScript. That’s
just more work for us, even if objectively it is pretty damn stupid from the perspective
of our customers’ software budgets.
</p>
<h3>Server Software
</h3>
<p>
Servers are a bit simpler than client devices.
</p>
<p>
The primary technologies used today on servers are .NET and Java. Though as I pointed
out at the start of this post, you shouldn’t discount the amount of COBOL, RPG, FORTRAN,
and other legacy languages/tools/platforms that make our world function.
</p>
<p>
Although JavaScript has a nescient presence on the server via tools like <a href="http://nodejs.org/">node.js</a>,
I don’t think any responsible business decision maker is looking at moving away from
existing server platform tools in the foreseeable future.
</p>
<p>
In other words the current 60/40 split (or 50/50, depending on whose numbers you believe)
between .NET and Java on the server isn’t likely to change any time soon.
</p>
<p>
<em>Personally</em> I am loath to give up the idea of a common technology platform
between client and server – something provided by VB in the 1990s and .NET over the
past 13 years. So if we really do end up writing all our client software in JavaScript
I’ll be a strong advocate for things like node.js on the server.
</p>
<p>
In the mid-1990s it was pretty common to write “middle tier” software in C++ and “client
tier” software in PowerBuilder or VB. Having observed such projects and the attendant
complexity of having a middle tier dev team who theoretically coordinated with the
client dev team, I can say that this isn’t a desirable model. I can’t support the
idea of a middle tier in .NET and a client tier in JavaScript, because I can’t see
how team dynamics and inter-personal communication capabilities have changed enough
(or at all) over the past 15 years such that we should expect any better outcome now
than we got back then.
</p>
<p>
So from a server software perspective I think .NET and Java have a perfectly fine
future, because the server-side JavaScript concept is even less mature than client-side
JavaScript.
</p>
<p>
At the same time, I really hope that (if we move to JavaScript on the client) JavaScript
matures rapidly on both client and server, eliminating the need for .NET/Java on the
server as well as the client.
</p>
<h3>Conclusion
</h3>
<p>
In the early 1990s I was a VB expert. In fact, I was one of the world’s leading VB
champions through the 1990s. So if we are going to select JavaScript as the “one technology
to rule them all” I guess I’m OK with going back to something like that world.
</p>
<p>
I’m not <em>totally</em> OK with it, because I rather enjoy modern C#/VB and .NET.
And yes, I could easily ride out the rest of my career on .NET, there’s no doubt in
my mind. But I have never in my career been a legacy platform developer, and I can’t
imagine working in a stagnant and increasingly irrelevant technology, so I doubt I’ll
make that choice – stable though it might be.
</p>
<p>
Fwiw, I do still think Microsoft has a chance to make Windows 8, WinRT, and .NET a
viable business app development target into the future. But their time is running
out, and as I said earlier they seem oblivious to the danger (or are perhaps embracing
the loss of Windows as the primary app dev target on the client). I would <em>like</em> to
see Microsoft wake up and get a clue, resulting in WinRT and .NET being a viable future
for business app dev.
</p>
<p>
Failing that however, we all need to start putting increasing pressure on vendors
(commercial and open source) to mature JavaScript, its related libraries and tools,
and its offspring such as TypeScript – on both client and server. The status of JavaScript
today is too primitive to replace .NET/Java, and if we’re to go down this road a lot
of money and effort needs to be expended rapidly to create a stable, predictable,
and productive enterprise-level JavaScript app dev platform.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=860e6ea5-1ad4-41ed-8f14-84fa5d2d3eb0" />h5jsJavaScriptMicrosoft .NETProgrammingWebWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=deac1d00-e082-4388-a260-6ce8cacc4882http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,deac1d00-e082-4388-a260-6ce8cacc4882.aspxRockford Lhotka

A lot of people, including myself, felt (feel?) deeply betrayed by Microsoft’s rather
abrupt dismissal of what some of us thought was the best client-side dev platform
they’ve ever come up with: Silverlight.

Perhaps even more people are worried about the future of WPF in the face of Microsoft’s
obvious focus on the new Windows Runtime (WinRT) at the expense of the Desktop (Win32)
technologies such as Windows Forms and WPF.

I’m a little more sanguine about this than many people.

I never really bought into the idea of Silverlight as a cross-platform technology.
I know, I know, Microsoft made it work on some flavors of OS X. But they didn’t take
it to Linux or Android, and Apple blocked them from ever going to the iPad or iPhone.
And honestly, you have to follow the money. Companies don’t exist to do good,
they exist to make money, and Microsoft didn’t charge for Silverlight and so only
stood to lose money by enabling us to build apps that ran on non-Windows
devices just as well as Windows devices.

(as an aside, this is why I never get too upset when Google drops yet another free
service – the way I look at it is that I’m exploiting the hell out of Google’s free
stuff as long as they have it, and when they decide to drop a free service I just
have to start paying for something I should have been paying for the entire
time (but didn’t have to thanks to Google’s amazing “business” model)).

I did buy into the idea of Silverlight as a much safer and easier-to-deploy
way of building Windows smart client apps. So to me the truly sad part about Silverlight
going away is that it pushed us back toward creating apps that aren’t as safe (out
of the sandbox), and that are slightly harder to deploy (ClickOnce).

Perhaps I’m unusual, but I really do buy into the idea that smart client apps don’t
need the ability to reformat people’s hard drives, or alter system files, or snoop
through my personal documents without my knowledge. In other words, the full client-side
.NET/WPF/Windows Forms/Win32 technology stack just isn’t necessary for 99% of the
apps I want to build and/or run, and after a few decades of dealing with viruses and
malware and other bad stuff, I’m about ready to be done with it!

So here we site, with Silverlight in maintenance mode so Microsoft will keep it running
on their platforms for another decade, but without any real assurance that it will
continue to work on the Mac. And frankly I don’t really care, because I always thought
the Mac was a lark.

To me where we are is simple:

Microsoft is treating all of Win32/.NET on the client as legacy, so Windows Forms,
WPF, and Silverlight are in the exact same boat

They are all stable (essentially unchanging) into the foreseeable future

They are all good/viable Win32/Desktop client technologies

They will ultimately fade away

Microsoft is putting all their energy/money into rapidly bringing WinRT up to speed

Being a fan of “follow the money”, I expect that we’ll all eventually move to WinRT

WinRT 8.1 shows some good XAML/C# improvements over 8.0, demonstrating Microsoft’s
commitment to making this a viable platform

WinRT still has a fundamentally flawed deployment/licensing model for business apps,
and until they fix this WinRT is pretty much useless for business

WinRT still lags in XAML features behind Silverlight 5, but it is catching up

WinRT (like Silverlight) will hopefully never do everything WPF does, because
then we’d be back to the same malware hell-hole we’re in with Win32

In short, for everyone wishing and hoping for Microsoft to put more energy/money into
WPF (or even more far-fetched into Silverlight) I think the answer is that THEY ARE
– but they are doing it via WinRT, by eventually providing a viable XAML/C# platform
for business development on Windows that escapes the baggage of legacy Win32/.NET/Desktop.

We just need to do two things

Be patient, because WinRT is a v1 technology and will take a little time to mature

Something I’m not worried about, because most businesses are just now getting to Win7
and won’t go to Win8 for a couple more years, so there’s some time for Microsoft to
get their act together

Keep the pressure on Microsoft to bring WinRT to the level we need

In terms of licensing/deployment models

In terms of technology capabilities

Let’s face it. Either Microsoft (with us pushing/prodding/helping) provides a viable
WinRT platform for us in the future, or we’d better all start learning JavaScript
and/or Objective C…

WinRT as the new Silverlight and WPFhttp://www.lhotka.net/weblog/PermaLink,guid,deac1d00-e082-4388-a260-6ce8cacc4882.aspxhttp://www.lhotka.net/weblog/WinRTAsTheNewSilverlightAndWPF.aspx
Tue, 09 Jul 2013 16:58:43 GMT<p>
A lot of people, including myself, felt (feel?) deeply betrayed by Microsoft’s rather
abrupt dismissal of what some of us thought was the best client-side dev platform
they’ve ever come up with: Silverlight.
</p>
<p>
Perhaps even more people are worried about the future of WPF in the face of Microsoft’s
obvious focus on the new Windows Runtime (WinRT) at the expense of the Desktop (Win32)
technologies such as Windows Forms and WPF.
</p>
<p>
I’m a little more sanguine about this than many people.
</p>
<p>
I never really bought into the idea of Silverlight as a cross-platform technology.
I know, I know, Microsoft made it work on some flavors of OS X. But they didn’t take
it to Linux or Android, and Apple blocked them from ever going to the iPad or iPhone.
And honestly, <em>you have to follow the money</em>. Companies don’t exist to do good,
they exist to make money, and Microsoft didn’t charge for Silverlight and so only
stood to <em>lose</em> money by enabling us to build apps that ran on non-Windows
devices just as well as Windows devices.
</p>
<p>
(as an aside, this is why I never get too upset when Google drops yet another free
service – the way I look at it is that I’m exploiting the hell out of Google’s free
stuff as long as they have it, and when they decide to drop a free service I just
have to start paying for something I <em>should </em>have been paying for the entire
time (but didn’t have to thanks to Google’s amazing “business” model)).
</p>
<p>
I <em>did</em> buy into the idea of Silverlight as a much safer and easier-to-deploy
way of building Windows smart client apps. So to me the truly sad part about Silverlight
going away is that it pushed us back toward creating apps that aren’t as safe (out
of the sandbox), and that are slightly harder to deploy (ClickOnce).
</p>
<p>
Perhaps I’m unusual, but I really do buy into the idea that smart client apps don’t
need the ability to reformat people’s hard drives, or alter system files, or snoop
through my personal documents without my knowledge. In other words, the full client-side
.NET/WPF/Windows Forms/Win32 technology stack just isn’t necessary for 99% of the
apps I want to build and/or run, and after a few decades of dealing with viruses and
malware and other bad stuff, I’m about ready to be done with it!
</p>
<p>
So here we site, with Silverlight in maintenance mode so Microsoft will keep it running
on their platforms for another decade, but without any real assurance that it will
continue to work on the Mac. And frankly I don’t really care, because I always thought
the Mac was a lark.
</p>
<p>
To me where we are is simple:
</p>
<ul>
<li>
Microsoft is treating all of Win32/.NET on the client as legacy, so Windows Forms,
WPF, and Silverlight are in the exact same boat</li>
<ul>
<li>
They are all stable (essentially unchanging) into the foreseeable future</li>
<li>
They are all good/viable Win32/Desktop client technologies</li>
<li>
They will ultimately fade away</li>
</ul>
<li>
Microsoft is putting all their energy/money into rapidly bringing WinRT up to speed</li>
<ul>
<li>
Being a fan of “follow the money”, I expect that we’ll all eventually move to WinRT</li>
<li>
WinRT 8.1 shows some good XAML/C# improvements over 8.0, demonstrating Microsoft’s
commitment to making this a viable platform</li>
<li>
WinRT still has a fundamentally flawed deployment/licensing model for business apps,
and until they fix this WinRT is pretty much useless for business</li>
<li>
WinRT still lags in XAML features behind Silverlight 5, but it is catching up</li>
<li>
WinRT (like Silverlight) will hopefully <em>never</em> do everything WPF does, because
then we’d be back to the same malware hell-hole we’re in with Win32</li>
</ul>
</ul>
<p>
In short, for everyone wishing and hoping for Microsoft to put more energy/money into
WPF (or even more far-fetched into Silverlight) I think the answer is that THEY ARE
– but they are doing it via WinRT, by eventually providing a viable XAML/C# platform
for business development on Windows that escapes the baggage of legacy Win32/.NET/Desktop.
</p>
<p>
We just need to do two things
</p>
<ol>
<li>
Be patient, because WinRT is a v1 technology and will take a little time to mature</li>
<ol>
<li>
Something I’m not worried about, because most businesses are just now getting to Win7
and won’t go to Win8 for a couple more years, so there’s some time for Microsoft to
get their act together</li>
</ol>
<li>
Keep the pressure on Microsoft to bring WinRT to the level we need</li>
<ol>
<li>
In terms of licensing/deployment models</li>
<li>
In terms of technology capabilities</li>
</ol>
>
<p>
Let’s face it. Either Microsoft (with us pushing/prodding/helping) provides a viable
WinRT platform for us in the future, or we’d better all start learning JavaScript
and/or Objective C…
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=deac1d00-e082-4388-a260-6ce8cacc4882" />Microsoft .NETWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=3395dc25-66bf-43da-8814-3d1203d6d106http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,3395dc25-66bf-43da-8814-3d1203d6d106.aspxRockford Lhotka

After having a couple days to collect my thoughts regarding last week’s Build 2013
conference I want to share some of my observations.

First, I left Build happier with Microsoft than I’ve been for a couple years. Not
necessarily due to any single thing or announcement, but rather because of the broader
thematic reality that Microsoft really is listening (if perhaps grudgingly in some
cases) to their customers. And the display of truly amazing, cool, and sexy laptops
and tablets running Windows 8 was really something! I was almost literally drooling
over some of the machines on display!

Now to summarize some of my thoughts.

The bad:

They didn’t add support for Silverlight in the WinRT browser (not that anyone really
thought they would).

The changes in Windows 8.1 to provide some accommodations for people who are attached
to the Start button are quite nice. To be honest, I was pretty skeptical that these
changes were just silliness, but having used 8.1 Preview for a few days now I’m sold
on my own positive emotional reaction to having the wallpaper the same on the desktop
and start screen (though I’m still not booting to desktop, nor do I plan to do so).

The Windows 8.1 changes that bring the start screen experience more in line with Windows
Phone are even nicer. The new item selection gesture (tap and hold) and the fact that
new apps don’t automatically appear on the start screen (only on the “app apps” screen)
are just like the phone, and make the system easier to deal with overall.

The updates to WinRT XAML are extremely welcome – especially around data binding –
these are changes I’ll use in CSLA .NET right away.

The added WinRT API capabilities demonstrate Microsoft’s commitment to rapidly maturing
what amounts to a Version 1 technology as rapidly as possible.

The fact that Azure had no big announcements, because they’ve been continually releasing
their new stuff as it becomes available is wonderful! In fact, this whole “faster
release cadence” concept from Windows, Azure, and Visual Studio is (imo) a welcome
change, because it means that the overall .NET and Microsoft platform will be far
more competitive by being more agile.

There was a serious emphasis on XAML, and most of the JavaScript content was web-focused,
not WinRT-focused – and I think this is good because it reflects the reality of the
Microsoft developer community. Most of us are .NET/XAML developers and if we’re going
to shift to WinRT someday in the future it’ll be via .NET/XAML. For my part, if I’m
forced to abandon .NET for JavaScript I’ll learn general JavaScript, not some Microsoft-specific
variation or library – but if I see a viable future for .NET in the WinRT world, then
I’ll continue to invest in .NET – and this conference was a start on Microsoft’s
part toward rebuilding a little trust in the future of .NET.

The new 8” tablet form factor is way nicer than I’d expected. I had a Kindle Fire
and ultimately gave it to my son because I already have an eInk Kindle and couldn’t
see a good use for the Fire. But an 8” Win8 tablet is a whole different matter, because
it runs the Kindle app and it runs Office and WinRT apps so it is immediately
useful. The small screen means amazing battery life and light weight, and the ATOM
processor means it runs Win32 and WinRT apps – I’m really enjoying this new
Acer device!

The neutral:

As I tweeted last week the one recurring bit of feedback I heard from people was disappointment
in the lack of WPF announcements or content. I’m not overly concerned about that,
because I view Windows Forms, Silverlight, and WPF as all being the same – they are
all in maintenance mode and Microsoft is just keeping them running. The same unprecedented
stability enjoyed by Windows Forms developers for the past 8 years is now the reality
for WPF too. Sure, this might be a little boring to be on an unchanging platform,
but the productivity is hard to beat!!

Related to the lack of WPF content I want to suggest a different interpretation. WinRT
with .NET/XAML is (imo) the “future of WPF”. What we really need to see is
WinRT XAML continuing to rapidly evolve such that it becomes a natural progression
to move from WPF/Silverlight to WinRT at some point in the future. I am encouraged
by what was presented at Build in terms of the evolution of WinRT XAML, and if that
continues I think we’ll find that moving to WinRT will become pretty attractive at
some future time.

There was some content on the use of WinRT to create business apps, and that content
was welcome. If-and-when Microsoft does fix the side-loading licensing issues so WinRT
becomes viable for business use it is nice to know that some serious thought has gone
into design and development of business apps on the new platform.

In conclusion, the overall vibe at the conference was positive. Attendees were, from
what I could see, enjoying the conference, the content, and the technology. Moreover,
I think Microsoft has taken a first small step toward rebuilding their relationship
with (what was once) the Microsoft developer community (not that Azure ever lost this
rapport, but the Windows client sure did). If they continue to build and foster this
rapport I think they can win back some confidence that there’s a future for .NET and/or
Windows on the client.

Thoughts on Build 2013http://www.lhotka.net/weblog/PermaLink,guid,3395dc25-66bf-43da-8814-3d1203d6d106.aspxhttp://www.lhotka.net/weblog/ThoughtsOnBuild2013.aspx
Mon, 01 Jul 2013 22:14:12 GMT<p>
After having a couple days to collect my thoughts regarding last week’s Build 2013
conference I want to share some of my observations.
</p>
<p>
First, I left Build happier with Microsoft than I’ve been for a couple years. Not
necessarily due to any single thing or announcement, but rather because of the broader
thematic reality that Microsoft really is listening (if perhaps grudgingly in some
cases) to their customers. And the display of truly amazing, cool, and sexy laptops
and tablets running Windows 8 was really something! I was almost literally drooling
over some of the machines on display!
</p>
<p>
Now to summarize some of my thoughts.
</p>
<p>
The bad:
</p>
<ol>
<li>
They didn’t add support for Silverlight in the WinRT browser (not that anyone really
thought they would).</li>
<li>
They didn’t fix (or even discuss) the nasty <a href="http://www.lhotka.net/weblog/Windows8WinRTLicensingIdeas.aspx">business
licensing cost issues around side-loading</a>, meaning most businesses will still
find WinRT unpalatable as a development target.</li>
</ol>
<p>
The good:
</p>
<ol>
<li>
The changes in Windows 8.1 to provide some accommodations for people who are attached
to the Start button are quite nice. To be honest, I was pretty skeptical that these
changes were just silliness, but having used 8.1 Preview for a few days now I’m sold
on my own positive emotional reaction to having the wallpaper the same on the desktop
and start screen (though I’m still not booting to desktop, nor do I plan to do so).</li>
<li>
The Windows 8.1 changes that bring the start screen experience more in line with Windows
Phone are even nicer. The new item selection gesture (tap and hold) and the fact that
new apps don’t automatically appear on the start screen (only on the “app apps” screen)
are just like the phone, and make the system easier to deal with overall.</li>
<li>
The updates to WinRT XAML are extremely welcome – especially around data binding –
these are changes I’ll use in CSLA .NET right away.</li>
<li>
The added WinRT API capabilities demonstrate Microsoft’s commitment to rapidly maturing
what amounts to a Version 1 technology as rapidly as possible.</li>
<li>
The fact that Azure had no big announcements, because they’ve been continually releasing
their new stuff as it becomes available is wonderful! In fact, this whole “faster
release cadence” concept from Windows, Azure, and Visual Studio is (imo) a welcome
change, because it means that the overall .NET and Microsoft platform will be far
more competitive by being more agile.</li>
<li>
There was a serious emphasis on XAML, and most of the JavaScript content was web-focused,
not WinRT-focused – and I think this is good because it reflects the reality of the
Microsoft developer community. Most of us are .NET/XAML developers and if we’re going
to shift to WinRT someday in the future it’ll be via .NET/XAML. For my part, if I’m
forced to abandon .NET for JavaScript I’ll learn general JavaScript, not some Microsoft-specific
variation or library – but if I see a viable future for .NET in the WinRT world, then
I’ll continue to invest in .NET – and this conference was a <em>start</em> on Microsoft’s
part toward rebuilding a little trust in the future of .NET.</li>
<li>
The new 8” tablet form factor is way nicer than I’d expected. I had a Kindle Fire
and ultimately gave it to my son because I already have an eInk Kindle and couldn’t
see a good use for the Fire. But an 8” Win8 tablet is a whole different matter, because
it runs the Kindle app <em>and it runs Office</em> and WinRT apps so it is immediately
useful. The small screen means amazing battery life and light weight, and the ATOM
processor means it runs Win32 and WinRT apps – I’m really enjoying this <a href="http://www.engadget.com/2013/06/24/acer-iconia-w3-now-on-sale-in-the-us/">new
Acer device</a>!</li>
</ol>
<p>
The neutral:
</p>
<ol>
<li>
As I tweeted last week the one recurring bit of feedback I heard from people was disappointment
in the lack of WPF announcements or content. I’m not overly concerned about that,
because I view Windows Forms, Silverlight, and WPF as all being the same – they are
all in maintenance mode and Microsoft is just keeping them running. The same unprecedented
stability enjoyed by Windows Forms developers for the past 8 years is now the reality
for WPF too. Sure, this might be a little boring to be on an unchanging platform,
but the productivity is hard to beat!!</li>
<li>
Related to the lack of WPF content I want to suggest a different interpretation. WinRT
with .NET/XAML is (imo) the “future of WPF”. What we <em>really</em> need to see is
WinRT XAML continuing to rapidly evolve such that it becomes a natural progression
to move from WPF/Silverlight to WinRT at some point in the future. I am encouraged
by what was presented at Build in terms of the evolution of WinRT XAML, and if that
continues I think we’ll find that moving to WinRT will become pretty attractive at
some future time.</li>
<li>
There was some content on the use of WinRT to create business apps, and that content
was welcome. If-and-when Microsoft does fix the side-loading licensing issues so WinRT
becomes viable for business use it is nice to know that some serious thought has gone
into design and development of business apps on the new platform.</li>
</ol>
<p>
In conclusion, the overall vibe at the conference was positive. Attendees were, from
what I could see, enjoying the conference, the content, and the technology. Moreover,
I think Microsoft has taken a first small step toward rebuilding their relationship
with (what was once) the Microsoft developer community (not that Azure ever lost this
rapport, but the Windows client sure did). If they continue to build and foster this
rapport I think they can win back some confidence that there’s a future for .NET and/or
Windows on the client.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=3395dc25-66bf-43da-8814-3d1203d6d106" />Microsoft .NETWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=5a2db6bf-9503-4701-9d90-d6f0bdf47703http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,5a2db6bf-9503-4701-9d90-d6f0bdf47703.aspxRockford Lhotka

Mary
Jo reports that Windows 8 sales are roughly on par with Windows 7 sales. Which
is good news for Windows 8, because Microsoft said (at the time) that Windows 7 was
the fastest selling OS to that point.

She also points out that actual usage of Win8 isn’t terribly high at this
point – which isn’t at all surprising (see my blog post on if
Windows 8 is a success).

The real value of the numbers just provided by Microsoft is that they are an apples
to apples comparison between Win7 and Win8, and that they demonstrate that Win8 is
following roughly the same track as Win7 in terms of production and sales.

That’s good news, given that Win7 is (by nearly any measure) extremely successful,
and is considered by many people to be the best OS Microsoft has released. Windows
8 on an x86 machine can basically be viewed as a faster version of Windows 7, plus
the ability to run WinRT apps, and so I pretty much think of Windows 8 as a slight
improvement over the already excellent Windows 7.

As Mary Jo notes, we don’t know if the 100 million figure includes Windows RT. At
this point I’m not sure if that really matters – at least not from a business app
dev perspective. Windows RT can only run WinRT (Windows Runtime) apps, and the WinRT
dev platform is too new and immature to risk targeting it when building large enterprise
apps (not to mention the side-loading
cost issues).

At this point most organizations appear to be building new smart client apps using
WPF, and of course they continue to maintain a great many Windows Forms apps. The
strength of Windows 8, as I see it, is that it remains an extremely relevant and potent
business app platform via its desktop mode, which runs Win32/.NET apps at least as
well as its predecessor.

If Microsoft resolves the side-loading cost issues so licensing and deployment becomes
reasonable for small, medium, and large organizations I do think WinRT has a reasonable
shot at being the successor to Win32/.NET for business developers. In another version
or two it should stabilize and mature to the point that it is pretty comparable to
WPF, and thus is attractive and useful to C#/XAML developers. That’ll probably take
a couple years, which is also the timeframe that corporate IT groups will probably
be willing to consider upgrading from Windows 7 to Windows 8.

In summary: good Windows 8 sales today means that betting on WPF for smart client
development should be pretty safe, and will hopefully have a decent migration path
to WinRT in 2-3 years.

Good Windows 8 saleshttp://www.lhotka.net/weblog/PermaLink,guid,5a2db6bf-9503-4701-9d90-d6f0bdf47703.aspxhttp://www.lhotka.net/weblog/GoodWindows8Sales.aspx
Tue, 07 May 2013 04:30:54 GMT<p>
<a href="http://www.zdnet.com/microsoft-more-than-100-million-windows-8-licenses-sold-7000014957/">Mary
Jo reports</a> that Windows 8 sales are roughly on par with Windows 7 sales. Which
is good news for Windows 8, because Microsoft said (at the time) that Windows 7 was
the fastest selling OS to that point.
</p>
<p>
She also points out that actual <em>usage</em> of Win8 isn’t terribly high at this
point – which isn’t at all surprising (see my blog post on <a href="http://www.lhotka.net/weblog/IsWindows8ASuccess.aspx">if
Windows 8 is a success</a>).
</p>
<p>
The real value of the numbers just provided by Microsoft is that they are an apples
to apples comparison between Win7 and Win8, and that they demonstrate that Win8 is
following roughly the same track as Win7 in terms of production and sales.
</p>
<p>
That’s good news, given that Win7 is (by nearly any measure) extremely successful,
and is considered by many people to be the best OS Microsoft has released. Windows
8 on an x86 machine can basically be viewed as a faster version of Windows 7, plus
the ability to run WinRT apps, and so I pretty much think of Windows 8 as a slight
improvement over the already excellent Windows 7.
</p>
<p>
As Mary Jo notes, we don’t know if the 100 million figure includes Windows RT. At
this point I’m not sure if that really matters – at least not from a business app
dev perspective. Windows RT can only run WinRT (Windows Runtime) apps, and the WinRT
dev platform is too new and immature to risk targeting it when building large enterprise
apps (not to mention the <a href="http://www.lhotka.net/weblog/Windows8WinRTLicensingIdeas.aspx">side-loading
cost issues</a>).
</p>
<p>
At this point most organizations appear to be building new smart client apps using
WPF, and of course they continue to maintain a great many Windows Forms apps. The
strength of Windows 8, as I see it, is that it remains an extremely relevant and potent
business app platform via its desktop mode, which runs Win32/.NET apps at least as
well as its predecessor.
</p>
<p>
If Microsoft resolves the side-loading cost issues so licensing and deployment becomes
reasonable for small, medium, and large organizations I do think WinRT has a reasonable
shot at being the successor to Win32/.NET for business developers. In another version
or two it should stabilize and mature to the point that it is pretty comparable to
WPF, and thus is attractive and useful to C#/XAML developers. That’ll probably take
a couple years, which is also the timeframe that corporate IT groups will probably
be willing to consider upgrading from Windows 7 to Windows 8.
</p>
<p>
In summary: good Windows 8 sales today means that betting on WPF for smart client
development should be pretty safe, and will hopefully have a decent migration path
to WinRT in 2-3 years.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=5a2db6bf-9503-4701-9d90-d6f0bdf47703" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=81b1601f-bce0-42e5-8cc5-2e52de8076c3http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,81b1601f-bce0-42e5-8cc5-2e52de8076c3.aspxRockford Lhotka

I’ve now done four posts where I summarize Microsoft’s side-loading licensing scheme
in terms of just how it works, what it looks like from various business perspectives,
and why I think they have designed this scheme to compete with the wrong target (iPad
instead of HTML 5).

If you work for a large enterprise with EA/SA agreements and an IT staff that manages
all your domain-joined Windows 8 Enterprise workstations you can probably stop reading
now. You are the one demographic that is well-covered by the existing licensing model.

If you are a small or medium business, or an enterprise (such as a franchise or co-op
org) where you have lots of non-domain joined machines, machines that run Windows
8 Pro, Windows RT, or the lowly “Windows 8” basic edition, then read on.

After my first four posts I heard from community members and people inside Microsoft
– “ok tough guy, you’ve said what’s wrong, now how would you do it right?” (to paraphrase
of course ).

My first reaction is that this isn’t my job. If Microsoft wants to make WinRT unpalatable
for business developers so we all switch to cross-platform HTML 5/JavaScript (h5js)
then who am I to stop them? Besides, don’t they have high-paid experts to figure this
stuff out, and so why should I give my thoughts for free?

My second reaction is that from 2001-today I’ve had the pleasure of working with .NET,
and these have been the most enjoyable years of my professional career. Although TypeScript appears
to offer some reasonable wrapper around the horror that is JavaScript, I’d much prefer
it if Microsoft didn’t destroy the idea of building WinRT apps with XAML/C#/VB.

So here are my thoughts – though please keep in mind that I’m not a licensing expert,
nor did I stay at a Holiday Inn Express last night.

To be successful, WinRT licensing needs to address its real competitor: h5js and/or
WPF+ClickOnce. If WinRT is going to levy an additional licensing cost above those
technologies, then WinRT must have commensurate benefits to offset that cost.

What is the cost to deploy an h5js app? Effectively zero, because the app downloads
from a web deployment server into a browser. The browsers are all
free, there’s no per-workstation license to enable downloading HTML or JavaScript,
so the cost is essentially zero.

What is the cost to deploy a WPF app with ClickOnce? Effectively zero, because the
app downloads from a deployment server and is installed on the workstation through
a standardized ClickOnce client process. No per-workstation license is required –
as long as you have a legal copy of the OS, .NET (and thus ClickOne) are free.

I’ve already covered the costs of deploying WinRT apps in the current scheme in my
previous blog posts. Those costs can easily add up to thousands or even millions of
added dollars – just for the privilege of deploying your own app to your own workstations.

So does WinRT have benefits over h5js or WPF that make it work this added licensing
cost? Probably not at this time. It is a version 1 technology and so is less mature
than h5js or WPF. Unlike h5js it isn’t cross-platform, and unlike WPF it doesn’t have
a simple pre-built deployment technology like ClickOnce. It does have two benefits:
WinRT apps can run on ARM devices as well as Intel devices, and WinRT offers a superior
model for building touch-enabled apps. I’ll let you decide if those benefits are worth
thousands or millions of extra dollars.

Assuming we agree that WinRT isn’t good enough to justify the added licensing
fees over its competition, the question becomes how to license WinRT side-loading
in a competitive manner.

Microsoft has expressed the (imo) very valid concern that they don’t want to enable
the free-for-all side-loading model of the Android world. And I agree – the last thing
I want is for my kids to yet again be able to download random software from random
locations that are infested with viruses and malware. I really want control over
what gets into public stores. I want my software to be vetted when it comes
from public locations.

At the same time, I absolutely don’t want added cost or overhead or complexity for
apps coming from my corporate marketplaces. I’m in consulting, so the model must allow
for Magenic to have a marketplace for our employees, and our consultants must also
be able to leverage the marketplaces of our clients so we have access to their apps
while we’re working for them.

Thus far I’ve accumulated some requirements:

No per-device licensing fees

One device must be able to access multiple marketplaces

Public marketplaces must be controlled (or perhaps there is just the one Microsoft
Store)

People do work from home, where the “Windows 8” edition is most common, so it should
support side-loading as well

InTune is a fine idea for deployment, but it shouldn’t be the only option – customized/tailored
“marketplace” experiences should be possible

No per-device fees

Let’s start with this requirement. Microsoft doesn’t charge extra for us to use Windows
for business, and it makes no sense as to why they think they can charge an extra
tax for us to use WinRT for business. This includes discarding the $30/device fee
as well as not requiring the InTune per-device/per-month fee.

If InTune has enough other value people will buy it, but h5js and ClickOnce don’t
have a monthly fee, so WinRT needs a comparable model.

Multiple marketplaces

As I noted above, employees of a company like Magenic need access to the Magenic marketplace,
and to the marketplace of the company(ies) where they are working as consultants.
And one would hope we’d have access to the Microsoft Store as well! This implies a
way for each device to access multiple “stores” or marketplaces.

Public marketplaces

I’m rather neutral about public marketplaces beyond the Microsoft Store. My only requirement
here, is that if Microsoft did allow such a thing to occur then they should be able
to revoke any public marketplace’s “license” or “key” if that vendor becomes a source
(intentionally or unintentionally) for malware. The bar for any public marketplace
should be as high as the Microsoft Store in that regard.

Or perhaps a better solution is to make public stores legally liable for malware.
So it becomes possible for me to seek financial or legal recourse if a marketplace
allows malware to slip through onto my device?

Work from home

It is patently absurd to think that I can go to Best Buy and purchase a lowly Windows
RT tablet and it can side-load business apps, but the most common Windows 8 edition
(Windows 8) can’t be used to run my business apps. I can’t envision any justification
for this at all, so clearly this just needs to be fixed.

No InTune requirement

I understand the value of InTune – it does a lot of cool stuff, one of which is deployment.
But not everyone wants all that other stuff, and making InTune the only real ClickOnce
replacement makes WinRT uncompetitive. Again, h5js and ClickOnce have no monthly cost,
and WinRT needs a zero cost option as well.

The result

As a result I think the answer is to license deployment servers not client
devices.

And for public servers these licenses should be revokable so Microsoft can easily
shut down rogue public marketplaces. I’ll leave the public marketplace concept alone
for the rest of this discussion, as I’m much more interested in corporate marketplaces.

To make this work for a small business (think 2-500 employees) the cost of a deployment
server license/key must be quite low. A 5 person company might spend 10’s or low 100’s
of dollars by not beyond that. I can see how Microsoft might want the cost to scale
somewhat, so you could envision deployment server licenses working against a “registered
device” model. I honestly think Microsoft would be best served by not charging
an extra fee, but if they feel they must find a new revenue source perhaps it could
work like this:

<=100 devices $100

<=500 devices $500

<=1000 devices $1000

MSDN subscribers should get a <=10 device license as part of their subscription,
allowing for software development and testing.

EA/SA customers might get some deployment server license “for free” as part of their
negotiated contract.

Interestingly, Windows Phone 8 already has a corporate marketplace concept built into
the phone, where you can register your phone with a corporate marketplace. They (to
my knowledge) only support one marketplace, but the core idea is there.

To make this work, a server admin must be able to revoke the registration of a client
device (employee leaves, device stolen, etc.), and there should probably be a pre-built
WinRT app users can run to register their device with a marketplace (perhaps based
on access to an appropriate email domain – like WP8 again).

So a Magenic employee would run this WinRT device registration app and enter their
magenic.com email address. Perhaps this causes the marketplace server to send an email
to that address with a confirmation hyperlink. The user clicks that hyperlink to confirm
and the marketplace completes registration of that device, making the apps in that
marketplace available to the end user.

Conclusion

Again, I’m not a licensing expert. I’m simply looking at the competitive landscape
and trying to figure out how to make WinRT financially competitive with h5js and WPF+ClickOnce.
Assuming that WinRT has no incredible value proposition over its competitors (and
I don’t see that it does) then it must provide a cost-comparable licensing/deployment
model.

Given that h5js and WPF+ClickOnce have a zero licensing/deployment cost, the goal
should be for WinRT apps to have a zero licensing/deployment cost.

At the same time, I surely don’t want public marketplaces to come into being
without some substantial recourse and penalty for any such marketplace that
becomes a vector for malware.

I think something along the lines of what I’ve proposed here can achieve these goals,
and can make WinRT into a viable business development platform in the future. My guess
is that Microsoft has a few months, perhaps 18 at most, to make this happen (or at
least to lay out a clear roadmap) before business developers really start
migrating away from Windows toward h5js in an effort to ensure their careers remain
vibrant and healthy.

Windows 8 WinRT licensing ideashttp://www.lhotka.net/weblog/PermaLink,guid,81b1601f-bce0-42e5-8cc5-2e52de8076c3.aspxhttp://www.lhotka.net/weblog/Windows8WinRTLicensingIdeas.aspx
Tue, 05 Mar 2013 20:33:53 GMT<p>
I’ve now done four posts where I summarize Microsoft’s side-loading licensing scheme
in terms of just how it works, what it looks like from various business perspectives,
and why I think they have designed this scheme to compete with the wrong target (iPad
instead of HTML 5).
</p>
<ol>
<li>
<a title="Cost to enable side-loading on a Windows 8 device" href="http://www.lhotka.net/weblog/CostToEnableSideloadingOnAWindows8Device.aspx">Cost
to enable side-loading on a Windows 8 device</a>
</li>
<li>
<a title="Windows 8 LOB deployment ‘story’" href="http://www.lhotka.net/weblog/Windows8LOBDeploymentLsquostoryrsquo.aspx">Windows
8 LOB deployment ‘story’</a>
</li>
<li>
<a title="Perspectives on WinRT app licensing" href="http://www.lhotka.net/weblog/PerspectivesOnWinRTAppLicensing.aspx">Perspectives
on WinRT app licensing</a>
</li>
<li>
<a title="Windows 8 WinRT sideloading update" href="http://www.lhotka.net/weblog/Windows8WinRTSideloadingUpdate.aspx">Windows
8 WinRT sideloading update</a>
</li>
</ol>
<p>
If you work for a large enterprise with EA/SA agreements and an IT staff that manages
all your domain-joined Windows 8 Enterprise workstations you can probably stop reading
now. You are the one demographic that is well-covered by the existing licensing model.
</p>
<p>
If you are a small or medium business, or an enterprise (such as a franchise or co-op
org) where you have lots of non-domain joined machines, machines that run Windows
8 Pro, Windows RT, or the lowly “Windows 8” basic edition, then read on.
</p>
<p>
After my first four posts I heard from community members and people inside Microsoft
– “ok tough guy, you’ve said what’s wrong, now how would you do it right?” (to paraphrase
of course <img class="wlEmoticon wlEmoticon-smile" style="border-top-style: none; border-left-style: none; border-bottom-style: none; border-right-style: none" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8-WinRT-licensing-ideas_ABFF/wlEmoticon-smile_2.png" /> ).
</p>
<p>
My first reaction is that this isn’t my job. If Microsoft wants to make WinRT unpalatable
for business developers so we all switch to cross-platform HTML 5/JavaScript (h5js)
then who am I to stop them? Besides, don’t they have high-paid experts to figure this
stuff out, and so why should I give my thoughts for free?
</p>
<p>
My second reaction is that from 2001-today I’ve had the pleasure of working with .NET,
and these have been the most enjoyable years of my professional career. Although <a href="http://typescriptlang.org/">TypeScript</a> appears
to offer some reasonable wrapper around the horror that is JavaScript, I’d much prefer
it if Microsoft <em>didn’t</em> destroy the idea of building WinRT apps with XAML/C#/VB.
</p>
<p>
So here are my thoughts – though please keep in mind that I’m not a licensing expert,
nor did I stay at a Holiday Inn Express last night.
</p>
<p>
To be successful, WinRT licensing needs to address its real competitor: h5js and/or
WPF+ClickOnce. If WinRT is going to levy an additional licensing cost above those
technologies, then WinRT <em>must</em> have commensurate benefits to offset that cost.
</p>
<p>
What is the cost to deploy an h5js app? Effectively zero, because the app downloads
from a <strike>web</strike> deployment server into a browser. The browsers are all
free, there’s no per-workstation license to enable downloading HTML or JavaScript,
so the cost is essentially zero.
</p>
<p>
What is the cost to deploy a WPF app with ClickOnce? Effectively zero, because the
app downloads from a deployment server and is installed on the workstation through
a standardized ClickOnce client process. No per-workstation license is required –
as long as you have a legal copy of the OS, .NET (and thus ClickOne) are free.
</p>
<p>
I’ve already covered the costs of deploying WinRT apps in the current scheme in my
previous blog posts. Those costs can easily add up to thousands or even millions of
added dollars – just for the privilege of deploying your own app to your own workstations.
</p>
<p>
So does WinRT have benefits over h5js or WPF that make it work this added licensing
cost? Probably not at this time. It is a version 1 technology and so is less mature
than h5js or WPF. Unlike h5js it isn’t cross-platform, and unlike WPF it doesn’t have
a simple pre-built deployment technology like ClickOnce. It does have two benefits:
WinRT apps can run on ARM devices as well as Intel devices, and WinRT offers a superior
model for building touch-enabled apps. I’ll let you decide if those benefits are worth
thousands or millions of extra dollars.
</p>
<p>
Assuming we agree that WinRT <em>isn’t</em> good enough to justify the added licensing
fees over its competition, the question becomes how to license WinRT side-loading
in a competitive manner.
</p>
<p>
Microsoft has expressed the (imo) very valid concern that they don’t want to enable
the free-for-all side-loading model of the Android world. And I agree – the last thing
I want is for my kids to yet again be able to download random software from random
locations that are infested with viruses and malware. I <em>really want control</em> over
what gets into public stores. I <em>want</em> my software to be vetted when it comes
from public locations.
</p>
<p>
At the same time, I absolutely don’t want added cost or overhead or complexity for
apps coming from my corporate marketplaces. I’m in consulting, so the model must allow
for Magenic to have a marketplace for our employees, and our consultants must also
be able to leverage the marketplaces of our clients so we have access to their apps
while we’re working for them.
</p>
<p>
Thus far I’ve accumulated some requirements:
</p>
<ol>
<li>
No per-device licensing fees</li>
<li>
One device must be able to access multiple marketplaces</li>
<li>
Public marketplaces must be controlled (or perhaps there is just the one Microsoft
Store)</li>
<li>
People do work from home, where the “Windows 8” edition is most common, so it should
support side-loading as well</li>
<li>
InTune is a fine idea for deployment, but it shouldn’t be the only option – customized/tailored
“marketplace” experiences should be possible</li>
</ol>
<p>
<strong>No per-device fees</strong>
</p>
<p>
Let’s start with this requirement. Microsoft doesn’t charge extra for us to use Windows
for business, and it makes no sense as to why they think they can charge an extra
tax for us to use WinRT for business. This includes discarding the $30/device fee
as well as not <em>requiring</em> the InTune per-device/per-month fee.
</p>
<p>
If InTune has enough other value people will buy it, but h5js and ClickOnce don’t
have a monthly fee, so WinRT needs a comparable model.
</p>
<p>
<strong>Multiple marketplaces</strong>
</p>
<p>
As I noted above, employees of a company like Magenic need access to the Magenic marketplace,
and to the marketplace of the company(ies) where they are working as consultants.
And one would hope we’d have access to the Microsoft Store as well! This implies a
way for each device to access multiple “stores” or marketplaces.
</p>
<p>
<strong>Public marketplaces</strong>
</p>
<p>
I’m rather neutral about public marketplaces beyond the Microsoft Store. My only requirement
here, is that if Microsoft did allow such a thing to occur then they should be able
to revoke any public marketplace’s “license” or “key” if that vendor becomes a source
(intentionally or unintentionally) for malware. The bar for any public marketplace
should be as high as the Microsoft Store in that regard.
</p>
<p>
Or perhaps a better solution is to make public stores legally liable for malware.
So it becomes possible for me to seek financial or legal recourse if a marketplace
allows malware to slip through onto my device?
</p>
<p>
<strong>Work from home</strong>
</p>
<p>
It is patently absurd to think that I can go to Best Buy and purchase a lowly Windows
RT tablet and it can side-load business apps, but the most common Windows 8 edition
(Windows 8) can’t be used to run my business apps. I can’t envision any justification
for this at all, so clearly this just needs to be fixed.
</p>
<p>
<strong>No InTune requirement</strong>
</p>
<p>
I understand the value of InTune – it does a lot of cool stuff, one of which is deployment.
But not everyone wants all that other stuff, and making InTune the only real ClickOnce
replacement makes WinRT uncompetitive. Again, h5js and ClickOnce have no monthly cost,
and WinRT needs a zero cost option as well.
</p>
<p>
<strong>The result</strong>
</p>
<p>
As a result I think the answer is to license <em>deployment servers</em> not client
devices.
</p>
<p>
And for public servers these licenses should be revokable so Microsoft can easily
shut down rogue public marketplaces. I’ll leave the public marketplace concept alone
for the rest of this discussion, as I’m much more interested in corporate marketplaces.
</p>
<p>
To make this work for a small business (think 2-500 employees) the cost of a deployment
server license/key must be quite low. A 5 person company might spend 10’s or low 100’s
of dollars by not beyond that. I can see how Microsoft might want the cost to scale
somewhat, so you could envision deployment server licenses working against a “registered
device” model. I honestly think Microsoft would be best served by <em>not</em> charging
an extra fee, but if they feel they must find a new revenue source perhaps it could
work like this:
</p>
<ul>
<li>
&lt;=100 devices $100</li>
<li>
&lt;=500 devices $500</li>
<li>
&lt;=1000 devices $1000</li>
</ul>
<p>
MSDN subscribers should get a &lt;=10 device license as part of their subscription,
allowing for software development and testing.
</p>
<p>
EA/SA customers might get some deployment server license “for free” as part of their
negotiated contract.
</p>
<p>
Interestingly, Windows Phone 8 already has a corporate marketplace concept built into
the phone, where you can register your phone with a corporate marketplace. They (to
my knowledge) only support one marketplace, but the core idea is there.
</p>
<p>
To make this work, a server admin must be able to revoke the registration of a client
device (employee leaves, device stolen, etc.), and there should probably be a pre-built
WinRT app users can run to register their device with a marketplace (perhaps based
on access to an appropriate email domain – like WP8 again).
</p>
<p>
So a Magenic employee would run this WinRT device registration app and enter their
magenic.com email address. Perhaps this causes the marketplace server to send an email
to that address with a confirmation hyperlink. The user clicks that hyperlink to confirm
and the marketplace completes registration of that device, making the apps in that
marketplace available to the end user.
</p>
<p>
<strong>Conclusion</strong>
</p>
<p>
Again, I’m not a licensing expert. I’m simply looking at the competitive landscape
and trying to figure out how to make WinRT financially competitive with h5js and WPF+ClickOnce.
Assuming that WinRT has no incredible value proposition over its competitors (and
I don’t see that it does) then it <em>must</em> provide a cost-comparable licensing/deployment
model.
</p>
<p>
Given that h5js and WPF+ClickOnce have a zero licensing/deployment cost, the goal
should be for WinRT apps to have a zero licensing/deployment cost.
</p>
<p>
At the same time, I surely don’t want <em>public</em> marketplaces to come into being
without some <em>substantial</em> recourse and penalty for any such marketplace that
becomes a vector for malware.
</p>
<p>
I think something along the lines of what I’ve proposed here can achieve these goals,
and can make WinRT into a viable business development platform in the future. My guess
is that Microsoft has a few months, perhaps 18 at most, to make this happen (or at
least to lay out a clear roadmap) before business developers <em>really</em> start
migrating away from Windows toward h5js in an effort to ensure their careers remain
vibrant and healthy.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=81b1601f-bce0-42e5-8cc5-2e52de8076c3" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=a5a34a07-24cd-43a6-a573-42a165b8afd3http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,a5a34a07-24cd-43a6-a573-42a165b8afd3.aspxRockford Lhotka

If you’ve followed my blog recently you know I’ve done a lot of research into the
licensing around deployment (side-loading) of business apps on Windows 8 (Windows
Runtime aka WinRT).

First, I’ve had some interesting conversations with a few people at Microsoft. Some
understand the issue, others just don’t get it. If you think this is an issue
I suggest you have conversations with any Microsoft people you know because that’ll
help educate and pressure them to fix the problem.

As an aside, it is hard to talk to the right people at Microsoft because the Windows
Division owns all this stuff and they don’t talk to developers. In fact, they are
almost constantly behind what’s known as the “veil of silence” – essentially unable
to discuss anything interesting without risk of being fired. This unwillingness to
talk to developers on your own platform is pretty ridiculous, and makes it virtually
impossible to generate enthusiasm for building apps on the platform. I have hopes
that Sinofsky’s departure from Microsoft will eventually allow them to come to their
senses…

Second, I’ve had a number of people ask if I think Windows and/or Microsoft is done
for on the client, at least in terms of business software development.

Although I think that’s a very real possibility, given just a bit more maturity in
the HTML 5/JavaScript (h5js) space, I don’t think the Windows client is a lost cause
yet either.

The thing about the licensing/deployment side-loading story is that Microsoft has
it set up to be perfectly acceptable to large enterprises. Those orgs almost certainly
already have an EA/SA and use SCCM and run domain-joined Windows Enterprise machines.
Their Windows RT or other Win8 mobile devices are covered by the SA and/or companion
device licensing. So their only incremental cost is the $4/mo/device InTune cost.
That’s extremely comparable to the cost of MDM products for iPad/Android devices.

Where the Microsoft story falls short is in the SMB (small-medium business) space
where businesses probably don’t have those bigger contracts and IT infrastructure.
That’s where the incremental costs start to add up pretty fast (as per my previous
blog posts and Excel cost calculator). Of course the long
tail suggests that there are a lot more SMB orgs than enterprise orgs, so the
poor story for this segment of the market is pretty devastating.

I keep posting and talking bluntly about the licensing/deployment story because I
think we all need to be aware of what’s going on. We all need to know it so we can
make near-term decisions regarding the use of WPF, h5js, and/or WinRT. And because
those of us who enjoy building smart client Windows apps can pressure Microsoft into
fixing the licensing story before it is too late.

Finally, speaking of “too late”, that’s a slippery phrase.

Businesses are mostly just now upgrading to Windows 7, and won’t go to Windows 8 for
2-4 more years. So in a sense you can argue that Microsoft has a lot of time to fix
the side-loading story, because almost no one is going to care about this for a long
time anyway.

On the other hand, the developer community tends to move a bit faster. We’re
a fickle bunch. If we don’t perceive WinRT as a viable future platform for business
apps then we’ll start retooling our skills to something else in order to preserve
our careers. That won’t take 4 years. I suspect Microsoft has less than 2 years to
get developer buy-in to WinRT or the siren call of h5js will become too much to bear.

At the moment of course, h5js has no rational or consistent smart client deployment
story either. Although its ability to support smart client business development is
maturing pretty fast, the only widespread deployment model still requires a real-time
connection from the client device to a web server. Once the industry settles on a
way to package and deploy “h5js apps” for offline use (and I believe that _will_ happen)
then Microsoft’s ability to generate enthusiasm for WinRT becomes much harder.

I see this as a race. Can Microsoft generate enthusiasm around WinRT in the business
developer world (by fixing the side-loading issue and by actually talking
to developers at all)? And can they do that faster than the h5js world can
devise and settle on a reliable smart client story of their own (because they already
have developer enthusiasm).

In short:

Microsoft has the technical issues pretty much solved, but seems intent on alienating
business developers.

The h5js world has a lot of developer enthusiasm, but has yet to tackle or solve some
critical technical issues

It’ll be fun to see what happens over the next couple years.

Windows 8 WinRT sideloading updatehttp://www.lhotka.net/weblog/PermaLink,guid,a5a34a07-24cd-43a6-a573-42a165b8afd3.aspxhttp://www.lhotka.net/weblog/Windows8WinRTSideloadingUpdate.aspx
Tue, 26 Feb 2013 18:21:15 GMT<p>
If you’ve followed my blog recently you know I’ve done a lot of research into the
licensing around deployment (side-loading) of business apps on Windows 8 (Windows
Runtime aka WinRT).
</p>
<ol>
<li>
<a href="http://www.lhotka.net/weblog/CostToEnableSideloadingOnAWindows8Device.aspx">http://www.lhotka.net/weblog/CostToEnableSideloadingOnAWindows8Device.aspx</a>
</li>
<li>
<a href="http://www.lhotka.net/weblog/Windows8LOBDeploymentLsquostoryrsquo.aspx">http://www.lhotka.net/weblog/Windows8LOBDeploymentLsquostoryrsquo.aspx</a>
</li>
<li>
<a href="http://www.lhotka.net/weblog/PerspectivesOnWinRTAppLicensing.aspx">http://www.lhotka.net/weblog/PerspectivesOnWinRTAppLicensing.aspx</a>
</li>
</ol>
<p>
As a result of this two things have happened.
</p>
<p>
First, I’ve had some interesting conversations with a few people at Microsoft. Some
understand the issue, others just don’t get it. If <em>you</em> think this is an issue
I suggest you have conversations with any Microsoft people you know because that’ll
help educate and pressure them to fix the problem.
</p>
<blockquote>
<p>
<em>As an aside, it is hard to talk to the right people at Microsoft because the Windows
Division owns all this stuff and they don’t talk to developers. In fact, they are
almost constantly behind what’s known as the “veil of silence” – essentially unable
to discuss anything interesting without risk of being fired. This unwillingness to
talk to developers on your own platform is pretty ridiculous, and makes it virtually
impossible to generate enthusiasm for building apps on the platform. I have hopes
that Sinofsky’s departure from Microsoft will eventually allow them to come to their
senses…</em>
</p>
</blockquote>
<p>
Second, I’ve had a number of people ask if I think Windows and/or Microsoft is done
for on the client, at least in terms of business software development.
</p>
<p>
Although I think that’s a very real possibility, given just a bit more maturity in
the HTML 5/JavaScript (h5js) space, I don’t think the Windows client is a lost cause
yet either.
</p>
<p>
The thing about the licensing/deployment side-loading story is that Microsoft has
it set up to be perfectly acceptable to large enterprises. Those orgs almost certainly
already have an EA/SA and use SCCM and run domain-joined Windows Enterprise machines.
Their Windows RT or other Win8 mobile devices are covered by the SA and/or companion
device licensing. So their only incremental cost is the $4/mo/device InTune cost.
That’s extremely comparable to the cost of MDM products for iPad/Android devices.
</p>
<p>
Where the Microsoft story falls short is in the SMB (small-medium business) space
where businesses probably don’t have those bigger contracts and IT infrastructure.
That’s where the incremental costs start to add up pretty fast (as per my previous
blog posts and Excel cost calculator). Of course the <a href="http://en.wikipedia.org/wiki/The_Long_Tail">long
tail</a> suggests that there are a lot more SMB orgs than enterprise orgs, so the
poor story for this segment of the market is pretty devastating.
</p>
<p>
I keep posting and talking bluntly about the licensing/deployment story because I
think we all need to be aware of what’s going on. We all need to know it so we can
make near-term decisions regarding the use of WPF, h5js, and/or WinRT. And because
those of us who enjoy building smart client Windows apps can pressure Microsoft into
fixing the licensing story before it is too late.
</p>
<p>
Finally, speaking of “too late”, that’s a slippery phrase.
</p>
<p>
Businesses are mostly just now upgrading to Windows 7, and won’t go to Windows 8 for
2-4 more years. So in a sense you can argue that Microsoft has a lot of time to fix
the side-loading story, because almost no one is going to care about this for a long
time anyway.
</p>
<p>
On the other hand, the <em>developer community</em> tends to move a bit faster. We’re
a fickle bunch. If we don’t perceive WinRT as a viable future platform for business
apps then we’ll start retooling our skills to something else in order to preserve
our careers. That won’t take 4 years. I suspect Microsoft has less than 2 years to
get developer buy-in to WinRT or the siren call of h5js will become too much to bear.
</p>
<p>
At the moment of course, h5js has no rational or consistent smart client deployment
story either. Although its ability to support smart client business development is
maturing pretty fast, the only widespread deployment model still requires a real-time
connection from the client device to a web server. Once the industry settles on a
way to package and deploy “h5js apps” for offline use (and I believe that _will_ happen)
then Microsoft’s ability to generate enthusiasm for WinRT becomes much harder.
</p>
<p>
I see this as a race. Can Microsoft generate enthusiasm around WinRT in the business
developer world (by fixing the side-loading issue and by <strong>actually talking
to developers at all</strong>)? And can they do that faster than the h5js world can
devise and settle on a reliable smart client story of their own (because they already
have developer enthusiasm).
</p>
<p>
In short:
</p>
<ol>
<li>
Microsoft has the technical issues pretty much solved, but seems intent on alienating
business developers.</li>
<li>
The h5js world has a lot of developer enthusiasm, but has yet to tackle or solve some
critical technical issues</li>
</ol>
<p>
It’ll be fun to see what happens over the next couple years.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=a5a34a07-24cd-43a6-a573-42a165b8afd3" />h5jsWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=86b24176-a39c-4e67-8e97-1c5705ed1388http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,86b24176-a39c-4e67-8e97-1c5705ed1388.aspxRockford Lhotka

Another alternative is to install the app onto the Surface device via PowerShell.
This won’t attach the debugger, but is often an appropriate solution for people who
are just testing the app (QA testers, colleagues willing to provide feedback, etc.).

This is a multi-step process. At a high level it goes like this:

Developer packages the WinRT app to a folder on their hard drive, then puts the package
on a network share or USB key, etc.

Tester unlocks PowerShell on their device (this is a one-time thing)

Tester gets the WinRT app package and runs a PowerShell script to install the app
on their device

Creating the Package

The developer needs to create a distributable package for the app. This is done by
right-clicking on the WinRT project in the Visual Studio solution explorer, and choosing
Store –> Create App Packages.

This brings up the Create App Package wizard. The first question is whether you want
to deploy the the store, and the answer in this case is No.

Next, you’ll be asked where to create the package, how to create the package version
number (different from the app version number) and what platforms to target.

When the Create button is clicked, the project is built and packaged, with the results
placed in the specified folder.

The top level folder contains an appxupload file that you can safely ignore (it is
used for uploads to the store). It also contains a sub-folder with the actual app
package.

These are the files you must make available to the tester. You can put these files
on a network share, a USB key, a SkyDrive folder, or any other location where the
tester can gain access. The Add-AppDevPackage.ps1 file is the PowerShell script the
tester will run to install the app.

Unlocking PowerShell

The tester’s device must be able to execute PowerShell scripts before they can install
the app. By default PowerShell has security settings that prevent scripts from executing.
This TechNet article discusses
running PowerShell scripts. In summary, you need to open PowerShell as Admin and run
this command:

Set-ExecutionPolicy unrestricted

Be aware that this allows execution of any script, so you do assume some risk by enabling
this policy.

Once this has been done your test device is now able to install WinRT apps by executing
the PowerShell script generated by Visual Studio.

Installing the App

On the test device you must have access to the contents of the package folder created
by the developer in Visual Studio. You might get those files from a network share,
a USB key, or other location.

Simply execute the Add-AppDevPackage.ps1 file in PowerShell to install the app.

The script will ask permission to run.

If this device does not have a side-loading unlock key (MAK or developer key), you
will be asked if you want to get a developer key. You should answer yes and walk through
the wizard to get a developer key for this device. This step will require you to enter
your Microsoft Account email address and password. The resulting key will expire after
a short period of time (currently three months).

The PowerShell script will then ask for permission to install the certificate for
the app. If you’ve already installed the certificate (perhaps you are installing a
newer version of the same app) the script will skip this step.

Once the certificate is installed, the script will install the WinRT app itself.

At this point the WinRT app is installed and its tile should appear on the start screen
along with all other apps installed on this device.

The user may now run the app like any other app.

Once the developer key for this device expires the app will stop working. Obviously
the intent of this installation approach isn’t for the user to run the app forever,
but rather so they can test it and provide feedback during the development process.

Testing a WinRT app on a Surface RThttp://www.lhotka.net/weblog/PermaLink,guid,86b24176-a39c-4e67-8e97-1c5705ed1388.aspxhttp://www.lhotka.net/weblog/TestingAWinRTAppOnASurfaceRT.aspx
Thu, 20 Dec 2012 18:06:59 GMT<p>
A colleague of mine at Magenic recently posted on how to <a href="http://elybob.wordpress.com/2012/12/19/step-by-step-to-deploying-app-to-surface/">deploy
and debug a WinRT app on a Surface RT</a>.
</p>
<p>
Another alternative is to install the app onto the Surface device via PowerShell.
This won’t attach the debugger, but is often an appropriate solution for people who
are just testing the app (QA testers, colleagues willing to provide feedback, etc.).
</p>
<p>
This is a multi-step process. At a high level it goes like this:
</p>
<ol>
<li>
Developer packages the WinRT app to a folder on their hard drive, then puts the package
on a network share or USB key, etc.</li>
<li>
Tester unlocks PowerShell on their device (this is a one-time thing)</li>
<li>
Tester gets the WinRT app package and runs a PowerShell script to install the app
on their device</li>
</ol>
<h3>Creating the Package
</h3>
<p>
The developer needs to create a distributable package for the app. This is done by
right-clicking on the WinRT project in the Visual Studio solution explorer, and choosing
Store –&gt; Create App Packages.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_2.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb.png" width="434" height="72" /></a>
</p>
<p>
This brings up the Create App Package wizard. The first question is whether you want
to deploy the the store, and the answer in this case is No.
</p>
<p>
Next, you’ll be asked where to create the package, how to create the package version
number (different from the app version number) and what platforms to target.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_4.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_1.png" width="374" height="305" /></a>
</p>
<p>
The Neutral architecture in Release (Any CPU) allows testing on Intel and ARM devices.
</p>
<p>
When the Create button is clicked, the project is built and packaged, with the results
placed in the specified folder.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_6.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_2.png" width="372" height="302" /></a>
</p>
<p>
The top level folder contains an appxupload file that you can safely ignore (it is
used for uploads to the store). It also contains a sub-folder with the actual app
package.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_8.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_3.png" width="374" height="90" /></a>
</p>
<p>
These are the files you must make available to the tester. You can put these files
on a network share, a USB key, a SkyDrive folder, or any other location where the
tester can gain access. The Add-AppDevPackage.ps1 file is the PowerShell script the
tester will run to install the app.
</p>
<h3>Unlocking PowerShell
</h3>
<p>
The tester’s device must be able to execute PowerShell scripts before they can install
the app. By default PowerShell has security settings that prevent scripts from executing.
This <a href="http://technet.microsoft.com/en-us/library/cc764242.aspx">TechNet article</a> discusses
running PowerShell scripts. In summary, you need to open PowerShell as Admin and run
this command:
</p>
<blockquote>
<p>
Set-ExecutionPolicy unrestricted
</p>
</blockquote>
<p>
Be aware that this allows execution of any script, so you do assume some risk by enabling
this policy.
</p>
<p>
Once this has been done your test device is now able to install WinRT apps by executing
the PowerShell script generated by Visual Studio.
</p>
<h3>Installing the App
</h3>
<p>
On the test device you must have access to the contents of the package folder created
by the developer in Visual Studio. You might get those files from a network share,
a USB key, or other location.
</p>
<p>
Simply execute the Add-AppDevPackage.ps1 file in PowerShell to install the app.
</p>
<p>
The script will ask permission to run.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_10.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_4.png" width="495" height="70" /></a>
</p>
<p>
If this device does not have a side-loading unlock key (MAK or developer key), you
will be asked if you want to get a developer key. You should answer yes and walk through
the wizard to get a developer key for this device. This step will require you to enter
your Microsoft Account email address and password. The resulting key will expire after
a short period of time (currently three months).
</p>
<p>
The PowerShell script will then ask for permission to install the certificate for
the app. If you’ve already installed the certificate (perhaps you are installing a
newer version of the same app) the script will skip this step.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_14.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_6.png" width="493" height="66" /></a>
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_12.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_5.png" width="491" height="96" /></a>
</p>
<p>
Once the certificate is installed, the script will install the WinRT app itself.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_18.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Testing-a-WinRT-app-on-a-Surface-RT_A2E8/image_thumb_8.png" width="492" height="33" /></a>
</p>
<p>
At this point the WinRT app is installed and its tile should appear on the start screen
along with all other apps installed on this device.
</p>
<p>
The user may now run the app like any other app.
</p>
<p>
Once the developer key for this device expires the app will stop working. Obviously
the intent of this installation approach isn’t for the user to run the app forever,
but rather so they can test it and provide feedback during the development process.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=86b24176-a39c-4e67-8e97-1c5705ed1388" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=899d1465-56d6-4cc6-9de5-6eb98d97722chttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,899d1465-56d6-4cc6-9de5-6eb98d97722c.aspxRockford Lhotka

The Silverlight.net web site is apparently now gone, merged into the broader msdn.com
ecosystem (where it belonged in the first place imo):

As we’ve known now for a long time, Silverlight is “dead”. It is in support mode and
will be for a decade.

Just like Windows Forms has been since 2005, and WPF is now as well (do you really
think Microsoft is going to divert money from WinRT to do anything with WPF
at this point??? If so I’ve got this beachfront property for sale…).

As an aside, ASP.NET Web Forms also “died” in 2005, but recently got a major infusion
of money in .NET 4.5 – showing that even a “dead” technology can receive a big cash
investment sometimes – though it still isn’t clear that this will be enough to breath
any new life into Web Forms for most organizations. I suspect it is more likely that
this recent investment will just allow organizations with massive Web Forms sites
to keep them limping along for another 5-10 years.

If a technology is defined as “dead” when its vendor stops enhancing it and starts
maintaining it while they put most of their money into the future, then I must say
that I’ve spent pretty much my entire ~25 year career working on dead technologies.
And it has been fun!

Although some of us tech geeks like to jump to the next potential upcoming
thing, the people who actually fund software projects rarely want to accept that kind
of risk. They generally prefer to build applications on stable technology.
Most stable technology is “dead” or “dying” based on this idea of “live” technology
being rapidly changing and evolving.

Obviously there’s a fine line here.

Target stable technology that is too old and you really are in trouble. Windows Forms
is an example of this, because its underlying technology has no migration path to
a WinRT future. Although a lot of organizations have massive investments
in Windows Forms, I would hope that they’d shy away from starting new development
on this extremely stable, but now too old, technology.

Target stable technology that is new, but old enough to be stable and life is generally
pretty good. WPF and Silverlight (for smart clients, not for cross-platform RIA) are
examples of this. The reason is that these technologies (especially Silverlight) have
a good migration story to a WinRT future. A lot of organizations are investing in
WPF, and that’s good. But I’d be shocked if Microsoft invests anything in WPF going
forward – its future is the one Windows Forms has enjoyed since 2005 – stable maintenance
of the technology. Perfect for building critical business apps. Organizations
also have large investments in Silverlight, and as long as the intent was smart client
development (not cross-platform RIA) it seems to me that they are in the exact same
place as everyone using WPF. Arguably better, because Silverlight is much closer to
WinRT than WPF.

If you are using Silverlight for cross-platform rich web development, then I do agree
that the news is not good. The current alternative appears to be HTML 5, though it
is also clear that this is an expensive alternative with an unsure future. Just like
every other silver bullet to write once and run anywhere, I think you have to go into
such a venture expecting a lot of cost and pain. There’s no widely successful example
in the history of computing that indicates otherwise…

The final option is to target “live” technologies. You know, the ones where vendors are dumping
huge amounts of money, and where the technology and platform are changing rapidly.
Things like HTML 5 and WinRT are examples of this. As a tech geek I love it
when organizations want to do this sort of thing, because the challenge is high and
we all get to learn a lot of new stuff. Of course the development costs are also quite
high because we’re getting paid to learn this new stuff. And the overall costs for
the software are high because the technology/platform isn’t stable and the app probably
needs to be rewritten (in whole or part) every few months to deal with platform changes.

Some organizations are willing to accept the costs and inconvenience associated with
using “live” technologies. But most organizations don’t have the time or money or
risk tolerance, and are far better off targeting “dead” technologies like WPF and
Silverlight. They just need to be careful to have strategic migration plans so they
can get off those technologies before they reach the point of where Windows Forms
is today.

Silverlight is &ldquo;dead&rdquo;http://www.lhotka.net/weblog/PermaLink,guid,899d1465-56d6-4cc6-9de5-6eb98d97722c.aspxhttp://www.lhotka.net/weblog/SilverlightIsLdquodeadrdquo.aspx
Fri, 07 Dec 2012 17:23:33 GMT<p>
The Silverlight.net web site is apparently now gone, merged into the broader msdn.com
ecosystem (where it belonged in the first place imo):
</p>
<p>
<a title="http://www.zdnet.com/microsoft-pulls-the-plug-on-its-silverlight-net-site-7000008494/" href="http://www.zdnet.com/microsoft-pulls-the-plug-on-its-silverlight-net-site-7000008494/">http://www.zdnet.com/microsoft-pulls-the-plug-on-its-silverlight-net-site-7000008494/</a>
</p>
<p>
As we’ve known now for a long time, Silverlight is “dead”. It is in support mode and
will be for a decade.
</p>
<p>
Just like Windows Forms has been since 2005, and WPF is now as well (do you really
think Microsoft is going to divert money from WinRT to do <em>anything</em> with WPF
at this point??? If so I’ve got this beachfront property for sale…).
</p>
<blockquote>
<p>
<em>As an aside, ASP.NET Web Forms also “died” in 2005, but recently got a major infusion
of money in .NET 4.5 – showing that even a “dead” technology can receive a big cash
investment sometimes – though it still isn’t clear that this will be enough to breath
any new life into Web Forms for most organizations. I suspect it is more likely that
this recent investment will just allow organizations with massive Web Forms sites
to keep them limping along for another 5-10 years.</em>
</p>
</blockquote>
<p>
If a technology is defined as “dead” when its vendor stops enhancing it and starts
maintaining it while they put most of their money into the future, then I must say
that I’ve spent pretty much my entire ~25 year career working on dead technologies.
And it has been fun! <img class="wlEmoticon wlEmoticon-smile" style="border-top-style: none; border-left-style: none; border-bottom-style: none; border-right-style: none" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Silverlight-is-dead_9AEB/wlEmoticon-smile_2.png" />
</p>
<p>
Although some of us tech geeks like to jump to the next <em>potential</em> upcoming
thing, the people who actually fund software projects rarely want to accept that kind
of risk. They generally <em>prefer</em> to build applications on stable technology.
Most stable technology is “dead” or “dying” based on this idea of “live” technology
being rapidly changing and evolving.
</p>
<p>
Obviously there’s a fine line here.
</p>
<p>
Target stable technology that is too old and you really are in trouble. Windows Forms
is an example of this, because its underlying technology has no migration path to
a WinRT future. Although a <em>lot</em> of organizations have massive investments
in Windows Forms, I would hope that they’d shy away from starting new development
on this extremely stable, but now too old, technology.
</p>
<p>
Target stable technology that is new, but old enough to be stable and life is generally
pretty good. WPF and Silverlight (for smart clients, not for cross-platform RIA) are
examples of this. The reason is that these technologies (especially Silverlight) have
a good migration story to a WinRT future. A lot of organizations are investing in
WPF, and that’s good. But I’d be shocked if Microsoft invests anything in WPF going
forward – its future is the one Windows Forms has enjoyed since 2005 – stable maintenance
of the technology. <em>Perfect</em> for building critical business apps. Organizations
also have large investments in Silverlight, and as long as the intent was smart client
development (not cross-platform RIA) it seems to me that they are in the exact same
place as everyone using WPF. Arguably better, because Silverlight is much closer to
WinRT than WPF.
</p>
<p>
<a title="http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx" href="http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx">http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx</a>
</p>
<p>
If you are using Silverlight for cross-platform rich web development, then I do agree
that the news is not good. The current alternative appears to be HTML 5, though it
is also clear that this is an expensive alternative with an unsure future. Just like
every other silver bullet to write once and run anywhere, I think you have to go into
such a venture expecting a lot of cost and pain. There’s no widely successful example
in the history of computing that indicates otherwise…
</p>
<p>
The final option is to target “live” technologies. You know, the ones where vendors <em>are</em> dumping
huge amounts of money, and where the technology and platform are changing rapidly.
Things like HTML 5 and WinRT are examples of this. As a tech geek I <em>love</em> it
when organizations want to do this sort of thing, because the challenge is high and
we all get to learn a lot of new stuff. Of course the development costs are also quite
high because we’re getting paid to learn this new stuff. And the overall costs for
the software are high because the technology/platform isn’t stable and the app probably
needs to be rewritten (in whole or part) every few months to deal with platform changes.
</p>
<p>
Some organizations are willing to accept the costs and inconvenience associated with
using “live” technologies. But most organizations don’t have the time or money or
risk tolerance, and are far better off targeting “dead” technologies like WPF and
Silverlight. They just need to be careful to have strategic migration plans so they
can get off those technologies before they reach the point of where Windows Forms
is today.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=899d1465-56d6-4cc6-9de5-6eb98d97722c" />SilverlightWindows FormsWinRTWPFhttp://www.lhotka.net/weblog/Trackback.aspx?guid=6a3bac97-1184-4143-9480-b5a15a98277chttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,6a3bac97-1184-4143-9480-b5a15a98277c.aspxRockford Lhotka

At a .NET Rocks event a few weeks ago an
attendee asked if there would be some add-on to Windows 7 that allowed running WinRT
apps.

My answer: Yes! It is called Windows 8 :)

Can you run WinRT apps on Win7?http://www.lhotka.net/weblog/PermaLink,guid,6a3bac97-1184-4143-9480-b5a15a98277c.aspxhttp://www.lhotka.net/weblog/CanYouRunWinRTAppsOnWin7.aspx
Thu, 15 Nov 2012 16:57:19 GMT<p>
At a <a href="http://www.dotnetrocks.com/">.NET Rocks</a> event a few weeks ago an
attendee asked if there would be some add-on to Windows 7 that allowed running WinRT
apps.
</p>
<p>
My answer: Yes! It is called Windows 8&#160; :)
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=6a3bac97-1184-4143-9480-b5a15a98277c" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=0cbaffe9-9eae-4671-bf0e-f9f106a4b0b6http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,0cbaffe9-9eae-4671-bf0e-f9f106a4b0b6.aspxRockford Lhotka

I am pleased to announce the final release of CSLA 4 version 4.5 with support
for the following platforms:

This release includes a number of important features and changes, including:

Support for Windows Runtime (WinRT), so you can simply recompile your existing CSLA
.NET business classes for WinRT with little or no changes required to migrate to the
new platform

Support for the new async and await keywords in .NET 4.5 (and in .NET 4 and SL5 via
the async targeting pack)

Enhancements to the business rules engine

Enhancements to Windows Forms support via the Csla.Windows namespace

The entire CSLA .NET dev team has put a lot of work into this release, and we hope
you enjoy it and find it useful!

CSLA 4 version 4.5 released with support for WinRThttp://www.lhotka.net/weblog/PermaLink,guid,0cbaffe9-9eae-4671-bf0e-f9f106a4b0b6.aspxhttp://www.lhotka.net/weblog/CSLA4Version45ReleasedWithSupportForWinRT.aspx
Wed, 24 Oct 2012 22:00:51 GMT<p>
I am pleased to announce the final release of CSLA&nbsp;4 version 4.5 with support
for the following platforms:
</p>
<ul>
<li>
.NET 4.5</li>
<li>
Windows Runtime (WinRT)</li>
<li>
.NET 4</li>
<li>
Silverlight 5</li>
</ul>
<p>
The new release is available via <a href="http://nuget.org/packages?q=csla">nuget</a> and
the <a href="http://www.lhotka.net/cslanet/download.aspx">CSLA download page</a>.
</p>
<p>
This release includes a number of important features and changes, including:
</p>
<ul>
<li>
Support for Windows Runtime (WinRT), so you can simply recompile your existing CSLA
.NET business classes for WinRT with little or no changes required to migrate to the
new platform</li>
<li>
Support for the new async and await keywords in .NET 4.5 (and in .NET 4 and SL5 via
the async targeting pack)</li>
<li>
Enhancements to the business rules engine</li>
<li>
Enhancements to Windows Forms support via the Csla.Windows namespace</li>
</ul>
<p>
The entire CSLA .NET dev team has put a lot of work into this release, and we hope
you enjoy it and find it useful!
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=0cbaffe9-9eae-4671-bf0e-f9f106a4b0b6" />CSLA .NETWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=0f6164fa-537a-49ed-8902-a4909ba52b6chttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,0f6164fa-537a-49ed-8902-a4909ba52b6c.aspxRockford Lhotka

Notice that the rule’s constructor sets the rule’s IsAsync property to true. This
tells the CSLA rules engine that the rule will be async.

Also notice that the rule’s Execute method is marked with the async keyword, allowing
the use of the await keyword within the method. In this example, the rule uses the
data portal to asynchronously execute a command object by awaiting the ExecuteAsync
method.

Because the rule has IsAsync true, the Execute method must call context.Complete
to indicate that the rule has finished processing. If you don’t call context.Complete
the CSLA rule engine will never process the rule’s result, and you’ll have a bug in
your application.

The command object itself also uses the async keyword to implement the DataPortal_Execute
method. Notice that this method returns a Task. The server-side data portal components
are smart enough to detect when a DataPortal_XYZ method returns type Task, so the
DataPortal_XYZ method is invoked correctly.

Within the DataPortal_Execute method I just use Task.Delay to create an artificial
delay. This represents some long-running operation such as calling a slow web service,
invoking an intensive oData query, or something like that.

The end result is that a business object can attach this CustomRule to a property,
and the rule will run asynchronously. This is done in the business class’s AddBusinessRules
method.

In your UI you can use helper components such as Csla.Xaml.PropertyInfo to determine
that the property is running an async rule. For example, you might use XAML like this
in WinRT:

The specific XAML syntax is a little different in WPF/Silverlight because the XAML
language is more mature there than in WinRT. But the basic concept of building a rich
user experience based on an async rule is the same across all smart client platforms.

CSLA 4 version 4.5.2 is now online. This is Beta 1 of the 4.5 release, and is the
start of the beta process. I expect to release a number of betas in relatively short
order between now and the end of October. My plan is to have a final release before
Windows 8 GA.

You can get this beta release from nuget (show unreleased versions), or via the installer
from the CSLA download page.

This release supports .NET 4, .NET 4.5, WinRT, and Silverlight 5.

This beta release is a major change over the previous preview releases.

CSLA now fully supports the new WinRT platform for Windows 8 development.

The data portal now supports async/await on the client and on the server. Additionally,
the .NET, WinRT, and Silverlight data portal implementations are now the same. There
is no longer a “Silverlight data portal”. To make this happen, the data portal pipeline
underwent major changes. This includes a number
of breaking changes.

The MobileFormatter is now available for use by .NET applications (not just Silverlight
and WinRT). This might allow .NET apps to run in partial trust, and certainly
allows .NET apps to use the same data portal channel/endpoint as a WinRT or
Silverlight app.

Jonny has done a lot of work on the business rules engine. There shouldn’t be any
real breaking changes, but there are a lot of good new features.

BusinessBase metastate properties (such as IsDirty) are now bindable – they raise
PropertyChanged as you’d expect. This enables some XAML scenarios, but be careful
because WinRT XAML doesn’t notice when the DataContext has changed, so you can run
into some strange issues when saving an editable object in WinRT.

Johann put a lot of work into the nuget release process, allowing us to use nuget
for prereleases like this one, and to create a nuget package with code templates for
use in your projects.

We now support .NET 4.5 and 4.0 with CSLA 4.5, so you can use the same CSLA 4.5 on
existing .NET 4 machines, on Windows Azure, and also use it on .NET 4.5 machines.
A 4.5 client can talk to a .NET 4 server and visa versa.

WinRT now includes language resources.

A number of changes were made to the Windows Forms CslaActionExtender type.

Be aware that the .NET 4 and Silverlight 5 environments now require that
you use the Async Targeting Pack from Microsoft (typically via nuget) so that CSLA
and your code can use the async/await keywords and related functionality.

The Enterprise Services, Remoting, and asmx data portal channels have been removed.
If you need these wire transport technologies you can create your own proxy and host
types based on the version 3.8 code (perhaps they’ll end up in CslaContrib at some
point).

The namespaces for proxy and host types that included “Silverlight” in the namespace
now use the term “Mobile” instead. For example, Csla.Server.Hosts.IWcfPortal is now
Csla.Server.Hosts.Mobile.IWcfPortal.

The client-side ProxyMode concept is now eliminated entirely, and you should use the
same RunLocal attribute in Silverlight as you do in .NET.

All client-side DataPortal_XYZ methods in Silverlight are now different, and no longer
accept a callback handler parameter. Instead, code all client-side DataPortal_XYZ
methods for Silverlight just as you would for .NET.

Please direct any comments, suggestions, bug reports, or other feedback to the CSLA
forums.

CSLA 4 version 4.5 beta 1 releasedhttp://www.lhotka.net/weblog/PermaLink,guid,a6b791e5-b7bb-40ec-bc99-cb6ea741c731.aspxhttp://www.lhotka.net/weblog/CSLA4Version45Beta1Released.aspx
Mon, 24 Sep 2012 20:16:59 GMT<p>
CSLA 4 version 4.5.2 is now online. This is Beta 1 of the 4.5 release, and is the
start of the beta process. I expect to release a number of betas in relatively short
order between now and the end of October. My plan is to have a final release before
Windows 8 GA.
</p>
<p>
You can get this beta release from nuget (show unreleased versions), or via the installer
from the <a href="http://www.lhotka.net/cslanet/download.aspx">CSLA download page</a>.
</p>
<p>
This release supports .NET 4, .NET 4.5, WinRT, and Silverlight 5.
</p>
<p>
This beta release is a <em>major</em> change over the previous preview releases.
</p>
<ol>
<li>
CSLA now fully supports the new WinRT platform for Windows 8 development.</li>
<li>
The data portal now supports async/await on the client and on the server. Additionally,
the .NET, WinRT, and Silverlight data portal implementations are now the same. There
is no longer a “Silverlight data portal”. To make this happen, the data portal pipeline
underwent major changes. <font style="background-color: #ffff00">This includes a number
of breaking changes.</font>
</li>
<li>
The MobileFormatter is now available for use by .NET applications (not just Silverlight
and WinRT). This <em>might</em> allow .NET apps to run in partial trust, and certainly
allows .NET apps to use the same data portal channel/endpoint&#160; as a WinRT or
Silverlight app.</li>
<li>
Jonny has done a lot of work on the business rules engine. There shouldn’t be any
real breaking changes, but there are a lot of good new features.</li>
<li>
BusinessBase metastate properties (such as IsDirty) are now bindable – they raise
PropertyChanged as you’d expect. This enables some XAML scenarios, but be careful
because WinRT XAML doesn’t notice when the DataContext has changed, so you can run
into some strange issues when saving an editable object in WinRT.</li>
<li>
Johann put a lot of work into the nuget release process, allowing us to use nuget
for prereleases like this one, and to create a nuget package with code templates for
use in your projects.</li>
<li>
We now support .NET 4.5 and 4.0 with CSLA 4.5, so you can use the same CSLA 4.5 on
existing .NET 4 machines, on Windows Azure, and also use it on .NET 4.5 machines.
A 4.5 client can talk to a .NET 4 server and visa versa.</li>
<li>
WinRT now includes language resources.</li>
<li>
A number of changes were made to the Windows Forms CslaActionExtender type.</li>
</ol>
<p>
Be aware that the .NET 4 and Silverlight 5 environments now <em>require</em> that
you use the Async Targeting Pack from Microsoft (typically via nuget) so that CSLA
and your code can use the async/await keywords and related functionality.
</p>
<p>
Be aware that <a href="http://www.lhotka.net/weblog/CSLADataPortalChangesInVersion45.aspx">the
data portal has breaking changes</a>, especially for Silverlight users. Some highlights
of breaking changes:
</p>
<ul>
<li>
The Enterprise Services, Remoting, and asmx data portal channels have been removed.
If you need these wire transport technologies you can create your own proxy and host
types based on the version 3.8 code (perhaps they’ll end up in CslaContrib at some
point).</li>
<li>
The namespaces for proxy and host types that included “Silverlight” in the namespace
now use the term “Mobile” instead. For example, Csla.Server.Hosts.IWcfPortal is now
Csla.Server.Hosts.Mobile.IWcfPortal.</li>
<li>
The client-side ProxyMode concept is now eliminated entirely, and you should use the
same RunLocal attribute in Silverlight as you do in .NET.</li>
<li>
All client-side DataPortal_XYZ methods in Silverlight are now different, and no longer
accept a callback handler parameter. Instead, code all client-side DataPortal_XYZ
methods for Silverlight just as you would for .NET.</li>
</ul>
<p>
Please direct any comments, suggestions, bug reports, or other feedback to the <a href="http://forums.lhotka.net/forums/5.aspx">CSLA
forums</a>.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=a6b791e5-b7bb-40ec-bc99-cb6ea741c731" />CSLA .NETWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=6c81edff-6e47-4be2-aa61-bc19051ae393http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,6c81edff-6e47-4be2-aa61-bc19051ae393.aspxRockford Lhotka

Most of the work Magenic does for our customers centers around enterprise app development.
That’s another way of saying ‘line of business’ or LOB apps in most cases.

Most enterprise and LOB apps will never be placed into the Windows Store for deployment.
They’ll typically be deployed from corporate servers to the devices (tablets, ultrabooks,
laptops, desktops) of employees. In the mobile world this is called “side-loading”,
but that’s just jargon for deploying apps without using a public store.

The process for Windows RT (ARM devices) seems to be more polished than for Intel
devices, and that is rather strange. But still, Intel devices can be enabled to side-load
apps via domain policy or a command line script.

The important thing to understand is that you can side-load enterprise or
LOB apps to all editions of Windows 8.

As I’ve said
before, if you want to write Windows apps that can run on any Win8 device, you
should be targeting WinRT as your development platform.

Side-loading on Windows 8http://www.lhotka.net/weblog/PermaLink,guid,6c81edff-6e47-4be2-aa61-bc19051ae393.aspxhttp://www.lhotka.net/weblog/SideloadingOnWindows8.aspx
Tue, 21 Aug 2012 15:35:55 GMT<p>
Most of the work Magenic does for our customers centers around enterprise app development.
That’s another way of saying ‘line of business’ or LOB apps in most cases.
</p>
<p>
Most enterprise and LOB apps will never be placed into the Windows Store for deployment.
They’ll typically be deployed from corporate servers to the devices (tablets, ultrabooks,
laptops, desktops) of employees. In the mobile world this is called “side-loading”,
but that’s just jargon for deploying apps without using a public store.
</p>
<p>
The Wikipedia page describing the Win8 editions is highly misleading:
</p>
<p>
<a title="http://en.wikipedia.org/wiki/Windows_8_editions" href="http://en.wikipedia.org/wiki/Windows_8_editions">http://en.wikipedia.org/wiki/Windows_8_editions</a>
</p>
<p>
If you look at the last item in the comparison grid, it appears that only Windows
8 Enterprise supports side-loading. That is entirely wrong.
</p>
<p>
The following two links provide important details:
</p>
<ul>
<li>
<a href="http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx">Deploying
Metro Apps to Businesses</a>
</li>
<li>
<a href="http://technet.microsoft.com/en-us/library/hh852635.aspx">How to Add and
Remove Apps</a>
</li>
</ul>
<p>
The process for Windows RT (ARM devices) seems to be more polished than for Intel
devices, and that is rather strange. But still, Intel devices can be enabled to side-load
apps via domain policy or a command line script.
</p>
<p>
<strong>The important thing to understand is that you can side-load enterprise or
LOB apps to <em>all editions of Windows 8</em>. </strong>
</p>
<p>
As I’ve <a href="http://www.lhotka.net/weblog/Windows8TerminologyAndConcepts.aspx">said
before</a>, if you want to write Windows apps that can run on any Win8 device, you
should be targeting WinRT as your development platform.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=6c81edff-6e47-4be2-aa61-bc19051ae393" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=c00dda50-37d9-466e-9280-8229cc7673f8http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,c00dda50-37d9-466e-9280-8229cc7673f8.aspxRockford Lhotka

At Visual Studio Live in Redmond I gave a talk about using SkyDrive and the Windows
Live services from WinRT applications.

Windows RT – Windows 8 on ARM devices (note: Windows RT and WinRT
are not the same thing)

Windows 8 UI style – a user experience design language often used
when building WinRT applications

Windows 8 basically includes two different operating systems.

One is the “old” Win32 OS we think of today as Windows 7. This is now called Windows
8 Desktop, and is available on Windows 8 Intel tablets, laptops, and desktops. This
is only partially available on ARM devices, and you should not expect to build or
deploy Win32 Desktop apps to ARM devices.

The other is the new Windows Runtime (WinRT) “operating system”. This is a whole new
platform for apps, and is available on all Windows 8 machines (ARM, Intel, tablet,
laptop, desktop). If you want the widest reach for your apps going forward, you should
be building your apps for WinRT.

Confusingly enough, “Windows 8” runs on Intel devices/computers. “Windows RT” is Windows
8 for ARM devices. The only real difference is that Windows RT won’t allow you to
deploy Win32 Desktop apps. Windows RT does have a Desktop mode, but only Microsoft
apps can run there. Again, if you want to build a Windows 8 app that works on all
devices/computers, build the app for WinRT, because it is consistently available.

Windows 8 UI style describes a user experience design language for the look and feel
of WinRT apps. This isn’t a technology, it is a set of design principles, concepts,
and guidelines.

Another source of confusion is that to build a WinRT app in Visual Studio you need
to create a “Windows 8 UI style” app. What makes this odd, is that this type of app
is targeting WinRT, and it is entirely up to you to conform to the Windows 8 UI style
guidelines as you build the app.

“Windows 8 UI style” was called “Metro style”, but Microsoft has dropped the use of
the term “Metro”. I am skeptical that this new “Windows 8 UI style” term will last
long-term, because it obviously makes little sense for Windows Phone 8, Xbox, Windows
9, and other future platforms that may use the same UI style. But for now, this appears
to be the term Microsoft is using.

Thinking about app development now, there are several options on the Microsoft platforms.

Windows 8 Terminology and Conceptshttp://www.lhotka.net/weblog/PermaLink,guid,970ce9b2-a608-4c68-9784-bc0bb0ddc5b1.aspxhttp://www.lhotka.net/weblog/Windows8TerminologyAndConcepts.aspx
Fri, 03 Aug 2012 16:03:20 GMT<p>
With all the new terminology and conceptual surface area that comes with Windows 8,
I think it is important to have some clarity and consistency around the terms and
concepts.
</p>
<p>
Here are some of the basic terms:
</p>
<ul>
<li>
<strong>Windows 8</strong> – the new operating system that runs in a “dual mode”:
Desktop (Win32) and WinRT (Windows Runtime)</li>
<li>
<strong>Desktop</strong> – the Win32 OS API that supports today’s applications in
Win8 (basically Windows 7)</li>
<li>
<strong>WinRT</strong> – Windows Runtime: the new OS API that supports “modern” applications
</li>
<li>
<strong>Windows RT</strong> – Windows 8 on ARM devices (note: Windows RT and WinRT
are not the same thing)</li>
<li>
<strong>Windows 8 UI style</strong> – a user experience design language often used
when building WinRT applications
</li>
</ul>
<p>
Windows 8 basically includes two different operating systems.
</p>
<p>
One is the “old” Win32 OS we think of today as Windows 7. This is now called Windows
8 Desktop, and is available on Windows 8 Intel tablets, laptops, and desktops. This
is only partially available on ARM devices, and you should not expect to build or
deploy Win32 Desktop apps to ARM devices.
</p>
<p>
The other is the new Windows Runtime (WinRT) “operating system”. This is a whole new
platform for apps, and is available on all Windows 8 machines (ARM, Intel, tablet,
laptop, desktop). If you want the widest reach for your apps going forward, you should
be building your apps for WinRT.
</p>
<p>
Confusingly enough, “Windows 8” runs on Intel devices/computers. “Windows RT” is Windows
8 for ARM devices. The only real difference is that Windows RT won’t allow you to
deploy Win32 Desktop apps. Windows RT does have a Desktop mode, but only Microsoft
apps can run there. Again, if you want to build a Windows 8 app that works on all
devices/computers, build the app for WinRT, because it is consistently available.
</p>
<p>
Windows 8 UI style describes a user experience design language for the look and feel
of WinRT apps. This isn’t a technology, it is a set of design principles, concepts,
and guidelines.
</p>
<p>
Another source of confusion is that to build a WinRT app in Visual Studio you need
to create a “Windows 8 UI style” app. What makes this odd, is that this type of app
is targeting WinRT, and it is entirely up to you to conform to the Windows 8 UI style
guidelines as you build the app.
</p>
<p>
“Windows 8 UI style” was called “Metro style”, but Microsoft has dropped the use of
the term “Metro”. I am skeptical that this new “Windows 8 UI style” term will last
long-term, because it obviously makes little sense for Windows Phone 8, Xbox, Windows
9, and other future platforms that may use the same UI style. But for now, this appears
to be the term Microsoft is using.
</p>
<p>
Thinking about app development now, there are several options on the Microsoft platforms.
<br />
</p>
<table border="0" cellspacing="0" cellpadding="2" width="637">
<tbody>
<tr>
<td valign="top" width="113">
&nbsp;</td>
<td valign="top" width="207">
<strong>Technologies</strong></td>
<td valign="top" width="315">
<strong>Platforms</strong></td>
</tr>
<tr>
<td valign="top" width="113">
Full .NET 4.5</td>
<td valign="top" width="207">
ASP.NET, WPF, Windows Forms, WCF, WF</td>
<td valign="top" width="315">
Windows 7, Windows 8 Desktop, Windows Server 2008, Windows Server 2012</td>
</tr>
<tr>
<td valign="top" width="113">
WinRT .NET 4.5</td>
<td valign="top" width="207">
Windows 8 UI style apps</td>
<td valign="top" width="315">
Windows 8 WinRT, Windows Phone 8, rumored for next-gen Xbox</td>
</tr>
<tr>
<td valign="top" width="113">
Full .NET 4</td>
<td valign="top" width="207">
ASP.NET, WPF, Windows Forms, WCF, WF</td>
<td valign="top" width="315">
Windows 7, Windows Server 2008, Azure PaaS</td>
</tr>
<tr>
<td valign="top" width="113">
Silverlight</td>
<td valign="top" width="207">
Silverlight</td>
<td valign="top" width="315">
Windows 7, Windows 8 Desktop, Windows Phone 7, Windows Phone 8</td>
</tr>
</tbody>
</table>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=970ce9b2-a608-4c68-9784-bc0bb0ddc5b1" />Microsoft .NETWindows 8Windows PhoneWinRTWP8http://www.lhotka.net/weblog/Trackback.aspx?guid=1cfed469-df70-4f07-918f-3270372dbf81http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,1cfed469-df70-4f07-918f-3270372dbf81.aspxRockford Lhotka

I want to summarize some of the more major changes coming to the data portal in CSLA
4 version 4.5. Some of these are breaking changes.

I’ve done four big things with the data portal:

Added support for the new async/await keywords on the client and server

Merged the .NET and Silverlight data portal implementations into a single code base
that is now common across WinRT, .NET, and Silverlight

Removed the public virtual DataPortal_XYZ method definitions from Silverlight, because
it can now invoke non-public methods just like in .NET. Also, all local Silverlight
data portal methods no longer accept the async callback handler, because they now
support the async/await pattern

Remove the ProxyMode concept from the Silverlight data portal, because the RunLocal
attribute is now available on all platforms

All four have some level of breaking change.

Adding comprehensive support for async/await changes the way .NET handles exceptions.
Although I’ve worked to keep the top level exceptions consistent, the actual
exception object graph (nested InnerExceptions) will almost certainly be different
now.

Merging the .NET and Silverlight data portal implementations introduces a number of
relatively minor breaking changes for Silverlight users. Though if you’ve created
custom proxy/host pairs or other more advanced scenarios you might be more affected
than others. There may also be unintended side-effects to .NET users. Some might be
bugs, others might be necessary to achieve platform unification.

Removing the public virtual DataPortal_XYZ methods from BusinessBase and BusinessListBase
will break anyone using the local Silverlight data portal. The fix is minor – just
change the public scopes to protected. This change shouldn’t affect anyone using .NET,
or using a remote data portal from Silverlight.

Removing the async callback parameter from all Silverlight client-side DataPortal_XYZ
methods will break anyone using the local Silverlight data portal. The fix is to switch
to the new async/await pattern. The code changes are relatively minor, and generally
simplify your code, but if you’ve made extensive use of the client-side data portal
in Silverlight this will be a pretty big change I’m afraid.

Similarly, removing the ProxyMode concept from the Silverlight data portal is a breaking
change for people using the local Silverlight data portal. Again, the fix is pretty
simple – just add the RunLocal attribute to the DataPortal_XYZ (or object factory)
methods as you have always done in .NET.

On the upside, the coding patterns for writing code in .NET, WinRT, and Silverlight
are now the same.

For example, a DataPortal_Fetch method on any platform looks like this:

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

The data portal will automatically detect if your method returns a Task and it will
await the method, allowing you to use the await keyword inside your DataPortal_XYZ
methods.

This is one of the few platform-specific concepts left in the data portal.

What is really cool is that the client and server sync/async concepts can be mixed
(as long as you know what to expect).

Client method

Client platform

Server method

Server platform

Remarks

Fetch

.NET only

void DataPortal_Fetch

any

Client call is synchronous; server call is synchronous

Fetch

.NET only

Task DataPortal_Fetch

any

Client call is synchronous; server call is asynchronous; note that client will block
until the server’s work is complete

BeginFetch

any

void DataPortal_Fetch

any

Client call is asynchronous (event-based); server call is synchronous; client will
not block, and must handle the callback event to be notified when the server call
is complete

BeginFetch

any

Task DataPortal_Fetch

any

Client call is asynchronous (event-based); server call is asynchronous; client will
not block, and must handle the callback event to be notified when the server call
is complete

FetchAsync

any

void DataPortal_Fetch

any

Client call is asynchronous; server call is synchronous; client will block or not,
depending on how you invoke the client-side Task (using await or other techniques);
the client-side Task will complete when the server call is complete

FetchAsync

any

Task DataPortal_Fetch

any

Client call is asynchronous; server call is asynchronous; client will block or not,
depending on how you invoke the client-side Task (using await or other techniques);
the client-side Task will complete when the server call is complete

I expect all client-side data portal code to switch to the async/await versions of
the methods, and so I’ve made them the mainline path through the data portal. The
synchronous and event-based async methods use async/await techniques behind the scenes
to do implement the desired behaviors.

There is a lot of variety in how you can invoke an awaitable method like FetchAsync.
The specific async behaviors you should expect will vary depending on how you invoke
the method. For example, there’s a big difference between using the await keyword
or the Result or RunSynchronously methods:

var obj = await CustomerEdit.GetCustomerAsync(123);

var obj = CustomerEdit.GetCustomerAsync(123).Result;

The former is async, the latter is sync. The former will return a simple exception
(if one occurs), the latter will return an AggregateException containing the simple
exception. This has little to do with CSLA, and nearly everything to do with the way
the async/await and task parallel library (TPL) are implemented by .NET.

Finally, I do need to state that the actual network transport (typically WCF) used
by .NET, Silverlight, and WinRT aren’t the same. This is because WCF in .NET is far
more flexible than in Silverlight or WinRT. And because the WCF client-side proxies
generated for Silverlight use event-driven async methods, and in WinRT the proxy is
task-based.

The data portal hides these differences pretty effectively, but you should understand
that they exist, and as a result there may be subtle behavioral differences between
platforms, especially when it comes to exceptions and exception details. The success
paths for creating, fetching, updating, and deleting objects are identical, but there
may be edge cases where differences exist.

All in all I am quite pleased with how this is turning out. I’ve put a massive amount
of work into the data portal for 4.5, especially around unifying the implementations
across platforms. I suspect there’ll be some issues to work through during the beta
testing phase, but the end result is a far more consistent, maintainable, and streamlined
codebase for all platforms. That will benefit all of us over time.

CSLA data portal changes in version 4.5http://www.lhotka.net/weblog/PermaLink,guid,1cfed469-df70-4f07-918f-3270372dbf81.aspxhttp://www.lhotka.net/weblog/CSLADataPortalChangesInVersion45.aspx
Tue, 31 Jul 2012 04:53:23 GMT<p>
I want to summarize some of the more major changes coming to the data portal in CSLA
4 version 4.5. Some of these are breaking changes.
</p>
<p>
I’ve done four big things with the data portal:
</p>
<ol>
<li>
Added support for the new async/await keywords on the client and server</li>
<li>
Merged the .NET and Silverlight data portal implementations into a single code base
that is now common across WinRT, .NET, and Silverlight</li>
<li>
Removed the public virtual DataPortal_XYZ method definitions from Silverlight, because
it can now invoke non-public methods just like in .NET. Also, all local Silverlight
data portal methods no longer accept the async callback handler, because they now
support the async/await pattern</li>
<li>
Remove the ProxyMode concept from the Silverlight data portal, because the RunLocal
attribute is now available on all platforms</li>
</ol>
<p>
All four have some level of breaking change.
</p>
<p>
Adding comprehensive support for async/await changes the way .NET handles exceptions.
Although I’ve worked to keep the <em>top level</em> exceptions consistent, the actual
exception object graph (nested InnerExceptions) will almost certainly be different
now.
</p>
<p>
Merging the .NET and Silverlight data portal implementations introduces a number of
relatively minor breaking changes for Silverlight users. Though if you’ve created
custom proxy/host pairs or other more advanced scenarios you might be more affected
than others. There may also be unintended side-effects to .NET users. Some might be
bugs, others might be necessary to achieve platform unification.
</p>
<p>
Removing the public virtual DataPortal_XYZ methods from BusinessBase and BusinessListBase
will break anyone using the local Silverlight data portal. The fix is minor – just
change the public scopes to protected. This change shouldn’t affect anyone using .NET,
or using a remote data portal from Silverlight.
</p>
<p>
Removing the async callback parameter from all Silverlight client-side DataPortal_XYZ
methods will break anyone using the local Silverlight data portal. The fix is to switch
to the new async/await pattern. The code changes are relatively minor, and generally
simplify your code, but if you’ve made extensive use of the client-side data portal
in Silverlight this will be a pretty big change I’m afraid.
</p>
<p>
Similarly, removing the ProxyMode concept from the Silverlight data portal is a breaking
change for people using the local Silverlight data portal. Again, the fix is pretty
simple – just add the RunLocal attribute to the DataPortal_XYZ (or object factory)
methods as you have always done in .NET.
</p>
<p>
On the upside, the coding patterns for writing code in .NET, WinRT, and Silverlight
are now the same.
</p>
<p>
For example, a DataPortal_Fetch method <em>on any platform</em> looks like this:
</p>
<blockquote>
<p>
private void DataPortal_Fetch(int id)
</p>
</blockquote>
<p>
or like this
</p>
<blockquote>
<p>
private async Task DataPortal_Fetch(int id)
</p>
</blockquote>
<p>
The data portal will automatically detect if your method returns a Task and it will
await the method, allowing you to use the await keyword inside your DataPortal_XYZ
methods.
</p>
<p>
Similarly, all platforms can now write this client-side code:
</p>
<blockquote>
<p>
var obj = await CustomerEdit.GetCustomerAsync(123);
</p>
</blockquote>
<p>
or the older event-style code:
</p>
<blockquote>
<p>
CustomerEdit.GetCustomer(123, (o, e) =&gt;
<br />
&#160; {
<br />
&#160;&#160;&#160;&#160;&#160; if (e.Error != null)
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; throw e.Error;
<br />
&#160;&#160;&#160;&#160; else
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; obj = e.Object;
<br />
&#160; });
</p>
</blockquote>
<p>
Only .NET code can use the synchronous approach:
</p>
<blockquote>
<p>
var obj = CustomerEdit.GetCustomer(123);
</p>
</blockquote>
<p>
This is one of the few platform-specific concepts left in the data portal.
</p>
<p>
What is really cool is that the client and server sync/async concepts can be mixed
(as long as you know what to expect).
</p>
<table border="0" cellspacing="0" cellpadding="2" width="877">
<tbody>
<tr>
<td valign="top" width="79">
Client method</td>
<td valign="top" width="77">
Client platform</td>
<td valign="top" width="141">
Server method</td>
<td valign="top" width="10">
Server platform</td>
<td valign="top" width="571">
Remarks</td>
</tr>
<tr>
<td valign="top" width="83">
Fetch</td>
<td valign="top" width="81">
.NET only</td>
<td valign="top" width="141">
void DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is synchronous; server call is synchronous</td>
</tr>
<tr>
<td valign="top" width="83">
Fetch</td>
<td valign="top" width="81">
.NET only</td>
<td valign="top" width="141">
Task DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is synchronous; server call is asynchronous; note that client will block
until the server’s work is complete</td>
</tr>
<tr>
<td valign="top" width="83">
BeginFetch</td>
<td valign="top" width="81">
any</td>
<td valign="top" width="141">
void DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is asynchronous (event-based); server call is synchronous; client will
not block, and must handle the callback event to be notified when the server call
is complete</td>
</tr>
<tr>
<td valign="top" width="83">
BeginFetch</td>
<td valign="top" width="81">
any</td>
<td valign="top" width="141">
Task DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is asynchronous (event-based); server call is asynchronous; client will
not block, and must handle the callback event to be notified when the server call
is complete</td>
</tr>
<tr>
<td valign="top" width="83">
FetchAsync</td>
<td valign="top" width="81">
any</td>
<td valign="top" width="141">
void DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is asynchronous; server call is synchronous; client will block or not,
depending on how you invoke the client-side Task (using await or other techniques);
the client-side Task will complete when the server call is complete</td>
</tr>
<tr>
<td valign="top" width="83">
FetchAsync</td>
<td valign="top" width="81">
any</td>
<td valign="top" width="141">
Task DataPortal_Fetch</td>
<td valign="top" width="10">
any</td>
<td valign="top" width="571">
Client call is asynchronous; server call is asynchronous; client will block or not,
depending on how you invoke the client-side Task (using await or other techniques);
the client-side Task will complete when the server call is complete</td>
</tr>
</tbody>
</table>
<p>
I expect all client-side data portal code to switch to the async/await versions of
the methods, and so I’ve made them the mainline path through the data portal. The
synchronous and event-based async methods use async/await techniques behind the scenes
to do implement the desired behaviors.
</p>
<p>
There is a lot of variety in how you can invoke an awaitable method like FetchAsync.
The specific async behaviors you should expect will vary depending on how you invoke
the method. For example, there’s a big difference between using the await keyword
or the Result or RunSynchronously methods:
</p>
<blockquote>
<p>
var obj = await CustomerEdit.GetCustomerAsync(123);
</p>
<p>
var obj = CustomerEdit.GetCustomerAsync(123).Result;
</p>
</blockquote>
<p>
The former is async, the latter is sync. The former will return a simple exception
(if one occurs), the latter will return an AggregateException containing the simple
exception. This has little to do with CSLA, and nearly everything to do with the way
the async/await and task parallel library (TPL) are implemented by .NET.
</p>
<p>
Finally, I do need to state that the actual network transport (typically WCF) used
by .NET, Silverlight, and WinRT aren’t the same. This is because WCF in .NET is far
more flexible than in Silverlight or WinRT. And because the WCF client-side proxies
generated for Silverlight use event-driven async methods, and in WinRT the proxy is
task-based.
</p>
<p>
The data portal hides these differences pretty effectively, but you should understand
that they exist, and as a result there may be subtle behavioral differences between
platforms, especially when it comes to exceptions and exception details. The success
paths for creating, fetching, updating, and deleting objects are identical, but there
may be edge cases where differences exist.
</p>
<p>
All in all I am quite pleased with how this is turning out. I’ve put a massive amount
of work into the data portal for 4.5, especially around unifying the implementations
across platforms. I suspect there’ll be some issues to work through during the beta
testing phase, but the end result is a far more consistent, maintainable, and streamlined
codebase for all platforms. That will benefit all of us over time.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=1cfed469-df70-4f07-918f-3270372dbf81" />CSLA .NETMicrosoft .NETSilverlightWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=6696d807-cbf2-4a63-91b0-9e686fe900f8http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,6696d807-cbf2-4a63-91b0-9e686fe900f8.aspxRockford Lhotka

While the punditry and others are fixated on whether users can adapt to (or even enjoy)
the new Windows Start screen and other new UX features, they are missing the real
point of Windows 8 and WinRT.

A couple days ago my reasonably computer-savvy son wanted to do some art work, so
he downloaded Paint .NET. Or so he thought.

These days most software for Windows is downloaded via the web. And any reasonably
popular software has malicious clones with domain names, web sites, and even installers,
that look similar to the real thing. This is absolutely the case with Paint .NET.

So my son downloaded what appeared to be a valid installer, from a domain name that
seemed reasonable. And just like that his computer was infected with a bunch of Yahoo
crap, along with a bunch of real spyware and malware. He’s still trying to get it
all cleaned up.

I’ve done the same thing, and I’m extremely computer savvy. Sometimes even the most
savvy user gets suckered by a very clever bad guy.

WinRT apps only come from a store. The Microsoft Store, or a corporate “store”.

To get into the Microsoft Store, developers must be registered, apps are screened
by Microsoft, and if anything malicious does slip through, the app can be removed/revoked
from the store.

To get into a corporate “store”, your employer must choose to put the app into that
store. It seems unlikely that your IT department will put apps in their own store
that they didn’t create or acquire from a known vendor.

As a result, you can imagine a “Paint WinRT” app that is like Paint .NET, but that
my son would have found in the Microsoft Store, and installed from the Store. Effectively
zero chance of all the spyware, malware, and Yahoo crap that comes with so much of
today’s software.

Now think of all the PC users around the world who will be able to actually find and
install software without the fear we all feel in today’s world.

Sure, Win8 and WinRT mean accepting some change. But personally I am entirely ready
to embrace that change to get the benefits offered!

Why Windows 8 is so importanthttp://www.lhotka.net/weblog/PermaLink,guid,6696d807-cbf2-4a63-91b0-9e686fe900f8.aspxhttp://www.lhotka.net/weblog/WhyWindows8IsSoImportant.aspx
Tue, 03 Jul 2012 14:30:53 GMT<p>
While the punditry and others are fixated on whether users can adapt to (or even enjoy)
the new Windows Start screen and other new UX features, they are missing the real
point of Windows 8 and WinRT.
</p>
<p>
A couple days ago my reasonably computer-savvy son wanted to do some art work, so
he downloaded Paint .NET. Or so he thought.
</p>
<p>
These days most software for Windows is downloaded via the web. And any reasonably
popular software has malicious clones with domain names, web sites, and even installers,
that look similar to the real thing. This is absolutely the case with Paint .NET.
</p>
<p>
So my son downloaded what appeared to be a valid installer, from a domain name that
seemed reasonable. And just like that his computer was infected with a bunch of Yahoo
crap, along with a bunch of real spyware and malware. He’s still trying to get it
all cleaned up.
</p>
<p>
I’ve done the same thing, and I’m extremely computer savvy. Sometimes even the most
savvy user gets suckered by a very clever bad guy.
</p>
<p>
WinRT apps only come from a store. The Microsoft Store, or a corporate “store”.
</p>
<p>
To get into the Microsoft Store, developers must be registered, apps are screened
by Microsoft, and if anything malicious does slip through, the app can be removed/revoked
from the store.
</p>
<p>
To get into a corporate “store”, your employer must choose to put the app into that
store. It seems unlikely that your IT department will put apps in their own store
that they didn’t create or acquire from a known vendor.
</p>
<p>
As a result, you can imagine a “Paint WinRT” app that is like Paint .NET, but that
my son would have found in the Microsoft Store, and installed from the Store. Effectively
zero chance of all the spyware, malware, and Yahoo crap that comes with so much of
today’s software.
</p>
<p>
Now think of all the PC users around the world who will be able to actually find and
install software without the fear we all feel in today’s world.
</p>
<p>
Sure, Win8 and WinRT mean accepting some change. But personally I am entirely ready
to embrace that change to get the benefits offered!
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=6696d807-cbf2-4a63-91b0-9e686fe900f8" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=d9d80213-55f1-4618-8d9a-bc285ed906f3http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,d9d80213-55f1-4618-8d9a-bc285ed906f3.aspxRockford Lhotka

This is why I’m putting so much work into making sure CSLA .NET works great on WinRT!

<Paragraph>
This is some text. And some <Bold>bolded text</Bold>.
</Paragraph>

I would like to just bind this text to a RichTextBlock control for display. Sadly
there’s no way to put content into a RichTextBlock control at runtime short of adding
Block objects to the control’s Blocks collection.

As a workaround, I’ve been playing with the idea of a custom control like this:

using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Markup;

There are three fairly popular presentation layer design patterns that I collectively
call the “M” patterns: MVC, MVP, and MVVM. This is because they all have an “M” standing
for “Model”, plus some other constructs.

The thing with all of these “M” patterns is that for typical developers the patterns
are useless without a framework. Using the patterns without a framework almost always
leads to confusion, complication, high costs, frustration, and ultimately despair.

These are just patterns after all, not implementations. And they are big, complex
patterns that include quite a few concepts that must work together correctly to enable
success.

You can’t sew a fancy dress just because you have a pattern. You need appropriate
tools, knowledge, and experience. The same is true with these complex “M” patterns.

And if you want to repeat the process of sewing a fancy dress over and over again
(efficiently), you need specialized tooling for this purpose. In software terms this
is a framework.

Trying to do something like MVVM without a framework is a huge amount of work. Tons
of duplicate code, reinventing the wheel, and retraining people to think differently.

At least with a framework you avoid the duplicate code and hopefully don’t have to
reinvent the wheel – allowing you to focus on retraining people. The retraining part
is generally unavoidable, but a framework provides plumbing code and structure, making
the process easier.

You might ask yourself why the MVC pattern only became popular in ASP.NET a few short
years ago. The pattern has existed since (at least) the mid-1990’s, and yet few people
used it, and even fewer used it successfully. This includes people on other platforms
too, at least up to the point that those platforms included well-implemented MVC frameworks.

Strangely, MVC only started to become mainstream in the Microsoft world when ASP.NET
MVC showed up. This is a comprehensive framework with tooling integrated into Visual
Studio. As a result. typical developers can just build models, views, and controllers.
Prior to that point they also had to build everything the MVC framework does – which
is a lot of code. And not just a lot of code, but code that has absolutely nothing
to do with business value, and only relates to implementation of the pattern itself.

We’re in the same situation today with MVVM in WPF, Silverlight, Windows Phone, and
Windows Runtime (WinRT in Windows 8). If you want to do MVVM without a framework,
you will have to build everything a framework would do – which is a lot of code that
provides absolutely no direct business value.

Typical developers really do want to focus on building models, views, and viewmodels.
They don’t want to have to build weak reference based event routers, navigation models,
view abstractions, and all the other things a framework must do. In fact, most developers
probably can’t build those things, because they aren’t platform/framework
wonks. It takes a special kind of passion (or craziness) to learn the deep, highly
specialized techniques and tricks necessary to build a framework like this.

What I really wish would happen, is for Microsoft to build an MVVM framework
comparable to ASP.NET MVC. Embed it into the .NET/XAML support for WinRT/Metro, and
include tooling in VS so we can right-click and add views and viewmodels. Ideally
this would be an open, iterative process like ASP.NET MVC has been – so after a few
years the framework reflects the smartest thoughts from Microsoft and from the community
at large.

In the meantime, Caliburn Micro appears
to be the best MVVM framework out there – certainly the most widely used. Probably
followed by various implementations using PRISM, and then MVVM Light, and some others.

Using the MVVM pattern requires a frameworkhttp://www.lhotka.net/weblog/PermaLink,guid,c61fd797-16f7-4f5f-a6fc-226f235b132a.aspxhttp://www.lhotka.net/weblog/UsingTheMVVMPatternRequiresAFramework.aspx
Mon, 07 May 2012 20:01:55 GMT<p>
There are three fairly popular presentation layer design patterns that I collectively
call the “M” patterns: MVC, MVP, and MVVM. This is because they all have an “M” standing
for “Model”, plus some other constructs.
</p>
<p>
The thing with all of these “M” patterns is that for typical developers the patterns
are useless without a framework. Using the patterns without a framework almost always
leads to confusion, complication, high costs, frustration, and ultimately despair.
</p>
<p>
These are just patterns after all, not implementations. And they are big, complex
patterns that include quite a few concepts that must work together correctly to enable
success.
</p>
<p>
You can’t sew a fancy dress just because you have a pattern. You need appropriate
tools, knowledge, and experience. The same is true with these complex “M” patterns.
</p>
<p>
And if you want to repeat the process of sewing a fancy dress over and over again
(efficiently), you need specialized tooling for this purpose. In software terms this
is a framework.
</p>
<p>
Trying to do something like MVVM without a framework is a huge amount of work. Tons
of duplicate code, reinventing the wheel, and retraining people to think differently.
</p>
<p>
At least with a framework you avoid the duplicate code and hopefully don’t have to
reinvent the wheel – allowing you to focus on retraining people. The retraining part
is generally unavoidable, but a framework provides plumbing code and structure, making
the process easier.
</p>
<p>
You might ask yourself why the MVC pattern only became popular in ASP.NET a few short
years ago. The pattern has existed since (at least) the mid-1990’s, and yet few people
used it, and even fewer used it successfully. This includes people on other platforms
too, at least up to the point that those platforms included well-implemented MVC frameworks.
</p>
<p>
Strangely, MVC only started to become mainstream in the Microsoft world when ASP.NET
MVC showed up. This is a comprehensive framework with tooling integrated into Visual
Studio. As a result. typical developers can just build models, views, and controllers.
Prior to that point they also had to build everything the MVC framework does – which
is a lot of code. And not just a lot of code, but code that has absolutely nothing
to do with business value, and only relates to implementation of the pattern itself.
</p>
<p>
We’re in the same situation today with MVVM in WPF, Silverlight, Windows Phone, and
Windows Runtime (WinRT in Windows 8). If you want to do MVVM without a framework,
you will have to build everything a framework would do – which is a lot of code that
provides absolutely no direct business value.
</p>
<p>
Typical developers really do want to focus on building models, views, and viewmodels.
They don’t want to have to build weak reference based event routers, navigation models,
view abstractions, and all the other things a framework must do. In fact, most developers
probably <em>can’t </em>build those things, because they aren’t platform/framework
wonks. It takes a special kind of passion (or craziness) to learn the deep, highly
specialized techniques and tricks necessary to build a framework like this.
</p>
<p>
What I really <i>wish</i> would happen, is for Microsoft to build an MVVM framework
comparable to ASP.NET MVC. Embed it into the .NET/XAML support for WinRT/Metro, and
include tooling in VS so we can right-click and add views and viewmodels. Ideally
this would be an open, iterative process like ASP.NET MVC has been – so after a few
years the framework reflects the smartest thoughts from Microsoft and from the community
at large.
</p>
<p>
In the meantime, <a href="http://caliburnmicro.codeplex.com/">Caliburn Micro</a> appears
to be the best MVVM framework out there – certainly the most widely used. Probably
followed by various implementations using PRISM, and then MVVM Light, and some others.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=c61fd797-16f7-4f5f-a6fc-226f235b132a" />ArchitectureMicrosoft .NETProgrammingWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=04a35ef0-345e-4c5a-bfaf-70a6b7883107http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,04a35ef0-345e-4c5a-bfaf-70a6b7883107.aspxRockford Lhotka

I am sometimes asked for technical career advice. A common question these days is
whether it is worth learning WPF, or Silverlight – .NET and XAML in general I suppose,
or would it be better to learn HTML 5 and JavaScript, or perhaps even Objective C?

This is a challenging question to be sure. How good is your crystal ball?

XAML appears to be alive and well – WPF, Silverlight, and now WinRT (Windows 8 – and
probably Windows Phone 8 and “Xbox 720” and more) all use XAML.

I look at the WinRT usage of XAML as being essentially “Silverlight 6” – it is far
closer to Silverlight than WPF, but isn’t exactly like Silverlight either. Assuming
success with Windows 8, WinRT will become the new primary client dev target for most
smart client development (over the next few years).

The primary competitors are Objective C (if you believe iPads will take over the client
space), and HTML 5/JavaScript (if you believe in fairy tales the concept of
‘one technology to rule them all’).

This is where the crystal ball comes into play.

Do you think Apple will displace Microsoft – iPads will replace the use of Windows
– as the monopoly client OS?

Do you think the concept of ‘natural monopoly’ that has caused the Windows hegemony
over the past 20 years is at an end – that some fundamental economic shift has occurred
so companies are now willing to increase their IT budgets as a % of revenue to accommodate
multiple client platforms (unlike the past 20 years)? In which case business app developers
should expect to support at least iPad and Windows, if not Android, into the future?

Do you think that Windows 8 and WinRT will be strong enough to withstand the iPad
onslaught, and that the natural monopoly economic effect remains in place, so Windows
will remain the dominant client platform for business apps into the foreseeable future?

H5/js rules the world as the ‘one technology to rule them all’ and vendors like Microsoft
and Apple become entirely irrelevant because we live in a purely open-source world
where nobody makes money off any platform technologies, so probably the only hardware/OS
left is something like Android running Chrome, because it is a 100% commodity play
at that level

.NET and XAML remain entirely valid, and life generally continues like it is today,
with a mix of .NET smart client work and primarily server-based web work with h5/js
primarily used to boost the user experience, but not often used to write standalone
smart client apps

My crystal ball leans toward option 3 – I don’t think economic realities change much
or often, and I struggle to see where IT departments will come up with the increased
budget (% of revenue) necessary to build apps for both iPads and Windows over the
long term. It will be measurably cheaper (by many, many, many thousands of dollars)
for companies to buy employees Win8 tablets rather than building and maintaining both iOS
and Windows versions of every business app.

And I don’t believe in the ‘one technology to rule them all’ idea. That hasn’t happened
in the entire history of computing, and it is hard to imagine everyone on the planet
embracing one monoculture for software development. Especially when it would be counter
to the interests of every platform vendor out there (Microsoft, Apple, Google, Oracle,
and even IBM).

Still with me?

To summarize, I think learning XAML is time well spent. Today that’s WPF or Silverlight.
There is absolutely no doubt that Silverlight is closer to WinRT than WPF, and people
building SL apps today will have an easier time migrating them to WinRT later, whereas
most WPF apps will be a pretty big rewrite.

But there’s nothing wrong with focusing yourself on h5/js. If you do so, I suggest
doing it in a way that ignores or minimizes all server-side coding. If h5/js does take
over the world, it will be used to create pure smart client apps, and if there’s a
“web server” involved at all, it will exist purely as a deployment server for the
client app. The ‘pure’ h5/js/jquery/etc. world isn’t linked to any vendor – not Microsoft,
Apple, or anyone. To me this represents a pretty major career shift, because to truly
embrace h5/js as a complete software development platform is so demanding (imo) it
won’t leave time to retain .NET or other vendor-specific technology expertise.

For my part, I’m not yet ready to abandon Microsoft for h5/js, because I think Windows
8, WinRT, .NET, and XAML have a rather bright future. A year from now I think a lot
of people will be happily using Windows 8 desktops, laptops, and tablets – and hopefully
a lot of Windows Phones, and with luck we’ll be looking forward to some cool new Xbox.
I live in (I think realistic) hope that my .NET/XAML skills will apply to all these
platforms.

What does your crystal ball say?

Should I learn Silverlight? Objective C? HTML 5?http://www.lhotka.net/weblog/PermaLink,guid,04a35ef0-345e-4c5a-bfaf-70a6b7883107.aspxhttp://www.lhotka.net/weblog/ShouldILearnSilverlightObjectiveCHTML5.aspx
Thu, 26 Apr 2012 15:32:58 GMT<p>
I am sometimes asked for technical career advice. A common question these days is
whether it is worth learning WPF, or Silverlight – .NET and XAML in general I suppose,
or would it be better to learn HTML 5 and JavaScript, or perhaps even Objective C?
</p>
<p>
This is a challenging question to be sure. How good is your crystal ball? <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-smile" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Should-I-learn-Silverlight-HTML-5_9026/wlEmoticon-smile_2.png" />
</p>
<p>
XAML appears to be alive and well – WPF, Silverlight, and now WinRT (Windows 8 – and
probably Windows Phone 8 and “Xbox 720” and more) all use XAML.
</p>
<p>
I look at the WinRT usage of XAML as being essentially “Silverlight 6” – it is far
closer to Silverlight than WPF, but isn’t exactly like Silverlight either. Assuming
success with Windows 8, WinRT will become the new primary client dev target for most
smart client development (over the next few years).
</p>
<p>
The primary competitors are Objective C (if you believe iPads will take over the client
space), and HTML 5/JavaScript (if you believe in <s>fairy tales</s> the concept of
‘one technology to rule them all’).
</p>
<p>
This is where the crystal ball comes into play.
</p>
<p>
Do you think Apple will displace Microsoft – iPads will replace the use of Windows
– as the monopoly client OS?
</p>
<p>
Do you think the concept of ‘natural monopoly’ that has caused the Windows hegemony
over the past 20 years is at an end – that some fundamental economic shift has occurred
so companies are now willing to increase their IT budgets as a % of revenue to accommodate
multiple client platforms (unlike the past 20 years)? In which case business app developers
should expect to support at least iPad and Windows, if not Android, into the future?
</p>
<p>
Do you think that Windows 8 and WinRT will be strong enough to withstand the iPad
onslaught, and that the natural monopoly economic effect remains in place, so Windows
will remain the dominant client platform for business apps into the foreseeable future?
</p>
<p>
These are really the three options, resulting in:
</p>
<ol>
<li>
Objective C slowly overtakes .NET and we ultimately are Apple devs instead of Microsoft
devs</li>
<li>
H5/js rules the world as the ‘one technology to rule them all’ and vendors like Microsoft
and Apple become entirely irrelevant because we live in a purely open-source world
where nobody makes money off any platform technologies, so probably the only hardware/OS
left is something like Android running Chrome, because it is a 100% commodity play
at that level</li>
<li>
.NET and XAML remain entirely valid, and life generally continues like it is today,
with a mix of .NET smart client work and primarily server-based web work with h5/js
primarily used to boost the user experience, but not often used to write standalone
smart client apps</li>
</ol>
<p>
My crystal ball leans toward option 3 – I don’t think economic realities change much
or often, and I struggle to see where IT departments will come up with the increased
budget (% of revenue) necessary to build apps for both iPads and Windows over the
long term. It will be measurably cheaper (by many, many, many thousands of dollars)
for companies to buy employees Win8 tablets rather than building and maintaining <i>both</i> iOS
and Windows versions of every business app.
</p>
<p>
And I don’t believe in the ‘one technology to rule them all’ idea. That hasn’t happened
in the entire history of computing, and it is hard to imagine everyone on the planet
embracing one monoculture for software development. Especially when it would be counter
to the interests of every platform vendor out there (Microsoft, Apple, Google, Oracle,
and even IBM).
</p>
<p>
Still with me? <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-winkingsmile" alt="Winking smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Should-I-learn-Silverlight-HTML-5_9026/wlEmoticon-winkingsmile_2.png" />
</p>
<p>
To summarize, I think learning XAML is time well spent. Today that’s WPF or Silverlight.
There is absolutely no doubt that Silverlight is closer to WinRT than WPF, and people
building SL apps today will have an easier time migrating them to WinRT later, whereas
most WPF apps will be a pretty big rewrite.
</p>
<p>
But there’s nothing wrong with focusing yourself on h5/js. If you do so, I suggest
doing it in a way that ignores or minimizes all server-side coding. If h5/js <i>does</i> take
over the world, it will be used to create pure smart client apps, and if there’s a
“web server” involved at all, it will exist purely as a deployment server for the
client app. The ‘pure’ h5/js/jquery/etc. world isn’t linked to any vendor – not Microsoft,
Apple, or anyone. To me this represents a pretty major career shift, because to truly
embrace h5/js as a complete software development platform is so demanding (imo) it
won’t leave time to retain .NET or other vendor-specific technology expertise.
</p>
<p>
For my part, I’m not yet ready to abandon Microsoft for h5/js, because I think Windows
8, WinRT, .NET, and XAML have a rather bright future. A year from now I think a lot
of people will be happily using Windows 8 desktops, laptops, and tablets – and hopefully
a lot of Windows Phones, and with luck we’ll be looking forward to some cool new Xbox.
I live in (I think realistic) hope that my .NET/XAML skills will apply to all these
platforms.
</p>
<p>
What does your crystal ball say?
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=04a35ef0-345e-4c5a-bfaf-70a6b7883107" />ProgrammingWindows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=de88eb90-3010-4e69-950f-eba0dfed0b7bhttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,de88eb90-3010-4e69-950f-eba0dfed0b7b.aspxRockford Lhotka

The lack of the BindingExpression type and related functionality in WinRT is a serious
issue to anyone trying to create custom controls. Hopefully this issue will be resolved
post-beta.

Sadly, the only information I’ve been able to find on this topic from Microsoft is
the suggestion to use LostFocus event handlers instead of binding. Obviously that’s
a pretty useless workaround when trying to create a custom control

I started writing a data binding engine for Android (because they don’t have one at
all). It would be a serious shame if we’re forced to write a data binding engine for
XAML in WinRT just to be able to implement basic custom control concepts…

No BindingExpression in WinRT?http://www.lhotka.net/weblog/PermaLink,guid,de88eb90-3010-4e69-950f-eba0dfed0b7b.aspxhttp://www.lhotka.net/weblog/NoBindingExpressionInWinRT.aspx
Mon, 23 Apr 2012 22:10:32 GMT<p>
The lack of the BindingExpression type and related functionality in WinRT is a serious
issue to anyone trying to create custom controls. Hopefully this issue will be resolved
post-beta.
</p>
<p>
Sadly, the only information I’ve been able to find on this topic from Microsoft is
the suggestion to use LostFocus event handlers instead of binding. Obviously that’s
a pretty useless workaround when trying to create a custom control <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-sadsmile" alt="Sad smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/No-BindingExpression-in-WinRT_F137/wlEmoticon-sadsmile_2.png" />
</p>
<p>
I started writing a data binding engine for Android (because they don’t have one at
all). It would be a serious shame if we’re forced to write a data binding engine for
XAML in WinRT just to be able to implement basic custom control concepts…
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=de88eb90-3010-4e69-950f-eba0dfed0b7b" />WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=af9641c9-6f00-482e-a7a6-1c3b2fb66865http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,af9641c9-6f00-482e-a7a6-1c3b2fb66865.aspxRockford Lhotka

I've been watching a number of discussion threads regarding the usability of Windows
8, especially regarding the start screen, Desktop application usage, and multi-monitor
scenarios.

All I can say is don’t knock it until you try it.

I’ve been running Win8 on my tablet and laptop for a few weeks now. The work I do
on my laptop is often multi-monitor, and is real work.

There are three themes I’d like to address, based on my full-time usage experience
thus far.

First, some people feel that Microsoft is making a mistake by having WinRT (Metro
style) and Desktop apps run on the same machine at the same time. I vehemently disagree.
I absolutely want one machine that I can use as a tablet on the plane, and
as a real computer when I get to my destination. My tablet does this (Samsung from
//build/) for almost everything, except when I’m doing distributed computing demos
and need my full laptop to run virtual machines (because my laptop has tons of memory
and an i7, vs the tablet with less memory and an i5).

I love the fact that I have WinRT apps, which are far superior to most web sites,
for consuming news, weather, etc. And I love the fact that the same machine, plugged
into a small portable dock, has a keyboard, mouse, second monitor, and can run Visual
Studio just fine!

Second, there’s this idea floating around that the Win7 start menu is superior to
the new Win8 start screen. That doesn’t hold true for me. Let me explain why.

When I read the Microsoft blog post about the Win7 telemetry data they used to design
the start screen, they were describing me. When I use Win7 I pin my common apps and
web sites to the start bar, and to run any other apps I press the Windows key and
type part of the application name, then press enter. Almost never do I actually use
the start menu to browse for apps.

In Win8 (keyboard/mouse – desktop/laptop computer) I pin my common desktop apps to
the start bar, and my WinRT apps to the first page or two of the start screen. And
I still press the Windows key and type the first part of the application name to run
other applications. In other words, THERE IS NO DIFFERENCE between Win7 and Win8 from
my perspective – other than that the live tiles from news/weather/stocks/etc. make
the start screen a useful dashboard – so it is BETTER than Win7.

(as an aside, I do have some Desktop apps on my start page tiles too – but I find
that I rarely use those tiles, preferring instead to tap the Desktop tile and then
launch from the start bar – a personal quirk I suppose)

Third, the multi-monitor problems aren’t as bad as they are being portrayed. But the
story isn’t good either, and I truly hope it improves over the next few months.

If you are doing “real work” today, you are probably spending 90% of your time (or
more) in desktop mode. And if you’ve pinned your common apps to the start bar (like
Win7, and I have done this) then you’ll probably never leave desktop mode. And in
this case, multi-monitor works just like Win7, but slightly better because the start
bar works better in Win8 (or at least it has new options I find useful).

Where the multi-monitor falls down is if you are using a mix of WinRT apps and Desktop
applications at the same time.

WinRT only runs on the primary monitor, and that’s just lame. It completely prevents
the use of WinRT for many business scenarios where multi-monitor is critical. I honestly
don’t expect this to get fixed in WinRT v1, but I hope we don’t have to wait for Windows
9 (2014?) for this to be solved, because it is a major blocker for WinRT development
in the real world.

Between the Dev and Consumer previews, they did change the way WinRT apps use the
primary monitor. At least now in the Consumer preview it is possible to keep a WinRT
app running on the primary monitor while using a Desktop app on other monitors. I
do find though, that it is too easy for some errant Desktop app to use the primary
monitor, thus making the WinRT app disappear – and this is frustrating.

Sadly it is not possible to keep the start page visible while using a Desktop app
on a secondary monitor – reducing its otherwise high value as a dashboard L

To summarize the multi-monitor scenario: if you are a Desktop app user, Win8 is as
good or better than Win7, because you’ll only see the start screen when you press
the Windows key to launch some non-pinned app. If you are a WinRT user multi-monitor
is useless. If you are a hybrid user (like me) the experience is workable, but unpredictable
and frustrating.

Clearly Microsoft needs to do more work in this area.

In final summary, don’t knock it until you try it full-time on real machines. The
experience overall is quite good, and I VERY much like having WinRT apps that I can
use on my main computer instead of using web pages with their inferior usability and
aesthetics. Given that most of my main laptop usage is in Visual Studio, Word, and
PowerPoint, I find the experience with multi-monitor to be adequate, and Win8 is just
as productive for those scenarios as Win7.

Windows 8, Start Screen, Multi-Monitor Usabilityhttp://www.lhotka.net/weblog/PermaLink,guid,af9641c9-6f00-482e-a7a6-1c3b2fb66865.aspxhttp://www.lhotka.net/weblog/Windows8StartScreenMultiMonitorUsability.aspx
Fri, 06 Apr 2012 15:50:13 GMT<p>
I've been watching a number of discussion threads regarding the usability of Windows
8, especially regarding the start screen, Desktop application usage, and multi-monitor
scenarios.
</p>
<p>
All I can say is don’t knock it until you try it.
</p>
<p>
I’ve been running Win8 on my tablet and laptop for a few weeks now. The work I do
on my laptop is often multi-monitor, and is real work.
</p>
<p>
There are three themes I’d like to address, based on my full-time usage experience
thus far.
</p>
<p>
First, some people feel that Microsoft is making a mistake by having WinRT (Metro
style) and Desktop apps run on the same machine at the same time. I vehemently disagree.
I <i>absolutely</i> want one machine that I can use as a tablet on the plane, and
as a real computer when I get to my destination. My tablet does this (Samsung from
//build/) for almost everything, except when I’m doing distributed computing demos
and need my full laptop to run virtual machines (because my laptop has tons of memory
and an i7, vs the tablet with less memory and an i5).
</p>
<p>
I love the fact that I have WinRT apps, which are far superior to most web sites,
for consuming news, weather, etc. And I love the fact that the same machine, plugged
into a small portable dock, has a keyboard, mouse, second monitor, and can run Visual
Studio just fine!
</p>
<p>
Second, there’s this idea floating around that the Win7 start menu is superior to
the new Win8 start screen. That doesn’t hold true for me. Let me explain why.
</p>
<p>
When I read the Microsoft blog post about the Win7 telemetry data they used to design
the start screen, they were describing me. When I use Win7 I pin my common apps and
web sites to the start bar, and to run any other apps I press the Windows key and
type part of the application name, then press enter. Almost never do I actually use
the start menu to browse for apps.
</p>
<p>
In Win8 (keyboard/mouse – desktop/laptop computer) I pin my common desktop apps to
the start bar, and my WinRT apps to the first page or two of the start screen. And
I still press the Windows key and type the first part of the application name to run
other applications. In other words, THERE IS NO DIFFERENCE between Win7 and Win8 from
my perspective – other than that the live tiles from news/weather/stocks/etc. make
the start screen a useful dashboard – so it is BETTER than Win7.
</p>
<p>
(as an aside, I do have some Desktop apps on my start page tiles too – but I find
that I rarely use those tiles, preferring instead to tap the Desktop tile and then
launch from the start bar – a personal quirk I suppose)
</p>
<p>
Third, the multi-monitor problems aren’t as bad as they are being portrayed. But the
story isn’t good either, and I truly hope it improves over the next few months.
</p>
<p>
If you are doing “real work” today, you are probably spending 90% of your time (or
more) in desktop mode. And if you’ve pinned your common apps to the start bar (like
Win7, and I have done this) then you’ll probably never leave desktop mode. And in
this case, multi-monitor works just like Win7, but slightly better because the start
bar works better in Win8 (or at least it has new options I find useful).
</p>
<p>
Where the multi-monitor falls down is if you are using a mix of WinRT apps and Desktop
applications at the same time.
</p>
<p>
WinRT only runs on the primary monitor, and that’s just lame. It completely prevents
the use of WinRT for many business scenarios where multi-monitor is critical. I honestly
don’t expect this to get fixed in WinRT v1, but I hope we don’t have to wait for Windows
9 (2014?) for this to be solved, because it is a major blocker for WinRT development
in the real world.
</p>
<p>
Between the Dev and Consumer previews, they did change the way WinRT apps use the
primary monitor. At least now in the Consumer preview it is possible to keep a WinRT
app running on the primary monitor while using a Desktop app on other monitors. I
do find though, that it is too easy for some errant Desktop app to use the primary
monitor, thus making the WinRT app disappear – and this is frustrating.
</p>
<p>
Sadly it is not possible to keep the start page visible while using a Desktop app
on a secondary monitor – reducing its otherwise high value as a dashboard L
</p>
<p>
To summarize the multi-monitor scenario: if you are a Desktop app user, Win8 is as
good or better than Win7, because you’ll only see the start screen when you press
the Windows key to launch some non-pinned app. If you are a WinRT user multi-monitor
is useless. If you are a hybrid user (like me) the experience is workable, but unpredictable
and frustrating.
</p>
<p>
Clearly Microsoft needs to do more work in this area.
</p>
<p>
In final summary, don’t knock it until you try it full-time on real machines. The
experience overall is quite good, and I VERY much like having WinRT apps that I can
use on my main computer instead of using web pages with their inferior usability and
aesthetics. Given that most of my main laptop usage is in Visual Studio, Word, and
PowerPoint, I find the experience with multi-monitor to be adequate, and Win8 is just
as productive for those scenarios as Win7.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=af9641c9-6f00-482e-a7a6-1c3b2fb66865" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=ab0b2564-5286-4deb-a98f-98124c3598achttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,ab0b2564-5286-4deb-a98f-98124c3598ac.aspxRockford Lhotka

I’ve been spending quite a bit of time working with WinRT over the past couple weeks.
Specifically prepping for next week’s Visual Studio
Live! and VS Connections conferences.

As part of this process, I have a super early version of CSLA 4 version 4.5 that builds
and (mostly) runs on WinRT. I’d done a lot of the work months ago when the Windows
8 developer preview came out, so getting it to work on the consumer preview took only
a couple hours.

The only new feature I’ve added so far is support for the new async and await keywords
for WinRT data portal code. I still need to add async/await support for the .NET data
portal. I might refine some of my implementation, but right now I can use async/await
to call the data portal in WinRT, and that’s cool!

The primary observation I want to make right now though, is that business classes
created using CSLA 4 that target Silverlight will now recompile for WinRT with no
code changes required. I took the entire ProjectTracker business library project and
just recompiled it for WinRT and it works – unchanged.

If you want direct reuse of your business
logic from .NET/Silverlight to WinRT, you should consider using CSLA 4.

Because I did add the async/await data portal support, I chose to add async factory
methods to my business classes, alongside the existing .NET and Silverlight factory
methods. From a porting/reuse perspective this is not necessary, but in terms of writing
new code for .NET 4.5 and/or WinRT I think we’ll all tend to write these async factory
methods.

This allows the viewmodel or other presentation layer code to retrieve business objects
like this:

var obj = await ProjectList.GetProjectListAsync();

No need for async callback handlers or the other messy goo from a typical WPF/Silverlight
application. Of course WPF 4.5 will be able to use the await keyword too, so only
SL/WP7 will still require the callback handler model when all is said and done.

Although these are early days, and I am still working through all the features of
CSLA .NET to make sure they work on WinRT, it is nice to know that data binding, business/validation
rules, and the data portal are all functional already. I expect to still do some work
around authorization rules, and the local data portal implementation – but the vast
majority of CSLA 4 functionality is already working just fine on WinRT and that makes
me very happy!

Early findings going from Silverlight to WinRThttp://www.lhotka.net/weblog/PermaLink,guid,e9b66040-ee7a-4abb-977c-c1410e8ce18c.aspxhttp://www.lhotka.net/weblog/EarlyFindingsGoingFromSilverlightToWinRT.aspx
Wed, 21 Mar 2012 14:49:28 GMT<p>
I’ve been spending quite a bit of time working with WinRT over the past couple weeks.
Specifically prepping for next week’s <a href="http://www.vslive.com/">Visual Studio
Live!</a> and <a href="http://www.devconnections.com/">VS Connections</a> conferences.
</p>
<p>
As part of this process, I have a super early version of CSLA 4 version 4.5 that builds
and (mostly) runs on WinRT. I’d done a lot of the work months ago when the Windows
8 developer preview came out, so getting it to work on the consumer preview took only
a couple hours.
</p>
<p>
The only new feature I’ve added so far is support for the new async and await keywords
for WinRT data portal code. I still need to add async/await support for the .NET data
portal. I might refine some of my implementation, but right now I can use async/await
to call the data portal in WinRT, and that’s cool!
</p>
<p>
The primary observation I want to make right now though, is that business classes
created using CSLA 4 that target Silverlight will now recompile for WinRT with no
code changes required. I took the entire ProjectTracker business library project and
just recompiled it for WinRT and it works – unchanged.
</p>
<blockquote>
<p>
<strong><font style="background-color: #ffff00">If you want direct reuse of your business
logic from .NET/Silverlight to WinRT, you should consider using CSLA 4.</font></strong>
</p>
</blockquote>
<p>
Because I did add the async/await data portal support, I chose to add async factory
methods to my business classes, alongside the existing .NET and Silverlight factory
methods. From a porting/reuse perspective this is not necessary, but in terms of writing
new code for .NET 4.5 and/or WinRT I think we’ll all tend to write these async factory
methods.
</p>
<p>
In short, I added code like this:
</p>
<blockquote>
<p>
<font face="Courier New">#if WINRT
<br />
&#160;&#160;&#160; public async static System.Threading.Tasks.Task&lt;ProjectList&gt;
GetProjectListAsync()
<br />
&#160;&#160;&#160; {
<br />
&#160;&#160;&#160;&#160;&#160; return await Csla.DataPortal.FetchAsync&lt;ProjectTracker.Library.ProjectList&gt;();
<br />
&#160;&#160;&#160; }
<br />
#endif
<br />
</font>
</p>
</blockquote>
<p>
This allows the viewmodel or other presentation layer code to retrieve business objects
like this:
</p>
<blockquote>
<p>
<font face="Courier New">var obj = await ProjectList.GetProjectListAsync();</font>
</p>
</blockquote>
<p>
No need for async callback handlers or the other messy goo from a typical WPF/Silverlight
application. Of course WPF 4.5 will be able to use the await keyword too, so only
SL/WP7 will still require the callback handler model when all is said and done.
</p>
<p>
Although these are early days, and I am still working through all the features of
CSLA .NET to make sure they work on WinRT, it is nice to know that data binding, business/validation
rules, and the data portal are all functional already. I expect to still do some work
around authorization rules, and the local data portal implementation – but the vast
majority of CSLA 4 functionality is already working just fine on WinRT and that makes
me very happy!
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=e9b66040-ee7a-4abb-977c-c1410e8ce18c" />CSLA .NETWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=597819aa-1569-477a-af6e-cd2abd70f20dhttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,597819aa-1569-477a-af6e-cd2abd70f20d.aspxRockford Lhotka

One issue I’ve encountered while building Metro-style WinRT apps on Windows 8 is the
need to have my app interact with a WCF service running on the same machine.

This is obviously a common scenario for any n-tier or SOA app development. The challenge
we face is that WinRT apps are blocked from calling back to localhost (127.0.0.1).
The challenge and solution are described here:

The author makes some valid points. Most notably, in the consumer preview there are
a ton of inconsistencies where the user is dumped into legacy mode (sorry, Desktop
mode) when doing things as common as setting up a printer. That’s clearly confusing,
and Microsoft has their work cut out to replace all the OS dialogs between now and
release.

And the fact that there’s no obvious way out of Desktop mode once you get there is
a problem. If you happen to accidentally get your mouse in the far lower-left corner
of the screen you might escape, otherwise normal users just get trapped there with
no way out. That’s pretty silly.

But toward the end of the article he makes an observation that I think is completely
faulty:

“I don’t see touch being that important of a driver to either sell new PCs or
a new operating system. Outside of Microsoft and a small number of power users, I
don’t really see a demand for touch for PCs from either enterprise of consumer markets.
Instead, what we have is Microsoft trying — once again — to stir up interest in touch
devices.”

Apparently the author hasn’t noticed the massive uptake of iPad and Kindle Fire devices
all over the place – at the consumer and corporate level. It is an understatement
to say that demand exists for touch devices, and it would be absurd to think Microsoft
would ignore that demand.

Or perhaps the author is suggesting that nobody wants a PC with touch. That they’d
rather carry a PC for work, and a totally different type of device for touch? That
is possible, but it seems unlikely that people would choose to spend twice
the money and carry twice the hardware just to have two different experiences – at
least if they have a choice of carrying one device that is good for work and play.

There are many reasons I’m motivated to see Windows 8 be successful (though I agree
that success isn’t a foregone conclusion). Perhaps the biggest though, is apps. For
touch, keyboard, and mouse, I want apps.

Why?

Because apps are the resurgence of the smart client and distributed computing. And
there are no apps on the PC, so PC users are increasingly stuck using the second-class
web interfaces to interact with the world.

Take almost anything – news, weather, stocks, social services like Facebook – you
name it. PC users have to interact with these things via the web, reducing their super-powerful
PC to a dumb terminal. But mobile device users get rich, smooth apps that are a lot
more fun to use.

Given a choice, would you interact with Facebook via a web UI, or a nice app with
clear navigation, nice animations, and well-considered user interaction? People have
spoken – Facebook apps for tablets and phones are the primary way to interact with
the social service over the web UI.

As a PC user I am increasingly left out. Left to suffer with browser-based experiences
while my wife uses her iPad to interact with the same services in a more enjoyable
manner.

It seems obvious now that apps will never come to the Win32/.NET PC world. So the
only way to have decent interaction with the world at large is to figure out a way
to get apps on the PC – and that is clearly via WinRT and Metro.

I think the lack of apps on the PC is because there’s no store, so no easy way to
find and install such apps. Microsoft could have created an app store for Windows
7, but Win7 doesn’t offer a fully sandboxed runtime environment where such apps can
be virus and harm-free to the end user.

I also think Microsoft could have created such a sandbox world based on Silverlight,
without the need to create a whole new operating system. It would have been possible
to enable Silverlight apps to be directly hosted on Win7, and to be purchased from
a centralized and curated store.

But that wouldn’t have addressed the tablet and touch issues.

So what we’ve got is a new operating system, with a runtime designed from the ground
up to support safe apps that are deployed from a store. And from a .NET developer
perspective this new Windows Runtime (WinRT) is extremely close to Silverlight in
terms of its development model. So in a sense Microsoft is doing exactly what you’d
expect to enable apps – but they are also enabling tablets and touch.

In short, I am looking forward to Windows 8 because it breathes new life into the
smart client and distributed computing world – and because as a user I can finally
get a first-class experience for interacting with news, weather, and social services
on the “web”.

Why I want Windows 8 on my PChttp://www.lhotka.net/weblog/PermaLink,guid,bd6898d1-cbc2-4f02-a0f3-3a97486d3168.aspxhttp://www.lhotka.net/weblog/WhyIWantWindows8OnMyPC.aspx
Tue, 13 Mar 2012 15:56:44 GMT<p>
I just read this article about what’s wrong with Windows 8:
</p>
<p>
<a title="http://www.zdnet.com/blog/hardware/heres-whats-wrong-with-windows-8/19027?tag=nl.e539" href="http://www.zdnet.com/blog/hardware/heres-whats-wrong-with-windows-8/19027?tag=nl.e539">http://www.zdnet.com/blog/hardware/heres-whats-wrong-with-windows-8/19027?tag=nl.e539</a>
</p>
<p>
The author makes some valid points. Most notably, in the consumer preview there are
a ton of inconsistencies where the user is dumped into legacy mode (sorry, Desktop
mode) when doing things as common as setting up a printer. That’s clearly confusing,
and Microsoft has their work cut out to replace all the OS dialogs between now and
release.
</p>
<p>
And the fact that there’s no obvious way out of Desktop mode once you get there is
a problem. If you happen to accidentally get your mouse in the far lower-left corner
of the screen you might escape, otherwise normal users just get trapped there with
no way out. That’s pretty silly.
</p>
<p>
But toward the end of the article he makes an observation that I think is completely
faulty:
</p>
<blockquote>
<p>
<em>“I don’t see touch being that important of a driver to either sell new PCs or
a new operating system. Outside of Microsoft and a small number of power users, I
don’t really see a demand for touch for PCs from either enterprise of consumer markets.
Instead, what we have is Microsoft trying — once again — to stir up interest in touch
devices.”</em>
</p>
</blockquote>
<p>
Apparently the author hasn’t noticed the massive uptake of iPad and Kindle Fire devices
all over the place – at the consumer and corporate level. It is an understatement
to say that demand exists for touch devices, and it would be absurd to think Microsoft
would ignore that demand.
</p>
<p>
Or perhaps the author is suggesting that nobody wants a PC with touch. That they’d
rather carry a PC for work, and a totally different type of device for touch? That
is possible, but it seems unlikely that people would <em>choose</em> to spend twice
the money and carry twice the hardware just to have two different experiences – at
least if they have a choice of carrying one device that is good for work and play.
</p>
<p>
There are many reasons I’m motivated to see Windows 8 be successful (though I agree
that success isn’t a foregone conclusion). Perhaps the biggest though, is apps. For
touch, keyboard, and mouse, I want apps.
</p>
<p>
Why?
</p>
<p>
Because apps are the resurgence of the smart client and distributed computing. And
there are no apps on the PC, so PC users are increasingly stuck using the second-class
web interfaces to interact with the world.
</p>
<p>
Take almost anything – news, weather, stocks, social services like Facebook – you
name it. PC users have to interact with these things via the web, reducing their super-powerful
PC to a dumb terminal. But mobile device users get rich, smooth apps that are a lot
more fun to use.
</p>
<p>
Given a choice, would you interact with Facebook via a web UI, or a nice app with
clear navigation, nice animations, and well-considered user interaction? People have
spoken – Facebook apps for tablets and phones are the primary way to interact with
the social service over the web UI.
</p>
<p>
As a PC user I am increasingly left out. Left to suffer with browser-based experiences
while my wife uses her iPad to interact with the same services in a more enjoyable
manner.
</p>
<p>
It seems obvious now that apps will never come to the Win32/.NET PC world. So the
only way to have decent interaction with the world at large is to figure out a way
to get apps on the PC – and that is clearly via WinRT and Metro.
</p>
<p>
I think the lack of apps on the PC is because there’s no store, so no easy way to
find and install such apps. Microsoft could have created an app store for Windows
7, but Win7 doesn’t offer a fully sandboxed runtime environment where such apps can
be virus and harm-free to the end user.
</p>
<p>
I also think Microsoft could have created such a sandbox world based on Silverlight,
without the need to create a whole new operating system. It would have been possible
to enable Silverlight apps to be directly hosted on Win7, and to be purchased from
a centralized and curated store.
</p>
<p>
But that wouldn’t have addressed the tablet and touch issues.
</p>
<p>
So what we’ve got is a new operating system, with a runtime designed from the ground
up to support safe apps that are deployed from a store. And from a .NET developer
perspective this new Windows Runtime (WinRT) is extremely close to Silverlight in
terms of its development model. So in a sense Microsoft is doing exactly what you’d
expect to enable apps – but they are also enabling tablets and touch.
</p>
<p>
In short, I am looking forward to Windows 8 because it breathes new life into the
smart client and distributed computing world – and because as a user I can finally
get a first-class experience for interacting with news, weather, and social services
on the “web”.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=bd6898d1-cbc2-4f02-a0f3-3a97486d3168" />Windows 8WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=0b924ed7-c5ae-4285-be44-2fe2ec047632http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,0b924ed7-c5ae-4285-be44-2fe2ec047632.aspxRockford Lhotka

I’ve spent a couple days using Windows 8 on my laptop now. And I’ve been using it
on my tablet for a long time (Dev Preview and now Consumer Preview).

To get this out of the way right off: Windows 8 is clearly designed for tablets first,
and desktop/laptop machines second. I really enjoy using it on the tablet, and it
is fine on the laptop, but perhaps not as nice as Windows 7.

Performance

It is (or feels) faster than Win7 on the same machine. Win8 is just snappy. Microsoft
likes the phrase “fast and fluid”, and it is fluid with touch, but it is snappy with
keyboard/mouse.

Desktop usage

I’ve now pinned my common apps to the desktop start bar, just like I did with Win7.
I had all my apps pinned in Win7 too, and rarely used the Start menu to launch anything,
and the same is true in Win8.

I am finding that I rarely leave the desktop at all really. So in that regard, Win8
is just a slightly faster Win7. Most of what I’ve been doing has involved the use
of Outlook, Word, Excel, IE, and Visual Studio – all of which run happily on the desktop,
and so I often forget that I’m running Win8.

WinRT Metro style usage

When I do leave the desktop for WinRT, it has been to launch apps so I can pin them
on the desktop start bar, or to play around with the various Metro style apps available.
I’ve already discussed how pinning the apps on the desktop leads to a Win7-like experience,
so I’ll now move on to my thoughts on using the Metro style apps with keyboard/mouse.

By way of disclaimer, I find the various Metro style apps to be incredibly inconsistent
on both the tablet and laptop. They are clearly all works in progress. Some are better
than others, but the lack of consistency in terms of the “back” concept and general
navigation is really annoying. Microsoft has a lot of work to do just to get their
own Metro style apps to be consistent and pleasant, and I don’t know how they will
convince the creators of other apps to do a better job…

(as an aside, iPad users have told me that they are often frustrated with the lack
of consistency across iPad apps too – so maybe this is just the future we’re embracing
– one where every app makes up its own rules and us users have to just suck it up…)

“Back” concept frustration

My biggest issue with Metro style apps is the “back” concept.
This comes in two forms: there are two “back” concepts, and apps don’t consistently
implement the “back” concept they control.

First, a left-swipe is “back” to the previous app, and this is an OS concept. And
apps can implement their own “back” concept, often with an arrow pointing left, or
an X icon, or something else – and that moves you back within the context of the
app.

Having these two back concepts isn’t so bad until one app launches another. The most
common scenario is the People hub launching IE. So I was in the People hub, reading
what people have been doing, now I’m in IE. I might click on a couple links in IE
too. So now I can use the IE back button to move back through IE, but I (the human
user) have to know to use a left-swipe to get back to the People hub. Personally I
find this jarring and frustrating. Especially when compared to Windows Phone, where
the back button would take me back through the web pages, and then back to the People
hub. Smooth and consistent.

(I suspect it is too late in the game for Microsoft to address this issue – but I
also suspect it will be the butt of jokes about Win8 UX design for the next decade
or so, because it is a serious PITA)

To make this whole thing worse, the “back” concept implemented by each app is really
under the app’s control. And every app seems to make up their own way to handle the
scenario. Some examples:

The back button is always visible in the upper-left of the UI, wasting space, and
not near my thumb (on the tablet) so I have to shift my hands to go back – yuck!

The back button is in the app bar, but in the top bar, not the bottom, forcing me
to swipe or right-click in the app bar, then shift my hands to go back – super yuck!

The back button is in the upper-right corner (either ways visible or in the app bar)
– which is amazingly terrible!

The back button is in the app bar in the lower-left, forcing me to swipe or right-click
in the app bar, but at least I don’t have to shift my hands – this is so so…

On a laptop, I’m constantly moving my mouse this way and that to find and click the
back/close buttons where ever a particular app decided to put the button.

Personally, I think Microsoft should have put a Back button on the actual device like
they did on the phone. Or the left-swipe should be back for the app, and then the
OS, more like the WP7 back button… Again, I suspect we’re just in for a lot of pain
and jokes for years to come

Mouse support

The start screen and most Metro style apps provide some basic support for the mouse.
Nothing spectacular, but there are scrollbars for panning and scrolling and they work
fine. Right-click is like swiping in the app bar with touch.

Some things are still easier with the mouse, like selecting something and interacting
with it. Much more precise and reliable with the mouse than with touch.

On the whole, the mouse support in Metro style apps is adequate, but not particularly
good. That’s true for the start screen and all the other apps I tried.

Update: After installing the touchpad driver and enabling the various
scroll/pan/zoom/rotate gestures supported by the touchpad, I am finding the “mouse”
experience to be much more satisfying in Metro style apps. I’m not sure if this really
counts, because these aren’t technically “mouse” gestures. But for a laptop user with
a decent touchpad (like on my Dell), this does make a big difference.

Keyboard “support”

The start screen has a bunch of Windows key shortcuts for the keyboard. Learn these
and the start screen becomes quite pleasant (imo) for a keyboard/mouse user. The start
screen’s mouse support is limited, but with the keyboard shortcuts it is easy to be
fast and productive from the start screen.

Individual apps do or don’t work with the keyboard much or at all. Few of the apps
seem to take the keyboard into account much at all, and others use the keyboard, but
not in a way I find intuitive.

For example, the US News app (which is visually stunning) uses left and right arrow
keys to move between news stories. But there doesn’t seem to be any way to use the
keyboard to pan the current story left or right. Because all stories must be panned
left to read the text, the result is that you must use the mouse and scrollbar
to read the story. That’s just lame.

I’d have expected left/right arrows to pan the story, and perhaps page-up/down to
move between stories.

Other apps do use left/right arrow to pan the current item, but usually at such a
slow rate of panning as to be useless.

I know, these apps were rushed out so they could be in the store for the Consumer
Preview launch. And I’m sure the primary focus was on touch, not keyboard/mouse support.

On the other hand, I’m hoping that by recording my thoughts and experiences as a laptop
user, future versions of these apps, and other future apps, will remember that desktop/laptop
users will run Win8 too, and that these apps need to support non-touch devices as
well as touch.

Metro style summary

Microsoft has made it clear that their intent is for Metro style apps to
treat touch as a first-class interaction model. Other than the apps having the consistency
of the web in 1997 (which is to say none), I would say that they’ve achieved that
goal. These apps are all about touch.

But Microsoft also made it clear that their intent is for keyboard/mouse to be a first-class
interaction model. The start screen certainly treats the keyboard as first-class.
The mouse is probably second-class at this point. Individual Metro style apps are
pretty much completely treating keyboard/mouse as an afterthought – let’s go with
third-class.

So this is a call to Microsoft to stick with their intent and to keep pushing the
keyboard/mouse and touch models in parallel and with parity.

And even more, this is a reminder to all of us app developers that it is our responsibility to
ensure that keyboard/mouse and touch users are all happy with our user experience
designs.

Finally, it is a call to Microsoft to do something about the horrible “back”
concept issue. Again, I recognize it is probably too late to fix the dual model issue.
But at least provide some STRONG guidance (and a consistent example in your own apps)
on how to implement the application back concept. For lack of anything better, my
vote is for an always-visible button in the lower-left of the screen. Don’t make me
bring up the app bar, and really don’t make me shift my hands to reach the
top (left or right) of the screen.

Close

To close, I am finding Win8 to be a perfectly good beta experience. Is it ready for
prime time? Of course not, it is a beta. If you install it on a machine can you be
productive and happy? Absolutely yes.

This is especially true if you (like me) are already used to pinning your common apps
to the desktop start bar. Do that, and you’ll hardly know you are running Win8 at
all.

The immature state of the Metro style apps doesn’t really worry me. As more and more
people use these apps and provide feedback like I’m doing here, the user experiences
provided by those (and future) apps will improve for touch and keyboard/mouse users
alike.

I’m quite excited about Win8 and WinRT and the future of the platform. It really does
bring user experience into the forefront of application development. The difference
between apps that have attention to UX and those that don’t is the difference between
a usable app and one that sucks productivity and joy from life.

It is now up to all of us as developers to recognize this reality, and to provide
a UX that does bring joy and productivity to our users – keyboard, mouse, or touch.

Windows 8 on a laptophttp://www.lhotka.net/weblog/PermaLink,guid,0b924ed7-c5ae-4285-be44-2fe2ec047632.aspxhttp://www.lhotka.net/weblog/Windows8OnALaptop.aspx
Wed, 07 Mar 2012 22:48:41 GMT<p>
I’ve spent a couple days using Windows 8 on my laptop now. And I’ve been using it
on my tablet for a long time (Dev Preview and now Consumer Preview).
</p>
<p>
To get this out of the way right off: Windows 8 is clearly designed for tablets first,
and desktop/laptop machines second. I really enjoy using it on the tablet, and it
is fine on the laptop, but perhaps not as nice as Windows 7.
</p>
<h3>Performance
</h3>
<p>
It is (or feels) faster than Win7 on the same machine. Win8 is just snappy. Microsoft
likes the phrase “fast and fluid”, and it is fluid with touch, but it is snappy with
keyboard/mouse.
</p>
<h3>Desktop usage
</h3>
<p>
I’ve now pinned my common apps to the desktop start bar, just like I did with Win7.
I had all my apps pinned in Win7 too, and rarely used the Start menu to launch anything,
and the same is true in Win8.
</p>
<p>
I am finding that I rarely leave the desktop at all really. So in that regard, Win8
is just a slightly faster Win7. Most of what I’ve been doing has involved the use
of Outlook, Word, Excel, IE, and Visual Studio – all of which run happily on the desktop,
and so I often forget that I’m running Win8.
</p>
<h3>WinRT Metro style usage
</h3>
<p>
When I do leave the desktop for WinRT, it has been to launch apps so I can pin them
on the desktop start bar, or to play around with the various Metro style apps available.
I’ve already discussed how pinning the apps on the desktop leads to a Win7-like experience,
so I’ll now move on to my thoughts on using the Metro style apps with keyboard/mouse.
</p>
<p>
By way of disclaimer, I find the various Metro style apps to be incredibly inconsistent
on both the tablet and laptop. They are clearly all works in progress. Some are better
than others, but the lack of consistency in terms of the “back” concept and general
navigation is really annoying. Microsoft has a lot of work to do just to get their
own Metro style apps to be consistent and pleasant, and I don’t know how they will
convince the creators of other apps to do a better job…
</p>
<p>
(as an aside, iPad users have told me that they are often frustrated with the lack
of consistency across iPad apps too – so maybe this is just the future we’re embracing
– one where every app makes up its own rules and us users have to just suck it up…)
</p>
<h3>“Back” concept frustration
</h3>
<p>
<sub></sub><sub></sub>My biggest issue with Metro style apps is the “back” concept.
This comes in two forms: there are two “back” concepts, and apps don’t consistently
implement the “back” concept they control.
</p>
<p>
First, a left-swipe is “back” to the previous app, and this is an OS concept. And
apps can implement their own “back” concept, often with an arrow pointing left, or
an X icon, or something else – and that moves you back <em>within the context of the
app</em>.
</p>
<p>
Having these two back concepts isn’t so bad until one app launches another. The most
common scenario is the People hub launching IE. So I was in the People hub, reading
what people have been doing, now I’m in IE. I might click on a couple links in IE
too. So now I can use the IE back button to move back through IE, but I (the human
user) have to know to use a left-swipe to get back to the People hub. Personally I
find this jarring and frustrating. Especially when compared to Windows Phone, where
the back button would take me back through the web pages, and then back to the People
hub. Smooth and consistent.
</p>
<p>
(I suspect it is too late in the game for Microsoft to address this issue – but I
also suspect it will be the butt of jokes about Win8 UX design for the next decade
or so, because it is a serious PITA)
</p>
<p>
To make this whole thing worse, the “back” concept implemented by each app is really
under the app’s control. And every app seems to make up their own way to handle the
scenario. Some examples:
</p>
<ul>
<li>
The back button is always visible in the upper-left of the UI, wasting space, and
not near my thumb (on the tablet) so I have to shift my hands to go back – yuck!
</li>
<li>
The back button is in the app bar, but in the top bar, not the bottom, forcing me
to swipe or right-click in the app bar, then shift my hands to go back – super yuck!
</li>
<li>
The back button is in the upper-right corner (either ways visible or in the app bar)
– which is amazingly terrible!
</li>
<li>
The back button is in the app bar in the lower-left, forcing me to swipe or right-click
in the app bar, but at least I don’t have to shift my hands – this is so so…
</li>
</ul>
<p>
On a laptop, I’m constantly moving my mouse this way and that to find and click the
back/close buttons where ever a particular app decided to put the button.
</p>
<p>
Personally, I think Microsoft should have put a Back button on the actual device like
they did on the phone. Or the left-swipe should be back for the app, and then the
OS, more like the WP7 back button… Again, I suspect we’re just in for a lot of pain
and jokes for years to come <img class="wlEmoticon wlEmoticon-sadsmile" style="border-top-style: none; border-bottom-style: none; border-right-style: none; border-left-style: none" alt="Sad smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8-on-a-laptop_E309/wlEmoticon-sadsmile_2.png" />
</p>
<h3>Mouse support
</h3>
<p>
The start screen and most Metro style apps provide some basic support for the mouse.
Nothing spectacular, but there are scrollbars for panning and scrolling and they work
fine. Right-click is like swiping in the app bar with touch.
</p>
<p>
Some things are still easier with the mouse, like selecting something and interacting
with it. Much more precise and reliable with the mouse than with touch.
</p>
<p>
On the whole, the mouse support in Metro style apps is adequate, but not particularly
good. That’s true for the start screen and all the other apps I tried.
</p>
<p>
<strong>Update:</strong> After installing the touchpad driver and enabling the various
scroll/pan/zoom/rotate gestures supported by the touchpad, I am finding the “mouse”
experience to be much more satisfying in Metro style apps. I’m not sure if this really
counts, because these aren’t technically “mouse” gestures. But for a laptop user with
a decent touchpad (like on my Dell), this does make a big difference.
</p>
<h3>Keyboard “support”
</h3>
<p>
The start screen has a bunch of Windows key shortcuts for the keyboard. Learn these
and the start screen becomes quite pleasant (imo) for a keyboard/mouse user. The start
screen’s mouse support is limited, but with the keyboard shortcuts it is easy to be
fast and productive from the start screen.
</p>
<p>
Individual apps do or don’t work with the keyboard much or at all. Few of the apps
seem to take the keyboard into account much at all, and others use the keyboard, but
not in a way I find intuitive.
</p>
<p>
For example, the US News app (which is visually stunning) uses left and right arrow
keys to move between news stories. But there doesn’t seem to be any way to use the
keyboard to pan the current story left or right. Because all stories must be panned
left to read the text, the result is that you <em>must</em> use the mouse and scrollbar
to read the story. That’s just lame.
</p>
<p>
I’d have expected left/right arrows to pan the story, and perhaps page-up/down to
move between stories.
</p>
<p>
Other apps do use left/right arrow to pan the current item, but usually at such a
slow rate of panning as to be useless.
</p>
<p>
I know, these apps were rushed out so they could be in the store for the Consumer
Preview launch. And I’m sure the primary focus was on touch, not keyboard/mouse support.
</p>
<p>
On the other hand, I’m hoping that by recording my thoughts and experiences as a laptop
user, future versions of these apps, and other future apps, will remember that desktop/laptop
users will run Win8 too, and that these apps need to support non-touch devices as
well as touch.
</p>
<h3>Metro style summary
</h3>
<p>
Microsoft has made it clear that their <em>intent</em> is for Metro style apps to
treat touch as a first-class interaction model. Other than the apps having the consistency
of the web in 1997 (which is to say none), I would say that they’ve achieved that
goal. These apps are all about touch.
</p>
<p>
But Microsoft also made it clear that their intent is for keyboard/mouse to be a first-class
interaction model. The start screen certainly treats the keyboard as first-class.
The mouse is probably second-class at this point. Individual Metro style apps are
pretty much completely treating keyboard/mouse as an afterthought – let’s go with
third-class.
</p>
<p>
So this is a call to Microsoft to stick with their intent and to keep pushing the
keyboard/mouse and touch models <em>in parallel</em> and <em>with parity</em>.
</p>
<p>
And even more, this is a reminder to all of us app developers that <em>it is our responsibility</em> to
ensure that keyboard/mouse and touch users are all happy with our user experience
designs.
</p>
<p>
Finally, it is a call to Microsoft to do <em>something</em> about the horrible “back”
concept issue. Again, I recognize it is probably too late to fix the dual model issue.
But at least provide some STRONG guidance (and a consistent example in your own apps)
on how to implement the application back concept. For lack of anything better, my
vote is for an always-visible button in the lower-left of the screen. Don’t make me
bring up the app bar, and <em>really</em> don’t make me shift my hands to reach the
top (left or right) of the screen.
</p>
<h3>Close
</h3>
<p>
To close, I am finding Win8 to be a perfectly good beta experience. Is it ready for
prime time? Of course not, it is a beta. If you install it on a machine can you be
productive and happy? Absolutely yes.
</p>
<p>
This is especially true if you (like me) are already used to pinning your common apps
to the desktop start bar. Do that, and you’ll hardly know you are running Win8 at
all.
</p>
<p>
The immature state of the Metro style apps doesn’t really worry me. As more and more
people use these apps and provide feedback like I’m doing here, the user experiences
provided by those (and future) apps will improve for touch and keyboard/mouse users
alike.
</p>
<p>
I’m quite excited about Win8 and WinRT and the future of the platform. It really does
bring user experience into the forefront of application development. The difference
between apps that have attention to UX and those that don’t is the difference between
a usable app and one that sucks productivity and joy from life.
</p>
<p>
It is now up to all of us as developers to recognize this reality, and to provide
a UX that does bring joy and productivity to our users – keyboard, mouse, or touch.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=0b924ed7-c5ae-4285-be44-2fe2ec047632" />WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=ff21aa43-f048-49d5-9d11-7518d2e2bae1http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,ff21aa43-f048-49d5-9d11-7518d2e2bae1.aspxRockford Lhotka

At a time when many organizations are moving from Windows XP or 2000 to Windows 7,
the last thing a lot of people want to think about is Windows 8. At the same time,
it is incredibly clear that the future of client computing is undergoing a major shift
thanks to the rapid growth of iPad and other tablet devices. Windows 8 is not only
the next desktop operating system from Microsoft, but it is also Microsoft’s answer
to this substantial shift toward low-power touch-based client devices.

This change impacts not only the operating system, but the underlying application
development model. The new Windows Runtime (WinRT) development platform represents
an evolution for .NET developers, and a significant shift for non-.NET developers.

Realistically, enterprises should expect two things. First, the enterprise desktop/laptop
platform will most likely continue its shift to Windows 7, and may remain on Windows
7 for many years. Second, the enterprise is already forced to deal with iPad and other
tablet devices, and they’ll need to deal with (or embrace) Windows 8 tablets in the
same way.

To the first point, I think it unlikely that most organizations will roll out Windows
8 on a broad scale to desktops or laptops. Most organizations are just now moving
from XP/2000 to Windows 7, only because those ancient operating systems will soon
be entirely unsupported. It is not realistic to think that organizations will immediately
move from Windows 7 to Windows 8. It is more realistic to think that they’ll be on
Windows 7 for 5-10 years, and will then move to “Windows 11” or something along that
line.

As a result, organizations will be building and maintaining applications using Microsoft
.NET (WPF, Silverlight, Windows Forms) for many years to come. There is no WinRT for
Windows 7, so that new development platform will be off limits for mainstream enterprise
application development targeting the desktop/laptop space in the foreseeable future.

To the second point, the reality that end users in organizations will acquire and
use tablets on their own, if not supplied by the organization, is already happening.
The flood gates are open, and organizations are now left to deal with the results.
A chaotic landscape composed of iPads, random incompatible Android devices, and soon
Windows 8 devices.

This is where things get interesting. Windows 8 on Intel devices can run the same
.NET applications as a desktop or laptop. They can also run WinRT applications, which
(when built using .NET) are extremely similar to Silverlight applications. Windows
8 on ARM devices will only run WinRT applications.

iPad and Android devices require completely different application development using
tools unlike .NET. No code or functionality sharing between existing .NET desktop/laptop
applications and these platforms is possible. Truly embracing these platforms means
building up duplicate development staff for Objective C and Java, or switching entirely
away from traditional smart client development to a pure HTML5 model. Sadly, HTML5
isn’t compatible across all these devices either, so even that isn’t an obvious solution.

In reality, it might be less expensive for organizations to buy employees Windows
8 tablets than to pay developers to re-implement applications across multiple platforms,
and to then support those multiple implementations over time. In fact, I suspect it
will almost always be cheaper to spring for a few Windows 8 tablets than to pay for
duplicate software development and maintenance forever.

To achieve the broadest reach, Windows 8 apps should target WinRT. That allows the
apps to run on Intel and ARM devices. As I mentioned earlier, when using .NET to build
WinRT applications, the development model is very similar to Silverlight. This means
that existing WPF and Silverlight developers will have a relatively easy time shifting
to WinRT, and substantial amounts of Silverlight application code will often just
work on WinRT.

Frameworks such as CSLA .NET provide even more cross-platform compatibility. For example,
the business logic code for applications written using CSLA 4 that target Silverlight
will just recompile for WinRT, usually with no changes required at all. The vast majority
of business logic from WPF or Windows Forms applications written using CSLA 4 will
also just recompile for WinRT.

In summary, Windows 8 represents a major factor in enterprise application development
strategy. In the short term, it might offer a lower-cost way to get users onto tablets
without the high cost of duplicate software development, or dealing with the cross-platform
HTML5 issues. In the long term, WinRT appears to be Microsoft’s new strategic development
platform, so organizations need to be considering how to move to this platform over
a period of years.

Windows 8 and enterprise app dev strategyhttp://www.lhotka.net/weblog/PermaLink,guid,ff21aa43-f048-49d5-9d11-7518d2e2bae1.aspxhttp://www.lhotka.net/weblog/Windows8AndEnterpriseAppDevStrategy.aspx
Wed, 07 Mar 2012 19:36:50 GMT<p>
At a time when many organizations are moving from Windows XP or 2000 to Windows 7,
the last thing a lot of people want to think about is Windows 8. At the same time,
it is incredibly clear that the future of client computing is undergoing a major shift
thanks to the rapid growth of iPad and other tablet devices. Windows 8 is not only
the next desktop operating system from Microsoft, but it is also Microsoft’s answer
to this substantial shift toward low-power touch-based client devices.
</p>
<p>
This change impacts not only the operating system, but the underlying application
development model. The new Windows Runtime (WinRT) development platform represents
an evolution for .NET developers, and a significant shift for non-.NET developers.
</p>
<p>
Realistically, enterprises should expect two things. First, the enterprise desktop/laptop
platform will most likely continue its shift to Windows 7, and may remain on Windows
7 for many years. Second, the enterprise is already forced to deal with iPad and other
tablet devices, and they’ll need to deal with (or embrace) Windows 8 tablets in the
same way.
</p>
<p>
To the first point, I think it unlikely that most organizations will roll out Windows
8 on a broad scale to desktops or laptops. Most organizations are just now moving
from XP/2000 to Windows 7, only because those ancient operating systems will soon
be entirely unsupported. It is not realistic to think that organizations will immediately
move from Windows 7 to Windows 8. It is more realistic to think that they’ll be on
Windows 7 for 5-10 years, and will then move to “Windows 11” or something along that
line.
</p>
<p>
As a result, organizations will be building and maintaining applications using Microsoft
.NET (WPF, Silverlight, Windows Forms) for many years to come. There is no WinRT for
Windows 7, so that new development platform will be off limits for mainstream enterprise
application development targeting the desktop/laptop space in the foreseeable future.
</p>
<p>
To the second point, the reality that end users in organizations will acquire and
use tablets on their own, if not supplied by the organization, is already happening.
The flood gates are open, and organizations are now left to deal with the results.
A chaotic landscape composed of iPads, random incompatible Android devices, and soon
Windows 8 devices.
</p>
<p>
This is where things get interesting. Windows 8 on Intel devices can run the same
.NET applications as a desktop or laptop. They can also run WinRT applications, which
(when built using .NET) are extremely similar to Silverlight applications. Windows
8 on ARM devices will only run WinRT applications.
</p>
<p>
iPad and Android devices require completely different application development using
tools unlike .NET. No code or functionality sharing between existing .NET desktop/laptop
applications and these platforms is possible. Truly embracing these platforms means
building up duplicate development staff for Objective C and Java, or switching entirely
away from traditional smart client development to a pure HTML5 model. Sadly, HTML5
isn’t compatible across all these devices either, so even that isn’t an obvious solution.
</p>
<p>
In reality, it might be less expensive for organizations to buy employees Windows
8 tablets than to pay developers to re-implement applications across multiple platforms,
and to then support those multiple implementations over time. In fact, I suspect it
will almost always be cheaper to spring for a few Windows 8 tablets than to pay for
duplicate software development and maintenance forever.
</p>
<p>
To achieve the broadest reach, Windows 8 apps should target WinRT. That allows the
apps to run on Intel and ARM devices. As I mentioned earlier, when using .NET to build
WinRT applications, the development model is very similar to Silverlight. This means
that existing WPF and Silverlight developers will have a relatively easy time shifting
to WinRT, and substantial amounts of Silverlight application code will often just
work on WinRT.
</p>
<p>
Frameworks such as CSLA .NET provide even more cross-platform compatibility. For example,
the business logic code for applications written using CSLA 4 that target Silverlight
will just recompile for WinRT, usually with no changes required at all. The vast majority
of business logic from WPF or Windows Forms applications written using CSLA 4 will
also just recompile for WinRT.
</p>
<p>
In summary, Windows 8 represents a major factor in enterprise application development
strategy. In the short term, it might offer a lower-cost way to get users onto tablets
without the high cost of duplicate software development, or dealing with the cross-platform
HTML5 issues. In the long term, WinRT appears to be Microsoft’s new strategic development
platform, so organizations need to be considering how to move to this platform over
a period of years.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=ff21aa43-f048-49d5-9d11-7518d2e2bae1" />CSLA .NETWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=92574020-6c8a-4089-bf44-bfe9963ac15ahttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,92574020-6c8a-4089-bf44-bfe9963ac15a.aspxRockford Lhotka

I’ve now installed the Windows 8 Consumer Preview four times on three machines.

First, I did a reimage of the tablet I got at //build/ last fall.
That was a smooth and seamless process, and I’m really enjoying using Windows 8 on
the tablet.

Second, I did an install into a VirtualBox virtual machine on my
main desktop. This is not satisfying. The CP release is slower in VirtualBox than
the Dev Preview was, and so I’ve already deleted the virtual machine. Clearly we’re
at a point where a VM just isn’t going to cut it unless you are desperate. (the alternative
is boot from vhd, and people seem to be having good luck with that)

In short, I don’t think I’ll mess with trying to run Win8 in a VM anymore.

Third, I did an upgrade of my Win7 laptop to Win8. This seemed to
go very smoothly, but ultimately was a failure. Issues I encountered include:

I couldn’t link my Magenic domain user to a Microsoft user, so some apps (like SkyDrive)
just didn’t work at all, and others kept prompting me for credentials

I couldn’t get a dev license from VS11 to debug Metro style apps in WinRT

The login process took forever and a day – every time; I’m not sure what it was doing,
but it was really slow

Other hard-to-define quirky issues that I didn’t see on the tablet – minor stuff that
would be annoying long-term

The inability to get a developer license key for Metro style apps was obviously a
show-stopper. I know other people who’ve gotten a key on machines joined to a domain,
so I doubt that was the issue. My current working theory is that something gets messed
up (or got messed up in my case) when upgrading from Win7.

In short, I don’t think I’ll be upgrading from Win7 to Win8 again.

Fourth, I did a fresh Win8 install on my laptop. This also went smoothly,
though I have some concerns about it automatically getting all the right drivers (like
for the motherboard chipset and power control). I guess we’ll see what happens there.

On the whole, running Win8 on a laptop is an adequate experience. The new start screen
isn’t as friendly to a mouse as to touch, but it works.

On my tablet and laptop I’ve installed Office 2010 and Lync. These applications appear
to work just fine, though they are obviously ill-suited for touch-based usage.

I’ve also installed Visual Studio 11 three times now.

First, I installed it on the tablet. That was a fresh Win8 image, and VS11 installed
and ran without a hitch.

Second, I installed it on the upgraded laptop. That was a side-by-side install with
an existing VS10 installation. The VS11 install went without a hitch, but as I mentioned
earlier, I was unable to get a developer license key for Metro style apps, so it was
pretty useless.

Third, I installed it on the reimaged laptop – but after installing VS10 SP1 again.
So again, a side-by-side install. The VS11 install went without a hitch, and I’m now
happily working on Metro style apps targeting WinRT.

Windows 8 CP install experiencehttp://www.lhotka.net/weblog/PermaLink,guid,92574020-6c8a-4089-bf44-bfe9963ac15a.aspxhttp://www.lhotka.net/weblog/Windows8CPInstallExperience.aspx
Tue, 06 Mar 2012 02:20:26 GMT<p>
I’ve now installed the Windows 8 Consumer Preview four times on three machines.
</p>
<p>
<strong>First</strong>, I did a reimage of the tablet I got at //build/ last fall.
That was a smooth and seamless process, and I’m really enjoying using Windows 8 on
the tablet.
</p>
<p>
<strong>Second</strong>, I did an install into a VirtualBox virtual machine on my
main desktop. This is not satisfying. The CP release is slower in VirtualBox than
the Dev Preview was, and so I’ve already deleted the virtual machine. Clearly we’re
at a point where a VM just isn’t going to cut it unless you are desperate. (the alternative
is boot from vhd, and people seem to be having good luck with that)
</p>
<p>
In short, I don’t think I’ll mess with trying to run Win8 in a VM anymore.
</p>
<p>
<strong>Third</strong>, I did an upgrade of my Win7 laptop to Win8. This seemed to
go very smoothly, but ultimately was a failure. Issues I encountered include:
</p>
<ul>
<li>
I couldn’t link my Magenic domain user to a Microsoft user, so some apps (like SkyDrive)
just didn’t work at all, and others kept prompting me for credentials</li>
<li>
I couldn’t get a dev license from VS11 to debug Metro style apps in WinRT</li>
<li>
The login process took forever and a day – every time; I’m not sure what it was doing,
but it was really slow</li>
<li>
Other hard-to-define quirky issues that I didn’t see on the tablet – minor stuff that
would be annoying long-term</li>
</ul>
<p>
The inability to get a developer license key for Metro style apps was obviously a
show-stopper. I know other people who’ve gotten a key on machines joined to a domain,
so I doubt that was the issue. My current working theory is that something gets messed
up (or got messed up in my case) when upgrading from Win7.
</p>
<p>
In short, I don’t think I’ll be upgrading from Win7 to Win8 again.
</p>
<p>
<strong>Fourth</strong>, I did a fresh Win8 install on my laptop. This also went smoothly,
though I have some concerns about it automatically getting all the right drivers (like
for the motherboard chipset and power control). I guess we’ll see what happens there.
</p>
<p>
On the whole, running Win8 on a laptop is an adequate experience. The new start screen
isn’t as friendly to a mouse as to touch, but it works.
</p>
<p>
On my tablet and laptop I’ve installed Office 2010 and Lync. These applications appear
to work just fine, though they are obviously ill-suited for touch-based usage.
</p>
<p>
I’ve also installed Visual Studio 11 three times now.
</p>
<p>
First, I installed it on the tablet. That was a fresh Win8 image, and VS11 installed
and ran without a hitch.
</p>
<p>
Second, I installed it on the upgraded laptop. That was a side-by-side install with
an existing VS10 installation. The VS11 install went without a hitch, but as I mentioned
earlier, I was unable to get a developer license key for Metro style apps, so it was
pretty useless.
</p>
<p>
Third, I installed it on the reimaged laptop – but after installing VS10 SP1 again.
So again, a side-by-side install. The VS11 install went without a hitch, and I’m now
happily working on Metro style apps targeting WinRT.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=92574020-6c8a-4089-bf44-bfe9963ac15a" />WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=4605d505-63af-4bcc-9b35-67b786dfcec9http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,4605d505-63af-4bcc-9b35-67b786dfcec9.aspxRockford Lhotka

I have been working with some of my colleagues at Magenic to write a whitepaper that
summarizes our view on how “Windows 8” and WinRT affect existing Microsoft developers.

If you’ve read my previous WinRT
related blog posts you’ll see that the whitepaper is similar, but provides more
formal analysis and information in a presentable format.

Windows 8 and WinRT development whitepaperhttp://www.lhotka.net/weblog/PermaLink,guid,4605d505-63af-4bcc-9b35-67b786dfcec9.aspxhttp://www.lhotka.net/weblog/Windows8AndWinRTDevelopmentWhitepaper.aspx
Wed, 30 Nov 2011 16:33:35 GMT<p>
I have been working with some of my colleagues at Magenic to write a whitepaper that
summarizes our view on how “Windows 8” and WinRT affect existing Microsoft developers.
</p>
<p>
<a href="http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx">http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx</a>
</p>
<p>
If you’ve read my previous <a href="http://www.lhotka.net/weblog/Windows8BlogSummary.aspx">WinRT
related blog posts</a> you’ll see that the whitepaper is similar, but provides more
formal analysis and information in a presentable format.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=4605d505-63af-4bcc-9b35-67b786dfcec9" />WinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=2461dff3-e39c-4bd2-9279-12c349a04395http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,2461dff3-e39c-4bd2-9279-12c349a04395.aspxRockford Lhotka

One of the primary goals for CSLA 4 version 4.3 (the next version we’ll be creating)
is to improve the performance of the MobileFormattter that is used for Silverlight
and Windows Phone applications. This is made all the more important, because it will
also be used in WinRT applications in the future.

Sergey (a CSLA dev team member, and Magenic colleague) has been doing some heavy research
into this area, and we’d originally thought to do the changes as part of the 4.2 release.
It turns out that doing a really great job of optimization will require some breaking
changes – at least for people who aren’t using managed backing fields. So we are deferring
the bigger changes until 4.3.

In the meantime, Sergey has blogged about how
to improve performance of MobileFormatter in 3.8 and 4 (4.0, 4.1, or 4.2). These
are changes you can make to your CSLA codebase now if you want some of the performance
benefits without waiting for the “big change” that’ll come in 4.3.

Improving CSLA 4 MobileFormatter behaviorhttp://www.lhotka.net/weblog/PermaLink,guid,2461dff3-e39c-4bd2-9279-12c349a04395.aspxhttp://www.lhotka.net/weblog/ImprovingCSLA4MobileFormatterBehavior.aspx
Sat, 12 Nov 2011 18:41:27 GMT<p>
One of the primary goals for CSLA 4 version 4.3 (the next version we’ll be creating)
is to improve the performance of the MobileFormattter that is used for Silverlight
and Windows Phone applications. This is made all the more important, because it will
also be used in WinRT applications in the future.
</p>
<p>
Sergey (a CSLA dev team member, and Magenic colleague) has been doing some heavy research
into this area, and we’d originally thought to do the changes as part of the 4.2 release.
It turns out that doing a really great job of optimization will require some breaking
changes – at least for people who aren’t using managed backing fields. So we are deferring
the bigger changes until 4.3.
</p>
<p>
In the meantime, Sergey has blogged about <a href="http://dotnetspeak.com/index.php/2011/11/how-to-improve-performance-of-csla-for-silverlight/">how
to improve performance of MobileFormatter</a> in 3.8 and 4 (4.0, 4.1, or 4.2). These
are changes you can make to your CSLA codebase now if you want some of the performance
benefits without waiting for the “big change” that’ll come in 4.3.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=2461dff3-e39c-4bd2-9279-12c349a04395" />CSLA .NETSilverlightWindows PhoneWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=e94b8c16-d9eb-4698-b928-beee7cbf2c35http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,e94b8c16-d9eb-4698-b928-beee7cbf2c35.aspxRockford Lhotka

Joe writes a nice summary of why a web app is not a web page – it is something different,
and in important ways.

This distinction becomes very important when considering building H5/js apps on WinRT
in Windows 8, or if you believe (in general) that H5/js will replace existing dev
platforms like Java and .NET. For that to happen, we have to stop thinking about HTML
and js as web technologies – they must be thought of as general purpose technologies
that sometimes happen to be used on the web too.

Web sites vs Web appshttp://www.lhotka.net/weblog/PermaLink,guid,e94b8c16-d9eb-4698-b928-beee7cbf2c35.aspxhttp://www.lhotka.net/weblog/WebSitesVsWebApps.aspx
Wed, 09 Nov 2011 16:10:01 GMT<p>
Joe writes a nice summary of why a web app is not a web page – it is something different,
and in important ways.
</p>
<p>
<a title="http://www.misfitgeek.com/2011/11/html5-app-versus-html5-page/" href="http://www.misfitgeek.com/2011/11/html5-app-versus-html5-page/">http://www.misfitgeek.com/2011/11/html5-app-versus-html5-page/</a>
</p>
<p>
This distinction becomes very important when considering building H5/js apps on WinRT
in Windows 8, or if you believe (in general) that H5/js will replace existing dev
platforms like Java and .NET. For that to happen, we have to stop thinking about HTML
and js as web technologies – they must be thought of as general purpose technologies
that sometimes happen to be used on the web too.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=e94b8c16-d9eb-4698-b928-beee7cbf2c35" />WebWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=12925691-3e22-41e2-9d8f-a66c115e8b8chttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,12925691-3e22-41e2-9d8f-a66c115e8b8c.aspxRockford Lhotka

Disclaimer: I know nothing. The following is (hopefully) well educated speculation
on my part. Time will tell whether I’m right.

I really like Silverlight. I’ve been a strong proponent of Silverlight
since 2007 when I rushed to port CSLA .NET to the new platform.

In fact, Magenic provided me with a dev and test team to make that transition happen,
because we all saw the amazing potential of Silverlight.

And it has been a good few years.

But let’s face reality. Microsoft has invested who-knows-how-much money to build WinRT,
and no matter how you look at it, WinRT is the replacement for Win32. That means all
the stuff that runs on Win32 is “dead”. This includes Silverlight, Windows Forms,
WPF, console apps – everything.

I wouldn’t be surprised if Silverlight 5 was the last version. I also wouldn’t be
surprised if .NET 4.5 was the last version for the Win32 client, and that future versions
of .NET were released for servers and Azure only.

Before you panic though, remember that VB6 has been “dead” for well over a decade.
It died at the PDC in 1999, along with COM. But you still use VB6 and/or COM? Or at
least you know organizations who do? How can that be when it is dead??

That’s my point. “dead” isn’t really dead.

Just how long do you think people (like me and you) will continue to run Win32-based
operating systems and applications? At least 10 years, and many will probably run
15-20 years into the future. This is the rate of change that exists in the corporate
world. At least that’s been my observation for the past couple decades.

Microsoft supports their technologies for 10 years after a final release. So even
if SL5 is the end (and they haven’t said it is), that gives us 10 years of supported
Silverlight usage. The same for the other various .NET and Win32 technologies.

That’s plenty of time for Microsoft to get WinRT mature, and to allow us to migrate
to that platform over a period of years.

I don’t expect WinRT 1.0 (the Windows 8 version) to be capable of replacing Win32
or .NET. I rather expect it to be pretty crippled in many respects. Much like VB 1.0
(and 2.0), .NET 1.0 and 1.1, Silverlight 1 and 2, etc.

But Windows 9 or Windows 10 (WinRT 2.0 or 3.0) should be quite capable of replacing
Win32 and .NET and Silverlight.

If we assume Win8 comes out in 2012, and that Microsoft does a forced march release
of 9 and 10 every two years, that means 2016 will give us WinRT 3.0. And if we hold
to the basic truism that Microsoft always gets it right on their third release, that’ll
be the one to target.

I think it is also reasonable to expect that Win9 and Win10 will probably continue
to have the “blue side” (see my Windows
8 dev platform post), meaning Win32, .NET, and Silverlight will continue to be
released and therefore supported over that time. They may not change over
that time, but they’ll be there, and they’ll be supported – or so goes my theory.

This means that in 2016 the clock might really start for migration from Win32/.NET/Silverlight
to WinRT.

Yes, I expect that a lot of us will build things for WinRT sooner than 2016. I certainly
hope so, because it looks like a lot of fun!

But from a corporate perspective, where things move so slowly, this is probably good
news. Certain apps can be ported sooner, but big and important apps can move slowly
over time.

What to do in the meantime? Between now and 2016?

Focus on XAML, and on n-tier or SOA async server access as architectural models.

Or focus on HTML 5 (soon to be HTML 6 fwiw, and possibly HTML 7 by 2016 for all we
know).

In fact, the plan is for a version 4.3 release to support Silverlight 5, then version
4.5 with support for .NET 4.5 and WinRT.

I suspect that you can use Silverlight or WPF as a bridge to WinRT. The real key is
architecture.

An n-tier architecture is fine, as long as the data access layer is running on a server,
and the client uses async calls to interact with the server. WinRT requires a lot
of async, at a minimum all server interactions. Silverlight forces you to adopt this
architecture already, so it is a natural fit. WPF doesn’t force the issue, but you
can choose to do “the right thing”.

You can also build your client applications to be “edge applications” – on the edge
of a service-oriented system. This is a less mature technology area, and it is more
costly. But it is also a fine architecture for environments composed of many disparate
applications that need to interact as a loosely coupled system. Again, all service
interactions by the edge applications (the ones running on the clients) must be async.

Or you can build “hybrid solutions”, where individual applications are built using
n-tier architectures (with async server calls). And where some of those applications
also expose service interfaces so they can participate as part of a broader service-oriented
system.

I favor option 3. I don’t like to accept the cost and performance ramifications of
SOA when building an application, so I’d prefer to use a faster and cheaper
n-tier architecture. At the same time, many applications do need to interact with
each other, and the requirement to create “application mashups” through edge applications
happens from time to time. So building my n-tier applications to have dual interfaces
(XAML and JSON for example) is a perfect compromise.

The direct users of my application get n-tier performance and maintainability. And
the broader organization can access my slower-moving, standards-based, contractual
service interface. It is the best of both worlds.

So do I care if Silverlight 5 is the last version of Silverlight?

Only if WPF continues to evolve prior to us all moving to WinRT. If WPF continues
to evolve, I would expect Silverlight to, at a minimum, keep up. Otherwise Microsoft
has led a lot of people down a dead-end path, and that’s a serious betrayal of trust.

But if my suspicions are correct, we won’t see anything but bug fixes for WPF or Silverlight
for many years. I rather expect that these two technologies just became the next Windows
Forms. You’ll notice that WinForms hasn’t had anything but bug fixes for 6 years right?
The precedent is there for a UI technology to be “supported, stable, and stagnant”
for a very long time, and this is my expectation for WPF/SL.

And if that’s the case, then I don’t care at all about a Silverlight 6 release. We
can use WPF/SL in their current form, right up to the point that WinRT is stable and
capable enough to act as a replacement for today’s Win32/.NET applications.

Silverlight 6 doesn&rsquo;t matterhttp://www.lhotka.net/weblog/PermaLink,guid,12925691-3e22-41e2-9d8f-a66c115e8b8c.aspxhttp://www.lhotka.net/weblog/Silverlight6DoesnrsquotMatter.aspx
Wed, 09 Nov 2011 02:51:12 GMT<p>
<em>Disclaimer: I know nothing. The following is (hopefully) well educated speculation
on my part. Time will tell whether I’m right.</em>
</p>
<p>
I really like Silverlight. I’ve been a strong proponent of <sub></sub>Silverlight
since 2007 when I rushed to port CSLA .NET to the new platform.
</p>
<p>
In fact, Magenic provided me with a dev and test team to make that transition happen,
because we all saw the amazing potential of Silverlight.
</p>
<p>
And it has been a good few years.
</p>
<p>
But let’s face reality. Microsoft has invested who-knows-how-much money to build WinRT,
and no matter how you look at it, WinRT is the replacement for Win32. That means all
the stuff that runs on Win32 is “dead”. This includes Silverlight, Windows Forms,
WPF, console apps – everything.
</p>
<p>
(this is partially in answer to <a href="http://www.zdnet.com/blog/microsoft/will-there-be-a-silverlight-6-and-does-it-matter/11180">Mary-Jo’s
article on Silverlight 5</a>)
</p>
<p>
I wouldn’t be surprised if Silverlight 5 was the last version. I also wouldn’t be
surprised if .NET 4.5 was the last version for the Win32 client, and that future versions
of .NET were released for servers and Azure only.
</p>
<p>
Before you panic though, remember that VB6 has been “dead” for well over a decade.
It died at the PDC in 1999, along with COM. But you still use VB6 and/or COM? Or at
least you know organizations who do? How can that be when it is dead??
</p>
<p>
That’s my point. “dead” isn’t really dead.
</p>
<p>
Just how long do you think people (like me and you) will continue to run Win32-based
operating systems and applications? At least 10 years, and many will probably run
15-20 years into the future. This is the rate of change that exists in the corporate
world. At least that’s been my observation for the past couple decades.
</p>
<p>
Microsoft supports their technologies for 10 years after a final release. So even
if SL5 is the end (and they haven’t said it is), that gives us 10 years of supported
Silverlight usage. The same for the other various .NET and Win32 technologies.
</p>
<p>
That’s plenty of time for Microsoft to get WinRT mature, and to allow us to migrate
to that platform over a period of years.
</p>
<p>
I don’t expect WinRT 1.0 (the Windows 8 version) to be capable of replacing Win32
or .NET. I rather expect it to be pretty crippled in many respects. Much like VB 1.0
(and 2.0), .NET 1.0 and 1.1, Silverlight 1 and 2, etc.
</p>
<p>
But Windows 9 or Windows 10 (WinRT 2.0 or 3.0) should be quite capable of replacing
Win32 and .NET and Silverlight.
</p>
<p>
If we assume Win8 comes out in 2012, and that Microsoft does a forced march release
of 9 and 10 every two years, that means 2016 will give us WinRT 3.0. And if we hold
to the basic truism that Microsoft always gets it right on their third release, that’ll
be the one to target.
</p>
<p>
I think it is also reasonable to expect that Win9 and Win10 will probably continue
to have the “blue side” (see my <a href="http://www.lhotka.net/weblog/UpdatedWin8DevPlatformDiagram.aspx">Windows
8 dev platform</a> post), meaning Win32, .NET, and Silverlight will continue to be
released and therefore supported over that time. They may not <em>change</em> over
that time, but they’ll be there, and they’ll be supported – or so goes my theory.
</p>
<p>
This means that in 2016 the clock might really start for migration from Win32/.NET/Silverlight
to WinRT.
</p>
<p>
Yes, I expect that a lot of us will build things for WinRT sooner than 2016. I certainly
hope so, because it looks like a lot of fun!
</p>
<p>
But from a corporate perspective, where things move so slowly, this is probably good
news. Certain apps can be ported sooner, but big and important apps can move slowly
over time.
</p>
<p>
What to do in the meantime? Between now and 2016?
</p>
<p>
Focus on XAML, and on n-tier or SOA async server access as architectural models.
</p>
<p>
Or focus on HTML 5 (soon to be HTML 6 fwiw, and possibly HTML 7 by 2016 for all we
know).
</p>
<p>
I’m focusing on XAML, creating a CSLA 4 version 4.5 release that supports .NET 4.5
on servers, Azure, Windows (Win32), and Windows (WinRT). And Silverlight 5 of course.
</p>
<p>
In fact, the plan is for a version 4.3 release to support Silverlight 5, then version
4.5 with support for .NET 4.5 and WinRT.
</p>
<p>
I suspect that you can use Silverlight or WPF as a bridge to WinRT. The real key is
architecture.
</p>
<ol>
<li>
An n-tier architecture is fine, as long as the data access layer is running on a server,
and the client uses async calls to interact with the server. WinRT requires a lot
of async, at a minimum all server interactions. Silverlight forces you to adopt this
architecture already, so it is a natural fit. WPF doesn’t force the issue, but you
can choose to do “the right thing”.</li>
<li>
You can also build your client applications to be “edge applications” – on the edge
of a service-oriented system. This is a less mature technology area, and it is more
costly. But it is also a fine architecture for environments composed of many disparate
applications that need to interact as a loosely coupled system. Again, all service
interactions by the edge applications (the ones running on the clients) must be async.</li>
<li>
Or you can build “hybrid solutions”, where individual applications are built using
n-tier architectures (with async server calls). And where <em>some</em> of those applications
also expose service interfaces so they can participate as part of a broader service-oriented
system.</li>
</ol>
<p>
I favor option 3. I don’t like to accept the cost and performance ramifications of
SOA when building <em>an application</em>, so I’d prefer to use a faster and cheaper
n-tier architecture. At the same time, many applications do need to interact with
each other, and the requirement to create “application mashups” through edge applications
happens from time to time. So building my n-tier applications to have dual interfaces
(XAML and JSON for example) is a perfect compromise.
</p>
<p>
The direct users of my application get n-tier performance and maintainability. And
the broader organization can access my slower-moving, standards-based, contractual
service interface. It is the best of both worlds.
</p>
<p>
So do I care if Silverlight 5 is the last version of Silverlight?
</p>
<p>
Only if WPF continues to evolve prior to us all moving to WinRT. If WPF continues
to evolve, I would expect Silverlight to, at a minimum, keep up. Otherwise Microsoft
has led a lot of people down a dead-end path, and that’s a serious betrayal of trust.
</p>
<p>
But if my suspicions are correct, we won’t see anything but bug fixes for WPF or Silverlight
for many years. I rather expect that these two technologies just became the next Windows
Forms. You’ll notice that WinForms hasn’t had anything but bug fixes for 6 years right?
The precedent is there for a UI technology to be “supported, stable, and stagnant”
for a very long time, and this is my expectation for WPF/SL.
</p>
<p>
And if that’s the case, then I don’t care at all about a Silverlight 6 release. We
can use WPF/SL in their current form, right up to the point that WinRT is stable and
capable enough to act as a replacement for today’s Win32/.NET applications.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=12925691-3e22-41e2-9d8f-a66c115e8b8c" />ArchitectureCSLA .NETMicrosoft .NETSilverlightWinRTWPFhttp://www.lhotka.net/weblog/Trackback.aspx?guid=1f835c0f-f720-4704-910c-3a7d8e86dc68http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,1f835c0f-f720-4704-910c-3a7d8e86dc68.aspxRockford Lhotka

Based on comments from my previous Windows
8 Development Platform blog post (thank you to Shawn and Slavo in particular),
here’s an updated Magenic diagram.

This one adds the Chakra js engine to the WinRT and desktop sides of the diagram,
and it expands the detail of WinRT and Win32 to include things like COM, GDI+, and
DirectX.

The result is that DirectX and GDI+ are duplicated – they are shown as a presentation
technology at the top (which is valid), and as a core part of the OS APIs too (which
is also valid). I’m not entirely sure that this adds clarity (or causes confusion?),
but it seems like a reasonable addition to me based on Shawn’s comments.

The DirectX/GDI+ addition is directly valuable (I think), because it clearly illustrates
that GDI+ is a Win32 thing, and doesn’t exist in the WinRT world.

Updated Win 8 Dev Platform diagramhttp://www.lhotka.net/weblog/PermaLink,guid,1f835c0f-f720-4704-910c-3a7d8e86dc68.aspxhttp://www.lhotka.net/weblog/UpdatedWin8DevPlatformDiagram.aspx
Tue, 25 Oct 2011 16:28:14 GMT<p>
Based on comments from my previous <a href="http://www.lhotka.net/weblog/Windows8DevelopmentPlatformClarified.aspx">Windows
8 Development Platform</a> blog post (thank you to Shawn and Slavo in particular),
here’s an updated Magenic diagram.
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Updated-Win-8-Dev-Platform-diagram_9FF8/image_2.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Updated-Win-8-Dev-Platform-diagram_9FF8/image_thumb.png" width="342" height="191" /></a>
</p>
<p>
This one adds the Chakra js engine to the WinRT and desktop sides of the diagram,
and it expands the detail of WinRT and Win32 to include things like COM, GDI+, and
DirectX.
</p>
<p>
The result is that DirectX and GDI+ are duplicated – they are shown as a presentation
technology at the top (which is valid), and as a core part of the OS APIs too (which
is also valid). I’m not entirely sure that this adds clarity (or causes confusion?),
but it seems like a reasonable addition to me based on Shawn’s comments.
</p>
<p>
The DirectX/GDI+ addition is directly valuable (I think), because it clearly illustrates
that GDI+ is a Win32 thing, and doesn’t exist in the WinRT world.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=1f835c0f-f720-4704-910c-3a7d8e86dc68" />MagenicWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=37980542-4e6c-4a85-840e-7cd1aecaf6c3http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,37980542-4e6c-4a85-840e-7cd1aecaf6c3.aspxRockford Lhotka

I’ve posted a number of blog entries on Windows 8 and WinRT, and thought it might
be worth summarizing them. I suggest reading them in this order:

At Visual Studio Live! last week I used some
slides that several of us at Magenic have been
working on to provide clarity around the “Windows 8” development platform, based on
what we know from //Build/ 2011. I wanted to share some of these slides here.

We’re also working on a related white paper that will be online soon, and I’ll link
to that when it is available.

First, is the obligatory Microsoft “boxology” diagram that generated so much controversy
due to its over-simplistic design:

Although this diagram is usually found to be lacking, it did set the standard for
the green/blue color scheme and overall layout of everyone else’s “boxology” diagrams
– including ours.

Magenic Windows 8 Diagram

Here is the Magenic diagram that provides more detail and clarity:

Win32 (blue) is the existing Windows operating system API, and it shouldn’t be surprising
that it supports existing technologies.

WinRT (green) is the new Windows operating system API, that I suspect will replace
Win32 over a period of many, many years. In my mind this is absolutely necessary.
Win32 is more than 16 years old, and just doesn’t provide the capabilities we want
in a modern operating system. Hopefully the new WinRT API will provide these capabilities,
and will last for another 15+ years.

The idea in the Magenic diagram is to clearly show the WinRT (Metro, green) and Win32
(desktop, blue) sides of the Windows 8 platform, and the various development technology
stacks that can be used to build software for each operating system API.

To provide even more clarity, we have a series of highlight diagrams for various technology
stacks.

The Desktop (blue)

I’ll start by walking through all the technology stacks on the desktop (blue) side
of the master diagram:

Silverlight

WPF

Web sites with plugins

Web sites with pure HTML/js

Windows Forms

C++, MFC, ATL

Each technology maps directly from today into Windows 8.

Silverlight

Silverlight runs in Win8 in the desktop browser, and out of browser, just like it
does today on Win7.

WPF

WPF runs in the Win8 desktop just like it does today in Win7.

Web sites with plugin support

Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common
web technologies all run in the desktop web browser. This is the same as web sites
work today in Win7.

Web sites with pure HTML/js

If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop
browsers interchangeably. Microsoft clearly expects this type of web site to become
more common over time, though it is interesting that a large number of existing Microsoft
web sites are really only useful in the desktop browser.

Windows Forms

Windows Forms continues to run in Windows 8 on the desktop, just like it does in Win7.
This isn’t surprising, given that Windows Forms is almost certainly still the dominant
technology for building Windows smart client applications, even though the technology
hasn’t had anything beyond bug fixes since 2005. It goes to show how stability in
a platform is important, and attracts widespread use for business development.

C++, MFC, ATL

Although little business development is done with C++ anymore, this technology remains
relevant for game developers, OS and device driver developers, and every now and then
I encounter someone using it for business development. From my perspective, the important
thing about C++ support is that my favorite games will probably continue to run on
Win8 in the desktop.

WinRT (green)

Next, I’ll walk through the three technologies that support the WinRT API:

WinRT .NET

WinRT HTML 5

WinRT C++

Each technology draws from existing technologies by the same names, but in each case
there’s a little “twist” as you move from the Win32 to the WinRT platform.

WinRT .NET and XAML

I expect this to be the most widely used technology stack for building WinRT applications.
The .NET available to WinRT applications is (I think) best thought of as being like
.NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a
bunch of WinRT-specific features and capabilities. The differences between Silverlight
and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate.

The XAML is very close to Silverlight and WPF, and the types of code you can write
using C# and VB are very comparable to what you can write today using Silverlight.

As a preview: the white paper we’re creating at Magenic ultimately concludes that
using Silverlight today provides the easiest transition to WinRT in the future. Not
seamless or trivial, but practical. We also conclude that WPF can enable a WinRT transition
too – especially if you limit your use of WPF and .NET to the Silverlight subset of
behaviors and features.

WinRT HTML 5

Microsoft has made much of the HTML 5 technology stack for building WinRT applications.
In no way are we talking about web sites, web pages, or web applications here. This
is smart client development done using technologies that were previously
web-focused.

For a .NET developer, the technologies map like this:

HTML instead of XAML

JavaScript instead of C#

WinJS instead of the .NET BCL

In my conversations with traditional web developers, it is a brain-bending moment
when I point out that there is no web server involved, and so no server-side
code at all here. All the stuff that is done in ASP.NET or PHP is now done in JavaScript.
From an architecture, design, and application functionality perspective, a WinRT HTML
5 app is almost, but not completely, unlike a web app.

On the positive side, if a web developer can learn and embrace the smart client architectural
model, their skills with HTML, CSS, and JavaScript will carry over to this new platform.
Some HTML and CSS assets, and perhaps some js assets, will carry from web development
into this type of smart client development as well.

WinRT C++

Finally, C++ remains relevant on WinRT as well. This should come as no surprise, given
that the Windows OS developers primarily use C++, and there’ll hopefully be games
and other applications that are traditionally created using this technology.

I also suspect that Objective C apps will port to WinRT more directly through C++
than with C# or js, and (at least for my part) I hope that some of the existing iPad/iPhone
apps quickly make their way onto WinRT so I can enjoy them.

Summary

Through this series of diagrams, we clearly show how today’s technologies map directly
into the Win8 desktop world, still running on the Win32 API. And we show the three
technology stacks that enable development of applications on the new WinRT API.

From everything we know today, it seems clear that migrating to WinRT will require
effort, regardless of the technology used today, or in the Win8 desktop. Of all existing
technologies, Silverlight and then WPF appear to offer the easiest migration. HTML
5, css, and js skills, along with some code assets will also migrate, but there’s
a non-trivial architectural difference between web development and smart client development
that shouldn’t be overlooked.

As Microsoft releases updates to the Win8 preview and moves into a beta process, I’m
sure that we’ll learn more about the platform and how existing technologies map into
the future. It will be interesting to see how we need to update these diagrams as
Microsoft provides more information over time.

Windows 8 is exciting, and the new WinRT platform is long-overdue. I look forward
to building WinRT applications in the not-to-distant future!

Windows 8 Development Platform Clarifiedhttp://www.lhotka.net/weblog/PermaLink,guid,62f31de1-af1a-4afb-956b-a3b7ce71eb9d.aspxhttp://www.lhotka.net/weblog/Windows8DevelopmentPlatformClarified.aspx
Mon, 24 Oct 2011 17:08:54 GMT<p>
At <a href="http://www.vslive.com/">Visual Studio Live!</a> last week I used some
slides that several of us at <a href="http://www.magenic.com/">Magenic</a> have been
working on to provide clarity around the “Windows 8” development platform, based on
what we know from //Build/ 2011. I wanted to share some of these slides here.
</p>
<p>
We’re also working on a related white paper that will be online soon, and I’ll link
to that when it is available.
</p>
<p>
First, is the obligatory Microsoft “boxology” diagram that generated so much controversy
due to its over-simplistic design:
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_2.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb.png" width="244" height="138" /></a>
</p>
<p>
Although this diagram is usually found to be lacking, it did set the standard for
the green/blue color scheme and overall layout of everyone else’s “boxology” diagrams
– including ours.
</p>
<h1>Magenic Windows 8 Diagram
</h1>
<p>
Here is the Magenic diagram that provides more detail and clarity:
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_4.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_1.png" width="244" height="137" /></a>
</p>
<p>
Win32 (blue) is the existing Windows operating system API, and it shouldn’t be surprising
that it supports existing technologies.
</p>
<p>
WinRT (green) is the new Windows operating system API, that I suspect will replace
Win32 over a period of many, many years. In my mind this is absolutely necessary.
Win32 is more than 16 years old, and just doesn’t provide the capabilities we want
in a modern operating system. Hopefully the new WinRT API will provide these capabilities,
and will last for another 15+ years.
</p>
<p>
The idea in the Magenic diagram is to clearly show the WinRT (Metro, green) and Win32
(desktop, blue) sides of the Windows 8 platform, and the various development technology
stacks that can be used to build software for each operating system API.
</p>
<p>
To provide even more clarity, we have a series of highlight diagrams for various technology
stacks.
</p>
<h2>The Desktop (blue)
</h2>
<p>
I’ll start by walking through all the technology stacks on the desktop (blue) side
of the master diagram:
</p>
<ul>
<li>
Silverlight</li>
<li>
WPF</li>
<li>
Web sites with plugins</li>
<li>
Web sites with pure HTML/js</li>
<li>
Windows Forms</li>
<li>
C++, MFC, ATL</li>
</ul>
<p>
Each technology maps directly from today into Windows 8.
</p>
<h3>Silverlight
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_8.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_3.png" width="244" height="136" /></a>
</p>
<p>
Silverlight runs in Win8 in the desktop browser, and out of browser, just like it
does today on Win7.
</p>
<h3>WPF
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_10.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_4.png" width="244" height="136" /></a>
</p>
<p>
WPF runs in the Win8 desktop just like it does today in Win7.
</p>
<h3>Web sites with plugin support
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_12.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_5.png" width="244" height="134" /></a>
</p>
<p>
Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common
web technologies all run in the desktop web browser. This is the same as web sites
work today in Win7.
</p>
<h3>Web sites with pure HTML/js
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_14.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_6.png" width="244" height="134" /></a>
</p>
<p>
If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop
browsers interchangeably. Microsoft clearly expects this type of web site to become
more common over time, though it is interesting that a large number of existing Microsoft
web sites are really only useful in the desktop browser.
</p>
<h3>Windows Forms
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_16.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_7.png" width="244" height="136" /></a>
</p>
<p>
Windows Forms continues to run in Windows 8 on the desktop, just like it does in Win7.
This isn’t surprising, given that Windows Forms is almost certainly still the dominant
technology for building Windows smart client applications, even though the technology
hasn’t had anything beyond bug fixes since 2005. It goes to show how stability in
a platform is important, and attracts widespread use for business development.
</p>
<h3>C++, MFC, ATL
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_18.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_8.png" width="244" height="135" /></a>
</p>
<p>
Although little business development is done with C++ anymore, this technology remains
relevant for game developers, OS and device driver developers, and every now and then
I encounter someone using it for business development. From my perspective, the important
thing about C++ support is that my favorite games will probably continue to run on
Win8 in the desktop.
</p>
<h2>WinRT (green)
</h2>
<p>
Next, I’ll walk through the three technologies that support the WinRT API:
</p>
<ul>
<li>
WinRT .NET</li>
<li>
WinRT HTML 5</li>
<li>
WinRT C++</li>
</ul>
<p>
Each technology draws from existing technologies by the same names, but in each case
there’s a little “twist” as you move from the Win32 to the WinRT platform.
</p>
<h3>WinRT .NET and XAML
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_20.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_9.png" width="244" height="138" /></a>
</p>
<p>
I expect this to be the most widely used technology stack for building WinRT applications.
The .NET available to WinRT applications is (I think) best thought of as being like
.NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a
bunch of WinRT-specific features and capabilities. The differences between Silverlight
and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate.
</p>
<p>
The XAML is very close to Silverlight and WPF, and the types of code you can write
using C# and VB are very comparable to what you can write today using Silverlight.
</p>
<p>
As a preview: the white paper we’re creating at Magenic ultimately concludes that
using Silverlight today provides the easiest transition to WinRT in the future. Not
seamless or trivial, but practical. We also conclude that WPF can enable a WinRT transition
too – especially if you limit your use of WPF and .NET to the Silverlight subset of
behaviors and features.
</p>
<h3>WinRT HTML 5
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_22.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_10.png" width="244" height="138" /></a>
</p>
<p>
Microsoft has made much of the HTML 5 technology stack for building WinRT applications.
In no way are we talking about web sites, web pages, or web applications here. This
is <em>smart client development</em> done using technologies that were previously
web-focused.
</p>
<p>
For a .NET developer, the technologies map like this:
</p>
<ul>
<li>
HTML instead of XAML</li>
<li>
JavaScript instead of C#</li>
<li>
WinJS instead of the .NET BCL</li>
</ul>
<p>
In my conversations with traditional web developers, it is a brain-bending moment
when I point out that there is <em>no web server involved</em>, and so no server-side
code at all here. All the stuff that is done in ASP.NET or PHP is now done in JavaScript.
From an architecture, design, and application functionality perspective, a WinRT HTML
5 app is almost, but not completely, unlike a web app.
</p>
<p>
On the positive side, if a web developer can learn and embrace the smart client architectural
model, their skills with HTML, CSS, and JavaScript will carry over to this new platform.
Some HTML and CSS assets, and perhaps some js assets, will carry from web development
into this type of smart client development as well.
</p>
<h3>WinRT C++
</h3>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_24.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Windows-8_9AEF/image_thumb_11.png" width="244" height="138" /></a>
</p>
<p>
Finally, C++ remains relevant on WinRT as well. This should come as no surprise, given
that the Windows OS developers primarily use C++, and there’ll hopefully be games
and other applications that are traditionally created using this technology.
</p>
<p>
I also suspect that Objective C apps will port to WinRT more directly through C++
than with C# or js, and (at least for my part) I hope that some of the existing iPad/iPhone
apps quickly make their way onto WinRT so I can enjoy them.
</p>
<h2>Summary
</h2>
<p>
Through this series of diagrams, we clearly show how today’s technologies map directly
into the Win8 desktop world, still running on the Win32 API. And we show the three
technology stacks that enable development of applications on the new WinRT API.
</p>
<p>
From everything we know today, it seems clear that migrating to WinRT will require
effort, regardless of the technology used today, or in the Win8 desktop. Of all existing
technologies, Silverlight and then WPF appear to offer the easiest migration. HTML
5, css, and js skills, along with some code assets will also migrate, but there’s
a non-trivial architectural difference between web development and smart client development
that shouldn’t be overlooked.
</p>
<p>
As Microsoft releases updates to the Win8 preview and moves into a beta process, I’m
sure that we’ll learn more about the platform and how existing technologies map into
the future. It will be interesting to see how we need to update these diagrams as
Microsoft provides more information over time.
</p>
<p>
Windows 8 is exciting, and the new WinRT platform is long-overdue. I look forward
to building WinRT applications in the not-to-distant future!
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=62f31de1-af1a-4afb-956b-a3b7ce71eb9d" />MagenicSilverlightWinRTWPFhttp://www.lhotka.net/weblog/Trackback.aspx?guid=2b63c654-9cf0-4a24-8636-9e3f2bb1df2bhttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,2b63c654-9cf0-4a24-8636-9e3f2bb1df2b.aspxRockford Lhotka

Magenic sent a team to Microsoft’s recent //build/ conference to learn about the new
Windows 8 and WinRT platform. You can now watch a series of interviews with several
of Magenic’s thought leaders to get an insight into the first impressions about Windows
8:

Magenic interviews at Build11http://www.lhotka.net/weblog/PermaLink,guid,2b63c654-9cf0-4a24-8636-9e3f2bb1df2b.aspxhttp://www.lhotka.net/weblog/MagenicInterviewsAtBuild11.aspx
Tue, 18 Oct 2011 21:34:17 GMT<p>
Magenic sent a team to Microsoft’s recent //build/ conference to learn about the new
Windows 8 and WinRT platform. You can now watch a series of interviews with several
of Magenic’s thought leaders to get an insight into the first impressions about Windows
8:
</p>
<p>
<a href="http://magenic.com/Portfolio/VideoBuildInterviews.aspx">http://magenic.com/Portfolio/VideoBuildInterviews.aspx</a>
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=2b63c654-9cf0-4a24-8636-9e3f2bb1df2b" />MagenicWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=d95c9322-bb52-4422-9b98-9c2d8c1f3d98http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,d95c9322-bb52-4422-9b98-9c2d8c1f3d98.aspxRockford Lhotka

With all the new terminology and conceptual surface area that comes with the OS code-named
“Windows 8”, I’ve been struggling to come up with clarity as I discuss the technology.
In the absence of true clarity from Microsoft, we’re left to interpret that they’ve
said and come up with our own consistent terminology.

Here’s my current thinking:

Windows 8 – the new operating system that runs in a “dual mode”: Desktop (Win32) and
WinRT

Win32 – the OS API that supports today’s applications in Win8

WinRT – the new OS API that supports future applications

Metro – a user experience design language often used when building WinRT applications

If I’m right, this is important, because people will ultimately be building business
applications on WinRT. Those apps may or may not be strictly “Metro”, but by running
on WinRT they’ll gain the benefits of the new runtime API, services, and application
model.

People talk about “Metro apps”, but even in the Microsoft samples there are apps running
on WinRT that violate those standards left and right. So it is extremely clear that
WinRT apps might or might not be “Metro”.

Additionally, it seems pretty reasonable to think about building Silverlight or WPF
apps, even today, following the Metro standards. Some of that might require a lot
of work (at least until third party control vendors create some new components for
us), but it is surely possible.

So you could argue that "Metro apps” might transcend WinRT. In fact, Metro is
also used to describe Windows Phone apps, and they are mostly written in Silverlight.

So I think there are “WinRT apps”, and this includes any/all apps written on the WinRT
API.

Then there are “Metro apps” that are probably a WinRT app, that also follows the Metro
user experience guidelines.

This terminology helps a lot when talking about .NET, present and future.

Right now, today, we have some flavors of .NET:

.NET Full profile

.NET Client profile

Silverlight

Windows Phone

It seems to me that Windows 8 just adds a new option:

.NET WinRT profile

As I think about the future of CSLA .NET, for example, this is how I approach the
issue. We’ve already put in a lot of work to make the framework support the existing
flavors of .NET (plus mono, mono for iOS, and mono for Android). Much of that effort
lays the necessary groundwork for also supporting this new WinRT flavor of .NET.

Win8, Metro, and WinRT terminologyhttp://www.lhotka.net/weblog/PermaLink,guid,d95c9322-bb52-4422-9b98-9c2d8c1f3d98.aspxhttp://www.lhotka.net/weblog/Win8MetroAndWinRTTerminology.aspx
Sat, 15 Oct 2011 03:04:37 GMT<p>
With all the new terminology and conceptual surface area that comes with the OS code-named
“Windows 8”, I’ve been struggling to come up with clarity as I discuss the technology.
In the absence of true clarity from Microsoft, we’re left to interpret that they’ve
said and come up with our own consistent terminology.
</p>
<p>
Here’s my current thinking:
</p>
<ul>
<li>
Windows 8 – the new operating system that runs in a “dual mode”: Desktop (Win32) and
WinRT</li>
<li>
Win32 – the OS API that supports today’s applications in Win8</li>
<li>
WinRT – the new OS API that supports future applications</li>
<li>
Metro – a user experience design language often used when building WinRT applications</li>
</ul>
<p>
If I’m right, this is important, because people will ultimately be building business
applications on WinRT. Those apps may or may not be strictly “Metro”, but by running
on WinRT they’ll gain the benefits of the new runtime API, services, and application
model.
</p>
<p>
People talk about “Metro apps”, but even in the Microsoft samples there are apps running
on WinRT that violate those standards left and right. So it is <em>extremely clear</em> that
WinRT apps might or might not be “Metro”.
</p>
<p>
Additionally, it seems pretty reasonable to think about building Silverlight or WPF
apps, even today, following the Metro standards. Some of that might require a lot
of work (at least until third party control vendors create some new components for
us), but it is surely possible.
</p>
<p>
So you could argue that &quot;Metro apps” might transcend WinRT. In fact, Metro is
also used to describe Windows Phone apps, and they are mostly written in Silverlight.
</p>
<p>
So I think there are “WinRT apps”, and this includes any/all apps written on the WinRT
API.
</p>
<p>
Then there are “Metro apps” that are probably a WinRT app, that also follows the Metro
user experience guidelines.
</p>
<p>
This terminology helps a lot when talking about .NET, present and future.
</p>
<p>
Right now, today, we have some flavors of .NET:
</p>
<ul>
<li>
.NET Full profile</li>
<li>
.NET Client profile</li>
<li>
Silverlight</li>
<li>
Windows Phone</li>
</ul>
<p>
It seems to me that Windows 8 just adds a new option:
</p>
<ul>
<li>
.NET WinRT profile</li>
</ul>
<p>
As I think about the future of CSLA .NET, for example, this is how I approach the
issue. We’ve already put in a lot of work to make the framework support the existing
flavors of .NET (plus mono, mono for iOS, and mono for Android). Much of that effort
lays the necessary groundwork for also supporting this new WinRT flavor of .NET.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=d95c9322-bb52-4422-9b98-9c2d8c1f3d98" />CSLA .NETWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=9cc11080-eeb5-41c0-bde7-b437d28d56fchttp://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,9cc11080-eeb5-41c0-bde7-b437d28d56fc.aspxRockford Lhotka

There is no BackgroundWorker (BW) component in WinRT. Although that is arguably a
good thing, I have CSLA .NET code that relies on this component. I can’t eliminate
the BW from CSLA, because I need to continue to support .NET, Silverlight, and Windows
Phone, even as I add support for WinRT.

Because .NET/SL/WP7 don’t (yet) have the async/await keywords, and WinRT doesn’t have
BW, I need to come up with a solution that leaves existing code/behavior alone, and
yet provides comparable behavior in WinRT.

To resolve this issue, I’ve created a BackgroundWorker type for WinRT. This type hasn’t
gone through extensive testing, but it is a good start at least:

People often ask “Why should I use MVVM? It seems like it complicates things.”

The most common reason hard-core developers put forward for MVVM is that “it enables
unit testing of presentation code”.

Although that can be true, I don’t think that’s the primary reason people
should invest in MVVM.

I think the primary reason is that it protects your presentation code against some
level of change to the XAML. It makes your code more maintainable, and will help it
last longer.

For example, build a WPF app with code-behind. Now try to move it to Silverlight without
changing any code (only XAML). Pretty hard huh?

Or, build a Silverlight app with code-behind. Now have a user experience designer
rework your XAML to look beautiful. Your app won’t build anymore? They changed numerous
XAML types and there are now compiler errors? Oops…

Looking forward, try taking any WPF or Silverlight app that has code-behind and moving
it to WinRT (Windows 8) without changing any code (only XAML – and the XAML will need
to change). Turns out to be nearly impossible doesn’t it?

And yet, I have lots of CSLA .NET application code that uses MVVM to keep the presentation
code cleanly separated from the XAML. Examples where the exact same code runs
behind WPF and Silverlight XAML. I’m not quite yet to the point of having CSLA working
on WinRT, but I fully expect the exact same code to run on Windows 8, just
with a third set of XAML.

To me, that is the power and value of MVVM. Your goal should be no code-behind, viewmodel
code that doesn’t rely on specific XAML types, and an abstract set of viewmodel methods
that can be bound to arbitrary UI events.

Yes, MVVM is an investment. But it will almost certainly pay for itself over time,
as you maintain your app, and move it from one flavor of XAML to another.

Does MVVM mean you can completely avoid changing code when the XAML changes?
No. But it is a whole lot closer than any other technique I’ve seen in my 24+ year
career.

Why MVVM?http://www.lhotka.net/weblog/PermaLink,guid,680a932d-7e2c-4ed8-93e0-7c24e0ef3ea8.aspxhttp://www.lhotka.net/weblog/WhyMVVM.aspx
Mon, 03 Oct 2011 15:59:08 GMT<p>
People often ask “Why should I use MVVM? It seems like it complicates things.”
</p>
<p>
The most common reason hard-core developers put forward for MVVM is that “it enables
unit testing of presentation code”.
</p>
<p>
Although that can be true, I don’t think that’s the <em>primary</em> reason people
should invest in MVVM.
</p>
<p>
I think the primary reason is that it protects your presentation code against some
level of change to the XAML. It makes your code more maintainable, and will help it
last longer.
</p>
<p>
For example, build a WPF app with code-behind. Now try to move it to Silverlight without
changing any code (only XAML). Pretty hard huh?
</p>
<p>
Or, build a Silverlight app with code-behind. Now have a user experience designer
rework your XAML to look beautiful. Your app won’t build anymore? They changed numerous
XAML types and there are now compiler errors? Oops…
</p>
<p>
Looking forward, try taking any WPF or Silverlight app that has code-behind and moving
it to WinRT (Windows 8) without changing any code (only XAML – and the XAML <em>will</em> need
to change). Turns out to be nearly impossible doesn’t it?
</p>
<p>
And yet, I have lots of CSLA .NET application code that uses MVVM to keep the presentation
code cleanly separated from the XAML. Examples where the <em>exact same code</em> runs
behind WPF and Silverlight XAML. I’m not quite yet to the point of having CSLA working
on WinRT, but I fully expect <em>the exact same code</em> to run on Windows 8, just
with a third set of XAML.
</p>
<p>
To me, that is the power and value of MVVM. Your goal should be no code-behind, viewmodel
code that doesn’t rely on specific XAML types, and an abstract set of viewmodel methods
that can be bound to arbitrary UI events.
</p>
<p>
Yes, MVVM is an investment. But it will almost certainly pay for itself over time,
as you maintain your app, and move it from one flavor of XAML to another.
</p>
<p>
Does MVVM mean you can <em>completely</em> avoid changing code when the XAML changes?
No. But it is a whole lot closer than any other technique I’ve seen in my 24+ year
career.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=680a932d-7e2c-4ed8-93e0-7c24e0ef3ea8" />ArchitectureProgrammingWinRThttp://www.lhotka.net/weblog/Trackback.aspx?guid=dd726e14-09c9-4a42-b88e-a4b9ce526034http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,dd726e14-09c9-4a42-b88e-a4b9ce526034.aspxRockford Lhotka

I have been giving quite a lot of thought to the WinRT migration path. What is the
outlook for taking a Windows Forms, WPF, or Silverlight app into WinRT/Metro in Windows
8?

The amount of effort required for any given application may vary radically, depending
on the architecture used when building the application, and how well that architecture
was implemented in the actual code. And it is obviously important to understand how
much client-side application code uses .NET features that aren’t in WinRT, or that
are substantially different in WinRT.

And of course I tend to look at this from a CSLA .NET perspective
If you use CSLA 4 today, and you adhere to the architecture and coding structures
recommended when using CSLA, most or all of your business layer code will probably
move to WinRT without change.

So, rather simplified, and CSLA-centric, here’s a set of process flows:

Although the first decision point is “Using CSLA?”, you could replace that with “using
a architecture/framework that abstracts all business, validation, authorization, data
access and other application logic away from the UI, exposing a model that supports
data binding and async server interactions”. Although I’m obviously biased, there
are absolutely other architectures that offer the same layered abstraction to keep all
business and data logic out of the presentation layer. And that’s really what’s
required.

In the final analysis, if you have any business or data logic in your code-behind,
or you aren’t using data binding to connect your existing UI views to some sort of
business objects, you have some work ahead of you to get to that point.

Essentially all non-CSLA Windows Forms apps I’ve ever seen will require
a complete rewrite. Most use DataSet objects, and therefore require total rework.
And most use a lot of code-behind, and therefore require total rework. And a lot of
them use numerous windows and modal dialogs, so the user workflow will require a complete
rethink.

A surprising number of WPF apps are written much like Windows Forms
apps, with code-behind, etc. Those apps will require much the same effort to migrate
as Windows Forms. But if you’ve written your WPF app using MVVM, even without something
like CSLA, and have strictly avoided code-behind, the migration probably won’t be
too bad.

The big thing is that a lot of WPF apps aren’t written to assume async server interactions,
and updating code to handle that can be a lot of work. WPF apps written using CSLA
may already be using the async features in CSLA, and so can avoid this issue entirely.
Worst case, if you are already using CSLA synchronously, the changes to move to async
aren’t overwhelming.

If you have a Silverlight app, you are in the best position of anyone,
because you are already using async server interaction, and can’t have made the mistake
of using the DataSet. And if you are using MVVM without any code-behind your migration
will probably be quite smooth.

If you are also using CSLA, then your existing business layer will probably translate
to WinRT without change.

Quite a number of people are mistakenly saying that “Silverlight is dead”, when in
reality Silverlight has never been more important.

What are you going to use to build business apps in the years between now and when
Win8 is available in your organization?

You might consider using the technology that appears to offer the easiest migration
to WinRT… And that is Silverlight (plus MVVM and CSLA 4 ).

Migrating smart clients to WinRThttp://www.lhotka.net/weblog/PermaLink,guid,dd726e14-09c9-4a42-b88e-a4b9ce526034.aspxhttp://www.lhotka.net/weblog/MigratingSmartClientsToWinRT.aspx
Wed, 28 Sep 2011 17:35:58 GMT<p>
I have been giving quite a lot of thought to the WinRT migration path. What is the
outlook for taking a Windows Forms, WPF, or Silverlight app into WinRT/Metro in Windows
8?
</p>
<p>
The amount of effort required for any given application may vary radically, depending
on the architecture used when building the application, and how well that architecture
was implemented in the actual code. And it is obviously important to understand how
much client-side application code uses .NET features that aren’t in WinRT, or that
are substantially different in WinRT.
</p>
<p>
And of course I tend to look at this from a CSLA .NET perspective <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-smile" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Migrating-smart-clients-to-WinRT_ABF7/wlEmoticon-smile_2.png" />&#160;
If you use CSLA 4 today, and you adhere to the architecture and coding structures
recommended when using CSLA, most or all of your business layer code will probably
move to WinRT without change.
</p>
<p>
So, rather simplified, and CSLA-centric, here’s a set of process flows:
</p>
<p>
<a href="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Migrating-smart-clients-to-WinRT_ABF7/image_4.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Migrating-smart-clients-to-WinRT_ABF7/image_thumb_1.png" width="403" height="306" /></a>
</p>
<p>
Although the first decision point is “Using CSLA?”, you could replace that with “using
a architecture/framework that abstracts all business, validation, authorization, data
access and other application logic away from the UI, exposing a model that supports
data binding and async server interactions”. Although I’m obviously biased, there
are absolutely other architectures that offer the same layered abstraction to keep <em>all
business and data logic</em> out of the presentation layer. And that’s really what’s
required.
</p>
<p>
In the final analysis, if you have any business or data logic in your code-behind,
or you aren’t using data binding to connect your existing UI views to some sort of
business objects, you have some work ahead of you to get to that point.
</p>
<p>
Essentially all non-CSLA <strong>Windows Forms apps </strong>I’ve ever seen will require
a complete rewrite. Most use DataSet objects, and therefore require total rework.
And most use a lot of code-behind, and therefore require total rework. And a lot of
them use numerous windows and modal dialogs, so the user workflow will require a complete
rethink.
</p>
<p>
A surprising number of <strong>WPF apps </strong>are written much like Windows Forms
apps, with code-behind, etc. Those apps will require much the same effort to migrate
as Windows Forms. But if you’ve written your WPF app using MVVM, even without something
like CSLA, and have strictly avoided code-behind, the migration probably won’t be
too bad.
</p>
<p>
The big thing is that a lot of WPF apps aren’t written to assume async server interactions,
and updating code to handle that can be a lot of work. WPF apps written using CSLA
may already be using the async features in CSLA, and so can avoid this issue entirely.
Worst case, if you are already using CSLA synchronously, the changes to move to async
aren’t overwhelming.
</p>
<p>
If you have a <strong>Silverlight app</strong>, you are in the best position of anyone,
because you are already using async server interaction, and can’t have made the mistake
of using the DataSet. And if you are using MVVM without any code-behind your migration
will probably be quite smooth.
</p>
<p>
If you are also using CSLA, then your existing business layer will probably translate
to WinRT without change.
</p>
<p>
As I mentioned in a previous <a href="http://www.lhotka.net/weblog/WinRTAndNET.aspx">WinRT
post</a>, Windows 8 is years away for most organizations. At the same time, I do think
that <a href="http://www.lhotka.net/weblog/WinRTAndBusinessApps.aspx">WinRT/Metro
will be used for business app development</a>.
</p>
<p>
Quite a number of people are mistakenly saying that “Silverlight is dead”, when in
reality Silverlight has never been more important.
</p>
<p>
What are you going to use to build business apps in the years between now and when
Win8 is available in your organization?
</p>
<p>
You might consider using the technology that appears to offer the easiest migration
to WinRT… And that is Silverlight (plus MVVM and CSLA 4 <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-smile" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Migrating-smart-clients-to-WinRT_ABF7/wlEmoticon-smile_2.png" /> ).
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=dd726e14-09c9-4a42-b88e-a4b9ce526034" />CSLA .NETSilverlightWinRT