Tag Archives: winrt

.net, microsoft, professional, software development

Microsoft introduces a new 2D graphics API for the Windows Runtime

Microsoft has announced Win2D, a Windows Runtime API that wraps Direct2D (part of DirectX), for accelerated graphics in Windows Store apps.

The new API is described here and you can download the current binary here. It is in its early stages, but already supports basic drawing, bitmap loading, some image effects, and a vector and matrix math library. Here is some sample code:

void canvasControl_Draw(CanvasControl sender, CanvasDrawEventArgs args)
{
args.DrawingSession.Clear(Colors.CornflowerBlue);
args.DrawingSession.DrawEllipse(190, 125, 140, 40, Colors.Black, 6);
args.DrawingSession.DrawText("Hello, world!", 100, 100, Colors.Yellow);
}

Although this hardly looks exciting, it is important because it enables accelerated custom drawing from languages other than C++, and without needing to learn Direct2D itself. It will be easier to make rich custom controls, or casual 2D games.

That said, there are already alternative C# wrappers for DirectX in Windows Runtime apps, such as SharpDX.

Some of the comments on the MSDN post are sceptical:

Managed DirectX and XNA were however cancelled despite the frustration from the community which in response created open source alternatives to save the projects and customers that had invested in technology Microsoft introduced.

I understand that the future is "uncertain", but is this technology something that we should dare invest in or will it see the same fate as it’s earlier incarnations?

Microsoft’s Shawn Hargreaves assures:

Win2D is absolutely not a side project or some kind of stop gap that will later be replaced by anything different.

The target here is universal apps, so not just Windows Store apps but also Windows Phone. Despite the hesitant reception for the Windows Runtime in Windows 8, it looks as if Microsoft is still committed to the platform and that it will remain centre stage in Windows vNext.

microsoft, open source

VLC efforts targeting WinRT with open source tools could enable more open source ports

2 Comments

An email from VideoLAN concerning the port of the open source VLC media player to WinRT, the tablet platform in Windows 8, provides insight into some of the technical difficulties facing open source developers.

Large Orange VLC media player Traffic Cone Logo

This is the heart of the problem:

The build process of VLC is not integrated with Windows Tools, notably Visual Studio, because VLC uses Unix Tools to run on all platforms. This is one of the reasons why VLC media player works on Windows, Linux, BSD, Solaris, iOS, Android, OS/2 and so many other operating systems.

In order to qualify for Windows Store distribution, apps must pass Microsoft’s security requirements, avoiding prohibited API calls. The VLC developers have done most of that successfully, but hit a problem with the Microsoft C Runtime, MSVCRT. Many open source projects use the ancient version 6.0 for maximum compatibility, but:

on WinRT, one MUST use MSVCRT 11.0 in order to pass the validation. This meant that we had to modify our compiler and toolchain to be able to link with this version.

When we asked Microsoft, some engineers told us that this could not possibly succeed, since the validation would not allow application compiled with 3rd party compilers to link with MSVCRT110. We did not want to believe them, since this would have killed the project.

And, they were wrong. We did it, but this took us way more time than anything we had anticipated. The final work was shared and integrated in our toolchain, Mingw-W64. All other open source applications will benefit from that, from now on.

Apparently the final piece of work is working out how to call the WinRT interop layer (the bit that looks like COM but is not COM) from C code. That is now working too so VLC is now completing the work of rewriting headers to call these new APIs.

This work could have wider consequences. Since VLC is open source, all these efforts are available to others, which means that porting other open source projects that use a similar tool chain should be easier.

This is especially significant for Windows RT, the ARM port, where it is not possible to install desktop apps.

VideoLAN’s work could be a great benefit to the WinRT Platform. Microsoft’s engineers should be doing everything they can to help, rather than (as the email implies) telling the developers that it cannot work.

embarcadero, software development

Windows 8 sideloading and Embarcadero’s Metropolis fake-WinRT framework

2 Comments

Embarcardero’s John Ray Thomas and Jason Vokes spoke to me about the company’s forthcoming RAD Studio XE3 development tool and in particular the new Metropolis framework which creates apps that have the appearance of a Windows 8 “Modern UI” (formerly known as Metro) but which are really desktop applications. Metropolis works with both the Delphi/C++ Builder VCL (Visual Component Library) and also with the newer FireMonkey user interface library.

“It’s a pretty large effort for us to get our compilers and runtime over to WinRT – which we intend to do”, said Thomas. In the meantime though, he argues that “Metro is just a style” and that developers will welcome the ability to “get their desktop apps over but participate in the Metro look and feel.”

