B
Bob Grommes
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
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
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
S
Sean Hederman
Bob Grommes said: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.
C
cody
However, when Longhorn is released, It will go from
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.
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.
G
Guest
Have you looked at Microsoft Operations Manager 2005? A considerable amount
of it is written in .NET.
of it is written in .NET.
W
William Stacey [MVP]
Cool. I never heard of Retail Management System. When was that released?
Will it integrate with SBA?
Will it integrate with SBA?
W
William Stacey [MVP]
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.
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.
G
Gerry Hickman
Hi Cody,
Who on earth wrote that! A Disney character who jumped out of the 3d
rendered Avalon desktop experience?
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.
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.
D
Daniel O'Connell [C# MVP]
Here's an example; .NET does not have any proper Video Editing
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.
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.
G
Guest
Err...ever hear of a little thing called BizTalk Server 2004? Written in C#.
1.5 million lines of it and more...
Dave
1.5 million lines of it and more...
Dave
G
Guest
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
(e-mail address removed)
http://www.smartwebagent.com
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
(e-mail address removed)
http://www.smartwebagent.com
B
Brock Allen
Umm, I couldn't wade though your entire post, but Moore's law has been dead
for a while now. We will probably not see the continuing speed improvements
we've seen over the past 40-60 years. This has been apparent in the past
couple of years.
-Brock
DevelopMentor
http://staff.develop.com/ballen
for a while now. We will probably not see the continuing speed improvements
we've seen over the past 40-60 years. This has been apparent in the past
couple of years.
-Brock
DevelopMentor
http://staff.develop.com/ballen
G
Guest
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
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
W
William Stacey [MVP]
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.
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.
G
Gerry Hickman
Hi Daniel,
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).
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...
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...
S
Sean Hederman
'"Gerry Hickman said: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/2005/01/son-of-whiny-gripes-about-net.html
D
Daniel O'Connell [C# MVP]
Gerry Hickman said: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.
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 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.
D
Daniel O'Connell [C# MVP]
Sean Hederman said:'"Gerry Hickman said: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.
G
Guest
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?
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?
R
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 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.
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.
G
Gerry Hickman
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. 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 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?
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.