The Old Joel on Software Forum: Part 4 (of 5)

The real problem with .NET

I'm sure most of us have heard the parable about the house built on rock and the house built on sand. The house built on the sand washes away with the tide whereas the house built on the rock stands firm. (Well ok just humor me if you haven't heard it, it's biblical.)

We also have houses (applications) built on rock, Win32 API, and houses built on sand, .NET.

Microsoft confuses the Win32 API with .NET. They think both are the same when, in reality, they aren't, but they should be. That's right folks, they should be one and the same.

If .NET is simply a virtual machine environment then it should expose all of the functionality of the rock it's built on, the Win32 API. Unfortunately it falls short of this task.

If on the other hand, .NET is a platform, then it should be the OS. Thus, instead of letting .NET wash out to sea, you would have another rock. (Did I hear someone say... AS/400?)

Hey Microsoft! When is your new VM OS coming out?

Name
Sunday, May 23, 2004

If they charge for the .Net Framework and make a handsome change, maybe it would work out.. porting it that is. You gotta remember Win32 is HUGE, to replicate it for other platforms is a requirement for porting .Net Framework. Java on the other-hand most the most part really do rely on a fairly complete abstraction that maps to a very thin layer of Win32 or other platform specific calls. Swing relies on little more than a very fast canvas on all platforms and blits to it.

Li-fan Chen
Sunday, May 23, 2004

From what I hear, it seems that Longhorn will rely extensively on the .NET framework. Although I'm sure the Win32 API isn't going away anytime soon, the fact that MS is "eating their own dog food" at least shows that they are trying to position .NET as a rock.

Joe
Sunday, May 23, 2004

.Net abstracts Win32, to the benefit of both developers and admins.

.Net adds garbage collection, memory management, abstraction of complex libraries (writing against the SqlClient library instead of native ODBC code, for example). Abstracting them both makes writing the code easier (especially with intellisense in unfamiliar territory) and makes it somewhat more difficult to write code that will break other apps or the system.

In addition, code access security means that admins can control what code runs and what doesn't - even to the degree of allowing certain developers to do certain things. In theory, in a 100% managed code environment, viruses would be impossible (unrecognized code simply cannot execute, or can't affect resources outside its environment). I don't believe you can say the same about a Win32 environment.

Now you can argue about the implementation, or the manageability, but I'd venture that the intent is for .Net to be a house of rock in the Win32 desert of sand. But it depends on what you're looking for in development.

Philo

Philo
Sunday, May 23, 2004

And it produces UI that looks like my 10 year old did it.

Simon Lucy
Sunday, May 23, 2004

The ultimate goal of .NET should have been to become it's own platform not to abstract a platform. .NET fails to choose whether it's a platform or not. It teeters on the edge. Right now it's simply an abstraction layer that has the added benefit of giving developers a nice RAD environment, GC etc etc. I'm definitely not arguing the merits of the current incarnation of .NET because there are many.

If .NET matures to become a real platform, (or an OS in and of itself) it will allow exposure to complete functionality of the underlying API.

Now if .NET were an OS, it would eliminate the whole .NET VM layer because that would be transparent, which is the way it should be.

This is why I think Microsoft should have simply created a whole new VM based OS instead of just a thin layer. Though, this may be their plan for the future.

Name
Sunday, May 23, 2004

"And it produces UI that looks like my 10 year old did it."

Are you trying to keep up with the trolls? Please show me a Win32 program with such glamorous UI that any Windows Forms UI pales beside it...

Chris Nahr
Sunday, May 23, 2004

I personally think it is bad to force users into the VM world. Let's say there is a great new hardware technology in the future, let's call it, WI-FI++.

Since WI-FI++ is a hardware technology it makes sense to abstract that in the OS. If Microsoft only provides access to this interface via .NET, I think this is bad. I may want to write a server, or other application that requires that WI-FI++ be near real time and deterministic, and I don't want to take the overhead of the VM.

I think Microsoft should continue to support a native interface similar to Win32.

To me .NET is the modern day lisp machine.

christopher baus (www.baus.net)
Sunday, May 23, 2004

"Microsoft confuses the Win32 API with .NET. "

I don't think MS is confused in the least. They know exactly which is which. Developers on the hand.....

As Philo said, .NET abstracts the Win32 API. If there are things that you need in Win32, then you can still make calls to Win32. Of course, this comes at a cost.

I've not had time to keep current with Longhorn, but it certainly looks like it will be what you are wanting.

"And it produces UI that looks like my 10 year old did it."

You must be thinking of Java .NET doesn't produce UIs. Developers do and they do it using tools that transcend the .NET Framework. If a UI sucks, then it's because the designer making the UI lacks the talent.

Mark Hoffman
Sunday, May 23, 2004

Name, I think if .NET were developed in a vacuum, then making it the core of the OS may have been a good approach. But as it wasn't, there are other factors to consider, like time to market and existing legacy code bases. And Christopher Baus makes a good point about VM vs native in regard to hardware support and real-time apps, too.

Personally, I think .NET should have been released even earlier than it was, since it fills a crucial gap in Windows development (between the point and click VB'er, and the C++ crowd). I'm glad we didn't have to wait another 5-10 years for it!

I will agree that the UI's Visual Studio .NET is capable of producing out of the box leave something to be desired. However the problem there is the set of controls included in the box, not the Framework itself. You'd think if MS wants us to write apps that conform to the look and feel of the currently shipping OS (Win XP), that they would have made it a little easier to do.

Instead, we got manifest files and Application.EnableVisualStyles(), which also forces us to run arround setting the proper FlatStyle attribute on every textbox and button in the entire application. Blech! And mind you, that doesn't work for all controls, either... TreeView, for example, still sticks you with 3 border choices: None, FixedSingle, or Fixed3D, which are all pretty ugly. It really is a lot of work to make a UI that shines as nicely as Office XP/2003 or VS.Net.

Joe
Sunday, May 23, 2004

"To me .NET is the modern day lisp machine."

The irony is, this is read according to the person. Someone who loves VMs reads this as a compliment, not an insult. The LISP Virtual Machine was an amazing feat of engineering, decades ahead of its time.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, May 23, 2004

As Joe said, the real problem in creating UIs is with the controls in .NET, not with the .NET itself. Not all of these controls support right-to-left (or mirrored) text either. .NET 2.0 will support Office 2003 style UIs. Not so sure whether support for RTL (mirrored) controls would improve or not. By the way, it's really easy to create new controls in .NET. In fact, Windows-based controls seem easier to create than web-based ASP.NET controls.

The "real problem" with .NET is that it has evolved or extended itself to other territories too. Initially it was simply NGWS and ASP+ - to create Web Services and web-based applications. It was probably targetted to enterprise development. That's why we dont see *real* support for *real* Windows-based UIs in .NET - not before .NET 2.0.

About the VM or .NET OS thing. Two or three days back, a friend was telling about some research in his university for creating an OS that executes .NET applications without any need for an additional runtime (something of that sort). I thought it was a pretty stupid idea or probably I didn't get it right. It turned out that Microsoft was funding it. They have to shell out their huge R&D budget some way or the other.

But the *real problem* that is often attributed with .NET is also the source of its integrity. The huge 23+ MB file that we're afraid of. If that huge file was broken into smaller components which could be redistributed separately, we would have something on the lines of Java. There's J2SE, J2ME, J2EE, JWSDP, etc and a huge pile of JSRs.

Green Pajamas
Sunday, May 23, 2004

"By the way, it's really easy to create new controls in .NET."

The difference, though, is that when Microsoft releases the .NET 2.0 Framework with new controls, behind the scenes these controls will be native code (as most of the Framework is -- clean layers atop native code), and thus will perform excellently. Creating your own control generally entails 100% managed, which for GUI widgets is less than spritely.

Dennis Forbes
Sunday, May 23, 2004

Great, so in 2005(+) when Whidbey finally ships, we'll get Office 2003 style controls...and then Longhorn will come out shortly thereafter, with a new style of its own, and we'll be left behind playing catch up once again *sigh*

Also, creating useful controls isn't as easy as the code samples would have you believe -- *useful* being the keyword. Sure, writing a composite user control is pretty darn easy, and a lot of the time you can get what you need by extending an existing control, but what if you have to start from scratch? The painting code alone can get pretty complex if you're trying to support various OS look'n'feels. And what if you want your control to support things like complex DataBinding? Then there's the VS.Net designer to write, too...

Actually, I do like the bloated installer though...it makes it nice and easy to get end users to install the framework on their systems. Just one package. Done. Can you imagine having to get people to maintain 10 different .NET related packages, all with similar but different confusing acronyms, just to run your shiny new app? eesh...

Joe
Monday, May 24, 2004

"The ultimate goal of .NET should have been to become it's own platform not to abstract a platform."

Isn't that what Longhorn will do? From what I've read it seems like .NET will be "native" ("native" in quotes because it will still be "managed" to some extent) and Win32 programs will be virtualized.

T. Norman
Monday, May 24, 2004

The sad thing is, if they'd just write a decent API, .Net would be rendered largely redundent. As it is we're stuck with the hack jobs that are Win32 and MFC and the Fatworks that is .Net. I find that kind of sad.

Mr Jack
Monday, May 24, 2004

And how exactly would you go about turning Win32 into a "decent" C API?

Chris Nahr
Monday, May 24, 2004

You wouldn't.

You make a good OO (C++) API and then layer a C interface over the top of it. Since procedural languages are widely outnumbered by OO ones in makes sense to prioritise them in you API design.

You'd get rid of every single hack-job #define and all the multiple versions of the same call/struct, and generally alter the framework so that it followed sensible OO design principles rather than just being a big pile of shit.

Mr Jack
Tuesday, May 25, 2004

The Windows API was designed before C++ or any other OO language had become widely adopted. Also, Win32 is based on Win16, and had to be for backwards compatibility.

Creating a new OO API is precisely what Microsoft is currently doing with .NET and Longhorn. The choice for VM and GC was right, it's state of the art today and I definitely wouldn't want to see another API encumbered by the primitive C++ header file mechanism. Also, "bloated" is hardly the word for an installed size of less than 60 MB at a time when new hard drives are at least a thousand times as big.

The only point where I see valid criticism is MFC. Microsoft clearly botched what could have been a decent C++ based Windows API. But as I said, IMO the time for C++ based APIs is over anyway so that's no great loss.

Chris Nahr
Tuesday, May 25, 2004

Well, exactly, Win32 is awful because of backwards compatibility, MFC is awful because - well, I don't know why MFC is so awful, it just is. The point is that rather than shackling everything to the .Net style of things they could have invested that effort in replacing Win32 and MFC with good clean setups and then we'd have had the major benefits without the cost.

Mr Jack
Tuesday, May 25, 2004

"The choice for VM and GC was right, it's state of the art today"

A VM & GC was state of the art 15 years ago. It's an option today, but that doesn't make it the best option. I'm curious how many Microsoft advocates were praising Java when it came out?

One of the primary advantages of the VM in the Windows world (given that _very_ few Windows users plan on running their IL apps on anything other than a Windows/x86 platform) is that it allows the OS to strictly enforce access controls on every system resource -- whether the app wants to open a file, list a directory contents, connect to a website, or listen on a port: With .NET and Code-Access Security (the most important feature of .NET in my opinion) you can strictly limit what an app can do, and with a policy of least privilege you can ensure that an app fault where extended permissions are requested will lead it to simply except and fail.

Here's what burns me about this "revolution": This has _always_ been possible in the 32-bit world, as the CPU enforces what is effectively a "Virtual Machine" on all outer-ring applications (user-mode apps). There is limited activity that a user-mode application can do without the cooperation and understanding of the operating system, so if an app wants to open a network socket, write to a file, or delete your MBR, the operating system has to be cooperative. Of course we all know that Microsoft dropped the ball: Virtually all services run under the "system" account (saves trying to figure out least privilege) so a simple buffer overflow gives system access. Even if users were assigned appropriately, the majority of system services (like sockets) have no ACL permissions allowed, so the operating system doesn't give you granular control if you wanted it. Microsoft effectively took this great new architecture and grabbed defeat from the hands of victory.

Dennis Forbes
Tuesday, May 25, 2004