Hi all,
A first release candidate of RosBE-Unix 2.0 is now available on
http://svn.reactos.org/RosBE-Temp/. Compared to 1.5, it finally includes
CMake 2.8.5 (with Jerome's patches), an updated GNU Make and new GMP and
MPFR libraries. For the latter ones, I've added a patch to fix building
under Mac OS X 10.7.
Please try it out and tell me about your results. If there's anything
that needs to be fixed before the release, please tell me in a reply to
this mail.
For the reference, the current CMake building commands in a ReactOS
checkout are as follows:
- ./configure.sh
- cd output-i386-MinGW/host-tools
- makex
- cd ../reactos
- makex bootcd
I'll also set up this Build Environment on the Debug Buildslave as soon
as possible.
Happy building,
Colin
Hello!
As per discussion during the last status meeting, I proposed to set
up a deadline for having a 0.3.14 Release Candidate available by the
time of the next meeting.
Olaf, Amine and others were kind enough to make an up-to-date list of
critical bugs and regressions to be fixed. It's available here:
http://www.reactos.org/wiki/Buglist (indeed this page should be in
your web browser's Favorites!) .
I want to ask all of you to concentrate on fixing regressions and
critical/blocker bugs first, before going into fancy features or
implementing something else. It's really important, we need to make
0.3.14 as the last release before switching to 0.4. We have all
necessary prerequisites, and just need to sit down and fix regressions.
I personally put off all of my ReactOS-related "fancy" projects
because I want a solid trunk first, and I am working only on stuff
which is urgently needed - fixing remaining LDR rewrite regressions,
special pool to catch pool corruptions, etc. It's meaningless to work
on something else now if regressions aren't fixed.
Hopefully you will follow my advice and we will have a wonderful
bugfixing week(s)!
Thank you!
WBR,
Aleksey Bragin.
Hi all,
Previously I used edited version of freeldr.ini to build livecd ISOs,
it is in \output-i386\livecd\
Now freeldr.ini is becoming overwritten in make process by newly
generated "standard" one, and it is overwriting my manually edited
version.
So
1) what is now the correct way is to have custom freeldr.ini in iso image?
2) For what are these new automagical erase-and-newly-generate scripts?
Although I can now manually edit (in iso image) what has been done
earlier automatically, replace the file, but, at my PoV something goes
wrong.
--
Best Regards,
M.A.
Hi!
Well if anyone cares! This commit message is a lie!
In IntKeyboardInput I added support for KF_DLGMODE and KF_MENUMODE !
BTW is used! In Dialog.c DF_DIALOGACTIVE! So someone will fix it
right?
Okay,
James
You might know me as a stout supporter of CMake transition, but a single experience shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with a cmake iso. The results were horrendous. The backtrace was lenghty, but on rbuild such task would take around 15 mintues for me, having all files extracted and prepped log.. At the present moment, cmake bt resolving is a total mess and practically prevents anyone doing such log. I might not be a programmer, but was somewhat skilled in my testers duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i hate it:
1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command
2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that...
3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually.
4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so?
This HAS to be resolved before rbuild is put to retirement. Amine was talking about getting back to rsym - sure, why not? Anything that works will be better than current situation.
--
With best regards
Caemyr
cgutman(a)svn.reactos.org wrote:
> - Implement support for scatter/gather DMA
This commit deserves a huge LIKE button, thanks!
Will try it out as soon as I have access to my ReactOS laptop again.
Finally a chance for getting its Ethernet port to work :-)
- Colin
Hi!!
This is wrong, 8^(
+ class.style |= CS_GLOBALCLASS;
+ class.hInstance = COMCTL32_hModule;
The point in THEMING_Initialize was to get the current global classes
and make locals for each process. So that process could have it. Not
the whole system!
Note from a msdn blog, "If you pass the CS_GLOBALCLASS flag when
registering the class, then the window manager will ignore the
instance handle when looking for your class. All of the USER32 classes
are registered as global."
I spent a week now looking through it all, ReactOS is handling the
class registration correctly. My best guess, if themes is active do as
the original code had it before and use IsThemeActive like it is
setup. Keep class.hInstance = COMCTL32_hModule; and don't use
CS_GLOBALCLAS so you can find it again.
Thanks,
James
Hi,
today, after looking at the daily source analysis we have, I found out
that all that stuff could be improved by lightening trunk. We have huge
amount of unused code (even not linked in CMake) rotting in trunk.
I'm mainly talking about icu4ros. AFAIK it was an attempt from KJK for I
even don't recall what.
Here is my proposal: we do a branch for this. And then, we remove it
from trunk. This will make things lighter, without loosing code.
Any objections/comments?
Regards,
Pierre