Category Archives: software development

Windows XP Mode hassles for Windows 8 upgraders

One of the reasons for the success of Windows 7 was the provision Microsoft made for customers stuck with applications that only run on Windows XP. Windows XP Mode is a free add-on for Windows 7 Professional that runs Windows XP. It can also hide the XP desktop and run individual applications in their own window, though this is cosmetic and merely hides the desktop. Windows XP Mode uses Virtual PC as its virtualisation platform.

What would expect to happen if you upgraded Windows 7 with XP Mode to Windows 8? Without having researched it, my expectation was that Windows XP Mode would migrate smoothly to Hyper-V in Windows 8.

Not so. Here is the official word:

With the end of extended support for Windows XP in April 2014, Microsoft has decided not to develop Windows XP Mode for Windows 8.  If you’re a Windows 7 customer who uses Windows XP Mode and are planning a move to Windows 8, this article may be helpful to you.  
When you upgrade from Windows 7 to Windows 8, Windows XP Mode is installed on your machine, however Windows Virtual PC is not present anymore. This issue occurs because Windows Virtual PC is not supported on Windows 8. To retrieve data from the Windows XP Mode virtual machine, perform the steps listed in the More Information section.

If you were relying on XP Mode to run some old but essential application, this is definitely worth knowing. Microsoft’s guidance on retrieving the data is unlikely to be much use, since the reason you use XP Mode is to run applications rather than to store data. Some users are not impressed:

This is SHOCKING.  I was using Win 7 Pro and had a fully configured (hours of work) XP Virtual Machine with my complete web development environment in it.  It didn’t even occur to me that it wouldn’t work on Windows 8.  I’ve only just discovered now when I tried to access it to do some updates!

I MUST recover this virtual PC.

Why did the Upgrade Advisor not mention this!?!?  I carefully resolved all the issues highlighted there before moving on.

Of course it is desirable to move off Windows XP completely, even in XP Mode, but the rationale is that it is better to be on a recent and supported version of Windows and to run XP in a virtual environment, than to run Windows XP itself.

Another oddity is that you can run Windows XP on Hyper-V in Windows 8. However you cannot get XP Mode to work unless you perform a repair install that changes the way it is licensed. Yes, it is licensing rather than technical reasons that blocks the XP Mode upgrade:

Note: The Windows XP Mode virtual hard disk will not work on Windows 8 as Windows 8 does not provide the Windows XP Mode license. The Windows XP Mode license is a benefit provided on Windows 7 only.

Users have discovered workarounds. Aside from the repair install mentioned above, you can also use Oracle Virtual Box and trick XP Mode into thinking that it is running on Windows 7 and Virtual PC. You can also run a virtual instance of Windows 7 and run XP Mode within that.

Microsoft and mediocrity in programming

A post by Ahmet Alp Balkan on working as a developer at Microsoft has stimulated much discussion. Balkan says he joined Microsoft 8 months ago (or two years ago if you count when he started as an intern) and tells a depressing tale (couched in odd language) of poor programming practice. Specifically:

  • Lack of documentation and communication. “There are certain people, if they got hit by a bus, nobody can pick up their work or code.”
  • Inability to improve the codebase. “Nobody will appreciate you for fixing styling or architectural issues in their core, in fact they may get offended.”
  • Lack of enthusiasm. “Writing better code is not a priority for the most”
  • Lack of productivity. “I spend most of my time trying to figure out how others’ uncommented/undocumented code work, debugging strange things and attending daily meetings.”
  • Lack of contribution to the community. “Everybody loves finding Stack Overflow answers on search results, but nobody contributes those answers.”
  • Lack of awareness of the competition. “No one I met in Windows Azure team heard about Heroku or Rackspace.”
  • Working by the book. “Nobody cares what sort of mess you created. As long as that functionality is ready, it is okay and can always be fixed later.”
  • Clipboard inheritance. “I’ve seen source files copy pasted across projects. As long as it gets shit done (described above) no one cares if you produced unmaintainable code.”
  • Using old tools. “Almost 90% of my colleagues use older versions of Office, Windows, Visual Studio and .NET Framework.”
  • Crippling management hierarchy. “At the end, you are working for your manager’s and their managers’ paychecks.”

There are a couple of points to emphasize. This is one person in one team which is part of a very large corporation, and should not be taken as descriptive of Microsoft programming culture as a whole. Balkan’s team is in “the test org”, he says, and not making product decisions. Further, many commenters observe that they have seen similar at other organisations.

