Tag Archives: windows

cloud computing, microsoft, professional, windows, windows 7

Why there are no tablets running Windows Phone 7

Once again people are asking why Microsoft has not allowed OEMs to build tablets running Windows Phone 7. Matthew Baxter-Reynolds says it is to do with income from OEM licenses:

Now, Microsoft charges OEMs far less for Windows Phone licenses (about $15 per unit) than for full-on Windows licenses (on average, working out to about $56 per unit) …  But for Ballmer and the team, this is the bad news scenario. Only $15 per licence? And even less in profit? Compared to $37 in profit? It’s a money-loser, people.

While I agree that Microsoft has a problem with its business model in the new world of mobile devices, I do not follow this reasoning. There is nothing to stop Microsoft charging more for Windows Phone OS on tablets than on phones if it could get away with it. Nor is it necessarily true that Microsoft will succeed in charging as much for Windows 8 on tablets as it does for Windows 8 on PCs. In fact, that is unlikely to be be true; they will be cheaper, especially on ARM.

If it is not this then, that still leaves the question of why Microsoft has not licensed the Windows Phone 7 OS for tablets.

Microsoft has undoubtedly fumbled tablet computing and this was a costly mistake. Nevertheless, it is a company capable of strategic thinking. I think it goes something like this, in no particular order.

First, I reckon Microsoft is thinking beyond the initial OEM license income for its profits from Windows 8 tablets. It is all about the apps – 30% of the income from every app sold on the locked-down ARM edition of Windows 8. Apps tend to be cheap, and there is cost in running the store, but there is potential for ongoing income that will exceed the initial license sale. Especially if, like Apple, Microsoft insists on a cut of subscription income, in-app advertising income, and so on.

Second, Microsoft is also betting on cloud computing. Windows Phone 7 is marketed mainly as a consumer device, but Microsoft is going to play the “this is the device for professionals” card at some point. You can bet that Windows 8 tablets, and their successors, will be promoted as the ideal client for Office 365, as well as for on-premise Exchange, SharePoint and Lync. Sell a tablet, buy a customer for Office 365. Lock customers into Office 365, and sell them other cloud applications and services. Plenty of opportunity for profit.

Third, my guess is that the Windows team at Microsoft does not consider the Windows Phone 7 OS good enough to be the foundation of its future mobile platform. They respect it enough to borrow its Metro design language, along with many aspects of the development model, but in the end Sinofsky and his team were not willing to hand over the future of Windows on devices to Windows CE and Silverlight.

What we are getting with the forthcoming Windows Runtime is a more deeply thought-through new platform in which .NET, native C++ code, and HTML 5 are equally well supported, and in which developers are forced to use asynchronous APIs that keep the user interface responsive. It will be a better app platform than the current Windows Phone OS; in fact, I fully expect Windows Runtime to migrate to the phone in some future version.

If Microsoft had allowed Windows Phone 7 onto tablets, it would have the difficult task of explaining to its customers how Windows 8 tablets differ from Windows Phone OS tablets as well as from those old Windows tablets from Bill Gates days.

Therefore Microsoft took the decision to wait until Windows 8 was ready. That was a bold decision, and it may be too late, but the reasoning is plausible.

image

microsoft

Thoughts on the future of the Win32 platform

8 Comments

Overheard last week at a non-techy social event: “I have just got an iPad. It is gorgeous. It is amazing how much it can do” … conversation continues … “Trevor is always swearing at his computer. He always blames Microsoft. It doesn’t matter what the problem is, he blames Microsoft.”

This is the kind of conversation which is annoying to hear if you are remotely technical. I have and enjoy using an iPad, but it has many limitations and its own share of annoyances. Recently the iOS WordPress app crashed whenever I tried to moderate comments on this blog. On Windows I could have done some troubleshooting, but on the iPad there was little to do other than blindly try removal and reinstall, or wait for a fix. As for Windows, I find it generally reliable and the majority of issues I have with it are not the direct fault of Microsoft.

In other words, reality is not so clear cut; but there is a powerful myth out there that goes along the lines of the conversation I overheard; and it is a myth that is not entirely unfounded given the quality of Apple’s design work and the problems that surround what we might call the Windows ecosystem: foistware, hardware built down to a price, the peculiarities of Outlook, and so on.

