By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,386 Members | 1,676 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,386 IT Pros & Developers. It's quick & easy.

Why no serious MS Application in .NET yet ??

P: n/a
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05
Share this Question
Share on Google+
142 Replies


P: n/a
there are lots of serious applications, just because word isn't coded in .NET
doesn't mean that there arn't ones out there... I work for a large insurance
agency and all our recent upgrades on our software for insurance related
programs all seemed to of went to .NET based solutions. And these are real
world applications doing real world data handling, so I would qualify that as
a serious application

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #101

P: n/a
office is NOT written in .NET, if it was it would require the framework to be
installed first to ues it, and it does not require it at all... Tablet PC and
Media Center PC how ever ARE written in .NET

"alejandro lapeyre" wrote:
The .NET is great, but it needs a lot of work to replace the windows api.
Before asking that Office is written in .NET, the ListBox should be written
in .NET!

regards
Alejandro Lapeyre

"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> escribió en el mensaje
news:%2******************@TK2MSFTNGP09.phx.gbl...
As the founder of .NET framework, Microsoft claims that it invention will
be
the next best platform for programming in a near future. Now it is 2005,
.NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?



Jul 21 '05 #102

P: n/a

"Tablet PC"?
"Media Center PC"?

Media Center PC. - Microsoft Windows XP Media Center Edition 2005 is a
version of Windows XP that allows home computing and entertainment to
be joined into one device -

Do you care to maybe rephrase that?

Jul 21 '05 #103

P: n/a
If my memory serves me correctly, Indigo is written completely in C#. Mostly
safe C# with something like 19 instances of the "unsafe" keyword.

Building your next gen messeging system on .NET I'd say is a pretty hefty
investment.

"Julian Sharp" wrote:
On Fri, 25 Feb 2005 21:01:53 +0330, "Herr Lucifer"
<"\n"HerrLucifer\n@microsoft.com> wrote:
So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications?


It does!

Microsoft CRM
BizTalk 2004
Sharepoint

Julian

Jul 21 '05 #104

P: n/a
I am not sure if this has been pointed out (I didn't read every post) But
most of SharePoint is written in .NET and parts of SQL Server 2005 will be. I
think someone mentioned .NET was released about 3 years ago and Microsoft has
been busy getting it to a point where they want it. The newer applications
are starting to include more and more .NET code; but it's a step by step
transition just like any company.

- Jonathan

"Brian" wrote:
there are lots of serious applications, just because word isn't coded in .NET
doesn't mean that there arn't ones out there... I work for a large insurance
agency and all our recent upgrades on our software for insurance related
programs all seemed to of went to .NET based solutions. And these are real
world applications doing real world data handling, so I would qualify that as
a serious application

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #105

P: n/a
Joe
I am not sure if this has been mentioned yet, but in addition to SPS 2003,
BizTalk Server 2004 is touted as the worlds largest .NET code base with >1
million lines of C#. With an investment like that it is hard to convince me
that MS is not fully vested in its .NET strategy.

"Jonathan" wrote:
I am not sure if this has been pointed out (I didn't read every post) But
most of SharePoint is written in .NET and parts of SQL Server 2005 will be. I
think someone mentioned .NET was released about 3 years ago and Microsoft has
been busy getting it to a point where they want it. The newer applications
are starting to include more and more .NET code; but it's a step by step
transition just like any company.

- Jonathan

"Brian" wrote:
there are lots of serious applications, just because word isn't coded in .NET
doesn't mean that there arn't ones out there... I work for a large insurance
agency and all our recent upgrades on our software for insurance related
programs all seemed to of went to .NET based solutions. And these are real
world applications doing real world data handling, so I would qualify that as
a serious application

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #106

P: n/a
i'm convinced now for sure

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________
"Joe" <Jo*@discussions.microsoft.com> wrote in message
news:5F**********************************@microsof t.com...
I am not sure if this has been mentioned yet, but in addition to SPS 2003,
BizTalk Server 2004 is touted as the worlds largest .NET code base with >1
million lines of C#. With an investment like that it is hard to convince
me
that MS is not fully vested in its .NET strategy.

"Jonathan" wrote:
I am not sure if this has been pointed out (I didn't read every post) But
most of SharePoint is written in .NET and parts of SQL Server 2005 will
be. I
think someone mentioned .NET was released about 3 years ago and Microsoft
has
been busy getting it to a point where they want it. The newer
applications
are starting to include more and more .NET code; but it's a step by step
transition just like any company.

- Jonathan

"Brian" wrote:
> there are lots of serious applications, just because word isn't coded
> in .NET
> doesn't mean that there arn't ones out there... I work for a large
> insurance
> agency and all our recent upgrades on our software for insurance
> related
> programs all seemed to of went to .NET based solutions. And these are
> real
> world applications doing real world data handling, so I would qualify
> that as
> a serious application
>
> "Herr Lucifer" <"\n" wrote:
>
> > As the founder of .NET framework, Microsoft claims that it invention
> > will be
> > the next best platform for programming in a near future. Now it is
> > 2005,
> > ..NET is 5 years old, and can talk and walk for himself with some
> > help of his
> > mum.
> > However, we see the same native office applications are coming out
> > again,
> > and many other tools in SP2 of XP which could be in managed
> > code....but are
> > not. So, as the inventor of .NET , why doesn't Microsoft itself use
> > "DOTNET"
> > in its applications? Is there any concern over the baby's runnung
> > performance inside Microsoft itself, or they gonna teach the baby how
> > to run
> > like a C kinda guy in future, so that they'll be able to use it for
> > themselves?
> >
> >
> >
> >
> >
> >
> >

Jul 21 '05 #107

P: n/a
Well... clearly you are unaware or overlooking the first official, major,
inarguably serious Microsoft application every written exclusively by
leveraging the .NET framework.

You probably remember what it is by now and surely you're a bit embarrassed,
but for the benefit of everyone else, that application is:

Microsoft Customer Relationship Management

I can hear the objections already... but, make no mistake, MS CRM is, in
fact, a Microsoft application.

It's also a show case for no compromise, no legacy development methods we
should all seek to emulate. Further, an application of MS CRM's scale being
developed using the most advanced development system Microsoft has to offer -
PROVES that if you have unlimited financial resources, two years, enough
graphic artists, marketing professionals and offshore developers to rebuild
the Hoover dam, and an unrepentant capacity to mislead the industry; you TOO
can build a collection of incomprehesible pages that are almost good enough
to install if it were free - with or without the framework.

But, just for the record. I like .NET.

Jul 21 '05 #108

P: n/a
Herr Lucifer wrote:
Replace the API? You're kidding! Dot Net doesn't really do anything on its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is really
there.


But what does it matter, really? This is what OO is all about, create an
object with a defined purpose, expose an interface and hide the
implementation. Today they are wrappers, tomorrow they can be fully managed.

Mono today implements 95% of Windows.Forms in managed code, in the
future .NET Windows.Forms can be based in Avalon and the application
won't even notice.
Jul 21 '05 #109

P: n/a
Another reason, which may have been mentioned already, is .NET is slower,
for one obvious reason. Current Windows is build in unmanaged code, so, .NET
code must run in an AppDomain. Doing that requires the creation of a seperate
environment for that code, and, must then use .NET's internal interop to turn
it into unmanaged code, then finally machine code the computer can process
outside of the AppDomain. However, when Longhorn is released, It will go from
managed code directly to machine code, skipping any interop. In today's date,
that is just extra work, when using Forms at least. Web Applications on the
other hand, are a different matter. Look at Microsoft's Web Site. You can see
for the most part, they are porting it to ASP.NET. It isn't limited to
console applications. However, there are little programs Microsoft has made
with .NET. Like the "Time Zone Utility", you can see that in Downloads. We
are talking about a massive code shift. It it hailed as a revolution.
Revolutions take time to go into effect. Unmanaged code will be around for
decades, maybe longer. I still see Applications written in COBOL and Turbo
PASCAL. Even though .NET is really nice to use, why re-write a program with
Managed Code if the Unmanaged code is equally is good? Interop will always be
a part of .NET In a sense, Interop is what makes .NET famous. It was hailed
because it was a major update, and it didn't require a complete abandon of
old code.

"Herr Lucifer" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?

Jul 21 '05 #110

P: n/a
"VC# Jones" <VC*****@discussions.microsoft.com> wrote in message
news:25**********************************@microsof t.com...
Another reason, which may have been mentioned already, is .NET is slower,
for one obvious reason. Current Windows is build in unmanaged code, so,
.NET
code must run in an AppDomain. Doing that requires the creation of a
seperate
environment for that code, and, must then use .NET's internal interop to
turn
it into unmanaged code, then finally machine code the computer can process
outside of the AppDomain. However, when Longhorn is released, It will go
from
managed code directly to machine code, skipping any interop.
You're confusing managed and native code. Managed code is generally compiled
to native (via JIT/NGEN). Interop is the transition between
managed/unmanaged. Even if you have 2 sets of code compiled to native, if
one is managed and one unmanaged, it will still require interop to cross
between them. Longhorn will not make any changes in the execution model, but
will result in more managed interfaces to the OS, which *should* result in
less interop requirements. AppDomains do not always imply a separate
environment, merely a separate logical process.
In today's date,
that is just extra work, when using Forms at least. Web Applications on
the
other hand, are a different matter. Look at Microsoft's Web Site. You can
see
for the most part, they are porting it to ASP.NET. It isn't limited to
console applications. However, there are little programs Microsoft has
made
with .NET. Like the "Time Zone Utility", you can see that in Downloads. We
are talking about a massive code shift. It it hailed as a revolution.
Revolutions take time to go into effect. Unmanaged code will be around for
decades, maybe longer.
Oh yeah, I'd say at least as long as assembler has been around so far.
I still see Applications written in COBOL and Turbo
PASCAL. Even though .NET is really nice to use, why re-write a program
with
Managed Code if the Unmanaged code is equally is good?
Couldn't agree more.
Interop will always be
a part of .NET In a sense, Interop is what makes .NET famous. It was
hailed
because it was a major update, and it didn't require a complete abandon of
old code.
Again, couldn't agree more. I hear people whining about how stuff isn't
"pure" .NET, and the whole point about COM Interop/P/Invoke/IJW and suchlike
is that they make all these disparate technologies part of .NET in a sense.
"Herr Lucifer" wrote:
As the founder of .NET framework, Microsoft claims that it invention will
be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?

Jul 21 '05 #111

P: n/a
Small Business Accounting 2006, Business Contact Manager, Retail Management
System to name a few, and that's just in the business solutions org.

"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
As the founder of .NET framework, Microsoft claims that it invention will
be
the next best platform for programming in a near future. Now it is 2005,
.NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #112

P: n/a
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d1**********@ctb-nnrp2.saix.net...
Longhorn will not make any changes in the execution model, but will result
in more managed interfaces to the OS, which *should* result in less
interop requirements. AppDomains do not always imply a separate
environment, merely a separate logical process.


Assuming that the managed interfaces exposed in the OS don't simply push
interop overhead off into the OS itself. Are they going to just be wrappers
or are they going to actually be managed code all the way down to the metal?

--Bob
Jul 21 '05 #113

P: n/a
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:uH**************@TK2MSFTNGP09.phx.gbl...
"Sean Hederman" <us***@blogentry.com> wrote in message
news:d1**********@ctb-nnrp2.saix.net...
Longhorn will not make any changes in the execution model, but will
result in more managed interfaces to the OS, which *should* result in
less interop requirements. AppDomains do not always imply a separate
environment, merely a separate logical process.
Assuming that the managed interfaces exposed in the OS don't simply push
interop overhead off into the OS itself. Are they going to just be
wrappers or are they going to actually be managed code all the way down to
the metal?


I think it will depend. Interfaces to core OS will almost certainly involve
some interop. I can't see how they'd implement core kernel services in
managed code, so in those cases there will definately be some interop
required. As for things that don't require managed code, some (if not most)
will almost certainly be wrappers. You'll find more and more of the OS
coming under the managed environment as time goes on however. I'm also
pretty sure that Longhorn will be optimized for the CLR, so your interop
should be faster.
--Bob

Jul 21 '05 #114

P: n/a
> However, when Longhorn is released, It will go from
managed code directly to machine code, skipping any interop.
No. The Windows API will be between the dotnet code and machine code,and
this won't change in longhorn and it won't change in the next couple of
years. Even if WinFX is introduced as the new Windows API, WinFX will just
be a wrapper of the native Windows API.

"VC# Jones" <VC*****@discussions.microsoft.com> schrieb im Newsbeitrag
news:25**********************************@microsof t.com... Another reason, which may have been mentioned already, is .NET is slower,
for one obvious reason. Current Windows is build in unmanaged code, so, ..NET code must run in an AppDomain. Doing that requires the creation of a seperate environment for that code, and, must then use .NET's internal interop to turn it into unmanaged code, then finally machine code the computer can process
outside of the AppDomain. However, when Longhorn is released, It will go from managed code directly to machine code, skipping any interop. In today's date, that is just extra work, when using Forms at least. Web Applications on the other hand, are a different matter. Look at Microsoft's Web Site. You can see for the most part, they are porting it to ASP.NET. It isn't limited to
console applications. However, there are little programs Microsoft has made with .NET. Like the "Time Zone Utility", you can see that in Downloads. We
are talking about a massive code shift. It it hailed as a revolution.
Revolutions take time to go into effect. Unmanaged code will be around for
decades, maybe longer. I still see Applications written in COBOL and Turbo
PASCAL. Even though .NET is really nice to use, why re-write a program with Managed Code if the Unmanaged code is equally is good? Interop will always be a part of .NET In a sense, Interop is what makes .NET famous. It was hailed because it was a major update, and it didn't require a complete abandon of
old code.

"Herr Lucifer" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his mum.
However, we see the same native office applications are coming out again, and many other tools in SP2 of XP which could be in managed code....but are not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET" in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run like a C kinda guy in future, so that they'll be able to use it for
themselves?

Jul 21 '05 #115

P: n/a
Have you looked at Microsoft Operations Manager 2005? A considerable amount
of it is written in .NET.

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #116

P: n/a
Cool. I never heard of Retail Management System. When was that released?
Will it integrate with SBA?

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Kollen Glynn [MS]" <sb*@online.microsoft.com> wrote in message
news:42********@news.microsoft.com...
Small Business Accounting 2006, Business Contact Manager, Retail Management System to name a few, and that's just in the business solutions org.

"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
.NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again, and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?




Jul 21 '05 #117

P: n/a
Its funny. If you watch the "Action Performance Customer Video" for Retail
Management, they talk about using RMS, but the system in the video looks
like some other touch screen system like Aloha or something. Maybe the
touch screen option displays a different gui.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Kollen Glynn [MS]" <sb*@online.microsoft.com> wrote in message
news:42********@news.microsoft.com...
Small Business Accounting 2006, Business Contact Manager, Retail Management System to name a few, and that's just in the business solutions org.

"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
.NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again, and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?




Jul 21 '05 #118

P: n/a
Hi Cody,
However, when Longhorn is released, It will go from
managed code directly to machine code, skipping any interop.

Who on earth wrote that! A Disney character who jumped out of the 3d
rendered Avalon desktop experience?
No. The Windows API will be between the dotnet code and machine code,and
this won't change in longhorn and it won't change in the next couple of
years. Even if WinFX is introduced as the new Windows API, WinFX will just
be a wrapper of the native Windows API.


Yes, I cease to be amazed by the fantasy tales I keep reading on these
..NET newsgroups. Part of the problem is the terminology ".NET" can mean
almost anything, and that applies to the products cited by Microsoft as
being "written in .NET". Do they mean these products were written
completely independent of COM - including .NET classes that rely on COM?

Here's an example; .NET does not have any proper Video Editing
capabilities, but guess what? You can write a video editor in .NET! You
can then come on this newsgroup and say "Wow, I wrote a video editor in
..NET", and it would be true! How cool is that? But scratch away the
surface and all you've got is a bunch of calls to the same old
DirectShow COM interfaces that they've been using for the last 6 years.
You even wonder if some of Avalon will just be calls to Direct3D.

In some ways it does not matter, as long as it works. I just wish people
would get a grip on what's actually going on behind the scenes.

--
Gerry Hickman (London UK)
Jul 21 '05 #119

P: n/a
> Here's an example; .NET does not have any proper Video Editing
capabilities, but guess what? You can write a video editor in .NET! You
can then come on this newsgroup and say "Wow, I wrote a video editor in
.NET", and it would be true! How cool is that? But scratch away the
surface and all you've got is a bunch of calls to the same old DirectShow
COM interfaces that they've been using for the last 6 years.


Thats partially incorrect. The .NET framework does not have any classes to
do video editing for you, if you want prebuilt libraries you will have to
use COM interop(directly or via Managed DirectX) or other third party
libraries. *However*, there is nothing stopping you from writing a video
editor in pure managed code...its just a matter of wanting to write codecs,
file parsers, and the like yourself.

Of course, that won't be accelerated(or very accelerated), would be alot of
work, and no codecs written by third parties in the future are going to be
usable. And you won't be able to avoid GDI...but, you can also say "I wrote
a video editor in C++\Delphi\VB\Perl\whatever" and still be saying the same
thing. What *you* wrote still relies on DirectX, all you wrote was a shell
in your favorite language. No language or runtime I am aware of has video
editing capabilities built in. It is always provided by DirectX.
This argument was bad the first time you made it and it still is.
Jul 21 '05 #120

P: n/a
Err...ever hear of a little thing called BizTalk Server 2004? Written in C#.
1.5 million lines of it and more...

Dave
"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #121

P: n/a

Ma'am, Sir,

There is so much to sort through in life already and our work as programmers
of the world's computer programs is only one of the many interesting things
to do in life.

When a new programmer arrives on the scene the human soul inside the shell
of socio-economic-materialistic person must look deep (deeper than that)
within themselves and decide what is and is not art to them. Everyone sees
art in a different way much as Mr. Henry David Thorreau described us all as
'stepping to the beat of a different drummer'. Perhaps we should all just
wait and see where time and the future really takes each of us and just look
at all the different kinds of art along the way deciding each for ourselves.

Mr. Charles Moore in his brilliance set the world, especially Intel on a
path of excellence that is nearly unbridaled. Every single day all over the
earth many (more than that) computer hardware engineers work with a very
strong (stronger than that) sense of motivation, dedication and purpose.
Their hard work is what makes Mr. Moore's law a reality. If they were lazy,
the demise of computer programming could perhaps take place, but they are not
and for that I love them dearly.

Think of this: today, it is the 25th day of the month of March in the year
2005 and the fastest Dell PC in the catalog on my desk that was mailed to me
from Dell.com states that a 3.2GHZ CPU is the fastest machine sold by
Dell.com. Now think that is the year 2007, Moore's law states that we can
expect 6.4GHZ. Again, it is now 2009 and we are at 12.8GHZ. Keep going on
your own and discover like I did that every 20 years we add three zeros to
the cycles-per-second HERTZ measurement-number meaning that in the year 2025
3,200,000,000,000 will have replaced the 3,200,000,000 which is to say that
3,200GHZ will exist in the year 2025 and 3.2GHZ exists today in the year
2005. That means that in the year 2065 which will be three years away from
my 100th birthday since I was born in 1968, the fastest CPU on earth may very
well be 3,200,000,000,000,000,000 or 3,200,000,000GHZ which means that we
ancient programmers way back in the year 2005 will hardly be thought out or
remembered anymore than the ASSEMBLY language programmers of the 1960s are
thought of by C programmers or C++ programmers or Java programmers or C#
programmers or BASIC programmers today. Time changes everything. It is no
one's fault, it is simply the progress of human kind observed by us mere
mortal human beings. I like quoting movies to make points so I ask you to
remember the movie "THE LION KING" remember the line ..."The Circle of Life"
so it is for us too.

If Moore's Law holds true which is as likely as it is not likely for the
sake of history supporting Moore's original observations, consider then that
programming and the nature of programming or rather the art of programming
computers will also change. Already the nature of code has really changed
incredibly since the early days of Altair BASIC and Q-DOS. Back then very
few people worried about anything other than MACHINE or ASSEMBLY languages
because CPU speeds were very, very, very, very slow compared to today speeds.
Consider that an Intel 486/25mhz or 25,000,000 cycles per second existed in
about 1991 and that Intel released 286 and 386 slower machines than the 486
only years earlier. RAM was very expensive and was very limited and very
expensive at about $100 for a stick of good 8mb memory or perhaps a deal at
16mb for $129.99. Today, 512mb of RAM in one stick where four slots usually
exists only costs about $79.99 on average in a retail store like COMP-USA.
Programmers in the 1950s and 1960s before had to really work hard to do
anything. The most clever text-graphic-creating COBOL programmers were
looked up to as they printed very long banners on dot matrix printers for our
offices at work. I remember how it really was. FLOPPY DISKS were humongous
and very flimsy. Today, CD-RWs and DVD-RWs and SD/MMC has greatly changed
non-volatile data storage.

In 1970, Dennis Ritchie and Brian Kernigham produced the first C language
compiler while working at Bell Laboratories. Since then, religious-like
stances on the art of programming have introduced themselves as sects or
divisions amongst the world's programmers. It is as sad as the Muslim vs
Christian vs Hindu vs Judaism vs Buddhism warring on earth today. We all
share voltage or no-voltage states of mind should we not celebrate that? Or
should we be devoutly C or devoutly UNIX or devoutly BASIC or devoutly JAVA
or devoutly C-SHARP? We should respect each other's opinions and celebrate
each other's accomplishments and try with every fiber of our being to
forgive/overlook each other's shortcomings. A pat on the back is worth
$1,000,000,000,000.00, a trillion dollars, to a working-class man or woman on
earth. Remember that, Mr. and Mrs. Corporate Executive! Remember that Mr.
and Mrs. Admiral/General/Military Officers! Remember that Mr. and Mrs.
Elected Official/Judge. Remember to pat your folks on their backs. Speaking
of, my wife just called and made sure that I end this shortly and return to
pat her on her back for all she does for me and my children. See what I
mean...folks, we need each other.

So, before I go, given a CPU's speed constantly increases over time while
also becoming less expensive over time, volatile-storage RAM increases in
capacity and speed over time while also becoming less expensive over time,
and that non-volatile-storage EIDE/SCSI/CD-RW/DVD-RW/SD-MMC, etc. increases
in capacity and speed over time while also becoming less expensive over time,
it is clear that we, the computer-software-engineers, PROGRAMMERS, have only
good things to look forward to with regard to the ART OF PROGRAMMING as the
future unfolds...that is, if we do destroy our wonderful planet, EARTH, by
any means.

All that I have said has not even mentioned the issues of the day which are
TCP/IPv4/IPv6/HTTP/HTTPS, XML, HTML, XHTML, TXT, CSV, TSV, CHTML, FELICA,
WML, AES, HDML, ASCII, UNICODE, UTF-7, UTF-8, UTF-16LE, UTF-16LE, BMP, GIF,
JPEG, PNG, SVG, MP3, WAV, WMA, MPEG, MOV, WMV, ASPX, MMIT_ASPX, ASMX, ASCX,
C, H, CPP, DLL, JS, CS, VB, EXE, CE_EXE, DIRECTX, ACTIVEX, COM, OLE, SOAP,
WSDL, DISCO, UDDI, and on and on the list of important file types, standards,
technologies, acronyms goes on into time.

I believe that their is something preciously primitive about the acronym
BLIDSSS which is to say:

B oolean
L ong
I nteger
D ecimal
D ouble
S ingle
S hort
S tring

meaning that BLIDDSSS is a way to say that in the year 2065 when central
processing units or CPUs are going 1 million times faster than they are today
that those fast little brains will still be dealing with BLIDDSSS primitive
data types which by the say are defined by the Microsoft .NET Framework and
not by me.

I did purchase BLIDDSSS.com intending to illustrate what exactly I mean and
will do so to the best of my ability.

I have said what I came to say as honestly and intelligently as I can. I
rest in peace.

Thank you for your time and to all of the people who have written books or
helped me along the way I thank you all.

Respectfully,

SmartWebAgent
John Flaherty
sm***********@hotmail.com
http://www.smartwebagent.com

"Herr Lucifer" <"\n" wrote:
What we've got in C is "quiet" like what we have in C#. Why? because both
languages don't do any "machine level" thing on their own. Well, C- the
great language- has the chance of having a compiler which translates the C
code into the native machine code directly. However, in C#, we have a layer
in between (an intermediate language) which is the reason for all these
troubles. I believe if there was a "Native Image Generator", which could
really generate native images, just like the final thing you make by using
C, there wouldn't be any more troubles over performance issues in .NET
desktop apps as we see now.

PS: I personally think the framework is great (and its modern oo design),
sth that you can never have when using C , nevertheless, this framework
could be harnessed in much better ways by much better compilers. For
example, imagine by third-party compilers that would compile your .NET code
(VB or C#) into machine level instruction directly.(just my idea)

"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote :
Cynic, of course. The perfect operating system, UNIX, and the perfect
programming language, C, were released 1/3 of a century ago. No further
progress in computing has ever occurred. :) :) :)


Jul 21 '05 #122

P: n/a
I have'nt read all the posts, so someone may have mentioned it, but the Media
Center app in Windows XP Media Center Edition is entirely written in .NET

How major that becomes is yet to be seen.

I would imagine that Microsoft's existing apps with a large codebase already
written would not be migrating any time soon. However, I believe we will see
more MS .NET apps emerging, especially in Longhorn.

I do not think we will see any critical or security sensitive apps or OS
components written in .NET because of the ease of decompiling and
reverse-engineering .NET executables. There is even a web site out there that
gives instructions on how to decompile Media Center's Media Center app using
Microsoft's own SDK tools, change the Media Center code to make it work with
XP Pro, and then recompile it. (granted the assembly is no longer signed)
I'm sure Microsoft knows this is a risk they take with any software they
produce in .NET.

As for programming in .NET. I was a long-time VB4,5,6 programer, with some
experience in C++, when .NET came out I was completely lost and did not want
to switch. Then i gave up, and decided to learn .NET and now I have a hard
time going back.

I like .NET, and on most any modern computer, speed drop is hardly noticible
(vs. C++ unmanaged) I would like to point out to some newbies that may not
realize it, but in the C++.NET you can do managed or unmanaged.... C++
managed still compiles to MSIL... I have heard some people who swear C++ is
much faster than VB.NET... and yet, they are writing managed code (.NET) in
C++. (I have seen this argument in numerous .NET + DirectX fourms for game
programming)

-Kevin

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #123

P: n/a
Also, among the many advantages of managed code is platform neutrality.
Thinking of 64-bit coming as we speak, you can just move a current .Net
assem with *no changes and it will just run in the 64 bit OS (AMD or
Intel) - no new compile needed (c++ native assems would need a recompile
however.) You could also force its "bitness" with a simple switch if you
needed 32-bit mode for some reason. Just some more infrastructure you get
for free in a managed environment.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Kevin C" <Kevin C@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com...
I have'nt read all the posts, so someone may have mentioned it, but the Media Center app in Windows XP Media Center Edition is entirely written in .NET

How major that becomes is yet to be seen.

I would imagine that Microsoft's existing apps with a large codebase already written would not be migrating any time soon. However, I believe we will see more MS .NET apps emerging, especially in Longhorn.

I do not think we will see any critical or security sensitive apps or OS
components written in .NET because of the ease of decompiling and
reverse-engineering .NET executables. There is even a web site out there that gives instructions on how to decompile Media Center's Media Center app using Microsoft's own SDK tools, change the Media Center code to make it work with XP Pro, and then recompile it. (granted the assembly is no longer signed)
I'm sure Microsoft knows this is a risk they take with any software they
produce in .NET.

As for programming in .NET. I was a long-time VB4,5,6 programer, with some
experience in C++, when .NET came out I was completely lost and did not want to switch. Then i gave up, and decided to learn .NET and now I have a hard
time going back.

I like .NET, and on most any modern computer, speed drop is hardly noticible (vs. C++ unmanaged) I would like to point out to some newbies that may not
realize it, but in the C++.NET you can do managed or unmanaged.... C++
managed still compiles to MSIL... I have heard some people who swear C++ is much faster than VB.NET... and yet, they are writing managed code (.NET) in C++. (I have seen this argument in numerous .NET + DirectX fourms for game
programming)

-Kevin

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his mum.
However, we see the same native office applications are coming out again, and many other tools in SP2 of XP which could be in managed code....but are not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET" in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run like a C kinda guy in future, so that they'll be able to use it for
themselves?



Jul 21 '05 #124

P: n/a
Hi Daniel,
Here's an example; .NET does not have any proper Video Editing
capabilities,
Thats partially incorrect. The .NET framework does not have any classes to
do video editing for you, if you want prebuilt libraries you will have to
use COM interop(directly or via Managed DirectX)
Managed DirectX is a TOTAL joke when it comes to video editing!

Regarding "COM interop", that was exactly my argument. Of course it can
be done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down
to the metal" (quoting from the post I replied to).
or other third party
libraries. *However*, there is nothing stopping you from writing a video
editor in pure managed code...its just a matter of wanting to write codecs,
file parsers, and the like yourself.


I cannot believe you (as an MVP) are saying this? Have you ever actually
written a codec? You can find me in the unmanged DirectShow groups if
you are interested in in-depth video editing discussion IN THE REAL
WORLD, but this is totally absurd.

This is another typical example of a Disney character who jumped out of
the fairy tale land of the Avalon desktop...

--
Gerry Hickman (London UK)
Jul 21 '05 #125

P: n/a
'"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:Ow*************@TK2MSFTNGP15.phx.gbl...
Hi Daniel, [Snip] Regarding "COM interop", that was exactly my argument. Of course it can be
done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down to
the metal" (quoting from the post I replied to).


I really don't understand this preoccupation some people have with having
..NET "all the way down" or "pure .NET". I often hear these terms bandied
about as if they actually made sense.

http://codingsanity.blogspot.com/200...about-net.html
Jul 21 '05 #126

P: n/a

"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:Ow*************@TK2MSFTNGP15.phx.gbl...
Hi Daniel,
Here's an example; .NET does not have any proper Video Editing
capabilities,
Thats partially incorrect. The .NET framework does not have any classes
to do video editing for you, if you want prebuilt libraries you will have
to use COM interop(directly or via Managed DirectX)


Managed DirectX is a TOTAL joke when it comes to video editing!


Which is irrelevent since you'd consider it invalid even if it wasn't. We've
been over this before.

Regarding "COM interop", that was exactly my argument. Of course it can be
done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down to
the metal" (quoting from the post I replied to).
or other third party libraries. *However*, there is nothing stopping you
from writing a video editor in pure managed code...its just a matter of
wanting to write codecs, file parsers, and the like yourself.


I cannot believe you (as an MVP) are saying this? Have you ever actually
written a codec? You can find me in the unmanged DirectShow groups if you
are interested in in-depth video editing discussion IN THE REAL WORLD, but
this is totally absurd.

So...writing codecs and video encoding\editing libraries manually is absurd,
but using existing third party libraries is incorrect because they aren't
managed? This is the same double standard showing its head again, since
someone is going to have to write the codec and to get it "down to the
metal" as you put it, someone will have to write those codecs in managed
code, manually. How do you suggest achieving both goals without anyone ever
writting a codec in managed code? Your assertion that there is no capability
is partially incorrect. The base capability is there, the framework does not
break video encoding, no one has yet decided to attempt porting over a codec
model and the sizable number of codecs that would be required to use it(to
my knowledge anyway).

Personally I've never written a video codec(some minimal attempts at MP3
encoding years ago), and I have little to no interest in doing so. It is a
niche of programming which holds less of my interest than dos-era TSRs. But
you are telling me that it is impossible to write them in managed code, or
atleast doing your damndest to imply that they are. I will assure you it is
not. It will not be optimal, and excluding certain video compression
junkies, not a whole lot of fun, but the capacity is there. Someone simply
has to decide to write the code. Until every codec manufacturer is producing
managed codecs(like that is going to happen anyway, most codec manufacturers
can't even get the C\C++ version working right. Supporting two would be a
terrible mess), your argument is about as senseless as the same argument
requiring you to only use video libraries you wrote yourself in C++ or
requring a hardware driver to have to be written in managed code. You work
with what you have and what the rest of the world gives you.

The problem I have is that your argument always centers around C\C++ users
being allowed to use the standard 3rd party libraries because...umm...they
are C\C++ users! It is absurdly self serving. Your argument is basically one
group can use the standard interfaces and libraries while the other one
can't, therefore the first group is better. However, the second group can,
you just don't consider it proper. It doesn't make much sense to me.
Jul 21 '05 #127

P: n/a

"Sean Hederman" <em*******@codingsanity.blogspot.com> wrote in message
news:d2**********@ctb-nnrp2.saix.net...
'"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:Ow*************@TK2MSFTNGP15.phx.gbl...
Hi Daniel,

[Snip]
Regarding "COM interop", that was exactly my argument. Of course it can
be done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down to
the metal" (quoting from the post I replied to).


I really don't understand this preoccupation some people have with having
.NET "all the way down" or "pure .NET". I often hear these terms bandied
about as if they actually made sense.


As best I can tell it is either that the person hates the way the old
version works and wishes it could be fixed using managed(usually actually
meaning OO) concepts or the person needs ammo for an argument. It never
seems to come up any other time.
Jul 21 '05 #128

P: n/a
I create .NET applications of the enterprise data management variety for
installation at other companies. For the last year our development staff has
had to load its own .NET runtimes and make sure that the redistributed
runtime is available in the products we sell. So far using .NET only on the
server,
and we've been worried about using client side features like J# browser
controls because of the need to foist the .NET runtime more widely at
customer sites.

But, meanwhile, as we worried, our own company's standard desktop environment,
maintained by the IT group, has suddenly started to include the .NET runtime.
I'm told by the IT staff that it is required for the Microsoft Outlook
Business Contact
Manager. How clever, sounds like just the kind of thing that
senior management would
want to use every day. Such considerations quickly drive
a defacto standard. Why do you think PORT 80 remains open out of
most company firewalls?

"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?


Jul 21 '05 #129

P: n/a
A major point of .NET is so that nobody has to be aware of what is
going behind the scenes. More power to you if you do know, but as a
general speaking you don't need to and while relying on what is going
on behind the scenes is nice one should not be so careful to tie one's
programming structure to that aspect. Especailly as the .NET migrates
to more platforms. Mono, Avalon, etc
Just my 2 cents worth.

Jul 21 '05 #130

P: n/a
Hi Sean,
Regarding "COM interop", that was exactly my argument. Of course it can be
done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down to
the metal" (quoting from the post I replied to).
I really don't understand this preoccupation some people have with having
.NET "all the way down" or "pure .NET". I often hear these terms bandied
about as if they actually made sense.


I think you are agreeing with what I said above. I was replying to a
comment along these same lines and I agree that it does not make any
sense. Could it be the VB6 heads have come over to .NET, but have never
really understood how a computer or it's subsystems actually work?

--
Gerry Hickman (London UK)
Jul 21 '05 #131

P: n/a
Hi recoil,
A major point of .NET is so that nobody has to be aware of what is
going behind the scenes. More power to you if you do
A good point, but personally I'm not convinced. You only have to watch a
..NET guy trying use the W3C DOM/CSS/ECMA to reel in horror at the
inefficiency and lack of cross-browser co-ordination as they struggle
with the facilities and limitations of the so-called "web control", or
watch them try to get a simple video editor working with JPEG extraction
for the family holidays, or worse still watch them try to negotiate the
secure channel between a bungling XP box and it's domain controller.
Watch them try to develop ADSI web apps without the security risk of
turning on delegation in IIS. At that point, it's time to call in the
experts and get the job done in half the time and half the budget.
programming structure to that aspect. Especailly as the .NET migrates
to more platforms. Mono, Avalon, etc


Hmm, well Mono I agree with, but Avalon?? This is just an extra bloated
UI layer that serves no purpose, it's not a platform.

--
Gerry Hickman (London UK)
Jul 21 '05 #132

P: n/a
Hi Daniel,
Managed DirectX is a TOTAL joke when it comes to video editing!
Which is irrelevent since you'd consider it invalid even if it wasn't. We've
been over this before.
This is not true, I was one of the first people to try out the new
Managed DirectX. You may find some of my old messages archived.
Microsoft actually tried to bury the DirectShow portion of it because it
was such a disaster, and just for the record, there are _no_ video
editing facilities in Managed DirectX (unless a new version has just
been released I don't know about...)
I cannot believe you (as an MVP) are saying this? Have you ever actually
written a codec?

So...writing codecs and video encoding\editing libraries manually is absurd,
but using existing third party libraries is incorrect because they aren't
managed?
I did not say any such thing. Your claim was that "you can write a codec
in .NET"; this is _totally_ abusrd and inaccurate; apart from anything
else it would be the worst (and slowest) codec ever written, as it would
not be able to take advantage of the SSE SIMD extensions. Maybe you can
enlighten us as to what strategy you'd use for this codec (e.g. what
..NET classes would you make calls to, and what language you'd use?)
This is the same double standard showing its head again, since
someone is going to have to write the codec and to get it "down to the
metal" as you put it,
You are confusing what was written above. I replied to a post where a
guy claimed Longhorn would support .NET "all the way down to the metal".
I was disagreeing with it.
someone will have to write those codecs in managed
code, manually.
Well, I'm glad it won't be me!
is partially incorrect. The base capability is there, the framework does not
break video encoding, no one has yet decided to attempt porting over a codec
The base capability is not there (other than making calls to unmanged
code), and the reason no one has done it, is because no one is dumb
enough to try!
Personally I've never written a video codec(some minimal attempts at MP3
encoding years ago), and I have little to no interest in doing so. It is a
niche of programming


Right, so family videos and Time-Warner are a "nich" market now. Somehow
I think Microsoft would disagree.

--
Gerry Hickman (London UK)
Jul 21 '05 #133

P: n/a
> was such a disaster, and just for the record, there are _no_ video editing
facilities in Managed DirectX (unless a new version has just been released
I don't know about...)


Out of curiosity, how important is having video editing built into .net
anyways?

-Darrel
Jul 21 '05 #134

P: n/a
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:ef**************@TK2MSFTNGP09.phx.gbl...
Hi Sean,
Regarding "COM interop", that was exactly my argument. Of course it can
be done with COM or "third party libraries", but that's not what we're
discussing here. We were talking about "pure" managed code "right down to
the metal" (quoting from the post I replied to).
I really don't understand this preoccupation some people have with having
.NET "all the way down" or "pure .NET". I often hear these terms bandied
about as if they actually made sense.


I think you are agreeing with what I said above. I was replying to a
comment along these same lines and I agree that it does not make any
sense.


Yep, I was agreeing with you.
Could it be the VB6 heads have come over to .NET, but have never really
understood how a computer or it's subsystems actually work?
I'm an ex-"VB6 head", and I know very well how a computer works thank you
very much. Then again, I have had the misfortune of writing low-level
assembler before <shudder/>.

--
Gerry Hickman (London UK)

Jul 21 '05 #135

P: n/a

"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:OE**************@TK2MSFTNGP12.phx.gbl...
Hi Daniel,
Managed DirectX is a TOTAL joke when it comes to video editing!
Which is irrelevent since you'd consider it invalid even if it wasn't.
We've been over this before.
This is not true, I was one of the first people to try out the new Managed
DirectX. You may find some of my old messages archived. Microsoft actually
tried to bury the DirectShow portion of it because it was such a disaster,
and just for the record, there are _no_ video editing facilities in
Managed DirectX (unless a new version has just been released I don't know
about...)


I am aware that there aren't. I found that to be disappointing. My primary
reason for restarting this argument(if you look back, I think we've had the
same one a time or two now) was your assertion that .NET means no COM
interop. I still think that "Written in <anything>" should mean no COM
interop. That is all I have ever tried to get across. Relating it to .NET is
a waste of time.

It has always seemed to me that your gripe is .NET has some relation to COM
somewhere, be it in a framework class or required to use standard
interfaces, therefore nothing can actually be written in .NET. I find it to
be a rather desperate viewpoint.
I cannot believe you (as an MVP) are saying this? Have you ever actually
written a codec?
So...writing codecs and video encoding\editing libraries manually is
absurd, but using existing third party libraries is incorrect because
they aren't managed?
I did not say any such thing. Your claim was that "you can write a codec
in .NET"; this is _totally_ abusrd and inaccurate; apart from anything
else it would be the worst (and slowest) codec ever written, as it would
not be able to take advantage of the SSE SIMD extensions. Maybe you can
enlighten us as to what strategy you'd use for this codec (e.g. what .NET
classes would you make calls to, and what language you'd use?)


Personally? I imagine the only built in classes I'd have much use for would
be the various streams and readers needed to get the data and to write it
back out, plus whatever classes are associated with the calculations.

I'm personally happy with interop. What is missing that disallows one from
writing a codec? Not considering performance, is there *ANYTHING* that stops
a dedicated person from writing one?
is partially incorrect. The base capability is there, the framework does
not break video encoding, no one has yet decided to attempt porting over
a codec


The base capability is not there (other than making calls to unmanged
code), and the reason no one has done it, is because no one is dumb enough
to try!


Sure it is, just not the best possible support. SIMD or any other
instructions certainly are not required to write a codec. They permit it to
operate in real-time perhaps, but are not required to simply decode or
encode a video.
Personally I've never written a video codec(some minimal attempts at MP3
encoding years ago), and I have little to no interest in doing so. It is
a niche of programming


Right, so family videos and Time-Warner are a "nich" market now. Somehow I
think Microsoft would disagree.


I never said they were a niche market, I said it was a niche of programming.
There is a difference. The market is big, but I doubt anywhere near a
appreciable percentage of active coding is related to it. And much of what
is is likely more related to UI than anything else. I certainly imagine I
can make it through my life without having to bother writing a line of video
editor code. I also imagine a great many others will as well.

I realize it is your central interest(and likely your profession), but you
really seem to overestimate its importance.
Jul 21 '05 #136

P: n/a
Hi Daniel,
and just for the record, there are _no_ video editing facilities in
Managed DirectX
I am aware that there aren't. I found that to be disappointing.
Finally, you are now back in reality!
My primary
reason for restarting this argument(if you look back, I think we've had the
same one a time or two now) was your assertion that .NET means no COM
interop.
When did I ever say that? My view is the complete opposite. Let me try
to explain once more:

..NET is limited, bloated, slow and inefficient for programming of real
world enterprise and world facing tasks (no surprises there). We all
know that every useful call from .NET requires a further call to either
COM or Win32 (no surprises there either). We also know that (contrary to
some views), .NET can still not run without the Windows registry and the
COM interface entries. ASP.NET also creates COM+ objects.

This is all fine and I have no problem with it.

My gripe is with people in the .NET newsgroups who either dispute the
above, or claim that ".NET is COM independent", or that "under Longhorn
it will be managed code all the way to the metal", or that "you can do
everything in managed code that you can do in unmanaged code such as
writing a codec". The latter views are complete nonsense and when you
ask people to demonstrate them in code, they suddenly go quiet. The only
clever thing about .NET is that it's "easier" for beginners and VB6
heads who think that "programming" is dragging a button onto a form.
I did not say any such thing. Your claim was that "you can write a codec
in .NET"; Personally? I imagine the only built in classes I'd have much use for would
be the various streams and readers needed to get the data and to write it
back out, plus whatever classes are associated with the calculations.
Ok, well I'll leave any comments on this to others. I have some very
elegant codec source code in front of me, and it's actually written
under NASM (the non-Microsoft assembler). The day we see this kind of
thing is C# and .NET will be a very interesting day indeed!
Right, so family videos and Time-Warner are a "nich" market now. Somehow I
think Microsoft would disagree.

I never said they were a niche market, I said it was a niche of programming.
OK, I see what you mean.
I realize it is your central interest(and likely your profession), but you
really seem to overestimate its importance.


It was just an example of one of many .NET limitations - strange in a
world where Microsoft claims to be at the "cutting edge" of media
developments?

--
Gerry Hickman (London UK)
Jul 21 '05 #137

P: n/a
"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:OF****************@tk2msftngp13.phx.gbl...
Hi Daniel,
.NET is limited, bloated, slow and inefficient for programming of real
world enterprise and world facing tasks (no surprises there).
Compared to what? I find .NET more than fast enough for my purposes
(managing enterprise workflows and documents). I certainly haven't noticed
any massive speed drops when switching. I've generally found that the #1
cause of poor performance is poor programming, not the platform.
The only clever thing about .NET is that it's "easier" for beginners and
VB6 heads who think that "programming" is dragging a button onto a form.
I take it you haven't looked into such things as the tight control you can
exert over things like Remoting and the Runtime. Ever tried to implement a
custom compression scheme on DCOM? I never figured it out, and I suspect
it's impossible. Making things that should be simpler easier is not a bad
thing. Or would you have us still using assembler for business apps?

Oh, and by the way, I was a "VB6 head". I used VB6 because it allowed me to
do my job quicker and easier. Sure, I sometimes dropped down into ATL to
produce libraries to get around VB's limitations, but my primary tool was
VB. Now, I mainly use C#, and you know what? The amount of time I spend
dropping down into C++ is virtually nil, because I don't need to. IMO that
indicates a pretty good programming environment.

I'm sick of this impression that because one uses a RAD tool, it makes one a
worse programmer in some way. I believe that using the most cost-effective
tool for the job makes one a *better* programmer. If the tool makes simple
things simpler, fantastic. I can assure you that as a "VB6 head" I had a
better understanding of COM than all the C++ programmers at my previous
company.
Ok, well I'll leave any comments on this to others. I have some very
elegant codec source code in front of me, and it's actually written under
NASM (the non-Microsoft assembler). The day we see this kind of thing is
C# and .NET will be a very interesting day indeed!
We never will. What would the purpose be? Using something like SIMD flies
completely against the whole idea of IL. What we might see are .NET
libraries that expose the capabilities of this. Hell, why don't you do it?
It was just an example of one of many .NET limitations - strange in a
world where Microsoft claims to be at the "cutting edge" of media
developments?


Oh for Pete's sake! Where did they claim that .NET is at the cutting edge of
media developments? Microsoft is not 100% geared towards .NET you know. They
have masses of tools and product of which .NET is currently a small (but
growing) part. .NET is their long-term strategy, but not all of what they
do. So, I'm sure that you can concede that in an organisation Microsofts
size it is feasible that you could have areas which are at the "cutting edge
of media developments", and others which are not?
Jul 21 '05 #138

P: n/a
Hi Sean,
.NET is limited, bloated, slow and inefficient for programming of real
world enterprise and world facing tasks (no surprises there).
Compared to what?
Compared to everything else except VB6.
I find .NET more than fast enough for my purposes
(managing enterprise workflows and documents). I certainly haven't noticed
any massive speed drops when switching.
Yes, if you've moving through a form, it won't make any difference, but
have you tested it with processor intensive tasks on a world facing
application with 1000 user sessions, or rendering an amimated 3d model
of an aircraft engine, or editing some MPEG-4 video in real-time? The
original topic of this thread was related to "serious applications". Of
course not all serious apps need to be processor intensive, nor should
they be. I think the original poster was talking about things like
Office, Photoshop, Premiere, SQL Server, Backup Exec, VirusScan.

The .NET heads on this group claim that .NET is "more powerful" than
unmanaged code because it's "easier to use". This is nonsense. Ease of
use is not a criteria when you're a seasoned developer. Slick installs,
superfast response times and rock-solid stability certainly are. Not
only that, you don't want your app at risk next time some idiot upgrades
the framework in conjunction with some other product. That's certainly
worth looking out for, soon we'll have a mish-mash of .NET 1.1, and .NET
2.0 targetted apps and everyone installing the same thing over and over
again, breaching security on the user's machine because the latest
patches were not slipstreamed into the .NET distributable at the time
the app was released. Hell, you can't even slipstream patches into the
dist even if you wanted to.

Can you imagine writing an Anti-Virus app in bungling "managed code"?
That's what Microsoft are claiming we should do under "Longhorn". Have
you any idea how badly the file serving SAN of a huge corporation would
run with a .NET based Anti-Virus scanner? Not only that, but none of the
data structures would make any sense at that level. Can you imagine SQL
server trying to run a block-level bulk-insert under "managed code", I
don't think so. Have a good look at Yukon SQL 2005 and tell me if you
see "managed code all the way to the metal" - I don't think so! Why?
Because when you need a job doing properly, you have to use a proper
programming methodology, and .NET it aint.
I've generally found that the #1
cause of poor performance is poor programming, not the platform.
Very true!
I take it you haven't looked into such things as the tight control you can
exert over things like Remoting and the Runtime. Ever tried to implement a
custom compression scheme on DCOM?
No, that sounds difficult! What does it do?
I never figured it out, and I suspect
it's impossible. Making things that should be simpler easier is not a bad
thing. Or would you have us still using assembler for business apps?
No, I agree that some levels of abstraction can only be a good thing.
Oh, and by the way, I was a "VB6 head". I used VB6 because it allowed me to
do my job quicker and easier.
Hmm.
Sure, I sometimes dropped down into ATL to
produce libraries to get around VB's limitations, but my primary tool was
VB. Now, I mainly use C#, and you know what? The amount of time I spend
dropping down into C++ is virtually nil, because I don't need to. IMO that
indicates a pretty good programming environment.
Yes I agree, but what exact kind of things did you used to do in ATL
that you now do in C#?
I'm sick of this impression that because one uses a RAD tool, it makes one a
worse programmer in some way.
The problem arises when they get stuck and come running to me.
tool for the job makes one a *better* programmer. If the tool makes simple
things simpler, fantastic. I can assure you that as a "VB6 head" I had a
better understanding of COM than all the C++ programmers at my previous
company.
I thought COM and API calls under VB6 were a joke, but there we are.
elegant codec source code in front of me, and it's actually written under
NASM (the non-Microsoft assembler). The day we see this kind of thing is
C# and .NET will be a very interesting day indeed!

We never will. What would the purpose be? Using something like SIMD flies
completely against the whole idea of IL. What we might see are .NET
libraries that expose the capabilities of this.
Yes, but my original comments were against the claims that "it can be
..NET all the way to the metal", in order to perform the task you outline
above, we'd need to switch to unmanaged code - which goes all the way
back to my original gripe.
Hell, why don't you do it?
Yikes, o/s independent ASM neatly wrapped up in .NET - maybe in my dreams!

Of course that reminds me of another major problem with .NET, it's
Microsoft only (ok I know about Mono, but let's keep that separate for
now). I'm looking at some production C++ code here, the clever part is
that huge chunks of it can run on Linux, Unix and Mac, with just a 2
tiny additional DLLs to make each o/s talk to it - you can't do that in
..NET, hell I've even got some Java code here that can run "out of the
box" on Linux, Mac and Windows - try that with .NET. Why do you think
HP, IBM and Nortel Networks are using Java instead of .NET?
Oh for Pete's sake! Where did they claim that .NET is at the cutting edge of
media developments?


I didn't say ".NET", I said "Microsoft", and .NET happens to be what
Microsoft are claiming is the "future of Windows", and we can only
assume that means multi-media too? Or maybe they don't want developers
being able to do multi-media - could be seen as competition to
pay-per-view Windows Media with DRM etc.

OK, I've worked it out!

[ * the following is fiction and joking around * ]

Does anyone remember years ago under Win16 API there was a claim that
Microsoft had some "secret" API calls that could make their products
perform better than the competition? I never knew if this was true, but
it sounded possible (e.g. if you [Microsoft] knew there's a bug in one
of your APIs and didn't want to wait for the next "official" release,
you could create a new version and use it in your own products ahead of
the competition - who would have to continue to use the buggy version).

We could see this repeated, only this time with managed vs unmanaged
code. Microsoft will keep the fast, slick, flexible unmanaged code for
their own products, but will force competitors to use bungling managed
code instead, with all it's toy-town limitations. This would guarantee
Microsoft's products would always work faster and better than those of
"3rd parties".

[ * end fiction and joking around * ]

--
Gerry Hickman (London UK)
Jul 21 '05 #139

P: n/a
Ummmmm.

We could see this repeated, only this time with managed vs unmanaged
code. Microsoft will keep the fast, slick, flexible unmanaged code for
their own products, but will force competitors to use bungling managed
code instead, with all it's toy-town limitations. This would guarantee
Microsoft's products would always work faster and better than those of
"3rd parties".

Microsots Sql Enterprise Manager is a an example of that "fast
wonderful code" that works faster and better. It works so much faster
and so much better that I can crash it evfery single time I use it if i
want to. It works so well and so much faster that my own Database
manager developed in .NET is a scale of 3-5 times faster then it, more
functional and user friendly in aspects that i have had time to work on
and things that cause SQL Manager to crash do not crash my application.

How a programmer uses the language is really what determines how useful
it is. I can tell you from my own experience and usage of the langauge,
I turn it into something powerful and I attempt to concentrate on
making interfaces more user friendly, bringing more functionality and
better error handling and notification when something does go wrong to
the table.

Jul 21 '05 #140

P: n/a
Hi recoil,
Microsots Sql Enterprise Manager is a an example of that "fast
wonderful code" that works faster and better. It works so much faster
and so much better that I can crash it evfery single time I use it if i
want to.


This is strange because all the developers in my office today were
saying how good it was (and I happen to agree). Can you list the exact
steps required to crash it, so I can replicate on my own systems. We're
running a pure Win2k network in native mode AD, with mirrored Linux DNS.
Our SQL server is running v2000 with service pack 3.

I've never seen it crash.

But this is hardly related to what we were discussing - the Enterprise
manger is just a UI, I was talking about the ability to serve block
level data from a RAID enabled SAN - believe me, you don't want .NET
anywhere near something like that.

--
Gerry Hickman (London UK)
Jul 21 '05 #141

P: n/a
Installed an Update and the next time I went to open Enterprise SQL
Manager it crashes. No window shows up. just the "Microsoft Management
Console has encountered a problem and needs to close. We are sorry for
the inconvenience."

Unhandled exception at 0x0101f07e in mmc.exe: 0xC0000005: Access
violation reading location 0x00000064.

0101F06C mov ecx,esi
0101F06E call dword ptr [eax+5Ch]
0101F071 mov eax,dword ptr [ebx]
0101F073 mov ecx,ebx
0101F075 call dword ptr [eax+60h]
0101F078 mov eax,dword ptr [esi]
0101F07A push 0
0101F07C mov ecx,esi
0101F07E call dword ptr [eax+64h]
0101F081 mov byte ptr [esi+101h],0
0101F088 mov byte ptr [ebp-4],0
0101F08C call 01080E36
0101F091 mov ecx,dword ptr [eax+4]
0101F094 call 01080EAE
0101F099 push 8000FFFFh
0101F09E mov edi,10A3E78h
0101F0A3 push edi
0101F0A4 lea eax,[ebp-14h]
0101F0A7 push eax
0101F0A8 call 01018F06
0101F0AD mov ecx,dword ptr [eax]

EAX = 00000000 EBX = 009A1EF0
ECX = 009A10A8 EDX = 000A2F98
ESI = 009A10A8 EDI = 0003BC10
EIP = 0101F07E ESP = 0007F6E0
EBP = 0007F720 EFL = 00000202

00000064 = ????????

Jul 21 '05 #142

P: n/a
Hello,

I want to give some example on the contrary to what has been said here about
Windows Media and .Net.
In the company I work for we (the team, but not me personally) have created
a timeshifting Media Server plugin that records a live Windows Media
broadcast and allows users to watch it 'timeshifted' by any offset. The
plugin was first implemented in C++ with the use of Media Format SDK, but
this combination introduced many problems, especially the Media Format SDK
part. Then the author of the plugin made a shift to pure .Net (even wrote
basic ASF-parsing code), throwing away everything non-dotnet. BTW, it is not
recommended (by many 'experts') to write Media Server plugins in managed
code. As for now the plugin works perfectly, the development time and bug
amount was greatly reduced, and the performance is not very much lower than
of the Media Server itself (during load tests the plugin was not the
bottleneck, earlier we topped the IO and network throughput, and the
performance of the timeshifting plugin was almost the same as of 'pure'
mms).
So, this is a clear example that there are areas in digital media software
that could benefit from the .Net platform. However, some advanced .Net
knowledge is necessary to anticipate and prevent performance problems, and
probably a pure drag&drop programmer wouldn't make it.

Best Regards,
Rafal Gwizdala

"Gerry Hickman" <ge********@yahoo.co.uk> wrote in message
news:Ox**************@TK2MSFTNGP15.phx.gbl...
Hi recoil,
Microsots Sql Enterprise Manager is a an example of that "fast
wonderful code" that works faster and better. It works so much faster
and so much better that I can crash it evfery single time I use it if i
want to.


This is strange because all the developers in my office today were saying
how good it was (and I happen to agree). Can you list the exact steps
required to crash it, so I can replicate on my own systems. We're running
a pure Win2k network in native mode AD, with mirrored Linux DNS. Our SQL
server is running v2000 with service pack 3.

I've never seen it crash.

But this is hardly related to what we were discussing - the Enterprise
manger is just a UI, I was talking about the ability to serve block level
data from a RAID enabled SAN - believe me, you don't want .NET anywhere
near something like that.

--
Gerry Hickman (London UK)

Jul 21 '05 #143

142 Replies

This discussion thread is closed

Replies have been disabled for this discussion.