Category Archives: software development

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.

.net, microsoft, professional, software development, windows

Developing a Windows Runtime app: some observations

2 Comments

What would it take to create a Windows 8 Modern UI content reader for this site? Just for fun, I built a simple one; or rather, I slightly adapted Microsoft’s Metro style blog reader tutorial.

The app only has four screens (or pages) but despite its simplicity I found the tutorial somewhat fiddly. Getting the data from the WordPress RSS feed is simple, thanks to the Windows.Web.Syndication namespace which is part of .NET Framework 4.5. Most of the work is in the user interface, which means switching between XAML and C#. Of course as a developer I would rather work in C#.

Further, the Visual Studio editor for C# is better than the editor for XAML. In C# I can easily navigate the code using Go to Definition, Find all References, and so on.  In XAML it takes longer to find things like referenced styles and resources. Plus XAML is XML, which I find harder to read than an elegant language like C#. Even commenting out a line is more hassle in XML.

I did not like the colours used by the tutorial for the list of posts in SplitePage.xaml. It took me a while to work out what to change. Was the colour defined in a resource, or in a template, or in a style, or directly coded as an attribute of the relevant TextBlock object?

Of course you can open the XAML in Blend if you prefer, the designer-oriented tool that comes with Visual Studio 2012. Blend is more complex than the Visual Studio XAML editor, but may be better once you have figured out how it works.

The amount of work involved in making your app well-behaved is proportionately larger if your app is essentially very simple. You have to deal with different layouts for different screen sizes and orientation, as well as the small Snapped layout. You also have to consider what happens if your app is suspended and resumed.

The above means that despite the apparent simplicity of a Modern UI interface, with its chunky buttons, there is more to consider than with, say, a Windows Forms application whose window is never rotated and over which you have full control.

Still, I was pleased with my app which has reasonable functionality based on a small amount of work.

Visual Studio 2012 is impressive, though I did experience some screen corruption after switching back and forth between the Metro and Visual Studio environments for debugging. Restarting Visual Studio fixes it. Using the simulator seems more robust in this respect.

image

The App Bar

One thing though. If you squint at the above screenshot, you will see that I have put a Read button to the right of the post title. Clicking or tapping this opens the post in a embedded web browser view that is nearly full-screen. However, this Read button is not included in the tutorial, which says:

On the split page, we must provide a way for the user to go to the detail view of the blog post. We could put a button somewhere on the page, but that would distract from the core app experience, which is reading. Instead, we put the button in an app bar that’s hidden until the user needs it.

This may in fact be an excuse to include an App Bar in the tutorial; but I disagree with it. With the App Bar, the user has to right-click or swipe down to display the App Bar, and then click or tap the View Web Page button.

image

That is two actions rather than one. Is it really better than having a small button in the UI?

It seems to me that tucking things into the App Bar is fine in cases where there is real merit in an immersive experience, such as in the web browser, but less compelling when you already have a screen with a back button and a scrollable list. I was also concerned that users might not realise they needed to display the App Bar in order to use the app properly.

Let the design debate continue.

Design-centric

Microsoft’s Modern UI continues a trend which began with Windows Presentation Foundation (the first incarnation of XAML), which is to make a platform richer for UI designers and more challenging for developers who lack design skills. Nothing wrong with that; but if you remember how easy it was to snap together an app in Visual Basic 3.0, you may feel that something has been lost.

I guess that recognition of that fact was one of the motivations behind Visual Studio LightSwitch, in which you define the data and business rules, but the screens are generated for you. LightSwitch has complexities of its own though.

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.

delphi, development, embarcadero, software development, web authoring, windows

Embarcadero previews Metropolis in RAD Studio XE3: fake Metro apps?

4 Comments

Embarcadero has released a video (embedded at the foot of this post) previewing RAD Studio XE3, the next version of the application development suite which includes Delphi and C++ Builder.

Two big new features are Metropolis applications and an new HTML5 Builder tool which looks like a next-generation PHP Builder.

