Fog Creek Software
Discussion Board




.Net Forms

I have a couple of comments/questions about Forms in .NET. First off, I currently do tons of work in Borland C++, which works very well for our business. I'm looking at doing some new stuff in .NET forms.

1. Does .NET Form applications feel kind of klunky to anyone else? When I run an app built with .NET, the interface just doesn't seem right. It’s hard to explain, but it doesn’t feel like a normal Windows application. It kind of makes me fill like I’m running an app under X11.

2. It takes a while for an application to launch for the first time even on a fast machine. Is this normal?

3. Are there any real commercial apps written in .NET, or are most people using it for .ASP programming?

4. Can’t people get at your compiled source much easier than disassembling a standard Windows app?

I do like the new Visual Studio that comes with .NET and I like C# quite a bit.

Curious
Tuesday, May 20, 2003

1. If you are used to ObjectWindows, MFC or even Win32 programming, then yea the feel of .NET is "bloat".  It's the same feeling I experienced when I started using Visual Basic.

2. Yes it is normal.  I believe the first time - your program is compiled to run on the CLR and after that it is built incrementally.

3. Yes there are real commercial apps built using .NET.  There is a thread a little further down that asks this very question.

4. Not sure.

For Sale
Tuesday, May 20, 2003

Part of the "bonus" of .NET is the JIT compilation. This is why the app can feel sluggish. Once the app is loaded, however, it's a slick as anything else. I've not noticed it otherwise, and that's comparing it to VB6/Delphi/VC.

There are a few commerical applications written in .NET, and I believe you'll see a whole lot more over the coming years.

As far as code security, it's no more or less secure than a standard exe. I can take a disassembler and look at the assembly language generated by your compiler, and reverse engineer that (if I was sadistic enough).

.NET assemblies can be disassembled too, but at a slightly higher level. MSIL is a form of high level assembly language. It's a little easier to read, but it would still be a PITA to reverse engineer an application.

I'm sure you'll find tools to help obfuscate things though. There was a company that made a tool that obfuscated VB P-code, from memory. They may have something for .NET. They also had a tool that packed the VB runtime and any controls you needed into the one exe, and unpacked them when your exe ran.

Geoff Bennett
Wednesday, May 21, 2003

1. Not really. Most likely you're just experiencing the startup delay -- .NET controls are constructed at runtime, with some dynamic library loading and JIT compilation in-between, so you don't get the "bang" immediate GUI presence as with a Win32 app. Once it's all loaded and compiled and initialised, it's just as fast as Win32.

2. Yes, well, the Framework has to load and then the app has to be JIT compiled. You can ngen the application but the Framework will still have to load, and that's usually the slower part anyway. Wait for a version of Windows that preloads the Framework...

3. Look at the other thread from a week or two ago. No, there aren't currently any retail desktop apps using the .NET Framework. It's too new and not widespread enough. There are a bunch of commercial web applications, though.

4. Yes. The usual argument that "every program can be disassembled" is, begging your pardon, bollocks. Take a look at the free Anakrino decompiler...

http://www.saurik.com/net/exemplar/

...which produces perfectly readable C# source code from .NET assemblies.  Commercial decompilers basically create a C# (or whatever) project, ready for recompilation.

Java is in a similar situation but there is NO equivalent to this level of source code recreation with languages that compile to native machine code. You definitely don't want to distribute "secret" algorithms in a .NET assembly, unless you embed them as native code segments using Managed C++.

Chris Nahr
Wednesday, May 21, 2003

But every program *can* be disassembled. To what degree depends on the language and its assembled state. MSIL can map back nicely to VB.NET/C#, as can VB5/6 P-Code be mapped back nicely.

Assembly language is quite difficult to map back to a source language, as it's the final target of every language (or language VM in the case of Java/.NET/etc).

If you have a proprietary algorithm and someone wants it bad enough, it doesn't matter that the final source is assembly.

The only chance you have is to go with a code obfuscator. Again, if you're desperate enough, you can examine the running processes memory and still get the un-obfuscated code.

Geoff Bennett
Wednesday, May 21, 2003

VS.NET 2003 includes a built in obfuscator.