End-users, explains Thomas, will not care about the WinRT or Win32 technology, but only notice that some apps have the new style and some do not. “We took the VCL and FireMonkey frameworks and used the styling engines that we introduced in XE2 to allow them to modify the forms to take on the look of those controls, as well as adding features like Windows 8 gesture support, improving the touch handling, and also taking on some of the standard templates like the grid and split views.”

Metropolis also support Live Tiles with update of dynamic content, and even enables apps to show up in the Windows 8 App Bar (which most desktop application do not support). This is done by means of a small WinRT app that is installed with the Metropolis application, and which communicates with it over a REST API – there being no built-in inter-process communication between desktop and WinRT apps. The WinRT app is a kind of proxy that lets the user launch or close the desktop Metropolis app. However access to Windows 8 contracts is not supported. “I think we’re hitting on the key elements that end users are going to expect when they’re working with WinRT applications,” says Thomas.

There is also the issue of how to deploy Metropolis apps. They will not be accepted by the Windows Store (other than perhaps as links to a vendor’s site as with other desktop apps), so how will software vendors get them onto a user’s machine? Getting the Win32 part installed is easy using standard Windows setup tools, but what about the WinRT component, if it is used? The procedure for installing a WinRT app without using the Store is called sideloading; and Microsoft intends that it only happens either for development and testing, or for enterprises deploying line of business applications.

“Sideloading requires a digital certificate and using a Powershell script that we provide to do the deployment,” says Thomas. “They can make that part of their standard desktop installer.”

Clever stuff; but will it work? I did some of my own testing. The most detailed technical article on WinRT app deployment is this one, which describes the  add-appxpackage PowerShell command which I presume Embarcadero is using. Using a Windows 8 Professional machine which does not have a developer licence installed, I was able to install my own WinRT app by trusting the certificate generated by Visual Studio as part of the Appx package, and after setting the key:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

However, although the app installed it did not run.

image

The reason is this:

The computer does not have to be joined to a domain or have an activated sideloading product key before you install provisioned LOB apps. However, the apps will not run until the computer meets this sideloading requirement.

The key statement here concerns the activated sideloading product key. What is this? There is also a reference to it by Microsoft’s Antoine Leblond here:

To enable sideloading of a Metro style app onto a [non domain-joined] PC:

  • Set Group Policy for “Allow all trusted apps to install”. If you cannot use Group Policy, then you can set this through the following setting: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1
  • Verify that the app is signed by a CA that is trusted on the target machines
  • Activate a special product key by using a script on the target machine to enable sideloading. We’ll go into more detail about how the IT admin will acquire the product keys in an upcoming blog post. The product key only needs to be install and activated once on the PC.

The word script is linked to the reference for slmgr.vbs which is used for installing and activating Windows product keys, so although Microsoft has yet to reveal everything about these special product keys, it does sound like something which only makes sense in an enterprise context. A third-party vendor cannot mess with slmgr.vbs, which implies that sideloading will not always work.

Here is a developer who has run into exactly this problem. He wants to be able to deploy “a Win32 app that has a sideloaded WinRT component”. Microsoft’s Tim Heuer says:

I’m pretty sure you’re going to need enterprise SKUs

Maybe Embarcadero has found some setting that makes it work; but even if they have, what if Microsoft made some change to WinRT in the name of security that closes off these loopholes? Or stops the Metropolis REST communication from working?

“Our testing shows that there are switches that can enable that mode and you can set your PowerShell script to do these things,” says Thomas about the latter issue. “We’re going to be working around some of the limitations or additional constraints that Microsoft may put on their environment. We’re going to have to be active in understanding the changes, in talking to Microsoft about it, and updating it as necessary to make it continue to work in their sandboxed environment. It is their environment after all.”

Might there be security risks for the user in opening up holes to make Metropolis apps work? “I don’t think so,” says Thomas. “The WinRT side of it is really just four functions. The fact that they may allow the WinRT app to do this communication I don’t think opens up any kind of security hole.”

Despite Thomas’s reassurance, it seems to me risky to depend on a feature that runs counter to the way the operating system is intended to work.

That said, you can use Metropolis without the WinRT component, though you lose Live Tile support; and in fact such apps will run on older versions of Windows such as XP and Windows 7 as well; though you would have thought that they would make more sense for tablet users who are likely to be running Windows 8 anyway.

