Protect .NET source code by obfuscating it?

[cyberjoe2]

Hi,

I'm looking for a tool that can be utilized by daily build to encode our assemblies.

It should prevent of decoding our code by disassemblers.

I need something like: http://www.smartassembly.com/product/how4.aspx

Is this the best we can have?

cyberjoe2

[jcarle]

I wouldn't bother... if someone REALLY wants to disassemble your code, they will. Obfuscated or not.

[CoffeeFiend]

Well, I wouldn't go as far as saying "don't bother".

But then again, people have been saying the same about the countless "unbreakable" exe-wrappers/encrypters. Does that mean one shouldn't bother at all? Not necessarily. You could say the same about every other software protection of any kind too (serials, online/phone activation, HASPs, etc), and even all forms of DRM, as someone who knows enough and who's determined enough can, and WILL break it.

You could extend that analogy to padlocks and deadbolts too. They'll keep the average person from walking away with your stuff as they were passing by, but it won't stop anybody who really wants to. Does that mean one shouldn't bother with locks of any kind? (no padlock at the gym, no deadbolts on the house, no keys needed for your car, your bank not using safes, etc)? I don't think something not being perfect is a reason to not use it. Being reasonably good is often all that's needed.

Locks don't stop thieves, they just keep the honest people honest. If people don't do anything at all to protect their software, you know NOBODY will pay for it, they'll just copy it (pirates will pirate it regardless). Combine that with advantages for people who pay, like support and various perks (could be anything - extras/samples/newsletters/whatever with useful content, cheap upgrades, chance to win something, listening to their feature requests, etc) and perhaps annoyances for those who don't (have to disable auto update, must block with firewall, find crack for every new weekly build - half of which fail hidden checks, etc), and some people will pay. Locks and protection/obfuscation aren't ironclad, but I still use 'em.

Anyways, he can make his own choice. And there are lots of obfuscating products to choose from:

-Dotfuscator

-Salamander .NET obfuscator

-9Rays.NET / Spices.Obfuscator

-Aspose.Obfuscator

-CodeVeil (obfuscation and encryption)

-Demeanor for .NET

-dotNet Protector

-Dynu .NET obfuscator

-CliSecure

-Xenocode Postbuild

-Deploy.NET (encryption - not obfuscation)

-LSW-IL-Obfuscator

-Skater .NET Obfuscator

-{smartassembly}

And most likely others...

Combined with other methods/techniques if used properly (like signing and such), it can make a pretty decent protection.

As for {smartassembly}, I've never used it, so no idea.

[jcarle]

True enough.

The thing is, if the person is skilled enough to disassemble, wouldn't you imagine they'd be skilled enough to work around obfuscators?

[LLXX]

You can obfuscate it but that will only make an already inefficient program even more so.

Why bother protecting code that no one will want?

There are better things on the non-.NET side. Including better software protections.

[CoffeeFiend]

True enough.

The thing is, if the person is skilled enough to disassemble, wouldn't you imagine they'd be skilled enough to work around obfuscators?

Not necessarily. MSIL is pretty simple (basic assembly is, too). So it depends on the obfuscator and what it does - some have pretty good tricks up their sleeve. But then again, I don't use an obfuscator alone either (signatures, asymmetric encryption, DPAPI, etc). You could always NGEN your stuff too. I don't want my code to be easily read (like an open book) by ILDASM.

But most of these programming related questions are better answered on relevant newsgroups. There has been much talk about all this, many many times unsurprisingly, often involving some very intelligent people (many MVPs, experts, book writers, etc). Most people asking programming questions here ought to try newsgroups instead (I don't even look in the "programming" section anymore)

And as I expected, the usual anti-.NET troll showed up, with his usual FUD. Obfuscating hardly makes any difference in performance (can you back that? didn't think so). And who said it's inefficient in the first place? (oh yeah, you're a anti-.net troll - everything in anything else than asm or C++ is inefficient). And there's tons of people who do want apps, which often require the .net framework (e.g. nlite). Enough FUD already, quit your jihad, no one cares about what you think about .NET. Don't like it? Don't use it.

[jcarle]

You know, I don't understand what people's gripes are with .NET.

I don't like .NET applications because they require the .NET framework...

which is akin to the logic

I don't like VB6 applications because they require the VB runtimes...

which is akin to the logic

I don't like Windows applications because they require access to Win32 APIs.

You might as well just end with,

I don't like Windows.

.NET is the next generation of programming on the windows platform. It's very similar to Java, holds some of the similar roots, but it's funny, no one complained because it was a Sun product. So just because it's MS, it's bad? I just don't get it.

[Tarun]

A lot of complaints on .NET is because of the "bloated Framework".

[CoffeeFiend]

You might as well just end with,

I don't like Windows.

Yeah, that's what it seems to come down to.

A lot of complaints on .NET is because of the "bloated Framework".

Problem is, people don't seemingly know what the .NET framework is. Yeah, it uses HD space. The .NET framework 2.0 uses 150MB - which is a whole nickel worth of HD space at today's prices (some people sure make a very big deal out of 5 cents worth of storage). The space is used by common libs/classes/whatever so not every app has to replicate them, using more space in the end. And if you look at what you're getting, you'll see it's not exactly that big - there's other stuff "left there" - like the .NET framework installer itself (Microsoft .NET Framework 2.0\netfx.msi) - 25mb for that, and 7mb for the J# 2.0 Redist installer. It gets blamed for the space it takes partly because it doesn't "hide" its installer files like most other apps under C:\windows\Installer (a folder that's over 500MB on the box I'm writing this from). So we're already down to like 118mb for the framework itself. And out of that, you're getting a LOT of things:

-several full compilers (csc for C#, vbc for VB, vjc for J# and jsc for JScript.NET, + the MS IL assembler and JIT) & accompanying dev tools and environment (MSBuild, etc) - how much space would that normall take using other companies' compilers? Yeah, a whole LOT more.

-everything to have ASP.NET and Web Services working on your IIS server (to install everything, register stuff, handle page rendering/requests, compile them, http modules, etc)

-everything that's needed to hookup to a database like SQL server (for several purposes)

-a testing web server (WebDev.WebServer.exe)

-security tools (like CasPol) and a web based authorization manager (AzMan front end)

and many more things - along with the part that people seem to think that the .NET framework is (the CLR part) - a bit like the JRE runtime, which provides tons of rich, standard, consistent, well designed classes that perform quite well, garbage collection (mind you most people don't seemingly understand what that means). Classes for threading, IO, database access (ADO.NET, SqlClient, etc) and transactions, for WMI and performance counters, for localization of apps, for networking, remoting, crypto work of all kinds, directory services, mail, GDI+, messenging, caching, enterprise services, interop, RegExp, XML, etc - and all this via different programming languages.

So it's not like you're only getting minor functionality that should fit in 5MB of DLLs.

.NET is the next generation of programming on the windows platform.

That sentence sums it up nicely. The adoption rate of .NET is very high, unsurprisingly. It's what MS are pushing [very hard] as next generation dev platform, and their dev tools, documentation and all reflect this. Lots of the nice and new technologies are .NET only (like WPF a.k.a Avalon). Vista is a step towards that too. Those who don't want of .NET are better migrating off windows ASAP [to whatever OS they please], because it's definitely here to stay.

[LLXX]

Obfuscating hardly makes any difference in performance (can you back that? didn't think so).

That should be a self-evident truth. The essence of obfuscation is to obscure the intent of the code by changing its flow (add jump instructions to delinearise sequential blocks), introducing extra code that does nothing ("garbage code"), or converting basic operations to equivalent series of instructions that require more operations, which goes as far as implementing another virtual machine.

What takes more instructions, x+1 or x+60-65535+65596 ?

everything in anything else than asm or C++ is inefficient

Analysis of the current "best"-in-efficiency software reveals absolute efficiencies of approximately 12-20%.

By merely changing a few compiler options, in MSVC for example, that can be improved into the 70-80% range. ("Hello World!" messagebox compiled with MSVC6 default settings: 40Kb; same source, same compiler, different settings: 1Kb | for comparison, the same function in unopt'd Asm: 1Kb )

It can thus be demonstrated that C/C++ can approach the efficiency of "normal" unoptimised Asm, but only via two conditions - [1] the compiler is set to generate the most efficient output, and [2] the programmer takes care in writing the source. The first point is trivial to satisfy, and I am indeed very surprised, by the number of programmers that never neglected to take notice or by M$ which seems intent on making the compiler produce the worst output I'm not sure of which.

The second point is a little more difficult to satisfy, but by taking care to remove duplicated code and use methods which increase efficiency (such as HeapAlloc()'ing instead of putting the entire 256 thousand zero bytes into the executable) it is not that hard after all.

You know, I don't understand what people's gripes are with .NET.

I don't like .NET applications because they require the .NET framework...

which is akin to the logic

I don't like VB6 applications because they require the VB runtimes...

which is akin to the logic

I don't like Windows applications because they require access to Win32 APIs.

You might as well just end with,

I don't like Windows.

.NET is the next generation of programming on the windows platform. It's very similar to Java, holds some of the similar roots, but it's funny, no one complained because it was a Sun product. So just because it's MS, it's bad? I just don't get it.

No, plenty complained about Java. In fact I'd sooner install .NET than Java, then strip out everything I don't need than the basic runtimes.

Java was developed to fill a specific niche requiring portability across different platforms, and indeed it has done so. Sun hasn't been pushing Java for everything though, and it remains successfully used on platforms that are hard to standardise (phones, PDAs, etc.)

Why don't we like the .NET framework? One reason, is because most of it's just plain useless to the end-user.

And out of that, you're getting a LOT of things:

-several full compilers (csc for C#, vbc for VB, vjc for J# and jsc for JScript.NET, + the MS IL assembler and JIT) & accompanying dev tools and environment (MSBuild, etc) - how much space would that normall take using other companies' compilers? Yeah, a whole LOT more.

-everything to have ASP.NET and Web Services working on your IIS server (to install everything, register stuff, handle page rendering/requests, compile them, http modules, etc)

-everything that's needed to hookup to a database like SQL server (for several purposes)

-a testing web server (WebDev.WebServer.exe)

-security tools (like CasPol) and a web based authorization manager (AzMan front end)

The end-user doesn't care that it comes with compilers. The end-user doesn't write programs (did M$ intend them to? I don't think so.) The end-user doesn't need all of that.

.NET sounds like a good concept in theory, and like you said, having all those standard classes is great, but the way they implemented it just fails.

.NET is the next generation of programming on the windows platform.

It may be, but I'm certainly not going along with it without some serious consideration of the implications of doing so. It's just a way for M$ to coerce the mindless lusers to upgrade to new hardware.

HDD space is cheap, so what? Just because we have exabytes of storage available doesn't mean the software has to expand to fill it! More space should mean we can store more data and software, not store the same amount of bigger less efficient software. Do more with less, not less with more.

[jcarle]

Why don't we like the .NET framework? One reason, is because most of it's just plain useless to the end-user.

I'd really love to hear how you gather that development platform is useless to the end-user when the end-user has NOTHING to do with the development platform?

All programs, wether coded in ASM, C++, Delphi, VB, .NET, all have the same output. They present the user with a Windows UI to do whatever it's tasks are. The end-user has no knowledge, no understanding and no desire to know wether the application was coded in C++ or VB. The only thing the user cares about is to be able to install it and use it.

As I'm sure you know, I've coded several utilities which have been very successful and popular on MSFN. Windows Updates Downloader alone, since the start of it's existance, has been downloaded over 500,000 from it's homepage. That doesn't even include all the numerous large websites that have decided to host copies of the installers themselves (Softopedia comes to mind). So where is the uselessness there?

WUD and the WMP11 Integrator I wrote are both small, lightweight .NET applications that look and act no different then any other Windows application coded in various other applications. Nothing that the end-user could notice.

Yes, the .NET development platform can be quite a headache to come to understand and learn to work in. I'm particularily rather hating the DataGridView at the moment. But like most new languages, it takes time for the dust to settle, time for it to mature, and time to learn. I code leaps better now in C# then I did when I first started a couple of years back. There's concepts now that I get that I couldn't even get my head around back them because they seemed so foreign with .NET. All that's changed and the platform keeps getting better, faster and more efficient. Generics come to mind for one.

All and all, I don't really see the difference between a .NET application and one that uses strictly Win API calls. It's all in the way you write your application. Best example, you can use Data Bindings to bind your database to various form objects OR you can get down with the gritty and write your own data population function to load those form objects with data from the database. In the end, it comes back to the developer to make those choices. The end user has no control over the developer.

[CoffeeFiend]

That should be a self-evident truth. The essence of obfuscation is to obscure the intent of the code by changing its flow

It's not quite self-evident at all - much the inverse! Self evident that it doesn't. Goes to show how little you know about obout obfuscating. Basic obfuscating is mainly about renaming stuff (does not affect performace at all). More complex obfuscating has no more effect on performance than the average exe packer or such - basically none. When I say "evidence", I mean things like benchmarks that back those false claims (you won't find any, because it's just not true).

It can thus be demonstrated that C/C++ can approach the efficiency of "normal" unoptimised Asm

Says the guy who brags about his "uber-optimized" 1337 MD5 code in asm. Yeah, it performs far better hashing MD5 in memory than a 10 year old intepreted language that's unsuited to the task does from disk.

Hate to break it to you, but you probably shouldn't be writing assembler, and leave it to the pros. Yeah, everyone and their dog can write asm up to the MMX level. But past that, it takes real skill, knowledge, experience and all - things like using SIMD instructions, ordering instructions (makes a real difference in today's CPUs), keeping the pipelines full, preventing cache misses, etc. This is better leaved at people who do this for a living. Otherwise, you end up with something that's in fact SLOWER than it would have been using a C/C++ compiler - or just about anything else, because most compilers nowadays are FAR better than the average wannabe asm hacker at most things.

350MB/s on a P4 4.1GHz is not something I'd brag about. The way you're talking, this should be quite a bit faster than C/C++ implementations - it's written in asm to be faster than C/C++, and it's "highly optimized".

Too bad it loses against .NET. The default .NET MD5CryptoServiceProvider (and you always whine about how inefficient .NET is) beats that hands down! Repeatedly 370MB/s+ on my P4 3GHz (example source code on request). The default Java ways are also faster (and especially implementations like this one). Too bad it also loses to the libraries like Crypto++ too (written in C++).

The point being, likely, you shouldn't be writing asm anymore. Every compiler out there seem to be better at it than you (well, except VB6, but I wouldn't brag about that). And the cryptography classes on higher-level languages are writen by expert and perform quite well.Sure, you can still write code that makes smaller executables, but that hardly matters at all (I sure don't give a F about a few KB of disk space), and perhaps a couple MBs of memory usage than higher level languages, but it's hardly an issue anymore. We're not running 486's with 4MB RAM where saving every byte one could was required. Performance of computationally intensive parts is important though (and your code fails at this).

There's no point in having to write your own libs in asm, hand optimizing them, bug fixing them, maintaining them and all (taking lots of hours, costing lots of $ in the processs, etc), if all they accomplish is be slower, waste time, cost money and is platform-specific. And even if performance was ~10% better in the first place (it ISN'T), it would still make hardly any difference in most apps - 10% of the time your PC is hashing, but it won't help one bit for the other 90% of the time where it's wating for the HD, so your real gains in overall speed would be like 1%. There's no point in over optimizing something if there's no significant difference (something about profiling code, and optimizing what actually needs it)

Java was developed to fill a specific niche requiring portability across different platforms, and indeed it has done so. Sun hasn't been pushing Java for everything though, and it remains successfully used on platforms that are hard to standardise (phones, PDAs, etc.)

Java wasn't developped solely for portability. It was one goal (which they have achieved like you said), but you're willingly ignoring everything else. And they ARE pushing java for absolutely everything - for end user apps, for server middleware, for embedded devices, the dreaded applets, etc - far more than Microsoft is!

It's just a way for M$ to coerce the mindless lusers to upgrade to new hardware.

FUD as always. There's no need to upgrade hardware for anything. If your PC can handle a modern version of windows (like win2k), it can handle .NET apps just fine. Unless you mean it'll force lusers to throw away their P2 400, but arguably that's a good thing. This is patently false.

That's just like saying they just create a new version of windows to force people to buy new PCs - just too bad they don't see a penny from hardware sales. People have been whining about this for ages. The whine about how "Vista is bloated" is just this years' version. People said the same about every version of windows that ever came out. Win95 worked fine on my 3600$ P133 back then, on 486's, it wasn't nearly as fast, and on 386's (which LOTS of people still had), it was a bad joke. New software with new features doesn't run great on outdated hardware. But people quickly forget. Now that they have today's high-end software running on an OS that's like 6 years old (XP), it seems pretty fast.

Your point is just as false as the bit about "being useless" that jcarle refuted. Explain how WUD, nLite, Paint.NET and countless others apps really force people to update. Or perhaps you meant that "mindless lusers" will upgrade (even if they don't need to)?

HDD space is cheap, so what? Just because we have exabytes of storage available doesn't mean the software has to expand to fill it! Do more with less, not less with more.

You're talking like it's taking every extra bit of HD space we're getting nowadays. It doesn't exactly expand to fill it. You're talking like it's using 100GB out of a 200GB HD. The point is, space is cheap enough that using the required and reasonable space for new features is not a big concern anymore. We do more apps with less code, more apps with less time, more features with less time, and more apps with less costs - that matters FAR more than a hundred MBs of disk space nowadays. There's just no need to have MS word work on the same resources as edlin did though.

Edited December 9, 2006 by crahak

[LLXX]

It's not quite self-evident at all - much the inverse! Self evident that it doesn't. Goes to show how little you know about obout obfuscating. Basic obfuscating is mainly about renaming stuff (does not affect performace at all). More complex obfuscating has no more effect on performance than the average exe packer or such - basically none. When I say "evidence", I mean things like benchmarks that back those false claims (you won't find any, because it's just not true).

We do not consider renaming a method of obfuscation.

Evidence? Just apply an obfuscator that actually obfuscates to any .NET program you have and watch what happens to its size both on-disk and in-memory. Does it take less time to execute more instructions?

because most compilers nowadays are FAR better than the average wannabe asm hacker at most things.

Perhaps you've never taken a look at the output of an "optimizing" compiler. Sure, it does know a few tricks - after all, compiler writers do know Asm, but most of the time it's just performing a deterministic transformation of the source, based on fixed patterns.

350MB/s on a P4 4.1GHz is not something I'd brag about. The way you're talking, this should be quite a bit faster than C/C++ implementations - it's written in asm to be faster than C/C++, and it's "highly optimized".

Too bad it loses against .NET. The default .NET MD5CryptoServiceProvider (and you always whine about how inefficient .NET is) beats that hands down! Repeatedly 370MB/s+ on my P4 3GHz (example source code on request). The default Java ways are also faster (and especially implementations like this one). Too bad it also loses to the libraries like Crypto++ too (written in C++).

...and your P4 probably isn't the same as my P4. Clock speed isn't everything. A Core2 at 2GHz would probably outperform both of those. Also, the Crypto++ MD5 routine binary is identical to the MD5 code I have, only the source is represented in C++.

The point being, likely, you shouldn't be writing asm anymore. Every compiler out there seem to be better at it than you (well, except VB6, but I wouldn't brag about that). And the cryptography classes on higher-level languages are writen by expert and perform quite well.Sure, you can still write code that makes smaller executables, but that hardly matters at all (I sure don't give a F about a few KB of disk space), and perhaps a couple MBs of memory usage than higher level languages, but it's hardly an issue anymore. We're not running 486's with 4MB RAM where saving every byte one could was required. Performance of computationally intensive parts is important though (and your code fails at this).

There's no point in having to write your own libs in asm, hand optimizing them, bug fixing them, maintaining them and all (taking lots of hours, costing lots of $ in the processs, etc), if all they accomplish is be slower, waste time, cost money and is platform-specific. And even if performance was ~10% better in the first place (it ISN'T), it would still make hardly any difference in most apps - 10% of the time your PC is hashing, but it won't help one bit for the other 90% of the time where it's wating for the HD, so your real gains in overall speed would be like 1%. There's no point in over optimizing something if there's no significant difference (something about profiling code, and optimizing what actually needs it)

I don't start writing in Asm unless it's a very small program. I start with C to establish the initial design, then gradually convert portions to Asm where the compiler didn't do as good of a job translating the source as it should've.

That's just like saying they just create a new version of windows to force people to buy new PCs - just too bad they don't see a penny from hardware sales.

But on the other hand, the hardware industry coming out with faster hardware does help the software companies to sell their software. If it weren't for the huge amounts of storage and ultrafast processors being available to the general public, I doubt that software would've become what it is today.

Or perhaps you meant that "mindless lusers" will upgrade (even if they don't need to)?

"I want Vista because it's the newest OS and I want the fastest computer so I can run it..."

The point is, space is cheap enough that using the required and reasonable space for new features is not a big concern anymore.

Emphasis on "required and reasonable". Software with more features should take up more space, that much is logical. But, just how much of an increase is warranted is questionable.

We do more apps with less code, more apps with less time, more features with less time, and more apps with less costs - that matters FAR more than a hundred MBs of disk space nowadays.

Have you ever thought about the fact that more time should be spent using those apps than creating them? Or, in other words, is all you care about money

There's just no need to have MS word work on the same resources as edlin did though.

Nor could it ever do so, but there is definitely room for improvement.

[CoffeeFiend]

We do not consider renaming a method of obfuscation.

"We" as in "you". Seemingly you don't consider obfuscators as obfuscators... Or perhaps you don't understand what they do or how they work? Entity renaming is the very base of what obfuscators do (they ALL do this!) - renaming namespaces/classes/methods/properties/fields/enums (the metadata). Much harder to understand this way already, especially if it's not easily readable (just numbers, or using weird unicode chars; lots of identical/duplicate names where possible, etc; and if it confuses and crashes ILDASM, then that's a bonus). There are obfuscators out there that do basically just that.

Evidence? Just apply an obfuscator that actually obfuscates to any .NET program you have and watch what happens to its size both on-disk and in-memory. Does it take less time to execute more instructions?

Again, sidestepping the benchmark part, because it does NOT make any noticeable different AT ALL, just like the average exe packer (actually, the average exe packer is has way more impact, but do we see people complain about that? Heck, it made no noticeable difference on a 286). The ONLY thing that's different is the MS IL, which perhaps makes a ~1% difference on disk size (not relevant, might just fill a bit more of the empty part of the last cluster it uses). Memory/CPU usage wise, it makes NO DIFFERENCE AT ALL once it's JIT'ed (100% identical output) - and again, the JIT doesn't care if it's human readable names or not. Do a quick test, you'll see it changes nothing. Again, if it's so obvious, you'll surely find benchmarks saying how slow it makes it, or you'll easily be capable to produce some. My FUD meter is reading off the scale...

Perhaps you've never taken a look at the output of an "optimizing" compiler. Sure, it does know a few tricks - after all, compiler writers do know Asm, but most of the time it's just performing a deterministic transformation of the source, based on fixed patterns.

Perhaps it's more like you don't know the tricks modern compilers can do (branch optimizations, instruction scheduling, etc). And yes, I do use optimizing compilers (used GCC and IAR tonite alone, for C code, imagine that, and I also look at the generated code, and there's also an asm part - not x86 code, but the concepts are the same, and I know x86 decently well too).

...and your P4 probably isn't the same as my P4

My P4 is a ghetto 519J with slow FSB and ghetto HP "Goldfish" motherboard (onboard video/audio/ethernet and all), paired with high latency slow RAM, no HT or anything like that (and the thing's running so much stuff at once/and in the background, you wouldn't believe it). There's nothing exceptional about this system. If you have a 4.1GHz P4, it's definitely far better than this one (unless it's a half core or something).

"I want Vista because it's the newest OS and I want the fastest computer so I can run it..." whistling.gif

More like "I want the latest OS with all the new features and cool stuff" or are they supposed to say "I want some ghetto old OS and the slowest hardware I can find"? The newer OS'es have all kinds of new and useful stuff, and I don't see why people wouldn't want the fastest hardware. Besides, if you want to blame anything for forcing people to upgrade all the time, try games.

Have you ever thought about the fact that more time should be spent using those apps than creating them? Or, in other words, is all you care about money confused.gif

I use all kinds of apps, but what I said is about a developper's standpoint. It's not like I make programs for the sake of making programs. Money is relevant to 99.9% of end users (perhaps not the Oracle cutomers). The price at which you can make software available is totally relevant, and how fast you can get it out the door and such. Customers want something inexpensive (else they won't buy it; I also want an acceptable profit margin - gotta eat and pay the bills sometimes), and they want it right now. Getting it out the door in time and on budget isn't exactly optional for most of us. And using higher level languages and rich frameworks like I do does exactly what you say: it leaves me more time to do other things than just programming.

Is all I care about money? No, but when you're making software - or any other product, you have such limits you can't ignore. If money was no object, I'm sure we'd have wicked nice cars too, amazing HDTVs, etc. But living in reality, we just can't ignore it. Given the same features, when given the choice, the client will usually pick the program that's half price (and is out the door in half the time) even if it uses 5% extra resources. Just like most people won't pay twice as much for a 5% nicer car that's out half a year late.

Edited December 10, 2006 by crahak

[jcarle]

The price at which you can make software available is totally relevant, and how fast you can get it out the door and such. Customers want something inexpensive (else they won't buy it; I also want an acceptable profit margin - gotta eat and pay the bills sometimes), and they want it right now. Getting it out the door in time and on budget isn't exactly optional for most of us. And using higher level languages and rich frameworks like I do does exactly what you say: it leaves me more time to do other things than just programming.

Development timelines is perhaps one of the most crucial aspect of any development language. The truth of the matter is that which programming languages survive and which one die are weighted heavily upon by their developmental time scales.

If you can create Microsoft Office 2007 to fit on a 1.44MB floppy and run on a 486, sure that's fast and efficient coding, but if it takes you three years to develop because it's coded fully in ASM to accomplish such a feat? Does the company or the client care if the suite comes on a CD or even on a DVD? Nope. But they both will care that it takes only 6 months to develop the new version.

With .NET I can create powerful database driven web powered applications in a blink of an eye. How long would it take to write the code to create the TCP/IP sockets to connect to the database, write a data handling module to interact with it, write data population code to extract the information from the database and publish it. Then the time to write another set of TCP/IP socket code to work around HTTP, extract commands, parse and post back.

In .NET I simply go, Connect to said database, load said table into the data grid, and when clicked here, download this file from this url. Done. I want perform a DNS lookup? There's a function for that. Download a file? Function for that. Resize an image with high quality bicubic resampling? There's a function for that.

I get ten time the work done in one tenth the time. And you know, because of the power of the .NET framework, if ALL windows applications were coded in .NET, applications would take up less space. Office would be only a few MBs instead of the 700MB it is now. Adobe Creative Suite would come on a single CD instead of five. All the duplicate code that all the different applications write would be eliminated.

Why have fifty applications that write their own custom TCP/IP connection code when they could use a single .NET function that would have all this code optimized already and uniform across all applications? Tweak the TCP/IP functions that make up the .NET framework and now you've improved performance in ALL applications simultaneously. I hardly see any downsides when compared to so many benefits.