Interesting that the wine code doesn't check for NULL at HeapAlloc at all
- could these be submitted to wine?
Additionally, at least one HeapAlloc isn't checked also in our build:
piDx = HeapAlloc(GetProcessHeap(),0,sizeof(INT) * (*count));
Perhaps a
#ifdef __REACTOS__
if (piDx == NULL)
{
return FALSE; //Not sure about this, just looked at the diff ;)
}
#endif
would be usefull there.
Best regards,
Michael Fritscher
> Author: akhaldi
> Date: Sat May 30 17:14:16 2015
> New Revision: 67974
>
> URL: http://svn.reactos.org/svn/reactos?rev=67974&view=rev
> Log:
> [USER32] Sync edit.c with Wine Staging 1.7.37. CORE-9246
>
> Modified:
> trunk/reactos/media/doc/README.WINE
> trunk/reactos/win32ss/user/user32/controls/edit.c
>
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.
Whats the difference between DPRINT and DbgPrint? I wrote a little
program that I can use to observe pipes, which I use for debugging. The
text from DPRINT is there, but where does DbgPrint go and why are there
multiple different debugging aids?
Well this is a weird one, the DDK says these callbacks are cdecl (missing NTAPI) and anyone building against the DDK will obviously declare their callbacks to match this convention. However internally, windows uses stdcall for these callbacks.
I can't find much by way of problems people have encountered with this, so why aren't people seeing problems with the way the stack is cleaned up? Anyone have any ideas before I blindly revert this change?
Ged.
-----Original Message-----
From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of gedmurphy(a)svn.reactos.org
Sent: 05 May 2015 19:54
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions
Author: gedmurphy
Date: Tue May 5 18:54:28 2015
New Revision: 67563
URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
Log:
[DDK]
Fix the FS filter callback definitions
Modified:
trunk/reactos/include/ddk/ntifs.h
Modified: trunk/reactos/include/ddk/ntifs.h
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=67…
==============================================================================
--- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original)
+++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Tue May 5 18:54:28 2015
@@ -4890,12 +4890,12 @@
} FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
typedef NTSTATUS
-(NTAPI *PFS_FILTER_CALLBACK) (
+(*PFS_FILTER_CALLBACK) (
_In_ PFS_FILTER_CALLBACK_DATA Data,
_Out_ PVOID *CompletionContext);
typedef VOID
-(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
+(*PFS_FILTER_COMPLETION_CALLBACK) (
_In_ PFS_FILTER_CALLBACK_DATA Data,
_In_ NTSTATUS OperationStatus,
_In_ PVOID CompletionContext);
Hi
I'm new to ReactOS development and started to look into some issues I
noticed with the setup. When I tried to install it I experimented a bit
and noticed that you can create extended partitions during the setup.
The setup also accepts such a partition for installation, but the actual
installations fails with an error.
Now I wondered, what would be the correct way to fix it. I checked with
Windows 7 installation, and it apparently doesn't allow you to install
on an extended partition either, at least it only allows you to create
primary partitions. So if this shouldn't be possible, then I would add
an error message to the setup, when the user chooses an extended partition.
If this should be possible though, I would look into it, why it fails
and try to fix it. Not sure if XP or others allow installations on
extended partitions, I have to check this (been a long time since I last
installed an XP :) ).
regards,
Gerhard Gruber
On 02/05/2015 12:15, akhaldi(a)svn.reactos.org wrote:
> Author: akhaldi
> Date: Sat May 2 10:15:37 2015
> New Revision: 67508
>
> URL: http://svn.reactos.org/svn/reactos?rev=67508&view=rev
> Log:
> [PARPORT] Introduce a skeleton that will serve as base for implementing the parallel port function driver. Brought to you by The ReactOS Printing Group. CORE-9644
Is there a need for that much secrecy?
I shall remind that we ask people to contribute with their real names.
Such secret looks useless and damaging for the project.
And no, ARM group isn't a good example, nor a reason to keep doing so.
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
As already announced at the meeting today, I'm planning the very first
"ReactOS Hackfest" this year. Let's all finally meet up independently of
an exhibition and do some great work on ReactOS for a week!
The first idea was to have it at a location in Sweden, but this one
turned out to be not ready yet. Anyway, I found a possibility to have it
in the university city of Aachen, Germany.
Before we can plan any further regarding travelling and accomodation, I
need to know who's coming and when. So please fill out this Doodle:
http://doodle.com/tdaaie3rbbs5phpb
Cheers,
Colin
Hello,
Let me invite you to the monthly status meeting taking place 30th of
April, 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.
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
On 22/04/2015 05:10, aandrejevic(a)svn.reactos.org wrote:
> +static inline PXMS_HANDLE GetHandleRecord(WORD Handle)
> +{
> + PXMS_HANDLE Entry = &HandleTable[Handle - 1];
> + if (Handle == 0 || Handle >= XMS_MAX_HANDLES) return NULL;
> +
> + return Entry->Size ? Entry : NULL;
> +}
This looks highly dangerous to me and likely compiler dependent.
I'd rather perform the sanity checks before ever touching HandleTable,
especially because the value of Handle is coming right from caller
registers and have never been sanitized before.
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.