I do not think conversations like that quoted above are exceptional and it illustrates the pressure Microsoft is under. For years Windows has been in an almost unassailable position because the alternatives were insufficiently compelling to most people: Linux too awkward and fractured, Mac/OSX too expensive. Now change has come about because of the rise of new kinds of devices, smartphones and tablets, for which Windows was unsuitable. The result is that Apple iOS and Google Android are widely used and growing fast.

That said, we still need PCs, and although the Mac is gaining ground the large majority of these still run Windows. The smartphone or tablet model does not fit all kinds of computing. In fact, if we are thinking of the iPad in particular, it is only a good fit for a minority of uses. I am not thinking of what you just about do with an iPad if you have to, I am thinking of the scenarios where it is your tool of choice. Take word processing for example: the iPad has a version of Pages and you can get an external keyboard but even so I would rather type on a PC or a Mac, or even a netbook, and will get my work done quicker that way.

image

Leaving aside the software that is available, a full PC or Mac gives you keyboard, mouse, and easily supports one or more large high-resolution screens. Whether it is Microsoft Excel, Adobe Photoshop, the latest graphics-intensive game like Bethseda’s Skyrim, CAD software, or development tools like Visual Studio or Eclipse, there are many activities for which a tablet is a poor PC substitute.

Even for things for which a tablet is generally considered good, such as web browsing, a full PC or notebook is better. When browsing the web on an iPad there are little annoyances like slower typing of search queries (and the often daft auto-correct in iOS), awkwardness of looking up a password for a login and pasting it into the browser, small screen size making you scroll around, difficulty of hitting small hyperlinks on sites like discussion forums, and so on.

All of this means that the traditional PC, Mac or notebook seems still to have a strong future, which seems further to imply that Windows also is secure.

I would argue though that this is a rose-tinted view of the future of the Win32/Win64 platform – by which I mean full desktop Windows rather than the “Metro” tablet platform which Microsoft has previewed for the dual-personality Windows 8. Here are three reasons why it is under threat:

1. Tablets will get better and will gradually encroach on the PC market as they become more capable. This process will be complemented by web sites adapting to work better for the growing number of tablet users.

2. Hybrid devices like the Asus Eee Pad Transformer, which runs Android but also docks into a laptop-like keyboard and clamshell case, will cause users to question whether they really need to replace their Windows laptop when it wears out.

3. The drive towards cloud computing will reduce our dependence on desktop applications. Although Google’s Chromebook has not yet caught on, the fact that it exists shows the progress cloud computing is making: a notebook that only has a web browser is a viable proposition.

My assumption is that many of us would like to use tablets for a greater proportion of our computing activities if we could easily do so, because we like their mobility, convenience, low power demands, and relatively low cost. This is especially true for consumers, and less applicable to more regimented offices where there is a computer on every desk.

Another factor for Win32 is that Microsoft itself will slow down its future development, concentrating instead on Metro and its Windows Runtime, as well as cloud services. There are good business reasons for this. Microsoft is not under pressure to improve Win32; users would like it to run faster and with greater reliability, but their main demand is that it continues to run their critical applications successfully.

The conclusion: although Win32 will remain an important and stable platform for many years to come, it is now in slow decline. This will be the case whether or not Microsoft manages to bring Windows itself back on track with a success for Windows 8 on tablets, and overturns the assumption reflected in my initial quote: that an Apple iPad is delightful and Windows nothing but problems.

.net, apple, mobile

Why developers need a Mac

18 Comments

I am by no means an Apple fan. For one thing, I find Windows (and Linux) stable and fast, so you are not going to hear me argue that my computing life was transformed once I made that Switch (with a capital letter). Admittedly that is partly because I am familiar with how to fix and tune Windows and remove foistware, but it is not that hard. For another, I am not an admirer of Apple’s secretive approach, or the fact that most requests for comment from journalists are responded to with silence. For a third, I dislike the notion that all apps for its popular mobile platform must be distributed through the Apple store and subject to a fee, now extended to in-app upgrades and subscriptions as well as initial sales. There is also much that I admire about Apple’s platform, but I hope I have convinced you that I am not so bedazzled by the company that I am unable to think coherently about its products.

Nevertheless, I have run a Mac alongside Windows for years now, and I find myself needing it increasingly. Here are four reasons.

The first is that sooner or later you will need to build or test an app for the Mac or, more likely, for iOS. You can only do so using a Mac (leaving aside the exciting world of the hackintosh). This is because Apple only provides the iOS SDK and simulators for its own operating system.

As an aside, I recently spoke to Keith Varty who is evangelising Windows Phone development at Nokia. I asked about the issue of Visual Studio only running on Windows, was that an obstacle for developers using a Mac? He pointed out that it is the same in reverse with Apple, you need a Mac to develop for the iPhone. In fact, it is easier to develop for Windows using a Mac, thanks to the existence of excellent PC emulators, than it is to develop for a Mac using Windows. In any case, special rules apply for Apple.

Second, other than in the most closed internal environments, some of your users will have a Mac or at least an iPad or iPhone. A few years back both developers and system administrators could get away with a deliberate ignorance of Apple computers, saying they are “not supported” or “untested” or just “I have no idea.” That is no longer acceptable (if it ever was) and it is important to test apps on a Mac where that is appropriate, as with web or cross-platform Java or Adobe AIR applications, and more generally to get a feel for how things work on a Mac so that you can respond intelligently to users.

Third, in many areas of development Macs are now dominant. This means that Windows-only developers may be disadvantaged. Today, for example, I was researching Sencha products and came across this:

image

Yes, to get the preview developer tools for Sencha Touch 2, you need a Mac. No doubt Windows versions will follow, but there are times when you need a Mac just to keep up with the latest technology.

Fourth, and this is the most difficult point to make, it is valuable to spend some time on a Mac to avoid bad assumptions about usability. One example that comes to mind is version control. On Windows there is no problem using Git, or Subversion, or any number of systems including Microsoft’s Team Foundation Server installed either locally or on its own server. There is some setup involved though. On a Mac with the latest Xcode, you will find a checkbox in the new project wizard:

image

It is built-in. There is nothing more to do other than check this box. And yes, I know it is pretty easy to use Subversion or Git on Windows – though I would never describe a Team Foundation setup as trivial – but I am talking about the usability of a single checkbox. If you are thinking about the design of your own UI then spending some time on a Mac is though-provoking and likely to be beneficial.

By the way, some other parts of Xcode are less usable than Visual Studio so do not read too much into this example!

Another example which comes to mind is installing a web server. Windows has IIS, which is a good web server, and you can enable it on Windows 7 by going to Control Panel, Programs, Turn Windows Features on and off, and then waiting while the dialog populates, and then checking which bits of IIS you want to install:

image

Not difficult, though the intricacies of which Application Development Features you need may require some research. But here is how you set up Apache on a Mac. Go to System Preferences, and check Web Sharing. Apache is now up and running, and on my Mac Mini it started instantly:

image

I am sure there are many more examples, and even examples where Windows has better usability than then Mac (I miss the thumbnail previews in the task bar) but my point is this: it pays to have experience beyond Windows from which to evolve your own user interface ideas.

Post sponsored by Monster for the best in IT Jobs.

tips

Fixing a Windows 7 blue screen with Driver Verifier

A recent annoyance was a blue screen when I was in the middle of typing a Word document. “Memory management” it said.

You might think faulty RAM, but I did not think so as I had tested it extensively with the excellent Memtest86. So what was causing it? And no, I do not regard Windows as an unstable operating system, not any more (not really since Windows 98 days).

I started troubleshooting. The first step is to install the Debugging Tools for Windows, if you have not already, run Windbg, and load the minidump which Windows usually creates when it crashes. Minidumps are saved in the /Windows/Minidump folder.

image

It said VISTA_DRIVER_FAULT and identified the SearchProtocol process, but I was not convinced that this process was really to blame. My reasoning is that it is a Microsoft process that is running on most Windows boxes so unlikely to be badly broken.

I decided to look for a faulty driver. You can do this by running the Driver Verifier Manager, summoned by running verifier.exe (this lives in /Windows/System32 but you can start it from anywhere).

image

This application enables a debugging mode in Windows that will scrutinise the drivers you specify for errors. This slows down Windows so it is not something you want to leave enabled, but it is great for finding problems.

I elected to check all drivers and continued. Reboot, and as expected, an immediate blue screen.

While Driver Verifier is enabled and causing a crash you can only boot into safe mode. However Windbg works OK in safe mode. I took a look at the new minidump. The process name this time was services.exe. That means any of the services could be at fault, so not all that illuminating.

I ran msconfig and disabled all non-Microsoft services. Restarted and verifier was happy. Now it was a matter of “hunt the service”.

Eventually I discovered through trial and error and hunch (it had to be a service which I had recently installed or updated) which service failed to verify. The guilty party: Intel Desktop Utilities. This application monitors sensors on an Intel motherboard for temperature and fan speed, and fires alerts if the readings go outside safe limits.

I uninstalled the desktop utilities. No more blue screens since.

I find it hard to believe that an Intel utility distributed with all its motherboards is causing Windows blue screens; on the other hand in my case it seems clear cut. And yes, I did have the latest version 3.2.0.038b “for Intel Desktop Boards with 5 or 6 Series chipsets.” My board is the DH67CL. I would be interested to know if others with same version can successfully boot with Driver Verifier enabled.

.net, apple, development, microsoft, mobile, professional, software development, visual studio, windows

Quick thoughts on Xcode and Objective C versus Microsoft’s tools

2 Comments

I have been trying out JetBrains’ AppCode which meant working in an Apple development environment for a time. I took the opportunity to implement my simple calculator app in iOS native code.

image

Objective C is a distinctive language with a mixed reputation, but I enjoy coding with it. I used Automatic Reference Counting (ARC), a feature introduced in Xcode 4.2 and OSX 10.7, iOS 5; ARC now also works with 10.6 and iOS 4. This means objects are automatically disposed, and I did not have to worry about memory management at all in my simple app. This is not a complete memory management solution (if there is such a thing) – if you use malloc you must use free – but it meant that the code in my app is not particularly verbose or complex compared to other languages. Apple’s libraries seem to favour plain English method names like StringByAppendingString which makes for readable code.

I was impressed by how easy it is to make an app that looks good, because the controls are beautifully designed. I understand the attraction of developing solely for Apple’s platform.

I also love the integrated source control in Xcode. You find yourself using a local Git repository almost without thinking about it. Microsoft could learn from that; no need for Team Foundation Server for a solo developer.

I did miss namespaces. In Objective C, if you want to remove the risk of name collision with a library, you have to use your own class prefix (and hope that nobody else picked the same one).

image

Interface Builder, the visual UI designer, is great but many developers do not use it, because coding the UI without it is more flexible. It is a shame that you have to make this choice, unlike IDE’s with “two way tools” that let you edit in code or visually and seamlessly keep the two in synch. I found myself constantly having to re-display windows like the Attributes Inspector though it is not too bad once you learn the keyboard shortcuts. The latest Interface Builder has a storyboard feature which lets you define several screens and link them. It looks useful, though when I played with this I found it difficult to follow all the linking lines the designer drew for me.

It is interesting to compare the Mac and iOS development platform with that for Windows. Microsoft promotes the idea of language choice, though most professional development is either C# or C++, whereas on Apple’s platform it is Objective C and Cocoa or you are on your own. Although Mac and Windows are of a similar age, Microsoft’s platform gives a GUI developer more choices: Win32, MFC, WTL, Windows Forms, Windows Presentation Foundation and Silverlight, and in Windows 8 the new WinRT.

I get the impression that Microsoft is envious of this single-minded approach and trying to bring it to Metro-style Windows 8, where you still have a choice of languages but really only one GUI framework.

That said, Visual Studio is an impressive tool and both C# and C++ have important features which are lacking in Objective C. I would judge that Visual Studio is the more productive tool overall, but Apple’s developer platform has its own attractions.

microsoft, windows

Moving Windows with its applications: too difficult

5 Comments

I have just replaced my PC – well, if you count new motherboard, new CPU, new hard drive, new RAM as replacement, though it sits in the same case – and faced again the question of what to do with my Windows setup, complete with hundreds of applications.

A few years back, there was no question. You took every opportunity to do a clean install, because without it Windows gradually became unusable, as gloriously recounted by Verity Stob.

Stob’s analysis is not completely wrong today, but the matter has greatly improved. The Windows 7 64-bit installation that I use today was installed in August 2009 (run systeminfo if you want to check yours), and that was an in-place upgrade from Windows Vista 64-bit, as recorded here. That Vista install was done in January 2008, so I have preserved applications and settings for coming up to four years and two motherboard changes.

The trade-off is that in return for putting up with some cruft you get a big win in convenience. There is no need to dig out install media, downloads and licence codes, and migration to a new system is quicker.

So why complain? Well, although it can usually be done, moving Windows from one machine to another is not supported by Microsoft, unless the hardware is identical:

