Fix of the Week

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: Fix of the Week

Post by vicmarcal » Fri Oct 14, 2011 11:53 am

USB Mices and Keyboards Support!!!
I can't paste just a commit, because a lot of people (mainly Janderwald and Mjmartin) and commits make this possible.
Please retest in RH!!
Image

elhoir
Test Team
Posts: 397
Joined: Thu Sep 13, 2007 7:01 pm
Location: Madrid, Spain
Contact:

Re: Fix of the Week

Post by elhoir » Fri Oct 28, 2011 1:42 pm

"Fixes "Assertion 'GuardedMutex->Owner == KeGetCurrentThread()' failed" when faulting in pages via MmProbeAndLockPages"

Commit by cgutman :: r54256

Yeah, i know, this is not a real fix, but a hackfix, but still...

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: Fix of the Week

Post by vicmarcal » Thu Nov 17, 2011 12:40 am

Commit by cgutman :: r54402 reactos/drivers/network/ndis/ndis/config.c: (link)

[NDIS]

Fix a critical bug in registry entry parsing that was causing all REG_SZ values to be reported as NdisParameterTypeInteger
Distinguish between NdisParameterTypeInteger and NdisParameterTypeHexInteger
3Com NICs are fully functional now [bug 4330]


No comments. But NICs compatibility has suffered a big boooooooooooooooooost during the last months. Intel pro/realteks/3Com...
Try your NICs and report to aicom, he is on steroids!Aicom congratz!!Keep this cool work MAN!
Image

Bblaauw
Posts: 149
Joined: Mon Aug 03, 2009 12:59 am

Re: Fix of the Week

Post by Bblaauw » Sat Dec 10, 2011 6:32 pm

I'd like to nominate:

Code: Select all

Commit by cgutman :: r54632 reactos/base/setup/usetup/ (cabinet.c cabinet.h): (link)

[USETUP]

    Cache the last data block and offset so we don't have to search from the start each time
    This avoids needless swapping of cabinet data in and out of RAM
    File copy in text-mode setup on 32 MB RAM is down from 8 minutes to 20 seconds (in my testing)
Works flawlessly (though don't even try to specify less than 32MB in QEMU).
It's a very nice improvement over bug 6526, though I'm not sure what current memory requirements for phase 2 (LDR/mshtml.dll bug) and phase 3 are.

elhoir
Test Team
Posts: 397
Joined: Thu Sep 13, 2007 7:01 pm
Location: Madrid, Spain
Contact:

Re: Fix of the Week

Post by elhoir » Thu Jan 19, 2012 12:02 am

Of course, r55000 (merge of wlan-bringup branch) is a MUST in "feature of the month" contest :)

oswetto
Posts: 109
Joined: Mon Oct 26, 2009 10:43 pm

Re: Fix of the Week

Post by oswetto » Wed Jan 25, 2012 10:41 am

http://cia.vc/stats/project/ReactOS/.message/3dc6b46

Finally add the long awaited Mount Point Manager (aka mountmgr).
It's not complete yet, but will do most of the job it's been designed for.
What's missing is some dos volumes handlers, complete database support (local - registry - is complete, remote - files - is not).
It handles NTFS properties like reparse points.
It also handles devices with drive letters and those without drive letters (by using their unique ID).
Devices removal/arrival is detected through notifications (might be an issue).
Some work will have to be done in storage stack to fully support it.
Most of its IOCTL have been implemented (it's possible, for example, to notify a volume arrival through them, in case notifications don't work).

There's still some work to do on it to have it complete and fully implemented.
Enjoy!

fLuXx
Posts: 76
Joined: Sun Oct 25, 2009 11:42 am

Re: Fix of the Week

Post by fLuXx » Thu Feb 23, 2012 2:56 pm

An epic commit today! This is easily going to be the fix of this week if not month!
r55833:
[NEWCC]
A reintegration checkpoint for the NewCC branch, brought to you by Team NewCC.

Differences with current ReactOS trunk:
  • A new memory area type, MEMORY_AREA_CACHE, is added, which represents a mapped region of a file. In NEWCC mode, user sections are MEMORY_AREA_CACHE type as well, and obey new semantics. In non-NEWCC mode, they aren't used.
  • A way of claiming a page entry for a specific thread's work is added. Placing the special SWAPENTRY value MM_WAIT_ENTRY in a page table, or in a section page table should indicate that memory management code is intended to wait for another thread to make some status change before checking the state of the page entry again. In code that uses this convention, a return value of STATUS_SUCCESS + 1 is used to indicate that the caller should use the MiWaitForPageEvent macro to wait until somebody has change the state of a wait entry before checking again. This is a lighter weight mechanism than PAGEOPs.
  • A way of asking the caller to perform some blocking operation without locks held is provided. This replaces some spaghettified code in which locks are repeatedly taken and broken by code that performs various blocking operations. Using this mechanism, it is possible to do a small amount of non-blocking work, fill in a request, then return STATUS_MORE_PROCESSING_REQUIRED to request that locks be dropped and the blocking operation be carried out. A MM_REQUIRED_RESOURCES structure is provided to consumers of this contract to use to accumulate state across many blocking operations. Several functions wrapping blocking operations are provided in ntoskrnl/cache/reqtools.c.
  • Image section pages are no longer direct mapped. This is done to simplify consolidation of ownership of pages under the data section system. At a later time, it may be possible to make data pages directly available to image sections for the same file. This is likely the only direct performance impact this code makes on non-NEWCC mode.
RMAPs:
  • A new type of RMAP entry is introduced, distinguished by RMAP_IS_SEGMENT(Address) of the rmap entry. This kind of entry contains a pointer to a section page table node in the Process pointer, which in turn links back to the MM_SECTION_SEGMENT it belongs to. Therefore, a page belonging only to a segment (that is, a segment page that isn't mapped) can exist and be evicted using the normal page eviction mechanism in balance.c. Each of the rmap function has been modified to deal with segment rmaps.
  • The low 8 bits of the Address field in a segment rmap denote the entry number in the generic table node pointed to by Process that points to the page the rmap belongs to. By combining them, you can determine the file offset the page belongs to.
  • In NEWCC mode, MmSharePageEntry/UnsharePageEntry are not used, and instead the page reference count is used to keep track of the number of mappings of a page, allowing the last reference expiring to allow the page to be recycled without much intervention. These are still used in non-NEWCC mode. One change has been made, the count fields have been narrowed by 1 bit to make room for a dirty bit in SSE entries, needed when a page is present but unmapped.
Section page tables:
  • The section page tables are now implemented using RtlGenericTables. This enables a fairly compact representation of section page tables without having the existence of a section object imply 4k of fake PDEs. In addition, each node in the generic table has a wide file offset that is a multiple of 256 pages, or 1 megabyte total. Besides needing wide file offsets, the only other visible change caused by the switch to generic tables for section page tables is the need to lock the section segment before interacting with the section page table.
Eviction:
  • Page eviction in cache sections is accomplished by MmpPageOutPhysicalAddress. In the case of a shared page, it tries to remove all mappings of the indicated page. If this process fails at any point, the page will simply be drawn back into the target address spaces. After succeeding at this, if TRUE has been accumulated into the page's dirty bit in the section page table, it is written back, and then permanently removed.
NewCC mode:
  • NEWCC mode is introduced, which rewrites the file cache to a set of cache stripes actively mapped, along with unmapped section data.
  • NewCC is more authentic in its interpretation of the external interface to the windows cache than the current cache manager, implementing each of the cache manager functions according to the documented interface with no preconceived ideas about how anything should be implemented internally. Cache stripes are implemented on top of section objects, using the same memory manager paths, and therefore economizing code and complexity. This replaces a rather complicated system in which pages can be owned by the cache manager and the memory manager simultaneously and they must cooperate in a fairly sophisticated way to manage them. Since they're quite interdependent in the current code, modifying either is very difficult. In NEWCC, they have a clear division of labor and thus can be worked on independently.
  • Several third party filesystems that use the kernel Cc interface work properly using NEWCC, including matt wu's ext3 driver.
  • In contrast with code that tries to make CcInitializeCacheMap and CcUninitializeCacheMap into a pair that supports reference counting, NEWCC lazily initializes the shared and private cache maps as needed and uses the presence of a PrivateCacheMap on at least one file pointing to the SharedCacheMap as an indication that the FILE_OBJECT reference in the SharedCacheMap should still be held. When the last PrivateCacheMap is discarded, that's the appropriate time to tear down caching for a specific file, as the SharedCacheMap data is allowed to be saved and reused. We honor this by making the SharedCacheMap into a depot for keeping track of the PrivateCacheMap objects associated with views of a file.

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Re: Fix of the Week

Post by Haos » Wed Mar 14, 2012 12:25 am

Let me announce revision 56124, which is one of the final commits needed to close first bug i ever reported for ReactOS project: bug 2286.

This was a five year long effort, taked by:
- Magnus Olsen;
- Timo Kreuzer;
- James Tabor;
- Jerome Gardou;
- Thomas Faber;
- Cameron Gutman;

To fix this bug we had:
- ARM3 rewrite
- YAROTOWS;
- wide range of videoprt fixes
- PnP/PCI fixing.

Its finaly done.

Webunny
Posts: 1201
Joined: Sat Apr 28, 2012 1:30 pm

Re: Fix of the Week

Post by Webunny » Sun Jun 24, 2012 10:28 pm

Haos wrote:Let me announce revision 56124, which is one of the final commits needed to close first bug i ever reported for ReactOS project: bug 2286.

This was a five year long effort, taked by:
- Magnus Olsen;
- Timo Kreuzer;
- James Tabor;
- Jerome Gardou;
- Thomas Faber;
- Cameron Gutman;

To fix this bug we had:
- ARM3 rewrite
- YAROTOWS;
- wide range of videoprt fixes
- PnP/PCI fixing.

Its finaly done.
Nice. That said; aren't there any noteworthy fixes in May and June?

Btw, Haos, I've responded at http://www.reactos.org/forum/viewtopic. ... 9&start=15 as well.

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Re: Fix of the Week

Post by Haos » Mon Jun 25, 2012 12:04 am

Nothing epic to mention, unfortunately.

gonzoMD
Posts: 1008
Joined: Fri Oct 20, 2006 7:49 am
Location: Germany
Contact:

Re: Fix of the Week

Post by gonzoMD » Wed Jun 27, 2012 7:55 am

Here we have something little, but important:

Code: Select all

Commit by spetreolle :: r56808 reactos/base/system/format/format.c:

[FORMAT]
Handle read only devices and report them unsupported.
Forbid the formatting of the system drive.

Patch by Mikael Lyngvig.
See bug 2081 for more details.

oswetto
Posts: 109
Joined: Mon Oct 26, 2009 10:43 pm

Re: Fix of the Week

Post by oswetto » Thu Jul 12, 2012 10:35 am

bug 7148

http://cia.vc/stats/project/ReactOS/.message/3fdabce

Code: Select all

Update Uniata to 41b5. Thanks to Alter for the great driver and Olaf Siejka for preparing the patch, getting our changes upstream and testing the updated version. See issue #7148 for more details.

milon
Posts: 969
Joined: Sat Sep 05, 2009 9:26 pm

Re: Fix of the Week

Post by milon » Thu Jul 12, 2012 2:23 pm

Sweet! I've been waiting for that one!

Saibamen
Posts: 212
Joined: Mon Jul 19, 2010 11:19 am
Location: Poland
Contact:

Re: Fix of the Week

Post by Saibamen » Fri Sep 14, 2012 6:43 pm

revision 57293
[WIN32SS]
Properly implement GetNearestColor
1286 more tests completed in gdi32:bitmap :)
ReactOS Forum Global Moderator
IT-Maniak.pl administrator

fulup
Posts: 25
Joined: Thu Jan 03, 2008 12:11 am
Location: Brest, Bretagne

Re: Fix of the Week

Post by fulup » Thu Nov 29, 2012 2:26 am

Hermes Belusca-Maito resolved CORE-4247 - Can't send debugging information out COM1 with VPC as 'Fixed'

A bug from 2009-06-11 was squashed. The COM port will be available for debbuging on Microsoft Virtual PC now.
Greetings Hermes!

Post Reply

Who is online

Users browsing this forum: DotBot [Crawler] and 3 guests