Category Archives: software development

A glimpse into Microsoft history which goes some way to explaining the decline of Windows

Why is Windows in decline today? Short answer: because Microsoft lost out and/or gave up on Windows Phone / Mobile.

But how did it get to that point? A significant part of the story is the failure of Longhorn (when two to three years of Windows development was wasted in a big reset), and the failure of Windows 8.

In fact these two things are related. Here’s a post from Justin Chase; it is from back in May but only caught my attention when Jose Fajardo put it on Twitter. Chase was a software engineer at Microsoft between 2008 and 2014.

Chase notes that Internet Explorer (IE) stagnated because many of the developers working on it switched over to work on Windows Presentation Foundation, one of the “three pillars” of Longhorn. I can corroborate this to the extent that I recall a conversation with a senior Microsoft executive at Tech Ed Europe, in pre-Longhorn days, when I asked why not much was happening with IE. He said that the future lay in rich internet-connected applications rather than browser applications. Insightful perhaps, if you look at mobile apps today, but no doubt Microsoft also had in mind locking people into Windows.

WPF, based on .NET and DirectX, was intended to be used for the entire Windows shell in Longhorn. It was too slow, memory hungry, and buggy, eventually leading to the Longhorn reset.

“Ever since Longhorn the Windows team has had an extremely bitter attitude towards .NET. I don’t think its completely fair as they essentially went all in on a brand new technology and .NET has done a lot of evolving since then but nonetheless that sentiment remains among some of the now top players in Microsoft. So effectively there is a sentiment that some of the largest disasters in Microsoft history (IE’s fall from grace and multiple “bad” versions of Windows) are, essentially, totally the fault of gambling on .NET and losing (from their perspective). “

writes Chase.

This went on to impact Windows 8. You will recall that Windows Phone development was once based on Silverlight. Windows 8 however did not use Silverlight but instead had its own flavour of XAML. At the time I was bemused that Microsoft, with an empty Windows 8 app store, had not enabled compatibility with Windows Phone applications which would have given Windows 8 a considerable boost as well as helping developers port their code. Chase explains:

“So when Microsoft went to make their new metro apps for windows 8/10, they almost didn’t even support XAML apps but only C++ and JavaScript. It was only the passion of the developer community that pushed it over the edge and let it in.”

That was a shame because Silverlight was a great bit of technology, lightweight, powerful, graphically rich, and even cross-platform to some extent. If Microsoft had given developers a consistent and largely compatible path from Silverlight to Windows Phone to Windows 8 to Windows 10, rather than the endless changes of direction that happened instead, its modern Windows development platform would be stronger. Perhaps, even, Windows Phone / Mobile would not have been abandoned; and we would not have to choose today between the Apple island and the ad-driven Android.

The end of the Edge browser engine. Another pivotal moment in Microsoft’s history

Microsoft’s Joe Belfiore has announced that future versions of its Edge web browser will be built on Chromium. Chromium is an open source browser project originated by Google, which uses it for Chrome. The browser engine is Blink, which was forked from WebKit in April 2013.

image

Belfiore does not specify what will happen to Chakra, the JavaScript engine used by Edge, but it seems likely that future versions of Edge will use the Chrome V8 engine instead.

There is plenty of logic behind the move. The immediate benefit to Microsoft in having its own browser engine is rather small. Chromium-based Edge will still have Microsoft’s branding and can still have unique features. It opens an easy route to cross-platform Edge, not only for Android, but also for MacOS and potentially Linux. It will improve web compatibility because all web developers know their stuff has to run properly in Chrome.

This is still a remarkable moment. The technology behind Edge goes right back to Trident, the Internet Explorer engine introduced in 1997. In the Nineties, winning the browser wars was seen as crucial to the future of the company, as Microsoft feared that users working mostly in the browser would no longer be hooked to Windows.

Today those fears have somewhat come to pass; and Windows does indeed face a threat, especially from Chrome OS for laptops, and of course from iOS and Android on mobile, though it turns out that internet-connected apps are just as important. Since Microsoft is not doing too well with its app store either, there are challenges ahead for Microsoft’s desktop operating system.

The difference is that today Microsoft cares more about its cloud platform. Replacing a Windows-only building block with a cross-platform one is therefore strategically more valuable than the opportunity to make Edge a key attraction of Windows, which was in any case unsuccessful.

The downside though (and it is a big one) is that the disappearance of the Edge engine means there is only Mozilla’s Gecko (used by Firefox), and WebKit, used by Apple’s Safari browser, remaining as mainstream alternatives to Chromium. Browser monoculture is drawing closer then, though the use of open source lessens the risk that any one company (it would be Google in this instance) will be able to take advantage.

Internet Explorer was an unhealthy monoculture during its years of domination, oddly not because of all its hooks to Windows, but because Microsoft stagnated its development in order to promote its Windows-based application platform (at least, that is my interpretation of what happened).

Let me add that this is a sad moment for the Edge team. I like Edge and there was lots of good work done to make it an excellent web browser.

State of Microsoft .NET: transition to .Net Core or be left behind

The transition of Microsoft’s .NET platform from Windows-only to cross-platform (and open source) is the right thing. Along with Xamarin (.NET for mobile platforms), it means that developers with skills in C#, F# and Visual Basic can target new platforms, and that existing applications can with sufficient effort be migrated to Linux on the server or to mobile clients.

That does not mean it is easy. Microsoft forked .NET to create .NET Core (it is only four years since I wrote up one of the early announcements on The Register) and the problem with forks is that you get divergence, making it harder to jump from one fork to the other.

At first this was disguised. The idea was that .NET Framework (the old Windows-only .NET) would be evolved alongside .NET Core and new language features would apply to both, at least initially. In addition, ASP.NET Core (the web framework) runs on either .NET Framework or .NET Core.

This is now changing. Microsoft has shifted its position so that .NET Framework is in near-maintenance mode and that new features come only to .NET Core. Last month, Microsoft’s Damian Edwards stated that ASP.NET Core will only run on .NET Core starting from 3.0, the next major version.

This week Mads Torgersen, C# Program Manager, summarised new features in the forthcoming C# 8.0. Many of these features will only work on .NET Core:

Async streams, indexers and ranges all rely on new framework types that will be part of .NET Standard 2.1. As Immo describes in his post Announcing .NET Standard 2.1, .NET Core 3.0 as well as Xamarin, Unity and Mono will all implement .NET Standard 2.1, but .NET Framework 4.8 will not. This means that the types required to use these features won’t be available when you target C# 8.0 to .NET Framework 4.8.

Default interface member implementations rely on new runtime enhancements, and we will not make those in the .NET Runtime 4.8 either. So this feature simply will not work on .NET Framework 4.8 and on older versions of .NET.

The obvious answer is to switch to .NET Core. Microsoft is making this more feasible by supporting WPF and Windows Forms with .NET Core, on Windows only. Entity Framework 6 will also be supported.  It is also likely that this will work on Windows 7 as well as Windows 10.

This move will not be welcome to all developers. The servicing for .NET Framework is automatic, via Windows Update or on-premises equivalents, but for .NET Core requires developer attention. Inevitably some things will not work quite the same on .NET Core and for long-term stability it may be preferable to stay with .NET Framework. The more rapid release cycle of .NET Core is not necessarily a good thing if you prioritise reliability over new features.

The problem though: from now on, .NET Framework will not evolve much. There are a few new things in .NET Framework 4.8, like high DPI support, Edge-based browser control, and better touch support. There are really minimal essential updates. In time, maintaining applications on .NET Framework will look like a mistake as application capabilities and performance fall behind. That means, if you are a .NET developer, .NET Core is in your future.

SQLite with .NET: excellent but some oddities

I have been porting a C# application which uses an MDB database (the old Access/JET format) to one that uses SQLite. The process has been relatively smooth, but I encountered a few oddities.

One is puzzling and is described by another user here. If you have a column that normally stores string values, but insert a string that happens to be numeric such as “12345”, then you get an invalid cast exception from the GetString method of the SQLite DataReader. The odd thing is that the GetFieldType method correctly returns String. You can overcome this by using GetValue and casting the result to a string, or calling GetString() on the result as in dr.GetValue().ToString().

