Category Archives: software development

development, gaming, google, open source, professional, qt, software development

Google Native Client: browser apps unleashed, or misconceived and likely to fail?

6 Comments

Last week Google integrated Native Client into the beta of Chrome 14. Native client lets you compile C/C++ code to run in the browser. It depends on a new plug-in API called Pepper. These are open source projects sponsored by Google and implemented in the Chrome browser, and therefore also likely to turn up in Chrome OS which is an operating system in which all apps run in the browser.

Native Client is cool. For example, NaCLBox lets you run old DOS games in the browser by porting DOSBox to Native Client.

image

Another project is Qt for Google Native Client, a project currently in development. Qt is an excellent and popular GUI and application framework which would speed development of Native Client apps as well as enabling many existing applications to be ported.

It is also worth mentioning that Native Client provides another way to run .NET code in the browser, via Mono with NaCl support.

Why Native Client? Google’s vision, or at least the part of it that focuses on Chrome OS rather than Android, is that everything runs on the Internet and in the browser, making the local operating system unimportant and easily replaced. Native Client removes any performance compromises in managed languages such as JavaScript, ActionScript or Java, as well as easing migration for businesses with existing C/C++ code.

Writing native code for the browser is nothing new. Both Microsoft’s ActiveX and the NPAPI plug-in API used by non-Microsoft browsers let you extend the browser with native code. However Native Client is seamless for the user; you do not have to install any additional plug-in. The main limitation is that Native Client applets do not have access to the local operating system, for security reasons.

It is also worth noting that Native Client apps are not altogether cross-platform. They must be recompiled for different CPU instruction sets, with the current implementation supporting x86 and ARM though you have to compile two binaries. Google says it will support LLVM output to enable cross-platform binaries though this will impact performance.

But is Native Client secure? That is an open question. Google was aware of the security challenge from the beginning of the project. Unlike the plug-in mechanisms which rely mainly on trust in developer competence and signed code to verify the origin of the plug-in or ActiveX control, Native Client inspects the actual code for unsafe instructions before allowing it to run. There is also an “outer sandbox” which intercepts system calls.

However, adding any new way for code to run makes the browser less secure. Google ran a Native Client Security Contest to help identify vulnerabilities, and the contestants did not have any problem finding security flaws. Of course all of these discovered flaws will have been fixed, but there may be others and likely will be.

And is Native Client necessary? The latest JIT-compiled JavaScript engines are fast enough to enable most types of application to run at a satisfactory speed. This is not just about performance though; it is about reusing existing skills, libraries and applications. There is no doubt that Native Client is nice to have; whether its benefits outweigh the risks is harder to judge.

The last question, which may prove the most significant, is political. Google has forged ahead on its own with Native Client, saying as vendors always do that it hopes it will become a web standard. In the early days of the project, it looked like a Native Client plug-in might enable the feature in other browsers, but abandoning NPAPI for Pepper makes this difficult. Will other browser vendors support Native Client?

Here is a comment from Google’s Ian NI-Lewis that I find remarkable:

As you probably know, the rule in Web standards is "implementation wins." So we’re concentrating on getting a good quality implementation out the door. We’re doing that in Chrome. That doesn’t mean that NaCl is intended to be "Chrome only," just that we have to start somewhere.

So Native Client is non-standard, and therefore less interesting than HTML 5 until either Google has a Microsoft-Office-like de facto monopoly of web browsers, or it persuades Mozilla, Microsoft and Apple to support it.

That said, you can think of Chrome as an installable runtime in the same way as the Java Virtual Machine or Adobe Flash, just a potentially more intrusive one. Here is our app, you have to install the free Chrome browser to use it. If this happens to any great extent, I can foresee other browser makers hastening to support it.

.net, c++, intel, microsoft, open source, professional, software development

C++ 11 is approved by ISO: a big day for native code development

4 Comments

Herb Sutter reports that C++ 0x, which will be called C++ 11, has been unanimously approved by the ISO C++ committee. The “11” in the name refers to the year of approval, 2011. The current standard is C++ 98, though amended as C++ 03, so it has taken 8 or 13 years to update it depending on how you count it.

This means that compiler makers can get on with implementing the full C++ 11 standard. Most current compilers implement some of the features already. This Apache wiki shows the current status. A quick glance suggests that the open source GCC is ahead of the pack, followed by Intel C++ and then perhaps Microsoft Visual C++.

C++ 11 is pretty much compatible with C++ 03 so existing code should still work. However there are many new features, enough for Bjarne Stroustrup to say in his feature summary:

Surprisingly, C++0x feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever. If you timidly approach C++ as just a better C or as an object-oriented language, you are going to miss the point. The abstractions are simply more flexible and affordable than before. Rely on the old mantra: If you think of it as a separate idea or object, represent it directly in the program; model real-world objects, and abstractions directly in code. It’s easier now.

Concurrent programming is better supported in C++ 11, important for getting the best performance from modern hardware.

It is curious how the programming landscape has changed in recent year. A few years back, you might have foreseen a day when most programming would be .NET, Java or JavaScript: all varieties of managed code. While those languages do still dominate, native code has come more to the fore, thanks to factors like Apple’s focus on Objective C, and signs of internal conflict at Microsoft over the best language for coding Windows applications.

That said, C++ 11 remains a demanding language to learn and use. As Stroustrup notes, since C++ 11 is a superset of C++ 98 it is technically harder to learn all of it, though new libraries and abstractions should help beginners. The reasons for using or not using C++ are not going to change significantly with this new standard.

apple, development, open source, professional, software development

Building PasswordSafe for the Mac: Lion development hassles

10 Comments

I am doing some work on a Mac at the moment. On Windows I store passwords in PasswordSafe, an open source utility that works well, so I wondered if I could access my PasswordSafe database from the Mac.

image

I could have run the Windows version in Parallels, which I have just installed, but I figured a Mac version would be more convenient. I didn’t see a Mac build among the downloads, but PasswordSafe is cross-platform, so I downloaded the source to do a quick compile.

I was glad to find README.MAC.DEVELOPERS.txt in the PasswordSafe source and set to work. The first task is to download wxWidgets, a cross-platform GUI library, so I went off to download that. Ran the osx-build-wx script as instructed. Result: error message stating C compiler cannot create executables.

The problem seems to be that PasswordSafe expects GCC 4.0 but the latest Xcode installs GCC 4.2. The solution suggested here is to remove Xcode 4, install Xcode 3, and then reinstate Xcode 4. There are related issues concerning PPC fat binaries and older versions of the Mac SDK.

That solution seemed risky and ardous to me, and I remembered that I still had an old Mac Mini from which I was forced to upgrade in order to install Lion, the latest OS X. I hooked it up, removed Xcode 4, installed Xcode 3, and set to work again.

I get the impression not many people build PasswordSafe for the Mac. The first issue I discovered was that the steps in in the README.MAC.DEVELOPERS.txt don’t mention that after running osx-build-wx you also have to run make in order to build static libraries. That was easy though. The next thing is to load the supplied PasswordSafe project into Xcode and build.

I did that but got an error – the linker could not resolve SizeRestrictedPanel. The fix was to add SizeRestrictedPanel.cpp and SizeRestrictedPanel.h to the project. PasswordSafe then built and seems to work fine, on Lion as well as earlier versions of OS X, though there are a few cosmetic issues. You can see from the image that the caption for the New Database button is slightly awry.

If anyone wants my build, it is here. There is also a Java version, and some people have success with that on the Mac.

.net, apple, mobile, professional, software development

Mozilla to take on the cross-platform app challenge

2 Comments

Mozilla is facing an uncertain future. Its problem: basing a business (even a non-profit one) on being the alternative to Microsoft’s Internet Explorer is no longer sensible, given that Apple and Google are now doing this too, and even Microsoft is now investing in HTML 5. I discussed these issues in more detail here.

So what is Mozilla to do? Mozilla Chair Mitchell Baker has posted about a possible new approach, based on being the alternative to Apple for apps. She lists some of the problems with the current “app experience”. Apps are device-specific, require permission at many levels, and a few App Store owners (mainly Apple but also Google) control the business model and customer relationships.

