Datasheet
languages that could have generated the IL code. For example, you can load a compiled Visual Basic
application and Reflector will show you C# code that is roughly equivalent. This tool is also very useful
for comparing the IL generated by similar pieces of Visual Basic and C# code — the results are not
always the same. You can download Reflector and some other useful tools at
www.aisto.com/
roeder/dotnet
.
How important are these objections? Programmers often focus on speed but, as I’ll argue later in this
book, usability and correctness are more important than speed for most applications. If an application
spends most of its time waiting for user input and calling a database engine, pure CPU speed isn’t an
issue. With today’s fast computers and JIT compilation, speed is usually not a problem.
C# uses IL just as Visual Basic does, so there’s no reason to think using C# will improve performance.
Some languages such as Delphi may give better performance because they use better compiler optimiza-
tion techniques. Assembly can also give better performance, but only if you write good assembly code,
and the difficultly is rarely worth it.
Installing huge run-time libraries can be a serious issue. If you’re developing software for use within
your company, you may be able to require users to download a 22.4MB file that uses 280MB of disk
space when installed. However, if you want to allow customers to download your program from the
Internet, this may be a problem. For example, a 56K modem would take almost an hour to download the
file. Once customers have the run-time libraries installed, they will not need to download them for
future Visual Basic applications, but downloading them the first time could be problematic. Even with
Visual Basic’s new Click-Once Deployment, it’s much easier for the user to run a self-installing Java
application on whatever browser he or she prefers.
Finally, IL security can be a big issue for some applications. Many companies are protective of their soft-
ware, and the chance of reverse-engineering has made many of them reluctant to adopt Visual Basic
.NET. For many applications, you can easily deduce the code from the user interface. Any programmer
can figure out how to make menus, dialogs, and reports. Often, there is only a small part of the applica-
tion that is proprietary. If security is a real concern, you may be able to move that small piece of code
into a library written in a truly compiled language such as C++.
When considering whether the reduced security provided by IL is a show-stopping issue, ask yourself
these questions:
❑ How likely is it that someone will try to reverse-engineer the code?
❑ Does the program contain real proprietary information that you need to protect? Or, is most of
the code obvious from the user interface?
❑ Can you pull the sensitive pieces out and compile them into a compiled library?
You can also use obfusticators to deter casual hackers. Some of the latest obfusticators do a pretty good
job of making the code so confusing that it will be easier for a hacker to rewrite the application from
scratch, rather than to sift through the scrambled code. If you do use an obfusticator, you should also use
Lutz Roeder’s Reflector program to see what the resulting IL looks like. If you’re not confused by the
result, a hacker won’t be either.
5
Chapter 1: Language Selection
05_053416 ch01.qxd 1/2/07 6:28 PM Page 5