Nevertheless, some of the points chime with other things I have seen. Take this post by Ian Smith, formerly a Microsoft-platform developer, on trying to buy a Surface Pro at Microsoft’s online store. From what he describes, the software behind the store is of dreadful quality. Currently, there is a broken image link on the home page.

image

This is not how you beat the iPad.

Another piece of evidence is in the bundled apps for Windows 8. The more I have reflected on this, the more I feel that supplying poor apps with Windows 8 was one of the worst launch mistakes. Apps like Mail, Calendar and Contacts on the Metro-style side have the look of waterfall development (though I have no inside knowledge of this). They look like what you would get from having a series of meetings about what the apps should do, and handing the specification over to a development team. They just about do the job, but without flair, without the benefit of an iterative cycle of improvements based on real user experience.

When the Mail app was launched, it lacked the ability to see the URL behind a hyperlink before tapping it, making phishing attempts hard to spot. This has since been fixed in an update, but how did that slip through? Details matter.

A lot is known about how to deliver high quality, secure and robust applications. Microsoft itself has contributed excellent insights, in books like Steve McConnell’s Code Complete and Michael Howard’s Writing Secure Code. The Agile movement has shown the importance of iterative development, and strong communication between all project stakeholders. Departing from these principles is almost always a mistake.

The WinRT platform needed a start-up culture. “We’re up against iPad and Android, we have to do something special.” Microsoft can do this; in fact, Windows Phone 7 demonstrated some of that in its refreshing new user interface (though the 2010 launch was botched in other ways).

Another piece of evidence: when I open a Word document from the SkyDrive client and work on it for a while, typing starts to slow down and I have to save the document locally in order to continue. I am not alone in experiencing this bug. Something is broken in the way Office talks to SkyDrive. It has been that way for many months. This is not how you beat Dropbox.

In other words, I do think Microsoft has a problem, though equally I am sure it does not apply everywhere. Look, for example, at Hyper-V and how that team has gone all-out to compete with VMWare and delivered strong releases.

Unfortunately mediocrity, where it is does exist, is a typical side-effect of monopoly profits and complacency. Microsoft (if it ever could) cannot afford for it to continue.

Build Mac and iOS apps in Visual Studio: Oxygene for Cocoa

Remobjects has released Oxygene for Cocoa, which lets you build apps for Mac and iOS using Visual Studio and the Oxygene language.

Oxygene is a Delphi-like language, making this an easy transition for Delphi developers. Until the most recent release, a version of Oxygene, called Prism, was bundled with Delphi, though this targeted .NET rather than Cocoa. Oxygene can also build apps for the Java runtime, making it a three platform solution.

The cross-platform approach is different from that taken by Embarcadero with FireMonkey, a cross-platform framework for Delphi itself. FireMonkey abstracts the GUI as well as the non-visual code, and in many cases controls are drawn by FireMonkey rather than using the native controls on platforms such as iOS. By contrast, Oxygene works directly with the Cocoa frameworks, so you will build the GUI in code or using the Xcode tools on the Mac.

More like Xamarin then? “We do work together with Mono and with Xamarin,” says Remobjects chief Marc Hoffman. “Oxygene for .NET works with the regular Mono framework for desktop or server apps. But when you get to the devices, the benefit with Oxygene is that you get much closer to the framework, you don’t have the weight of providing an abstraction for the classes you want to use.  If you write a UITableViewController to define a view, then you really write a UITableViewController, the same as you would in Objective-C, just the language is different, whereas in Xamarin you write a different class that sits on top and Mono does the mapping.”

Why not just use Xcode? This is in part a language choice. Remobjects says that Oxygene is “better than Objective-C” thanks to features like automatic boxing of integers, floats and strings, and generic arrays. There is more about the language here. Perhaps more important, if you know Pascal or Delphi it will look more familiar. You also get the ability to share code between Windows, Android, Mac and iOS, though this will be the non-visual code. Developers can also work mainly in Visual Studio rather than in Xcode.

The disadvantage is that you need two machines, or a VM running Windows on a Mac, and a remote connection to a Mac in order to debug.

I plan to try out Oxygene for Cocoa soon and of course will report on the experience.

Miguel de Icaza: don’t blame Google for Microsoft’s contempt for developers

Xamarin’s Miguel de Icaza (founder of the Mono project) has complained on Twitter about Microsoft’s Windows Division’s “contempt for developers” when it created the Windows Runtime and a “4th incompatible Xaml stack”, in a conversation prompted by the company’s spat with Google over the YouTube app for Windows Phone. Google wants this removed because it does not show YouTube ads, to which Microsoft counters that the API for showing these ads is not available.

image 

I am more interested in his general reflections on the wisdom (or lack of it) shown by Microsoft in creating a new platform for touch-friendly apps in Windows 8, that lacks compatibility with previous Windows frameworks. “No developer wants to build apps twice for Windows: one for desktop, one for winstore” he also remarked.

The four XAML stacks are Windows Presentation Foundation, Silverlight (for which de Icaza created a version for Linux called Moonlight), Windows Phone (which runs a slightly different version of Silverlight), and now the Windows Runtime.

Could Microsoft have done this differently, without compromising the goal of creating a new tablet personality for Windows rather than continue with doomed attempts to make the desktop touch-friendly?

The obvious answer is that it could have used more of Silverlight, which had already been adapted to a touch environment for Windows Phone. On the other hand, the Windows division was keen to support native code and HTML/JavaScript as equally capable options for Windows Runtime development. In practice, I have heard developers remark that HTML/JavaScript is better than C#/XAML for the new platform.

It is worth noting that the Windows Runtime stack is by no means entirely incompatible with what has gone before. It still uses the Windows API, although parts are not available for security reasons, and for non-visual code much of the .NET Framework works as before.

RAD Studio XE4 with Delphi for iOS is here. Who will use it?

Embarcadero has released RAD Studio XE4, its suite of development tools for Window, Web and for the first time, Apple iOS. iOS support first appeared in an earlier release, but in preview, and the current effort works using a new LLVM-based ARM compiler so is somewhat unlike the preview. Individual products such as Delphi XE4 are also available separately.

Looking at what’s new in Delphi and C++ Builder in XE4 it is apparent that iOS support is by far the main change since RAD Studio XE3, though there are two other significant changes:

  • Prism, a version of RemObjects Oxygene that compiles a Delphi-like language to .NET (and soon other targets) has been removed. Oxygene lives on at RemObjects.
  • FireDAC, a data access engine acquired from DA-SOFT, is now part of RAD Studio.

I ran up the new RAD Studio on a Parallels VM on a Mac, a VM on a Mac being the best way to try cross-platform development for OS X and iOS. The new IDE immediately presents you with instructions on setting up for iOS development (though I am not a fan of videos, preferring clear text instructions) but I no problems configuring the Mac agent (called PAServer) which makes this work. Start a new mobile app and you can pick a starter template or begin with a blank canvas.

image

I picked the Tabbed Application and was soon trying out my new app on the iOS simulator

image

So far so good, though the ability to run up a quick app is no proof of the quality of the development tool. Still, a few reflections.

As I noted earlier, it seems to me that Delphi developers are either Windows developers using the tried and trusted VCL (in which case there is very little for them in XE4), or developers who are targeting mobile platforms and using the cross-platform FireMonkey framework in order to share code between Windows, Mac and mobile. I guess it is also possible that developers targeting iOS alone will be so taken with Delphi or C++ Builder that they will come in as new users.

VCL developers now have 64-bit compilation and a mature framework, and given that the efforts of Embarcadero are now focused elsewhere, and that even Microsoft is going slow on new features for what it now calls “desktop Windows”, there is little reason for such developers to upgrade.

The key questions then are about the quality of the FireMonkey framework and the iOS support. It is hard for me to be objective, since I know Delphi from of old and it is a familiar environment. Delphi or C++ Builder for iOS has obvious attractions for such developers. I would be intrigued though to know what an Objective C or even a JavaScript developer would make of Delphi, coming to it fresh. I am sceptical whether an Xcode developer would find enough productivity benefit in Delphi and FireMonkey to want to move over, and suspect also that many would not be impressed by the FireMonkey approach to iOS controls, which are generally custom drawn rather than true native, or faked completely like the Segmented Control which you are meant to put together from SpeedButtons with segmented styling, as explained in the Delphi iOS tutorial:

image

Embarcadero is making a big play of being “true native” but native is not just about the executable code (I have written more about this elsewhere) and cross-platform always involves compromise.

There is also some disquiet in the developer community about the cost of keeping up to date with RAD Studio. The full RAD Studio XE4 Architect edition currently costs £2,892.60 ex VAT for a new user, or £1,927.80 to upgrade. If you just want basic Delphi, Delphi XE4 Pro is a more reasonable £642.60 for a new user, or £352.80 to upgrade – but you do not get iOS support for that, that is another £320.40 for the Mobile Add-on, and FireDAC if you need it a further £285.00. When XE3 came out, Embarcadero promised that iOS and Android support would be available later at a “low cost”; of course that is a relative and subjective term, but I can understand if some feel that the price is on the high side. Or you can buy software assurance and get upgrades free; I don’t have prices for that but the cost is significant.

It is unfortunate for Embarcadero that there is intense competition in the iOS tools space, not only from Apple’s excellent and free tools, but also from the likes of Xamarin and Titanium.

None of the above is intended to detract from the achievement of bringing Delphi to iOS, with Android promised, which is considerable.

Changes in the Delphi language for ARM and mobile support

Delphi developers should note changes in the Delphi language coming as a result of the move towards the LLVM compiler for mobile support. Embarcadero has released a paper describing these in detail. The just-released RAD Studio XE4 includes the ARM compiler for iOS, with an Android compiler to follow later this year.

It seems to me that Delphi developers will now fall into two broad camps:

1. Windows VCL developers for whom the new FireMonkey cross-platform framework is of little interest, either because they are not developing for Mac or mobile, or because they prefer other tools for those platforms.

2. Developers who are embracing the new platform targets, migrating code to FireMonkey or starting new projects there, and planning to share code across all platforms as far as possible.

If you are in the first camp, you need not worry too much about language changes yet. I believe it is Embarcadero’s long-term intention to unify Delphi’s compilers around LLVM on all platforms, but when or whether this will happen for Win32 and Win64 is moot; my guess is that what the company now calls the “classic compiler” will be around for a long time yet. However the Mac compiler may migrate to LLVM sooner. (I am speculating).

Currently, RAD Studio XE4 includes five compilers:

  • The Win32 compiler (DCC32)
  • The Win64 compiler (DCC64)
  • The Mac compiler (DCCOSX)
  • The iOS Simulator compiler (DCCIOS32)
  • The iOS ARM compiler (DCCIOSARM)

Of these, only the last one currently uses LLVM, though the iOS Simulator compiler behaves as closely as possible like its ARM cousin. In general the language changes are currently only applicable by default for the LLVM and Simulator compilers as far as I can tell.

What are the language changes? My quick summary of the biggest changes is as follows:

  • One string type only: UTF16, reference counted, immutable (though this is a point of confusion; reading the paper it seems it is not yet immutable as it describes modifying in place, but may become so).
  • 0-based strings. There is a compiler directive $ZEROBASEDSTRINGS, which is off for Delphi XE3 and Delphi XE4, but on for the mobile compiler in XE4.
  • Automatic reference counting. Objects are destroyed automatically when the reference count hits zero. MyObj.Free; does not destroy the object, only reduces the reference count (and destroys it if zero). You can create weak references (which do not increment the count) by using the [Weak] attribute. If you really want to destroy the object, use MyObj.DisposeOf;.

In addition, the With statement is now deprecated.

The language changes are described in detail in the paper The Delphi Language for Mobile Development, which you can find here.

No more Delphi for .NET: Prism removed from RAD Studio XE4

Embarcadero is removing Prism from the next version of RAD Studio, XE4, expected later this month.

Prism is actually a third-party product, based on RemObjects Oxygene. Prism and Oxygene let you code in Delphi and compile to .NET or Mono.

Marc Hoffman from RemObjects explains the change here:

Starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4″ branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

The disappearance of Prism is the final chapter in the story of Delphi for .NET. Borland’s Delphi was first released in 1995, and combined a visual interface builder superficially similar to Visual Basic with a native code compiler, enabling full access to the Windows API  as well as better performance than Microsoft’s VB.

Delphi built up a strong following, but in 2002 when Microsoft brought out the .NET Framework Borland worried that Delphi would be left behind. In 2002 it brought out CSharpBuilder, an IDE for C# targeting the .NET Framework, and in 2003 Delphi 8 which also targeted .NET.

Other .NET versions followed, but whereas native code Delphi was a compelling alternative to runtime-based platforms like VB and .NET, the .NET versions of Delphi were less distinctive. Developers coding for .NET preferred Microsoft’s Visual Studio, while Delphi developers preferred to stick with native code.

When Embarcadero acquired the Delphi tools from Borland in 2008, it dropped .NET support from Delphi itself and replaced it with Prism.

I doubt that the disappearance of Prism will cause much consternation. Prism developers will simply switch to Oxygene instead.

Xamarin acquires LessPainful, announces Test Cloud for mobile apps

Xamarin, a company which provides tools for cross-platform development in C#, has announced its acquisition of LessPainful and the creation of cloud-based testing for mobile apps based on LessPainful’s technology and the Calabash scripting language it created.

The Test Cloud will perform automated user-interface tests on real devices, hosted by Xamarin, will provide detailed reports in the event of test failures, and will support Continuous Integration so that bugs are caught as early as possible.

image

“After you’ve conquered the cross-platform mobile development problem, testing is the next large pain point” says Xamarin CEO Nat Friedman. “You can’t just get by with manual testing. There’s a need for the same level of tools and processes in mobile testing that you have in desktop and web testing.”

“Quality is actually more important on mobile than in other places. Mobile sessions are very short. People are really intolerant of low quality on mobile. The release cycles are shorter too. People are revving more frequently, and testing is a bigger challenge.”

Another issue with mobile testing is the number of devices out there, especially if you throw cross-platform into the mix. “You have on Android all these manufacturers who customise the OS in different ways, you have multiple different versions that are in use, and you have multiple different form factors and device capabilities. The testing permutation matrix is huge.”

“Automated UI testing is the only kind of testing that can ensure that the app does what it is supposed to do.”

Friedman says that the Xamarin UI tests are more robust than competing UI test frameworks because they do not depend on UI image recognition. “The right answer is object-based, you identify user interface elements on the screen by object IDs”.”

How does testing on real devices work? If you have 50 developers testing on 27 devices in Xamarin’s cloud, will there be racks and racks of devices to support them?  “That’s what it looks like at our end, racks and racks of devices,” confirmed Friedman. “The service is going to be built based on device/hour usage. We’ll be able to scale up to match what people need.

“We talk to developers who spend $8,000 a month just to get new devices. That’s not counting the labour and everything else they need to do, to set up their own testing infrastructure. It’s a giant pain point.”

Xamarin’s Test Cloud will offer plug-ins for Jenkins, TeamCity, and Microsoft’s Team Foundation Server, to support Continuous Integration.

The scripting language for the Test Cloud is either Calabash , or C# scripting which is under development by Xamarin.

The Test Cloud is not just for applications developed using Xamarin’s C# framework, but also supports other frameworks including those written in native iOS Objective C. However, only iOS and Android are supported.

Availability is set for the third quarter of 2013.

Xamarin’s Evolve conference is currently under way in Austin, Texas, with around 600 developers in attendance. Friedman says the company is growing fast. 1000 developers a day download the tools, there are over 15,000 paid developers, and the company now has 65 employees.

More information on the Xamarin Test Cloud is here.

Intel fights back against iOS with free tools for HTML5 cross-platform mobile development

Today at its Software Conference in Paris Intel presented its HTML5 development tools.

image

There are several components, starting with the XDK, a cross-platform development kit based on HTML5, CSS and JavaScript designed to be packaged as mobile apps using Cordova, the open source variant of PhoneGap.

There is an intriguing comment here:

The XDK is fully compatible with the PhoneGap HTML5 cross platform development project, providing many features that are missing from the open source project.

PhoneGap is Adobe’s commercial variant of Cordova. It looks as if Intel is doing its own implementation of features which are in PhoneGap but not Cordova, which might not please Adobe. Apparently code that Intel adds will be fed back into Cordova in due course.

Intel has its own JavaScript app framework, formerly called jqMobi and now called Intel’s App Framework. This is an open source framework hosted on Github.

There are also developer tools which run as an extension to Google Chrome, and a cloud-based build service which targets the following platforms:

  • Apple App Store
  • Google Play
  • Nook Store
  • Amazon Appstore for Android
  • Windows 8 Store
  • Windows Phone 8

And web applications:

  • Facebook
  • Intel AppUp
  • Chrome Store
  • Self-hosted

The build service lets you compile and deploy for these platforms without requiring a local install of the various mobile SDKs. It is free and according to Intel’s Thomas Zipplies there are no plans to charge in future. The build service is Intel’s own, and not related to Adobe’s PhoneGap Build, other than the fact that both share common source in Cordova. This also is unlikely to please Adobe.

You can start a new app in the browser, using a wizard.

image

Intel also has an iOS to HTML5 porting tool in beta, called the App Porter Tool. The aim is to convert Objective C to JavaScript automatically, and while the tool will not convert all the code successfully it should be able to port most of it, reducing the overall porting effort.

Given that the XDK supports Windows 8 modern apps and Windows Phone 8, this is also a route to porting from iOS to those platforms.

Why is Intel doing this, especially on a non-commercial basis? According to Zipplies, it is a reaction to “walled garden” development platforms, which while not specified must include Apple iOS and to some extent Google Android.

Note that both iOS and almost all Android devices run on ARM, so another way of looking at this is that Intel would rather have developers work on cross-platform apps than have them develop exclusively for ARM devices.

Zipplies also says that Intel can optimise the libraries in the XDK to improve performance on its processors.

You can access the HTML5 development tools here.