From 5e7ce7f6f54d4f9be4f45d366ee47648792030ac Mon Sep 17 00:00:00 2001 From: Royce Mitchell III Date: Wed, 22 Dec 2004 18:57:09 +0000 Subject: [PATCH] forgot to commit responses file svn path=/trunk/; revision=12290 --- rosapps/games/ArchBlackmann/tech.txt | 54 ++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 rosapps/games/ArchBlackmann/tech.txt diff --git a/rosapps/games/ArchBlackmann/tech.txt b/rosapps/games/ArchBlackmann/tech.txt new file mode 100644 index 00000000000..66f452342ba --- /dev/null +++ b/rosapps/games/ArchBlackmann/tech.txt @@ -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 -- 2.17.1