Metropolis – a neat name until Microsoft back-pedalled on the Metro designation for Windows Runtime apps – appears to be a framework for apps that look like Windows Runtime apps but in reality are not. At least, that is my presumption for “VCL Metropolis applications”. The VCL (Visual Component Library) is a Delphi framework (usable also in C++ Builder) which is tied to Windows and GDI, the old-style Windows graphics API, along with many other Win32 APIs. GDI does not work in the Windows Runtime.

image

No matter, all we need is full-screen apps, touch input, and a don’t-call-it-Metro look and feel, and presto, Windows Runtime apps in all but name. They might even run on Windows 7.

image

A glimpse at the controls.

image

Except that there will be significant differences between Metropolis and Windows Runtime. No support for Contracts, for example, the Windows Runtime mechanism for inter-app communication; no delivery from the Windows Store; no support for Windows RT.

The big issue though is this: why would you want a desktop app to look like a Windows Runtime app? And will not users be mightily confused?

The video then goes on to talk about converting existing apps with a “Convert to Metropolis UI” menu option. It turns out though that you can also create FireMonkey Metropolis apps, and the Convert to Metropolis UI option is shown with a FireMonkey app, not a VCL app. Since the FireMonkey framework is designed for cross-platform and uses custom drawing for all its controls, potentially a FireMonkey app could be a real Windows Runtime app, though I get the impression it probably is not.

image

I do think Embarcadero needs absolute clarity here, which is notably lacking in this preview. There is no point in pretending that a Win32 app is a Windows Runtime app when it is not. I have asked for further information.

HTML5 Builder

There is also a quick look at HTML5 Builder.

image

This tool targets server-side development with PHP, as well as apps for web,iOS,Android, Blackberry and Windows Phone. My guess is that there is PhoneGap/Cordova under the covers. I also saw some jQuery in the demo.

image

Here is a look at the CSS3 colour picker.

image

Update: looks like Embarcadero found a way to fake Live Tiles as well:

Metropolis applications are really traditional "desktop" applications styled to look like the Metro UI.
The TLiveTemplate component spawns a new process in the WinRT space which is is an actual WinRT LiveTile application. The LiveTile communicates with the Metropolis "desktop" backend via HTTP/REST to start/stop the application or update the LiveTile.

The screenshots are drawn from this video, or you can watch it on the Embarcadero site here.

For more info from attendees of the RAD Studio XE3 world tour see also:

http://members.adug.org.au/2012/08/22/highlights-of-the-sydney-xe3-event/

https://forums.embarcadero.com/thread.jspa?threadID=75773

microsoft, software development, windows

Microsoft really, really wants developers to build Windows Runtime apps

5 Comments

Or should that be Metro-style apps? or Modern UI apps? or Windows Store apps?

I am not sure; but one thing jumps out at me as I look at the Windows 8 development platform. Microsoft is doing all it can to push developers towards Windows Runtime (WinRT) rather than desktop development.

Here is a small piece of evidence. The contentious new Start screen uses tiles for application shortcuts. These can be static images and text, or live tiles that update with current information. There is only one Start screen though, so desktop apps also have tiles which you click or tap to launch the app in question.

However, there is no documented way for desktop apps to have good-looking tiles. Here is the tile for Excel 2013, for example:

image

It is mostly wasted space. A WinRT app on the other hand can fill that space:

image

or display a picture

image

or take up a double space

image

The question: how difficult would it have been for Microsoft to allow desktop apps to have pretty tiles? I can understand why desktop apps cannot have live tiles, but there is no technical reason I can think of why desktop apps could not have a resource used for a decent tile.

Here is the official answer though, from Microsoft’s Rob Caplan:

Desktop apps cannot customize their tiles and will always use the icon and name from their shortcut.

I guess Microsoft can argue that it wants users to know whether they are about to launch a desktop app or a WinRT app. This could easily be done with a little overlay signifying the desktop. There was no need to ensure that all tiles for desktop apps look ugly.

Except that Microsoft wants these tiles to look ugly. Because it wants you to develop WinRT apps, not desktop apps, and is even willing to have its own Office tiles look bad for the sake of the cause.