Mozilla is proposing what I presume is a new app platform, which will be cross-platform and cross-device. Instead of discovering apps in a single app store, she envisages multiple providers and the ability to find apps in the same way we find web content.

In other words, if the old Mozilla was about freedom from Microsoft and allowing web technology to progress, the new Mozilla might be about freedom from Apple and allowing app technology to progress.

It is a bold vision and one that in principle would be welcome. That said, Mozilla cannot change the control Apple has over its platform, and its insistence that apps are installed only through its own App Store. Maybe she has in mind a cross-platform toolkit, or browser-based apps, or some combination.

Another snag is that whereas there was widespread dissatisfaction with Microsoft’s Internet Explorer back in 2004 when Firefox was launched, this is not the case with Apple and its app platform today. Apple’s App Store system undoubtedly has a dark side, but the user experience is good and developers are making money, some of them at least. Apple’s control over app installation and the constraints imposed on what apps can do are also good for security.

Nevertheless, having looked at a number of cross-platform mobile toolkits, from PhoneGap to Appcelerator Titanium to Adobe AIR, I can see both the significance of this kind of development and that there is plenty of scope for improvement.

microsoft, software development

Charlie Kindel leaving Microsoft

3 Comments

Charlie Kindel, Windows Phone 7 developer champion at Microsoft, is leaving to start a new company, though he is vague about exactly what it will be:

Charlie will be staying in the Seattle area building a new tech company. The new company will be in stealth mode initially but involves advertising, mobile, cloud computing, and youth athletics.

says the press release.

He goes back a long way at Microsoft, 21 years to be precise. Among the accomplishments he claims:

  • Built ActiveX and DCOM
  • Shipped Internet Explorer 3.0
  • Drove the development of the home networking features in Windows XP
  • Founded eHome and shipped the first version of Windows Media Center
  • Drove the invention of Windows Smart Displays and Windows Media Center Extenders
  • Was the driving force behind Windows Home Server.

I remember IE 3.0 coming out. Surprising though it may seem today, it was an impressive achievement, though history has not been kind either to ActiveX or to DCOM.

.net, microsoft, software development, visual studio

Real-world Microsoft Team Foundation Server: Not very good, says ThoughtWorks

12 Comments

I spoke to Sam Newman, who is European Continuous Delivery Practice Lead at ThoughtWorks, a software development company. Needless to say, we talked extensively about Continuous Delivery and I will be reporting on this separately; but I was also interested in his comments on Microsoft’s Team Foundation Server (TFS).  He told me that ThoughtWorks teams often end up working with it at their .NET clients, but it is problematic. In one case, he said, 6% of productive time was absorbed dealing with TFS.

What was the problem, performance, bugs, features lacking?

When we’ve looked at the problems we’ve had, a lot of it unfortunately comes down to the version control system. It’s not very good. It’s slow, you can’t do rollbacks, sometimes things go missing, you get locks. When we talked about 6% of time, they were things like waiting for a solution to expand in Visual Studio. A lot of those issues are in the version control system.

A frustration is that you cannot use TFS with any version control system other than its own.

Every other build server in the world, from Anthill to Go to Cruise Control to Hudson, you can put in at least 10 version control systems. In TFS they are all coupled. So you can’t take the version control and point it at Subversion. That might resolve a lot of the issues.

Why is TFS so widely used? It is because it comes in the box, says Newman.

I can’t think of a single client that wanted a tool, went out into the marketplace, and selected TFS because it is the right tool for them. Most clients use TFS because it comes with their Enterprise MSDN licence.

I have tried TFS myself and found it pretty good; but then I am just testing it on small projects as a solo developer, so it is hard for me to replicate the experience of a real-world team. You would have thought that performance issues, such as waiting ages for a solution to expand in Visual Studio, could be solved by tracing the reason for the delay; but apparently this is not easy.

This is anecdotal evidence, and of course there may be plenty of TFS installations out there that work very well; I would be interested in hearing of counter examples. I am also not sure to what extent the problems apply to all versions of TFS, or whether there is improvement in TFS 2010.

Newman recognizes that anecdotal evidence is not much use: he says ThoughtWorks is trying to collect some solid data that can be used both to discuss with clients making version control and build system choices, and with Microsoft.

