Hi all,
Today, the motherboard in our Fezile server has finally failed after
many hick-ups over the year. This causes an outage for the following
services:
* doxygen.reactos.org
* cppcheck.reactos.org
* VMware Player Test slave
* VMware Player Patchbot
As this is not the first time we struggle with such problems,
iso.reactos.org is routed to a different server right now and not affected.
We have already ordered replacement hardware for this system and hope to
be able to get it back to a working state soon. Even if this machine is
from 2007, we have decided to revive it with replacement parts instead
of going for a brand-new one as this is much cheaper and quicker to
realize. Also there is a huge pile of replacement hardware available.
Sorry for the inconveniences!
Cheers,
Colin
Hello,
Is there a build command to install ReactOS to a folder. Something
equivalent to "make install" of good old RBuild days?
I used to install ReactOS on real hardware this way, because it allowed
me to have more control over the install process (aka control it
completely).
Thanks,
João Jerónimo
On 2014-12-28 11:05, pschweitzer(a)svn.reactos.org wrote:
> +extern ERESOURCE IopSecurityResource;
This resource is only ever acquired shared, meaning it doesn't provide
any mutual exclusion at all. Is that intentional?
On 2014-11-22 23:13, hbelusca(a)svn.reactos.org wrote:
> + Status = NtCreateEvent(&Console->InputBuffer.ActiveEvent, EVENT_ALL_ACCESS,
> + &ObjectAttributes, NotificationEvent, FALSE);
> + if (!NT_SUCCESS(Status))
> + {
> + return STATUS_UNSUCCESSFUL;
> + // return Status;
> + }
This was a while ago, but I'm curious: what's the point of this?
Avoiding STATUS_UNSUCCESSFUL is usually a good thing.
Isn't the correct solution to use SxS with an activation context?
Best regards,
Alex Ionescu
On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote:
> Author: gadamopoulos
> Date: Sat Dec 20 16:49:31 2014
> New Revision: 65766
>
> URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev
> Log:
> [COMCTL32]
> * Do not add two additional pixels at the top margin of the toolbar. This
> is the behaviour of comctl32 v6 and our explorer depends on that to appear
> properly. We don't have a proper solution for these differences in behavior
> and since we already opt to use the v6 behavior I think it is fine.
>
> CORE-5483 #resolve #comment Committed a slightly different version of the
> patch, thanks.
>
> Modified:
> trunk/reactos/dll/win32/comctl32/toolbar.c
>
> Modified: trunk/reactos/dll/win32/comctl32/toolbar.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar…
>
> ==============================================================================
> --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20
> 16:49:31 2014
> @@ -244,7 +244,12 @@
>
> static inline int default_top_margin(const TOOLBAR_INFO *infoPtr)
> {
> +#if 0
> return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER);
> +#else
> + /* This is the behaviour in comctl32 v6 */
> + return 0;
> +#endif
> }
>
> static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle)
>
>
>
Ideally, we'd fork comctl32 into two libraries like windows does, but that
would probably mean we'd have to fork from wine, moving the maintenance
effort to our side. That's why we did not do it yet.
Sent from my Windows Phone
------------------------------
From: Alex Ionescu
Sent: 21/12/2014 09:05
To: ReactOS Development List
Cc: Linda Wang; Filip
Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do
not add two additional pixels at the top margin of the toolbar. This is the
behaviour of comctl32 v6 and our explorer depends on that to appear
properly. We do...
Isn't the correct solution to use SxS with an activation context?
Best regards,
Alex Ionescu
On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote:
> Author: gadamopoulos
> Date: Sat Dec 20 16:49:31 2014
> New Revision: 65766
>
> URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev
> Log:
> [COMCTL32]
> * Do not add two additional pixels at the top margin of the toolbar. This
> is the behaviour of comctl32 v6 and our explorer depends on that to appear
> properly. We don't have a proper solution for these differences in behavior
> and since we already opt to use the v6 behavior I think it is fine.
>
> CORE-5483 #resolve #comment Committed a slightly different version of the
> patch, thanks.
>
> Modified:
> trunk/reactos/dll/win32/comctl32/toolbar.c
>
> Modified: trunk/reactos/dll/win32/comctl32/toolbar.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar…
>
> ==============================================================================
> --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20
> 16:49:31 2014
> @@ -244,7 +244,12 @@
>
> static inline int default_top_margin(const TOOLBAR_INFO *infoPtr)
> {
> +#if 0
> return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER);
> +#else
> + /* This is the behaviour in comctl32 v6 */
> + return 0;
> +#endif
> }
>
> static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle)
>
>
>
Hey,
since we skipped the meeting this week, I propose we do make a joint
November-December meeting somewhere in the middle of December. (as we
did in the previous year too).
How about 18th of December?
Regards,
Aleksey Bragin
Honestly, I don't see any point in these modifications. The next time
someone wants to use these debug routines, he will need to add it back.
Or he will start using DPRINT stuff again. I'd prefer to have this in
all files!
Am 12.12.2014 14:23, schrieb akhaldi(a)svn.reactos.org:
> Author: akhaldi
> Date: Fri Dec 12 13:23:45 2014
> New Revision: 65617
>
> URL: http://svn.reactos.org/svn/reactos?rev=65617&view=rev
> Log:
> [USER32] We're not using any debugging routines here.
>
> Modified:
> trunk/reactos/win32ss/user/user32/misc/rtlstr.c
>
> Modified: trunk/reactos/win32ss/user/user32/misc/rtlstr.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/r…
> ==============================================================================
> --- trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] (original)
> +++ trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] Fri Dec 12 13:23:45 2014
> @@ -10,10 +10,6 @@
> /* INCLUDES ******************************************************************/
>
> #include <user32.h>
> -
> -#include <wine/debug.h>
> -
> -WINE_DEFAULT_DEBUG_CHANNEL(user32);
>
> /* FUNCTIONS *****************************************************************/
> VOID
>
>
>
Hi all,
Due to an OS upgrade on one of our VMs, the following services will
temporarily be down tomorrow (Monday):
* SVN
* BuildBot Buildmaster
* Git Mirror
* Secondary nameserver
* File server at svn.reactos.org
I'll try to get this done as fast as possible, so that the downtime will
be reduced to a minimum.
Sorry for the inconveniences!
Cheers,
Colin