Ros-dev

ros-dev@reactos.org

5791 discussions

Re: [ros-dev] [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details.
by Ged 13 Mar '09

13 Mar '09

Looking at the patch only this looks wrong to me. Assuming this is radio button it should use the marlett font. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 04 March 2009 16:30 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details. Author: mkupfer Date: Wed Mar 4 19:29:57 2009 New Revision: 39871 URL: http://svn.reactos.org/svn/reactos?rev=39871&view=rev Log: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details. Modified: trunk/reactos/dll/win32/user32/windows/draw.c Modified: trunk/reactos/dll/win32/user32/windows/draw.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/d… ============================================================================== --- trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] Wed Mar 4 19:29:57 2009 @@ -1276,11 +1276,12 @@ yc = myr.top + SmallDiam - SmallDiam/2; i = 234*SmallDiam/750; i = i < 1 ? 1 : i; - myr.left = xc - i+i/2; + myr.left = xc - i/2; myr.right = xc + i/2; - myr.top = yc - i+i/2; + myr.top = yc - i/2; myr.bottom = yc + i/2; - Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye, xe, ye); + // if the start and the end point are equal, Pie() only draws a single line, so start one pixel lower + Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye+1, xe, ye); break; case DFCS_MENUCHECK:

4 3

Re: [ros-dev] [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests.
by Ged 13 Mar '09

13 Mar '09

It's not UserDrawIconEx which is hacky, it's just the code you added for detecting alpha pixels Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 13 March 2009 00:21 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests. Author: mkupfer Date: Fri Mar 13 03:20:48 2009 New Revision: 39997 URL: http://svn.reactos.org/svn/reactos?rev=39997&view=rev Log: - Add a hackfix comment for issue #4243 due to several requests. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 03:20:48 2009 @@ -1389,6 +1389,7 @@ } +/* FIXME: ReactOS specific hack */ BOOL UserDrawIconEx( HDC hDc,

1 0

Re: [ros-dev] [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details.
by Ged 13 Mar '09

13 Mar '09

This looks hacky -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 12 March 2009 21:26 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Author: mkupfer Date: Fri Mar 13 00:25:49 2009 New Revision: 39989 URL: http://svn.reactos.org/svn/reactos?rev=39989&view=rev Log: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 00:25:49 2009 @@ -1389,82 +1389,6 @@ } -#define STRETCH_CAN_SRCCOPY_ONLY - -#ifdef STRETCH_CAN_SRCCOPY_ONLY -void -FASTCALL -DoStretchBlt(HDC DcDest, int XDest, int YDest, int WidthDest, int HeightDest, - HDC DcSrc, int XSrc, int YSrc, int WidthSrc, int HeightSrc, - DWORD Rop3, BOOL Color) -{ - HDC DcStretched; - HBITMAP BitmapStretched; - HBITMAP OldBitmap; - - if (WidthDest == WidthSrc && HeightDest == HeightSrc) - { - NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, Rop3, 0, 0); - } - else if (SRCCOPY == Rop3) - { - NtGdiStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - Rop3, 0); - } - else - { - DcStretched = NtGdiCreateCompatibleDC(DcSrc); - if (NULL == DcStretched) - { - DPRINT1("Failed to create compatible DC\n"); - return; - } - if (Color) - { - BitmapStretched = NtGdiCreateCompatibleBitmap(DcDest, WidthDest, - HeightDest); - } - else - { - BitmapStretched = IntGdiCreateBitmap(WidthDest, HeightDest, 1, 1, NULL); - } - if (NULL == BitmapStretched) - { - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - OldBitmap = NtGdiSelectBitmap(DcStretched, BitmapStretched); - if (NULL == OldBitmap) - { - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - if (! NtGdiStretchBlt(DcStretched, 0, 0, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - SRCCOPY, 0) || - ! NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcStretched, 0, 0, Rop3, 0, 0)) - { - DPRINT1("Failed to blt\n"); - } - NtGdiSelectBitmap(DcStretched, OldBitmap); - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - } -} -#else -#define DoStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, \ - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, Rop3, Color) \ - NtGdiStretchBlt((DcDest), (XDest), (YDest), (WidthDest), (HeightDest), \ - (DcSrc), (XSrc), (YSrc), (WidthSrc), (HeightSrc), \ - (Rop3), 0) -#endif /* STRETCH_CAN_SRCCOPY_ONLY */ - BOOL UserDrawIconEx( HDC hDc, @@ -1482,7 +1406,6 @@ BITMAP bmpMask, bmpColor; COLORREF oldFg, oldBg; BOOL DoFlickerFree; - INT nStretchMode; SIZE IconSize; HDC hdcOff; @@ -1524,7 +1447,31 @@ when cxWidth or cyHeight is 0 */ if ((bmpColor.bmBitsPixel == 32) && (cxWidth != 0) && (cyHeight != 0)) { - bAlpha = TRUE; + SURFACE *psurfOff = NULL; + PFN_DIB_GetPixel fnSource_GetPixel = NULL; + INT x, y; + + //Find alpha into icon + psurfOff = SURFACE_LockSurface(hbmColor ? hbmColor : hbmMask); + if (psurfOff) + { + fnSource_GetPixel = DibFunctionsForBitmapFormat[psurfOff->SurfObj.iBitmapFormat].DIB_GetPixel; + if (fnSource_GetPixel) + { + for (x = 0; x < psurfOff->SurfObj.sizlBitmap.cx; x++) + { + for (y = 0; y < psurfOff->SurfObj.sizlBitmap.cy; y++) + { + bAlpha = ((BYTE)(fnSource_GetPixel(&psurfOff->SurfObj, x, y) >> 24) & 0xff); + if (bAlpha) + break; + } + if (bAlpha) + break; + } + } + SURFACE_UnlockSurface(psurfOff); + } } if (!diFlags) @@ -1608,8 +1555,6 @@ goto cleanup; } - nStretchMode = IntGdiSetStretchBltMode(hdcOff, STRETCH_DELETESCANS); - oldFg = IntGdiSetTextColor(hdcOff, RGB(0, 0, 0)); oldBg = IntGdiSetBkColor(hdcOff, RGB(255, 255, 255)); @@ -1622,7 +1567,7 @@ goto cleanup; } - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1633,7 +1578,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_IMAGE) ? SRCAND : SRCCOPY), - FALSE); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1642,7 +1587,7 @@ { hOldMem = NtGdiSelectBitmap(hdcMem, (hbmColor ? hbmColor : hbmMask)); - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1653,7 +1598,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_MASK) ? SRCINVERT : SRCCOPY), - NULL != hbmColor); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1729,7 +1674,6 @@ IntGdiSetTextColor(hdcOff, oldFg); IntGdiSetBkColor(hdcOff, oldBg); - IntGdiSetStretchBltMode(hdcOff, nStretchMode); Ret = TRUE;

2 1

Re: [ros-dev] rosapps
by WaxDragon 12 Mar '09

12 Mar '09

The only things I have habitually used in rosapps are ctm, ncftp, and download. I'd hate to see these go away. OTOH, there are quite a few things that l would consider "tests" in rosapps that could be moved. I think the argument that rosapps to long to build is crap. If you want to reduce the build time, ditch explorer. On Mar 12, 2009 11:02 AM, "Ged" <gedmurphy(a)gmail.com> wrote: I prefer this idea. I'd like to see rosapps removed completely and have all non essential stuff in trunk built via an rbuild variable (turned off by default) Ged. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto: ros-dev-bounces(a)reactos.org] ... Behalf Of Thomas Bluemel Sent: 12 March 2009 14:17 To: ReactOS Development List Subject: Re: [ros-de...

2 1

Restructuring ReactOS
by Richard Campbell 10 Mar '09

10 Mar '09

Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

6 7

Restructuring ReactOS...
by Richard Campbell 10 Mar '09

10 Mar '09

Restructuring ReactOS Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

1 0

10 Mar '09

Hi, Qemu w Head: (subsystems/win32/win32k/ntuser/desktop.c:612) RtlQueryRegistryValues failed for PaintDesktopVersion (c0000034) err:(base/system/winlogon/screensaver.c:86) ImpersonateLoggedOnUser() failed with error 5 (ntoskrnl/se/semgr.c:613) Denying access for caller: granted 0x600e8, desired 0xf01ff (generic mapping 80F290E8) Assertion 'PointerPte->u.Hard.Valid == 0' failed at ntoskrnl/mm/hypermap.c line 100 Entered debugger on embedded INT3 at 0x0008:0x808c1e7e. kdb:> bt Eip: <NTOSKRNL.EXE:c1e7f> Frames: <NTOSKRNL.EXE:7c608> <NTOSKRNL.EXE:7615f> On Tue, Mar 10, 2009 at 4:53 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Boot is broken for me in VMWare, with an assert being hit in > hypermap.c:178. > > > WBR, > Aleksey Bragin. >

1 0

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 39925: - Implement a new Hyperspace Mapping Interface: - The new interface is portable and much faster than before. For example, unmapping a hyperpage is almost a one-line operation. - The new interface is also thread-safe and uses the EPROCESS hyperspace spinlock. - However, in order to isolate from React Mm internals, the Hyper IRQL and Process are stored as globals, so this will not work on SMP. - For now, mapping vs. zero PTEs are not treated differently, but
by Aleksey Bragin 10 Mar '09

10 Mar '09

Boot is broken for me in VMWare, with an assert being hit in hypermap.c:178. WBR, Aleksey Bragin. On Mar 10, 2009, at 3:31 AM, ros-arm-bringup(a)svn.reactos.org wrote: > Author: ros-arm-bringup > Date: Tue Mar 10 03:31:14 2009 > New Revision: 39925 > > URL: http://svn.reactos.org/svn/reactos?rev=39925&view=rev > Log: > - Implement a new Hyperspace Mapping Interface: > - The new interface is portable and much faster than before. > For example, unmapping a hyperpage is almost a one-line operation. > - The new interface is also thread-safe and uses the EPROCESS > hyperspace spinlock. > - However, in order to isolate from React Mm internals, the > Hyper IRQL and Process are stored as globals, so this will not work > on SMP. > - For now, mapping vs. zero PTEs are not treated differently, > but the two interfaces have been separated pending future work. > - Performance tests with _rdtsc resulted in an improvement of > over 300% compared to the old interface. > - Hyperspace mappings are frequent, so the improvement is > noticeable during startup (3/10ths of a second). > - This also fixes incorrect initializtion of hyperspace -- > pages were zeroed out (which requires hyperspace) before hyperspace > was created.

1 0

Symbols...
by Timo Kreuzer 10 Mar '09

10 Mar '09

Hi, Can someone please enable symbols for sysreg. Thanks, Timo

1 0

Undocumented field in PEB?
by Jun Koi 06 Mar '09

06 Mar '09

Hi, I notice that in Windows Vista - and also Windows XP - there seems to be an undocumented field in PEB. >From Windbg, I found some below fields in PEB structure' ... +0x064 NumberOfProcessors : Uint4B +0x068 NtGlobalFlag : Uint4B +0x070 CriticalSectionTimeout : _LARGE_INTEGER ... We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field. So the next field should be at 0x6C. However, CriticalSectionTimeout is at 0x70. - So the question is why that happens? I suspect that there is an undocumented field after NtGlobalFlag, which is removed from the debugging data. Any idea? - Another thing: ReactOS now faithfully declares the PEB structure like above, without that secret 4 bytes hole. As a result, the ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do we need to care about that? Or not? Thanks, J

4 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev