Re: .NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Richard Grimes wrote:
> Mike Hofer wrote:
> >
> > You *know* so? How? What information sources do you have that we do
> > not? Can you please post them so we can be equally as informed?
> > Thanks.
>
> I first was given access to longhorn builds in mid 2002 (ie a year
> before the first public release) I had been asked to write a book about
> WinFS (you may have read my article on WinFS for MSDN Magazine). Of
> course that's all history now. My 'minder' at Microsoft told me that the
> developers on the LH team were told that *all* development in LH (note,
> I say Longhorn, not Whidbey), had to be managed code. They were told
> that if they wanted to write *any* native code they had to make a good
> case for it. I was told that unmanaged wrappers would be supplied for
> 'VB6 developers to use'.

First and foremost, I apologize if it seemed like I was questioning
your credentials. I wasn't. I was asking for the information because I
have an interest in it. I am sorry if I offended.

Mr. Skeet pointed out to me that you're the author of several books. I
wasn't aware of that. I I see that you've written "Professional ATL COM
Programming," and "Developing Applications with Visual Studio .NET".
I'm sure there are more, but Amazon isn't listing them. I have no
doubts about your credentials.

Sadly, my company is cheap. I'm still arm wrestling them to get an MSDN
subscription. If we had one, I'd have seen your article in the online
libraries.

> I have just finished an analysis of Vista and I find that there is very
> little .NET in the operating system. Clearly, when the big change
> happened, when the code base was changed from XP to Win2003 they also
> took the decision to do the majority of Longhorn development in native
> code. That is a huge shift, in just a few years. As a .NET enthusiast,
> and someone who has spent 5 years persuading people to use .NET that
> comes as a complete disappointment to me.

Now that *is* disappointing. And completely justifies what you were
saying. I wonder what drove that decision on their part.

<snip>

> Is this enough for you?
>
> http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

Quite. Thank you very much. I'm printing it now. :)

<snip>

> Go on, give me a quote *anywhere* on microsoft.com, or from *any*
> Microsoft person where they use the term 'cross platform'. They are
> studiously careful *not* to say that, because that is not their
> intention. .NET is a Windows technology and that is the way they want it
> to remain. Yes, Rotor has PAL so therortically you can compile it for
> other platforms, but it is a research tool, and it is not supported for
> production code.

Okay, you got me there. (Smacks of "plausible deniability," doesn't
it?) But it *seemed* to me that since Microsoft itself was publishing
the shared-source CLI on MSDN, that they were opening it up for
cross-platform development. It *seemed* to be a logical inference.

I'm going to have to stop doing that.

(PAL?)

<snip>
> I have asked Microsoft many times (most recently I asked Eric Rudder about
> this) and Microsoft have always replied that Office will remain a native
> application, although parts of it may have .NET code. Clearly their
> intention is to use .NET for RAD (in particular - RAD for *you*) and
> keep their code base native.

Now that's just cheating on Microsoft's part. It means that their
applications will always perform better unless you precompile
everything to native code.

And it is really sad that they don't plan to port Office to .NET. It
would be nice if IT folks only had to worry about one product, running
on two different OSes. It would make it easier to move between Mac and
PC as well. But, again, that kind of ease makes it *highly* improbable
that Microsoft will do it.

<snip>

> Here's a question: will mono code run under Microsoft's runtime, and
> visa versa?

That's a really good question. I feel an experiment coming on.

> Microsoft have *never* said that their intention is for 'mobile' code,
> that is, code that will run on multiple platforms. I know because I
> have spent 5 years trying to find such a statement!

I'll defer to your experience on that one, then.

But I really wish folks--including Microsoft--would stop treating the
Web as the silver bullet of application development. Web applications
are a pain in the ass to develop, don't have anywhere near as rich a
UI, and are slow as hell. My users keep asking why web applications
can't do things that desktop apps can. Explaining why to them is like
pulling chicken teeth.

But I digress.

<snip>

> You have amply killed your own argument: .NET is *not* cross platform.
> You cannot take code written for one platform and get it to run in
> another one.

You'll find that I do that a lot. I'm working hard at becoming more
informed, and writing more accurate, knowledgeable posts, though.

> The point is that the Compact Framework does not support the entire .NET
> framework that the desktop does. Most of the overloads are missing. Many
> of the classes are missing. For example, I wanted to use a SHA hash on
> my iPaq but there aren't any crypto classes in the CF, so I had to write
> my own. This means that any utility code written for the desktop that
> uses SHA, but does not use *any* hardware features, will not work on a
> CF machine.

Okay, I can see that.

> > Can you back that up with facts? Links? Statistical data? Under which
> > particular circumstances is it processor hungry?
>
> Been following the argument? When the GC occurs it suspends all threads.
> It does a walk of all objects from the roots it determines. All objects
> in the finalization queue are finalized. You're telling me that all of
> that is tivial and uses infitessimally small amounts of CPU cycles? I
> have written .NET code that has frozen the entire machine, sure, I
> didn't intend it to do that, and a bug created 10 times more objects
> that I intended, but it certainly froze the machine when a GC occurred.
> The GC is great for what it does, but don't ever imagine that it is some
> pice of magic that will solve all of your software problems.

I'd argue -- at the risk of shooting myself in the foot -- that that
was a defect that would have been rooted out in development or QA. I
think that the garbage collector can be expected to do odd things on a
development box, but not on a production box. Those kinds of bugs would
certainly have been rooted out before the product went live.

Right?

<ducking!>

.

Relevant Pages

  • Re: subroutine stack and C machine model
    ... If the code works as intended on a Microsoft platform ... Very few Microsoft C coders intend their code to run on non-Microsoft ...
    (comp.lang.c)
  • Re: does not contain debug information. Press OK to Continue
    ... this news group deals with standard C and platform specific stuff. ... You need to re-post on another (probably microsoft) relevant ng. ...
    (comp.lang.c)
  • Re: Transgressing the Boundaries: Towards a Transformative Hermeneutics of Copyright and Patent Law?
    ... to pay a "Microsoft tax" just to use a given piece of ... So basically there exists 1 commercial-quality free game (Enemy ... Funny that you keep arguing then. ... [snip further badmouthing of Nehahra] ...
    (comp.lang.java.programmer)
  • Re: Why to use VBA?
    ... Please don call me selfish for not counting VB; YES MS did lose some VB developers that were unwilling to port to new platform BUT the number of office customers is not comparable to VB 6! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ...
    (microsoft.public.word.vba.general)
  • Re: .NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO
    ... .NET is not cross platform and Microsoft have never claimed it to ... Shared Source CLI Implementation is a file archive ... In addition to the CLI implementation and the ...
    (microsoft.public.dotnet.framework)