I even misread the header. I could have reverted win32k as well. Luckily! > Who the hell do you think you are?! The day I'll need lesson, don't worry I > know who you are and where to find you. > I won't waste my time answering. Understand whatever you want, imagine > whatever you want. > Just for your information: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/include/win32kp.h?revision=49580&view=markup > And be sure I'll question your commitment whenever it's needed. > "Discussion" is over for me. > > > Hi, > > > > It appears your arguments are because you don't seem to understand what you > > have done wrong. > > > > Let me spell it out: > > > > " I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, > > just to be sure. I can get back ntoskrnl as they don't seem to be > > concerned." > > > > ie: > > > > "I know that my fix went beyond what was needed, but I did it anyway "just > > to be sure"". > > > > ie: > > > > "I know that A is impossible, yet I check for A anyway" -> logical fallacy > > > > Next: > > > > "- This has never be presented as a fix (but as a test)" > > > > Yet your email said "this will not be reverted". A test, by definition, > > should be reverted. Again, logical failure. > > > > Next: > > > > > - Win32k INIT_FUNCTION is not defined for GCC (only for MSVC) > > > > Strange, because Timo used objdump to let me know how big the .INIT section > > was. Maybe he was lying, I don't have information, so I'll pass. > > > > Next: > > > > > - Testbot is now stuck in ARM³ MM bugs > > > > I can't seem to access builds.reactos.org to check, but I think this > > argument really nails it: you really don't get it (you don't get the > > scientific method). > > > > You've just proven that the test samples are corrupted (ie: the compiler is > > broken), and now you expect me to hunt for bugs (ie: you expect me to > > analyze test results on samples that are now corrupted). > > > > The answer is no, I will not fix "bugs" which might be due to a broken > > compiler. Fix the compiler, than I'll spend time hunting bugs. > > > > > - You are away after breaking trunk (as usual) > > > > How am I away? I've been posting to this mailing list, haven't I? I've been > > working on ARM porting, which, in case you don't know, is my job. I've > > posted screenshots of FreeLDR booting up on a real ARM board (I don't think > > you understand the complexity involved). I've almost got the keyboard > > working. The fringe benefits of C changes and new memory management code, > > which don't seem to be appreciate, are just bonuses out of the kindness of > > my heart, and they set back my port significantly. It was booting to > > user-mode with the old memory manager, now much of the work had to be > > restarted/refactored (obviously, it benefits the ARM port too, but I > > could've skipped this and done it the easy way). > > > > My last 20 commits or so have ALL been bug fixes, and I still have more in > > the pipeline. I've fixed bugs that were more than 10 years old. > > > > Don't ever question my commitment again. > > > > > - Said "_Some_ people" include our testbot and some of our devs > > > > That's _exactly the point_. You've obviously got a strange > > system/os/host/compiler issue going on, which is why it works for some, but > > not for others. I wasn't saying there isn't a problem, I was saying the > > problem is subtle and could be responsible for other subtle "bugs" as well. > > You're ignoring this, and forging ahead (with corrupted test samples). What > > is this, the movie Splice? > > > > By your analysis, because GCC is broken, we should only use MSVC. I refuse > > to do so (and MSVC has its share of bugs). This "feature" is called PE > > sections. So you are saying GCC cannot/fails at generating PE sections. In > > other words, we can't use .data, .rsrc, .idata, etc anymore. In other > > words, the compiler is 100% broken and cannot be used. How do we know it's > > not failing because putting stuff in a different section doesn't somehow > > corrupt the code? Well, that means that it's also possible for code/data in > > .data, or in .idata to get corrupted in the exact same way. In other words, > > the compiler is broken and WE CAN'T TRUST ANYTHING. > > > > Finally "> - Being mean won't fix anything". > > > > Don't be a child. I was being harsh on your premise, to, I quote "not > > revert the commit", which implied that "well, the compiler is broken, but > > we'll just ignore that and assume there's no other side effects". Being > > "mean" is an entirely different emotion and outside the scope of the > > technical/professional communication I'm attempting to have with you. I am > > trying to educate/teach you. Being mean (and unprofessional) would've > > involved reverting your changes and calling you an idiot (I never once > > attacked you personally -- I called your decision braindead, that is > > different). > > > > -r > > > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > [email protected] > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