Microsoft does not support restoring a system state backup from one computer to a second computer of a different make, model, or hardware configuration. Microsoft will only provide commercially reasonable efforts to support this process. Even if the source and destination computers seem to be identical makes and models, there may be driver, hardware, or firmware differences between the source and destination computers.

What this means is that users who get a new computer are directed instead towards the Windows Easy Transfer application:

image

This is a handy tool, but it does not transfer applications. This last point can be particularly tiresome if you use software that requires activation on each machine on which it is installed, not least Microsoft’s own Windows and Office. Adobe’s Creative Suite, for example, allows installation on up to two machines, after which it will no longer install unless you specifically deactivate it:

image

If you trash your old PC, or it breaks, without deactivating first, then you have to call support and plead your case.

Apple’s Migration Assistant, by contrast, does move applications, making a better user experience.

If you can easily move applications, settings and data, of course, there is no need to move the entire operating system, since you have all that matters.

Why does Microsoft make this so hard? Two reasons I can think of.

One is that there are technical challenges in moving Windows to new hardware; though having said that, I suspect that Microsoft could easily have created a migration wizard that includes applications if it wished to do so.

The second, and more important, is licencing. Most consumer versions of Windows (and Office too) are OEM licences, which are not allowed to be transferred from the machine with which they are supplied. If Microsoft made it easier to move Windows or to migrate applications, less new software would be sold. Enterprises are expected to handle this in a different way, with centralised application management tools.

Virtualisation changes the game of course. The point of virtualisation is that you run the operating system on abstracted hardware that can easily be replicated on another machine. I really would like to run a virtual desktop, but I do not have a suitably high-powered server and there are niggles over fast graphics, USB devices, studio quality audio and so on. I expect all these to be solved and that a virtual desktop is in my future.

In the meantime, I have personally lost patience with the idea of reinstalling everything, and fortunately I do not use OEM Windows licences.

The wider question is interesting though. Although the desire of Microsoft and its partners to protect licence income is understandable, there are new models of application licencing that work better for users. In Google’s world you just sign on in your browser, and all your stuff is there. In Apple’s world, your iOS apps are licenced to you, not your device, and when you get a new device they all reappear. Even Microsoft’s Xbox works like this too, though that was not always the case.

This competition, in combination with virtualisation, means that Microsoft’s approach with Windows looks out of date as well as being unpleasant for users.

Windows 8 is on the horizon, and I would guess that the forthcoming Windows Store will be better in this respect, though note that at its Build conference in September Microsoft did not discuss the business aspects of the Store.

.net, microsoft, professional, silverlight, software development

Windows Runtime must come to Windows Phone

1 Comment

I’ve been trying Windows Phone 7 in its latest “Mango” version over the last couple of days and mostly enjoying it. One thing I am not impressed by though is the range of apps available. Have a look at the Marketplace – Microsoft may claim 30,000 apps, but given how unexciting even the “top” selections are, you can imagine how bad the bottom ones must be. Microsoft I guess has been guilty of accepting almost anything to puff up the numbers.

What would fix this? Sell more phones, of course; but also improve the platform for developers. Windows Phone 7.x is not a bad platform: you get Silverlight, XNA, C# and Visual Studio.

By contrast though, the Windows Runtime (WinRT) shown at the BUILD conference earlier this month is a platform mobile developers can love. Here are what seem to me three great features:

  • Three first-class languages and programming platforms – C#/.NET, JavaScript and HTML 5, C++ and native code. All three are strategic platforms. I particularly like the native code option, as many mobile developers like native code and it is a weakness of Windows Phone 7.
  • Asynchrony built into the platform. This is a smart move: make every API call that might cause a delay an async-only call. On top of that, build easy async programming into the languages. The result should give apps a responsive user interface almost by default; developers will need to make an effort to freeze the UI.
  • Contracts which integrate apps with the operating system and with one another. There are five contracts: search, share, play to, settings, and app to app picking (for example, file selection).

Microsoft’s Windows chief Steven Sinofsky says Windows 8 is for tablets but not for phones. But he has to say that, because if Microsoft announced that the current Windows Phone 7.5 is a platform without a future, it would further dampen enthusiasm for the product.

Is there any reason why WinRT should not come to Windows Phone? A few:

  • Windows Phone is currently built on Windows CE, a cut-down version of Windows, whereas WinRT runs on top of the full Windows API.
  • The Metro-style UI is designed for tablets rather than phones.
  • Finally, the existence of Desktop Windows is presumed in the current Windows 8 design. If Microsoft has not had time to work out a Metro-style UI for something, you simply use the Desktop version.