Performance is a feature, and makes a large contribution to user satisfaction. The first release of Outlook 2007 was extraordinarily slow in some setups, and I remember the pain of clicking on a folder and then waiting tapping my fingers while it thought about expanding. It sounds like some TFS users are having a similar experience but in Visual Studio.

delphi, development, embarcadero, iphone, professional, software development

Delphi for Windows, Mac and iOS: screenshots and video of cross-platform development

14 Comments

Embarcardero is drip-feeding information about its forthcoming RAD Studio XE2 in an annoying manner; nevertheless the product does look interesting and promises cross-platform native code apps for Windows 64-bit, Windows 32-bit, Mac OS X and Apple iOS. I have grabbed some screens from a video recently posted by Embarcadero’s Andreano Lanusse; the video is also embedded below.

Here is Delphi XE2 showing a FireMonkey application in the designer. FireMonkey is a new cross-platform GUI framework.

image

Note the list of target platforms on the right. If you squint you can see 64-bit Windows, OSX, and 32-bit Windows.

image

How do you compile for the Mac? It is clear from the demo that Lanusse is running in a VMWare virtual machine on a Mac. He also has a Remote Profile option set to target the host Mac:

image

He then refers to a “Platform assistant” which you can see running in a terminal window on the Mac.  He is then able to compile and run from the Windows IDE:

image

Finally, he targets iOS, though this is a separate project, not just another target. The process exports the project to Xcode, Apple’s Mac and iOS IDE:

image

Next, we see the app running on the iPad simulator:

image

The ability to target the Mac is nice to have, but I suspect it is iOS that will attract more interest, given the importance of Apple’s mobile platform.

Here’s the complete video where you can perhaps puzzle out a few more details.

Update: there is also some Q&A in the comments here.

Graphics rendering is Direct2D or Direct3D on Windows, OpenGL on Mac. FireMonkey renders all components through the graphics API, it does not support use native OS components, though Embarcadero’s Michael Swindell says:

FireMonkey client area controls are rendered by OpenGL on Mac, but appear and work just like Cocoa controls – or however you want them to. There are many different Cocoa UI styles in OSX apps, and Firemonkey can render any of them – including iTunes, or Prokit which is an Apple UI style for Pro apps like Final Cut, not available to devs via Cocoa. Windows are Cocoa Windows and the client areas and all user controls are rendered by OpenGL in HD(2D) or 3D. Menus are std and rendered by Cocoa in the menu bar, and common dialogs are rendered by Cocoa. If the “true OSX” look isn’t for you, you’re welcome to use any included Style, download a custom style, or create your own custom style.

Swindell also addresses the matter of Linux and Android:

We do plan Linux and Android. But no eta yet until we get Win/OSX/iOS out. We would also like to provide language bindings for other languages.

Finally, a bit more about that Platform Assistant:

Developer requires a PC and a Mac (or Mac with VM running Windows). You will develop on Windows, and use the platform assistant (PA running on your Mac) to compile natively to your Mac and the PA handles debugging communication between the Mac and your IDE running on Windows. Delphi (or C++Builder) and Firemonkey create compiled stand alone OSX executables that you can sell/distribute to your users. They are native Mac apps. They “copy install” and run like any other Mac app, or you can use a Mac installer if you like.

adobe, development, mobile, open source, professional, software development

PhoneGap is at version 1.0

I’ve just spotted that PhoneGap has reached version 1.0. The release was announced at PhoneGap day in Portland, on Friday 29th July.

I have spent some time trying out various cross-platform mobile development tools. PhoneGap is among the most interesting and popular, and is also open source and free to use. If you believe that using the browser engine as an application runtime is the most sensible route to cross-platform mobile applications, then PhoneGap is the leading contender. It wraps your application to look like a native app, and also provides ways to call the native API when necessary.

PhoneGap received a boost when Adobe built it into Dreamweaver 5.5. I tried it out and was impressed with the design environment, but I am not sure how serious Adobe is about PhoneGap since there is no documentation on how to package your PhoneGap app for release, and my post has comments from puzzled users. My solution was to export the project to Eclipse and the standard PhoneGap tools, which misses part of the value of having it integrated into Dreamweaver.

