On Fri, 18 Jul 2008 10:41:23 -0700, jmDesktop <needin4mation@ gmail.com>
wrote:
Well, that's an interesting example, if for no other reason than that the
DirectShow video capture stuff is a reasonably straight-forward and
natural thing to access from .NET using the p/invoke stuff. You may be
referring to the DirectShow.NET project, which I haven't used but
understand to be a pretty good wrapper for DirectShow.
As far as it not being "official" and not for "use in production", that
sort of thing is true for pretty much anything you find outside the normal
Microsoft API documentation. Even plain old C++ samples often come with a
similar caveat.
Personally, I don't think I'd ever write "don't use this in production" in
any sample code I make available, but I certainly feel that there's an
implied "use at your own risk" that goes along with _any_ sample code.
That's true...if you're going to incorporate some code into your own
projects, it may behoove you to understand what the code is doing. If
nothing else, doing otherwise risks getting someone's trojan hidden in
your own code. :)
But to some extent, it's hard to know where to draw the line. If a
component you use in your own code comes from a trusted source, do you
really need to know how it works? After all, I assume you haven't tried
to examine the implementation of .NET to determine for yourself how it
works, even though much of .NET is basically just a wrapper on the
unmanaged Windows API.
Likewise, if you find a library that you can use in your own .NET code and
which has a public API that is completely defined in terms of managed
code, as long as you trust the source, does it matter whether you know
exactly what's going on within the library?
Again, I realize in some such cases there may be warning against using the
library in production code, but to a large extent I believe that those
kinds of warnings are "CYA" measures. Any rational, thinking person
should be able to make a decision for themselves as to whether a publicly
available code sample or library is actually of high enough quality to use
in production code, regardless of whatever warnings come with it, with the
expectation that with adequate testing one can confirm or refute any
assumption of quality.
Well, as I said...I do believe that there's value in learning the
unmanaged API as well as being familiar enough with C/C++ to navigate any
example code related to the unmanaged API. So if you're of the mind to
learn that, by all means do. But I wouldn't consider it a prerequisite to
writing .NET code, and it may be that you will find it just as effective
to learn as you go along, inasmuch as you need that knowledge at all.
Pete
wrote:
Thanks. One example I came across was video capture. There are folks
out there that have written .net wrappers, but they do not appear to
be "official" and state things like "Don't use this in production."
out there that have written .net wrappers, but they do not appear to
be "official" and state things like "Don't use this in production."
DirectShow video capture stuff is a reasonably straight-forward and
natural thing to access from .NET using the p/invoke stuff. You may be
referring to the DirectShow.NET project, which I haven't used but
understand to be a pretty good wrapper for DirectShow.
As far as it not being "official" and not for "use in production", that
sort of thing is true for pretty much anything you find outside the normal
Microsoft API documentation. Even plain old C++ samples often come with a
similar caveat.
Personally, I don't think I'd ever write "don't use this in production" in
any sample code I make available, but I certainly feel that there's an
implied "use at your own risk" that goes along with _any_ sample code.
Well, if I do and it breaks, then when can I say? "Uh, I used this
guy's stuff off of CodeProject and yeah, he said not too." If I'm
going to use it I have to understand it to maintain it.
guy's stuff off of CodeProject and yeah, he said not too." If I'm
going to use it I have to understand it to maintain it.
projects, it may behoove you to understand what the code is doing. If
nothing else, doing otherwise risks getting someone's trojan hidden in
your own code. :)
But to some extent, it's hard to know where to draw the line. If a
component you use in your own code comes from a trusted source, do you
really need to know how it works? After all, I assume you haven't tried
to examine the implementation of .NET to determine for yourself how it
works, even though much of .NET is basically just a wrapper on the
unmanaged Windows API.
Likewise, if you find a library that you can use in your own .NET code and
which has a public API that is completely defined in terms of managed
code, as long as you trust the source, does it matter whether you know
exactly what's going on within the library?
Again, I realize in some such cases there may be warning against using the
library in production code, but to a large extent I believe that those
kinds of warnings are "CYA" measures. Any rational, thinking person
should be able to make a decision for themselves as to whether a publicly
available code sample or library is actually of high enough quality to use
in production code, regardless of whatever warnings come with it, with the
expectation that with adequate testing one can confirm or refute any
assumption of quality.
[...] I have had some C++, just
beginner stuff, so I can follow it and know what the constructs mean,
but that's about it. It's the low level stuff that I'd like to know
how to do because it seems to come in handy at times when looking at
MS's documentation.
beginner stuff, so I can follow it and know what the constructs mean,
but that's about it. It's the low level stuff that I'd like to know
how to do because it seems to come in handy at times when looking at
MS's documentation.
unmanaged API as well as being familiar enough with C/C++ to navigate any
example code related to the unmanaged API. So if you're of the mind to
learn that, by all means do. But I wouldn't consider it a prerequisite to
writing .NET code, and it may be that you will find it just as effective
to learn as you go along, inasmuch as you need that knowledge at all.
Pete
Comment