[ros-dev] [ros-diffs] [pschweitzer] 49662: [NTOSKRNL] [HAL] Disable INIT_FUN

Sat Nov 20 19:43:05 UTC 2010

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
> > Ros-dev at reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> 
> 
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev