I was speaking recently to a colleague of mine over at White Peak Software in Salem, Mass., who has witnessed firsthand a recent resurgence in demand for software development services to specifically create native (compiled) 32-bit executables for Windows (as opposed to the newer DotNet 1.1/2.0 technologies).
It seems there are a variety of reasons for this recent rebound in native-code development, including:
- Removal of programmatic dependencies. On the contrary, if using DotNet for development, you automatically are dependent on the DotNet Framework, and therefore must count on all machines having that framework installed -- which isn't a good assumption. Likewise with Java development that many times assumes the latest JRE (Java Runtime Environment) or some Java Swing Libraries, and so on are available on all computers running the application.
- Simplicity of deployment. The beauty of a single-file Executable (EXE) is hard to match, given that if the EXE has any and all dependencies compiled right into the EXE, there is nothing else to be deployed. So, one file to deploy. End of story.
- Simplified upgrades. Your code is much less likely to be "broken" (or otherwise rendered incompatible) by upgrades to frameworks, runtime libraries, DLLs, and the likes. And, if my executable changes, I have even found that even non-technical users can quickly deal with just replacing one EXE with another (heck, it is just a file!) if I Email them an update.
- Raw processing speed and small memory footprint. Keep in mind that if a DotNet or Java application appears to be quite small, don't discount the fact that behind the scenes that 500K "program" is also making use of a 20+MB framework that is loaded into memory! Suddenly those "lightweight" applications do not appear so lightweight when compared to a 1MB EXE that is just 1MB total - no framework dependencies.
Here are some of the things Kirby Turner, the CEO of White Peak Software, had to say about recent demand for Win32 EXE development, and how he has used Borland Delphi 2006 to solve customer demands and deliver top-notch native, compiled software to his clients:
"I’ve been doing non-stop Delphi programming for the last week [...] and, [CompanyName] isn’t the only Delphi customer work I’m doing. I just finished a small Delphi application for a Philladelphia customer, and I should hear by week’s end about another Delphi project. The trend in the last month has been the need for data import / data generation programs where the customer doesn’t want any outside dependencies in the program, i.e., no .NET Framework.
The call I had on Monday was probably the best. The customer said, “I’m sure you want to do this program using the latest .NET Framework, but I can’t guarantee the end user will have it installed. It’s unlikely .NET Framework 1.1 is even installed.” My response was, “Actually, for this type of program I prefer to write it as a native Win32 application. I can deliver a single EXE that will run on any Windows platform from Windows 98SE and up, and it does not require any additional installs or frameworks. In other words, no .NET Framework.” The customer got very excited.
I’m starting to sense that customers want native Win32 applications, but are:
- afraid to ask for it;
- believe it’s not possible any more;
- and, if it is possible, then it will cost a lot of money.
Yes Kirby, I agree, we need to know whether this is more than a short term trend, and market accordingly. But, I believe that marketing the advantages of a natively compiled Windows Executable (developed with Borland Delphi or other RAD environment that supports native application output) can create a "trend" in itself. I have seen the situation so many times where software developers and software development managers fall victim to trying to fit the "latest and greatest" technology (like DotNet) to every new project they have, whether it makes sense or not. So, the advantages of Native Executables must somehow be marketed to those in charge of software development projects in such a manner to counter the prevailing market forces (like, the massive Microsoft push for DotNet-only solutions).
Regardless, this recent demand for Win32 EXE development gives me hope that not everyone is falling victim to the hype surrounding DotNet and other framework-dependent and runtime-library dependent development methodologies. Sometimes "older" or "outdated" ways of doing things can still be the right way!