Ros-dev September 2010

ros-dev@reactos.org

30 participants
31 discussions

0.3.12 milestones status
by victor martinez 11 Oct '10

11 Oct '10

I am currently checking our 0.3.12 milestones. And the milestones status is: **********(Bug 5517)Some icons look wrong (blue background)********** There is a Hack for the release. **********(Bug5560): Adobe Acrobat Reader 7.1 throws exception at start**** This is a Wine regression. It is not in our hands.We have to wait for a Fix. **********(Bug 5472) comctl32: Keyboard shortcuts don't work after winesync*** Not as bad as it sounds. It does not work just in 2nd Installation Stage. Anyway, there is a Hack for this issue too. **********(Bug 5314) REGRESSION: Acrobat Reader: pen leak******* It is supposed to be fixed, but it is Bug5560 dependant so it is impossible to confirm the Fixed status. **********(Bug 5598) PATCH: Opera 9.64, FireFox 3.0+ crash when using Russian/Lithuanin/Ukrainian locale**** Reverting the *.nls changes solves the issue. There is a Hack attached. **********(Bug 5482)REGRESSION: ExplorerXP: black background on treeview area***** This is a Wine regression. It is not in our hands. We have to wait for a Fix. **********(Bug 4106) REGRESSION: Wrong text spacing in popup menus / icons after show a font in control applet / Remote Desktop******* It is a minor regression since it has been there for a while. Also Yarotows seems to fix some of the issues. **********(Bug 5591) REGRESSION: devmgr: wrong icons in the TreeView ***** Updating comctl32 will fix the issues. Or we can revert the comctl32 changes. ************** * Summing up * ************** There are 8 regressions. 4 has different options to be solved (Hack or Wine update/revert) 2 are current Wine regressions (we have to wait for a fix or revert Ole32/Comctl32 changes) 1 could be fixed (the Acrobar Reader leakage) but we need to fix Acrobat first(reverting?) 1 is a minor regression without a solution ( "Bug 4106") So we can solve 7/8 regressions. Is it time to think about a 0.3.12 release? It is time to take decisions (reverting/updating/waiting Fixes) since there are solutions. I don't think having the Trunk frozen is good for the project. So, opinions?

8 15

Re: [ros-dev] [ros-diffs] [sir_richard] 48940: [NTOS]: He's climbing in yo PFN database, he snatching yo pages up, tryin to page em so y'all need to hide your pool hide your cache, and hide your working set cuz they grabbin...
by Ged Murphy 30 Sep '10

30 Sep '10

This commit needs a 'like' button :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sir_richard(a)svn.reactos.org Sent: 30 September 2010 05:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sir_richard] 48940: [NTOS]: He's climbing in yo PFN database, he snatching yo pages up, tryin to page em so y'all need to hide your pool hide your cache, and hide your working set cuz they grabbin... Author: sir_richard Date: Thu Sep 30 04:40:31 2010 New Revision: 48940 URL: http://svn.reactos.org/svn/reactos?rev=48940&view=rev Log: [NTOS]: He's climbing in yo PFN database, he snatching yo pages up, tryin to page em so y'all need to hide your pool hide your cache, and hide your working set cuz they grabbin' all the pages out there. We gonna page you, we gonna page you, so you can run and fault on that, run and fault on that, home boy, homeboy, home homeboy. Enable ARM3 Paged Pool and remove all related deprecated code. Install tested on several VMs, it might cause new regressions. Let's fix them before 0.3.13 instead of reverting. Modified: trunk/reactos/ntoskrnl/ex/init.c trunk/reactos/ntoskrnl/mm/ARM3/expool.c trunk/reactos/ntoskrnl/mm/mmfault.c trunk/reactos/ntoskrnl/mm/mminit.c trunk/reactos/ntoskrnl/mm/ppool.c Modified: trunk/reactos/ntoskrnl/ex/init.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=489… ============================================================================== --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Thu Sep 30 04:40:31 2010 @@ -1270,8 +1270,6 @@ SharedUserData->ImageNumberHigh = IMAGE_FILE_MACHINE_ARCHITECTURE; } -extern BOOLEAN AllowPagedPool; - VOID NTAPI Phase1InitializationDiscard(IN PVOID Context) @@ -1891,9 +1889,6 @@ /* Update progress bar */ InbvUpdateProgressBar(90); - /* Enough fun for now */ - AllowPagedPool = FALSE; - /* Launch initial process */ ProcessInfo = &InitBuffer->ProcessInfo; ExpLoadInitialProcess(InitBuffer, &ProcessParameters, &Environment); Modified: trunk/reactos/ntoskrnl/mm/ARM3/expool.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/expool.c?… ============================================================================== --- trunk/reactos/ntoskrnl/mm/ARM3/expool.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/ARM3/expool.c [iso-8859-1] Thu Sep 30 04:40:31 2010 @@ -19,8 +19,6 @@ #undef ExAllocatePoolWithQuota #undef ExAllocatePoolWithQuotaTag -BOOLEAN AllowPagedPool = TRUE; - /* GLOBALS ********************************************************************/ ULONG ExpNumberOfPagedPools; @@ -454,11 +452,6 @@ PPOOL_HEADER Entry, NextEntry, FragmentEntry; KIRQL OldIrql; ULONG BlockSize, i; - - // - // Check for paged pool - // - if (!(AllowPagedPool) && (PoolType == PagedPool)) return ExAllocatePagedPoolWithTag(PagedPool, NumberOfBytes, Tag); // // Some sanity checks @@ -761,19 +754,6 @@ BOOLEAN Combined = FALSE; // - // Check for paged pool - // - if ((P >= MmPagedPoolBase) && - (P <= (PVOID)((ULONG_PTR)MmPagedPoolBase + MmPagedPoolSize))) - { - // - // Use old allocator - // - ExFreePagedPool(P); - return; - } - - // // Quickly deal with big page allocations // if (PAGE_ALIGN(P) == P) Modified: trunk/reactos/ntoskrnl/mm/mmfault.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/mmfault.c?rev=… ============================================================================== --- trunk/reactos/ntoskrnl/mm/mmfault.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/mmfault.c [iso-8859-1] Thu Sep 30 04:40:31 2010 @@ -105,10 +105,6 @@ switch (MemoryArea->Type) { - case MEMORY_AREA_PAGED_POOL: - Status = STATUS_SUCCESS; - break; - case MEMORY_AREA_SECTION_VIEW: Status = MmAccessFaultSectionView(AddressSpace, MemoryArea, @@ -196,12 +192,6 @@ switch (MemoryArea->Type) { - case MEMORY_AREA_PAGED_POOL: - { - Status = MmCommitPagedPoolAddress((PVOID)Address, Locked); - break; - } - case MEMORY_AREA_SECTION_VIEW: Status = MmNotPresentFaultSectionView(AddressSpace, MemoryArea, @@ -293,25 +283,3 @@ } } -NTSTATUS -NTAPI -MmCommitPagedPoolAddress(PVOID Address, BOOLEAN Locked) -{ - NTSTATUS Status; - PFN_NUMBER AllocatedPage; - - Status = MmRequestPageMemoryConsumer(MC_PPOOL, FALSE, &AllocatedPage); - if (!NT_SUCCESS(Status)) - { - MmUnlockAddressSpace(MmGetKernelAddressSpace()); - Status = MmRequestPageMemoryConsumer(MC_PPOOL, TRUE, &AllocatedPage); - MmLockAddressSpace(MmGetKernelAddressSpace()); - } - Status = - MmCreateVirtualMapping(NULL, - (PVOID)PAGE_ROUND_DOWN(Address), - PAGE_READWRITE, - &AllocatedPage, - 1); - return(Status); -} Modified: trunk/reactos/ntoskrnl/mm/mminit.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/mminit.c?rev=4… ============================================================================== --- trunk/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] Thu Sep 30 04:40:31 2010 @@ -199,21 +199,6 @@ ASSERT(Status == STATUS_SUCCESS); // - // And now, ReactOS paged pool - // - BaseAddress = MmPagedPoolBase; - Status = MmCreateMemoryArea(MmGetKernelAddressSpace(), - MEMORY_AREA_PAGED_POOL | MEMORY_AREA_STATIC, - &BaseAddress, - MmPagedPoolSize, - PAGE_READWRITE, - &MArea, - TRUE, - 0, - BoundaryAddressMultiple); - ASSERT(Status == STATUS_SUCCESS); - - // // Next, the KPCR // BaseAddress = (PVOID)PCR; @@ -287,10 +272,6 @@ MmSystemRangeStart, (ULONG_PTR)MmSystemRangeStart + MmBootImageSize, "Boot Loaded Image"); - DPRINT1(" 0x%p - 0x%p\t%s\n", - MmPagedPoolBase, - (ULONG_PTR)MmPagedPoolBase + MmPagedPoolSize, - "Paged Pool"); DPRINT1(" 0x%p - 0x%p\t%s\n", MmPfnDatabase, (ULONG_PTR)MmPfnDatabase + (MxPfnAllocation << PAGE_SHIFT), @@ -373,12 +354,7 @@ /* Initialize ARMÂ³ in phase 0 */ MmArmInitSystem(0, KeLoaderBlock); - - /* Put the paged pool after the loaded modules */ - MmPagedPoolBase = (PVOID)PAGE_ROUND_UP((ULONG_PTR)MmSystemRangeStart + - MmBootImageSize); - MmPagedPoolSize = MM_PAGED_POOL_SIZE; - + /* Intialize system memory areas */ MiInitSystemMemoryAreas(); @@ -387,7 +363,6 @@ } else if (Phase == 1) { - MmInitializePagedPool(); MiInitializeUserPfnBitmap(); MmInitializeMemoryConsumer(MC_USER, MmTrimUserMemory); MmInitializeRmapList(); Modified: trunk/reactos/ntoskrnl/mm/ppool.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ppool.c?rev=48… ============================================================================== --- trunk/reactos/ntoskrnl/mm/ppool.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/ppool.c [iso-8859-1] Thu Sep 30 04:40:31 2010 @@ -13,10 +13,6 @@ #include <ntoskrnl.h> #define NDEBUG #include <debug.h> - -#if defined (ALLOC_PRAGMA) -#pragma alloc_text(INIT, MmInitializePagedPool) -#endif #undef ASSERT #define ASSERT(x) if (!(x)) {DbgPrint("Assertion "#x" failed at %s:%d\n", __FILE__,__LINE__); DbgBreakPoint(); } @@ -967,26 +963,6 @@ R_RELEASE_MUTEX(pool); } -VOID -INIT_FUNCTION -NTAPI -MmInitializePagedPool(VOID) -{ - /* - * We are still at a high IRQL level at this point so explicitly commit - * the first page of the paged pool before writing the first block header. - */ - MmCommitPagedPoolAddress ( (PVOID)MmPagedPoolBase, FALSE ); - - MmPagedPool = RPoolInit ( MmPagedPoolBase, - MmPagedPoolSize, - MM_POOL_ALIGNMENT, - MM_CACHE_LINE_SIZE, - PAGE_SIZE ); - - ExInitializeFastMutex(&MmPagedPool->Mutex); -} - PVOID NTAPI ExAllocatePagedPoolWithTag (IN POOL_TYPE PoolType, IN ULONG NumberOfBytes,

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 48825: [MISC]: Fix several compiler issues on my main build box. Some of the Unicode translations in kernel32 fail to compile, while other libraries don't build because old C library ...
by Timo Kreuzer 28 Sep '10

