Matthew David introduces the new .NET 3.0 Framework, comparing it to previous releases and pointing out the fancy new features we can look forward to using.
Deconstructing .NET 3.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Microsoft has released code that demonstrates CardSpace integrated into a PHP application. (It only took 200 lines of code.)
I find this statement pretty entertaining. You can write the core of a lot of useful apps in 200 lines of code. Think compressors, physical simulations, etc. The fact that it’s got the word “only” prepended to it basically summarizes everything that’s wrong with Windows programming.
It’s web programming, not Windows programming.
This is most likely the sample code to which the article refers:
http://www.identityblog.com/?page_id=430
Last I heard, .NET 3.0 was just .NET 2.0 + WinFX… Has anything changed? If not, the only “fancy new features” would be WinFX.
Has MS decided to introduce some new language features, or even some new classes outside of WinFX?
Last I heard, .NET 3.0 was just .NET 2.0 + WinFX… Has anything changed?
.NET 3.0 adds 4 new system to .NET 2.0
Windows Presentation Foundation (WPF)
Windows Communication Foundation (WCF)
Windows Workflow Foundation (WWF)
Windows CardSpace (WCS)
Workflows is going to be tremendously useful to anyone programming enterprise applications.
The problem with these solutions is that they’re inherently very loose and insecure. How often have you heard people sharing usernames and passwords? When this occurs, you do not know who the person authenticating really is.
So the problem is people sharing their identities, right?
The new Windows CardSpace is a step toward changing this situation. Unlike previous attempts at managing security, Microsoft took a bold step with CardSpace and did something almost unprecedented—asking security experts outside Microsoft what security should really look like.(emphasis added)
Now THAT made me laugh my a** off!
Must be the way he put it…
The response was simple: Any user can create and share his or her unique identity. Windows CardSpace is Microsofts version of this new solution.
WTF?!?
Maybe it’s just because English is not my native language but this is how i got it:
problem: people share identities – that’s unsafe!
solution: people may share identities – that’s cool!
Does anybody know what he _really_ wanted to tell us?
I just don’t get it.
And, of course, the phrase “only 200 lines of code” made my day.
I mean, we’re talking about web sites, right?
Not some monstrous do-it-all enterprise app.
Just a web page whose only purpose is to get the identity of a given user.
fixed some errors in html display
Edited 2006-10-15 11:01
And, of course, the phrase “only 200 lines of code” made my day.
I mean, we’re talking about web sites, right?
Not some monstrous do-it-all enterprise app.
Just a web page whose only purpose is to get the identity of a given user.
Why not take a look at those 200 lines of code to see what it actually does, and then point out why it’s bloated?
Because the code was not there, did you even bother to read the article?
I’m not gonna search every single page on MS-servers just to point out exactly why it’s bloated.
Judging from the article, 200 loc referred to the part
of the code that was used to somehow interface with
Windows CardSpace.
This smells like boilerplate code for something that should be small and simple.
If you really want to improve security make it simple.
Otherwise people won’t use it.
Just look at PHP’s GET and POST method and guess which is more popular…
In addition, I did not say it was bloated – I only said it was not all that small by website standards.
We know what those 200 lines of code do: it’s code added to a PHP app to integrate with this new security mechanism. It should not take 200 lines of code to do something like that, period.
As RandomGuy rightly pointed out, it’s quite likely mostly boiler-plate. Why? Because that’s what nearly every Microsoft API is like. That’s why it takes dozens of lines just to create a winow in Win32, and why just setting up a DirectDraw window takes pages of code. That’s why you see multi-volume thousand page tomes about individual Windows APIs, and why things that are very simple in other APIs (say mmapping a file), is a multi-step, multi-function procedure in Win32.
http://osnews.com/permalink.php?news_id=16173&comment_id=171804
Let’s assume the example linked to in this post is the one referred to, or at least equal to the example referred to.
In the php-listings I see a LOT of error handling code.
And various comments.
If we cut out error handling and the comments, we can probably cut the code by at least 50%, if not more.
It can probably be reduced even more if we reduce the example to a special case and assume other things as well.
I haven’t coded enough Win32 to comment on that, but for .NET you don’t need a lot of code “just to create a window”. Especially not if you reduce the window to use default settings for everything, and don’t bind any event-handlers to it.
Does other API’s magically know what you want to do with them? I’d really want to know, because I have tons of ideas that I could use such an API for.
No. Indeed, creating a window with an empty event loop in Win32 does not take that much code. It takes more code than if you wrote some simple abstractions that make assumptions about what you want done–the so-called sensible defaults–but that is true of any low-level API. Creating a GL context with GLX and then doing some event handling with Xlib for matrix transformations is not exactly concise.
In practice doing either is rarely your problem, but then Rayiner really likes to complain about Microsoft’s terrible, awful APIs. Oh for shame, MapViewOfFile, for shame.
The Win32 API isn’t really that great, and well MFC was just a down-right bad direction for a class library, but Microsoft has a lot of APIs and quite a lot of them aren’t that bad at all. No, they aren’t all “one function is all I need for my whole program,” but that’s because they’re intended to be flexible; use a simplified interface abstraction and move on with your life. There’s a lot of them, after all.
In practice doing either is rarely your problem, but then Rayiner really likes to complain about Microsoft’s terrible, awful APIs. Oh for shame, MapViewOfFile, for shame.
You’re right. MapViewOfFile is a mark of shame upon Win32. I’m glad you see it that way too…
but Microsoft has a lot of APIs and quite a lot of them aren’t that bad at all.
I hear the .NET APIs are pretty sanely designed. I haven’t used them myself, so I couldn’t tell you.
No, they aren’t all “one function is all I need for my whole program,” but that’s because they’re intended to be flexible;
Flexibility isn’t the issue here. The inability to keep flexibility from leaking into every abstraction is the issue. Good APIs should adhere to he same design principles as good UIs. The complexity of the actions required should be proportional to the complexity of the desired result. Solutions to problems should be discoverable. There should be one obvious way to do a given task. None of these statements are reflective of Win32. When you consider the additional programmatic issues of minimality, orthogonality, and proper abstractions, the flaws of Win32 become really apparent.
MapViewOfFile is fine, though I’m sure the existence of an argument for a security attribute in CreateFileMapping eats you up inside because structural arguments are intimidating even if you can just pass NULL.
The .NET APIs are actually kind of retarded in various areas when compared to even Java, which usually hasn’t impressed me much. For a while I wasted some time writing class libraries and then just decided the whole thing was a waste of my time and haven’t touched the platform since, though I’ve kept up with developments I simply have no use for it. Creating a window is pretty simple, though, so you can rest easy. Platform APIs are usually comme ci comme ça at the best of times. The number of primitive low-level APIs in the typical unix is significant, and after all of the platforms I’ve developed for over even the last decade I could write a lot of rants for each of them.
Flexibility really is the issue–there are abstractions for essentially anything you want to complain about, but really you just want to complain about APIs designed well over a decade ago and point to more abstract interfaces (not mmap, which is itself pretty primitive) and complain about Microsoft and its icky-pants APIs. They are designed to maximize flexibility, and were not targeted at inexperienced programmers looking to crap out programs quickly. Microsoft would always take the approach of making the basic infrastructure flexible and then creating tools and encouraging a market for libraries to simplify development.
“Solutions to problems” are discovorable–in fact there are more developers for Microsoft and its mediocre platforms than any other, because of all of the money shoveled into MSDN, dev tools, and so forth.
Where’s the Checked Exceptions.
How many years is this already? 3?
How long is Spec# going to be JUST a RESEARCH PROJECT.
( Last time I read the license Spec# was specifically restrcted from being used in a Commercial Application. )
Where’s the Typing Program for all those: Msft Pgmrs/Dvlprs?
Checked exceptions are not all that great. In fact exceptions in general are far from perfect in highly-reliable code because they represent a jump through several frames of the callback and perhaps through some layers of abstraction. For a quick and dirty program, checked exceptions are a pain and for a serious app, they don’t buy your much beyond what you get from having a team discipline around error handling. I’m an error-codes kind of guy myself and so is a lot of MSFT based on what Larry Osterman writes.
.NET 3.0 is similar to the previous frameworks, in that it will run on multiple operating systems. At launch, .NET 3.0 will run on Windows XP, Windows 2003/R2, and Windows Vista. I haven’t heard any discussion about releasing .NET 3.0 for Windows 2000 or any other Windows operating system.
Because I’m almost sure they won’t be supported.
.NET 3.0 is built on foundation of Windows 2003 SP1 / Windows XP SP2 and thus only those operating systems will be supported. Including Vista, of course.
Changes made to W2003 SP1 and WXP SP2 are too radical to be backported. Anyway, this is a enhancement for initial project which was meant to make WinFX only available to Vista.
Of course, this is also done to shrink the range of Windows systems. Right now, there are quite too many W98 or WindowsNT/2000 systems. However, it would be really difficult to backport such wide changes to such old systems.
Right now, there are quite too many W98 or WindowsNT/2000 systems.
Onestat puts that number at less than 9%:
“The 10 most popular operating systems in the world on the web are:
1. Windows XP 86.80%
2. Windows 2000 6.09%
3. Windows 98 2.68%
4. Macintosh 2.32%
5. Windows ME 1.09%
6. Linux 0.36%
7. Windows NT 0.24%
8. Macintosh Power PC 0.15%”
Net Applications suggests around 10%.
http://marketshare.hitslink.com/report.aspx?qprid=2
Hmmm… I’d have said those systems had a bigger market share. We always hear about how difficult was WindowsXP prenetration.
If those numbers are real, then it’s clear why those systems are not supported.
You do realize that those numbers are from a extremely limited scope of websites, rendering the numbers absolutely worthless?
You do realize that those numbers are from a extremely limited scope of websites, rendering the numbers absolutely worthless?
OneStat has 50,000 customers each with 1 or more websites.
NetApplications has 40,000 websites (different than the ones OneStat monitors).
I think the numbers are really useful.
Face facts … 95% or more of home computers had XP installed on them for the last 5 years. Corporations may have installed Windows 2000 on their PC’s for a few years after XP RTM’d, but surely over the last 3 years most would be XP.
I agree most would be XP – and nobody claims otherwise (though I’d recommend switching to Win2K3 Server as desktop OS or a FOSS solution – or even better, stick to Win2K).
Your numbers are flawed, however. But we’ll never agree on that, I guess.
Its too bad Google quit publishings its OS figures after June 2004.
But … notice the trend?
Sept 2002 XP = 20% / Linux = 1%
Sept 2003 XP = 38% / Linux = 1%
Nov 2003 XP = 42% / Linux = 1%
Jun 2004 XP = 51% / Linux = 1%
http://www.google.com/press/zeitgeist/zeitgeist-sept02.html
http://www.google.com/press/zeitgeist/zeitgeist-sep03.html
http://www.google.com/press/zeitgeist/zeitgeist-nov03.html
http://www.google.com/press/zeitgeist/zeitgeist-jun04.html
Yeah yeah…
And at W3C we can see these numbers. The marketshare of Linux on the desktop have increased with 59% since March 2003, and with 10% since september 2005.
http://www.w3schools.com/browsers/browsers_stats.asp
If you want to, we can keep beating each other with meaningless stats.
And at W3C we can see these numbers. The marketshare of Linux on the desktop have increased with 59% since March 2003, and with 10% since september 2005.
W3C Schools is one website. Hardly in the same league as Google or OneStat or NetApplications.
Even W3Cschools admits that:
“W3Schools is a website for people with an interest for web technologies. These people are more interested in using alternative browsers than the average user. The average user tends to use Internet Explorer, since it comes preinstalled with Windows. Most do not seek out other browsers.
These facts indicate that the browser figures below are not 100% realistic.”
Even so, with Linux grossly overrepresented … I see that Linux grew by 0% from June of 2005 to September of 2006. Well, actually it shrunk for a while and then barely regained what it lost.
But don’t get me wrong. W3C trending is interesting but nowhere near close to Onestat or Netapplications.
One website <> 90,000.
But even that website holds little solace for Linux users.
In 2004 IDC stated that Linux on the desktop had a marketshare of 2,8%.
You have a funny way of looking at stats. I now understand much better why people talk about lies, damn lies and NutParker’s statistics.
In 2004 IDC stated that Linux on the desktop had a marketshare of 2,8%.
And in 2004 Google said 1% of its users were using Linux.
Accusing me of lying because I use stats from the largest search engine on the web makes you look really, really dumb.
I do quote IDC all the time for server share because thier methodology is close enough to Gartners.
In this case I think Googles numbers are better because of the sheer volume of users.
Of course when I quote IDC on server share I get called a liar too.
I’m beginning to suspect the OSS definition of “liar” is: telling an OSS “fan”atic things he/she doesn’t want to hear.
You have used IDC as a backup for your claim.
Your way of using stats are flawed, and all I’ve done is using stats the same way, to show how flawed your reasoning is.
IDC showed Linux had approx. 26% of the market share for servers in 2004.
For any new concept in Computer Science there’s always a crowd who will fight for the status quo, and not admit there’s a problem to be solved.
Checked Exceptions and jumping thru frames: When you leave the “TRUE” path, you’re going to Leave the True path, whatever that entails, whatever method you choose.
Checked exceptoins give you:
– Hard Warnings you need to handle Probable Error conditions, before the code goes into production.
– The ability to Recover from an Expected Error Condition in Production.
True for small who-cares projects, checked Exceptions, UML, and Agile programming are over kill. But, it’s strange( or is it ), that Microsoft can’t see the benefit for Large software projects where Millions of Dollars are running thru your system on a daily basis, that you absolutely need these techniques to deliver the Quality Required for Enterprise apps.
Lazyness is no good excuse to drop a feature.
But, it’s the C guys fighting this, and they’ve fought in the past:
– auto garbage collection
– string libraries
– Unicode – multilanguage support
– Decimal math libraries for accurate financial results.
So, why am I not surprised that Microsoft is fighting CheckedExceptions.
Microsoft needs to grow up not just target Dentist Office software.
http://www.artima.com/intv/handcuffs.html
“Bill Venners: You mentioned scalability and versioning concerns with respect to checked exceptions. Could you clarify what you mean by those two issues?
Anders Hejlsberg: Let’s start with versioning, because the issues are pretty easy to see there. Let’s say I create a method foo that declares it throws exceptions A, B, and C. In version two of foo, I want to add a bunch of features, and now foo might throw exception D. It is a breaking change for me to add D to the throws clause of that method, because existing caller of that method will almost certainly not handle that exception.
Adding a new exception to a throws clause in a new version breaks client code. It’s like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, because any implementation of it might have the methods that you want to add in the next version. So you’ve got to create a new interface instead. Similarly with exceptions, you would either have to create a whole new method called foo2 that throws more exceptions, or you would have to catch exception D in the new foo, and transform the D into an A, B, or C.
…. ”
Very interesting read.
This is funny coming from Microsoft:
VB4, VB5, VB6, Com, DCom, C++, Java, J#, C#. .Net1.1 vs .Net2.0
– Feature move and rename in every os.
– ADO namespace changes with every release.
Microsoft is worried about software compatibility?
It breaks compatibility as part of it’s BUSINESS MODEL!
The guys that stayed Cobol on the Mainframe are laughing all the way to the bank.
In Java, a jar file is a drop in replacement,
same with .Net dll’s.
Especially for web/server based apps.
Secondly, if a signature break worries you, you write a new method with a different name, but, only if you want to keep the previous method alive.
I looked at the PHP code linked in a comment and I agree its overly complex.
Their solution is technical overkill. It’s a support nightmare. It’s easy to tell someone that their username or password is wrong. How are you going to explain that their shared, signed, encrypted token file(?) is shared, signed or encrypted in the wrong way, or just mangled, expired, invalid, or belongs to someone else.
As usual MS has opted for something so complicated that people will mostly stick to simpler less secure methods like passwords.
How are you going to explain that their shared, signed, encrypted token file(?) is shared, signed or encrypted in the wrong way, or just mangled, expired, invalid, or belongs to someone else.
Something like Outlook pulls when its encryption gets hosed.
“Your name was not found by the underlying security system”
or
“The messaging subsystem returned an error”
nice and clear for the end user.
>That’s why it takes dozens of lines just to create a >winow in Win32,
Last time I tried (about 30 secs ago) it took me one line to create a window and another line to show it. I think its pretty much the same on most modern GUI frameworks?
And how many lines to set up the message loop, create the window class, etc?
Just compare a few of the steps between Win32 and GTK+:
– Application setup: 1 call in GTK+ (gtk_init), 0 calls in Win32 (because WinMain wraps the relevant setup for you).
– Creating the window class: 0 calls in GTK+, filling out of about a dozen struct fields + 1 call in Win32.
– Creating the window: 1 call in both, but the GTK+ version has one parameter, while the Win32 version has 11.
– Showing the window: One call in GTK+, with one parameter, and two calls in Win32, with three parameters total.
– Initializing the message loop: one call in GTK+, with no parameters, a loop with three calls and half a dozen total parameters in Win32.
Or, consider something like handling an expose event. In GTK+, to handle an expose event, you have no setup. You connect the signal handler, GTK+ passes it everything you need, and you just draw. In Win32, you’ve got to get a PAINTSTRUCT and an HDC from BeginPaint, and finish drawing with EndPaint.
Yes, a lot of this is boiler-plate, but that’s what we’re talking about here. There is rarely a simple, quick way to do a given task with Microsoft APIs. To do one thing, you first have to deal with setup procedures that expose you to the full generality of the system. That’s just bad API design.
Edited 2006-10-16 04:25
Yeah, because comparing a low level API to a high level one is really relevant.
Try Win32 vs Xlib or .NET vs GTK.
This is where you compare creating a button control on a window in Win32 to doing the same using Xlib. Hohoho, I crack me up.
The Win32 widget API is at the same level of abstraction as GTK+: both are low-level procedural interfaces to conventional widget toolkits. Xlib is at the same level as GDI: both are low-level procedural interfaces to window-management and drawing functionality; neither deals with widgets. .NET is at the same level as GTK#, both are object-oriented wrappers over their respective procedural APIs.
The area of Win32 that you are discussing and GTK+ are not at the same level of abstraction–that’s plain silly. Even when considering the use of common controls is a little iffy, because the event model of a basic Win32 program and GTK+ is completely different for example, and even message cracker macros do little to paper over that. You would be better off comparing MFC and GTK+ for terseness.
Xlib and GDI are not really on the same level. Xlib implements event handling, window management, atom management, and lots of other things not in GDI, because GDI basically just deals with device context tasks like drawing, some limited image stuff, and fonts. Parts of Xlib are the same level of GDI, but Xlib is larger. It clearly isn’t comparable to the common control aspects of the Win32 API, which are more comparable to Xt.
You’re missing the point. Both GTK+ and the bits of Win32 in question sit at the same level in their respective stacks. Both are the user-visible procedural APIs for their systems. When you sit down to write a GUI program on these two systems, that’s what you’ve got to work with.
You seem to be saying that its not fair to fault Microsoft for not building more usable abstractions on top of Win32, but I think it’s quite fair to fault them for that. If Win32 requires proper abstractions built on top in order to be usable, it should’ve never shipped without them.
It’s also a bit of historical reinterpretation to say that Microsoft didn’t intend for Win32 to be the primary programmer-visible interface to the Windows GUI — that they intended it to be a layer under a more usable abstraction. Clearly, if they’d inteded that to be the case, they would’ve shipped with such an abstraction. As bad as Xlib is, at least it was always intended to sit as a low-level API under a proper GUI toolkit.
Xlib and GDI aren’t completely equivalent of course, but at a simplified level GDI <-> Xlib is far more accurate than the original posters comparison of Win32 <-> Xlib. The Win32 common controls aren’t really equivalent to Xt, in a modern system anyway, because nobody uses Xt. Maybe Xt <-> OWL or something like that.
Edited 2006-10-16 18:10
The only part of GTK+ that is even remotely relevant to the boilerplate necessary for a simple Win32 program to get to creating a window is already abstracted away out of site. It’s also abstracted out of site of anyone that’s actually developing software on Windows.
Win32 is not comparable to Xlib because Win32 is a gigantic mass of libraries (including the GDI) that represent an entire low level platform. Comparing Xlib to GDI is naturally less wrong, because it’s a smaller domain of wrong. However the impetus he has for bringing up Xlib is that it contains similar low-level considerations such as creating contexts, securing compatible visuals, opening and using the correct display, using the correct screen, creating the window, if you intend to do any event processing configuring the window with the correct event mask, and of course creating device contexts, performing low-level drawing, and so on. A low level interface with a lot of boilerplate that is covered by higher level abstractions, present for both.
And Xt family (Xaw, Xaw3D, Motif) is far more equivalent to the basic widget deposit of Win32 than GTK+ is. GTK+ is more modern than either, both in age and in design. That the architecture for Xt has been abandoned is mostly inconsequential for comparison–few people program using Xlib either, even if it’s still used as the basis for all of the other absurdly non-orthogonal mostly-incompatible toolkits available for X.
There are lots of of higher level interfaces for creating GUI programs on Windows. That’s why there’s so much software for Windows.
When he tells you to use have a comparable level of abstraction, he’s telling you to have a comparable level of abstraction. Everything is simple after you’ve simplfied it, after all.
I’ll do you one better: with Visual Basic all I have to do is create a project and my program creates an empty window by default. Take that, bad GTK+ design!
Real glib, but that’s an incorrect comparison. If you bring code generation into play, as you’re doing, any API can be as automatic as Visual Basic.