Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 27th of June, 19:00 UTC. And that's tomorrow!
Put that into your calendars so you don't forget.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords 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 Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Hi All,
A few months ago, an SVN branch, vs_jc, was created so that I could
experiment with manual creation of Visual Studio solution. I am ready to
start putting files into it, but before I do, I would like to get it synced
with the trunk. Unfortunately, I am not very experienced with SVN (more like
hopelessly ignorant), and Id like to avoid making a mess if possible. I was
hoping that someone could sit with me for the 10-15 minutes that would be
needed to get it right so that I dont make a mess. Hermès was helping me
yesterday do a merge, but he seems to be out-of-pocket at the moment, and
Id rather not wait, as I am blocking the work of others.
The merge generated a lot of conflicts, and I see no option on Tortoise SVN
menu to resolve them, and I have tried 6 or 7 times myself to do a merge,
each time not being clear on what I am doing. I would have no problem
whatsoever blowing away vs_jc and simply branching HEAD-of-trunk and
starting over, as there is currently nothing that I put in vs_jc that is of
value.
Cheers!
-JC
That is still not correct. MM_DECOMMIT (which should be aliased as
MM_GUARDPAGE) is 0x10.
BUT, this is only a guardpage, if 0x8, aka MM_NOCACHE is not set.
it's like this:
Protection & 0x18 ==
0x00: normal
0x08: uncached
0x10: guard page
0x18: write combined
see http://www.reactos.org/wiki/Techwiki:Memory_Protection_constants
Am 16.06.2013 22:37, schrieb dreimer(a)svn.reactos.org:
> Author: dreimer
> Date: Sun Jun 16 20:37:04 2013
> New Revision: 59238
>
> URL: http://svn.reactos.org/svn/reactos?rev=59238&view=rev
> Log:
> logical 'and' applied to non-boolean constant
> Reviewed by Thomas Faber and asked for commit, so blame him!
> CORE-7207 #resolve #comment Fixed!
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Sun Jun 16 20:37:04 2013
> @@ -647,7 +647,7 @@
> (EndAddress >= ((PMMVAD_LONG)Vad)->u3.Secured.StartVpn))
> {
> /* Guard page? */
> - if (ProtectionMask && MM_DECOMMIT)
> + if (ProtectionMask & MM_DECOMMIT)
> {
> DPRINT1("Not allowed to change protection on guard page!\n");
> return STATUS_INVALID_PAGE_PROTECTION;
>
>
>
( end of the message) , and its more elegant than many (str[i] !=
prefix[i] || ) instructions.
Maybe youre criticizing this change because of performances reasons ?
Cheers
Hermès
De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belusca@sfr.fr]
Envoyé : lundi 3 juin 2013 11:10
À : 'ReactOS Development List'
Objet : RE: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
It was suggested by Thomas Faber, during some fixes of path.c
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
part de Alex Ionescu
Envoyé : lundi 3 juin 2013 04:33
À : ReactOS Development List
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
You should realize there's sometimes a reason why code doesn't use an
existing helper function. Among some very good bug fixes and patches, you
really seem to love changing code just for the sake of changing code.
Best regards,
Alex Ionescu
On Sun, Jun 2, 2013 at 3:51 PM, <hbelusca(a)svn.reactos.org> wrote:
Author: hbelusca
Date: Sun Jun 2 22:51:24 2013
New Revision: 59165
URL: http://svn.reactos.org/svn/reactos?rev=59165
<http://svn.reactos.org/svn/reactos?rev=59165&view=rev> &view=rev
Log:
[RTL]
Use RtlPrefixUnicodeString.
Modified:
trunk/reactos/lib/rtl/path.c
Modified: trunk/reactos/lib/rtl/path.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165
<http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165&r
1=59164&r2=59165&view=diff> &r1=59164&r2=59165&view=diff
============================================================================
==
--- trunk/reactos/lib/rtl/path.c [iso-8859-1] (original)
+++ trunk/reactos/lib/rtl/path.c [iso-8859-1] Sun Jun 2 22:51:24
2013
@@ -479,13 +479,19 @@
/* Capture input string */
CapturedDosName = *DosName;
- /* Check for \\?\ form */
- if ((CapturedDosName.Length <= RtlpWin32NtRootSlash.Length) ||
- (CapturedDosName.Buffer[0] != RtlpWin32NtRootSlash.Buffer[0]) ||
- (CapturedDosName.Buffer[1] != RtlpWin32NtRootSlash.Buffer[1]) ||
- (CapturedDosName.Buffer[2] != RtlpWin32NtRootSlash.Buffer[2]) ||
- (CapturedDosName.Buffer[3] != RtlpWin32NtRootSlash.Buffer[3]))
- {
+ /* Check for the presence of the NT prefix "\\?\" form */
+ if (RtlPrefixUnicodeString(&RtlpWin32NtRootSlash, &CapturedDosName,
FALSE))
+ {
+ /* NT prefix is contained in the path */
+
+ /* Use the optimized path after acquiring the lock */
+ QuickPath = TRUE;
+ NewBuffer = NULL;
+ }
+ else
+ {
+ /* NT prefix is not contained in the path */
+
/* Quick path won't be used */
QuickPath = FALSE;
@@ -497,12 +503,6 @@
NewBuffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, MaxLength);
DPRINT("MaxLength: %lx\n", MaxLength);
if (!NewBuffer) return STATUS_NO_MEMORY;
- }
- else
- {
- /* Use the optimized path after acquiring the lock */
- QuickPath = TRUE;
- NewBuffer = NULL;
}
/* Lock the PEB and check if the quick path can be used */
Revisions >= 59161 are fine (before starting with 59152 they are broken
- known).
This is only due to a VMware testbot internal failure. This is now fixed.
Sorry for the flood.
On 03/06/2013 00:28, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/985
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 59161
> Blamelist:
>
> BUILD FAILED: failed test
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation