That's a bit** of a hack. Either the code holds a reference and needs to release it or not. cLockObj is a private field and code outside of UserReference* should not be allowed to access it.
Thanks!
-Thomas
** actually it's a pretty big hack
On May 28, 2015 12:13:03 AM CEST, jimtabor(a)svn.reactos.org wrote:
>Author: jimtabor
>Date: Wed May 27 22:13:03 2015
>New Revision: 67937
>
>URL: http://svn.reactos.org/svn/reactos?rev=67937&view=rev
>Log:
>[NtUser]
>- De-reference global cursor. See CORE-8305.
>
>Modified:
> trunk/reactos/win32ss/user/ntuser/cursoricon.c
>
>Modified: trunk/reactos/win32ss/user/ntuser/cursoricon.c
>URL:
>http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/cursor…
>==============================================================================
>--- trunk/reactos/win32ss/user/ntuser/cursoricon.c [iso-8859-1]
>(original)
>+++ trunk/reactos/win32ss/user/ntuser/cursoricon.c [iso-8859-1] Wed May
>27 22:13:03 2015
>@@ -1077,6 +1077,12 @@
> if (pcurOld->CURSORF_flags & CURSORF_GLOBAL)
> {
> TRACE("Returning Global Cursor hcur %p\n",hOldCursor);
>+
>+ if (pcurOld->head.cLockObj > 2) // Throttle down to 2.
>+ {
>+ UserDereferenceObject(pcurOld);
>+ }
>+
> goto leave;
> }
>
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Hello,
Let me invite you to the monthly status meeting taking place 28th of
May, 19:00 UTC, as always.
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.
Please send agenda proposals to me before the meeting, so that we can
start with a proposed agenda.
Regards,
Aleksey Bragin
Hi guys!
After a week dealing with several scripts and options, we're finally integrating the most important info from Reactos.org and Community.reactos.org directly to our Social channels to keep a constant flow of updates to our followers.
Since now our ReactOS Facebook and ReactOS Twitter will be automatically updated when...
... A Jira bugreport is resolved with a 'Fixed' and 'Cannot reproduce' status.
... A blog post is published in "ReactOS.org"
... A blog post is published in "Community.ReactOS.org"
Some of the features:
- Updates are queued and published with a time gap between them, so in case, eg, a Tester/Dev runs a Spring Cleanup, we won't be publishing 10 Jira reports in the same minute.
- Facebook and Twitter updates include pictures in case the blog post or the Jira report has one. So please add a picture in case you're blogging even if it is just a screenshot of you running "whatever" in ReactOS.
- Includes #hashtags related to the current Jira/Blog report.
- Uses bit.ly shortener when needed.
- And several hidden Easter Eggs in Twitter...(I was bored in the train)
If you've any suggestions about other potential updates to be sent to our Social Channels, just tell me and I'd try to integrate them in an automated way.
I'm planning a way to ease and have community contributions filtered and joining the automated flow, but it'll have to wait until I master Drupal. Also I'm working in some "crossposting" among our Social Channels, so a direct post in Facebook not coming from our PR Update System is replicated in Twitter and the other way around.
We can be really proud of the current PR Update system implemented, since probably it even beats several bigger opensource projects and/or companies out there.
If you didn't join our Twitter or Facebook yet, please feel free to join:
- Facebook: https://www.facebook.com/pages/ReactOS/19143619259
- Twitter: http://www.twitter.com/reactos
Brought to you by the ReactOS PR Team.
On 2015-05-14 06:00, tkreuzer(a)svn.reactos.org wrote:
> - int sign = (copysignf(1, in) < 0);
> + int sign = (in < 0);
> - if (copysignf(1.0f, value) < 0.0f)
> + if (value < 0.0f)
> ++idx;
I believe the behavior would be different here for negative zero:
copysignf(1.0f, -0.0f) should be < 0.0f
-0.0f should be == 0.0f
Maybe that's the reason for having these calls?
On 2015-05-12 06:57, akhaldi(a)svn.reactos.org wrote:
> +/* FIXME: ntifs.h */
> +#define FILE_READ_ONLY_VOLUME 0x00080000
This should go in ndk/iotypes.h inside an NTOS_MODE_USER ifdef.
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
Manually uploaded.
On 10/05/2015 19:28, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS.
> Full details are available at:
> https://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/1177
>
> Buildbot URL: https://build.reactos.org/
>
> Buildslave for this Build: Debug
>
> Build Reason: The Periodic scheduler named 'Release' triggered this build
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed shell
>
> sincerely,
> -The Buildbot
>
>
>
>
>
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.