LwIP is in the final stage of testing, pending one bug fix before all known bugs are fixed. I would greatly appreciate everyone to try it and reply to this email with the results of your tests. I've already tried many apps including telnetd, chargen, and abyss web server, samba tng, and Opera 9.6. During my testing, the lwIP implementation performed flawlessly. It handled several chargen sessions while serving web pages and servicing open telnet sessions plus being probed by nmap. The only thing that finally killed the server was a pool leak that caused a win32k assert failure. I also ran a BitTorrent download and it peaked at 2.3 MB/s down. Web browsing is an absolute pleasure on lwIP. It really feels like I'm browsing on the host system directly. There are no more stutters like oskit had. I'd encourage everyone to try it. It's surprising how well it works especially since I thought oskit was fairly good. My testing on lwIP has been perfect and I hope everyone else has a similar experience. Please only report bugs that don't also happen with oskit. Happy testing!
LwIP ISO Link: http://www.mediafire.com/?d6j4qwz8vgabj9i
Thanks in advance,
Cameron
LinkedIn
------------
Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn.
-dimas
dimas francisco
Profissional de Serviços da informação
São Paulo e redondezas, Brasil
Confirme que você conhece dimas francisco
https://www.linkedin.com/e/-w5xu2x-gre1loc3-34/isd/3867275872/u_LdDFjC/
--
(c) 2011, LinkedIn Corporation
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