Category Archives: software development

C# vs C++ and .NET vs Mono vs Compact Framework performance tests

A detailed benchmark posted on codeproject investigates the performance of basic operations including string handling, hash tables, math generics, simple arithmetic, sorting, file scanning and (for C#) platform invoke of native code. These are the conclusions:

  • There is only a small performance penalty for C# on the desktop versus C++.
  • Mono is generally slower than Microsoft .NET but still acceptable, and all the benchmarks ran without modification.
  • The Compact Framework, an implementation of .NET for mobile devices, performs poorly.

My observations: this matches my own experiments. Why then do some .NET applications still perform badly? When Evernote switched its application from .NET to native code it got much better performance.

The main reason is a couple of issues that this kind of benchmark hides. One is the GUI layer, which involves a ton of platform invoke code under the covers. Another is the large size of .NET applications because of the runtime and library overhead; a lot more stuff gets loaded into memory.

One thing to like about Silverlight is that it is truly optimized for client programming and load time tends to be faster than for a desktop .NET application.

Note that for mobile these benchmarks suggest that C++ still has a big advantage. It would be interesting to see them applied to Silverlight apps on Windows Phone 7. As I understand it, the Silverlight .NET runtime in Windows Phone 7 shares code with the Compact Framework on Windows Mobile, so it is possible that the poor results for the Compact Framework would also apply to Silverlight on Windows Phone 7. Unfortunately developers do not have the option for C++ on Windows Phone 7.

RESTful and modernised: making sense of Adobe’s new Enterprise platform

Adobe has announced its Digital Enterprise Platform for Customer Experience Management. My tip to Adobe: that is too many words with too many syllables for busy IT people who are trying to get their work done. What on earth is it? The same old stuff repackaged, or something genuinely new?

The answer is a bit of each. Adobe has made several big acquisitions over the last few years, starting with the Macromedia merger in 2005 that really formed a new Adobe, bringing together digital publishing and the Flash platform. In September 2009 Adobe acquires Omniture for web analytics, and in October 2010 Day Software. This last one seems to be having a huge impact. Day’s product is called CQ5 Web Content Management and is built on CRX, a content repository which conforms to JCR 2.0 (Java Technology API 2.0), a Java API. Here’s Roy Fielding, formerly at Day and now Principal Scientist at Adobe, from this white paper [pdf]:

The Content Repository API for Java Technology (JCR) is poised to revolutionize the development of J2SE/J2EETM applications in the same way that the Web has revolutionized the development of network-based applications. JCR’s interface designers have followed the guiding principles of the Web to simplify the interactions between an application and its content repository, thus replacing many application-specific or storage-specific interfaces with a single, generic API for content repository manipulation.

JCR is a boon for application developers. Its multipurpose nature and agnostic content model encourages reuse of the same code for many different applications, reducing both the effort spent on development per application and the number of interfaces that must be learned along the way. Its clean separation between content manipulation and storage management allows the repository implementation to be chosen based on the actual performance characteristics of the application rather than some potential characteristics that were imagined early in the application design. JCR enables developers to build full-featured applications based on open source implementations of a repository while maintaining compatibility with the proprietary repositories that are the mainstay of large data centers.

Adobe already has an application platform based on LiveCycle Enterprise Suite, which you will notice now redirects to the Digital Enterprise Platform. Ben Watson, Adobe’s Principal Customer Experience Strategist, explained it to me like this:

The core of the platform now becomes the repository that we got from the Day acquisition. We are also following their leadership around the use of RESTful technology, so changing how we do our web services implementation, how we do our real time data integration into Flash using data services. There’s really four technologies at play here. There’s CQ5, Adobe LiveCycle which is all the business process management on the back end, the online marketing suite with Omniture, and Creative tools which allow to both design and develop all of this content and assets … We had two Java platforms and we brought them into one.

adobe-slide

You can read up on the Digital Enterprise Platform here or see a chart of capabilities here. Much of it does look like rebranding of existing LiveCycle modules; but as a statement of direction it is an interesting one.

Is this for on-premise deployment, or cloud hosted? Adobe has a tie-up with Amazon for hosted deployment, though there is no no multi-tenant hosting from Adobe yet; I got the impression from Watson that it is being worked on.

Adobe is aware that it does not stand alone, and there are several connectors and integration points for third-party applications, such as a SAP data services connector.

Adobe also has a series of “solutions”, which are permutations of web content management, analytics, document processing, social media and so on.  There is also a Unified Workspace, currently in beta, which is a dashboard application.

The company’s line is that it is well placed to address the challenge of the mobile revolution, and to bring greater usability and social interaction to business applications, the consumerization of IT.

Although that sounds a strong pitch, melding all this together into something new while keeping hold of existing developers and designers is a challenge. Another issue for Adobe is that the company’s strong presence in design, multimedia and marketing makes it hard to appeal to more general enterprise developers. Nevertheless, the combination of Fielding’s influence and Adobe’s strength in design, documents and cross-platform clients makes this a platform worth watching.

Adobe Flash Builder now targets Apple iOS, BlackBerry PlayBook, Google Android

Adobe has released Flash Builder 4.5.1, a free update to Flash Builder 4.5. The big news is that it now targets Apple iOS as well as Google Android and BlackBerry Tablet OS (as used in the PlayBook).

image

Although Apple iOS support in Flash Builder was announced when Creative Suite 5.5 was released, it has only now been made available. I will be testing the new support shortly so check back soon. In my simple cross-platform test app, mobile AIR was one of the better performers on Android, so if performance is good on iOS as well this will prove a useful tool.

Cross-platform concerns as Adobe abandons AIR for Linux

Adobe is giving up on AIR for Linux – at least, in a fully supported manner:

To support the variety of Linux-based platforms across PCs and devices, we are prioritizing a Linux porting kit for AIR (including source code), which Open Screen Project (OSP) partners can use to complete implementations of AIR for Linux-based platforms on PCs, mobile devices, TVs and TV-connected devices. We will no longer be releasing our own versions of Adobe AIR and the AIR SDK for desktop Linux, but expect that one or more of our partners will do so. The last Adobe release of AIR for desktop Linux is AIR 2.6.

This is a curious message. OSP partners include ARM, Intel, the BBC, Google, Toshiba and other big names; but which of these might build an AIR SDK and on what sort of terms might it be supplied? Or it is more likely that, say, the BBC will deliver BBC iPlayer for LInux in a bundle that includes the AIR runtime? Or is it just wishful thinking?

Adobe’s open source evangelist Dave McAllister has a go at defending the decision, pointing out that the growing client operating systems are Android and iOS, not desktop Linux, and that AIR for Linux accounts for only a 0.5% download share. However, Linux developers observe that Adobe’s AIR for Linux effort has always been half-hearted and tricky to install, especially on 64-bit installations. AIR itself is still 32-bit, as is the Flash Player on all systems, though there is 64-bit version in preview codenamed “Square”.

Most people run Windows or Mac desktops, and will not miss AIR for Linux. That said, decisions like this do undermine confidence in the Flash platform as a cross-platform proposition. The problem is, Flash technology is not open source and ultimately whether a particular platform is supported is a matter for Adobe, with all the commercial and political factors that implies.

The risk for Adobe is that when it abandons smaller platforms, it make open standard alternatives and in particular the collection of web technologies we call HTML5 more attractive.

Hands On with Appcelerator Titanium Studio

I spent some time today trying out Appcelerator’s new Titanium Studio. Titanium is a cross-platform framework that lets you compile apps for Apple iOS, Google Android, RIM Blackberry, and desktop operating systems. Its chief attraction is the mobile aspect, particularly as it claims to build “native apps”.

I am thoroughly bored of writing calculator apps, but having embarked on this this test case I am keeping going since it makes it easier to compare one with another. I started by writing it for Android on Windows. I had some setup issues, but once resolved it pretty much worked, though the development process was fairly painful.  There is no visual GUI designer and my calculator has quite a few buttons, so I ended up counting pixels and trying out my work by debugging in the emulator. Performing a build and running in the emulator is a lengthy operation, so this is a tedious way to work. Come back Visual Studio, all is forgiven!

I persevered though, and eventually had my calculator up and running on my HTC Desire.

image

The design could be improved; but it is good enough for my purpose. Unfortunately though the GUI is not as responsive as I would like. It is easy to lose taps if you tap a little too fast, which is a serious flaw in a calculator. In this respect, the Titanium build is better than the PhoneGap/JQuery app I built, but still not good enough for a production app.

Time to port to iOS. Here I ran into a number of difficulties. I installing Titanium Studio on a Mac, copied the project from Windows and tried to open it. Titanium Studio complained about the absence of the Android SDK and eventually froze trying to fully initialize the workspace. Force Quit, delete the project, and try again. This time I created a new project and just copied over the app.js file that has my source code. Titanium Studio was happier; but the app would not open in the iOS Simulator.

The problem: I have installed the latest Xcode and IOS 5.0 beta SDK. Even if you target iOS 4.x, Titanium is not quite compatible. However, my iPhone is still on iOS 4.3, and I was able to deploy the app to the device. Unfortunately the GUI was scrambled. This is how it looked:

image

Not good. Eventually I worked out the problem. On Titanium for Android there is no need to specify the height of buttons and labels; this automatically sizes to the content. On iOS though, if you do not specify the height it stretches the object from whatever you specify as top down to the bottom of the container.

I added height attributes to sort out the GUI, though I am still scratching my head over one issue. I specified a different value for the top attribute of a label and a button, but they were rendered at the same vertical position. Odd. I simply compensated for this and ended up with a workable GUI. Here it is on the iPhone:

image

The good news: this is by far the best performing of all the cross-platform solutions I have tried. I cannot out-tap it, and it would be fine in this respect for a production app.

Note that attempting to debug using the community edition raises this message:

image

No debugging without a subscription; a strong incentive to subscribe.

It is also worth noting that you can open the project generated by Titanium in Xcode. I wondered if that might shed light on the compatibility issues. It is an interesting thing to try, as you see the innards of Titanium’s code, complete with a number of reported issues.

image

I also get this:

image

Still, time to wrap up. I am impressed with the performance of my app on the iPhone, but disappointed on Android. On the other hand, the whole point of Titanium is to achieve cross-platform, otherwise you might as well use Objective C. Of course there may be ways to improve the performance; I just dived in and tried out the tool without chasing up possible optimisations.

Appcelerator has released Titanium Studio, IDE for cross-platform mobile development

Appcelerator has released Titanium Studio, an IDE built with Aptana, the Eclipse-based IDE which the company acquired in January. It is an interesting products because it lets you build cross-platform mobile apps for Apple iOS, Google Android, and Blackberry, as well as desktop applications.

I downloaded the community edition and gave it a quick try. The download includes the Titanium SDK and is around 150MB.

Titanium Studio wanted to grab file associations for CSS, JS and PHP by default – but at least it asked first

image

I noticed lots of Python scripts getting installed. The install completed and I was up and running.

Running the IDE requires login, which seems intrusive. You can avoid this by going offline.

image

I created a new empty Android 2.2 project and got an error on first run. Required jarsigner not found. Required javac not found.

image

I fixed this by adding the JDK to the path and setting Java_home to the JDK; previously my Adobe CS5 install had set this to its own JRE install.

Next, I built a hello world application.

image

It feels like a version 1.0 release. When I clicked Run it started the emulator but did not run the app for some reason. A second run after the emulator had opened worked. Code Assist seems a bit hit or miss. There it tooltip help for some keywords, but too brief to be much use, and pressing F1 is unrewarding. No visual GUI designer. Finally, and this is purely a personal thing, the editor has a black background – something I will be sure to change soon.

Nevertheless, this is a step forward for Titanium and presuming the apps perform well I think it is significant and worth investigating.

Easy database apps for iPad and iPhone with FileMaker Pro and Go

FileMaker Pro is a database manager from FileMaker Inc, a wholly owned subsidiary of Apple. It is a capable produce that has been around for over 20 years and is the dominant Mac-based database manager, though there is also a Windows version. FileMaker has evolved relatively slowly, with more focus on usability than on features. In comparison to Microsoft Access, FileMaker wins on usability and scalability, but Access has a more traditional approach based on SQL and programming with Visual Basic for Applications. FileMaker has a drag-and-drop script editor and support for AppleScript on the Mac.

Although the script editor is frustrating for someone used to writing code, it does work. As well as manipulating the data, you can set and retrieve local and global variables, perform loops and display custom dialogs; it is not as limited as it may seem at first.

A FileMaker database can be huge, with 8 terabytes specified as the theoretical limit. External databases are accessible through ODBC on both Windows and Mac.

The number of users supported by FileMaker is limited. The desktop product supports up to 5 concurrent users, and FileMaker Server up to 250 users. FileMaker has its own built-in security system, though FileMaker server can also authenticate against an external directory. Security is fine-grained, and you can even specify permissions for an individual record.

I have not looked at FileMaker for a few years, but renewed my interest when the company came out with FileMaker Go, a runtime client for Apple iOS. Given that FileMaker runs scripts you might have thought this would be restricted, bearing in mind this provision in the App Store guidelines:

2.7 Apps that download code in any way or form will be rejected

This is normally taken to prohibit runtimes like Java or Adobe Flash/AIR. Well, either someone decided that FileMaker scripts are not code; or there are special rules for an Apple subsidiary, which is reasonable enough. Anyway, FileMaker Go is in the App Store and does run scripts.

What this means is that you can create apps in FileMaker Pro and deploy them to iOS without going via the App Store. There are two models. FileMaker Go can open a file hosted by FileMaker desktop or server, in which case it behaves like a Mac or Windows client, or alternatively you can transfer a file to FileMaker Go to run locally. Transferring a file is easy using iOS launch service; essentially, if you can access the file via the internet or an email attachment, you can just tap it on the device and it will open in FileMaker Go. The advantage of running locally is offline use, whereas the advantage of the client-server model is that all users have the most up-to-date version of the data, and the database can be much larger. FileMaker is a real server application; this is not just file sharing. This also means that FileMaker must be running with the database open if you want to to use the client-server approach.

I tried FileMaker Go with a simple example and it works well. In essence it is delightful; you just open your database either locally or over the network, and it works. Here is a sample app on the iPhone 4:

image

That said, there are things that do not work, spell checking for example. It is also stripped of anything other than client features, so you cannot modify database structure, create new databases, or publish from the device to other clients. You also have to be careful with layout size. Most layouts designed for the desktop will need modification to work well.

There are a couple of issues. One is performance. It is just about bearable, but has that lethargic feel that you get with interpreted code on a relatively slow processor.

Another issue is synchronisation. If you want to work offline, how do you update your main database with any changes? The issue is little different with FileMaker Go than it is with a laptop, and it is discussed here. You have several choices:

1. Don’t synchronize, use client-server.

2. Treat your local database as read-only.

3. Use import and export. Existing records will simply be overwritten by imported ones.

4. Use a third-party tool. However the tool mentioned here, SyncDek, probably does not work with FileMaker Go since it needs to run a Java process on the client.

5. Roll your own. “FileMaker Pro has all the tools needed to create a robust synchronization system” says the guide; but it is non-trivial to implement this.

It is worth mentioning that FileMaker Pro also has an Instant Web Publishing feature that gives another route to mobile access and may perform better. There are pros and cons. The big one is offline, only available with FileMaker Go. Another is scripts. Some scripts work in Instant Web Publishing, but FileMaker Go is more compatible in this area.

I think this is significant for businesses where iOS devices are turning up. Many business apps do resolve down to forms over data, and this is is an easy way to deliver this kind of application to iOS users.

How is FileMaker pro as a programming tool? Just for fun, and because I have done it for other mobile development tools, I built a calculator in FileMaker. I do not recommend FileMaker for general-purpose programming; but it has the essentials, a form designer and scripting. Here is the result on an iPhone 4:

image

Oddly the biggest struggle I had was finding an easy way to display the input and result. In the end I added a field to the database just for this purpose. If a FileMaker expert could let me know a better way to update a text label on a layout via script, I would be interested to know.

The calculator is slow too, not for the calculation of course, but the operation of the user interface. Still, it does demonstrate that FileMaker Go is indeed able to download code and run it.

Update: I replaced the display field with a merge variable, which works better as it avoids focus issues and the keyboard popping up. Thanks to the commenter for the suggestion.

Common sense on Windows 8, Silverlight and .NET

I am wary about writing another post on this subject in the absence of any further news, but since there is a lot of speculation out there I thought it would be worth making a few further observations.

Will Windows 8 support Silverlight and/or some other variety of .NET in its new touch-centric mode? I will be astonished if it does not. Aside from other considerations, this is an essential unifying piece between the Windows Phone 7 developer platform and the Windows 8 developer platform, which from what we have seen have a similar user interface. For further evidence, try an internet search for “Jupiter” and “appx”.

Why isn’t Microsoft already shouting about this? A good question. Part of the answer is that Microsoft wants to get developers enthused about the forthcoming build conference in September, and is holding back information.

Another part of the answer is that Windows historically has kept .NET as a layer above the operating system, rather than as part of it. We saw this in Windows 7, where to take advantage of new features like jump lists or thumbnail toolbars, .NET developers had to use a supplementary Windows API Code Pack. The Windows team delivered only native code or COM APIs.

Admittedly, there are differences this time around. The Windows team is not just delivering native code APIs, but also an HTML and JavaScript API. This is a break with the past, hence the talk of a new platform.

When it comes to desktop applications, would not Silverlight or something .NET based be a better choice than HTML5? I can see both sides of this. On one side is all the effort Microsoft has invested in .NET and Silverlight over the past decade. As I’ve noted before, I see Silverlight as what client-side .NET should have been from the beginning, lightweight, secure, simple installation, but with support for C# and much of the .NET Framework which developers know so well.

On the other hand, I can see Microsoft wanting to tap into the wave of HTML5 development and to make it easy for web developers to build apps for Windows 8.

In the end, developers will most likely have the choice. That puts pressure on Microsoft’s developer division to provide strong tools for two different development models; but I think that is what we will get.

Is .NET itself under threat? As far as I am aware, Microsoft has no plan “B” in terms of web and application server technology, and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java. Further, this aspect of the Microsoft Platform is under Server and Tools which is 100% behind .NET as far as I can tell. We have also seen Silverlight crop up in the user interfaces for new server products like InTune and System Center. On the server then, there is no evidence for .NET doubts at Microsoft; and considering the trend towards cloud+device computing the server is now at the heart of most business application development.

That said, Microsoft has challenges in sustaining .NET momentum. It cannot afford to fail with Azure, yet other platforms such as Amazon EC2 have greater developer mindshare as cloud computing platforms. VMWare with its Java-based Spring framework is another key competitor. Microsoft was late to the server virtualisation party with Hyper-V. I also see declining market share for IIS versus Apache in Netcraft’s statistics, although these figures are distorted by millions of little-used domains that get shunted from one platform to another by major hosting providers.

Further, it seems to me that the fortunes of .NET on the server cannot be completely separated from what happens on the client. One of the attractions of .NET is the integration between client and server, with Visual Studio as the tool for both. Windows has lost momentum to Apple in mobile, in tablets, and in high-end laptops, making Windows-only clients less attractive. In that context, the decision of the Windows team to favour HTML5 over .NET is a blow, in that it seems to concede that the future client is cross-platform, though I expect there will be some sort of outcry when we see all the proprietary hooks Microsoft has implemented to get HTML5 apps integrated into Windows 8.

Therefore these really are difficult times for .NET. I do not count Microsoft out though; it still dominates business computing, and amongst consumers the Xbox may prove an important new platform as Tom Warren notes.

While I have reservations about Windows 8, it does demo nicely as a new touch-centric operating system and Microsoft surely has chances in the corporate world with new-style tablets that integrate with its system management tools and which run Microsoft Office.

Finally, the angst over the role of .NET in Windows 8 shows that many developers actually like the platform, including Visual Studio, the C# language, the .NET Framework, and XAML for building a rich user interface.

Apple iCloud: i is for integrated

Apple has announced iCloud, smart cloud storage for Apple devices.

The iCloud will store documents, email, contacts and appointments, and synch the data to multiple devices including iPad, iPhone, iPod touch, Mac or PC. You get 5GB free with more available to purchase. Books are synched so that your place is saved from one device to the next, a feature borrowed from Amazon Kindle.

Apple has also exposed an API for developers:

Apple apps are seamlessly integrated with iCloud, and we’ve given developers the tools to make their apps work with iCloud, too. So you’ll be able to paint a masterpiece, play a game, create reminders, edit stock lists, and more — and have it all stay with you on all your devices.

This API allows for key-value pairs to be stored as well as documents.

The iCloud also backs up settings, including device settings and app data. If your iOS device is stolen, restoring it should be just a matter of reconnecting:

When you set up a new iOS device or need to restore the information on one you already have, iCloud Backup does the heavy lifting. Just connect your device to Wi-Fi and enter your Apple ID and password. Your personal data — along with your purchased music, apps, and books from iTunes — will appear on your device.

This is similar to what Google is promising for the Chromebook; in fact, there are quite a few parallels there.

Email is also synchronised, provided you use Apple’s me.com email account. Users of Microsoft Exchange or similar server-based systems already have the experience of email, appointments and contacts synched across all devices; now iCloud brings this to all Apple users.

There is also special provision for music. In this case you do not actually have to upload the tracks in most cases, since Apple will “scan and match” your collection. This applies to CDs you have ripped as well as iTunes purchases, which strikes me as a big concession from the music industry, since there is actually no way to tell if you ripped your own CD or copied it from a friend. You do have to pay $24.99 annually for this though, so it is a kind of music subscription. However it falls short of Spotify’s play-anything offer, since you have to acquire each track by some separate means first.

Taking each feature individually, there is little new here other than Apple’s deal with the music companies. Taken together though, this is a big deal. Apple iOS devices are no longer tied to an iTunes installation on Mac or PC; they are now cloud devices. If you think as I do that cloud+device is the direction of computing today, this is a key move.

One weak point is collaboration. The iCloud seems to be a private store, whereas with technology like Microsoft SharePoint or Google Apps you can publish documents to selected individuals or to the world.

I expect it is just a matter of time before Apple adds document sharing based on Apple IDs or me.com email identities. Another obvious move would be some sort of web site integration so you can publish certain kinds of data.

Another weak point is system requirements. Some features will require iOS 5 or OS X Lion. However, in the past iOS upgrades have been free so that is unlikely to be a problem; and even an upgrade to Lion will only be $29.00, provided your Mac is compatible – it needs Intel Core 2 Duo or better.

There is also the question of whether you want to store all your critical data on Apple’s servers. In my own encounters with Apple’s online security I have not been impressed. Someone managed to sign up for iTunes using my email address once; I could have had full access to his account and stored credit card details. Apple also uses the notorious “security questions” technique for resetting passwords. It is also not clear whether data in iCloud is encrypted.

That said, as with the iPad versus Microsoft’s Tablet PC, I am struck by how Apple has taken a feature which Microsoft has worked on for years but failed to implement sensibly and consistently. Microsoft had Live Mesh for example back in 2008 complete with an API for synchronising documents across PCs. The API was poor, there was an operating system component which could be problematic to install, and mobile device support never really came. Then in 2010 Microsoft scrapped most it and replaced it with a new Live Mesh based on SkyDrive which is now part of Windows Live Essentials. It is an optional extra for Windows users and aimed at consumers; business users can get some of this using Exchange and SharePoint as mentioned above, though these are usually privately hosted. Everything is an extra, some things free, some things paid for. In the confusion third party services like Dropbox have flourished.

Microsoft will learn from Apple and we will see a nicely integrated cloud story in Windows sometime around 2014, based on past performance.

Full circle at Microsoft: from the early days of .NET to the new Chakra JavaScript engine

A discussion with a friend about the origins of Microsoft’s .NET runtime prompted a little research. How did it come about?

A quick search does not throw up any detailed accounts. Part of the problem is that much of it is internal Microsoft history, confidential at the time.

One strand, mentioned here, is Colusa’s OmniVM:

OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java.

Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft’s Jason Zander, commenting to a story on this blog, does not mention OmniVM:

The CLR was actually built out of the COM+ team as an incubation starting in late 1996. At first we called it the "Component Object Runtime" or COR. That’s why several of the unmanaged DLL methods and environment variables in the CLR start with the Cor prefix.

Still, the timing pretty much matches. If Lucco came to Microsoft in 1996, he could have been part of an incubation project starting later that year.

In June 1999 Microsoft previewed the Common Executable Format for Windows CE:

A demonstration on Common Executable Format (CEF), a new compiler target within the Visual C++® development system for Windows CE, was also presented. This compiler enables cross-processor portability within a category of devices, such as Palm-size PCs or Handheld PCs. A single program executable under CEF is translated to the native code on either the host PC or the device, as desired. This capability eliminates the need for developers to recompile an application for every possible processor on a given Windows CE-based appliance before bringing it to market, thus enabling them to support every version of a device (Palm-size or Handheld PC) quickly and easily.

In 2000 I interviewed Bob Powell, then at Stingray, who told me this in relation to .NET:

There was an early version of the system for Windows CE called the Common Executable Format (CEF). The Pocket PC, which uses around seven different processor types, and which has many different versions of the operating system, is a deployment nightmare. This problem was addressed by the CEF, which was a test case. What is now in the IL is a more refined version of that.

Hmm, now that Windows is coming to ARM alongside x86, this sounds like it could be useful technology … though despite obvious similarities, I don’t think CEF was really an early version of the CLR. Maybe the teams communicated to some extent.

Now this is interesting and brings the story up to date. Lucco is still at Microsoft and apparently his team built Chakra, the new JavaScript engine introduced in Internet Explorer 9:

image

Steven E. Lucco is currently the chief architect for the Microsoft Browser Programmability and Tools (BPT) team. BPT builds the Internet Explorer’s Chakra Javascript script engine, as well as the Visual Studio tools for creating scalable, efficient Web client applications.

Right now, these are dark days for .NET, because Microsoft now seems to be positioning HTML and JavaScript as the new universal runtime.

It seems that the man who perhaps began the .NET Runtime is also at the centre of the technology that might overtake it.

Update: this post has prompted some discussion and the consensus so far is that the OmniVM acquisition probably had little to do with the technology that ended up as .NET. The one thing that is beyond doubt is that the COM team created the .NET CLR as Zander reported. I actually spoke to Zander at TechEd recently and we touched on his early days at Microsoft working with Scott Guthrie:

I was actually one of the original CLR developers. When Scott and I first started working together, he invented ASP.NET and my team invented the CLR.

The history is interesting and if the relevant people at Microsoft are willing to talk about it in more detail it is something I would love to write up – so if that is you, please get in touch!