Another strange one is date comparisons. In my case the application only stores dates, not times; but SQLite using the .NET provider stores the values as DateTime strings. The SQLite query engine returns false if you test whether “yyyy-mm-dd 00:00:00” is equal to “yyy-mm-dd”. The solution is to use the date function: date(datefield) = date(datevalue) works as you would expect. Alternatively you can test for a value between two dates, such as more than yesterday and less than tomorrow.

Performance is excellent, with SQLite . Unit tests of various parts of the application that make use of the database showed speed-ups of between 2 and 3 times faster then JET on average; one was 8 times faster. Note though that you must use transactions with SQLite (or disable synchronous operation) for bulk updates, otherwise database writes are very slow. The reason is that SQLite wraps every INSERT or UPDATE in a transaction by default. So you get the effect described here:

Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. Transaction speed is limited by the rotational speed of your disk drive. A transaction normally requires two complete rotations of the disk platter, which on a 7200RPM disk drive limits you to about 60 transactions per second.

Without a transaction, a unit test that does a bulk insert, for example, took 3 minutes, versus 6 seconds for JET. Refactoring into several transactions reduced the SQLite time to 3 seconds, while JET went down to 5 seconds.

Should you convert your Visual Basic .NET project to C#? Why and why not…

When Microsoft first started talking about Roslyn, the .NET compiler platform, one of the features described was the ability to take some Visual Basic code and “paste as C#”, or vice versa.

Some years later, I wondered how easy it is to convert a VB project to C# using Roslyn. The SharpDevelop team has a nice tool for this, CodeConverter, which promises to “Convert code from C# to VB.NET and vice versa using Roslyn”. You can also find this on the Visual Studio marketplace. I installed it to try out.

image

Why would you do this though? There are several reasons, the foremost of which is cross-platform support. The Xamarin framework can use VB to some extent, but it is primarily a C# framework. .NET Core was developed first for C#. Microsoft has stated that “with regard to the cloud and mobile, development beyond Visual Studio on Windows and for non-Windows platforms, and bleeding edge technologies we are leading with C#.”

Note though that Visual Basic is still under active development and history suggests that your Windows VB.NET project will continue running almost forever (in IT terms that is). Even Visual Basic 6.0 applications still run, though you might find it convenient to keep an old version of Windows running for the IDE.

Still, if converting a project is just a right-click in Visual Studio, you might as well do it, right?

image

I tried it, on a moderately-size VB DLL project. Based on my experience, I advise caution – though acknowledging that the converter does an amazing job, and is free and open source. There were thousands of errors which will take several days of effort to fix, and the generated code is not as elegant as code written for C#. In fact, I was surprised at how many things went wrong. Here are some of the issues:

The tool makes use of the Microsoft.VisualBasic namespace to simplify the conversion. This namespace provides handy VB features like DateDiff, which calculates the difference between two dates. The generated project failed to set a reference to this assembly, generating lots of errors about unknown objects called Information, Strings and so on. This is quick to fix. Less good is that statements using this assembly tend to be more convoluted, making maintenance harder. You can often simplify the code and remove the reference; but of course you might introduce a bug with careless typing. It is probably a good idea to remove this dependency, but it is not a problem if you want the quickest possible port.

Moving from a case-insensitive language to a case-sensitive language is a problem. Visual Studio does a good job of making your VB code mostly consistent with regard to case, but that is not a fix. The converter was unable to fix case-sensitivity issues, and introduced some of its own (Imports System.Text became using System.text and threw an error). There were problems with inheritance, and even subtle bugs. Consider the following, admittedly ugly and contrived, code:

image

Here, the VB coder has used different case for a parameter and for referencing the parameter in the body of the method. Unfortunately another variable with the different case is also accessible. The VB code and the converted C# code both compile but return different results. Incidentally, the VB editor will work very hard to prevent you writing this code! However it does illustrate the kind of thing that can go wrong and similar issues can arise in less contrived cases.

C# is more strict than VB which causes errors in conversion. In most cases this is not a bad thing, but can cause headaches. For example, VB will let you pass object members ByRef but C# will not. In fact, VB will let you pass anything ByRef, even literal values, which is a puzzle! So this compiles and runs:

image

Another example is that in VB you can use an existing variable as the iteration variable, but in C# foreach you cannot.

Collections often go wrong. In VB you use an Item property to access the members of a collection like a DataReader. In C# this is omitted, but the converter does not pick this up.

Overloading sometimes goes wrong. The converter does not always successfully convert overloaded methods. Sometimes parameters get stripped away and a spurious new modifier is added.

Bitwise operators are not correctly converted.

VB allows indexed properties and properties with parameters. C# does not. The converter simply strips out the parameters so you need to fix this by hand. See https://stackoverflow.com/questions/2806894/why-c-sharp-doesnt-implement-indexed-properties if the language choices interest you.

There is more, but the above gives some idea about why this kind of conversion may not be straightforward.

It is probably true that the higher the standard of coding in the original project, the more straightforward the conversion is likely to be, the caveat being that more advanced language features are perhaps more likely to go wrong.

Null strings behave differently

Another oddity is that VB treats a String set to null (Nothing) as equivalent to an empty string:

Dim s As String = Nothing

If (s = String.Empty) Then ‘TRUE in VB
     MsgBox(“TRUE!”)
End If

C# does not:

String s = null;

   if (s == String.Empty) //FALSE in C#
    {
        //won’t run
    }

Same code, different result, which can have unfortunate consequences.

Worth it?

So is it worth it? It depends on the rationale. If you do not need cross-platform, it is doubtful. The VB code will continue to work fine, and you can always add C# projects to a VB solution if you want to write most new code in C#.

If you do need to move outside Windows though, conversion is worthwhile, and automated conversion will save you a ton of manual work even if you have to fix up some errors.

There are two things to bear in mind though.

First, have lots of unit tests. Strange things can happen when you port from one language to another. Porting a project well covered by tests is much safer.

Second, be prepared for lots of refactoring after the conversion. Aim to get rid of the Microsoft.VisualBasic dependency, and use the stricter standards of C# as an opportunity to improve the code.

SQLite adds support for .NET Core 2.0 and .NET Standard 2.0

image

The open source SQLite database engine goes from strength to strength, largely by not changing that much: it remains small, fast, reliable, cross-platform, and completely free. The engine is written in C but there are many wrappers for different languages, a recent addition being .NET Core 2.0 and .NET Standard 2.0:

1.0.109.0: Add preliminary support for .NET Core 2.0 and the .NET Standard 2.0. Pursuant to [5c89cecd1b].

.NET developers using SQLite are fortunate in that System.Data.SQLite, the .NET provider, is supported by the SQLite team and has its own sub-site on sqlite.org. “The SQLite team is committed to supporting System.Data.SQLite long-term,” states the home page.

The addition of .NET Core 2.0 support is valuable, in part because .NET Core is where Microsoft’s energy is now focused, and will make it easier to write cross-platform code. There is a snag though: there is no official cross-platform GUI for .NET Core, which would be useful for SQLite given that it is a local database engine. However, Microsoft’s Xamarin framework, which is cross-platform, does support .NET Standard 2.0 so this should work though I have not tried it.

The truth is that almost any framework can be made to work with SQLite. I did some work myself on a wrapper for Delphi (Object Pascal) which still has some users today.

Back in 2007 I interviewed SQLite’s creator, Dr Richard Hipp, for Guardian Technology. Worth a read if you are wondering why SQLite, unlike most open source projects, has no licence: it is simply public domain:

“I looked at all of the licences,” Hipp says, “and I thought, why not just put it in the public domain? Why have these restrictions on it? I never expected to make one penny. I just wanted to make it available to other people to solve their problem.”

Google announces Cloud Build: CI/CD for the Google Cloud Platform

Google Cloud Next is under way in San Francisco, and yesterday saw the announcement of Cloud Build, Continuous Integration and Continuous Deployment for the Google Cloud Platform.

image

Cloud Build runs a series of automated build steps and then optionally pushes built images to Googles container registry. It is a natural fit with Kubernetes but can be used with both containerised and direct deployments.

