Category Archives: software development

microsoft, php, professional, software development

Microsoft improves Windows Subsystem for Linux: launch Windows apps from Linux and vice versa

2 Comments

The Windows 10 anniversary update introduced a major new feature: a subsystem for Linux. Microsoft marketing execs call this Bash on Windows; Ubuntu calls it Ubuntu on Windows; but Windows Subsystem for Linux is the most accurate description. You run a Linux binary and the subsystem redirects system calls so that it behaves like Linux.

image

The first implementation (which is designated Beta) has an obvious limitation. Linux works great, and Windows works great, but they do not interoperate, other than via the file system or networking. This means you cannot do what I used to do in the days of Services for Unix: type ls at the command prompt to get a directory listing.

That is now changing. Version 14951 introduces interop so that you can launch Windows executables from the Bash shell and vice versa. This is particularly helpful since the subsystem does not support GUI applications. One of the obvious use cases is launching a GUI editor from Bash, such as Visual Studio Code or Notepad++.

The nitty-gritty on how it works is here.

image

Limitations? A few. Environment variables are not shared so an executable that is on the Windows PATH may not be on the Linux PATH. The executable also needs to be on a filesystem compatible with DrvFs, which means NTFS or ReFS, not FAT32 or exFAT.

This is good stuff though. If you work on Windows, but love Linux utilities like grep, now you can use them seamlessly from Windows. And if you are developing Linux applications with say PHP or Node.js, now you can develop in the Linux environment but use Windows editors.

Note that this is all still in preview and I am not aware of an announced date for the first non-beta release.

development, software development

On GitHub and GitHub Universe

I’ve been at GitHub Universe in San Francisco for the last few days. Around 1500 developers (not sure if that figure includes staff and exhibitors) in a warehouse at Pier 70. The venue was beautifully converted into an interaction space. Here is the view from outside as we were leaving; Octocat seems to be waving goodbye:

image

The main stage done up like a spaceship:

image

There was a large area for mingling, overseen by Octocat:

image

Plenty of space outside too, with a high standard of food and drink on offer.

image

There was also a “send a postcard” area where you could write a card; with cards, pens, stamps and postbox supplied there was no excuse not to do so:

image

You are probably thinking, when do we get to the techie stuff; but in some ways it is better to look at the space GitHub created and ask what it tells you about the company.

Running an event like this is not cheap, and I think we can conclude that GitHub has a business model that works. Further, there was a generous and inclusive spirit to the event which was good to experience. Kimberly Bryant from Black Girls Code spoke at the opening keynote – the event concert was a Black Girls Code benefit – and while there is often an element of PR in the causes which businesses choose to sponsor, I don’t question the authenticity of GitHub’s efforts to promote both coding and diversity in our sadly imbalanced software industry.

image

In some ways then the actual technical content was not the most important thing about this event. That said, there was some excellent content on themes including how GitHub scales its own service, new project management and code review features in GitHub, and how the product is evolving its add-in or “integrations” platform.

I also learned a bit about Electron, a framework for “creating native Desktop applications with web technologies” based on Chromium and Node.js. Microsoft’s Visual Studio Code uses Electron, as does GitHub’s own Atom editor.

If you are developer, you will be familiar with GitHub; it is the obvious choice for hosting an open source project (free) and a popular option for private repositories. When Google Code closed in 2015, the announcement cited the migration of developers to GitHub as the key reason and acknowledge that it was among “a wide variety of better hosting services” than Google’s own. “To meet developers where they are, we ourselves migrated nearly a thousand of our own open source projects from Google Code to GitHub,” remarked Google’s Chris DiBona. That was a pivotal moment, showing how GitHub has become a core part of the open source ecosystem as well as a strong commercial product for private and enterprise repositories.

GitHub does seem to take its responsibilities seriously and the fact that is has found a successful balance between free and commercial services is something to be thankful for.

c++, development, microsoft, software development, visual studio, windows

Adapting a native code DLL to be called from a Store or Universal Windows app

I am writing a Bridge game in C# – yes, I have been doing this for some time, it does run now but it is not ready for public unveiling.

It is good fun though and a learning experience, as I am writing it as a Windows 8 Store app. This means it can also be a Universal Windows Platform app but I have kept it compatible with Window 8.1 as I don’t want to lose that large market of Windows 8 users who have not upgraded to 10. Hmm.

Bridge is a card game in which a pack of 52 cards is dealt into 4 hands of 13 cards. Each hand is played as a sequence of 13 4-card “tricks”, and each trick is won one of two opposing pairs of players according to the cards played. Each pair of course tries to win as many tricks as possible, so one of the points of interests is how many tricks can be won if you play perfectly (ie with full knowledge of all four hands). Another point of interest is how each card played affects the potential number of tricks you can win with best play. For example, leading a King might cost you a trick (or more) if your opponents hold both the Ace and the Queen of that suit.

This is called “double dummy” analysis and smart people have written algorithms to calculate the answers. A double dummy analysis is useful in a bridge game for two reasons. One is that users may like to know, after playing a hand, what their best score could have been, or even to analyse the hand and see how if they played this card rather than that card at trick such-and-such the outcome would have varied. The other is that you can use it to assist the software in finding the best play. Of course it is important that the software plays fair by not using knowledge of all four hands beyond what would be known by human players; but it is legitimate to try out various possible hands that match what is currently known and use double dummy analysis on these hands.

One such smart person is Bo Haglund who wrote a C++ Windows library for double dummy analysis, called Double Dummy Solver (DDS) and released it as open source under the Apache 2 license. It works very well and is widely used in the Bridge software community, and has now been ported to Mac and Linux; you can find the latest code on Github.

Modifying a native code DLL to use with a Store app

I wanted to use the library in my own Bridge game but faced a compatibility problem. Windows Store apps can only call into DLLs that meet certain requirements, such as using only a subset of the Windows API, and DDS did not meet those requirements. My choice was either to port the DLL to C#, or to modify the code so that it would work as a Windows Runtime native DLL.

I have no doubt that the code could be ported to C# but it looks like rather a long job that would result in a library with slower performance (please feel free to prove me wrong). I thought it would be more realistic to modify the code, so I created a new Windows 8.1 DLL project in Visual Studio 2013 (I am now using Visual Studio 2015 but it is the same for this) and set about modifying the code so that it would compile.

In no particular order, here are some notes on what I learned.

I was able to get the DLL to compile after disabling the multi-threading support (more on this later), and commenting out some functions that I don’t yet need.

Another issue I hit was that Visual C++ by default performs “Security Development Lifecycle” checks (compile with /sdl). This means that that common functions like strcpy, strcat, sprintf and others will not compile. You have to use “secure” versions of those functions, strcpy_s, strcat_s, sprintf_s and so on. These are specific to Microsoft’s libraries though. Of course you can just not compile with /sdl, or define _CRT_SECURE_NO_WARNINGS, but I chose to fix all of these. Now the library compiled.

But did it work? No. I had introduced a stupid bug which took me a while to fix. Did it then work? Yes, but it took me some time to get it working from C#.

Next, I kept getting DLLNotFound exceptions. OK, so you have to add the DLL as content in your C# project, and make sure it is set to copy to your output. I still got DLLNotFound exceptions. It turns out that you get this exception even when the DLL is present, if there is a dependency in the DLL which is not found. What dependency was not found? I downloaded the Sysinternals Process Monitor utility and set the filter to monitor my C# game. I excluded SUCCESS results. Then I tried to load the DLL. This told me that it was looking for the file msvcr120_app.dll (the Windows Runtime version of the Visual C++ runtime library). My first thought was to add runtime libraries from the appx deployment packages, in:

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0

image

Then I discovered that all you need to do is to add a reference to the Visual C++ runtime packages, much easier. That fixed DLLNotFound.

Next, I had some problems calling the 64-bit DLL with Platform Invoke (PInvoke) from C#. I found it easier to compile both my C# app and the DLL itself as 32-bit code. I may go back to the 64-bit option later.

Concurrency issues

Now I had everything working; except that my DDS port was far inferior to the standard one because it was single-threaded. The original used QueueUserWorkItem which is not available in a Windows Runtime DLL. I searched for what to do, and came across this MSDN article which recommends using RunAsync, WorkItemHandler and IAsyncAction. However my DLL was not currently compiled using /ZW for “Consume Windows Runtime Extension”. I could add that of course; but then my DLL would have a dependency on the Windows Runtime and if I wanted to use the code for, say, Windows 7, it would not work. or not without yet more #ifdef blocks. No big deal perhaps; but my preference was to avoid this dependency.

There may be other solutions, but the one that I found was to use the Concurrency Runtime. Previously, QueueUserWorkItem was called in a for loop. I simply modified this to use a parallel_for loop instead, using the example here for guidance. I also added:

#include <ppltasks.h>

using namespace concurrency;

to the top of the code. It works well, speeding performance by about three times on my quad-core desktop. Of course I was greatly helped by the fact that the code was already written with concurrency in mind.

image

The effect is spoiled by the time it takes to load the DLL but fortunately you can get DDS to solve multiple boards in one call though I have yet to experiment with this.

.net, development, microsoft, open source, professional, software development

Running ASP.NET 5.0 on Nano Server preview

2 Comments

I have been trying out Microsoft’s Nano Server Preview and wrote up initial experiences for the Register. One of the things I mentioned is that I could not get an ASP.NET app successfully deployed. After a bit more effort, and help from a member of the team, I am glad to say that I have been successful.

image

What was the problem? First, a bit of background. Nano Server does not run the .NET Framework, presumably because it has too many dependencies on pieces of Windows which Microsoft wanted to omit from this cut-down deployment. Nano Server does support .NET Core, also known as Core CLR, which is the open source fork of the .NET Framework. This enables it to run PowerShell, although with a limited range of cmdlets, and my main two ways of interacting with Nano Server are with PowerShell remoting, and Windows file sharing for copying files across.

On your development machine, you need several pieces in order to code for ASP.NET 5.0. Just installing Visual Studio 2015 RC will do, except that there is currently an incompatibility between the version of the ASP.NET 5.0 .NET Core runtime shipped with Visual Studio, and what works on Nano Server. This meant that my first effort, which was to build an empty ASP.NET 5.0 template app and publish it to the file system, failed on Nano Server with a NativeCommandError.

This meant I had to dig a bit more deeply into ASP.NET 5.0 running on .NET Core. Note that when you deploy one of these apps, you can include all the dependencies in the app directory. In other words, apps are self-hosting. The binary that enables this bit of magic is called DNX (.NET Execution Environment); it was formerly known as the K runtime.

Developers need to install the DNX SDK on their machines (Windows, Mac or Linux). There is currently a getting started guide here, though note that many of the topics in this promising documentation are as yet unwritten.

image

However, after installation you will be able to use several handy commands:

dnvm This is the .NET Version manager. You can have several versions of the DNX runtime installed and this utility lets you list them, set aliases to save typing full paths, and manage defaults.

image

dnu This is the .NET Development Utility (formerly kpm) that builds and publishes .NET Core projects. The two commands I found myself using regularly are dnu restore which downloads Nuget (.NET repository) packages and dnu publish which packages an app for deployment. Once published, you will find .cmd files in the output which you use to start the app.

dnx This is the binary which you call to run an app. On the development machine, you can use dnx . run to run the console app in the current directory and dnx . web to run the web app in the current directory.

Now, back to my deployment issues. The Visual Studio templates are all hooked to DNX beta 4, and I was informed that I needed DNX beta 5 for Nano Server. I played around with trying to get Visual Studio to target the updated DNX but ran into problems so decided to ignore Visual Studio and do everything from the command line. This should mean that it would all work on Mac and Linux as well.

I had a bit of trouble persuading DNX to update itself to the latest unstable builds; the main issue I recall is targeting the correct repository. You NuGet sources must include (currently) https://www.myget.org/F/aspnetvnext/api/v2.

Since I was not using Visual Studio, I based my samples on these, Hello World Console, MVC and Web apps that you can use for testing that everything works. My technique was to test on the development machine using dnx . web, then to use dnu publish and copy the output to Nano Server where I could run ./web.cmd in a remote PowerShell session.

Note that I found it necessary to specify the CoreClr 64-bit runtime in order to get dnu to publish the correct files. I tried to make this the default but for some reason* it reverted itself to x86:

dnu publish –runtime "c:\users\[USERNAME]\.dnx\runtime\dnx-coreclr-win-x64.1.0.0-beta5-11701"

Of course the exact runtime version to use will change soon.

If you run this command and look in the /bin/output folder you will find web.cmd, and running this should start the app. The port on which the app listens is set in project.json in the top level directory of the project source. I set this to 5001, opened that port in the Windows Firewall on the Nano Server, and got a started message on the command line. However I still could not browse to the app running on Nano Server; I got a 400 error. Even on the development machine it did not work; the browser just timed out.

It turned out that there were several issues here. On the development machine, which is running Windows 10 build 10074, I discovered to my annoyance that the web app worked fine with Internet Explorer, but not in Project Spartan, sorry Edge. I do not know why.

Support also gave me some tips to get this working on Nano Server. In order for the app to work across the network, you have to edit project.json so that localhost is replaced either with the IP number of the server, or with a *. I was also advised to add dnx.exe to the allowed apps in the firewall, but I do not think this is necessary if the port is open (it is a nuisance, since the location of dnx.exe changes for every app).

Finally I was successful.

Final observations

It seems to me that ASP.NET vNext running on .NET Core has the characteristic of many open source projects, a few dedicated people who have little time for documentation and are so close to the project that their public communications assume a fair amount of pre-knowledge. The site I referenced above does have helpful documentation though, for the few topics that are complete. Some other posts I found helpful are this series by Steve Perkins, and the troubleshooting suggestions here especially David Fowler’s post.

I like The .NET Core initiative overall since I like C# and ASP.NET MVC and now it is becoming a true cross-platform framework. That said, the code does seem to be in rapid flux and I doubt it will really be ready when Visual Studio 2015 ships. The danger I suppose is that developers will try it in the first release, find lots of problems, and never go back.

I also like the idea of running apps in Nano Server, a low-maintenance environment where you can get the isolation of a dedicated server for your app at low cost in terms of resources.

No doubt though, the lack of pieces that you expect to find on Windows Server will be an issue and I am not sure that the mainstream Microsoft developer ecosystem will take to it. Aidan Finn is not convinced, for example:

Am I really expected to deploy a headless OS onto hardware where the HCL certification has the value of a bucket with a hole in it? If I was to deploy Nano, even in cloud-scale installations, then I would need a super-HCL that stress tests all of the hardware enhancements. And I would want ALL of those hardware offloads turned OFF by default so that I can verify functionality for myself, because clearly, neither Microsoft’s HCL testers nor the OEMs are capable of even the most basic test right now.

Finn’s point is that if your headless server is having networking issues it is hard to troubleshoot, since of course remote tools will not work reliably. That said, I have personally run Hyper-V Server (which is essentially Server Core with just the Hyper-V role) with great success for several years; I started keeping notes on how to troubleshoot from the command line and found solutions to common problems. If networking fails with Nano Server then yes, you have a problem, but there is always something you can do, even if it means mounting the Nano Server VHD or VHDX on another VM. Windows Server admins have become accustomed to a local GUI though and adjusting even to Server Core has not been easy.

*the reason was that I did not use the –p argument with dnvm use which would have made it persistent

.net, microsoft, software development

HoloLens: a developer hands-on

1 Comment

I attended the “Holographic Academy” during Microsoft’s Build conference in San Francisco. It was aimed at developers, and we got a hands-on experience of coding a simple HoloLens app and viewing the results. We were forbidden from taking pictures so you will have to make do with my words; this also means I do not have to show myself wearing a bulky headset and staring at things you cannot see.

image

First, a word about HoloLens itself. The gadget is a headset that augments the real world with a 3D “projected” image. It is not really a hologram, otherwise everyone would see it, but it is a virtual hologram created by combining what you see with digital images.

The effect is uncanny, since the image you see appears to stay in one place. You can walk around it, seeing it from different angles, close up or far away, just as you could with a real image.

That said, there were a couple of issues with the experience. One is that if you went too close to a projected image, it disappeared. From memory, the minimum distance was about 18 inches. Second, the viewport where you see the augmented reality was fairly small and you could easily see around it. This is detrimental to the illusion, and sometimes made it a struggle to see as much of your hologram as you might want.

I asked about both issues and got the same response, essentially “no comment’’. This is prototype hardware, so anything could change. However, according to another journalist who attended a hands-on demo in January, the viewport has gotten smaller, suggesting that Microsoft is compromising in its effort to make the technology into a commercially viable product.

Another odd thing about the demo was that after every step, we were encouraged to whoop and cheer. There was a Microsoft “mentor” for every pair of journalists, and it seemed to me that the mentors were doing most of the whooping and cheering. It is obvious that this is a big investment for the company and I am guessing that this kind of forced enthusiasm is an effort to ensure a positive iimpression.

Lest you think I am too sceptical, let me add that the technology is genuinely amazing, with obvious potential both for gaming and business use.

The developer story

The development process involves Unity, Visual Studio, and of course the HoloLens device itself. The workflow is like this. You create an interactive 3D scene in Unity and build it, whereupon it becomes a Visual Studio project. You open the project in Visual Studio, and deploy it to HoloLens (connected over USB), just as you would to a smartphone. Once deployed, you disconnect the HoloLens and wear it in order to experience the scene you have created. Unity supports scripting in C#, running on Mono, which makes the development platform easy and familiar for Windows developers.

Our first “Holo World” project displayed a hologram at a fixed position determined by where you are when the app first runs. Next, we added the ability to move the hologram, selecting it with a wagging finger gesture, shifting our gaze to some other spot, and placing it with another wagging finger gesture. Note that for this to work, HoloLens needs to map the real world, and we tried turning on wire framing so you could see the triangles which show where HoloLens is detecting objects.

We also added a selection cursor, an image that looks like a red bagel (you can design your own cursor and import it into Unity). Other embellishments were the ability to select a sphere and make it fall to the floor and roll around, voice control to drop a sphere and then reset it back to the starting point, and then “spatial audio” that appears to emit from the hologram.

All of this was accomplished with a few lines of C# imported as scripts into Unity. The development was all guided so we did not have to think for ourselves, though I did add a custom voice command so I could say “abracadabra” instead of “reset scene”; this worked perfectly first time.

For the last experiment, we added a virtual underworld. When the sphere dropped, it exploded making a virtual pit in the floor, through which you could see a virtual world with red birds flapping around. It was also possible to enter this world, by positioning the hologram above your head and dropping a sphere from there.

HoloLens has three core inputs: gaze (where you are looking), gesture (like the finger wag) and voice. Of these, gaze and voice worked really well in our hands on, but gesture was more difficult and sometimes took several tries to get right.

At the end of the session, I had no doubt about the value of the technology. The development process looks easily accessible to developers who have the right 3D design skills, and Unity seems ideally suited for the project.

The main doubts are about how close HoloLens is to being a viable commercial product, at least in the mass market. The headset is bulky, the viewport too small, and there were some other little issues like lag between the HoloLens detection of physical objects and their actual position, if they were moving, as with a person walking around.

Watch this space though; it is going to be most interesting.

microsoft, software development

StackOverflow developer survey shows decline in C#, Windows

6 Comments

StackOverflow, a popular (and the best) site for programming queries, has published its annual developer survey. Respondents included:

26,086 people from 157 countries participated in our 45-question survey. 6,800 identified as full-stack developers, 1,900 as mobile developers, 1,200 as front-end developers, 2 as farmers, and 12,000 as something else.

That is a decent sample size, though not necessarily representative of the entire developer community.

What is notable? Here are a few things that stood out for me:

Developers are young. The largest group is 25-29 and the average age 28.9 years old.

92.1% of respondents are male. Ouch.

Software is still a good bet for a career even if you have no qualifications. 41.8% declared themselves self-taught. That said, it is not clear to me what proportion of respondents do programming as their main job. Presumably not the two farmers?

If you look at the “Most popular technologies”, there is a striking decline in C# over the last three years:

2013: 44.7%

2014: 37.6%

2015: 31.6%

That’s a shame because C# is an excellent language. The reason? It’s speculation, but probably means less Windows development, whether server or desktop.

Swift is top of the “most loved” list, meaning a language that developers intend to continue with. Salesforce tops the “most dreaded”, meaning a platform that developers cannot wait to abandon, followed by Visual Basic.

What OS do developers use on the desktop? Here, Windows remains the biggest, but is declining:

2013: 60.4%

2014: 57.9%

2015: 54.5%

Windows XP has declined dramatically, down from 10.8% in 2013 to 1.0% today.

Where have developers gone, if they no longer use Windows? Mac is up over the period, but only by 2.8% share. 3.5% are using “Other”, interesting (Chromebook?).

I’ll stop there; I don’t want to spoil the survey.

Conclusions? This puts some data (albeit imperfect) on the theory that Microsoft is losing its grip on the developer community – though note that Microsoft’s technology in general remains popular, just less so than before.

Postscript: Several on Twitter have observed that most languages have declined over the period, not just C#. Here’s the difference in share from 2013 to 2015 for some of them:

JavaScript: –2.2%

SQL: –11.6%

Java: –5.1%

C#: –13.1%

PHP: –5.1%

In other words, all of the top 5 have declined, though C# has declined the most.

What does this mean? Since the numbers sum to more than 100%, it might imply more specialisation. Or it might just say something about how the StackOverflow community has evolved, since that is the source of the data. Still, it seems to me that you cannot spin this as good news for Microsoft, though it might be less bad than it first appears.

android, embarcadero, Internet of things, ios, microsoft, software development

Delphi and RAD Studio 2015 roadmap: no Universal Apps?

4 Comments

Embarcadero has posted a roadmap for RAD Studio 2015, its suite of tools for building apps for Windows, Mac, iOS and Android.

Note that the company says the (sketchy) plans outlined are “not a promise, or a contract”.

I will be interested to see if the company intends to support the Windows 10 Universal App Platform (UAP), which Microsoft is pushing as the future of Windows client app development. UAP apps run on the Windows Runtime, a sandboxed environment introduced in Windows 8. In Windows 10, UAP apps are integrated with the Windows desktop, and run on Windows Phone and Xbox as well as on PCs and tablets.

When Window 8 came out, Embarcadero came up with a project type called “Metropolis”, which simulated the Windows 8 Metro environment but with a Win32 executable. It was neither one thing nor the other, and mostly ignored as far as I can tell. That said, lack of support for Windows 8 Store apps proved to be no big deal, because of the low take-up for the platform in general. At this stage, nobody knows whether the UAP may be similarly unsuccessful, though it seems to me that it has a better chance thanks to its broader scope and changes that have been made.

The roadmap promises “Integration with new Windows 10 platform technologies” but does not promise support for the Windows Runtime or UAP, so my assumption for the moment is that Embarcadero is steering clear for the time being. There may also be technical challenges.

Not much new is promised for the venerable VCL (Windows-only apps), and only a little more for the cross-platform FireMonkey: new mobile components including Maps, a WebBrowser component for desktop apps, and more iOS platform (real native) controls.

A new iOS 64-bit compiler is promised, as well as moving the Win32 compiler to an LLVM-based toolchain, as is already the case for 64-bit Windows.

There is an Internet of Things slide which promises “mobile proximity integration” and components for connecting to different devices. Exactly what is new compared to the IoT support described here for XE7 is not clear to me.

Under consideration, Embarcadero says, is Linux server-side support for its middle-tier technologies like DataSnap, support for Intel Android, and a 64-bit toolchain for Mac OS X.

Since it is on SlideShare, I can embed the whole thing here:

This is some help I guess; though I recall much past angst expressed on the Embarcadero forums about these roadmaps, or the lack/lateness of them. The problem, I guess, is that roadmaps are of little benefit to the tools vendors, since they have potential to fuel discontent, set expectations that may later prove unrealistic, and give away plans to competitors.

This may explain why this one has so little content. Embarcadero could work a bit harder on the presentation as well; this really does not have the look of being the exciting next generation of a powerful cross-platform toolkit.

microsoft, mobile, software development, visual studio, windows

Windows 10 at Mobile World Congress 2015: a quick reflection

1 Comment

I attended Mobile World Congress in Barcelona last week – with 93,000 attendees and 2,100 exhibitors according to the latest figures.

It was a big event for Microsoft’s new Windows. It started for me on the Saturday before, when Acer unveiled a low-end Windows Phone (write-up on the Reg). Next was Microsoft’s press conference; Stephen Elop was on stage, presenting two new mid-range Lumias as if nothing had changed since last year when he announced the now-defunct Nokia X:

image

The Lumia 640 looks good value, especially in its XL guise: 5.7” 1280 x 720 display, 8GB storage plus microSD slot, 13MP camera, 4G LTE, quad-core 1.2GHz CPU, €189 ex VAT. The smaller Lumia 640 is now on presale at £169.99; we were told €139 ex VAT at MWC, so I guess the real price of the 640XL may be something like £230, though there will be deals.

These phones will ship with Windows Phone 8.1 but get Windows 10 when available.

The big Windows 10 event was elsewhere though, and not mentioned at the press conference. This was the developer event, where General Manager Todd Brix, Director of Program Management Kevin Gallo and others presented the developer story behind the new Universal App Platform (not the same as the old Universal App Platform, as I explain here).

image

This was the real deal, with lots of code. There was even a hands-on session where we built our own Universal Apps in Visual Studio 2015. Note that the Visual Studio build we used featured an additional application type for Windows 10; this is not the same as a Store app in Windows 8, though both use the Windows Runtime.

As someone with hands-on experience of developing a Store app, I am optimistic that the new platform will achieve more success. It is a second attempt with a bit more maturity, and much greater effort to integrate with the Windows desktop, whereas the first iteration went out of its way not to integrate.

Much of the focus was on the Adaptive UX, creating layouts that resize intelligently on different devices. The cross-platform UI concept is controversial, with strong arguments that you only get an excellent UI if you design specifically for a device, rather than trying to make one that runs everywhere. The Universal App Platform is a bit different though, since it is all Windows Runtime. Microsoft’s pitch is that by writing to the UAP you can target desktop, Windows Phone, tablet and Xbox One, with a single code base; and without a cross-device UI this pitch would lose much of its force. Windows 7 legacy is a problem of course; but if we see Windows 10 adopted as rapidly as Windows 7 (following the Vista hiccup) this may not be a deal-breaker.

The official account of the MWC event is in Gallo’s blog post which went out on the same day. There was much more detail at the event, but Microsoft is holding this back, perhaps for its Build conference at the end of April. So in this case you had to be there.

image

Aside: if you look at the publicity Microsoft got from MWC, you will note that it is mostly based on the press conference and the launch of two mid-range Lumias, hardly ground-breaking. The fact that a ton of new stuff got presented at the developer event got far less attention, though of course sharp eyes like those of Mary Jo Foley was onto it. I have a bias towards developer content; but even so, it strikes me that a session of new content that is critical to the future of Windows counts for more than a couple of new Lumias. This demonstrates the extent to which the big vendors control the news that is written about them – most of the time.

microsoft, software development

Universal Apps: a look at Microsoft’s first efforts on Phone and PC

1 Comment

Windows 10 for phones is now available on preview; I wrote a first-look piece for The Register here. I like it better than I had expected; it is a bit laggy but pretty much stable and with some compelling new features.

The main interest of the preview for me though is the appearance of first-party universal apps. Since these form a key part of the strategy for Windows 10, it seems to me that they merit close attention; after all, this is what Microsoft is hoping other developers will do when creating apps for Windows. Universal apps are not actually new in Windows 10 – you can write one today for Windows 8 and Windows Phone – but in the forthcoming Windows they run on the desktop rather than just in the tablet environment. There are also changes in the Windows Runtime API and frameworks though these are currently undocumented as far as I am aware (wait for Build!)

How many Microsoft universal apps are there in Windows 10, designed for both tablet and phone? Quite a few. The ones I am looking at here are Settings (not sure if this is actually the same app), Calculator, Photos, Sound Recorder, Alarms and Feedback.

There is more coming, most notably Outlook (including Mail and Calendar), Word, Excel and PowerPoint. The latter three are already available in preview in Windows 10 for PCs and tablets, but not yet for phone. However, the Android and iOS phone versions are probably a good indication of what is to come, at least for Word, Excel and PowerPoint. For Outlook there is some confusion caused by Microsoft acquiring third-party apps and rebadging them, so in these cases Windows 10 may diverge more from iOS and Android.

Enough apps then to be significant. In the screenshots that follow, I have shown in most cases three versions of each app: Windows Phone 8.1 (the equivalent app, not a universal app), Windows 10 PC, and Windows 10 phone. My general observations are:

1. The old Windows Phone version is more carefully optimized for a smartphone, with a chunky UI that is optimized for touch.

2. The new apps have more functionality, as you would expect for apps that need to work on the desktop where expectations are higher.

3. The new apps have a distinctive look and feel compared to either Windows Phone 8.1 apps, or Windows 8 “Metro” apps. Needless to say, they look different from Windows 7 style desktop apps as well. These are still Windows Runtime (the platform underlying “Metro” or “Store” apps) but in general the UI is denser than before; there is more information on view in a single screen.

While I have some doubts about the usability of the new apps on a phone, this seems to me a good direction overall; the phone is benefiting from work Microsoft is doing for the PC and vice versa. I think we will see better, more useful apps on both platforms as a result.

Now for the screenshots:

Calculator

Windows Phone 8.1 Windows 10 Phone Windows 10 PC
image image image

A good example of how the new app is more functional but less well optimized for touch.

Alarms

Windows Phone 8.1 Windows 10 Phone Windows 10 PC
image image image

I have cheated a bit here because no world clock in the old Alarms app!

Sound Recorder

Windows 10 Phone Windows 10 PC
image image

No Phone 8.1 version. But you can see this really is the same app. I am glad to see this on the phone; it is an update of an ancient Windows accessory and actually useful.

Photos

Windows Phone 8.1 Windows 10 Phone Windows 10 PC
image image image

Feedback

Windows 10 Phone Windows 10 PC
image image

While this is the same app, you can see that Microsoft has adapted the UI for the phone. In the Phone version, you hit the All Categories link to see the categories and select. In the PC version, they are listed in a left-hand column. The Universal App concept allows for a totally different UI on different devices if necessary.

Settings

Windows Phone 8.1 Windows 10 Phone Windows 10 PC
image image image

The Settings app is radically changed in Windows 10; a good thing in that the Windows Phone 8.1 settings is a hopeless long and confusing list and needed some organisation. The Windows 10 PC version looks different but has the same sections and icons.

microsoft, software development, windows

Windows 10 and HoloLens: quick thoughts and questions following the January reveal

3 Comments

Microsoft is revealing its Windows 10 plans in stages, presumably in part to build up expectation and get feedback, and in part because some pieces are ready to show before others.

image

Today in Redmond Microsoft shared a number of new features. In quick summary:

Windows 10 will be a free upgrade for all Windows 7 and 8.x users, at least for the first year.

Comment: this is necessary since the refusal of Microsoft’s user base to upgrade from Windows 7 is a strategic roadblock. For example, Windows 7 users cannot use Store apps, reducing the market for those apps. It is more important to persuade users to upgrade than to get upgrade revenue. Windows 10, of course, will have to be compelling as well as free for this initiative to work, as well as providing a smooth upgrade process (never a trivial task).

Windows to evolve to become a service Executive VP Terry Myerson says this in this post:

Once a Windows device is upgraded to Windows 10, we will continue to keep it current for the supported lifetime of the device – at no additional charge. With Windows 10, the experience will evolve and get even better over time. We’ll deliver new features when they’re ready, not waiting for the next major release. We think of Windows as a Service – in fact, one could reasonably think of Windows in the next couple of years as one of the largest Internet services on the planet.

And just like any Internet service, the idea of asking “What version are you on?” will cease to make sense – which is great news for our Windows developers.

Comment: What does this mean exactly, beyond what we already have via Windows Update? What does Myerson mean by “the supported lifetime of the device”? What are the implications for the typical three-year Windows release cycle? I hope to discover more detail soon, though when I enquired whether there will be, for example, a “Windows 11” I was told, “We aren’t commenting beyond what’s stated in post that you reference.”

Project Spartan (a code name) is a new browser developed as a universal app – this means an app built for the Windows Runtime (“Metro”) environment, though in Windows 10 these also run in a window on the desktop, blurring the sharp distinction you see in Windows 8. Project Spartan features, according to Microsoft’s Joe Belfiore, a new rendering engine along with features includes the ability to annotate web pages with keyboard or touch/stylus, and the ability to save pages for reading offline. There will also be “enterprise mode compatibility for existing web apps”, which means that old IE will live on.

image

Comment: Creating a new browser is a bold step though it may be as much for marketing reasons as anything else, since IE has a tarnished reputation. The advantages of the new rendering engine, and the way compatibility will be handled, are not yet clear. Another point of interest is compatibility issues caused not only by the new engine, but also by running in sandboxed universal app environment. Looking forward to more detail on this.

