rosapps/games/ArchBlackmann
diff -N tech.txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ tech.txt 22 Dec 2004 18:57:09 -0000 1.1
@@ -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*
\ No newline at end of file