Hi,
I just wanted to let everyone know that Wineconf 2009 is going to be
held in Holland on Nov 6-8th. I am of course planning on attending and
Fireball said that he might as well. If any ReactOS developers are
interested in going and don't have the resources, speak up and perhaps
some of the users and advocates that follow ReactOS development would
be willing to contribute $5 or $10 to the Foundation on your behalf.
Information (what little there is currently) is here:
http://wiki.winehq.org/WineConf2009
The ReactOS foundation Donation page is here
http://www.reactos.org/en/foundation_donate.html
Also while there has been some heated exchanges with Wine and ReactOS
developers in the past, we do get quite a lot in terms of code from
them so if your interested in helping them out, you can donate to the
Wine Development Fund, which will help pay for Wine developers to
attend. The donation link is on the main page of Winehq.org
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
as we earlier discussed, there is an idea to make 0.3.10 a "hardware-
compatibility" release.
There is a full list of 0.3.10 milestones bugs linked from our
roadmap page, but here are some possible directions for work:
- USB support for keyboard and mouse devices. Right now, it needs
fixing the rare crash during booting (bug is bugzilled, comment
explaining how to solve the problem is attached, some investigation
remains), and more testing on real hardware.
- Uniata support: it solves many problems at once, such as a stupid
8Gb limit which is a nonsense for a 2009-year operating system, and
Serial ATA support, which greatly enhances possible ReactOS usability
(along with the first item of this list). I use it in my builds
everyday for more than a month, it works very good. Problems:
VirtualBox CDROM support (it doesn't recognize it), on my
realhardware it also experiences similar problems. Bug is also
bugzilled, a lot of debug logs attached, so everyone can participate.
- Common NICs support: Cameron is doing great work, testers too.
There are some outstanding problems, which you can see from http://
www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards
- Sound support: Johannes knows best, but getting any progress with
sound by 0.3.10 release date is greatly appreciated.
- Videocards support: Olaf performs some tesitng and bugreporting.
Third party drivers support is rather weak, http://www.reactos.org/
wiki/index.php/Supported_Hardware/Video_cards , and usually is
limited by VMWare's video driver which is being one of the most
supported through the ReactOS development history.
Besides of that, Olaf is organizing the Golden Apps testing, so that
we won't discover regressions occasionally or by the time the release
is branched and everyone is awaiting, but instead that's going to
happen on a periodical basis, and he's going to manage this process
with help of our fellow testers.
Target 0.3.10 release date is month from now on - that means,
somewhere in the end of May. Certainly, if our goals aren't met, the
release is going to be rescheduled and that's it, but, I'd like to
ask to concentrate on the above problems first. They are hard to
solve when every problem is being approached by one person, but with
a common effort they aren't going to be a problem.
Any new developers - welcome! There are very definite goals, enough
of information, so please feel free to join and help.
With the best regards,
Aleksey Bragin.
Ok before you go on in this area, I am currently working on a complete
rewrite of sysparams stuff. It should hopefully be ready this week and
should fix almost all winetests and additional tests in this area.
Regards,
Timo
dchapyshev(a)svn.reactos.org schrieb:
> Author: dchapyshev
> Date: Mon May 25 17:08:57 2009
> New Revision: 41115
>
> URL: http://svn.reactos.org/svn/reactos?rev=41115&view=rev
> Log:
> - Stubimplement SPI_GETFONTSMOOTHINGTYPE/SPI_SETFONTSMOOTHINGTYPE
>
> Modified:
> trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
>
> Modified: trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
> ==============================================================================
> --- trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] Mon May 25 17:08:57 2009
> @@ -699,6 +699,22 @@
> {
> ASSERT(pvParam);
> *((BOOL*)pvParam) = IntIsFontRenderingEnabled();
> + break;
> + }
> + case SPI_SETFONTSMOOTHINGTYPE:
> + {
> + if (*((UINT*)pvParam) == FE_FONTSMOOTHINGCLEARTYPE)
> + {
> + DPRINT1("ReactOS does not support ClearType smoothing but it is returned TRUE\n");
> + }
> + bChanged = TRUE;
> + break;
> + }
> + case SPI_GETFONTSMOOTHINGTYPE:
> + {
> + /* We do not support ClearType. Only standard smoothing */
> + DPRINT1("ReactOS does not support ClearType smoothing. Returned FE_FONTSMOOTHINGSTANDARD\n");
> + *((UINT*)pvParam) = FE_FONTSMOOTHINGSTANDARD;
> break;
> }
> case SPI_GETICONTITLELOGFONT:
>
>
>
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;
> }
>
> /*
>
>