forgot to commit responses file

svn path=/trunk/; revision=12290
This commit is contained in:
Royce Mitchell III 2004-12-22 18:57:09 +00:00
parent 089686cac2
commit 5e7ce7f6f5

View file

@ -0,0 +1,54 @@
What do you think I am, your personal tech support?
You *know* a FAST_MUTEX is non-re-entrant, right?
The answer to that is so simple, I'm not going to waste my time telling you.
Well, of course... if you're not below DISPATCH_LEVEL, ros is gonna explode on ya.
I don't think that functionality has been implemented, yet.
What do you mean it crashed? It can't crash there!
Wow. That's a new one.
Ask Filip, I bet he knows.. he knows everything...
When's the last time you rebuilt?
Have you tried a make clean?
Is it plugged in?
Well it works on *my* system :P
Well don't do that, and you won't have that problem.
Didn't we already fix that?
Well... I don't know.. I just have that code disabled in my tree.
Try surrounding it with parenthesis.
Don't you know going around dereferncing null pointers all day can be hazardous to your health?
Well, duh!
There's a bit in cr3 for problems like that.
Just add a field to the PEB to keep track of it!
Don't worry about it... the garbage collector in the kernel will clean it up for you.
Did I do that?
Yes, I think I've seen that bug before... no... that was another program.
I could tell you, but then I'd have to unlink() you.
Well if you'd get some sleep, maybe you'd figure it out... not all of us can keep the hours arty can...
You did what? Uh oh... that can't be good.
Well... I could tell you, but the answer's pretty complicated. Why don't you wait to read about it in the book I'm writing.
Yeah, that's happened to me, before, too. All you have to do is wrap it in an SEH block and forget about it.
ASSERT is your friend!
I dunno.. but I bet GvG could find it for you.
I hereby declare that code is perfect. Your problem must be elsewhere.
I wrote that code... it must be perfect.
maybe I broke it in my last commit. Maybe I did it on purpose...
Have you tried debugging it? I got a can of Raid...
Try queueing a work item...
My DPC fell in love with an APC in the scheduler, and the code has been hell since...
Maybe the PEB is getting corrupted. Try allocating a new PEB and overwriting the old one. That's what I did last time I had a bug like that.
Hmm.. that seems to have been introduced by my last commit... I bet CVS mixed up the bits during the commit.
It can't possibly be my fault, so I don't care.
I'm not experiencing that problem, perhaps it's all in your mind.
Well... like a good friend of mine said... "Don't Panic!"
It just shows you how far ReactOS has come along! A year ago a bug like that wouldn't have even been possible!
Just surround the code with an #if 0/#endif block, it solves all my problems!
You know.. if kjk_hyperion had implemented lsa for us, we wouldn't be having this problem.
I say we move on to the next function, since we can't seem to figure this one out.
Well, sure, that would have been my first guess, too.... TEN YEARS AGO :p
yup, that sounds like a problem.
If I wanted to talk about VB, I'd go bug Alex...
ask arty
Thank you for that amazingly keen insight, Commander Obvious.
I dont know about that, but I just fixed a problem in MSAFD for Arty.
How should I know? I'm still trying to figure out this main() thing... ooh! wanna see what I did in the kernel?
lol!
*wink*