Windows 10 across PC, tablet and mobile: the OS will have the same name on all three, universal apps (like a new mobile Office) will run on all three, and there are new efforts to synchronize content. For example, notifications will sync across phone and PC/Tablet.

Comment: Sounds good, but there are a few downsides. One is that Windows Phone is tied to the same release cycle as full Windows, which is rather slow. Currently Windows Phone is falling back as it waits for Windows 10 in respect of both operating system upgrade and also the universal app version of Office – which is already available for iOS and Android. CEO Satya Nadella said today that there will be new “flagship” Windows phone devices, which is good news for what is currently a neglected platform, but it will be hard for the platform to thrive if it is constantly waiting for the next big Windows update. Update: if “Windows as a service” means no more monolithic upgrades but constant incremental improvement, perhaps this will not be the case. Watch this space.

Cortana coming to Windows PC and tablet: we saw Microsoft’s digital assistant, powered by Bing search, demonstrated on full Windows.

Comment: Cortana is impressive and fun, but I am not sure how much the feature enhances the platform. On the phone I do not use it much; the problem is that speaking to your phone “what meetings to I have today” and getting a spoken response is a great demo, but in practice it is easier to glance at the calendar, especially as voice control only works in quiet scenarios. The other aspect of Cortana is the personalisation it brings to things like web search or reminders; more data about our preferences and activities can bring some magic. This is Google Now territory, and while Microsoft’s approach to privacy may be preferable, Google will be hard to match in respect of the amount of data it can draw upon.

DirectX 12: Microsoft showed a demo of its latest DirectX graphics API, claiming up to 50% better performance and up to 50% less power consumption.

Comment: this is solid good news. If games run best on Windows 10 a significant enthusiast community will want to upgrade right away. Further, DirectX is not just for games.

Xbox One integration: Microsoft showed how Xbox Live team or competitive games can work across Xbox One and PC, and how games can be streamed from XboxOne so that the console becomes a kind of games server for your Windows 10 tablets and PCs. Xbox One will also run universal apps.

Comment: Better integration between Windows devices and Xbox is long overdue and can help to promote both. Xbox One though has a bit of a Windows 7 problem of its own, with Xbox 360 remaining popular simply because of the huge numbers of games that have not been ported. If only Microsoft could introduce backwards compatibility …

Surface Hub: this is a giant 84”, 4K display wall-hanging PC which you can use as an interactive whiteboard for meetings and so on. It seems to be the next innovation from the Perceptive Pixel folk who also developed the table-top Surface device.

image

Comment: Looks cool, but it will be expensive. May help to encourage businesses to keep faith with the Windows client.

Microsoft HoloLens: this was the big reveal, a secret project that, we were told, has been developed in the basement of the Microsoft Visitor Center on its Redmond campus.

image

HoloLens is a headset which enables 3D augmented reality: projected images are seen like holographic images in the space around you, and you can interact by gesture detected by cameras and motion sensors in the headset. Look carefully at the following image:

image

In this example, the demonstrator is assembling a quad copter using a palette of 3D components in Holo Studio, an application which uses the technology. However, note that you only see the quad copter through the HoloLens headset, the image from which in this case is merged with a view of the demonstrator herself using a custom camera:

image

If you had been in the room, you would see the quad copter only on the screen, not in the room itself. Therefore I suspect this is more accurately described as augmented reality than holography, though the scene does look holographic if you are wearing the headset.

In a final flourish, Microsoft a 3D printed version of the quad copter which duly flew up and down; I am sure the motor and so on was NOT 3D printed, but it made a lovely demo.

Apparently NASA loves the technology and will be using it with Mars Rover in July in a project called OnSight – read the NASA release.

image

Bringing it down to earth, Microsoft also stated that all universal apps will have access to the HoloLens APIs.

Comment: This looks amazing and must have potential for all sorts of scenarios: architects, planners, marketing, games and more. The tough question I suppose is how much it has to do with Windows 10 as experienced by most users.

In closing

Microsoft surprised us today and deserves kudos for that. Nobody can accuse the company of lack of innovation; then again, Windows 8 and the original Surface were innovative too, and proved to be a disaster. I do not think Windows 10 will be a disaster; we have already seen in the preview how it is an easier transition for Windows 7 users.

A key thing to note from a developer and technical perspective is that universal apps are right at the centre of the Windows 10 story. That is a good thing in many respects, since we get Store deployment, sandbox security, and a degree of compatibility across phone, PC, tablet and Xbox One. But is the Store app / Universal app platform mature enough to deliver a good experience for both developers and users, bearing in mind that in Windows 8.x it is really not good enough?

Look to Microsoft Build at the end of April, which Myerson said is the culmination of the Windows 10 reveal, to answer that question.