You can create your own build steps or use a prebuilt one. The prebuilt steps are:

  • bazel: runs the bazel tool
  • curl: runs the curl tool
  • docker: runs the docker tool
  • dotnet: run the dotnet tool
  • gcloud: runs the gcloud tool
  • git: runs the git tool
  • go: runs the go tool
  • gradle: runs the gradle tool
  • gsutil: runs the gsutil tool
  • kubectl: runs the kubectl tool
  • mvn: runs the maven tool
  • npm: runs the npm tool
  • wget: runs the wget tool
  • yarn: runs the yarn tool

Note that dotnet is in there so you can use this immediately with .NET Core.

There is also an option to  build locally. For example, you could build locally and only after a successful local build, invoke Cloud Build.

Cloud Build integrates with GitHub:

With this new integration, you can easily set up CI through Cloud Build and automate builds and tests as part of your GitHub workflow.

I doubt Google celebrated when Microsoft acquired GitHub but it is good to see GitHub continuing to support diverse platforms.

Overall this is an important feature as Google races to extend its cloud platform to match what is on offer from its key competitors, AWS and Microsoft Azure.

Gartner on Mobile App Development Platforms: Kony, Mendix, Microsoft, Oracle and Outsystems the winners

Gartner has published a paper and Magic Quadrant on Mobile App Development Platforms (MDAPs), which you can read for free thanks to Progress, pleased to be named as a “Visionary”, and probably from other sources.

According to Gartner, an MDAP has three key characteristics:

  • Cross-platform front-end development tools
  • Back-end services that can be used by diverse clients, not just the vendor’s proprietary tools.
  • Flexibility to support public and internal deployments

Five vendors ranked in the sought-after “Leaders” category. These are:

  • Kony, which offers Kony Visualizer for building clients, Kony Fabric for back-end services, and Kony Nitro Engine, a kind of cross-platform runtime based on Apache Cordova .
  • Mendix, which has visual development and modeling tools and multi-cloud, containerised deployment of back-end services
  • Microsoft, which has Xamarin cross-platform development, Azure cloud services, and PowerApps for low-code development
  • Oracle, which has Oracle Mobile Cloud Enterprise including JavaScript Extension Toolkit and deployment via Apache Cordova
  • Outsystems, a low-code platform which has the Silk UI Framework and a visual modeling language, and hybrid deployment via Apache Cordova

Of course there are plenty of other vendors covered in the report. Further, because this is about end-to-end platforms, some strong cross-platform development tools do not feature at all.

A few observations. One is the prominence of Apache Cordova in these platforms. Personally I have lost enthusiasm for Cordova, now that there are several other options (such as Xamarin or Flutter) for building native code apps, which I feel deliver a better user experience, other things being equal (which they never are).

With regard to Microsoft, Gartner notes the disconnect between PowerApps and Xamarin, different approaches to application development which have little in common other than that both can be used with Azure back-end services.

image
Microsoft PowerApps

I found the report helpful for its insight into which MDAP vendors are successfully pitching their platform to enterprise customers. What it lacks is much sense of which platforms offer the best developer experience, or the best technical capability when it comes to solving those unexpected problems that inevitably crop up in the middle of your development effort and take a disproportionate amount of time and effort to solve.

RemObjects Elements: mix and match languages and platforms as you like

The world of software development has changed profoundly in the last decade or so. Once it was a matter of mainly desktop Windows development for the client, mainly Java for server-based applications with web or Windows clients. Then came mobile and cloud – the iPhone SDK was released in March 2008, kicking off a new wave of mobile applications, while Amazon EC2 (Elastic Compute Cloud) came out of beta in October 2008. Microsoft tussled within itself about what to do with Windows Mobile and ended up ceding the entire market to Android and iOS.

The consequence of these changes is that business developers who once happily developed Windows desktop applications have had to diversify, as their customers demand applications for mobile and web as well. The PC market has not gone away, so there has been growing interest in both cross-platform development and in how to port Windows code to other platforms.

Embarcadero took Delphi, a favourite development tool based on an Object Pascal compiler, down a cross-platform path but not to the satisfaction of all Delphi developers, some of whom looked for other ways to transition to the new world.

Founded in 2002, RemObjects had a project called Chrome, which compiled Delphi’s Object Pascal to .NET executables. This product was later rebranded Oxygene. For a while Embarcadero bundled a version of this with Delphi, calling it Prism, after abandoning its own .NET compilation tools.

The partnership with Embarcadero ended, but RemObjects pressed on, adding language features to its flavour of Object Pascal and adding support for Mac OS X, iPhone and Java.

In February 2015 the company was an early adopter of Apple’s Swift language, introducing a Swift compiler called Silver that targets Android, .NET and native Mac OS X executables.

The company now offers a remarkable set of products for developers who want to target new platforms but in a familiar language:

  • Oxygene: Object Pascal
  • Silver: Swift 3 (and most of Swift 4)
  • Hydrogene: C# 7
  • Iodine: Java 8

Each language can import APIs from the others, and compile to all the platforms – well, there are exceptions, but this is the general approach.

More precisely, RemObjects defines four target platforms:

  • Echoes: .NET and .NET Core including ASP.NET and Mono
  • Cooper: Java and Android
  • Toffee: Mac, iOS, tvOS
  • Island: CPU native and WebAssembly

So if you fancy writing a WPF (Windows Presentation Foundation) application in Java, you can:

image

As you may spot from the above screenshot, the RemObjects tools use Visual Studio as the IDE. This is a limitation for Mac developers, so the company also developed a Mac IDE called Fire, and now a Windows IDE called Water (in preview) for those who dislike the Visual Studio dependency.

image

Important to note: RemObjects does not address the problem of cross-platform user interfaces. In this respect it is similar to the approach taken by Xamarin before that company came up with the idea of Xamarin Forms. So this is about sharing non-visual code and libraries, not cross-platform GUI (Graphical User Interface). If you are targeting Cocoa, you can use Apple’s Interface Builder to design your user interface, for example.

Of course WebAssembly and HTML is an interesting option in this respect.

A notable absentee from the list of RemObjects targets is UWP (Universal Windows Platform), a shame given the importance Microsoft still attaches to this.

RemObjects is mainly focused  on languages and compilers rather than libraries and frameworks. The idea is that you use the existing libraries and frameworks that are native to the platform you are targeting. This is a smart approach for a small company that does not wish to reinvent the wheel.

That said, there is a separate product called Data Abstract which is a multi-tier database framework.

These are interesting products, but as a journalists I have struggled to give them much coverage, because of their specialist nature and also the demands on my time as someone who prefers to try things out rather than simply relay news from press releases. I also appreciate that the above information is sketchy and encourage you to check out the website if these tools pique your interest.

Embarcadero launches free Community Edition of Delphi and C++Builder for mainly non-commercial use

A new Community Edition of Delphi and C++Builder, visual development tools for Windows, Mac, Android and iOS, has been released by Embarcadero.

image

The tools are licensed for non-commercial use or for commercial use (for up to 5 developers) where revenue is less than $5000 per year. It is not totally clear to me, but I believe this means the total revenue (or for non-profits, donations) of the individual or organisation, not just the revenue generated by Community Edition applications. From the EULA:

The Community Edition license applies solely if Licensee cumulative annual revenue (of the for-profit organization, the government entity or the individual developer) or any donations (of the non-profit organization) does not exceed USD $5,000.00 (or the equivalent in other currencies) (the “Threshold”). If Licensee is an individual developer, the revenue of all contract work performed by developer in one calendar year may not exceed the Threshold (whether or not the Community Edition is used for all projects).

Otherwise, the Community Editions are broadly similar to the Professional Editions of these tools. Note that even the Professional Edition lacks database drivers other than for local or embedded databases so this is a key differentiator in favour of the Architect or Enterprise editions.

An annoyance is that you cannot install both Delphi and C++ Builder Community Editions on the same PC. For this you need RAD Studio which has no Community Edition.

Delphi and C++ Builder are amazing tools for Windows desktop development, with a compiler that generates fast native code. For cross-platform there is more competition, not least from Microsoft’s Xamarin tools, but the ability to share code across multiple platforms has a powerful attraction.

Get Delphi Community Edition here and C++Builder Community Edition here.