reactos/rosapps/games/ArchBlackmann/tech.txt
Royce Mitchell III eba02683e2 give Arch a little more variety
svn path=/trunk/; revision=12296
2004-12-23 02:24:04 +00:00

61 lines
No EOL
3.6 KiB
Text

What do you think I am, your personal tech support?
You *know* a %stru% 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 when you try to do that ( duh! ).
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 %dev%, 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 %stru% 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?
Didn't %dev% fix that already?
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 %dev% 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.
Just put a NULL dereference in there and commit it. It helps get bugs fixed fast! (Not that I would know)
ASSERT is your friend!
I dunno.. but I bet %dev% 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.
$#@!$ One of these days I'm gonna throw %module% out the window!!! Sorry, what were you saying?
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...
Just delete it, it can't be that important ( You should see all the useless cruft I got rid of in %module% )
Try queueing a work item...
My %stru% fell in love with some %stru% in %module%, and %module% 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 %dev% would just finish %module% 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 %dev%
Thank you for that amazingly keen insight, Commander Obvious.
Sorry, can't help you right now, trying to track down this bug %dev% caused in %module%
I dont know about that, but I just fixed a problem in %module% for %dev%
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*
42
It's gonna take me %period%s to fix all %dev%'s bugs in %module% :(