Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Why Microsoft needs .NET

By NotZen in Technology
Wed Oct 02, 2002 at 01:55:08 PM EST
Tags: Software (all tags)

Microsoft claim that the .NET runtime is being produced purely because it clears away all the previous kludgey problems of writing Windows software.

There may, however, be an ulterior motive...

Lots of people seem to be confused by Microsoft's .NET initiative.  This is largely because it's actually several initiatives rolled into one.  for the purpouses of this entry I'm going to ignore web services and passport authenticiation, which, while both interesting in their own right, aren't going to strongly affect Windows itself.

The .NET framework, on the other hand, will.  For those of you who don't pay attention to these things, normally (and this is simplifying things greatly) you compile code from the actual text that is typed in straight to machine code that's specific to the chip you're working with (in the case of Windows, that's largely the 386, most x86 chips after that point basically working as 386 chips with addons, or at least imitating this).  .NET is different because your code actually gets compiled into what's called the Intermediate Language (IL).  It's only when this IL is first run that it actually gets converted to its final form, and it then runs on top of the .NET runtime.  This .NET runtime acts as a layer insulating the code from the machine it's running on (in part, anyway).

There are two advantages to this.  The first is talked about a lot.  The second is talked about very little.

  1. You can write code in any language you like and, so long as you have a compiler that produces IL code it can work with .NET.  This means (for instance) that you can write code in C# (the .NET version of C) and then call it from code written in VB.NET, and then call that from code written in COBOL.NET (list of available languages here), and so on.  You can kind of do that in windows already, but it not terribly well, and it wasn't at all seamless.
  2. Any platform that has a .NET runtime can run your software.  Big deal, you say, so I can run it on all the Microsoft platforms. Except that Microsoft has provided a minimal .NET for BSD Unix, there's a cut down version coming for PDAs and mobile phones and Mono is a GPL'd recreation designed to run on Linux (and supports Solaris and Windows too so far).  
Now, you may not remember, but when Windows NT came out, it was touted as multiplatform because it also supported  the DEC Alpha platform as well as the x86.   The problem being that any software that you wanted to run on the Alpha had to be completely recompiled to run on it.  Despite the Alpha being a great platform, if you couldn't get the software, it was hardly worth having.  I know that some companies went to the effort, but the major advantage of Windows is that you can get everything for it, so why bother if you can't?

On top of this, we have the new Intel Itanium processors.  These are Intel's next generation chips.  They're backwardly compatible with x86 chips, but very badly.  Any applications compiled for the x86 will run several times slower on them than on an x86.  Code compiled for them, on the other hand, is apparently blindingly fast.  In fact, the x86 line as a whole is creaking a lot.  Recent AMD and Intel chips are both actually very different chips internally, that fake being an x86 on the outside, translate everything and then run very quickly internally.  You can imagine that this isn't as efficient as it could be.

This has been a sticking point with graphics cards (and others) too, using the same chips just doesn't allow you to be as efficient and powerful as possible.  Moving to new chips means the old software breaks (or has to have chunks written seperately for each card).  This is solved by using "drivers" that conform to a standard.  The drivers take the calls and convert them to a language that the card recognises.  This allows the card makers to change their hardware as much as they like, so long as they write drivers that convert the standard calls to their own internal language.

I think you can see where I'm going with this - by moving software to .NET, Microsoft frees themselves from the x86 pit.  They need to compile the .NET framework for each platform they want to support, and they need to write the final compiler stage that converts the IL to machine code, and bingo your code runs on the new platform!

Of course, it's not quite as simple as this - the Microsoft version of .NET is very Windows reliant, so they have to port Windows too.  However, as I mentioned earlier, Windows was designed to be portable.  They stopped selling the Alpha version a while back because it wasn't making enough money, but they certainly continued producing it internally for a while.  Windows NT (and thus 2k and XP) were all based around the concept of a Hardware Abstraction Layer.  Theoretically by rewriting that small piece, everything else in Windows "just worked" (after a recompile, of course).  So if they've kept that ticking over in the background, you could suddenly see a profileration of Windows for different platforms.

Microsoft wins, because they can scale up to higher end computers without you losing all the lovely software you like.  Intel wins because you can use their lovely new chips.  You win because you'll be using a version of Windows designed for your machine, not for one with a slightly different chip, because MS will be able to have the compiler be the efficient for the chip it's running on - so Athlons will have Athlon stuff enabled, P4s will have their speedups enabled, etc.

And this, I think, is the real reason for the .NET runtime.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o here
o Mono
o while
o Also by NotZen

Display: Sort:
Why Microsoft needs .NET | 131 comments (99 topical, 32 editorial, 0 hidden)
Maybe a slight flaw (5.00 / 2) (#8)
by grand master thump on Wed Oct 02, 2002 at 05:47:50 AM EST

You assume that it is going to be a trivial matter for all of the thousands of legacy Win32 apps to be ported to .NET. As you pointed out the Alpha version of NT died because no one ported their apps to it, when it was simple matter of a recompile, now as TheophileEscargot pointed out in a previous post it is not a matter of a simple recompile for all those apps, they have to be rewritten, VB.NET is not VB, but more importantly Managed C is not C/C++ as it has no multiple inheritance and a host of other C/C++ capabilities. That means major re-writes for the software vendors, lots of money and developer time. Couple that with the simple fact that C#/Managed C/other interpreted language is rarely going to perform better than optimised C or C++ they will essentially be hamstringing their products, games are one of the biggest drivers of PC use in the home, no game development team is going to sacrifice clock cycles to the CLR. How likely is it that Windows is going to drop all support for the normal VC++ executables, not very likely at all as the major reason that everyone uses it is because you get all the applications you want for it, stop them using all their favourite apps and people may take alternatives a lot more seriously, double that for games. Ergo why would the software vendors bother porting their apps in the first place, they have no reason to and it would cost them more money.

I think MS looked at enterprise computing and said if we can homogenise the language environment it will make it a lot easier to get stuff to be interoperable, it worked for Sun and java and we want some of that.

This sig has been stolen

May be performance *gain* due to JIT (3.50 / 2) (#11)
by pjc50 on Wed Oct 02, 2002 at 06:50:30 AM EST

C# is not going to be interpreted, it's compiled into code appropriate for the processor it's running on. This may mean that it is actually faster, as it can take advantage of specific processor features / instruction timings / AMD 64-bit extensions / whatever.

Besides, memory architecture can cause strange phenomena. On the Acorn Archimedes, some benchmarks were faster in interpreted basic than
compiled C, because the program+interpreter+data
fitted into the cache and the compiled program didn't.

As for how to persuade people to use it - all they need do is stop updating the development tools that target native code, and people will switch to using CLR for new projects. It'll take a few years, though.

[ Parent ]

Optimization not so easy (none / 0) (#37)
by HidingMyName on Wed Oct 02, 2002 at 10:19:13 AM EST

Just In Time (JIT) Compilers only see the intermediate code. At that point there are several classes of optimization which are hard to perform, it is already too late (e.g. inline functions). Cache effects could be bad because the intermediate code generator doesn't know things about cache management so loop unrolling and other optimizations may be left undone or done with the wrong parameters. Modern processors are fast, modern memories are large, however, making a JIT exploit low level features during optimzation is going to be hard. The other problem with JIT is that mapping from binary back to source is a bit harder due to the extra level of compilation, sometimes that makes debugging harder.

[ Parent ]
Performance (5.00 / 2) (#55)
by ucblockhead on Wed Oct 02, 2002 at 12:17:51 PM EST

C# performs significantly worse than C/C++.

(Speaking as someone currently writing a moderate sized C# app.)

I've also got test programs that show it pretty clearly. The C++ STL container classes outperform the C# containers by a factor of ten. (And, surprisingly enough, Java also seems to outperform C# by a significant amount, though not as much as C++)
This is k5. We're all tools - duxup
[ Parent ]

JIT can only approximate... (none / 0) (#65)
by steveftoth on Wed Oct 02, 2002 at 01:49:35 PM EST

because if you are writing in a lower level language you can always do more optimization.  Writing critical code in assembly will yield faster runtimes then JIT.  Java's Hotspot is good, and C# may have a good optimizer, but as of right now, only 2 or 3 compilers actually use all the instructions avaliable to them.  Only a small few even know about MMX/SSE/3dnow instructions, and of those compilers, only one or two actually generate code that doesn't crash.  (I believe that gcc still doesn't do it correctly)  This may be more due to the bad implementation on the silicon rather then compilrs design I don't know, but the point is that optimizing code is hard for a program to do.  

[ Parent ]
JIT vs. Assembly (5.00 / 1) (#69)
by TheSleeper on Wed Oct 02, 2002 at 02:06:38 PM EST

because if you are writing in a lower level language you can always do more optimization. Writing critical code in assembly will yield faster runtimes then JIT.

Not necessarily true. JITs have runtime knowledge that is not available to the assembly programmer, and thus have the opportunity to make more aggressive optimizations. Read about HP Dynamo, sometime. It's an "interpreter" for HP's PA-RISC instruction set that produces speedups of up to 20% over running a program directly on the hardware.

[ Parent ]

I've read about that software... (none / 0) (#95)
by steveftoth on Thu Oct 03, 2002 at 12:19:00 PM EST

programming in assembly doesn't stop that technology from being effective.  That technology doesn't (AFAIK), depend on all compiled code.  you could intermix assembly with normal C code for example and the Dynamo would still work.  Since what it is probably doing is analysing the runtime charactertics, function call frequency, branches, etc, and inlining functions where they are frequently called. It's probably very similar to the HotSpot technology in the sun JRE.

[ Parent ]
.NET (none / 0) (#64)
by jmzero on Wed Oct 02, 2002 at 01:41:24 PM EST

I don't think companies are in a mad rush to port to .NET.  However, many are starting new development in it.  This means that, at some point, MS will be able to move with them to a new platform (and thus keep making money).

As you say, I'm sure MS will continue to support old native apps - either natively or via some sort of compatibility layer.  Either way, I think they see .NET as a way to make future apps portable.
"Let's not stir that bag of worms." - my lovely wife
[ Parent ]

On the other hand, (none / 0) (#67)
by spcmanspiff on Wed Oct 02, 2002 at 02:03:41 PM EST

Vendors that refused to port their applications to Windows 95 and varaints died a slow and painful death.


[ Parent ]

C# (2.80 / 5) (#10)
by Talez on Wed Oct 02, 2002 at 06:42:34 AM EST

Pointers are eeeeeevil *hides*

Si in Googlis non est, ergo non est
Pointers (none / 0) (#34)
by luserSPAZ on Wed Oct 02, 2002 at 10:10:56 AM EST

I can only imagine how much productivity is lost to programming mistakes that modern languages can avoid, such as memory mismanagement.  C and C++ are appropriate for some things, but I really think it's time to move on.  Not that I'm advocating Java, just something more advanced than C/C++.

[ Parent ]
perl: modern, stable, supported, powerful -nt (5.00 / 3) (#41)
by czth on Wed Oct 02, 2002 at 10:23:14 AM EST

[ Parent ]
Prrrl (5.00 / 1) (#44)
by luserSPAZ on Wed Oct 02, 2002 at 10:48:17 AM EST

I like perl.  But only for some tasks.  I don't think I'd want to write an "application" in it.  Whatever that means anymore.

Perl 6 looks like a winner, though.  It's like they READ MY MIND and made everything I didn't like about Perl work the way I thought it should.

Come to think of it, I've probably written more  code in Perl than any other language lately.  I still like Lisp better though.

[ Parent ]

But unreadable - nt (3.66 / 3) (#59)
by Cro Magnon on Wed Oct 02, 2002 at 12:28:59 PM EST

Information wants to be beer.
[ Parent ]
Non-intel NT (4.00 / 2) (#12)
by LQ on Wed Oct 02, 2002 at 06:57:20 AM EST

I once worked on a port of a product to a non-intel varient of NT. The manufacturer pulled out of the NT market because Microsoft insisted the manufacturer had to support the OS themselves. The manufacturers were getting the worst of both worlds - a bought-in OS but they had to handle all the support. I think Microsoft's greed killed NT portability.

Well, also... (3.50 / 2) (#19)
by DeadBaby on Wed Oct 02, 2002 at 07:53:35 AM EST

NT4 was a little too inmature to fight toe-to-toe with UNIX on those platforms. I think if Microsoft had releaseed ports of Windows 2000 for these platforms they would have a decent non-x86 market share right now.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
OK, Microsoft and Intel need .NET (3.00 / 7) (#13)
by Mr Incorrigible on Wed Oct 02, 2002 at 06:58:05 AM EST

so that Intel can sell more and faster chips and Microsoft can sell the next version of its operating system; they have to have something tangible around which they can base their marketing.

It seems, though that Microsoft is wasting its time trying to duplicate Java's theoretical "write once, run everywhere" approach. I can't say I care much; I only use MS tools at work because I'm paid to do so. At home I use FreeBSD, and if I want to optimise for my hardware (AMD Athlon XP 2000) I just set some compiler flags, run make world and go read a book while rhiannon and christabel do their thing. If I needed a really portable operating system I wouldn't fuck around with Microsoft's BDSM-OS, I'd just download a port of NetBSD for the hardware I'm using and install it. Microsoft is, IMHO, wasting its time and money -- but that isn't my problem; I've got my BSD.

I know I'm a cheeky bastard. My lady tells me so.

Good for you. (1.22 / 9) (#17)
by aitrus on Wed Oct 02, 2002 at 07:42:12 AM EST

Why how nice to know.  I mean, before, I never knew how uber l33t you were at computers.  Now, suddenly, I want to be like you.  You are my hero sir and, despite my being of the male persuasion, I would happily give you oral sex any time of day.

[ Parent ]
I guess the sun hasn't risen where you are. (none / 0) (#24)
by Mr Incorrigible on Wed Oct 02, 2002 at 08:47:23 AM EST

I could have sworn you were being a troll.

I know I'm a cheeky bastard. My lady tells me so.

[ Parent ]
It would be +1Section (3.00 / 3) (#14)
by mirleid on Wed Oct 02, 2002 at 06:59:45 AM EST

...but I'll abstain...What's the point of putting stuff in the edit queue if you dont use the feedback you get?

Chickens don't give milk
Apologies (none / 0) (#76)
by NotZen on Wed Oct 02, 2002 at 03:51:26 PM EST

Sorry, I didn't realise stories in the edit queue could actually be posted.

 I put it in the queue and went to work, figuring that I'd check the comments when I got back.  I got back and it had been posted.

[ Parent ]

_ (2.83 / 6) (#15)
by noogie on Wed Oct 02, 2002 at 07:15:17 AM EST

You win because you'll be using a version of Windows


Actually, I agree. (4.80 / 5) (#18)
by DeadBaby on Wed Oct 02, 2002 at 07:50:41 AM EST

I'm a little surprised no one else has caught on to this. It's always been very clear to me .NET was an effort to decentralize Microsoft's development platform. A lot of people think that's just a straw man to help compete with Java but I fully believe Microsoft realizes that OS/platform dependence is a thing of the past.

If .NET is fully taken advantage of it will ease the transition to 64-bit CPU's and it'll also allow Microsoft to move all their eggs out of one basket, so to say. .NET gives them a foothold on non-Windows, non-x86 platforms. They may not necessarily take advantage of it right away but down the road I can see Microsoft deciding that the OS is just low-level grunt work while pushing .NET as the successor of their Windows dynasty.

"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan

but, all this was/is true with Java (4.00 / 2) (#43)
by speek on Wed Oct 02, 2002 at 10:39:26 AM EST

If Java were fully taken advantage of, it would ease the transition to 64-bit CPU's in the same way. Why does Microsoft feel the need to duplicate it? Because they want to control it. Because they want to kill Java and control the future, because bytecode interpretted languages are the future for all the reasons mentioned and more.

It's not that Microsoft invented anything or are pushing the industry toward what they want - they are reacting to Java and the concept of virtual machines in general. Now, they are just trying to make a dominant place for themselves in that future.

Perhaps the State of Hawaii could countersue the woman that gave birth to and raised a
Parent ]

Yep, pretty much (4.00 / 3) (#48)
by DeadBaby on Wed Oct 02, 2002 at 11:02:57 AM EST

Yep. They tried to extend Java and make it their own and when that failed they decided to just create a Java clone. It's your typical Microsoft success story in the works. While Microsoft spends the next 2-3 years improving .NET, Java will start slipping and Sun will resort to name calling and government intervetion instead of actually improving their product. Within 5 years we can add Java's name to the long list of "loser by default", right by Lotus 1-2-3, Word Perfect, Netscape, OS/2, etc.  We've all seen it happen again and again.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
Or (4.40 / 5) (#51)
by speek on Wed Oct 02, 2002 at 11:21:51 AM EST

Sun finally does the smart thing and makes Java fully open source and standardized and lets the community take it over. It would have a hard time dying at that point. Plus, it has a big head start on actually being portable across win/unix/mac, whereas .NET is currently only windows. Java can't die at least until .NET works on those platforms.

Perhaps the State of Hawaii could countersue the woman that gave birth to and raised a
Parent ]

That'd be a start (NT) (2.00 / 1) (#52)
by DeadBaby on Wed Oct 02, 2002 at 11:41:47 AM EST

"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
Thanks, Miguel (none / 0) (#107)
by sgp on Thu Oct 03, 2002 at 11:17:05 PM EST

That's where Mono comes in - Miguel is doing that work for Bill already :)

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

Because Java is proprietary (3.00 / 1) (#93)
by codemonkey_uk on Thu Oct 03, 2002 at 07:01:09 AM EST

And Microsoft aren't going to just roll over and hand control of the platform to their arch rival. At least Microsoft are working with other companies (HP, & Intel) got get .NET and C# standardised. It's been ratified by the ECMA, and is now in the hands of ISO, showing that Microsoft recognise that Java will (has) fail(ed) because Sun tried to push a proprietary platform on the industry, claiming it was "open" and "standard" when it was not.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Keep up (none / 0) (#108)
by sgp on Thu Oct 03, 2002 at 11:19:39 PM EST

Keep up... in 1997 Cnet reported that Sun Microsystems (SUNW) has won approval to submit its Java programming language to the International Standards Organization as a standard..

That's about as far as .NET have got so far, AFAIK - except that Java already being used, too....

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

*sigh* (none / 0) (#111)
by codemonkey_uk on Fri Oct 04, 2002 at 04:52:56 AM EST

Sun then went on to withdraw the submission, where as the C#/.NET standards have been ratified.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Missing huge pieces of info (2.00 / 3) (#20)
by brunes69 on Wed Oct 02, 2002 at 08:03:05 AM EST

...The second is talked about very little.

Every programmer and his dog knows that .Net programs are portable. Of COURSE this is the reason for the .Net runtime. It was the advertised reason! That is the whole point of .Net. What I am trying to figure out is how you wrote this whole article without comparing the .Net runtime to Java? .Net is basicly a MS implimentation of Java, which runs much faster with graphical programs than Java simply because its GUI layer uses native widget sets. It is nothing really revolutionary, it is simply an idea MS stole from Sun. I am giving this a -1 simply because I have no idea what viewpoint you are coming from, you seem to be amazed about all this revolutionary cross-platform concept, when it has been in use for years. As well, it is a widely known fact that the main goal of .Net is to ensure cross-platform code, so that developers can write an app for Windows once and run it anywhere (PC, PDA, Phone, TV, etc). I fail to see the point of this article.

---There is no Spoon---
VMs weren't a Sun invention. (4.40 / 5) (#26)
by a2800276 on Wed Oct 02, 2002 at 09:10:46 AM EST

It is nothing really revolutionary, it is simply an idea MS stole from Sun.

Sun weren't first in coming up with the idea of bytecode executed by a virtual machine. It had been done in several implementations before. One of the more famous examples is Smalltalk.

This might be of interest.

[ Parent ]

no doubt (none / 0) (#98)
by NFW on Thu Oct 03, 2002 at 03:06:20 PM EST

Visual Basic is also compiled to bytecode (MS calls it p-code).  Did VB steal from Java, or did Java steal from VB?

Q: Which came first?  

A: Smalltalk? :-)

Got birds?

[ Parent ]

Java uses native widgets too (none / 0) (#102)
by TheLastUser on Thu Oct 03, 2002 at 09:45:08 PM EST

The awt is based on peer classes that are the native implementations of those widgets.

This design was ultimately dumped in favor of swing because if you are REALLY going to do cross platform computing, you will find that gui widgets and functionality might not be the same on all platforms. Apparently MS only intends .Net for use on MS platforms, where they can control the gui.

[ Parent ]

-1 : Missing the important bits (4.00 / 4) (#25)
by blackpaw on Wed Oct 02, 2002 at 09:01:25 AM EST

the CLR is old hat, if that was all it was then we might as well stick with java.

What about:
1. Code signing
2. built in module versioning
3. Built in portable typeinfo (aka COM typeinfo, only much better and transparent).

1 & 2 are important for virus prevention and controll of "DLL hell"

3 Is a very big deal - classes/functions written in one language (e.g C#) can be used with no recompile or header/IDL files needed in any other .NET language, e.g. C++ or Effiel.

Not so big a deal ... (5.00 / 1) (#91)
by Simon Kinahan on Thu Oct 03, 2002 at 05:27:20 AM EST

1. Java does that. ActiveX does that.
2. Granted.
3. Works with all languages that look like C#. "Managed" C++ is not C++. Eiffel# is not Eiffel. J# is nearly, but not quite, Java.


If you disagree, post, don't moderate
[ Parent ]
If they don't cripple it, it could be their doom (3.80 / 5) (#27)
by czth on Wed Oct 02, 2002 at 09:12:28 AM EST

Suppose most Windows applications start being written in .NET (it never happened for Java, but with MS pushing it and the whole native widgets thing, it might happen). And suppose they really are portable. Then there goes the major reason to use Windows - the wealth of applications; now that KDE and Gnome are pretty and distributions have setups that even your everyday imbecile can get through, with the ability to run the same apps Windows has, just as "natively" - why would anyone continue to use a soon-to-be-locked-down owned-by-Bill-and-the-RIAA BSOD-generating closed source rebooting-fixes-all $100-per-incident-for-a-cheap-workaround Microsoft OS?

So they'd better start making it J++-compliant, real soon now; at least nobody will be able to sue them this time.

If I could get Photoshop for Linux (say what you will, it's clunky under wine and sorry, the GIMP isn't nearly there yet), and be able to run Outlook (for work), I'd have no reason to use Windows ever again.


Shhhhh! (4.00 / 1) (#39)
by greenrd on Wed Oct 02, 2002 at 10:20:41 AM EST

Microsoft employees read k5 too you know! If they haven't realised this yet, probably best to keep quiet about it!

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Not very probable (4.00 / 1) (#46)
by vadim on Wed Oct 02, 2002 at 10:54:27 AM EST

This sounds great, of course. I'm writing a program for my company and will try to move it to .NET if I can. It'd be nice to be able to use it, or at least parts of it on Linux. Now, it's not as easy as you think.

The program uses Crystal Reports, which AFAIK isn't a .NET program. That means that I can rewrite the whole program for .NET if I want, but it won't be able to print, until somebody comes up with a free Crystal Reports for .NET.

I'm pretty sure most programs will be the same. Most programs will be still tied to Windows, even the simple ones. If a nice component it uses is a native Windows binary you're screwed. I'm sure MS will take care of that whatever it writes in .NET runs only on Windows.

So maybe you'll be able to run Windows Calculator .NET in Linux at some point, but I wouldn't expect to have Office or games any time soon, and that probably would be too slow anyway.

<@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.
[ Parent ]

i haven't tried this myself (4.00 / 1) (#54)
by aphrael on Wed Oct 02, 2002 at 12:16:23 PM EST

but a number of other people at work have, and they tell me that the win32 API access through .NET is icky. I *have* tried the COM interop access through .NET, and can tell you that that is *slow* .... which suggests to me that component vendors will have a huge incentive to port up once their customers are using .NET.

might just be me, your mileage may vary.

[ Parent ]

built in (2.66 / 3) (#87)
by theNote on Wed Oct 02, 2002 at 09:45:39 PM EST

Believe it or not, crystal reports is built in to .NET.

If you purchase VS.NET, it is right there and integrates like crazy.

[ Parent ]
It is their salvation, not their doom. (5.00 / 2) (#77)
by ghjm on Wed Oct 02, 2002 at 03:53:16 PM EST

Office makes most of the profit for Microsoft. Windows at best breaks even. Microsoft's major leverage with corporates is not because of Windows, it is because of Office.

Right now, Office cannot be challenged in the Windows world, which is most of the PC world. On the Mac, Office is front runner but there is stronger competition. On Linux, Solaris, etc., Office is nowhere to be seen. Customers of these platforms would buy Office if they could; in fact, they go to great lengths (running software-based x86/Windows emulators, for example) just so they can run Office. However, this is not a very good solution, so there is an opportunity here for Office competitors to eke out a marginal existence by selling to users of non-Windows platforms.

It is in Microsoft's best interests to deny this market to Office competitors. If Office competitors are allowed to flourish in the outlands, maybe some of them will come up with great new ideas that will force Microsoft to expend resources copying, purchasing or killing them.

Enter .NET, which will eventually allow Office to run everywhere there's an IL interpreter. After this, OpenOffice and similar projects no longer receive code contribution from the pragmatist Open Source types; the only reason to write code for OpenOffice is out of ideological belief in the GNU Manifesto. Some people will still contribute but the overall progress of the Linux-based alternative office suites will be drastically slowed. Also, end-user acceptance will be hampered because Office is so easy to get to.

And of course, there's the .NET Framework. Just having an IL interpreter isn't good enough, you also have to have all the class libraries, widget sets, fonts, Explorer, and everything else that gives you the familiar Windows user experience. This will presumably cost money. Instead of selling Windows-on-hardware, they will essentially be selling Windows-the-GUI, cross-platform. So much for Gnome and KDE. You want a nice stable Linux box with lots of applications and a great desktop user interface? Download a copy of Red Hat plus Bonobo/IL/whatever, and buy a copy of "Windows for .NET" (or whatever the productized .NET Framework becomes).

Apple has proven Unix plus a consumer-grade GUI can sell boxes. If there's money to be made, why wouldn't Microsoft want to be the one to make it?


[ Parent ]

Good point, but... (3.00 / 1) (#79)
by czth on Wed Oct 02, 2002 at 04:07:48 PM EST

Linus didn't start writing Linux because there were no commercial alternatives (although perhaps there weren't any for the x86, so pragmatism would certainly have played a part).

A lot of people, like myself, dislike Windows because of the inability to tinker, especially the inability of fix what's broken. If I have a problem in Linux [i.e., the kernel + software like KDE, the GNU base, apps, etc.], I can get the source of everything and work my way up to the kernel itself in debugging it, if necessary. I can also change anything I want. That's very important.

And I certainly don't consider myself a raving nutter RMS follower... although I'm very grateful for all he's done and have no objections to the GPL.


[ Parent ]

True (none / 0) (#110)
by sgp on Thu Oct 03, 2002 at 11:36:29 PM EST

But, out of interest, how much have you paid for productivity software in the past 2 years? People like you (and me) are a niche market who spend little, IMHO

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

Get Ximian Connector (none / 0) (#100)
by TheLastUser on Thu Oct 03, 2002 at 09:18:41 PM EST

Ximian.org makes a connector for Evolution that allows access to all the Outlook server stuff.

In addition you get to use evolution which is just better than outlook.

[ Parent ]

Java anyone? (3.50 / 4) (#29)
by ph317 on Wed Oct 02, 2002 at 09:34:16 AM EST

.NET just pisses me off because we already had JVMs on tons of platforms.  Most of the products I use in a commercial unix environment come with Java-based management guis that are seamlessly identical across Solaris, Linux, Windows, etc.  Lots of people have various problem with the Java library copomonents like Swing - but who says you have to use them.  If you want to develop a new cross-platform language, the obvious route in today's world would have been to make it compile to Java bytecode, and supply your own set of libraries.  Java bytecode isn't Java-specific - really the bytecode/jvm side is as generic (or more so perhaps?) than .NET's IRL environment.  In this way you build on the existing JVMs.

Java bytecode is java-specific (4.50 / 2) (#35)
by GGardner on Wed Oct 02, 2002 at 10:12:50 AM EST

Like it or not, Java bytecode is very java-specific. Sure there have been some kludgey attempts at getting other languages to run in a VM, but they are all stripped-down, and don't scale.

Because the VM is "safe", there is no way to implement even C in Java bytecodes -- you can't access memory directly. The Java bytecodes have 4 ways to implement function calls, and they are all java-specific. Want to hack around that, and implement your own method calling with gotos? Sorry, goto's only work within a method, and methods can only be 64k bytecode long (oops, except for static initializers, a java-ism).

There's a bunch of other things constraining about the bytecode and the verifier, but it is very difficult to implement a full implementation of any language which is very different from Java on a VM. Unsupported research projects, or implementations with terrible performance don't count.

For all of Microsoft's sins, they sure have learned from the mistakes and success of Java, and have applied a lot of that to the .NET CLR.

[ Parent ]

Hmmm (none / 0) (#72)
by ph317 on Wed Oct 02, 2002 at 02:15:06 PM EST

Well there goes my theory.  I didn't realize it has all those java-isms, or even oo-isms. :)

What about the backend of Lucent's Inferno?  I seem to remember they had something similar to the bytecode/jvm concept, but their language was entirely different.  In any case even if it was good for the task it's probably wrapped up in AT&T licenses and/or patents.

I think I have my next major programming project now :)  Write a JVM-ish thing that's a more generic bytecode language, closer to what a real processor has in terms of asm.

[ Parent ]

Other languages run fine on the JVM (none / 0) (#74)
by phliar on Wed Oct 02, 2002 at 03:28:55 PM EST

... there have been some kludgey attempts at getting other languages to run in a VM, but they are all stripped-down, and don't scale. ... Java bytecodes have 4 ways to implement function calls, and they are all java-specific.
Consider Jcon, an implementation of Icon on the JVM. This is a full implementation of a very complex language (especially with regard to function calls!) -- nothing "kludgey" or "stripped down" about it.

Plenty of people around the world use Icon; it's not an "usupported research project with terrible performance." C is not the only other language out there.

Faster, faster, until the thrill of...
[ Parent ]

Considering Jcon (4.00 / 1) (#81)
by GGardner on Wed Oct 02, 2002 at 04:44:26 PM EST

Jcon is a perfect example of what I'm talking about. As far as being an "unsupported research project with terrible performance",

1.) It is research project at the University of Arizona, and as such is not commercially supported.

2.) Jcon is substantially slower than the C-based traditional Icon interpreter.

3) Jcon can't run Icon procedures that are long, (thousands of lines) due to static limitations of the bytecode structure. Maybe you don't want icon procedures to be thousands of lines long, but this is common for machine-generated code (e.g. parser generators).

4) Jcon works by generating a separate class with one method for each icon procedure, with potentially huge vtable overhead.

As the jcon implementation paper says, there are several missing features in the java bytecode which would make the jcon runtime much more efficient and easier to implement. Like it or not, the .NET runtime was designed with more than one language in mind, and does have support for things like function pointers, which will make it a better target than java bytecodes for things like jcon.

[ Parent ]

Why is commercial support needed? (none / 0) (#85)
by phliar on Wed Oct 02, 2002 at 08:19:12 PM EST

I will concede that Jcon is slower than regular Icon. I don't think no. 3 is significant -- no function, let alone an Icon function, should be thousands of lines long. I have trouble picturing program-generated Icon functions that are thousands of lines long. Is no. 4 -- vtable overhead -- significant in normal use? My feeling is that it isn't, although I could be wrong, I don't use Jcon on a regular basis.

Your objection no. 1 is the one I find most interesting. The Arizona Icon immplementation is one of the most bug-free systems I have seen. (TeX is the most bug-free.) Ralph Griswold is a stickler for correctness, and mail to icon-project@cs.arizona.edu is still answered although The Icon Project is officially dead. The language book and the implementation book are excellent. Why is commercial support a make-or-break issue? Microsoft itself is not a company I'd hold up to support this.

Incidentally, Todd Proebsting -- the guy behind Jcon -- is now at Microsoft Research, as are people like Dave Hanson and Chris Fraser who have Arizona and Icon roots. Also, Cats Paw used to -- until recently -- offer a commercial version of Icon.

Faster, faster, until the thrill of...
[ Parent ]

Jcon (3.00 / 1) (#88)
by GGardner on Wed Oct 02, 2002 at 10:11:03 PM EST

Incidentally, Todd Proebsting -- the guy behind Jcon -- is now at Microsoft Research

I'm familiar with his work :-) In fact, the last time I talked to Todd, he had many unkind things to say about the design of Java bytecodes. (Not surprising, if you've ever talked to him).

As far as commercial vs. research, it's not that research programs tend to be buggier than commercial, but their goals are different -- usually it is "can this be done at all"? Yes, there are a lot of university projects to target some random programming language to the Java VM, but that just means that it can be done, not that it can be done efficiently, or in a way that the users of those programming languages would prefer.

[ Parent ]

Ah, yes! (none / 0) (#89)
by phliar on Wed Oct 02, 2002 at 11:40:57 PM EST

:-) In fact, the last time I talked to Todd, he had many unkind things to say about the design of Java bytecodes. (Not surprising, if you've ever talked to him).
Heh heh! I have fond memories of Todd from my dissertation defense. He had a couple of unkind things to say about it.

(BTW, I guess this is your official notification that I concede the entire argument about the JVM. I understand your points and agree.)

Faster, faster, until the thrill of...
[ Parent ]

The JVM is a traditional VM (5.00 / 1) (#92)
by Simon Kinahan on Thu Oct 03, 2002 at 05:36:08 AM EST

If you look at Lisp and Smalltalk VMs, they typically lack many of the facilities you mention too. The JVM is only different in that its bytecode and architecture are very skewed towards Java itself, rather than just towards safe, OO languages. There are more generic VMs, but they typically won't let you jump between methods either.

The CLR is a bit different. If you examine the spec, it is pretty clear that there are 2 distinct classes of op-codes. There are high-level ones that are only suitable for implementing safe, OO, single dispatch, single inheritance languages like C# and Java, and low-level ones that let you do pretty much anything a conventional CPU architecture can do.  


If you disagree, post, don't moderate
[ Parent ]

Why? (4.00 / 2) (#50)
by DeadBaby on Wed Oct 02, 2002 at 11:06:51 AM EST

You realize by doing this Microsoft would make themselves Sun's sweet little bitches right? Why would any company the size of Microsoft take that risk?

What it comes down to is, they had the money and the time to develop an entirely new language and VM so they didn't risk being boxed in by Sun, who's just as ruthless and blood thrusty as Microsoft themselves.

"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]

There's competition in JVMs (none / 0) (#70)
by ph317 on Wed Oct 02, 2002 at 02:12:12 PM EST

Aside from Sun there's some freeware ones and of course IBM's.  It's just the java language and libraries that more in Sun control.

[ Parent ]
just in time compliation (none / 0) (#119)
by bored on Tue Oct 08, 2002 at 11:21:04 AM EST

No one mentioned the fact that java's JVM is incredibly hard to compile out to native code. This is one thing that microsoft apparently used as a requirment for their platform. By itself this should result in a nice performace diffrence between the .net applications and java applications.

[ Parent ]
Performance of Java/.NET on Itanium? (4.50 / 2) (#45)
by GGardner on Wed Oct 02, 2002 at 10:49:47 AM EST

Does anyone have any performance comparisions of dynamically compiled languages like Java and C# on Itanium, compared to those same languages on conventional processors?

Both Sun and Microsoft have announced implementations of their environments for Itanium, but any time you ask about performance, they both get very quiet very fast. It's taken a lot of work to get Java VMs to run as fast as they do now on conventional CPUs. How much more work (if possible) will it take to get them running effectively on Itanium?

The Itanium and its EPIC architecture were designed right before dynamically-compiled languages like Java and now .NET became popular. Itanium requires a ton of compiler magic in order to extract the theoretical performance.

If Intel wants Itanium to compete with SPARC in the high-end data center, this would appear to be a huge stumbling block.

IIRC (3.00 / 1) (#63)
by DeadBaby on Wed Oct 02, 2002 at 01:36:49 PM EST

C# was designed from the ground up with the IA64 in mind.
"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
Why Microsoft needs .NET... (1.50 / 2) (#53)
by dvchaos on Wed Oct 02, 2002 at 11:59:37 AM EST

That answer is obvious, to help further their 'evil' plan for world domination of course, duh.

RAR.to - anonymous proxy server!
Anyone remember the bastard NT port? (2.66 / 3) (#60)
by Hired Goons on Wed Oct 02, 2002 at 12:46:49 PM EST

I'm talking about Windows NT on PowerPC. I believe it existed in the marketplace for about 5 minutes back in 1997 or thereabouts. Or maybe my old university had it as a test project. Anyway, it existed. I used it, it worked, etc. etc. etc.
You calling that feature a bug? THWAK
NT ran on 4 platforms (5.00 / 2) (#83)
by bill_mcgonigle on Wed Oct 02, 2002 at 06:23:13 PM EST

MIPS, PPC, Alpha and x86.  They're all on the NT 4 CD (pre-sp3).

Back then, the Microsoft sales reps promised NT4 for PPC would be supported for n number of years to come.  We were in the process of putting through an order for a couple thousand PPC machines to run it (Apple also promised support for these PReP machines) when news came down about Microsoft transferring development responsibility to Motorola.  Motorola balked at having to write Microsoft's software for them, so it was dropped.  Microsoft reps replied, "*We* didn't drop it, Motorola did."  Whatever.

MIPS had gone previosuly and Alpha did a year later.  The Alpha port even had FX32 technology, a dynamic recompilation emulator for x86 binary code that approached then-current-Pentium speed.

NeXT proved it's easy and succesful to ship multi-platform binaries in a single bundle, and that could have happened with NT.  .NET isn't the easiest or most straightforward way to get multi-architecture support.

Ah, well, had a few planets been in different alignment, I might be running OSX and WinXP on the same machine today.  

[ Parent ]

PPC port (none / 0) (#118)
by bored on Tue Oct 08, 2002 at 11:14:16 AM EST

I know a couple people who used the PPC version of NT. They claimed it was _REALLY_ slow. This probably had something to do with it getting dropped.

[ Parent ]
Slow PowerPC (5.00 / 1) (#124)
by longjohn on Fri Oct 18, 2002 at 12:03:01 AM EST

I was one of the developers working on the PowerPC edition of Windows NT. I really liked PowerPC; it is a very good architecture. Unfortunately we had three problems.

First, the calling standard for PowerPC was designed for AIX, and wasn't optimal for Windows NT. We had to make sure R2 (rToc) was set correctly for every call. This meant that every indirect call or DLL call was much slower than on x86. Since Windows is mostly DLLs, this hurt. (It is worth noting that Windows CE on PowerPC didn't do this.)

Another problem was that our compiler technology wasn't mature. The PowerPC port used three different compilers: first a research compiler from IBM, then a third-party compiler adapted by Motorola and finally a variant of the Microsoft cross-compiler for the Macintosh. We were working on a new compiler (based on the same code still used for the Visual C++ compiler) when the whole project was cancelled.

The most fundamental problem was that we simply didn't have enough buy-in from upper management at Motorola and IBM. We needed five years to make PowerPC a success. We got three. At the end Motorola wasn't making money from their desktop PowerPC machines and wanted to make consumer devices like cell phones. IBM was destracted with Network Computers. (Remember them?) What we really needed was a single computer that would run Windows NT and MacOS, and we were still about six months from having them when the plug was pulled. Oh well.

[ Parent ]

this is an interesting thought but (4.00 / 3) (#61)
by metagone on Wed Oct 02, 2002 at 01:25:47 PM EST

I do still think you need to analyze MS products in terms of intent and not capability. In business it is intent more than anything that determines what flies and what doesnt. If the capabilities provide ways to further one's intended plan then most likely this capability will find a way to be turned into a product.

What i see here is a discussion of capability that would benefit any .com that owned it. But what is MS intending here? at the very least it is to make profits. possibly they want the profits to remain solely in their hands and the hands of their allies.

Now i do not understand anti-trust law, but i understand that a .com is generally not allowed to do it. that is monopolize the market. Possibly, MS will distribute the monopoly along its alliance framework. Basically if you on the MS side then you get to share in a small but good percentage of the overall profits. The result is that MS moves further and further away from the front of the store to inside the infrastructure and slowly replaces the old infrastruct cells with new and improved MS cells. Biological cells not terrorist cells. MS continues to make software and this remains their primary source of revenue, but they now also own a majority of the computing infrastructure. No need to own the market by force. People will flock to you because you provide everything they need. You arent blocking out competitors because the technologies you are peddling potentially benefit developers. Slowly MS redefines the industry by innovating new ways to do business. innovating here is a relative term, but you can possibly see a positive spin (for MS).

In the long run, MS still makes loads of money and they have firmly secured a niche that will not disappear anymore because the term computing is practically synonymous with MS. Think Sofware or Computing eXPerience, Think MS.

It is subtle and and seems like MS is the bad guy. But it is all very skillful business. They almost got in serious trouble with the anti-trust stuff, but i wouldnt be surprised if this wasnt used as a signpost to galvanize the employees and then start implementing the next phase of the MS master plan. Because they do have a master plan make no mistake. What is the master plan? unless we get an insider, we can only infer from the observable evidence or basically every time you see MS in the news that is evidence to be analyzed and then somehow some really smart person will need to synthesize the master plan from that. I am sure it is possible just very hard. But as i said in the beginning at the very least MS is just trying to make more money in a  surer way. So long as the money keeps flowing the rest of the empire will keep running. And it is an empire make no mistake.


Computing Synonyms (none / 0) (#113)
by Captain Bonzo on Fri Oct 04, 2002 at 05:36:05 AM EST

In the long run, MS still makes loads of money and they have firmly secured a niche that will not disappear anymore because the term computing is practically synonymous with MS. Think Sofware or Computing eXPerience, Think MS.
I can't see this without thinking that until not long ago (about 15 years or less?) IBM was pretty much synonymous with computing. Empires can fall as well as rise.

That said, I agree it will probably take some time to knock MS of their pedestal. They seem to be more in the driving seat that IBM were during their fall from grace (even though MS's navigation might be somewhat unfriendly!).

[ Parent ]

PC = IBM (none / 0) (#114)
by metagone on Fri Oct 04, 2002 at 10:31:35 AM EST

even our language has changed as a result. and IBM still makes significant revenue selling computers. They might not be as big as Compaq/HP, but are still up there.

But IBM failed as an empire because they weren't as adaptive to the markets they were in. MS moved in like a cancer. Now the industry depends on this cancer. If MS hikes up the prices people still buy their products it is simple economics. As the value of the product increases either increase distribution to cut costs or increase the price to increase profits. MS has a wide distribution. Their products are already expensive.

But even if MS dies, the lasting changes it made to the market and industry as a whole will recreate it. That's the punch right there. The industry sustains MS. It would be extremely hard to get rid of MS harder than finding a cure for AIDS. well...i am exaggerating, but you understand my point. Every i use and MS product i am giving MS another reason to persist. It is the worst kind of drug because it is a helpful drug that is addictive as well. You would think that would make the drug a good one, but what this drug does it make you dependant. You dance to the MS tune. sure you can demand a particular product, but they don't care, they'll let some third-party ally to supply that demand. They are already plugged into the main arteries. I am telling you, MS's business practises are simply sweet from that pov.

Clarisworks can not even compete with Office. at the very least you compare it with MS Works. But even MS Works kicks ass. i mean can you not hear the subliminal here? MS works. it might go unnoticed with Claris because it is not part of their strategy but with MS it adds up. Works, Office, Outlook, Access, Projects etc.

But you are right, MS can fall. What might take its place might be worse though. IBM -> MS -> BigEvilCo? frightening thought isnt it? So we are trapped trying to sustain MS as long as possible, but it seems that MS is becoming BigEvilCo. damned if you do or dont.

But it is all business, so they arent really BigEvil, just ReallyCunningCo.
[ Parent ]

If everything is compiled at install time..... (3.00 / 1) (#66)
by steveftoth on Wed Oct 02, 2002 at 02:02:42 PM EST

think about how long it would take to install a program if you had to compile it when you installed it.  SOme of us already know this sucks if you are running Gentoo or some other os that has this option.  Or if you are just HardCore and compile everything.

Office already takes awhile to install, what if you had to compile it as well as copy all the files?  That will take forever, hours probably.  So many developers will still want to generate a binary version of their code.  

Yes, it's a little fuddy, but it's also the reality.  You have to test your software to make sure it works.  To make sure the test enviroment is the same as the deployment enviroment is a huge deal.  This is the reason that a lot of programs include their own versions of shared dlls in windows, like mfc and whatnot.  Because if they didn't then sometimes it might not work.  

The new framework is supposed to solve this problem of versioning.  I haven't dealt with it yet, so I'll be glad to hear if it works flawlessly.  

Re: If everything is compiled at install time..... (4.75 / 8) (#75)
by ghjm on Wed Oct 02, 2002 at 03:34:01 PM EST

Yes, compiling at install time makes installs slower. However, it also makes your system more stable overall because it eliminates library inconsistencies, given appropriately portable code (autoconf for windows anyone?)

However, this is not anything remotely similar to what is being proposed. Under the .NET scheme, you distribute BINARY code, compiled to IL. Each computer has an IL interpreter that runs all your BINARY applications.

The point is this. Suppose some chip company comes out with the Magic CPU of Godlike Speed. You, Joe Sixpack, want to put down $2000 cash on the barrel and receive a shiny new Office Depot MCGS PC. You want this because you will never have to wait for your computer again. Whatever you tell it to do, it will just do, instantly. Solve the halting problem, whatever.

Except you have all these Windows applications. You want to be able to run Age of Empires (American Imperialism Edition) and Warcraft VI and Quake IX. And of course you want to be up to date on all the latest pr0n standards like Super Ultra Extreme Video CD (SUX-VCD). Oh, and maybe you also want to install a pirated copy of Microsoft Office 2009 so you can vaguely think about maybe typing a resume when you lose your job.

When the MCGS PC got to your house, you discovered that only MS Office actually works in native mode, everything else requires you to run it in compatibility mode (whatever that is), and it's way slower than even your old, obsolete Athlon XP 3000+. You spent $2000 for nothing! MS Office is indeed a little faster (if you remember to disable Auto-Write-Essay-On-Unrelated-Topic), but you don't even notice that because you're too busy looking at the pr0n.

What Microsoft is trying to convince us all to do is start writing applications for IL instead of any real CPU. That way, *everything* runs in compatibility mode, *all the time* !!! That way, programmers don't have to write well-designed, portable code; application companies don't ever have to recompile; and nothing you ever do can actually run on bare metal any more! It's so obvious that this is a great idea that nobody can actually explain what's so great about it.

Oddly enough, it's the exact same plan that Sun wanted us to follow circa five years ago. If Microsoft had gone along with it then, we'd be there now. Why is it a good idea when Microsoft does it but a bad idea when Sun does it? Presumably because Microsoft sees owning the platform as in their strategic best interests.

If this really was the Ultimate Good Idea, then we would all be running on top of UCSD p-Code. The idea of a universal virtualization layer is one of those things that the computer industry re-invents every few years, like remotely accessing a computer, encrypting your disk files, or sending messages to other users. Perhaps having the full weight of Microsoft behind it means that this wave of the cycle will actually achieve dominance for a while. If so, then I predict a booming market in the 2010s for people selling "native instruction set accelerator cards" and the new buzzword will be NIS - golly, your code can run right on the bare metal! It's so fast it's hard to believe! Another amazing innovation brought to you by the power of the monopolistic free market!

Oh, and by the way - COM, which is a defining feature of Win32 and was introduced eight years ago, quite adequately solves the problem of DLL versioning. DLL versioning was a big issue on Win16. The only reason that DLL versioning has ever been a problem on Win32 is that applications vendors typically are apparently staffed by australopithicenes - a primate that walks upright like a human, but posesses the brain size and cognitive development of a great ape. "Nurg no like changing GUID when interface signature change. Nurg have to handle calls on prior version interfaces if Nurg have installed base of customers. That no fun. Nurg not remember what Nurg already sold, that a job for marketing. Nurg like develop new code but use same GUIDs. Nurg also like reboot when install stuff." But perhaps that's giving too much credit to applications vendors.

There's no need for .NET to solve DLL versioning, because COM already solves it; or conversely, there's no point for .NET to attempt to solve DLL versioning, because applications vendors will find a way to reintroduce it.


[ Parent ]

Ok, maybe I wasn't clear. (5.00 / 1) (#96)
by steveftoth on Thu Oct 03, 2002 at 12:33:30 PM EST

.Net has this feature whereby all IL code is compiled to native code when it is installed to your computer.  This is not a runtime deal, it's done before you actually run the app.

So what happens is that the developer compiles their source to IL, which can then be intrepreted or compiled to native x86, Alpha, whatever code.  Upon install in a client, the installer can force the client to compile it to native code so that it will run faster.  

If they actually do it is another matter, I think that developers will continue to write code that will be compiled down to native code before the client sees it and not bother with this IL stuff since native code is faster.  The only advantage that IL code has is that you can take the same binary file ( jar or assembly ) from one platform to the next and it should work.  However, since there is only one real working implementation of the .Net framework and it only runs on one platform, what is the point of IL code at all when all the developer wants is the maximum speed?

There is no way that any Windows developer would ever distribute their real source, that would reveal all the GPLed code they use to make their product. ;)

[ Parent ]

IL code is never interpreted (none / 0) (#131)
by Nurgled on Thu Dec 26, 2002 at 12:38:43 PM EST

According to Microsoft, there is no Virtual Machine for IL bytecode to run in. Microsoft's stuff always just-in-time compiles code before it runs, and in some cases the compiled code can be cached so that next time it runs it'll start up pretty fast.

I'd not heard about the compile-cache stuff being done at install time, but I guess that's a reasonable thing to do.

Compiling from bytecode is theoretically faster than compiling from human-readable source anyway, because the tokenizing stage is removed: all instructions are in a standard format which the compiler can rely on.

[ Parent ]
Who cares ? (1.66 / 18) (#68)
by Phillip Asheo on Wed Oct 02, 2002 at 02:04:01 PM EST

All this technical mumbo-jumbo about hardware abstraction layers and virtual machine runtime environments is all very well, but joe-sixpacks like myself, and the vast majority of computer users could care less about it.

At the end of the day, we just want it to work. We don't want to edit our /etc/resolv.conf file simply to read email. We have no interest in "recompiling our linux kernal" all we want to do is read e-mail and surf the web in peace, without being accused of sucking Bill Gates dick by the unwashed basement-dwelling virgin Linux-user crowd.

thank you.

"Never say what you can grunt. Never grunt what you can wink. Never wink what you can nod, never nod what you can shrug, and don't shrug when it ain't necessary"
-Earl Long

Interesting. (4.57 / 7) (#86)
by it certainly is on Wed Oct 02, 2002 at 09:15:32 PM EST

You used Standard Linux Troll #156 (novice editing obscure config file), Standard Linux Troll #163 (novice recompiling linux kernel) and Standard Linux Troll #53 (unwashed hippy / parents' basement). An intriguing combination not seen since last Wednesday on Slashdot.

While I admire your attempts to remind me what Slashdot looks like at -1, I respectfully suggest that you learn how to write original material.


kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Well spotted. (3.66 / 3) (#97)
by Phillip Asheo on Thu Oct 03, 2002 at 02:01:54 PM EST

This particular trolling style is well documented in spiralx's excellent troll "How To". It's known as the "indifference troll". Its highly effective at pulling in people who _care too much_ about any given subject, in this instance, operating systems. Fortunately this is not slashdot, and the people here are far too intelligent to be taken in with a crude troll like this.

Unfortunately for them, this is not in fact a troll, rather it is my genuine position. I really don't give a shit.

"Never say what you can grunt. Never grunt what you can wink. Never wink what you can nod, never nod what you can shrug, and don't shrug when it ain't necessary"
-Earl Long
[ Parent ]

It's not just indifference. (none / 0) (#103)
by it certainly is on Thu Oct 03, 2002 at 10:42:49 PM EST

Perhaps you intended to write an indifference troll, but were so bored by the third sentence that you decided to change tack and call the Linuxistas elitest ("accused of sucking...") then immediately slur them as unwashed hippies. I'd hardly count that as indifference.

Unfortunately for them, this is not in fact a troll, rather it is my genuine position.

How's kernel support for XML these days? You said it's an essential feature if Linux is to be taken seriously on the desktop. BSD wasn't taken seriously on the desktop, and now it's dead. What fate is in store for Linux?

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

I do it by numbers. (5.00 / 1) (#116)
by Phillip Asheo on Mon Oct 07, 2002 at 03:26:32 PM EST

I have a pearl script that takes various key topics from the flat file version of the old adequacy.org "troll resource database" and randomizes them. In this instance it came up with an indiffernce theme, but quaintly threw in the unwashed/never got laid/basement dwelling insults as well.

I had intended to re-write the script in Python in future to avoid these kind of bugs, but when I looked at the script a week after I wrote it, I could not actually work out what it did in the first place, such is the utter suckiness of pearl. I also wanted to port it to the MySql version of the troll database, but I looked at MySql, and decided it sucked. I may yet port the db to Sybase though, and then we may see some quality auto-generated trolls coming through.

"Never say what you can grunt. Never grunt what you can wink. Never wink what you can nod, never nod what you can shrug, and don't shrug when it ain't necessary"
-Earl Long
[ Parent ]

Obscure code (none / 0) (#130)
by OneEyedApe on Thu Dec 26, 2002 at 12:37:21 PM EST

...but when I looked at the script a week after I wrote it, I could not actually work out what it did in the first place...

This is what comments are for.

[ Parent ]
No (none / 0) (#122)
by epepke on Mon Oct 14, 2002 at 10:27:02 PM EST

No, that's not what most people want. The only people who really just want it to work are artists and musicians, and they buy Macs.

What most people want is one of the following:

  • Whatever it is they have at work so that they can do their work at home (and swipe software from work)
  • A Computer

The truth may be out there, but lies are inside your head.--Terry Pratchett

[ Parent ]
Ulterior Motive (3.50 / 2) (#78)
by aechols on Wed Oct 02, 2002 at 04:06:00 PM EST

Has there ever been a Microsoft product that has not had an ulterior motive?

Are you pondering what I'm pondering?
Ulterior Motive? (none / 0) (#94)
by Matrix on Thu Oct 03, 2002 at 07:43:00 AM EST

Err... Hmm... MS Bob. If they had an ulterior motive for that one, it was the dumbest ulterior motive ever.

"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Test of strength?! (none / 0) (#109)
by sgp on Thu Oct 03, 2002 at 11:24:50 PM EST

"If we can get away with this, we can get away with anything.... Mwahahhhahhhahhahhaahhh!"

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

Nah... (none / 0) (#117)
by aechols on Mon Oct 07, 2002 at 09:00:46 PM EST

If anything that would be the "we cant remove ie from windows" bs. I'm thinking more along the lines of a testbed for other future mind numbing applications.

Are you pondering what I'm pondering?
[ Parent ]
Yeah ... (3.50 / 2) (#80)
by Simon Kinahan on Wed Oct 02, 2002 at 04:09:10 PM EST

I've been wondering if this might be the other half of Microsoft's game-plan for .NET. Obviously right now the important thing is to get up Sun's nose, but I wonder if portability might be important in the future.


If you disagree, post, don't moderate
In part... (5.00 / 1) (#82)
by bsletten on Wed Oct 02, 2002 at 05:52:58 PM EST

I think it is hard to classify the intent behind .NET because it is hard to classify .NET. Microsoft has even gone on record as saying that they are still kind of figuring out what the services side is supposed to be. Rather than one specific motivating factor, it was probably more likely that a combination of Java, Linux and a desire for recurring revenue streams nudged them closer toward the designs that have emerged. Keep in mind that most of this work was done during the DOJ trials. It wasn't entirely clear what their future would be as one or more companies. They have successfully planned for most contingencies with this new architecture.

Their OSes are mostly their leverage points to force application (read "cash cow") upgrades. As people started to respond favorably to the idea of freeing themselves from the shackles of Windows, Microsoft needed a strategy to prepare for that possibility.

As people started responding to the improved productivity of both the Java language *AND* the APIs, they needed a strategy to deal with that. As they edged closer toward universal domination, they needed new ways to maintain revenue streams and instigate growth into new domains (i.e. handhelds, other hardware architectures). Recurring software licenses and platform independence are both means toward those ends.

In trying to pin a coherent vision on Microsoft for this, I'm reminded of Coke's reponse to accusations that Coke Classic was a marketing ploy. "The truth is, we're not that stupid and we're not that smart." Say what you will about Microsoft, I think they have shown themselves to have strong survival instincts and I think that they've responded to multiple threats successfully.

The real reason for .NET (2.00 / 5) (#84)
by Big Sexxy Joe on Wed Oct 02, 2002 at 06:28:31 PM EST

Computers get faster and faster all the time, so it is very challenging for MS to find ways to keep your computer running slowly. If they run everything on a virtual machine, they can keep your computer as slow as they wish.

Seriously though, I do think they want to slow your computer down so you'll quickly buy a new one (with Windows and other bundled software).

Good article, by the way.

I'm like Jesus, only better.
Democracy Now! - your daily, uncensored, corporate-free grassroots news hour

Good plan... (3.00 / 1) (#90)
by k31 on Thu Oct 03, 2002 at 01:37:20 AM EST

And one that the Linux folks might follow to circumvent issues like the lib5/glibc2 upgrade problem (which I know little about, so flame away).

On a more serious note, console makers could use similar techiniques... but probally won't because of the "cheap at all costs" mentality their hardware exhibits.

Your dollar is you only Word, the wrath of it your only fear. He who has an EAR to hear....

Limited experience (4.50 / 2) (#99)
by Silent Chris on Thu Oct 03, 2002 at 04:27:13 PM EST

So far, in my fairly limited experience coding with .NET, I like it.  I do agree with one Microsoft claim: it helps steer away from a lot of foibles that (admitedly) should never have occured with Windows in the first place.  The IL was obviously created by academics, because it is clean, has great documentation, and code compiles well (by "compiles well", I mean you get very descriptive explanations from the compiler about problems, and exceptions are actually useful if a program crashes).

.NET is an uphill battle for Microsoft.  It's definitely slower than using the old Win32 APIs (especially the first time a program runs, when a lot of the assemblies are registered).  Some of the languages are a joke: J++ is not worth learning, and C++ with Managed Extensions is almost painful.  Still, it's a step forward, and I credit them with that.

What MS means by "Cross Platform" (3.00 / 2) (#101)
by TheLastUser on Thu Oct 03, 2002 at 09:31:14 PM EST

What they really mean is that it will work on any MS platform, winCE, win32, etc., it will be a cold day in hell before MS does a VM that will allow stuff to run properly in Linux. Mono will always be the poor cousin to .Net on win32.

Its beyond me why people would consider using .Net instead of Java when it offers nothing new. I will switch to .Net when MS gives me something more, that means "real" cross platform VM's, like Sun supplies with Java, and then I want something new, something I don't already get from Java. I don't choose my tools based on marketing brochures.

Don't belive the hype (none / 0) (#112)
by codemonkey_uk on Fri Oct 04, 2002 at 05:05:50 AM EST

Have you actually tried to deliver a Java application across multiple platforms? You end up having to ship the godamn VM with it, and even then it's a bloody nightmare.

The idea that Java is Write Once Run Everywhere, or that it solves the platform problem is a complete myth.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Bullshit (none / 0) (#115)
by TheLastUser on Fri Oct 04, 2002 at 02:02:52 PM EST

Yes I have coded many cross platform apps in Java.

I run a site that has a Solaris staging server and Gnu/Linux production servers. I used to use Sun's JDK 1.3.1 on the staging server and then simply sync my content to Linux/IBM SDK 1.3. I NEVER once had a problem with VM differences. I ran this way for about a year before upgrading to Sun's 1.4 JDK on all machines.

I have also written a bunch of client apps and applets. The only problem I have ever had with VM's is when I used to write stuff for the MS VM, it never ran properly anywhere else, without more work.

Cross platfom computing is not automatic, you have to take into account the differences in the clients, i.e. Macs have only 1 mouse buton, win32 has multiple filesystem roots, etc. In my experience making a project run cross platform takes no more than 5-10% extra effort.

Sure, its not automatic, but its a hell of a lot easier than with C.

And as for the cross platform proporties of .Net, well all I have seen so far is some MS marketing docs. Seems to me that Java is great deal further down the road on this.

[ Parent ]

Microsoft "world domination" et al. (2.00 / 1) (#120)
by Luminion on Wed Oct 09, 2002 at 01:37:31 AM EST

First and foremost, I am surprised to see that the article fails to mention the DotGNU project which is very serious about creating a FREE .NET platform and has some really brilliant people.

Second, I am also surprised that the article fails to mention that .NET IL (as well as libraries around .NET and other stuff) is fairly well documented and standardized; C#, despite of all geek fingerpointing and bitching, is a language no weaker than Java and that overall it is pretty hard for Microsoft to "close" .NET, "conspire" against its users, "embrace and extend" blah blah blah blah. .NET is not a winmodem driver. It can and probably will be replicated in Free Software; and, all geek whining aside, it's a good technology, not perfect, but way more promising than todays grab-patch-compile-with-optimizations a'la Gentoo et al. You should understand that while we geeks like to have everything under our control (I personally run highly optimized Gentoo on desktop, and Debian on the servers), other people just don't have that need, and the benefit for them (and in general) is at least obvious.

I really suggest you talk to .GNU people before jumping to conclusions about how counterproductive/evil/misleading .NET is. Even though there is abuse potential in Microsoft's proprietary implementation of .NET, the technology itself is not as bad as everyone tries to paint iy lately.

I believe it is the time for us to have our software standardized. I don't mean that we should sell our ass to Microsoft, hell no, and I don't want to deprive anyone of choice, hell no, but do we really need a zillion of incompatible (or worse, semi-compatible) platforms and not a single way to write a 100% code?
<spanisman> you are really a dork and I'm going to complaint against you in the undernet society for you to get lost the op status

POSIX (none / 0) (#127)
by WebBug on Thu Oct 31, 2002 at 06:17:27 PM EST

need I say more?
-- It may be that your sole purpose is to server as a warning to others . . . at least I have one!
[ Parent ]
Why Microsoft needs .NET -- Itanium, Security, IP (3.00 / 2) (#121)
by OldCoder on Wed Oct 09, 2002 at 02:06:25 AM EST

One of the reasons Microsoft is heavily invested in .NET may well be the protean nature of the Itanium series of processors. The Itanium roadmap calls for the compilers to know which version of the chip it is compiling for, in order to get top performance.

A major concept of EPIC is that CPU scheduling is done before program execution, rather than during, as the RISC chips do. This is supposed to be one of the advantages that EPIC will have over RISC.

If you download an IL (.NET) applet, or install a .NET program, the installer can compile-from-IL upon installation. If chips get faster more rapidly than apps get large, then this is easily an overall win. (I nearly said a net win).

I guess Java could do this too, but for some reason the Java community is married to byte-code interpretation rather than compiling to machine code. (There are exceptions, I know).

As a historical note, it is clear that the good experience (good performance) MS got from the JIT compiling of its Java system was a motive for following this route.

Also, it might well be easier to make .NET secure than the win32 API. And security has become very big at MS. The managed memory model, for example, precludes buffer overruns. But buffer overruns are not enough of a security reason by themselves. Perhaps the .NET "Message Pump" is more secure.

New Platforms
Microsoft could also produce an Operating System that supports only .NET, and not the Win32 API. This could conceivably be faster and/or smaller than the current offerings. If so, it would probably be based on the NT kernel (aka the XP kernel), although it could be built on top of BSD, if they like. If Microsoft goes this way, I'd guess we'd see it first on servers or portables, and only later on desktops, if ever.

Intellectual Property
A box with the CLR in ROM and a secure, encrypted Activation system, might be a good counterattack against Piracy, especially in places like China and India where the rules are a little looser. Lots of customers there.

By reading this signature, you have agreed.
Copyright © 2004 OldCoder

Ownership (none / 0) (#128)
by WebBug on Thu Oct 31, 2002 at 06:23:13 PM EST

That is basically my objection to the whole .NET thing.

Microsoft owns the .NET runtime interpretter, has it sewed up in intellectual rights, and has no intention of allowing anyone else a hint of that control.

It also allows them to insert whatever system of "rights management" they choose.

I just don't trust MS to do something that would make my life easier buy cost them or their supporters revenue.

For example, being able to make a quick copy of my CD's so that the original remains in pristine  condition.

It's a HUGE issue.

-- It may be that your sole purpose is to server as a warning to others . . . at least I have one!
[ Parent ]

the swamp of middleware (2.00 / 1) (#123)
by christfokkar on Tue Oct 15, 2002 at 07:14:17 PM EST

I don't like VM's.  Part of me still likes dropping into a dos prompt, where the 80x25 scroll is as familiar to me as walking.  It's why I still sometimes play videogames, even though I'm too old - every byte is a known quantity, and it's hard not to appreciate the tightness of the experience.

There are good reasons for this besides hobbyist enthusiasm.  Performance and reliability require knowing as much about the system as possible.  If you don't feel that these are priorities, then I question what you really know about computing.

Programming is the art of singularly knowing every line of code and every logic branch in the system.  It's not a theoretical ideal but an actual one.  The computer doesn't know about bugs any more than a quilt knows about tattered threads or misplaced colors.  It's up to you.

Thus, a VM is code that I would have to understand anyway, and the shock of installing some of these 50mb VM's is more than I can bear.

What's the use?  Well, VM's allow for rapid prototyping of compiled software.  With the right VM, perhaps I can write a 3-line version of a 10,000-line program.  But it's going to be slow, and it won't do very much.

In turn, software allows rapid prototyping of hardware (notice how all those mid-80's graphics routines are now on-die?)  And hardware, of course, is for rapid prototyping of reality.

It's a tree of technologies, with greatest prototyping speed at the leaftips, and greatest performance at the trunk.  The question becomes, just how far removed from the earth do you want to be?

Big projects (none / 0) (#125)
by mozmozmoz on Wed Oct 23, 2002 at 12:37:53 AM EST

Programming is the art of singularly knowing every line of code and every logic branch in the system.

In the olden days, this was actually possible. But some of us now work in teams of more than one person, and have to deal with legacy code written more than a month ago, in projects that run for years and produce hideously complex programs. Any of those factors generally rules out intimate knowledge of the whole system.

Hence the invention of structured programming, and the continued development of ever more extreme versions of information hiding prgramming styles.

Many of us actually have to write code that runs on an operating system, so we generally can't know the whole system anyway. Let alone using modern processors that run microcode that we can't even get physical access to.

There's lots of comedy on TV too. Does that make children funnier?
[ Parent ]

An Inside View (3.50 / 2) (#126)
by EarWax on Fri Oct 25, 2002 at 07:47:01 PM EST

Okay so I work for Microsoft but I am not representing Microsoft in this post in any official capacity what-so-ever. Just my humble opinion of course :-) There are many reasons why Microsoft needs .NET. I'll outline what I think are the most important and make a couple of other comments. 1) Productivity. You can write better apps faster in .NET than using Win32 and our previous toolset. The framework just makes more sense. It's easier than COM. The programming model is what counts. 2) Tool innovation. We can put all our effort behind one framework and runtime rather than repeating efforts for a C++ IDE and a VB IDE etc. Language innovation will continue. Better tools make a big difference. Again, this boils down to productivity. 3) Performance. Yep, many think that in the long runtime we can get the best performance from .NET apps. Memory allocation from the heap in .NET easily outstrips C++ alloc. Upgrading to more powerful chips in the future is easier. Downgrading to less powerful chips and constrained memory is also easier. We can improve the performance of an installed base of apps by improving the CLR and JIT compilers. So I agree with the original article but it's just one of the reasons and not the "real" reason. 4) Portability. Yes, we have the option to move to other platforms but don't hold your breathe w/r to Unix. Why would we add value to a platform from which we get no revenue? It's not religion; it's just numbers. The really important platforms are mobile and embedded devices. Check out the Smart Device Extensions and the .NET Compact Framework. A couple of comments: The post by metagone is insightful. Microsoft is just a business that needs to provide value to stockholders. We do that by adding value to the Microsoft platform and .NET is our key for doing that. If you can use better tools to be more productive writing faster software on our platform, then the value of our platform grows and it's easier to sell. If we can grow the platform to play well with other devices, again the value of the platform increases. It's the same game every platform vendor plays. The goal is to innovate faster than the competition. As an aside, the Common Language Runtime is not a VM. A VM interprets. The CLR compiles. Java can do both. Because IL was designed for multiple languages and compilation, it has advantages over Java byte code. There's a good paper on the Microsoft Research website that describes it.

hmmm. (none / 0) (#129)
by WebBug on Thu Oct 31, 2002 at 06:27:43 PM EST

Your points are well presented, aside from the physical presentation, try plain text and use white space more effectively next time.

Just to make it easier to read.

I still think that I don't trust MS though. but then I'm an old free thinker and don't like profit as the only motive.

-- It may be that your sole purpose is to server as a warning to others . . . at least I have one!
[ Parent ]

Why Microsoft needs .NET | 131 comments (99 topical, 32 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!