OK, C# can be a PITA
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithNo one should be using P-Invoke if not understanding .NET memory management. Though tricky I find P-Invoke good fun, playing around with GCHandle, using delegates for function pointers (don't forget keeping them from being garbage collected!), so you can have callbacks from native to managed. Also don't forget about using InAttribute, OutAttribute and SuppressUnmanagedCodeSecurityAttribute to get the performance up. And yes, pinvoke.net is unreliable, just about any nitwit can put what they think is the right signature on there.
Wout
-
So you're interfacing with native code and in doing so have brought all the associated warts of it into the interface. Doesn't seem particularly newsworthy to me, except perhaps as an answer to the people wondering why MS doesn't just take the contents of pinvoke.net and provide .net wrappers for 100% of win32.
-- Rules of thumb should not be taken for the whole hand.
dan neely wrote:
Doesn't seem particularly newsworthy to me
What's newsworthy, IMO, is that because it is so easy to do, and there's a lot of examples out there, it gives the illusion that everything is hunkydory. Which it isn't. I bet a lot of people don't realize the issues with PInvoke nor the misinformation thats' out there. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Marc Clifton wrote:
In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes.
So does C++ when you mess with pointers, too short buffers, or all sort of inline assembly, if you're not aware what you're actually programming there. Neither language is perfect, and none is more dangerous than another one. regards
Greeeg wrote:
if you're not aware what you're actually programming there.
Quite true. Except that with C++, it's the ethos that you need to be careful about those things. With C#, it looks very easy with PInvoke. There's a lot of blank space on that www.pinvoke.net site to use for a big warning message about structures, GC, and native code. While the language may not be more dangerous than another one, it is the sense of security that C# gives you that lulls you to sleep, thus, IMO, making it more dangerous. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI honestly don't understand why people use p/invoke in c#. I've never had to use it and I've written a lot of code over the last few years in c# with the single exception of an article here for the .net platform on pocket pc. I must be missing something on this one, why did you need to use it and was there no other way to accomplish what you did without it?
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes
I think this is precisely why Microsoft doesn't recommend using P/Invoke. (I know you are aware of this I'm just blatantly pointing it out for the sake of ... hmmm ... dunno. Just thought it should be stated.) Your particular example is quite humorous from my end. Glad it was someone else rubbing their head for a change. But I can certainly see how that would be an issue.
-
Greeeg wrote:
if you're not aware what you're actually programming there.
Quite true. Except that with C++, it's the ethos that you need to be careful about those things. With C#, it looks very easy with PInvoke. There's a lot of blank space on that www.pinvoke.net site to use for a big warning message about structures, GC, and native code. While the language may not be more dangerous than another one, it is the sense of security that C# gives you that lulls you to sleep, thus, IMO, making it more dangerous. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Quite true. Except that with C++, it's the ethos that you need to be careful about those things.
I believe hardly any programmers (except the more experienced) know that carelessly using
strcpyor similiar functions can become a major pitfall. I'm talking about "plain" C(++) here, no libraries like STL involved. Too bad so many examples on pinvoke.net are erroneous, but so are many C++ tutorials you can find all around the web. regards -
I honestly don't understand why people use p/invoke in c#. I've never had to use it and I've written a lot of code over the last few years in c# with the single exception of an article here for the .net platform on pocket pc. I must be missing something on this one, why did you need to use it and was there no other way to accomplish what you did without it?
John Cardinal wrote:
why did you need to use it and was there no other way to accomplish what you did without it?
The routines in hid.dll aren't exposed in .NET, so there's no way to query the USB devices on the machine without p/invoke. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithSo if your essential point is
Marc Clifton wrote:
P/Invoke is dangerous
why not have that as the title?
-
So if your essential point is
Marc Clifton wrote:
P/Invoke is dangerous
why not have that as the title?
PIEBALDconsult wrote:
why not have that as the title?
Oh, for Pete's sake. Because, among other things, the hoops you have to go through IN C# to fix/marshal the pointers and structures makes C# a PITA.
PIEBALDconsult wrote:
So if your essential point is
That was NOT my essential point. Like most posts I make, I have several essential points. I can think of another essential point right now. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
So if your essential point is
Marc Clifton wrote:
P/Invoke is dangerous
why not have that as the title?
Yeah, can be the same problem in any .NET langauge ...
Rocky <>< Latest Code Blog Post: Vista for Web Development, Read this first! Latest Tech Blog Post: USA City Burnt To Death...
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
In other words, C# can be as, if not more, dangerous than C++
Excellent. I feel all bad-ass again now. Now where are some scissors so I can go running?
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around!
I would normally just alloc the 'unmanaged' memory :)
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithJust a hint: in .NET you can pin objects so the GC doesn't move them in memory.
________________________________________________ Personal Blog [ITA] - Tech Blog [ENG] Developing ScrewTurn Wiki 2.0 (2.0 Alpha is out)
-
I honestly don't understand why people use p/invoke in c#. I've never had to use it and I've written a lot of code over the last few years in c# with the single exception of an article here for the .net platform on pocket pc. I must be missing something on this one, why did you need to use it and was there no other way to accomplish what you did without it?
Monitoring for changes to files on a SAMBA share. The modern API wrapped by FileSystemWatcher isn't supported by Samba, and based on a message I managed to excavate from a mailing list archive won't be in the future because implementing it with acceptable performance would require large chucks of kernal level code. I've done several other minor things but that was the biggie.
-- Rules of thumb should not be taken for the whole hand.
-
Maybe I'll have to write some articles on this when I get a chance! :-) Any suggestions on where to start?
J. Dunlap wrote:
Any suggestions on where to start?
With USB, or working with unsafe code? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI would recommend wrapping unsafe code in its own app domain if possible. At least the main app will be safe from unexpected errors.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
So if your essential point is
Marc Clifton wrote:
P/Invoke is dangerous
why not have that as the title?
Yes, let's change the subject... :) Why wasn't the title P/Invoke is dangerous? As if the poor guy hasn't been flamed enough for pointing out what apparently was obvious to everyone else. :)
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smiththe problem you are talking about is well known. there is a away solving it using: GCHandle?.Alloc(data, GCHandleType.Pinned); UnmanagedFunction(gcHandle.Value.AddrOfPinnedObject(), (UIntPtr)0, (uint)flags); the first function, tells the gc not to move the data from it's memory block. and the second one send the pointer to data to your unmanaged function. hope that helps, Roey
Don't believe to what you hear on the news...
-
the problem you are talking about is well known. there is a away solving it using: GCHandle?.Alloc(data, GCHandleType.Pinned); UnmanagedFunction(gcHandle.Value.AddrOfPinnedObject(), (UIntPtr)0, (uint)flags); the first function, tells the gc not to move the data from it's memory block. and the second one send the pointer to data to your unmanaged function. hope that helps, Roey
Don't believe to what you hear on the news...
Roey C wrote:
the problem you are talking about is well known.
If it's well known, then why does a prominent site dealing with p/invoke have examples that are flat out wrong? Why does that site not even discuss the issue on the front page? Also, I consider myself very proficient in C# programming. I rarely however need to use p/invoke, except last week, when I was writing some asynchronous read/write functions for USB comm. I totally forgot about the GC! I imagine this happens to other people as well. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith