And, you have, of course, confirmed that this piece of kernel code is wrong,
and that DevMgr/Cfgapi/SetupApi are doing the right thing, right?
So if I was to reverse engineer ntoskrnl I wouldn't discover that it was
actually doing the same thing as the un-"fixed" code, right?
Best regards,
Alex Ionescu
On Sun, Aug 14, 2011 at 10:44 AM, <cgutman(a)svn.reactos.org> wrote:
> Author: cgutman
> Date: Sun Aug 14 14:44:34 2011
> New Revision: 53232
>
> URL: http://svn.reactos.org/svn/reactos?rev=53232&view=rev
> Log:
> [NTOSKRNL]
> - Fix NULL termination of strings in IoGetDeviceProperty
> - Fixes garbage displayed in the Enumerator field of the device manager
> property page
>
> Modified:
> trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c
>
> Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] Sun Aug 14
> 14:44:34 2011
> @@ -3467,6 +3467,8 @@
> NTSTATUS Status = STATUS_BUFFER_TOO_SMALL;
> GUID BusTypeGuid;
> POBJECT_NAME_INFORMATION ObjectNameInfo = NULL;
> + BOOLEAN NullTerminate = FALSE;
> +
> DPRINT("IoGetDeviceProperty(0x%p %d)\n", DeviceObject, DeviceProperty);
>
> /* Assume failure */
> @@ -3517,7 +3519,10 @@
> /* Get the name from the path */
> EnumeratorNameEnd = wcschr(DeviceInstanceName,
> OBJ_NAME_PATH_SEPARATOR);
> ASSERT(EnumeratorNameEnd);
> -
> +
> + /* This string needs to be NULL-terminated */
> + NullTerminate = TRUE;
> +
> /* This is the format of the returned data */
> PIP_RETURN_DATA((EnumeratorNameEnd - DeviceInstanceName) *
> sizeof(WCHAR),
> DeviceInstanceName);
> @@ -3567,7 +3572,10 @@
> /* It's up to the caller to try again */
> Status = STATUS_BUFFER_TOO_SMALL;
> }
> -
> +
> + /* This string needs to be NULL-terminated */
> + NullTerminate = TRUE;
> +
> /* Return if successful */
> if (NT_SUCCESS(Status))
> PIP_RETURN_DATA(ObjectNameInfo->Name.Length,
>
> ObjectNameInfo->Name.Buffer);
> @@ -3633,15 +3641,14 @@
> else if (NT_SUCCESS(Status))
> {
> /* We know up-front how much data to expect, check the caller's
> buffer */
> - *ResultLength = ReturnLength;
> - if (ReturnLength <= BufferLength)
> + *ResultLength = ReturnLength + (NullTerminate ?
> sizeof(UNICODE_NULL) : 0);
> + if (*ResultLength <= BufferLength)
> {
> /* Buffer is all good, copy the data */
> RtlCopyMemory(PropertyBuffer, Data, ReturnLength);
>
> - /* Check for properties that require a null-terminated string
> */
> - if ((DeviceProperty == DevicePropertyEnumeratorName) ||
> - (DeviceProperty ==
> DevicePropertyPhysicalDeviceObjectName))
> + /* Check if we need to NULL-terminate the string */
> + if (NullTerminate)
> {
> /* Terminate the string */
> ((PWCHAR)PropertyBuffer)[ReturnLength / sizeof(WCHAR)] =
> UNICODE_NULL;
>
>
>
Never depend on this!
Depending on funcs.h including types.h of the same module is fine, but you
should not depend on rtlfuncs dependong on pstypes.
Best regards,
Alex Ionescu
On Sun, Aug 14, 2011 at 8:57 AM, <akhaldi(a)svn.reactos.org> wrote:
> #define NTOS_MODE_USER
> -#include <ndk/pstypes.h>
> #include <ndk/rtlfuncs.h>
>
Maybe you could add all the other changes with checkin comments such
as "this should be sent upstream to wine" to that plan too :)
That practice has become quite common these days.
Ged.
Sent from my Windows Phone From: Jérôme Gardou
Sent: 09 August 2011 22:32
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore
lost ros specific change. Thanks Vic.
Don't worry, it's part of the plan!
Le 09/08/2011 23:29, Ged Murphy a écrit :
> Call me nuts, but why don't you add a ros_diff patch so it doesn't get
> lost again???
> From: jgardou(a)svn.reactos.org
> Sent: 09 August 2011 18:43
> To: ros-diffs(a)reactos.org
> Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros
> specific change. Thanks Vic.
> Author: jgardou
> Date: Tue Aug 9 17:43:37 2011
> New Revision: 53152
>
> URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev
> Log:
> [RPCRT4]
> - restore lost ros specific change.
> Thanks Vic.
>
> Modified:
> trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
>
> Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh…
> ==============================================================================
> --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug
> 9 17:43:37 2011
> @@ -6159,6 +6159,7 @@
> case RPC_FC_WCHAR:
> case RPC_FC_SHORT:
> case RPC_FC_USHORT:
> + case RPC_FC_ENUM16:
> {
> USHORT d;
> align_pointer(&pStubMsg->Buffer, sizeof(USHORT));
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Call me nuts, but why don't you add a ros_diff patch so it doesn't get
lost again???
From: jgardou(a)svn.reactos.org
Sent: 09 August 2011 18:43
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros
specific change. Thanks Vic.
Author: jgardou
Date: Tue Aug 9 17:43:37 2011
New Revision: 53152
URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev
Log:
[RPCRT4]
- restore lost ros specific change.
Thanks Vic.
Modified:
trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh…
==============================================================================
--- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug
9 17:43:37 2011
@@ -6159,6 +6159,7 @@
case RPC_FC_WCHAR:
case RPC_FC_SHORT:
case RPC_FC_USHORT:
+ case RPC_FC_ENUM16:
{
USHORT d;
align_pointer(&pStubMsg->Buffer, sizeof(USHORT));
Hello everybody,
Due to a mistake from my side, the uploaded BuildBot 7zipped ISO files
in the revision range from 53120 to 53127 as created by the Debug
Buildslave contained the very same ISO of revision 53119. This has been
fixed in the meantime, the faulty files have been removed from the
server and at least the 7-Zip archive of revision 53127 has been recreated.
On the other hand, Olaf and I have finally enabled his server to upload
ISOs to http://iso.reactos.org. These ISOs are built by his Buildslave
running under Windows, already using the new CMake buildsystem and
incorporating our regression tests and the Gecko CAB file.
I might have time to add another filter to http://reactos.org/getbuilds
soon, so that everybody can download the new ISOs easily.
- Colin
Am 05.08.2011 21:35, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Fri Aug 5 19:35:54 2011
> New Revision: 53087
>
> URL: http://svn.reactos.org/svn/reactos?rev=53087&view=rev
> Log:
> [PSDK]
> - do not redefine UNICODE_STRING and NTSTATUS if wintrnl.h has already been included
...
> -#if !defined(_NTDEF_)
> +#if !defined(_NTDEF_)&& !defined(__WINE_WINTERNL_H)
> typedef LONG NTSTATUS, *PNTSTATUS;
> #endif
Thats disgusting!
Why do we need this? I hate hacking headers because of crap elsewhere.
Regards,
Timo