Update: this link suggests you could get around the sideloading problem by checking for a development license in a script and renewing if necessary. Make all your users have development licenses though? That does not sound good to me.

embarcadero, microsoft, software development, windows

Third-party compilers locked out of Windows Runtime development

24 Comments

Embarcadero’s chief scientist Allen Bauer has posted about the problems facing tool vendors who want want to support Microsoft’s Windows Runtime (WinRT) platform with their own compilers, which he calls “Windows 8’s ‘dirty little secret.’”

The issue is that in order to enforce security and isolation in WinRT apps, Microsoft prohibits certain API calls. Even if you find a way to use them, applications that use these calls will not be accepted into the Windows Store, which in effect means no public distribution.

We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you’re the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management… Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store.

Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user’s app. We’re currently rattling some cages at MS to find out how or if they’re going to allow third-party tools to target WinRT. Until we can get past that, targeting WinRT isn’t actually possible from a deliverable product sense. We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

Bauer adds that there are other restrictions that make it hard to create an alternative toolchain:

For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls.

Embarcadero’s answer has been to create a framework that makes desktop apps look and behave somewhat like WinRT apps. I posted about these fake metro apps here. Even Live Tiles are supported. However, these apps cannot be distributed via the Store either, but only through a desktop setup. In addition, they lack the security of true WinRT, and access to the Contracts system for safe exchange of data.

The company does have a .NET tool in the works, called Prism, that will build WinRT apps.

Who is the villain here? Embarcadero’s concern is understandable, since it is locked out of creating a native code compiler for WinRT. On the other hand, to what extent can Microsoft relax the restrictions without blowing a hole in the WinRT security story. There are parallels with the complaints from Google and Mozilla that they cannot compete equally with IE10 in the Modern UI environment.

Thanks to .NET support, Microsoft does have a measure support for alternative languages; it is the Common Language Runtime after all. What would be better though would be to support LLVM, as Apple does on iOS, though this is not likely to be on Microsoft’s roadmap.

Thanks to Eric Grange for pointing me to this post.

.net, development, mobile, silverlight, software development, visual studio, windows

Hands on: building an app for Windows 8 Metro

2 Comments

How difficult is it to build an app for the Windows Runtime (WinRT), which powers Metro-style apps in Windows 8?

Here is how I created a simple calculator app (this is one in an occasional series) using Visual Studio 11 beta. I started with a new Visual C# Windows Metro Style project, choosing a blank template.

image

A slight complication is that you are prompted to install a Developer License, which means logging into your Windows Live account.

image

Next, I had to layout the controls. Visual Studio creates a single-page app with a main page called BlankPage.xaml. I renamed this to Calc.xaml. I also used Visual Studio’s refactor menu to rename the page class from BlankPage to Calc.

image

The default application has a black background, which seems gloomy. I changed the Background of the container grid to white.

My basic calculator design is based on six rows and four columns, so I added 6 RowDefinitions and 4 ColumnDefinition to the XAML grid. The units for RowDefinitions and ColumnDefinitions can be set to Auto, Pixel or Star. Star means the unit is a weight which is calculated at runtime. For example, if you set the value of one RowDefinition.Height to 2 and the others to 1, the first one would be twice as high as the others. Here is my basic grid:

image

Next, I placed controls in the grid. The easiest way to get them to fill the space neatly is to set their HorizontalAlignment and VerticalAlignment properties to Stretch. Then you control the margin round the control with the Margin property. You can have a control fill more than one cell by using the Grid.ColumnSpan and Grid.RowSpan properties.

I found it easier to add the controls in code using copy and paste.

image

A Grid has no FontSize property, and although the Page has a FontSize property it does not seem to be inherited by the controls. I therefore set the FontSize individually for each control but there must be a better way of doing this.

I then wrote minimal code that performs calculations without always crashing, and tested the app.  When you debug, you can choose Local Machine, Simulator, or Remote Machine. I found it easier to debug using the simulator, since if you use Local Machine and Visual Studio is running on the main display, then the app you are debugging becomes invisible if you hit a breakpoint or exception. The simulator seems really good (it is actually a remote session into your own machine) and I would like some way of running all Metro apps in a window like this, not just for debugging!

image

A few reflections

A developer with experience of C# and XAML (which is also used by Windows Presentation Foundation and by Silverlight) will not have much trouble getting started with WinRT, though I noticed that XAML is substantially cut-down, as Patrick Klug observes here.

Visual Studio 2011 is an excellent IDE although I do not much like the new property editor; a minor point, but I find the latest go at prettification detrimental to usability; it is too busy. This may be a matter of familiarity and it is a minor point.

image

The XAML visual designer is slow to refresh even with my simple app, so this could be annoying with a more complex layout.

Layout with XAML works well, though it is more difficult than say Windows Forms for a new developer. It is easy to get peculiar results unless you do everything with pixel layout, which is not the best approach.

What about Metro itself? Apps always run full screen, and I had a problem with this in that my little calculator does not need all that space.

image

I am not a designer; and I suppose with a bit of effort you could add some decoration or effects to use the space, or add extra features. But why?

I was thinking about the Atari ST the other day, following the death of Jack Tramiel. The ST did not really multitask, but to get around the problem of needing to run a second app without closing the first, it had the concept of desktop accessories, available from a pull-down menu. My calculator would work well as a desktop accessory in Metro, except there is no such concept – unless you count the “Snap” split view. I wonder if Microsoft is too religious about its “Immersive UI” concept.

A few reservations then; but that does not take away from the overall impression of a strong integrated development experience for building Metro-style apps.

.net, development, microsoft, mobile, software development, windows

Windows on ARM: Microsoft can write Desktop apps, but you cannot

15 Comments

Microsoft’s Windows chief Steven Sinofsky has written a long post describing Windows on ARM (WOA), which he says is a:

new member of the Windows family, much like Windows Server, Windows Embedded, or Windows Phone

There are many point of interest in the post, but the one which stands out for me is that while the traditional Windows desktop exists in WOA, third party applications will not be allowed there:

Developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services. The Windows Store can carry, distribute, and service both the ARM and x86/64 implementations of apps (should there be native code in the app requiring two distributions).

says Sinofsky. He writes with extreme care on this issue, since the position for which he argues is finely nuanced. Why have the Windows desktop on WOA at all?

Some have suggested we might remove the desktop from WOA in an effort to be pure, to break from the past, or to be more simplistic or expeditious in our approach. To us, giving up something useful that has little cost to customers was a compromise that we didn’t want to see in the evolution of PCs

he says, while also saying:

WOA (as with Windows 8 ) is designed so that customers focused on Metro style apps don’t need to spend time in the desktop.

From a developer perspective, the desktop is more than just a different Windows shell. Apps that run on the Windows Runtime (WinRT) are isolated from each other and can call only a limited set of “safe” Windows APIs, protecting users from malware and instability, but also constraining their capabilities. The desktop by contrast is the old Windows, an open operating system. On Windows 8 Intel, most things that run on Windows 7 today will still work. On WOA though, even recompilation to target the ARM architecture will not help you, since Microsoft will not let desktops apps install:

Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.

What if you really want to use WOA, but have some essential desktop application without which you cannot do your work, and which cannot quickly and easily be ported to WinRT? Microsoft’s answer is that you must use Windows on Intel.

That said, Microsoft itself has this problem in the form of Office, its productivity suite. Microsoft’s answer to itself is to run it on the desktop:

Within the Windows desktop, WOA includes desktop versions of the new Microsoft Word, Excel, PowerPoint, and OneNote, codenamed “Office 15”.

No Outlook, which I take to imply that a new WinRT-based Exchange client and PIM (Personal Information Manager) is on the way – a good thing.

Microsoft’s aim is to give customers the security and stability of a locked-down machine, while still offering a full version of Office. If you think of this as something like an Apple iPad but with no-compromise document editing and creation, then it sounds compelling.

At the same time, some users may be annoyed that the solution Microsoft has adopted for its legacy desktop application suite is not also available to them.

The caveat: it is not clear in Sinofsky’s post whether there may be some exceptions, for example for corporate deployments, or for hardware vendors or mobile operators. It will also be intriguing to see how Office 15 on ARM handles extensibility, for example with Office add-ins or Visual Basic macros. I suspect they will not be supported, but if they are, then that would be a route to a kind of desktop programming on WOA.

It will be interesting to see how Microsoft locks down Explorer, which Sinofksy says is present:

You can use Windows Explorer, for example, to connect to external storage devices, transfer and manage files from a network share, or use multiple displays, and do all of this with or without an attached keyboard and mouse—your choice.

By the way, this is a picture of the Windows ARM desktop as it looked at the BUILD conference last September. The SoC (System on a Chip) on this machine is from NVIDIA.

.net, microsoft, professional

Data Access in Windows 8 WinRT

