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 > Hi, > > 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. > > Now, on other remarks, considering that: > - This has never be presented as a fix (but as a test) > - Win32k INIT_FUNCTION is not defined for GCC (only for MSVC) > - Testbot is now stuck in ARM³ MM bugs > - You are away after breaking trunk (as usual) > - Said "_Some_ people" include our testbot and some of our devs > - Being mean won't fix anything > > Only ntoskrnl will get its INIT_FUNCTIONS back. > If GCC is broken, then we should only use that feature on MSVC, as it's done > with win32k. > If you are unhappy with such measures, keep in mind that you have commit > access also for fixes. > > Btw, www.itworksforme.com is a pretty bad reference. > > Regards, > P. Schweitzer > > > Hi, > > > > Considering that: > > > > - The code to throw out INIT sections isn't in trunk, so _nothing happens_ > > when a function is made INIT or not. > > - There were already many INIT functions in NTOSKRNL and the kernel worked > > fine > > - 49463 only added INIT_FUNCTION to the HAL > > - A later revision by Timo added INIT_FUNCTION to win32k, and that worked > > fine as well > > > > Don't you think it's a bit, pardon my language, braindead, to revert > > INIT_FUNCTION in NTOSKRNL, as your patch did? Wouldn't it make more sense > > to simply revert INIT_FUNCTION *just* in the HAL, which is what 49463 > > added? Why remove it from NTOSKRNL, where it always worked? Why _not_ > > remove it from Win32k, if you think INIT_FUNCTION is what's wrong? Your > > "fix" makes absolutely no logical sense from _any_ point of view (as usual). > > > > On a more serious note, don't you think it's strange that merely placing > > code in a section (which right now isn't dropped, or messed with, in any > > way), would cause problems in the OS? Isn't it immediately obvious to you > > that this is a red herring or that the compiler is broken? Especially since > > the revision only causes problems for _some_ people? For example, it works > > for me, and I even have a local change that _throw out_ init code. > > > > Please learn some basic rational logic methodologies, the scientific > > method, and software engineering processes. > > > > -r > > > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