28 Sep '10

sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Mon Sep 20 06:30:21 2010 > New Revision: 48825 > > > +  > + <define name="lseek">_lseek</define> > + <define name="read">_read</define> > + <define name="strdup">_strdup</define> > What's not "proper" with our oldnames library?

4 3

HTTP/WebDAV access for the Git mirror
by Colin Finck 26 Sep '10

26 Sep '10

Hello everybody, Just to let you know, I've just added HTTP/WebDAV access for our read-only Git mirror as requested by a developer. This means that you can also clone from http://git.reactos.org/reactos.git now if you sit behind a firewall blocking the Git protocol. Of course, the previous URL git://git.reactos.org/reactos.git will continue to work. Best regards, Colin

2 2

platform dependent configuration files
by Matthias Kupfer 26 Sep '10

26 Sep '10

HI, recently I had to alter some inf-files for fixing a bug. At present we have for each platform (i386, arm, amd64) separate files, which are hard to maintain because of some identical, that aren't platform dependent. Therefore I suggest the following change and I will write an example and the necessary tool: - combine all platforms to one file and work with special block markers - block markers work like filters, empty markers means all platforms otherwise the platforms limited to are given in comma separated lists - we have to maintain only one single file and the alteration is minimal, because the marker is a simple (syntactically comment) line like ";#platform_a,platform_b#" or ";##" - the needed file is extracted at build time, always up-to-date and shipped in the same way as present General remark: we have to make some efforts to bring (or at least to keep) the project in understandable and maintanable state. We have to use and introduce tools to reduce needless efforts resulted by managing multiple similar files which could be better generated without failures (that people tends to do). This and only this is my intention for this suggestion. Request for comments - other ways or changes with same goal are welcome Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