Update

This post was picked up by Reddit and of course there are some interesting comments. First, the desktop tiles are improved in the RTM build of Windows 8 (my screenshot above is from the Release Preview):

image

Second, here is a comment apparently from a Microsoft employee:

Wow, what a flimsy argument. The funniest thing about it, though, is that the desktop tiles look MUCH better in the RTM build (though customization is still left to Modern apps). Can’t seem to find a screenshot though.

But on the other hand, of course we want people to develop Modern apps. That’s why we built the platform. But the desktop tiles aren’t a part of that at all.

If I were the author, I’d bring up Contracts as a much better example. Desktop apps can’t support the Share Contract, or Search, or whatever; only Modern apps can. Of course, there’s no telling if this is simply a v1 limitation or a longer strategy; even I have no idea (I’ve only been at the company a little over a year). If we waited to release Windows until we had implemented everything we wanted to do, it wouldn’t come out for years. We have to draw the line somewhere.

Disclaimer: these are my thoughts, not the company’s.

In defence, I presented this only as a “small piece of evidence”.

Note the use of the term “Modern apps”.

microsoft, professional, software development, windows

Microsoft toughens logo requirements for Windows 8, forbids startup apps

1 Comment

Today I came across the certification requirements for Windows 8 desktop apps. This is the successor to the Windows 7 Logo program, and represents a set of best practices required for software to display the official Windows logo.

In practice, I am not sure how many buyers check that software is certified before buying, though it might make sense for businesses to do this as a matter of policy if they want keep Windows desktops running smoothly and safely.

The requirements are also interesting as a guide to what Microsoft considers to be well-behaved applications.

The new requirements are tougher than before. Some guidelines that were in the “Beyond Windows 7” section in the previous logo program have now moved to become full requirements. Others seem to be completely new.

Here are some highlights:

  • Your app must not depend on any Windows compatibility feature, nor the VB6 runtime.
  • Apps may not start automatically on startup. You may not set the “run” registry keys nor install a shortcut into a startup folder.
  • Apps must use “strong and appropriate ACLs” to secure executables, directories and registry keys.
  • Apps must be compiled with /SafeSEH (safe exception handling), /NXCOMPAT (no data execution) and /DYNAMICBASE (random address space layout).
  • All executables must be signed with an Authenticode certificate – this was the same in Windows 7 but worth repeating.

The automatic startup prohibition is particularly intriguing. It could not be clearer:

10.2 Your app must avoid starting automatically on startup

I hate unnecessary startup applications too; but I do not object to all of them. My password manager runs on startup and sits in the notification area. Some of Microsoft’s own applications do this, for example Lync, Skype and SkyDrive. I would have thought auto-startup is acceptable if it is under the user’s control.

One factor may be that Windows 8 desktop apps do not auto-start on log-in even if you set them to do so. Instead, they start when the user clicks or taps into the Desktop. Therefore, in a sense none of the normal auto-start techniques are reliable.

There is a way round this, which is to install an autorun service.

In general, tough certification requirements are a good idea, though if they are too demanding the risk is that vendors will simply ignore them.

.net, development, software development

Using Windows Runtime (WinRT) APIs from desktop applications

After trying out Windows 8 notifications from a Windows Forms application, I did a bit of research into using the Windows Runtime (WinRT) API from desktop applications.

It turns out that this is something Microsoft planned for:

Desktop apps should for the most part be able to use WinRT. This is an area where we should have more information moving forward.

says Microsoft’s David Lamb, in Developer Support. He was answering a question about the Proximity APIs.

How do you do it? In C/C++, according to Steve Harne:

For this to build, you’ll need to set the following compiler switches in the the C++ Win32 Console wizard generated project:

C/C++ / General Settings
    Enable Windows Runtime Extensions (/ZX)
    Additional #Using Directories (/AI) -> set this to "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata" (modify as per your installation)

C/C++ / Code Generation
    Disable Minimal Rebuild (/Gm-)  -> this is not compatible with /ZX

