Hi all,
Based on Hermès' suggestion, I've transformed our Debug-Buildbot
"Trunk_x86_GCCLin Debug" into a Patchbot. That means, it will continue
to build each SVN revision as usual, but you can also force a build and
enter a patch ID. Your build will then be patched accordingly.
After building and testing, you will have:
* The patched regtest ISO at http://iso.reactos.org/regtestcd/
* A test result in Testman with source "Patched Trunk_x86_GCCLin (KVM)"
These changes will be applied to the other Buildslaves too once our
servers are all back up.
Cheers,
Colin
Hello,
Let me invite you to the monthly status meeting taking place 26th of
February, 19:00 UTC.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Pierre before the meeting started to get one.
Please send agenda proposals to me before the meeting, so that we can
start with a proposed agenda.
And join Mumble! :-)
Regards,
Aleksey Bragin
Hi all,
As tests have shown that VirtualBox doesn't work properly inside an
already virtualized environment, ReactOS Deutschland e.V. has just
ordered a tiny Intel NUC that will serve as a VirtualBox Testslave. We
plan to set it up right next to our Buildslaves, so that every ISO could
possibly be regression-tested under VirtualBox. As a start, we plan to
test the builds of the new MSVC Builder. The machine is powerful enough
though to eventually test multiple ISOs simultaneously.
I don't know about the current state of sysreg2 regarding VirtualBox
support. To let this all happen as soon as possible, please ensure
sysreg2 can fully handle VirtualBox once I set up the machine.
Cheers,
Colin
I don't care about the reason.
Tests that fail on Windows are broken, period. In this order the tests
fail on Windows.
On 2015-02-26 09:38, jimtabor(a)svn.reactos.org wrote:
> Author: jimtabor
> Date: Thu Feb 26 08:38:00 2015
> New Revision: 66464
>
> URL: http://svn.reactos.org/svn/reactos?rev=66464&view=rev
> Log:
> [User32_WINETEST]
> - Move test_SetFocus first as it is done originally. Refer to read past wine CVS logs for the reason.
>
> Modified:
> trunk/rostests/winetests/user32/msg.c
>
> Modified: trunk/rostests/winetests/user32/msg.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/user32/msg.c?re…
> ==============================================================================
> --- trunk/rostests/winetests/user32/msg.c [iso-8859-1] (original)
> +++ trunk/rostests/winetests/user32/msg.c [iso-8859-1] Thu Feb 26 08:38:00 2015
> @@ -14717,8 +14717,8 @@
> START_TEST(msg_focus)
> {
> init_tests();
> + test_SetFocus();
> test_SetActiveWindow();
> - test_SetFocus();
>
> /* HACK: For some reason test_SetForegroundWindow fails on Windows unless
> * we do this */
Hi!
The message testing, LOL just made more work for Amine...
Okay AlterWindowStyle, could it be better to place it in WIN_SetStyle as a
wrapper, maybe? WIN_SetStyle is just glue code for ReactOS.
James
Author: tkreuzer
Date: Tue Feb 24 23:15:08 2015
New Revision: 66444
[USER32_APITEST]
Add some test for GetDCEx that highlight the ridiculous implementation
of owned and class DCs.
Hello All!
What is ridiculous is the attitude of our smart A__ developers!
James
Hi
I'd like to propose introducing C++ to win32k. Don't worry, this is not
a suggestion to rewrite everything from scratch in C++, but to gradually
introduce C++.
The reason is not "That's what Windows does", but the fact that
especially GDI would heavily benefit in terms of code simplicity,
clarily and quality from using C++.
A lot of the interfaces are already in a C++ object style way, but still
code can bypass interfaces and directly modify structure members, even
if it is not supposed to be done that way.
Unless there are strong objections, I'd post a design / style / roadmap
suggestion soon.
If people feel strongly about it, we can defer this to after a 0.4.0
release.
Regards,
Timo
it might fix an assert but the patch is incorrect. will this also take 6
months to revert?
Best regards,
Alex Ionescu
On Tue, Feb 17, 2015 at 6:19 AM, <jgardou(a)svn.reactos.org> wrote:
> Author: jgardou
> Date: Tue Feb 17 14:19:05 2015
> New Revision: 66334
>
> URL: http://svn.reactos.org/svn/reactos?rev=66334&view=rev
> Log:
> [NTOSKRNL/MM]
> - MiIsEntireRangeCommitted: Ensure the PTE we are checking is really
> faulted in.
> - Prefer MiPteToPde and MiPdeToPte (which should really be called
> MiFirstPteInPde) instead of MiAddressToPte and MiPteToAddress
> Fixes weird failed ASSERT in page fault handler when using DPH.
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Tue Feb 17
> 14:19:05 2015
> @@ -1994,14 +1994,13 @@
> if (OnBoundary)
> {
> /* Is this PDE demand zero? */
> - PointerPde = MiAddressToPte(PointerPte);
> + PointerPde = MiPteToPde(PointerPte);
> if (PointerPde->u.Long != 0)
> {
> /* It isn't -- is it valid? */
> if (PointerPde->u.Hard.Valid == 0)
> {
> /* Nope, fault it in */
> - PointerPte = MiPteToAddress(PointerPde);
> MiMakeSystemAddressValid(PointerPte, Process);
> }
> }
> @@ -2009,13 +2008,13 @@
> {
> /* The PTE was already valid, so move to the next one */
> PointerPde++;
> - PointerPte = MiPteToAddress(PointerPde);
> + PointerPte = MiPdeToPte(PointerPde);
>
> /* Is the entire VAD committed? If not, fail */
> if (!Vad->u.VadFlags.MemCommit) return FALSE;
>
> - /* Everything is committed so far past the range, return
> true */
> - if (PointerPte > LastPte) return TRUE;
> + /* New loop iteration with our new, on-boundary PTE. */
> + continue;
> }
> }
>
>
>
>