Hello,
Last thursday of this month is quite close, 30th of June, 20:00 UTC
I'm awaiting you all for the monthly status meeting. Colin said that
our private irc server is going to be ready by that date, so if
that's still true, Colin - could you please provide details for those
who don't remember where to connect?
Proposed agenda is:
1. New release of ReactOS
2. Website work status
3. GSoC status
4. Developers status.
With the best regards,
Aleksey Bragin.
I'm definitely not sure that the header[1] added to all converted files was absolute necessity.
AFAIK, that's SVN logs purpose...
Unless someone has a real justification to such line?
Many files even don't have a translator copyright but this line... Weird!
[1]: /* UTF-8 Conversion: Elton Chung aka MfldElton <elton328(a)gmail.com> (June, 2011) */
Hi Erik,
The NDK is for *undocumented* types. These flags are documented.
--
Best regards,
Alex Ionescu
On 2011-06-26, at 7:29 AM, ekohl(a)svn.reactos.org wrote:
> CM_RESOURCE_INTERRUPT_LEVEL_SENSITIVE
Hello,
as all of you could notice, I committed the LDR rewrite recently. I
tried to get rid of as much regressions as possible (any rewrite
should introduce improvements of course, rewrites are not done to
introduce regressions, however there is no rewrite without some
particulars problems).
So, dear developers, I need your help. Gabriel did a very nice work
and bugzilled all kinds of problems which new LDR introduced. Here is
the meta-bug:
http://www.reactos.org/bugzilla/show_bug.cgi?id=6346
Please look into the bugs, check something and add your findings to
bugzilla. The new LDR code is perfectly organized, very well
documented, so most of those bugs should be quite simple to fix, but
my time is not infinite, so I'm asking for collaboration. I'm always
available via IRC for any questions about the new code, so feel free
to ask.
Put away your usual stuff for an hour or for a day and look into
those. It would help greatly and motivate me to finish other parts of
the rewrite quicker.
Thanks,
Aleksey Bragin.
Hi sir_richard and welcome back!
Just to make sure you know, it seems this commit introduces a regression, ros hangs while loading ndis.sys, see testbot logs:
http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/1342/s…
I've filed http://www.reactos.org/bugzilla/show_bug.cgi?id=6292
Could you please take a look?
Thanks.
> Date: Sun, 5 Jun 2011 20:48:34 +0000
> To: ros-diffs(a)reactos.org
> From: sir_richard(a)svn.reactos.org
> Subject: [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
>
> Author: sir_richard
> Date: Sun Jun 5 20:48:34 2011
> New Revision: 52098
>
> URL: http://svn.reactos.org/svn/reactos?rev=52098&view=rev
> Log:
> [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms would build FreeLDR "page entries" for every page from 0 to 0x7FFF0000 and mark it as unusable, then build the actual valid entries from 0x80000000 -> end of RAM, thus resulting in large memory consumption (and in the bloat of the PFN database later once NTOS loads) and boot time. Therefore, the algorithm is changed to start the PFN database at the lowest valid RAM page described by the Firemware descriptors, and entries therefore will be offset. This means a 128MB embedded system no longer appears to have 2048+128MB of RAM worth of PFN entries.
> NOTE: Windows does not do this, opting instead to force manufacturers/use pull-up resistors/reconfigure the ARM Bus to map RAM at 0x00000000. For wider portability, I believe it makes more sense to simply do this "trick" in the boot loader.
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c
> trunk/reactos/boot/freeldr/freeldr/mm/meminit.c
>
Hi,
I'd like to change the Vtbl based architecture of freeldr into a normal
function call system.
Currently we have stuff like
#define MachHwDetect() MachVtbl.HwDetect()
MachVtbl.HwDetect = PcHwDetect;
This is IHO simply useless, since these functions don't change. I
suggest simply renaming PcHwDetect to MachHwDetect and do that will all
of those and get rid of the MachVtbl.
Any objections?
Regards,
Timo
gedmurphy(a)svn.reactos.org wrote:
> +// WIDL temp hack : [...]
Even though we all like to see a full MSVC build in the future, does
this really justify such an even bigger hack on top of the existing
ones? Would a proper fix really require that much more time?
If we don't want to end up in a new mess, this pretty much forces
someone to fix it in the coming days or the hack/commit will be
forgotten again. I'm certain about this, because nobody on #reactos-dev
really knew the reason behind the older __ROS_LONG64__ hack either.
Alternatively, you could open a detailed bug report about this issue and
assign some CMake people to it. But in any case, such hacks should be
tracked in our Bugzilla, in particular when more information about a
solution is known already.
- Colin