- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [dgorbachev] 42566: Fix IDT limit.

by Aleksey Bragin

Good catch, thanks! (I'm getting used to finding a real change in reformatting commits nowadays :)). WBR, Aleksey Bragin. On Aug 9, 2009, at 6:40 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Sun Aug 9 16:40:05 2009 > New Revision: 42566 > > URL: http://svn.reactos.org/svn/reactos?rev=42566&view=rev > Log: > Fix IDT limit. > > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386idt.S > trunk/reactos/boot/freeldr/freeldr/windows/wlmemory.c

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [hyperion] 42530: modified base/setup/vmwinst/vmwinst.c modified base/setup/vmwinst/vmwinst.rbuild Implement VMWare detection for Visual C++ as well For cleaner code, use SEH instead of VEH, even if it means losing this pearl of ReactOS wisdom: /* Setup a vectored exception handler to protect the detection. Don't use SEH here so we notice the next time someone removes support for vectored exception handling from ros... */ (www.passiveaggressivecommits.com, brought to you by Arch Bl

by Aleksey Bragin

On Aug 8, 2009, at 10:03 PM, hyperion(a)svn.reactos.org wrote: > Author: hyperion > Date: Sat Aug 8 20:03:48 2009 > New Revision: 42530 > > URL: http://svn.reactos.org/svn/reactos?rev=42530&view=rev > Log: > modified base/setup/vmwinst/vmwinst.c > modified base/setup/vmwinst/vmwinst.rbuild > Implement VMWare detection for Visual C++ as well > For cleaner code, use SEH instead of VEH, even if it means > losing this pearl of ReactOS wisdom: > > /* Setup a vectored exception handler to protect the > detection. Don't use SEH > here so we notice the next time someone removes support for > vectored > exception handling from ros... */ > > (www.passiveaggressivecommits.com, brought to you by Arch > Blackmann!) > Of course, it also means trading our VEH bugs for our SEH bugs, > so I'm not sure if it was worth changing This test should be added to the test suite which we have now (or maybe it is there already?). Putting various tests inside unrelated apps was a great idea back then but reactos evolved from that. WBR, Aleksey Bragin.

16 years, 1 month

2
1
0 0

Re: [ros-dev] [ros-diffs] [hpoussin] 42538: Fix some typos and make PFILE a ULONG

by Timo Kreuzer

hpoussin(a)svn.reactos.org wrote: > Author: hpoussin > Date: Sat Aug 8 23:11:40 2009 > New Revision: 42538 > > URL: http://svn.reactos.org/svn/reactos?rev=42538&view=rev > Log: > Fix some typos and make PFILE a ULONG > I hope this is fully 64 bit compatible... I think FILEID would look better and is less likely to confuse other devs when working with it ;-)

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 42569: Do not call CcUnpinData() with NULL PtrBCB.

by Filip Navara

This is very wrong! PtrBCB should never ever be NULL... and if it is then it means that CcMapData few lines above failed. In fact the whole chunk of code is wrong. CcMapData return value is not properly checked. If it got far enough that CcUnpinData crashed then PtrParentFCB->NTRequiredFCB.CommonFCBHeader.FileSize == 0 and obviously the mapping will fail. This case can easily be checked without even attempting to map the data... Best regards, Filip Navara On Sun, Aug 9, 2009 at 7:26 PM, <dgorbachev(a)svn.reactos.org> wrote: > Author: dgorbachev > Date: Sun Aug 9 19:26:10 2009 > New Revision: 42569 > > URL: http://svn.reactos.org/svn/reactos?rev=42569&view=rev > Log: > Do not call CcUnpinData() with NULL PtrBCB. > > Modified: > trunk/reactos/drivers/filesystems/ext2/src/create.c > > Modified: trunk/reactos/drivers/filesystems/ext2/src/create.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/ext2/s… > ============================================================================== > --- trunk/reactos/drivers/filesystems/ext2/src/create.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/ext2/src/create.c [iso-8859-1] Sun Aug 9 19:26:10 2009 > @@ -1410,8 +1410,12 @@ > } > } > > - CcUnpinData( PtrBCB ); > - PtrBCB = NULL; > + // FIXME > + if( PtrBCB ) > + { > + CcUnpinData( PtrBCB ); > + PtrBCB = NULL; > + } > > return InodeNo; > } > > >

16 years, 1 month

1
0
0 0

My ideas for some new Graphics

by xact11＠web.de

Hey everyone, my name is Huzky, I'm a Graphic-Artist and I would like to present my graphics for ReactOS to you: This is my idea for a new ROS-BE Icon: http://img188.imageshack.us/img188/2416/ros2.png And this is a preview of a Theme I'am creating for ROS, because I think ROS should look like the modern os it is :) http://img188.imageshack.us/img188/8097/task.png I would be very happy about critics or suggestions for Improvement. best regards, Huzky ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de

16 years, 1 month

4
3
0 0

Re: [ros-dev] [ros-diffs] [hyperion] 42530: modified base/setup/vmwinst/vmwinst.c modified base/setup/vmwinst/vmwinst.rbuild Implement VMWare detection for Visual C++ as well For cleaner code, use SEH instead of VEH, even if it means losing this pear

by Steven Edwards

On Sat, Aug 8, 2009 at 5:38 PM, Alex Ionescu<ionucu(a)videotron.ca> wrote: > Awe, Thomas's "Fuck Alex" code is gone... I think we should add it back with this discussion in comments so posterity is left to ponder. -- 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

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [hyperion] 42530: modified base/setup/vmwinst/vmwinst.c modified base/setup/vmwinst/vmwinst.rbuild Implement VMWare detection for Visual C++ as well For cleaner code, use SEH instead of VEH, even if it means losing this pearl of ReactOS wisdom: /* Setup a vectored exception handler to protect the detection. Don't use SEH here so we notice the next time someone removes support for vectored exception handling from ros... */ (www.passiveaggressivecommits.com, brought to you by Arch Bl

by Alex Ionescu

Awe, Thomas's "Fuck Alex" code is gone... On 8-Aug-09, at 11:03 AM, hyperion(a)svn.reactos.org wrote: > For cleaner code, use SEH instead of VEH, even if it means losing > this pearl of ReactOS wisdom: > > /* Setup a vectored exception handler to protect the > detection. Don't use SEH > here so we notice the next time someone removes support for > vectored > exception handling from ros... */ Best regards, Alex Ionescu

16 years, 1 month

1
0
0 0

Regression when installing drivers ("New Hardware Found" wizard) at 3rd stage

by Javier Agustìn Fernàndez Arroyo

Hi all, I have found a regression at 3rd stage, that prevents me to install my sound card drivers anymore, I have regtested it, and the range is 42150 - 42263 Unfortunately, there are no debug revisions between these 2 revs, so i cant regtest anymore. Since i was trying to install sound card drivers, i asked Janderwald about it, and he has led me to the ML This is the log im getting ( http://www.reactos.org/paste/index.php/5523/ ): fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"FMSynth" L"WDM_P16X.Interface.DMus" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"FMSynth" L"WDM_P16X.Interface.DMus" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({dff220f3-f70f-11d0-b917-00a0c9223196} L"FMSynth" L"WDM_P16X.Interface.DMus" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"Wave" L"WDM_P16X.Interface.Wave" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"Wave" L"WDM_P16X.Interface.Wave" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({65e8773d-8f56-11d0-a3b9-00a0c9223196} L"Wave" L"WDM_P16X.Interface.Wave" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"Topology" L"WDM_P16X.Interface.Topology" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({dda54a40-1e4c-11d1-a050-405705c10000} L"Topology" L"WDM_P16X.Interface.Topology" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({6994ad04-93ef-11d0-a3cc-00a0c9223196} L"UART" L"WDM_P16X.Interface.UART" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({65e8773e-8f56-11d0-a3b9-00a0c9223196} L"UART" L"WDM_P16X.Interface.UART" 0) fixme:(dll/win32/setupapi/interface.c:307) Need to InstallOneInterface({65e8773d-8f56-11d0-a3b9-00a0c9223196} L"UART" L"WDM_P16X.Interface.UART" 0) err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\sysaudio.sys" -> L"C:\\ReactOS\\System32\\sysaudio.sys" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\wdmaud.sys" -> L"C:\\ReactOS\\System32\\wdmaud.sys" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\portcls.sys" -> L"C:\\ReactOS\\System32\\portcls.sys" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\drmk.sys" -> L"C:\\ReactOS\\System32\\drmk.sys" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\kmixer.sys" -> L"C:\\ReactOS\\System32\\kmixer.sys" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\wdmaud.drv" -> L"C:\\ReactOS\\System32\\drivers\\wdmaud.drv" err:(dll/win32/setupapi/queue.c:1659) copy error 2 L"C:\\ReactOS\\inf\\ksuser.dll" -> L"C:\\ReactOS\\System32\\drivers\\ksuser.dll" err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory L"%USERPROFILE%\\Configuraci\00f3n local\\Archivos temporales de Internet". err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 0 err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory L"%USERPROFILE%\\Configuraci\00f3n local\\Historial". err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 1 err:(dll/win32/shell32/shellpath.c:1454) Failed to create directory L"%USERPROFILE%\\Cookies". err:(dll/win32/wininet/urlcache.c:554) Couldn't get path for default container 2 fixme:(dll/win32/setupapi/stubs.c:200) Stub 00638920 0132FF40 1 0132FF0C (drivers/wdm/audio/backpln/portcls/adapter.c:48) PcInitializeAdapterDriver (drivers/wdm/audio/backpln/portcls/adapter.c:52) Setting IRP handlers (drivers/wdm/audio/backpln/portcls/adapter.c:98) PcAddAdapterDevice called (drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15 (drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15 (drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15 (drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15 (drivers/wdm/audio/backpln/portcls/irp.c:142) unhandled function 15 Assertion 'PointerPte != NULL' failed at ARMÂ³::SYSPTE line 177 Entered debugger on embedded INT3 at 0x0008:0x808c06f6. kdb:> bt Eip: <NTOSKRNL.EXE:c06f7 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:79d20 (ARMÂ³::SYSPTE:177 (MiReserveSystemPtes@8))> <NTOSKRNL.EXE:793dd (ARMÂ³::POOL:270 (MiAllocatePoolPages@8))> <NTOSKRNL.EXE:7666d (ARMÂ³::EXPOOL:118 (ExAllocateArmPoolWithTag@12))> <NTOSKRNL.EXE:8403c (ntoskrnl/mm/pool.c:87 (EiAllocatePool@16))> <NTOSKRNL.EXE:8415d (ntoskrnl/mm/pool.c:166 (ExAllocatePoolWithTag@12))> <FM801A.sys:6f4d> <FM801A.sys:bfb9> <NTOSKRNL.EXE:8415d (ntoskrnl/mm/pool.c:166 (ExAllocatePoolWithTag@12))> <portcls.sys:997c (drivers/wdm/audio/backpln/portcls/pool.c:18 (AllocateItem))> <portcls.sys:da36 (drivers/wdm/audio/backpln/portcls/registry.c:371 (PcNewRegistryKey@36))> <FM801A.sys:e6ba> <FM801A.sys:909> <portcls.sys:4c65 (drivers/wdm/audio/backpln/portcls/irp.c:97 (PortClsPnp@8))> <portcls.sys:4d31 (drivers/wdm/audio/backpln/portcls/irp.c:268 (PcDispatchIrp@8))> <FM801A.sys:656f> <FM801A.sys:63bb> <NTOSKRNL.EXE:5a90a (ntoskrnl/io/pnpmgr/pnpmgr.c:534 (IopInitiatePnpIrp))> <NTOSKRNL.EXE:5a3c3 (ntoskrnl/include/internal/ke_x.h:98 (IopStartDevice))> <NTOSKRNL.EXE:5bd75 (ntoskrnl/io/pnpmgr/pnpmgr.c:2055 (IopActionInitChildServices))> <NTOSKRNL.EXE:59e31 (ntoskrnl/io/pnpmgr/plugplay.c:577 (IopResetDevice))> <NTOSKRNL.EXE:5a0cc (ntoskrnl/io/pnpmgr/plugplay.c:837 (NtPlugPlayControl@12))>--- Press q to abort, any other key to continue --- <NTOSKRNL.EXE:b8cf0 (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))> <ntdll.dll:658d> <umpnpmgr.exe:9614> <rpcrt4.dll:1c0b3> <rpcrt4.dll:1c479> <rpcrt4.dll:1c54b> <kernel32.dll:27b4f> <ntdll.dll:179f2> <ntdll.dll:181e6> <00000000> kdb:>

16 years, 1 month

1
2
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments

by WaxDragon

Your kung-fu is the best, Alex. On Aug 3, 2009 7:22 PM, "Alex Ionescu" <ionucu(a)videotron.ca> wrote: Just got back to San Francisco... I will take you up on the challenge. Your ass is grass, and I'm the lawnmower. Best regards, Alex Ionescu On Mon, Aug 3, 2009 at 11:15 AM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote: > > yeah ;-) > > Dmitr... _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

16 years, 1 month

7
21
0 0

[ros-diffs] [gschneider] 42402: asctime/ctime: Check for too low input time, fixes one msvcrt time winetest

by Gregor Schneider

Hi, I just checked: ctime and asctime have a different behaviour when it comes to parameter checks, although they work on the same buffer. I'll address this soon. Most param checks are missing indeed, but they'll be added one after another. I'm just starting on that. The only real life problem with the code that I could find is that mktime produces a time that is one or two hours off. Best regards Gregor Schneider

16 years, 1 month

3
3
0 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 42388: - Add "ReactOS Application Manager". This program is replacement "Download !" and appwiz.cpl.

by Steven Edwards

On Tue, Aug 4, 2009 at 3:02 PM, <dchapyshev(a)svn.reactos.org> wrote: > Author: dchapyshev > Date: Tue Aug 4 21:02:56 2009 > New Revision: 42388 > > URL: http://svn.reactos.org/svn/reactos?rev=42388&view=rev > Log: > - Add "ReactOS Application Manager". This program is replacement "Download !" and appwiz.cpl. > I don't have the time to do a build at the moment, are there screenshots of this guy anywhere? 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

16 years, 1 month

4
4
0 0

Re: [ros-dev] [ros-diffs] [gschneider] 42402: asctime/ctime: Check for too low input time, fixes one msvcrt time winetest

by Alexander Potashev

Hi, First of all, are you sure that this code is mature enough to care about minor details? I would say, "@implemented" has been added by mistake. About this commit: I tried to call asctime from glibc-2.8 on Linux, but tm_year=9 works fine (resulting in 1909). I know, it is not msvcrt. But I don't see any good reason to not allow years before 1970. Furthermore, I'm sure, this function was once introduced to just transform a date to human-readable format, and it shouldn't care about the date. Btw, MSDN says nothing Another tricky question is: How is the UNIX epoch connected with Reactos (or Windows)? About 'asctime': it might be holy, but it's "holey". It doesn't even check the month and the day of week to fit the ranges 0..11 and 0..6 correspondingly. So, please, fix the security problems first, and then revert this commit ;) 2009/8/4 <gschneider(a)svn.reactos.org>: > Author: gschneider > Date: Wed Aug 5 04:06:25 2009 > New Revision: 42402 > > URL: http://svn.reactos.org/svn/reactos?rev=42402&view=rev > Log: > asctime/ctime: Check for too low input time, fixes one msvcrt time winetest > > Modified: > trunk/reactos/lib/sdk/crt/time/ctime.c > > Modified: trunk/reactos/lib/sdk/crt/time/ctime.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/time/ctime.c?r… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/time/ctime.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/time/ctime.c [iso-8859-1] Wed Aug 5 04:06:25 2009 > @@ -1200,14 +1200,23 @@ > "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" > }; > static char result[26]; > - > - (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n", > - wday_name[timeptr->tm_wday], > - mon_name[timeptr->tm_mon], > - timeptr->tm_mday, timeptr->tm_hour, > - timeptr->tm_min, timeptr->tm_sec, > - TM_YEAR_BASE + timeptr->tm_year); > - return result; > + char* res = result; > + > + /* Check for invalid input time */ > + if (timeptr->tm_year <= 69) > + { > + res = NULL; > + } > + else > + { > + sprintf(res, "%.3s %.3s%3d %02d:%02d:%02d %d\n", > + wday_name[timeptr->tm_wday], > + mon_name[timeptr->tm_mon], > + timeptr->tm_mday, timeptr->tm_hour, > + timeptr->tm_min, timeptr->tm_sec, > + TM_YEAR_BASE + timeptr->tm_year); > + } > + return res; > } > > /* > > >

16 years, 1 month

2
4
0 0

Re: [ros-dev] [ros-diffs] [cgutman] 42400: - Partial rewrite of recursive mutex code - Makes the recursive mutex faster and smaller - Fixes several unprotected accesses to recursive mutex

by Alex Ionescu

Mutexes are already recursive, while fast-mutexes are not so I still don't understand the point of this library. Just use a KMUTEX. On 4-Aug-09, at 4:51 PM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Wed Aug 5 01:51:39 2009 > New Revision: 42400 > > URL: http://svn.reactos.org/svn/reactos?rev=42400&view=rev > Log: > - Partial rewrite of recursive mutex code > - Makes the recursive mutex faster and smaller > - Fixes several unprotected accesses to recursive mutex > > Modified: > trunk/reactos/drivers/network/tcpip/include/lock.h > trunk/reactos/drivers/network/tcpip/recmutex/recmutex.c > trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h > trunk/reactos/drivers/network/tcpip/tcpip/lock.c > > Modified: trunk/reactos/drivers/network/tcpip/include/lock.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/incl… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/drivers/network/tcpip/include/lock.h [iso-8859-1] > (original) > +++ trunk/reactos/drivers/network/tcpip/include/lock.h [iso-8859-1] > Wed Aug 5 01:51:39 2009 > @@ -13,7 +13,7 @@ > extern VOID TcpipAcquireFastMutex( PFAST_MUTEX Mutex ); > extern VOID TcpipReleaseFastMutex( PFAST_MUTEX Mutex ); > extern VOID TcpipRecursiveMutexInit( PRECURSIVE_MUTEX RecMutex ); > -extern UINT TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, > +extern VOID TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, > BOOLEAN ToWrite ); > extern VOID TcpipRecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ); > > > Modified: trunk/reactos/drivers/network/tcpip/recmutex/recmutex.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/recm… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/drivers/network/tcpip/recmutex/recmutex.c > [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/tcpip/recmutex/recmutex.c > [iso-8859-1] Wed Aug 5 01:51:39 2009 > @@ -3,7 +3,6 @@ > > VOID RecursiveMutexInit( PRECURSIVE_MUTEX RecMutex ) { > RtlZeroMemory( RecMutex, sizeof(*RecMutex) ); > - KeInitializeSpinLock( &RecMutex->SpinLock ); > ExInitializeFastMutex( &RecMutex->Mutex ); > KeInitializeEvent( &RecMutex->StateLockedEvent, > NotificationEvent, FALSE ); > @@ -11,76 +10,53 @@ > > /* NOTE: When we leave, the FAST_MUTEX must have been released. The > result > * is that we always exit in the same irql as entering */ > -SIZE_T RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, BOOLEAN > ToWrite ) { > +VOID RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex ) { > NTSTATUS Status = STATUS_SUCCESS; > PVOID CurrentThread = KeGetCurrentThread(); > - KIRQL CurrentIrql; > + KIRQL CurrentIrql = KeGetCurrentIrql(); > + > + ASSERT(RecMutex); > + ASSERT(CurrentIrql <= APC_LEVEL); > > /* Wait for the previous user to unlock the RecMutex state. > There might be > * multiple waiters waiting to change the state. We need to > check each > * time we get the event whether somebody still has the state > locked */ > > - if( !RecMutex ) return FALSE; > + ExAcquireFastMutex( &RecMutex->Mutex ); > > - if( CurrentThread == RecMutex->CurrentThread || > - (!ToWrite && !RecMutex->Writer) ) { > + if( CurrentThread == RecMutex->CurrentThread ) { > RecMutex->LockCount++; > - return TRUE; > + ExReleaseFastMutex( &RecMutex->Mutex ); > + return; > } > > - CurrentIrql = KeGetCurrentIrql(); > - > - ASSERT(CurrentIrql <= DISPATCH_LEVEL); > - > - if( CurrentIrql <= APC_LEVEL ) { > - ExAcquireFastMutex( &RecMutex->Mutex ); > - while( RecMutex->Locked ) { > - ExReleaseFastMutex( &RecMutex->Mutex ); > - Status = KeWaitForSingleObject( &RecMutex- > >StateLockedEvent, > - UserRequest, > - KernelMode, > - FALSE, > - NULL ); > - ExAcquireFastMutex( &RecMutex->Mutex ); > - } > - RecMutex->OldIrql = CurrentIrql; > - RecMutex->Locked = TRUE; > - RecMutex->Writer = ToWrite; > - RecMutex->CurrentThread = CurrentThread; > - RecMutex->LockCount++; > - ExReleaseFastMutex( &RecMutex->Mutex ); > - } else { > - KeAcquireSpinLockAtDpcLevel( &RecMutex->SpinLock ); > - RecMutex->OldIrql = DISPATCH_LEVEL; > - RecMutex->Locked = TRUE; > - RecMutex->Writer = ToWrite; > - RecMutex->CurrentThread = CurrentThread; > - RecMutex->LockCount++; > + while( RecMutex->LockCount != 0 ) { > + ExReleaseFastMutex( &RecMutex->Mutex ); > + Status = KeWaitForSingleObject( &RecMutex->StateLockedEvent, > + UserRequest, > + KernelMode, > + FALSE, > + NULL ); > + ExAcquireFastMutex( &RecMutex->Mutex ); > } > - > - return TRUE; > + RecMutex->CurrentThread = CurrentThread; > + RecMutex->LockCount++; > + ExReleaseFastMutex( &RecMutex->Mutex ); > } > > VOID RecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ) { > + ASSERT(RecMutex); > + > + ExAcquireFastMutex( &RecMutex->Mutex ); > > ASSERT(RecMutex->LockCount > 0); > RecMutex->LockCount--; > > if( !RecMutex->LockCount ) { > - RecMutex->CurrentThread = NULL; > - if( RecMutex->OldIrql <= APC_LEVEL ) { > - ExAcquireFastMutex( &RecMutex->Mutex ); > - RecMutex->Locked = FALSE; > - RecMutex->Writer = FALSE; > - ExReleaseFastMutex( &RecMutex->Mutex ); > - } else { > - RecMutex->Locked = FALSE; > - RecMutex->Writer = FALSE; > - KeReleaseSpinLockFromDpcLevel( &RecMutex->SpinLock ); > - } > - > KePulseEvent( &RecMutex->StateLockedEvent, > IO_NETWORK_INCREMENT, > FALSE ); > } > + > + ExReleaseFastMutex( &RecMutex->Mutex ); > } > > > Modified: trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/recm… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h > [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/tcpip/recmutex/recmutex.h > [iso-8859-1] Wed Aug 5 01:51:39 2009 > @@ -10,20 +10,12 @@ > PVOID CurrentThread; > /* Notification event which signals that another thread can take > over */ > KEVENT StateLockedEvent; > - /* IRQL from spin lock */ > - KIRQL OldIrql; > - /* Is Locked */ > - BOOLEAN Locked; > - /* Is reader or writer phase */ > - BOOLEAN Writer; > - /* Spin lock needed for */ > - KSPIN_LOCK SpinLock; > } RECURSIVE_MUTEX, *PRECURSIVE_MUTEX; > > extern VOID RecursiveMutexInit( PRECURSIVE_MUTEX RecMutex ); > -extern SIZE_T RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, > BOOLEAN ToRead ); > +extern VOID RecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex ); > extern VOID RecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ); > > -#define ASSERT_LOCKED(x) ASSERT((x)->Locked) > +#define ASSERT_LOCKED(x) > > #endif/*_ROSRTL_RECMUTEX_H*/ > > Modified: trunk/reactos/drivers/network/tcpip/tcpip/lock.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/tcpi… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/drivers/network/tcpip/tcpip/lock.c [iso-8859-1] > (original) > +++ trunk/reactos/drivers/network/tcpip/tcpip/lock.c [iso-8859-1] > Wed Aug 5 01:51:39 2009 > @@ -48,11 +48,9 @@ > RecursiveMutexInit( RecMutex ); > } > > -UINT TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, BOOLEAN > ToWrite ) { > - UINT Ret; > +VOID TcpipRecursiveMutexEnter( PRECURSIVE_MUTEX RecMutex, BOOLEAN > ToWrite ) { > //TI_DbgPrint(DEBUG_LOCK,("Locking\n")); > - Ret = RecursiveMutexEnter( RecMutex, ToWrite ); > - return Ret; > + RecursiveMutexEnter( RecMutex ); > } > > VOID TcpipRecursiveMutexLeave( PRECURSIVE_MUTEX RecMutex ) { > > Best regards, Alex Ionescu

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 42353: asm version of DIB_32BPP_ColorFill: - Add frame pointer - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned - Optimize the loop - Add comments

by Alex Ionescu

The version that GCC 4.4 and CL 15 will generate would be way more optimized than this unportable/slower assembly code. This isn't 1994 anymore. You can't beat the compiler anymore. Best regards, Alex Ionescu On Sun, Aug 2, 2009 at 3:31 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Mon Aug 3 00:31:29 2009 > New Revision: 42353 > > URL: http://svn.reactos.org/svn/reactos?rev=42353&view=rev > Log: > asm version of DIB_32BPP_ColorFill: > - Add frame pointer > - Get rid of algin_draw, 32bpp surfaces must be DWORD aligned > - Optimize the loop > - Add comments > > Modified: > trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > > Modified: > trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/di… > > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.s > [iso-8859-1] Mon Aug 3 00:31:29 2009 > @@ -4,78 +4,62 @@ > * FILE: subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.c > * PURPOSE: ASM optimised 32bpp ColorFill > * PROGRAMMERS: Magnus Olsen > + * Timo Kreuzer (timo.kreuzer(a)rectos.org) > */ > > - .globl _DIB_32BPP_ColorFill > - .intel_syntax noprefix > +.intel_syntax noprefix > > - .def _DIB_32BPP_ColorFill; > - .scl 2; > - .type 32; > - .endef > - > - _DIB_32BPP_ColorFill: > - sub esp, 24 > - mov ecx, [esp+32] > - mov [esp+8], ebx > - mov ebx, [esp+28] > - mov [esp+20], ebp > - mov ebp, [esp+36] > - mov [esp+12], esi > - mov [esp+16], edi > - mov edi, [ecx] > - mov esi, [ecx+8] > - mov edx, [ebx+36] > - sub esi, edi > - mov edi, [ecx+4] > - mov eax, edi > - imul eax, edx > - add eax, [ebx+32] > - mov ebx, [ecx] > - lea eax, [eax+ebx*4] > - mov [esp+4], eax > - mov eax, [ecx+12] > - cmp eax, edi > - jbe end > - sub eax, edi > - mov [esp], eax > - lea esi, [esi+0] > +/* > + * BOOLEAN > + * _cdecl > + * DIB_32BPP_ColorFill(SURFOBJ* pso, RECTL* prcl, ULONG iColor); > +*/ > > - for_loop: > - mov eax, ebp > - cld > - mov ebx, esi > - mov edi, [esp+4] > - test edi, 3 > - jnz algin_draw > - mov ecx, esi > - rep stosd > - add [esp+4], edx > - dec dword ptr [esp] > - jnz for_loop > - end: > - mov ebx, [esp+8] > - mov eax, 1 > - mov esi, [esp+12] > - mov edi, [esp+16] > - mov ebp, [esp+20] > - add esp, 24 > - ret > +.globl _DIB_32BPP_ColorFill > +_DIB_32BPP_ColorFill: > + push ebp > + mov ebp, esp > + push ebx > + push esi > + push edi > + sub esp, 4 /* Space for lDelta */ > > - algin_draw: > - stosd > - dec ebx > - mov ecx, ebx > - rol eax, 16 > - stosd > - add [esp+4], edx > - dec dword ptr [esp] > - jnz for_loop > + mov edx, [ebp+12] /* edx = prcl */ > + mov ecx, [ebp+8] /* ecx = pso */ > > - mov ebx, [esp+8] > - mov eax, 1 > - mov esi, [esp+12] > - mov edi, [esp+16] > - mov ebp, [esp+20] > - add esp, 24 > - ret > + mov ebx, [ecx+0x24] /* ebx = pso->lDelta; */ > + mov [esp], ebx /* lDelta = pso->lDelta; */ > + mov edi, [edx+4] /* edi = prcl->top; */ > + mov eax, edi /* eax = prcl->top; */ > + imul eax, ebx /* eax = prcl->top * pso->lDelta; */ > + add eax, [ecx+0x20] /* eax += pso->pvScan0; */ > + mov ebx, [edx] /* ebx = prcl->left; */ > + lea esi, [eax+ebx*4] /* esi = pvLine0 = eax + 4 * prcl->left; > */ > + > + mov ebx, [edx+8] /* ebx = prcl->right; */ > + sub ebx, [edx] /* ebx = prcl->right - prcl->left; */ > + jbe end /* if (ebx <= 0) goto end; */ > + > + mov edx, [edx+12] /* edx = prcl->bottom; */ > + sub edx, edi /* edx -= prcl->top; */ > + jbe end /* if (eax <= 0) goto end; */ > + > + mov eax, [ebp+16] /* eax = iColor; */ > + cld > + > +for_loop: /* do { */ > + mov edi, esi /* edi = pvLine0; */ > + mov ecx, ebx /* ecx = cx; */ > + rep stosd /* memset(pvLine0, iColor, cx); */ > + add esi, [esp] /* pvLine0 += lDelta; */ > + dec edx /* cy--; */ > + jnz for_loop /* } while (cy > 0); */ > + > +end: > + mov eax, 1 > + add esp, 4 > + pop edi > + pop esi > + pop ebx > + pop ebp > + ret > > >

16 years, 1 month

5
8
0 0

Re: [ros-dev] [ros-diffs] [sginsberg] 42369: - mingw: __builtin_return_address -> _ReturnAddress, __builtin_frame_address -> _AddressOfReturnAddress - ReactOS-generic.rbuild: Define __STDC__ for MSVC to fix some code depending on it (not using /Za as it breaks other code)

by Timo Kreuzer

We have _ReturnAddress() and _AddressOfReturnAddress defined in intrin_x86.h sginsberg(a)svn.reactos.org wrote: > Author: sginsberg > Date: Mon Aug 3 20:02:07 2009 > New Revision: 42369 > > URL: http://svn.reactos.org/svn/reactos?rev=42369&view=rev > Log: > - mingw: __builtin_return_address -> _ReturnAddress, __builtin_frame_address -> _AddressOfReturnAddress > - ReactOS-generic.rbuild: Define __STDC__ for MSVC to fix some code depending on it (not using /Za as it breaks other code) > > Modified: > trunk/reactos/ReactOS-generic.rbuild > trunk/reactos/lib/3rdparty/mingw/gs_support.c > > Modified: trunk/reactos/ReactOS-generic.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ReactOS-generic.rbuild?rev… > ============================================================================== > --- trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] (original) > +++ trunk/reactos/ReactOS-generic.rbuild [iso-8859-1] Mon Aug 3 20:02:07 2009 > @@ -95,6 +95,7 @@ > > <group compilerset="msc"> > <define name="inline" compiler="cc">__inline</define> > + <define name="__STDC__" compiler="cc">1</define> > <compilerflag>/Zl</compilerflag> > <compilerflag>/Zi</compilerflag> > <compilerflag>/W1</compilerflag> > > Modified: trunk/reactos/lib/3rdparty/mingw/gs_support.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/mingw/gs_supp… > ============================================================================== > --- trunk/reactos/lib/3rdparty/mingw/gs_support.c [iso-8859-1] (original) > +++ trunk/reactos/lib/3rdparty/mingw/gs_support.c [iso-8859-1] Mon Aug 3 20:02:07 2009 > @@ -108,12 +108,22 @@ > else > #endif > { > +#ifdef __GNUC__ > #ifdef _WIN64 > GS_ContextRecord.Rip = (ULONGLONG) __builtin_return_address (0); > GS_ContextRecord.Rsp = (ULONGLONG) __builtin_frame_address (0) + 8; > #else > GS_ContextRecord.Eip = (DWORD) __builtin_return_address (0); > GS_ContextRecord.Esp = (DWORD) __builtin_frame_address (0) + 4; > +#endif > +#else > +#ifdef _WIN64 > + GS_ContextRecord.Rip = (ULONGLONG) _ReturnAddress(); > + GS_ContextRecord.Rsp = (ULONGLONG) _AddressOfReturnAddress(); > +#else > + GS_ContextRecord.Eip = (DWORD) _ReturnAddress(); > + GS_ContextRecord.Esp = (DWORD) _AddressOfReturnAddress(); > +#endif > #endif > } > > > > >

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 42333: - Handle case when RosGdiSetDeviceClipping is being called without rects at all (with a respective DPRINT1). - Use combined clipping object everywhere to ensure drawing happens only in allowed rectangle, se

by Alex Ionescu

A similar question would apply to the ninjas' "issue #" that crept up once or twice... Best regards, Alex Ionescu On Sun, Aug 2, 2009 at 3:26 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote: > > - Use combined clipping object everywhere to ensure drawing happens only > in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox > and other apps which would corrupt memory if trying to blit to area outside > of DC. > > I keep seeing these comments, 'see arwinss nr. #'. Where do I go to > look this up? > > 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 > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 42333: - Handle case when RosGdiSetDeviceClipping is being called without rects at all (with a respective DPRINT1). - Use combined clipping object everywhere to ensure drawing happens only in allowed rectangle, see arwinss

by Steven Edwards

On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote: > - Use combined clipping object everywhere to ensure drawing happens only in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox and other apps which would corrupt memory if trying to blit to area outside of DC. I keep seeing these comments, 'see arwinss nr. #'. Where do I go to look this up? 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

16 years, 1 month

2
1
0 0

Re: [ros-dev] [ros-diffs] [fireball] 42333: - Handle case when RosGdiSetDeviceClipping is being called without rects at all (with a respective DPRINT1). - Use combined clipping object everywhere to ensure drawing happens only in allowed rectangle, se

by Javier Agustìn Fernàndez Arroyo

http://www.reactos.org/wiki/Arwinss ? On Mon, Aug 3, 2009 at 12:26 AM, Steven Edwards <winehacker(a)gmail.com>wrote: > On Sun, Aug 2, 2009 at 6:32 AM, <fireball(a)svn.reactos.org> wrote: > > - Use combined clipping object everywhere to ensure drawing happens only > in allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox > and other apps which would corrupt memory if trying to blit to area outside > of DC. > > I keep seeing these comments, 'see arwinss nr. #'. Where do I go to > look this up? > > 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 > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

16 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 42305: Add a hack in KiSystemStartupReal function until Better Times.

by Aleksey Bragin

That function is not supposed to be called by old bootloader directly. Why is that needed? And why in this function? WBR, Aleksey Bragin. On Jul 30, 2009, at 9:54 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Thu Jul 30 19:54:01 2009 > New Revision: 42305 > > URL: http://svn.reactos.org/svn/reactos?rev=42305&view=rev > Log: > Add a hack in KiSystemStartupReal function until Better Times. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/kiinit.c > > Modified: trunk/reactos/ntoskrnl/ke/i386/kiinit.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/ > i386/kiinit.c?rev=42305&r1=42304&r2=42305&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/kiinit.c [iso-8859-1] Thu Jul 30 > 19:54:01 2009 > @@ -712,18 +712,34 @@ > Ke386SetDs(KGDT_R3_DATA | RPL_MASK); > Ke386SetEs(KGDT_R3_DATA | RPL_MASK); > > - /* Save NMI and double fault traps */ > - RtlCopyMemory(&NmiEntry, &Idt[2], sizeof(KIDTENTRY)); > - RtlCopyMemory(&DoubleFaultEntry, &Idt[8], sizeof(KIDTENTRY)); > - > - /* Copy kernel's trap handlers */ > - RtlCopyMemory(Idt, > - (PVOID)KiIdtDescriptor.Base, > - KiIdtDescriptor.Limit + 1); > - > - /* Restore NMI and double fault */ > - RtlCopyMemory(&Idt[2], &NmiEntry, sizeof(KIDTENTRY)); > - RtlCopyMemory(&Idt[8], &DoubleFaultEntry, sizeof(KIDTENTRY)); > + /* HACK compensates for KiRosPrepareForSystemStartup hack */ > + if ((ULONG)Idt == KiIdtDescriptor.Base) > + { > + USHORT FlippedSelector; > + > + FlippedSelector = KiIdt[2].Selector; > + KiIdt[2].Selector = KiIdt[2].ExtendedOffset; > + KiIdt[2].ExtendedOffset = FlippedSelector; > + > + FlippedSelector = KiIdt[8].Selector; > + KiIdt[8].Selector = KiIdt[8].ExtendedOffset; > + KiIdt[8].ExtendedOffset = FlippedSelector; > + } > + else > + { > + /* Save NMI and double fault traps */ > + RtlCopyMemory(&NmiEntry, &Idt[2], sizeof(KIDTENTRY)); > + RtlCopyMemory(&DoubleFaultEntry, &Idt[8], sizeof(KIDTENTRY)); > + > + /* Copy kernel's trap handlers */ > + RtlCopyMemory(Idt, > + (PVOID)KiIdtDescriptor.Base, > + KiIdtDescriptor.Limit + 1); > + > + /* Restore NMI and double fault */ > + RtlCopyMemory(&Idt[2], &NmiEntry, sizeof(KIDTENTRY)); > + RtlCopyMemory(&Idt[8], &DoubleFaultEntry, sizeof(KIDTENTRY)); > + } > > AppCpuInit: > /* Loop until we can release the freeze lock */ > >

16 years, 1 month

4
11
0 0

Re: [ros-dev] [ros-diffs] [gschneider] 42311: - Implement Floodfill: iterative four neighbors version - Details for this algorithm are described in the comments - Nice with the paint clone since the bucket fill tool works now

by Timo Kreuzer

1.) Why are you using global variables? 2.) Why are you using an XLATEOBJ inside the fill loop? gschneider(a)svn.reactos.org schrieb: > Author: gschneider > Date: Fri Jul 31 17:41:09 2009 > New Revision: 42311 > > URL: http://svn.reactos.org/svn/reactos?rev=42311&view=rev > Log: > - Implement Floodfill: iterative four neighbors version > - Details for this algorithm are described in the comments > - Nice with the paint clone since the bucket fill tool works now > > Added: > trunk/reactos/subsystems/win32/win32k/dib/floodfill.c (with props) > Modified: > trunk/reactos/subsystems/win32/win32k/dib/dib.h > trunk/reactos/subsystems/win32/win32k/objects/fillshap.c > trunk/reactos/subsystems/win32/win32k/win32k.rbuild > > Modified: trunk/reactos/subsystems/win32/win32k/dib/dib.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/di… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/dib/dib.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/dib/dib.h [iso-8859-1] Fri Jul 31 17:41:09 2009 > @@ -133,6 +133,7 @@ > BOOLEAN DIB_32BPP_AlphaBlend(SURFOBJ*, SURFOBJ*, RECTL*, RECTL*, CLIPOBJ*, XLATEOBJ*, BLENDOBJ*); > > BOOLEAN DIB_XXBPP_StretchBlt(SURFOBJ*,SURFOBJ*,SURFOBJ*,SURFOBJ*,RECTL*,RECTL*,POINTL*,BRUSHOBJ*,POINTL*,XLATEOBJ*,XLATEOBJ*,ROP4); > +BOOLEAN DIB_XXBPP_FloodFill(SURFOBJ*, BRUSHOBJ*, RECTL*, POINTL*, XLATEOBJ*, COLORREF, UINT); > > extern unsigned char notmask[2]; > extern unsigned char altnotmask[2]; > > Added: trunk/reactos/subsystems/win32/win32k/dib/floodfill.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/di… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/dib/floodfill.c (added) > +++ trunk/reactos/subsystems/win32/win32k/dib/floodfill.c [iso-8859-1] Fri Jul 31 17:41:09 2009 > @@ -1,0 +1,168 @@ > +/* > + * COPYRIGHT: See COPYING in the top level directory > + * PROJECT: ReactOS win32 subsystem > + * PURPOSE: Flood filling support > + * FILE: subsystems/win32/win32k/dib/floodfill.c > + * PROGRAMMER: Gregor Schneider, <grschneider AT gmail DOT com> > + */ > + > +#include <w32k.h> > + > +#define NDEBUG > +#include <debug.h> > + > +/* > +* This floodfill algorithm is an iterative four neighbors version. It works with an internal stack like data structure. > +* The stack is kept in an array, sized for the worst case scenario of having to add all pixels of the surface. > +* This avoids having to allocate and free memory blocks all the time. The stack grows from the end of the array towards the start. > +* All pixels are checked before being added, against belonging to the fill rule (FLOODFILLBORDER or FLOODFILLSURFACE) > +* and the position in respect to the clip region. This guarantees all pixels lying on the stack belong to the filled surface. > +* Further optimisations of the algorithm are possible. > +*/ > + > +/* Floodfil helper structures and functions */ > +typedef struct _floodItem > +{ > + ULONG x; > + ULONG y; > +} FLOODITEM; > + > +static ULONG floodLen = 0; > +static FLOODITEM *floodStart = NULL, *floodData = NULL; > + > +static __inline BOOL initFlood(RECTL *DstRect) > +{ > + ULONG width = DstRect->right - DstRect->left; > + ULONG height = DstRect->bottom - DstRect->top; > + floodData = ExAllocatePoolWithTag(NonPagedPool, width * height * sizeof(FLOODITEM), TAG_DIB); > + if (floodData == NULL) > + { > + return FALSE; > + } > + floodStart = (FLOODITEM*)((PBYTE)floodData + (width * height * sizeof(FLOODITEM))); > + return TRUE; > +} > +static __inline VOID finalizeFlood() > +{ > + ExFreePoolWithTag(floodData, TAG_DIB); > +} > +static __inline VOID addItemFlood(ULONG x, > + ULONG y, > + SURFOBJ *DstSurf, > + RECTL *DstRect, > + XLATEOBJ* ColorTranslation, > + COLORREF Color, > + BOOL isSurf) > +{ > + if (x >= DstRect->left && x <= DstRect->right && > + y >= DstRect->top && y <= DstRect->bottom) > + { > + if (isSurf == TRUE && XLATEOBJ_iXlate(ColorTranslation, > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_GetPixel(DstSurf, x, y)) != Color) > + { > + return; > + } > + else if (isSurf == FALSE && XLATEOBJ_iXlate(ColorTranslation, > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_GetPixel(DstSurf, x, y)) == Color) > + { > + return; > + } > + floodStart--; > + floodStart->x = x; > + floodStart->y = y; > + floodLen++; > + } > +} > +static __inline VOID removeItemFlood() > +{ > + floodStart++; > + floodLen--; > +} > +static __inline BOOL isEmptyFlood() > +{ > + if (floodLen == 0) > + { > + return TRUE; > + } > + return FALSE; > +} > + > +BOOLEAN DIB_XXBPP_FloodFill(SURFOBJ *DstSurf, > + BRUSHOBJ *Brush, > + RECTL *DstRect, > + POINTL *Origin, > + XLATEOBJ *ColorTranslation, > + COLORREF Color, > + UINT FillType) > +{ > + ULONG x, y; > + ULONG BrushColor; > + > + BrushColor = Brush->iSolidColor; > + x = Origin->x; > + y = Origin->y; > + > + if (FillType == FLOODFILLBORDER) > + { > + /* Check if the start pixel has the border color */ > + if (XLATEOBJ_iXlate(ColorTranslation, > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_GetPixel(DstSurf, x, y)) == Color) > + { > + return FALSE; > + } > + > + if (initFlood(DstRect) == FALSE) > + { > + return FALSE; > + } > + addItemFlood(x, y, DstSurf, DstRect, ColorTranslation, Color, FALSE); > + while (!isEmptyFlood()) > + { > + x = floodStart->x; > + y = floodStart->y; > + removeItemFlood(); > + > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_PutPixel(DstSurf, x, y, BrushColor); > + addItemFlood(x, y + 1, DstSurf, DstRect, ColorTranslation, Color, FALSE); > + addItemFlood(x, y - 1, DstSurf, DstRect, ColorTranslation, Color, FALSE); > + addItemFlood(x + 1, y, DstSurf, DstRect, ColorTranslation, Color, FALSE); > + addItemFlood(x - 1, y, DstSurf, DstRect, ColorTranslation, Color, FALSE); > + } > + finalizeFlood(); > + } > + else if (FillType == FLOODFILLSURFACE) > + { > + /* Check if the start pixel has the surface color */ > + if (XLATEOBJ_iXlate(ColorTranslation, > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_GetPixel(DstSurf, x, y)) != Color) > + { > + return FALSE; > + } > + > + if (initFlood(DstRect) == FALSE) > + { > + return FALSE; > + } > + addItemFlood(x, y, DstSurf, DstRect, ColorTranslation, Color, TRUE); > + while (!isEmptyFlood()) > + { > + x = floodStart->x; > + y = floodStart->y; > + removeItemFlood(); > + > + DibFunctionsForBitmapFormat[DstSurf->iBitmapFormat].DIB_PutPixel(DstSurf, x, y, BrushColor); > + addItemFlood(x, y + 1, DstSurf, DstRect, ColorTranslation, Color, TRUE); > + addItemFlood(x, y - 1, DstSurf, DstRect, ColorTranslation, Color, TRUE); > + addItemFlood(x + 1, y, DstSurf, DstRect, ColorTranslation, Color, TRUE); > + addItemFlood(x - 1, y, DstSurf, DstRect, ColorTranslation, Color, TRUE); > + > + } > + finalizeFlood(); > + } > + else > + { > + DPRINT1("Unsupported FloodFill type!\n"); > + return FALSE; > + } > + return TRUE; > +} > > Propchange: trunk/reactos/subsystems/win32/win32k/dib/floodfill.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/subsystems/win32/win32k/objects/fillshap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/fillshap.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/fillshap.c [iso-8859-1] Fri Jul 31 17:41:09 2009 > @@ -1072,12 +1072,11 @@ > PDC dc; > PDC_ATTR pdcattr; > SURFACE *psurf = NULL; > - PBRUSH pbrFill = NULL; > + HPALETTE Pal = 0; > + XLATEOBJ *XlateObj = NULL; > BOOL Ret = FALSE; > RECTL DestRect; > POINTL Pt; > - > - DPRINT1("FIXME: NtGdiExtFloodFill is UNIMPLEMENTED\n"); > > dc = DC_LockDc(hDC); > if (!dc) > @@ -1110,17 +1109,21 @@ > else > goto cleanup; > > - pbrFill = dc->dclevel.pbrFill; > - if (!pbrFill) > + psurf = dc->dclevel.pSurface; > + if (!psurf) > { > Ret = FALSE; > goto cleanup; > } > - psurf = dc->dclevel.pSurface; > - if (!psurf) > - { > - Ret = FALSE; > - goto cleanup; > + > + Pal = dc->dclevel.pSurface->hDIBPalette; > + if (!Pal) Pal = pPrimarySurface->DevInfo.hpalDefault; > + XlateObj = (XLATEOBJ*)IntEngCreateXlate(PAL_RGB, 0, NULL, Pal); > + > + if (XlateObj != NULL) > + { > + Ret = DIB_XXBPP_FloodFill(&psurf->SurfObj, &dc->eboFill.BrushObject, &DestRect, &Pt, XlateObj, Color, FillType); > + EngDeleteXlate(XlateObj); > } > > cleanup: > > Modified: trunk/reactos/subsystems/win32/win32k/win32k.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/wi… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/win32k.rbuild [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/win32k.rbuild [iso-8859-1] Fri Jul 31 17:41:09 2009 > @@ -31,6 +31,7 @@ > <file>dib32bpp.c</file> > <file>dibXXbpp.c</file> > <file>dib.c</file> > + <file>floodfill.c</file> > > <if property="ARCH" value="i386"> > <directory name="i386"> > > > >

16 years, 1 month

1
1
0 0

Introducing myself & a few questions

by John Jackson

Hello all. My name is John Jackson and I'm looking to start doing driver development on Reactos. I've worked as a C++ / C# programmer for about 7 years, and I want to get back into more hard-core C development. Driver writing appeals to me since it sounds like a real challenge. I've never programmed drivers before, but I've been reading up on it and looking at code. (Also, I don't mean any of my questions or wordings in a negative way, I'm not entirely sure how to phrase some of my questions) I'd like to start by working on USB support. I've taken a couple glances through svn, and I've got some questions. 1. Does the reactos build environment support Windows Driver Framework or just the Windows Driver model? 2. I see under /drivers/usb there is an nt4compat folder. I understand basic usb keyboard/mouse support comes from here, but it's not coded using the new driver models introduced in xp. Is anyone currently working on a "proper" usb implementation? I see there are several stubs in /drviers/usb/ that just return true. 3. I assume the place to start with usb support is bus drivers? Do usb1 and usb2 mean different bus drivers? (I've not read up much on usb yet, I'm still trying to wrap my head around driver development) I'll try to get on the irc channel either tomorrow or Sunday to say hi in person, but I think this is a good start for conversation. --John Jackson --taladon(a)gmail.com

16 years, 1 month

3
2
0 0

Arwinss architecture

by Aleksey Bragin

Hello, I will be thoroughly explaining the arwinss architecture, and the very first start is the general flow diagram which could be seen here: http://www.reactos.org/wiki/Arwinss_architecture This page will also get more updates with regard to architecture and design of all modules, but most attention will be paid to win32k.sys internals and native gdi/user driver (so-called winent.drv). With the best regards, Aleksey bragn.

16 years, 1 month

12
28
0 0

FullFAT replacement for Fastfat.sys

by James Walmsley

Hi Everyone, I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk). Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver. I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc. For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS? Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future. James -- James Walmsley ---------------------------------------- james(a)worm.me.uk