2 1

OpenSource World Conference-Malaga(Spain)
by victor martinez 24 Sep '10

24 Sep '10

Hi guys/devs/testers/translators/followers ! I have just received this information from the OSWC organization: "Nos complace comunicarle que su propuesta presentada al Call for Paper ha sido aprobada de forma preliminar por el Comité de Ponencias de la Conferencia Internacional de Software Libre para su comunicación pública. Actualmente el programa de la Conferencia se encuentra en una fase temprana de elaboración, por ello solicitamos de usted nos comunique antes del próximo día 28 de septiembre de 2010, su disponibilidad para estar en Málaga tanto el día 27 de octubre, el 28 o ambos. Agradecemos su dedicación e interés y esperamos disfrutar de su compañía en Málaga Atentamente " You can use Google translator. Or summing up: "We are IN" Thanks to anyone who has voted and wish me good luck :) If anyone is interested about coming, please contact me before 28 September (there is one day just for professionals and closed to the general public) :) Victor Martinez "

2 2

Re: [ros-dev] 0.3.12 milestones status
by victor martinez 23 Sep '10

23 Sep '10

> From: gedmurphy(a)gmail.com > To: ros-dev(a)reactos.org > Date: Thu, 23 Sep 2010 08:09:57 +0100 > Subject: Re: [ros-dev] 0.3.12 milestones status > > victor Martinez wrote: > > > In the same way, and imho, I think it is much better > > to avoid sending critical code one month before the release. > > This isn't how you release. > The whole point in branching for a release is so you can stabalise the > branch whilst trunk continues to be 'bleeding edge' > What's the point in branching otherwise? We may as well just tag trunk and > do away with branching. I am not agree :) As far as i see we have tried to (more or less)stabilize trunk before branching at least in the 2 latest releases. An i.e is the 0.3.12 release, if we are following the "bleeding edge" concept then we should have branched several months ago and just pulled the regression fixes from trunk to the branch. Our approach was different: Stabilizing trunk fixing the known regressions (which,btw,were marked as Milestones) and then branching. There is not an incompatibility with the "stabilizing trunk" and "branching" concepts. First because exists the "Hack-releases" (fixes just applied for the release) and that just can be done in a branch. Second because a (more or less) stabilized trunk doesn't mean a regression-free trunk (but it could be). The first main advantage (about avoid sending critical code in the month we are going to release) is that we will have a whole month to check if the critical changes has waken up underlying bugs (or if the critical changes has introduced Eisenbugs).If we are following the "bleeding edge" approach we can just pray to find those Eisenbugs in the Release Candidate ISO tests and, since there aren't a lot of testers checking the RC ISO, it is quite unprovable. The second main advantage is that we reduce the Release Engineers amount of work. It is not the same bugging them to create just one RC ISO than bugging them to create 2 or 3 because playing with the "bleeding edge" concept.

4 4

Re: [ros-dev] 0.3.12 milestones status
by victor martinez 23 Sep '10

23 Sep '10

> > I am not agree :) As far as i see we have tried to (more or less) > > stabilize trunk before branching at least in the 2 latest releases. > This is because trunk has been in a mess for the past few releases. > Due to its instability it wasn't worth branching it as it was so far from > being releasable. > In the past we had (strived for) a 2 month release cycle. > We branched every 2 months no matter what and then worked on getting that > release out. > This is how linux and most other serious open source projects work. It's all > about discipline. "About discipline" and about having a lot of developers which can cover all the needs a project has. ;) And let me not talk about some "serious open source pojects" with tons developers/users which has introduced and released with critical regressions. > > There is not an incompatibility with the "stabilizing trunk" and > > "branching" concepts. First because exists the "Hack-releases" (fixes > > just applied for the release) and that just can be done in a branch. > > Second because a (more or less) stabilized trunk doesn't mean a > > regression-free trunk (but it could be). > This is exactly what it's for. Branch, fix bugs or hack bugs away. > Merge real bug fixes back into trunk, tag and release. Sure, I was just answering to your "What's the point in branching otherwise?" which seemed to be a question about an incompatibility with "avoiding critical commits" and "stabilizing trunk" before branching. > > The first main advantage (about avoid sending critical code in the > > month we are going to release) is that we will have a whole month to check > > if the critical changes has waken up underlying bugs > > This is the ongoing job of the testers to do both in trunk and more > importantly, in release branch. > If any serious bugs are found late in the process, drop the branch, fix in > trunk and rebranch. Just 2 words: Im-possible. :) You need a testing time frame. There is something called "Probability" of finding a regression(even more finding an eisenbug). If you branch right after a critical commit and that critical commit has introduced a regression you have much less "Probability" to find it that if the last critical commit was made 1 month ago. Even more, Release Candidates are mainly just tested by the Testers. So finding the regression depends mainly on "Probability Testers find a regression in one week" But during that Quarantine month other commits (non critical ones) can be sent and developers can feel/find regressions too. So finding the regressions would depend mainly on "Probability Testers and Devs find a regression in one month". Notice that the testing group is wider and so the time. We don't have Testing manpower to find a regression the next day/week it was commited. > > The second main advantage is that we reduce the Release Engineers amount of work. > But you hamper development. Locking down trunk for a month before every > release is a sure way to drive away all of your developers. > I would refuse to work on a project which worked in this way, as would most > other devs I assume. Who talked about freezing trunk? I should define 1-month Quarantine better: "Avoid commiting to critical areas. The trunk is open for those non-critical ones. You can send meanwhile your critical patches to a branch and after the release pushing them to trunk.". You have a ReactOS branch if needed. > If you're finding when release time comes that no devs work on fixing the > release branch and instead continue adding new code to trunk, then you have > a developer discipline issue not a release process issue. If we pay our developers we can ask for discipline meanwhile we can just accept their patches or refuse them. Will you refuse a Patch? Or maybe revoke a Dev commit access to create discipline? Any useful ideas? > Locking trunk is just a way to work around your developer discipline problem > instead of tackling the real problem, your devs can't be bothered to fix > existing code and continue to ignore their duties and add new code instead. Noone talked about Locking Trunk, and there are no duties. IIRC you were the first person that explained me why there are no dutie$ in this project. > Ged. Vic

2 1

Trunk freeze
by Aleksey Bragin 23 Sep '10

23 Sep '10

Hello, 0.3.12 was branched today, so I removed the lock from trunk. However, I want to really ask everyone not to jump into modern fancy features but pay more attention to fixing core parts of the system. Victor is doing the change log draft, and if Colin has time I would like to ask him to apply our usual release stuff. WBR, Aleksey Bragin.

1 0

0.3.12 Changelog Sum up.
by victor martinez 23 Sep '10

23 Sep '10

You have done a pretty cool work. 0.3.12 Changelog is opened, I have added a "Regression", "General Bugs" section where i reflect the Bugs fixed from 0.3.11 to 0.3.12. This is a little bit more user-friendly. You can find it here: http://www.reactos.org/wiki/ChangeLog-0.3.12#General The Bugzilla stats shows the next: - There were 259 General Bugs fixed (Regressions fixed are not counted here) - There were 20 Translations sent in 11 different Languages. - And you fixed 61 Regressions So more than 320 bugs has been fixed in less than 300 days. (Without counting Bugfixes in branch) You have killed more than 10 bugs older than 3 years old. And the eldest one is "#969 Minimized windows are shown on desktop" which is 5 years old. Congratz :)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev September 2010