In .NET applications you can set a reference to Windows.winmd. This is a WinRT metadata file, which you can browse in the Visual Studio object browser.

image

You even get a short summary describing each class and class member.

Note that as Microsoft’s Larry Osterman explains here:

there is absolutely no (zero) il in the windows.winmd file – it’s a metadata-only assembly. This is important because winmd files only describe structure, they don’t contain code (note that the C# compiler can produce hybrid winmd files that also contain some code, this was to support certain C# scenarios)

While a lot of stuff works, there will be WinRT API calls that make no sense other than for real WinRT apps. It is also worth noting that all of this is specific to Windows 8 (and higher, I presume). Since most desktop apps will need to be compatible at least with Windows 7, this requires some care. Lamb also says:

WinRT APIs may be tied to Metro style apps, Desktop apps or potentially available to both. The documentation will list which environments (Desktop, Metro style or both) a given API works in.

and in fact you can see this in the documentation. For example, the docs for the ToastNotification class states:

Applies to: Metro style apps | desktop apps

image

whereas if you look at the ContactPickerUI class, it says:

Applies to: Metro style apps only

For those APIs where desktop use is supported, you can go right ahead.

.net, professional, software development, windows

Notifications in Windows 8: how to display new-style toast from a desktop app

5 Comments

This post was prompted by the discussion over the fact that Windows 8 boots into the Start screen, and cannot apparently be modified to boot into the Desktop (though no doubt someone will find a way).

What if, I wondered, you put a desktop app into your startup folder so it runs automatically on boot? The answer: it runs on the desktop, but you will not see it until you click or tap into the desktop from the start screen. This is different behaviour from actually starting a desktop app from the start screen, which switches you to the desktop.

So what if that desktop app has something important to tell you? The answer: you will not see it until you switch to the desktop.

To demonstrate this, I wrote a Windows Forms app that displays a MessageBox alert after a 5 second delay. I ran the app, activated the alert, and switched to a Windows Runtime Metro app. When the alert fired, I heard a little ding, but saw no message. Only after switching to the desktop did I see the message.

image

To be fair, you might not see this even if you were working in the desktop, since Windows has complex (and sometimes unpredictable) rules about when apps are allowed to come to the foreground. Even calling the Activate method, which gives your window the focus, may do no more than flash the icon on the taskbar.

Windows 8 has a new-style “toast” notification mechanism that works across both desktop and Windows runtime. I got this working in my Windows Forms app.

image

So how do you do this? For some background, see Jim O’Neil’s series of posts which start here. However, I mostly used code from the sample Sending toast notifications from desktop apps. This is a WPF application, but I got the code to work in my Windows Forms application. Note that to reference Windows.UI.Notifications you have to add a reference to:

C:\Program Files (x86)\Windows Kits\8.0\References\CommonConfiguration\Neutral\Windows.winmd

Update: in the release version of Visual Studio 2012 the way you reference winmd has changed. See this MSDN article and the section called Core Subgroup; however at the time of writing the method described there does not quite work. Instead, proceed as follows. First right-click the project in the Solution Explorer and choose Unload Project. Then right-click the project again and choose Edit [project].csproj. Add the following to the project file after the other Reference elements:

<Reference Include="Windows" />

then save and close the editor. Finally, right-click the project name again and choose Reload project. Do not add the suggested TargetPlatformVersion element, since if you do the project will not compile.

You also need the Windows 7 API code pack which is here.

Here is a quick summary though. In order to display a toast notification, you first need a shortcut to your app on the Start menu. In addition, the shortcut has to have an AppUserModeId, which you can set in code.

Once that is sorted, you can use the ToastNotificationManager class – for which you need that reference to Windows.UI.Notifications – and retrieve a standard XML template for the notification. You can add event handlers to the notification, so you can respond if the user clicks it. Then call:

ToastNotificationManager.CreateToastNotifier(APP_ID).Show(toast);

to actually show the notification.

Note that your event handlers will not fire on the UI thread, so you need to use thread-safe methods if you want to interact with controls on your form.

It is all somewhat laborious, but on the plus side you get notifications which are better than the old notification area toast, and much better than MessageBox.

Note that this is one bit of code applications will only have if they are modified to work on Windows 8. That is worth noting if you have an application in which notifications play an important role.

image

development, linux, microsoft, open source, software development

Valve announces Steam-powered apps beyond games as well as embracing Linux

2 Comments

Steam maker Valve has announced that it is expanding beyond games, to sell software titles that “range from creativity to productivity”.

image

The Steam software is more than just a store. The platform handles updates, digital rights management, and supports multiplayer gaming. It also forms a chat network. The Steam overlay lets users access Steam features while playing a full-screen game.

Users can install a Steam title on multiple computers but can only play while logged in, and can only log in on one device.

Steam launched first on Windows, but also has clients for Mac and, via Wine compatibility, on Linux. There are also mobile clients for Android and iOS, and some support for PlayStation 3, though these have limited features. The mobile clients do not let you buy and run games for the mobile device itself.

With Apple, Google and now Microsoft backing their own app stores for their respective platforms, Valve has some tricky manoeuvring ahead if it is to avoid being squeezed out. Valve founder Gabe Newell made headlines recently by calling Windows 8 a “catastrophe”, though he is hardly a disinterested party. Note that he should not worry too much about Windows 8 in the short term, since Microsoft’s store does not support desktop titles other than by links to third-party sites, including Steam. However the general trend towards locked-down platforms with software installed only through an official store must be a concern to Newell.

Valve is turning towards Linux as a possible solution. It is talking at the Siggraph conference this week in Los Angeles about its work on OpenGL and Linux, and it seems that a native Linux Steam client is in prospect.

Could Windows gamers, or others disillusioned with Windows 8, turn to Linux in significant numbers as an alternative? While this is possible, it seems more likely that the Mac would benefit. You would also imagine that skilled gamers will be smart enough to operate the Windows 8 Start menu and discover that most of their stuff still runs fine on the new desktop.

The Steam platform is a strong one though, and with Microsoft not supporting desktop apps through its own Store, Valve has a good opportunity to extend its reach.

According to its own stats, Steam has peaked at over 4 million concurrent users this month.

image

microsoft, professional, software development

Fixing Visual Basic for Applications code for 64-bit Microsoft Office

The first macro programming language in Microsoft Office was Basic, and it is still there in the forthcoming Office 2013. In fact, Visual Basic for Applications (VBA) has been slightly updated, and reports itself as version 7.1 in the preview. The version is Office 2010 is 7.0.

image

Although it is embedded in Office, VBA is a powerful tool and there is not much that you cannot do. It is based on the same runtime that powers Visual Basic 6.0, the last version before the .NET revolution.

Visual Basic makes it easy to call the Windows API though the Declare statement. One implication though is that code written for 32-bit VBA may need revising to work in 64-bit Office, and I ran into this recently with some VBA code of my own.

Some existing Declare statements will work fine on both platforms, but Microsoft chose to force developers to review all of them by introducing a new PtrSafe attribute. The name of this attribute is dubious in that it does nothing to ensure pointer safety. In fact it does nothing at all other than to say to the compiler that the Declare works in 64-bit Office, whether or not it really does. Still, it means you have to add PtrSafe to all your Declares, the idea being that you check that they work. Without PtrSafe, the Declares will not execute in 64-bit Office.

The details of what to change are here. What that article does not mention though is that Microsoft has provided declarations for the most commonly used API declarations that work in both 32-bit and 64-bit VBA. The file is called Win32API_PtrSafe.txt and you can download it here. The file is too large to load into a single VBA module but you can use it to find the declarations that you need.

It can still be difficult to work out how to call some APIs. Note that if you get it wrong VBA and Office may crash. You are giving up the safety of VBA once you use these functions.

I have not yet seen Office running on ARM in Windows RT, but the rumour is that VBA is not supported. That is not surprising, since with VBA you can code pretty much any desktop application, if you don’t mind it running within Office, undermining Microsoft’s intention that only Windows Runtime (formerly known as Metro) apps can be installed on Windows RT.