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

[Pierre Schweitzer]

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/in…
>  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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev