Why no serious MS Application in .NET yet ??

[Gerry Hickman]

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]

Hi Daniel,

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...)

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.

 

[Darrel]

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

 

[Sean Hederman]

Hi Sean,



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

 

[Daniel O'Connell [C# MVP]]

Hi Daniel,



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 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?

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.

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.

 

[Gerry Hickman]

Hi Daniel,

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.

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!

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?

 

[Sean Hederman]

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?

 

[Guest]

Wrappers are a wonderful tool, *IF* used properly. Wrappers are used to take
existing, functional code, and make it work properly in a new environment.
Why rewrite the Win32 code to make it managed, if it already works? (OK, not
perfectly, but who writes 100% perfect code all the time?) Why do we insist
on re-inventing the wheel so bloody often? I write in both VB and VC, and
having to create wrappers to call specialized code in the other language is
just normal. .NET does it for me. Never written a TCP/IP app? Need to
understand XML parsing? Maybe you need to write a security aware app? Use
the .NET to understand the concepts behind it. As a learning tool, and for
raw code re-use, .NET is more useful. So it wraps Win32 API calls. Try
reading the Platform SDK as a new developer and writing something useful
directly to the API. Most VC6 users wrote to MFC, not the underlying API.

 

[Guest]

Then what are all these talks about the future platform of programming?
Isn't
"it" sth more than a wrapper around the real APIs?

 

[Guest]

Hi all,

first let me state a short sorry for the "empty" post I caused above ...
I think Mr.Lucifer ( freely translated with my DCX German ) is slightly
starting a flame thread

While talking about some "serious application" just a day before his focus
now includes the complete API . I'd refer to Bob Grommes but I'd like to
add a question.
Did you - Herr Lucifer - expect the introduction of trinary computing with
..NET or what are you really aiming at ?
If you just take few hours and get a head start into .NET for yourself you
will no doubt find out about some key-benefits.

No need to be sarcastic or asking whatever-motivated questions.
Give it a try ... and feel it

Cheers !

 

[Gerry Hickman]

Hi Sean,

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.

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 * ]

 

[recoil]

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.

 

[Gerry Hickman]

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.

 

[recoil]

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 = ????????

 

[Rafal Gwizdala]

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]

Hi Rafal,

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.

That's hardly comparable to the examples I gave. We all know that .NET
is good at creating "lag", and this is perfect when you want to watch
something later.

The examples I gave were related to professional video editing, encoding
and decoding, and rendering of complex effects in real-time. If you know
of a way to do this in .NET (without simply calling the superior COM
interfaces) then please let me know.