No idea how well it works.  The way I see it, if someone wants to see my code that bad, they're going to get to it one way or another.

Steve Barbour
Wednesday, May 21, 2003

Steve,

If someone wants it badly enough nothing will stop them. That does not mean, however, that you should not try and dissuade the casual hacker from looking at your software.

Ben Thompson
Wednesday, May 21, 2003

Let's do a reality check here. Normal people can't examine a process in-memory or even native machine code on-disk (without symbols) and recreate any complex algorithm from that. Even most developers can't do that. I know I can't, although I may be particularly stupid.

I know x86 assembler well enough to figure out what a well-written routine does, but the few x86 disassemblers I tried produced a basically unreadable mishmash of instructions and data that usually couldn't even be re-assembled. Never mind recreating C source code, let alone object-oriented C++ source code...

On the other hand, .NET decompilers like Anakrino require absolutely NO skill to use -- you literally click on a few buttons and get perfectly readable and recompilable C# source code! I could decompile the SortedList class and actually figure out how it works in maybe 20 minutes. That's possible because the MSIL is of a much higher level than x86 machine code, and of course because .NET requires embedded symbolic information for anything but locals.

Yes, "someone" will crack any code, but this generalisation is meaningless because most people are not such "someones" nor do they know a "someone" who could decompile x86 machine language (and actually figure out the algorithm). Everyone, however, can easily decompile a .NET assembly to correct high-level source code. I think the difference is fairly obvious.

Chris Nahr
Wednesday, May 21, 2003

I think the point is more about being overly paranoid about someone reverse engineering your code.

If I see a program running and can understand what it's doing, I can reproduce it pretty much - without reverse engineering the code.

There's bugger all that can't be replicated today, so obfuscating code doesn't achieve anything more than putting a burglar alarm on your house.

I can't think of one bit of mainstream software that couldn't be easily duplicated if you had the time.

As far as proprietary vertical market software goes, any algorigthms (in most cases) existed outside of the computer domain for a long time before they were inside it.

I've worked at so many companies who believed they had an edge over their competition solely based on a few handfulls of routines that could be figured out in about 5 seconds by anyone watching the program in action.

Like it was said, if someone can be bothered to reverse engineer anything I've written (no matter how easy it may be) good luck to them. What I provide is more than the executing code. That's something that can't be reproduced without a lot of effort. If you're the sort of person who would reverse engineer a simple application, then you're not the sort of person who would put the effort into the other.

Geoff Bennett
Wednesday, May 21, 2003

"I think the point is more about being overly paranoid about someone reverse engineering your code."

Well, that's quite another issue but I agree with you here. Some companies actually have crucial encryption algorithms or the like that they want to make as hard to understand as possible, but mostly it's paranoia.

"If I see a program running and can understand what it's doing, I can reproduce it pretty much - without reverse engineering the code."

Absolutely. If having a competitor's source code was enough to build a software business, OpenOffice would have spawned dozens of shops selling Word clones...

Chris Nahr
Thursday, May 22, 2003

What I find especially stupid is the nVidia won't release the source code for their Linux video drivers.  As if somebody else will all of a sudden start manufacturing competitive video cards as a result of seeing the source code.

T. Norman
Saturday, May 24, 2003

It's hard enough to understand code I wrote a year ago, never mind reading someone else's decompiled source-code.

In many situations, the actual source code itself has little intrinsic value without the underlying knowledge and design required to make use of it. If someone is capable enough to understand the decompiled code, then chances are, the value of that code was minimal as they could have programmed it themselves. In addition, there are other factors such as the ability to sell it effectively and having the skills/team/infrastructure required to maintain and enhance it that are are of greater importance.

Cosmetic companies face a similar problem... their products can be "reverse-engineered" using various techniques and many of the same arguments apply for their perfumes as well as for developer code.

SC
Monday, May 26, 2003

Fascinating example! Are there obfuscators for perfume? Can you somehow hide the chemical makeup with lots of trash molecules that don't contribute to the smell?

Chris Nahr
Monday, May 26, 2003

*  Recent Topics

*  Fog Creek Home