Hi..
I have had an idea which i want to share with you, so we can discuss if it is interesting or stupid enough.
Right now we have a Winetests comparator called TestMan thanks to the efforts of Colin and Lone_Rifle. This script compares the Winetest results of different revisions. It is really helpful to find regressions(Thanks Lone_rifle to be supervising them from time to time :) ).
My idea is about creating/adding a new script which compares the winetest results of a ReactOS revision vs the result of the WineHQ winetests.
Of course just in those functions/modules that we have full-synced with Wine.
Why?
Lets imagine that our Wininit:FTP functions are synced(as they are).That means that the code of those functions are the same in Wine and in ReactOS. That means that Bugs present in that code will be present in ReactOS too.These could be called the Expected bugs.ReactOS should fail in these tests since Wine functions are bugged: call them Expected Fails.
But sometimes ReactOS is showing more fails than the Expected Fails( in synced code).Why?
Well, these synced functions use other deeper functions which arent synced with Wine and which is own ReactOS code.And, of course,which can have Bugs.If these deeper functions arent working properlly then affects the synced functions which uses them and then you will see extra tests failing.
Lets give a small example.
Wininit:FTP is synced with Wine.
WineHQ reports 6 failures : http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_w…
ReactOS latest rev reports 19 failures: http://79.99.5.181/testman/detail.php?id=141321
These 13 extra failures arent expected.We expect just 6 Expected Fails (which seems to be related with Bugs in Wine code), so this 13 extra failures are related with deeper functions (which are ReactOS own code).
So the New Script would check the failures in WineHQ and in ReactOS rev and warn when the number of failures is higher than the number of Expected failures,showing also the differences, so the New Script can easily point our Devs towards ReactOS bugs, helping he "hunting" giving "clues" to them.
If my reasoning is wrong,or i am missing something,please tell me. :)
How much useful would be this Script?Is it interesting enough for Developing purposes?or Is it a waste of time/efforts?
Note: The ie is Bugzilled.It´s curious,since doing a small Timing trick you can have the 6 Expected Fails instead the 19 failures.
http://www.reactos.org/bugzilla/show_bug.cgi?id=4533
Vicmarcal
_________________________________________________________________
¡Acelera con la Fórmula 1! Juega y demuestra lo que sabes con MSN Deportes
http://msn.es.predictorpro.com/grand-prix/overview.aspx?season=8
Well mate, pity to hear that!
As you well know, one cannot simply leave this project! So everyone`s gonna
be glad to see you lurking around!
Best regards
Sorry for not replying to e-mails about this -- I was on vacation on a cruise.
When I'm back to Montreal I'll write a driver to test if this is
correct or not -- but definitely this is better.
Best regards,
Alex Ionescu
On Mon, May 25, 2009 at 1:17 AM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Mon May 25 03:17:48 2009
> New Revision: 41106
>
> URL: http://svn.reactos.org/svn/reactos?rev=41106&view=rev
> Log:
> MmGrowKernelStack: go back to the ASSERT and add a fixed check
>
> Modified:
> trunk/reactos/ntoskrnl/mm/procsup.c
>
> Modified: trunk/reactos/ntoskrnl/mm/procsup.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/procsup.c?rev=…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] Mon May 25 03:17:48 2009
> @@ -258,11 +258,15 @@
> {
> PETHREAD Thread = PsGetCurrentThread();
>
> - /* Make sure we have reserved space for our grow */
> - if (((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) >
> - (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE))
> - {
> - return STATUS_NO_MEMORY;
> + /* Make sure the stack did not overflow */
> + ASSERT(((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) <=
> + (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE));
> +
> + /* Check if we have reserved space for our grow */
> + if ((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit +
> + KERNEL_STACK_SIZE > KERNEL_LARGE_STACK_SIZE)
> + {
> + return STATUS_STACK_OVERFLOW;
> }
>
> /*
>
>
May I ask, why not use simple C for this?:
DriverBlock->DriverObject->MajorFunction = MajorFunctions;
Or if that doesn't work, use a casting trick...
Best regards,
Alex Ionescu
On Sun, May 24, 2009 at 2:49 AM, <cgutman(a)svn.reactos.org> wrote:
> Author: cgutman
> Date: Sun May 24 04:49:02 2009
> New Revision: 41090
>
> URL: http://svn.reactos.org/svn/reactos?rev=41090&view=rev
> Log:
> - MajorFunction has IRP_MJ_MAXIMUM_FUNCTION positions
> - Sorry for so many commits on the same function
>
> Modified:
> trunk/reactos/drivers/network/ndis/ndis/miniport.c
>
> Modified: trunk/reactos/drivers/network/ndis/ndis/miniport.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] Sun May 24 04:49:02 2009
> @@ -2788,7 +2788,7 @@
> return NDIS_STATUS_RESOURCES;
> }
>
> - for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++)
> + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
> DriverBlock->DriverObject->MajorFunction[i] = MajorFunctions[i];
>
> DriverBlock->DriverObject->MajorFunction[IRP_MJ_PNP] = NdisIDispatchPnp;
>
>
What is the reason we don't sync wine's secur32?
Thanks,
Timo
cwittich(a)svn.reactos.org schrieb:
> Author: cwittich
> Date: Sun May 24 13:40:15 2009
> New Revision: 41096
>
> URL: http://svn.reactos.org/svn/reactos?rev=41096&view=rev
> Log:
> fix secur32 main winetest crash by returning 0 packages in EmumSecurityPackagesA/W
>
> Modified:
> trunk/reactos/dll/win32/secur32/sspi.c
>
>
Hi,
This mail is a little bit late as I didn't find time to write it earlier.
Basically, I've decided that I do not want to continue working on
ReactOS. I just don't find it "fun" or interesting to do any more.
I spent months trying to get my head around Kernel Streaming and its
associated components, how they fit together let alone how they actually
function. And really, it's not enjoyable. I don't fully understand
Windows kernel-mode coding, and coding the sound system really isn't as
straightforward a task as I had originally anticipated. It has become
more of a chore over time.
Considering I made the switch from Windows to Linux around 2005 and have
rarely actually needed to use Windows at home since then, there doesn't
seem to be any benefit for me to put my time into working on ReactOS.
Also I never really seemed to get very far with sound... I see
Janderwald has taken up the challenge on this and is making good
progress on it.
I had been considering leaving a few months ago, but stuck around for
our gathering in Brussels, which was great (aside from the restaurant
which seemed like it was going to cook its customers, and the
overly-smiley waiter who didn't fully explain what "special sauce"
contained...) To be honest I think putting the hybrid CD together for
that to be my best and also most hacky achievement for ReactOS. Starflow
produced all the fliers/badges/etc. and I think altogether, FOSDEM was a
success. And I hope it sparked interest for other people to join the
project.
I intend on working on some of my own projects from this point on
(possibly audio related still...)
All the best for the future,
Andrew Greenwood
I have the code to complete this functionality locally, I just haven't committed it yet as it's not tested.
Thanks for the conflict :-P
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org
Sent: 22 May 2009 23:18
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [tkreuzer] 41046: #if out an unused static funtion. Don't know if it's still useful. Ged?
Author: tkreuzer
Date: Sat May 23 02:17:55 2009
New Revision: 41046
URL: http://svn.reactos.org/svn/reactos?rev=41046&view=rev
Log:
#if out an unused static funtion. Don't know if it's still useful. Ged?
Modified:
branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c
Modified: branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c
URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/base/…
==============================================================================
--- branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c [iso-8859-1] (original)
+++ branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c [iso-8859-1] Sat May 23 02:17:55 2009
@@ -50,6 +50,7 @@
return TreeView_InsertItem(hTreeView, &tvins);
}
+#if 0 // FIXME: What is this good for?
static VOID
AddServiceDependency(PSERVICEPROPSHEET dlgInfo,
HWND hTreeView,
@@ -123,6 +124,7 @@
}
}
+#endif
static VOID
AddServiceDependent(HWND hTreeView,