All of these are good reasons why the arrival of WinRT on the phone will be delayed, but none are insuperable. Long-term, I find it inconceivable that Microsoft will persevere with a different programming platform for the phone and for tablets.

What are the implications for Windows Phone developers today? Well, WinRT and Metro borrow from the phone OS, so the porting effort should not be too bad, except in the case of XNA, a .NET wrapper for DirectX which WinRT does not support.

Of course this post is entirely speculative, and I have no insight into Microsoft’s plans beyond what is publicly stated, so there might be other compatibility options when and if the time comes.

And it is time that is Microsoft’s biggest enemy. Fumbling tablet computing has been a costly mistake, and the big question is whether anyone will care how good some future Windows Phone will be, if the ecosystem which Nokia likes to talk about is firmly established as Android vs Apple.

.net, microsoft, professional, software development, visual studio, windows

A simple example of async and await in C# 5

10 Comments

I have been playing with the Visual Studio 11 developer preview and exploring its asynchronous features, specifically the async and await keywords which are new to C# 5.0. These features have actually been available as a CTP (Community Tech Preview) since October 2010, but I had not found time to try it.

I like to keep examples as simple as possible. I have a Windows Forms application which has a long-running task to perform, and I do not want to lock the UI while it runs. Here is my long-running function:

 private int slowFunc(int a,int b)       
 {          
 System.Threading.Thread.Sleep(10000); 
 return a + b;
 }

Yes, it takes 10 seconds! I am going to click a button on a form, call the function, and show the result on a label control.

Now, here is how I might try to achieve the goal of not locking the UI using Visual Studio 2010 and C# 4.0:

 private void button1_Click(object sender, EventArgs e)
 {            
 this.button1.Enabled = false; //prevent re-entry 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2));
 this.label1.Text = "Result: " + someTask.Result.ToString(); //oops, blocks calling thread 
 this.button1.Enabled = true;       
 }

Oops, this did not work at all! The reason is that although I have gone to the trouble of creating a Task in order to run the slow function on a background thread, my work is undone when I call the Result property of the Task object – since this blocks the thread until the Task completes.

Here is how you can fix it in Visual Studio 2010 – remember, there is an easier way in C# 5.0 coming up soon:

 private void button1_Click(object sender, EventArgs e)        
 {
 this.button1.Enabled = false;          
 var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); //get UI thread context 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); //create and start the Task 
 someTask.ContinueWith(x =>     
   {                                          
   this.label1.Text = "Result: " + someTask.Result.ToString();   
   this.button1.Enabled = true;   
   }, uiScheduler  
  );        
 }

This one works. I click the button and the UI does not lock up at all; I can minimize the form, move it around the screen, and so on.

However, I have had to do some extra work. The ContinueWith method tells the Task to run some other code after the background thread has completed. By default this code will not run on the UI thread, which means it will raise an exception when it updates the UI, but you can pass in a TaskScheduler object so that it continues on the UI thread.

Now here is a look at the same problem using C# 5.0. The slowFunc is the same, so I will not retype it. Here is the code for the button click:

 private async void button1_Click(object sender, EventArgs e)
 {
 this.button1.Enabled = false; 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); 
 await someTask;  
 this.label1.Text = "Result: " + someTask.Result.ToString(); 
 this.button1.Enabled = true;
 }

Less code, same result, which is usually a good thing.

What is going on here though? First, the async modifier is added to the click event handler. This does not mean that the method runs asynchronously. It means that it contains code that will run asynchronously using await. As Eric Lippert explains, it tells the compiler to rewrite the method for you.

Second, there is the await keyword. I cannot improve on Lippert’s explanation so here it is:

The “await” operator … does not mean “this method now blocks the current thread until the asynchronous operation returns”. That would be making the asynchronous operation back into a synchronous operation, which is precisely what we are attempting to avoid. Rather, it means the opposite of that; it means “if the task we are awaiting has not yet completed then sign up the rest of this method as the continuation of that task, and then return to your caller immediately; the task will invoke the continuation when it completes.”

If you refer back to the Visual Studio 2010 examples, you will see that the code is very close to my first, non-working example. In other words,using await makes the code work in the way that intuitively I hoped that it might, without specifically called the ContinueWith method and messing around with the thread context as in the second example.