16 years, 1 month

17
27
0 0

Committing to trunk

by Aleksey Bragin

Hello, our debug buildslave is currently offline, I'd like to ask developers to abstain from committing to trunk till it comes back online (hopefully we can thing something up, have a spare buildslave, turn release buildslave into a debug one or something). Otherwise we may miss potential regressions. Thanks for understanding, Aleksey Bragin.

16 years, 1 month

1
1
0 0

[BUG] Utterly incorrect implementation of input device coordinates.

by codeforfood＠pulseforce.com

Here's the information required to patch the incorrect implementation. Abstract: - SendInput()/NtUserSendInput() broken: --- Relative hardware mouse input "working", but not well implemented due to lack of modifying the travel distance using cursor acceleration and movement speeds (I've provided info on this as well below), input-virtual vs screen-real coordinates (even in the relative moves), etc. The two coordinate spaces are not the same thing! --- Absolute hardware mouse input broken (used by things like touchscreens), by a complete misunderstanding of how the virtual input device coordinate space works (it's NOT in ANY way a 1:1 map that's translatable to the screen, but the function uses it this way everywhere!) read below for full info since this is the serious problem. - SetCursorPos() broken (should NOT be using SendInput() since that's pointless and ineffective and is meant for the hardware input queue, we already have the desired coordinates and should move the cursor directly; and even its use of SendInput() is incorrect since it should FIRST convert the desired SCREEN coordinates to absolute-INPUT-coordinate-space), BUT since it's using the broken SendInput() (which currently doesn't know that absolute input coordinates have NOTHING to do with screen coordinates) it works correctly and will place cursors at the right location. This will have to be changed when SendInput() is patched; preferrably to a direct cursor update (elaborated in the recap below, before the log), rather than the current indirect/slow approach which places a message in the serial (as in serial-processing, first-come-first-serve) mouse-input-translation queue. So to recap: - Need to improve relative movement (to handle acceleration and mouse speed modifiers) - Need to change the code everywhere where you've been thinking that input coordinates are the same as screen coordinates (most likely only within SetCursorPos(), and SendInput()/NtUserSendInput()) - Absolute cursor placement inside SendInput() needs to be rewritten to convert absolute input-space coordinates to absolute screen-space coordinates (quite an easy change) using the algorithm I provide below, which is what Windows uses internally. - SetCursorPos() needs to COMPLETELY stop using SendInput() and instead manipulate the cursor X/Y struct directly, or equivalent methods, instead of injecting itself into the input queue. Alternatively, if it keeps using the input queue, it needs a reverse-algorithm to turn the desired screen-coordinates into virtual inputspace-coordinates, such as int mouseinput_abs_x_or_y_pos = (((65536 * screen_x_or_y_pos) / screen_width_or_height) + 1). The +1 is necessary for proper rounding. However, I see no reason to use the input queue within this function as that involves much more work than simply writing the cursor's location directly (which is what SendInput EVENTUALLY gets around to doing after LOTS of processing, and saving on cycles/jumps/calls is GOOD ;)). All details on how to fix these things are in the below log. Let me know if there's any questions. Log (most unrelated discussions/events snipped and long breaks between explaining different details have been separated with "..."): 19:56 Yewbacca . I am sure you've implemented SetCursorPos() incorrectly. Checking your source code for it at cursor.c:280. This function is SUPPOSED to take a SCREEN X/Y coordinate (ie X=1400, Y=800 on a 1440x900 screen, and then moves the cursor location directly, without emulating mouse movement. 19:57 Yewbacca . Instead, your version calls SendInput() with the x/y unmodified, that's awful. SendInput()'s absolute space is a virtual desktop square that stretches from 0-65535 in each direction and will not even be remotely close to what the intended destination is. 19:57 _0_ . sounds like a patch is in order Yewbacca 19:57 _0_ . :P 19:58 +encoded . Yewbacca, file bug report! 19:58 Yewbacca . _0_ Well I'd have to know how you're writing the cursor position inside NtSendUserInput etc. 19:58 Yewbacca . Or file a bug report, I'll do that. 20:01 Yewbacca . Related to this, Windows actually uses a slightly unexpected algorithm for its SendInput() absolute-mode coordinates-to-screen conversion. 20:01 Yewbacca . int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:01 Yewbacca . If you want pixel precise SendInput() that works as on windows you'd have to verify this. I'll bug report that too. 20:02 +encoded . <3 Yewbacca 20:02 Yewbacca . :) 20:02 +encoded . you can ofcourse see the source code of NtSendUserInput 20:03 Yewbacca . Yeah I was about to check that to make sure it's not already correct 20:04 +encoded . its in \subsystems\win32\win32k\ntuser\input.c 20:04 Yewbacca . Ah thanks, that saves a slow grep. 20:05 +encoded . wait opps 20:05 . garrythefish_ [n=fisher@unaffiliated/garrythefish] has joined #reactos 20:05 +encoded . oh well, nvm me 20:05 garrythefish_ . community choice award today. hope you guys win. :D 20:10 Yewbacca . Okay after brief confusion I noticed that IntMouseInput() contains the actual logic for mouse-type input to SendInput(), input.c:1081. Time to check it. ... 20:14 Yewbacca . Okay now I'm really confused. I read through IntMouseInput() from input.c:1081-1333 and unless I missed a call to a driver-coordinates-to-screen-coordinates somewhere, this function is miscoded as well. That'd mean that SetCursorPos() would work correctly since SendInput() would work incorrectly, and that normal SendInput() calls that expect a 0 to 65535 range would not work at all. 20:15 Yewbacca . It really seems to directly write the pointers for cursor X and Y with the values it has received 20:15 Yewbacca . with no conversion whatsoever 20:15 Yewbacca . even though the incoming values are in a 0 to 65535 range 20:15 Yewbacca . of that virtual space ... 20:16 Yewbacca . Basically for anyone unfamiliar with it, the driver implements a virtual space for the cursor to either move relatively within, or absolutely, to allow things like touchscreens to function easily (they'd just have to SendInput() their current position as a percentage of the 65535 range). 20:16 Yewbacca . So all incoming absolute-mode coordinates must be converted to screen coordinates, and microsoft does it with int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:17 Yewbacca . I'm going to re-read it again to see if I missed some conversion call. If not, that'll be 2 reports. Quite easy fixes luckily. 20:18 +encoded . <3 Yewbacca 20:18 Yewbacca . I think the reason you got by this far is because the HARDWARE mouse sends coordinates relatively 20:18 Yewbacca . The problem'd only appear with absolute input like touchscreens. And since SendInput()'s absolute mode is broken that means program's SetCursorPos() would work, so it's doubly broken and would only cause problems for absolute hardware-input (again, touchscreens mainly). 20:18 Yewbacca . :P 20:19 Yewbacca . Reading again 20:20 +encoded . Yewbacca, we can use someone like you who has knowledge of windows internals 20:20 Yewbacca . Maybe, right now I'm tied up with some major work :) ... 20:28 Yewbacca . Alright I've finished checking everything. IntMouseInput() stretches from input.c:1081-1333 and is the function that's called when NtUserSendInput()/SendInput() receives a mouse-type event. At line 1140 it grabs the pointer to the cursor's X/Y struct with IntGetCursorLocation(WinSta, &MousePos). Then we get to the significant errors. 20:29 Yewbacca . At lines 1146-1150 it incorrectly writes the virtual x/y of the INPUT coordinate system right into the memory holding the SCREEN x/y cursor location 20:30 Yewbacca . At lines 1151-1155 it handles relative movement but doesn't take into account cursor acceleration and movement speed (those settings we all love in the control panel->mouse), which in turn can increase the movement distance as much as 4 times the input value. 20:31 Yewbacca . Those two behaviours right there would need to be patched. The first should determine the destination on the screen through int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536. The latter should implement handling for cursor acceleration (check MSDN, it describes acceleration on SendInput()). 20:32 Yewbacca . And lastly, SetCursorPos() (forgot which file it's in) needs to *completely* skip the SendInput() baloney that it's doing right now (http://pastebin.com/d2db76985) and just directly grab the cursor X/Y pointer and update it in a simple assignment, AFTER checking that it's in range of course (otherwise clamping it to the screen). 20:33 +Lone_Rifle . Yewbacca, suggest that you subscribe to ros-dev and retype or copy-paste your findings there, it's quite a bit of text to go through in one sitting 20:33 Yewbacca . Oh yeah and if you wanna be 100% complete, also implement a check for ClipCursor() and don't allow the cursor to move outside that, no matter if it's from hardware input or SetCursorPos(). If it's outside, it should be clamped to the nearest inside value. 20:34 Yewbacca . Lone_Rifle Yeah, I agree and was going to submit it. I'll do that now. ... 20:37 Yewbacca . Acceleration is described at http://msdn.microsoft.com/en-us/library/ms646273(VS.85).aspx (info for the MOUSEINPUT struct). I'll submit this log to the mailing list. =EOF=

16 years, 1 month

2
1
0 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