Adobe installs PhoneGap into the Dreamweaver directory, so another issue is how to take advantage of the latest version if you are using Adobe’s tools. Overall I would suggest that using the PhoneGap SDK and Eclipse is a better option, though there is no problem with bringing in Dreamweaver for parts of the design.

I interviewed Nitobi president André Charland about PhoneGap earlier this year.

delphi, embarcadero, professional, software development

What’s coming in Delphi RAD Studio XE2: more details of 64-bit and Mac announced, introducing FireMonkey

10 Comments

Embarcadero’s David Intersimone has posted more details of what is coming in the new version of Delphi and RAD Studio XE2, to tie in with an international publicity tour.

One intriguing comment is a reference to FireMonkey:

with FireMonkey, the GPU-powered next-generation application platform, you’ll be able to create visually stunning HD and 3D business applications

Here is the teaser list of features:

  • Create GPU-powered FireMonkey applications
  • Build 64-bit Delphi applications
  • Create a single application and target both Windows and OS X
  • Extend your multi-tier DataSnap applications with new mobile and cloud connectivity in RAD Cloud
  • Connect any visual element to any type of data using LiveBindings™
  • Modernize the look and feel of your Windows applications with VCL styles
  • Create mobile-optimized web applications and standalone apps for iOS and Android devices using RadPHP

Hmm, so RAD Studio XE2 is targeting iOS and Android not with Delphi, but with RadPHP. That suggests some sort of HTML and JavaScript approach rather than a true native executable.

I was not greatly impressed with Delphi for PHP when I first looked at it. That was four years ago though, and since then Embarcadero has acquired Qadram, the third-party developer behind Delphi for PHP, so I would expect something more worthwhile in the forthcoming new version.

Update: Embarcadero’s Andreano Lanusse has posted more details about FireMonkey.

apple, development, google, mobile, nokia, open source, professional, software development, symbian, Web

Android only 23% open says report; Linux, Eclipse win praise

Vision Mobile has published a report on what it calls the Open Governance Index. The theory is that if you want to measure the extent to which an open source project is really open, you should look at its governance, rather than focusing on the license under which code is released:

The governance model used by an open source project encapsulates all the hard questions about a project. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative handsets or applications, and how are these requirements enforced? Governance determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

The 45-page report is free to download, and part-funded by the European Union Seventh Framework Program. It is a good read, covering 8 open source projects, including the now-abandoned Symbian Foundation. Here is the result:

Open Governance Index (%open)
Eclipse 84%
Linux 71%
WebKit 68%
Mozilla 65%
MeeGo 61%
Symbian 58%
Qt 58%
Android 23%

The percentages are derived by analysing four aspects of each project.

  • Access covers availability of source code and transparency of decisions.
  • Development refers to the transparency of contributions and acceptance processes.
  • Derivatives covers constraints on use of the project, such as trademarks and distribution channels.
  • Community structure looks at project membership and its hierarchy.

What is wrong with Android? I am not sure how the researchers get to 23%, but it scores badly in all four categories. The report observes that the code to the latest “Honeycomb” version of Android has not been published. It also has this to say about the Open Handset Alliance:

When launched, the Open Handset Alliance served the purpose of a public industry endorsement for
Android. Today, however, the OHA serves little purpose besides a stamp of approval for OHA
members; there is no formal legal entity, no communication processes for members nor frequent
member meetings.

By contrast, Eclipse and Linux are shining lights. MeeGo and Mozilla are also praised, thought the report does mention Mozilla’s “Benevolent dictators”:

In the case of conflicts and disputes, these are judged by one of two Mozilla “benevolent dictators” – Brendan Eich for technical disputes and Mitchell Baker for non-technical disputes.

Qt comes out OK but has a lower score because of Nokia’s control over decision making, though it sounds like this was written before Nokia’s Windows Mobile revolution.

WebKit scores well though the report notes that most developers work for Apple or Google and that there is:

Little transparency regarding how decisions are made, and no public information provided on this

Bearing that in mind, it seems odd to me that WebKit comes above Mozilla, but I doubt the percentages should be taken too seriously.

It is good to see a report that looks carefully at what it really means to be open, and the focus on governance makes sense.