This is still concurrent programming though. One thing that C# 5.0 cannot prevent is an impatient user clicking several times on the button when the result does not appear immediately, so in all the examples I have disabled the button while the background thread runs.

apple, delphi, professional, software development, windows

Delphi team focusing on FireMonkey, VCL winding down?

3 Comments

Julian Bucknall at componnent vendor DevExpress writes a thoughtful post arguing that Embarcadero will focus on Delphi’s new cross-platform FireMonkey framework in future, and that the VCL (Visual Component Library) which has been at the heart of Delphi since its first release will receive little future investment.

Bucknall notes that ex-Borland employee Danny Thorpe tweeted about 1/3 of the Delphi VCL and IDE team being laid off in Scotts Valley, USA; while Embarcadero’s Tony De La Lama blogs about new posts in Europe. FireMonkey was originally developed in Russia.

The VCL is a mature framework by any standards (Delphi was first released in 1995), and now that the 64-bit VCL has been released the most pressing demands of developers have been met.

Further, Microsoft itself is slowing development of the Win32 API on which VCL is based, in favour of the mobile and touch-friendly Metro user interface and the new Windows Runtime on which it is built. The VCL will never adapt to Metro, but FireMonkey might do so. The Windows Runtime has an API which is represented by metadata in same format used by .NET’s Ildasm. If Embarcadero can adapt Delphi to read this metadata so that you can easily call the API, then a Delphi for Metro seems plausible, but it would not use the VCL.

Delphi already works well for Windows applications, so from Embarcadero’s point of view, growth will come from cross-platform and mobile development using FireMonkey.

The main snag is that unlike the VCL, FireMonkey is far from mature, and developers are complaining about lack of documentation as well as limitations in the current implementation.

There is also a philosophical difference between VCL and FireMonkey. VCL is a “heavyweight” GUI framework in that it depends on native Windows controls, with the advantage that you get a truly native look and feel in your Delphi application. FireMonkey is a “lightweight” GUI framework which renders the UI entirely through custom drawing, which is great for cross-platform consistency, but poor if you want a native look and feel. Performance-wise, and despite the name, heavyweight frameworks often feel faster because native controls are optimised for the operating system.

The key question then: will FireMonkey be as good for cross-platform, as the VCL has been for Windows? Based on my first experiments I am not sure at the moment, though I expect it to improve. I would be interested in views from others who have worked with it.

microsoft, software, software development, windows, windows 7

Windows Live Messenger error message hell

Recently I tried to sign into Live Messenger on Windows 7, only to be informed of what appears to be a temporary interruption in service.

image

Show details, by the way, shows Error code: 80040154

I retried and got the same message, so I clicked the Get more information link, which took me here:

image

The help document says that the solution is to reinstall Windows Live Essentials. I confirmed this, not by reinstalling (yet), but by trying Live Messenger on another machine, where I could sign into the same account successfully.

A few observations about this:

  • The error message is incorrect, since the error is apparently on the client whereas the message states it is a temporary problem with the service.
  • Microsoft’s engineers know that the error message is incorrect, since the help document references both the message and the solution.
  • The error message has been incorrect for years, since it applies to both Windows Live Messenger 2009 and 2011.
  • The misleading error message is particularly annoying, since if the user wants to use Live Messenger urgently they may well wait as advised by the message, not realising that the problem can be fixed immediately.
  • The solution is a brute-force one that involves many other applications, including Live Mail and Live Writer (on which I am typing this post). Or is it enough just to reinstall Messenger? The message suggests not. However if you use Live Mail for all your email, you probably want to know whether the uninstall will delete all your email and contacts or not. The referenced article on uninstalling Live Essentials does not say.

How could Microsoft improve this? At risk of stating the obvious:

  • Give an accurate error message.
  • Give a solution which targets the exact problem rather than relying on an uninstall/reinstall procedure that changes many things that are working fine.
  • If this is impossible, at least advise the user in one place concerning their obvious questions, such as “what happens to my stuff”.

Update: I found the cause of this problem. A developer tool beta had overwritten my system path with its own, breaking this among other things. I do not blame any application for breaking in these circumstances. I fixed the Live Messenger problem by performing a Repair on Live Essentials – less risky than uninstall/reinstall, and in this case sufficient.

Another idea if you have this kind of problem is System Restore.

Nevertheless, the error message could do with some work!