1 Comment

I’ve been teasing out details about the Windows Runtime (WinRT) here at Microsoft’s BUILD conference in Anaheim, California.

WinRT is the runtime for touch-friendly Metro-style apps, in effect Microsoft’s operating system for tablets, though it has a dual personality and full desktop Windows is also available.

Microsoft experts told me that there is no client for SQL Server or other network databases in WinRT. To access such databases, you have to create a web service and call that. This is similar to the Silverlight model. The .NET Framework in WinRT will support WCF RIA Services, which is one option for this.

If you only want to store and retrieve data locally, there seems to be a JET API, or you could use something like SQLite or roll your own simple database manager. HTML and JavaScript apps support IndexedDB. All these options read and write data to the app’s isolated storage; they do not enable free access to the file system.

LINQ (Language Integrated Query) is supported but of course that is only as useful as the data it can connect to.

.net, professional, silverlight, software development, windows

A few facts about Microsoft’s new Windows Runtime

25 Comments

I’ve just come out of Martyn Lovell’s talk on WinRT internals here at BUILD in Anaheim, California.

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).

WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.

Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

There is no inter-app communication in WinRT other than by the pre-defined contracts built into the system (though Lovell noted that you could always use the file system and polling for a crude inter-process communication).

There is no way to install a shared dynamic library. Apps can only use the system libraries together with what you install with the app. Each app lives in its own context and is isolated. In other words, WinRT is not extensible, other than within your app’s code*.

If you figure out a way to bypass limitations of WinRT by calling other Windows APIs, your app might work but the submission process for the Windows Store will prohibit it.

Versioning is built into WinRT. This means that when Windows 9 comes along, you will be able to code just against the Windows 8 versions of the classes, for compatibility, and your IDE can support this by only exposing the Windows 8 version of the API.

The CLR exists in the Metro environment, for use by .NET applications, complete with JIT (Just in time) compilation. However only a subset of the .NET Framework libraries are included. Microsoft aimed to include only what was necessary for Metro. I am not sure yet what is included and what is not, beyond the obvious (no Windows Forms, for example) but will be investigating what is documented. The native WinRT APIs look similar to a COM callable wrapper from the .NET side. That said, you do not normally need to care about WinRT interfaces, even though these are there in WinRT. Normally you interact with WinRT classes, making it more natural for .NET than working with COM.

WinRT is full of asynchronous calls. Lovell told us that Microsoft had seen in the past that if both synchronous and asynchronous APIs are available for the same function, then developers often use the synchronous version even when they should not, making applications less responsive. The new await keyword in C# makes this easy to code.

WinRT makes use of the ILDasm metadata format which is also used by .NET. This means you get rich metadata for IntelliSense and debugging, but note that the actual runtime is not .NET; they just borrowed the same metadata format.

WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity. You should not have to worry about this; you can code according to the conventions of your language.

There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. Lovell assured me that there is little difference in performance in most cases, though there could be advantages for C++ in certain niche scenarios. Of course we heard that story for .NET as well, but from what I have seen it is more plausible in WinRT.

There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. It seems that you will need to use C++ for fancy DirectX coding, though this is not confirmed. Of course your XAML or Canvas code will be rendered by DirectX under the covers.

It is fascinating to see how Microsoft has borrowed XAML and ILDasm from .NET, but that WinRT is native and not .NET at its core. My take on this is that Microsoft intended to preserve the productivity of .NET, but without any performance compromise.

Despite the inclusion of .NET though, the fact that only a subset of the Framework is available, and that interop to the Windows API will not work*, means that most existing apps will need considerable work to be ported to Metro.

*Updates

A few clarifications.

It has been shown that you can call WinRT from Win32 (the favoured word for Win32 seems to be “desktop applications”) though I’m not sure how useful it is.

Concerning P/Invoke (Platform Invocation) to Win32 APIs, apparently this does work for a certain specified, small subset of the Windows API. It also works for your own native code DLL, with the proviso that if your native code DLL calls a disallowed Win32 API it will raise an error.

WinRT is partially extensible. A Framework Extension is a library which you can reference as a dependency in your app’s manifest. When the app is deployed it will download this dependency from the Windows Store. An example is the C Runtime Library. An extension library installs into its own directory, and can be used by multiple WinRT apps provided each one also references it in their manifests. However, the caveat is that only Microsoft can create these extensions: there is no way to create your own shared extension for general distribution, though an enterprise can deploy a shared extension internally.