Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] [ros-diffs] [sir_richard] 48475: [KERNEL32]: While working on the CMAKE branch, Amine and myself discovered a rather serious issue in kernel32 (and perhaps other libraries as well). Unlike rbuild, CMake does not allow you to export non-existant DLL functions (try it: add "poopyhead" in kernel32's exports under RBuild, and will it export "poopyhead", God knowing what that will actually link to). As an additional feature on top of the "allow non-existing functions to be exported" "feature", beca

by Aleksey Bragin

I have a couple of questions/suggestions. Even if it was a mistake to commit it to trunk, I still express my opinion because I think it's important for the changes to stay in trunk. 1. Channel-based system is preferred to the plain NDEBUG/DPRINT one. Kernel32 should not really be an exception. If there is something wrong, it's better to put some more time into it and fix the actual problem in that debug library. Everyone who ever tried to debug any usermode app in ROS, would understand. 2. .pspec file was also invented as a consistent way to be compatible with different compilers. Winebuild generates stubs for entries marked as "stub", so it's quite controllable. 3. Everything else is great, nice to see that mess being finally cleaned up. WBR, Aleksey Bragin. On Aug 7, 2010, at 9:02 AM, sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Sat Aug 7 05:02:58 2010 > New Revision: 48475 > > URL: http://svn.reactos.org/svn/reactos?rev=48475&view=rev > Log: > [KERNEL32]: While working on the CMAKE branch...

14 years, 9 months

Re: [ros-dev] [ros-diffs] [jgardou] 48465: [WIN32K] - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test)

by Timo Kreuzer

Hi, Please take care about proper protection of the user mode buffer. The current solution: probe and forget is not safe. Possibilities are: 1) SEH protected copying of the buffer, pass the copy of the buffer to lower level functions -> Easy to do, large overhead for large bitmaps. 2) SEH protected call to a lower level function, passing the user mode buffer. -> Not possible if the lower level function is either allocating any resources (unless also protected by SEH + finally) or can pass execution to 3rd party provided code, like drivers. 3) Be sure to have SEH at the lowest level (DIB) -> Not possible as the function might end up in a driver. 4) Use Mm to protect the buffer. Either with MmSecureVirtualMemory or double mapping using MmProbeAndLockPages + MmGetSystemAddressForMdlSafe. I think 4 is the way to go. While the overhead of remapping should be relatively small compared to a full copy, we are still wasting large ammounts of system address space. MmSecureVirtualMemory might at first sound like a good solution, but beware, it has some pitfalls. While it protects a memory range from being freed, it doesn't protect it from being paged out. That wouldn't be a problem, unless the memory is not backed by the page file, but let say a network resource, which becomes unavailable after a page was paged out. In this case we would get an in page error when trying to access the page, leading to a kernel crash. So unless we can be sure that the memory is backed by the page file, we need to additionally lock the pages into memory to be safe. Final thing to note is that MmSecureVirtualMemory is not implemented yet, but I hope with current work on the VAD code, we'll soon get a present (hint). Regards, Timo jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Thu Aug 5 21:12:57 2010 > New Revision: 48465 > > URL: http://svn.reactos.org/svn/reactos?rev=48465&view=rev > Log: > [WIN32K] > - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test) > > Modified: > branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > > Modified: branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c > URL: http://svn.reactos.org/svn/reactos/branches/reactos-yarotows/subsystems/win… > ============================================================================== > --- branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] (original) > +++ branches/reactos-yarotows/subsystems/win32/win32k/objects/dibobj.c [iso-8859-1] Thu Aug 5 21:12:57 2010 > @@ -290,7 +290,7 @@ > > if(!(psurfSrc && psurfDst)) > { > - DPRINT1("Error, could not lock surfaces.\n"); > + DPRINT1("Error, could not lock surfaces\n"); > goto cleanup; > } > > @@ -663,15 +663,15 @@ > if(pbmci) > { > pbmci->bmciHeader.bcWidth = psurf->SurfObj.sizlBitmap.cx; > - pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + pbmci->bmciHeader.bcHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy; > pbmci->bmciHeader.bcPlanes = 1; > pbmci->bmciHeader.bcBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > } > Info->bmiHeader.biWidth = psurf->SurfObj.sizlBitmap.cx; > - Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > + Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > + -psurf->SurfObj.sizlBitmap.cy : > psurf->SurfObj.sizlBitmap.cy;; > Info->bmiHeader.biPlanes = 1; > Info->bmiHeader.biBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > @@ -711,15 +711,15 @@ > case 8: > Info->bmiHeader.biClrUsed = 0; > > - /* If the bitmap if a DIB section and has the same format than what > + /* If the bitmap if a DIB section and has the same format than what > * we're asked, go ahead! */ > - if((psurf->hSecure) && > + if((psurf->hSecure) && > (BitsPerFormat(psurf->SurfObj.iBitmapFormat) == bpp)) > { > if(Usage == DIB_RGB_COLORS) > { > unsigned int colors = min(psurf->ppal->NumColors, 1 << bpp); > - > + > if(pbmci) > { > for(i=0; i < colors; i++) > @@ -773,7 +773,7 @@ > rgbTriples[i].rgbtGreen = pDcPal->IndexedColors[i].peGreen; > rgbTriples[i].rgbtBlue = pDcPal->IndexedColors[i].peBlue; > } > - > + > rgbQuads[i].rgbRed = pDcPal->IndexedColors[i].peRed; > rgbQuads[i].rgbGreen = pDcPal->IndexedColors[i].peGreen; > rgbQuads[i].rgbBlue = pDcPal->IndexedColors[i].peBlue; > @@ -822,7 +822,7 @@ > { > for(g = 0; g <= 5; g++) > { > - for(b = 0; b <= 5; b++) > + for(b = 0; b <= 5; b++) > { > colorTriple->rgbtRed = (r * 0xff) / 5; > colorTriple->rgbtGreen = (g * 0xff) / 5; > @@ -935,7 +935,7 @@ > /* Restore them */ > Info->bmiHeader.biWidth = width; > Info->bmiHeader.biHeight = height; > - > + > if(!hBmpDest) > { > DPRINT1("Unable to create a DIB Section!\n"); > @@ -972,7 +972,7 @@ > _SEH2_TRY > { > RtlCopyMemory(Bits, pDIBits, DIB_GetDIBImageBytes (width, height, bpp)); > - } > + } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > Status = _SEH2_GetExceptionCode(); > @@ -1021,95 +1021,104 @@ > UINT cjMaxBits, > HANDLE hcmXform) > { > - HBITMAP hBitmap, hOldBitmap = NULL; > - HDC hdcMem = NULL; > + PDC pdc; > + INT ret = 0; > + LONG height; > + LONG width; > + WORD planes, bpp; > + DWORD compr, size; > + HBITMAP hBitmap; > + BOOL fastpath = FALSE; > NTSTATUS Status = STATUS_SUCCESS; > - PVOID pvDIBits; > - INT Ret = 0; > + > > if (!Bits || !BitsInfo) > - { > - SetLastWin32Error(ERROR_INVALID_PARAMETER); > return 0; > - } > - > - /* Create a DIB Section, data will be probed there */ > - hBitmap = NtGdiCreateDIBSection(hDC, > - NULL, > - 0, > - BitsInfo, > - Usage, > - 0, > - 0, > - 0, > - &pvDIBits); > - > - if(!hBitmap) > - { > - DPRINT1("Failed to create a DIB.\n"); > - return 0; > - } > - > - /* Set bits */ > - _SEH2_TRY > - { > - ProbeForRead(Bits, cjMaxBits, 1); > - RtlCopyMemory(pvDIBits, Bits, DIB_GetDIBImageBytes(BitsInfo->bmiHeader.biWidth, > - BitsInfo->bmiHeader.biHeight, > - BitsInfo->bmiHeader.biBitCount)); > - } > - _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > - { > - Status = _SEH2_GetExceptionCode(); > - } > - _SEH2_END > - > - if(!NT_SUCCESS(Status)) > - { > - DPRINT1("Error : Could not read DIB bits\n"); > - SetLastNtError(Status); > - goto cleanup; > - } > - > - hdcMem = NtGdiCreateCompatibleDC(0); > - if(!hdcMem) > - { > - DPRINT1("Failed to create a memory DC!"); > - goto cleanup; > - } > - > - hOldBitmap = NtGdiSelectBitmap(hdcMem, hBitmap); > - if(!hOldBitmap) > - { > - DPRINT1("Could not select the DIB into the memory DC\n"); > - goto cleanup; > - } > - > - /* Do we want to stretch ? */ > - if((SrcWidth == DestWidth) && (SrcHeight == DestHeight)) > - { > - Ret = NtGdiBitBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, ROP, 0, 0); > - } > - else > - { > - Ret = NtGdiStretchBlt(hDC, XDest, YDest, XDest + DestWidth, YDest + DestHeight, > - hdcMem, XSrc, YSrc, XSrc + SrcWidth, YSrc + SrcHeight, > - ROP, 0); > - } > - > - if(Ret) > - Ret = SrcHeight ; > - > + > + if (!(pdc = DC_LockDc(hDC))) return 0; > + > + > + _SEH2_TRY > + { > + ProbeForRead(BitsInfo, cjMaxInfo, 1); > + ProbeForRead(Bits, cjMaxBits, 1); > + if (DIB_GetBitmapInfo( &BitsInfo->bmiHeader, &width, &height, &planes, &bpp, &compr, &size ) == -1) > + { > + DPRINT1("Invalid bitmap\n"); > + Status = STATUS_INVALID_PARAMETER; > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END > + > + if(!NT_SUCCESS(Status)) > + { > + DPRINT1("Error, failed to read the DIB bits\n"); > + goto cleanup; > + } > + > + if (width < 0) > + { > + DPRINT1("Bitmap has a negative width\n"); > + return 0; > + } > + > + hBitmap = NtGdiGetDCObject(hDC, OBJ_BITMAP); > + > + if (XDest == 0 && YDest == 0 && XSrc == 0 && XSrc == 0 && > + DestWidth == SrcWidth && DestHeight == SrcHeight && > + compr == BI_RGB && > + ROP == SRCCOPY) > + { > + BITMAP bmp; > + if (IntGdiGetObject(hBitmap, sizeof(bmp), &bmp) == sizeof(bmp)) > + { > + if (bmp.bmBitsPixel == bpp && > + bmp.bmWidth == SrcWidth && > + bmp.bmHeight == SrcHeight && > + bmp.bmPlanes == planes) > + fastpath = TRUE; > + } > + } > + > + if (fastpath) > + { > + /* fast path */ > + DPRINT1("using fast path\n"); > + ret = IntSetDIBits( pdc, hBitmap, 0, height, Bits, BitsInfo, Usage); > + } > + else > + { > + /* slow path - need to use StretchBlt */ > + HBITMAP hOldBitmap; > + HPALETTE hpal = NULL; > + HDC hdcMem; > + PVOID pvBits; > + > + hdcMem = NtGdiCreateCompatibleDC( hDC ); > + hBitmap = DIB_CreateDIBSection(pdc, BitsInfo, Usage, &pvBits, NULL, 0, 0); > + RtlCopyMemory(pvBits, Bits, cjMaxBits); > + hOldBitmap = NtGdiSelectBitmap( hdcMem, hBitmap ); > + > + /* Origin for DIBitmap may be bottom left (positive biHeight) or top > + left (negative biHeight) */ > + ret = NtGdiStretchBlt( hDC, XDest, YDest, DestWidth, DestHeight, > + hdcMem, XSrc, abs(height) - SrcHeight - YSrc, > + SrcWidth, SrcHeight, ROP, 0 ); > + if(hpal) > + GdiSelectPalette(hdcMem, hpal, FALSE); > + if(ret) > + ret = SrcHeight; > + NtGdiSelectBitmap( hdcMem, hOldBitmap ); > + NtGdiDeleteObjectApp( hdcMem ); > + GreDeleteObject( hBitmap ); > + } > cleanup: > - if(hdcMem) > - { > - if(hOldBitmap) NtGdiSelectBitmap(hdcMem, hOldBitmap); > - NtGdiDeleteObjectApp(hdcMem); > - } > - GreDeleteObject(hBitmap); > - > - return Ret; > + DC_UnlockDc(pdc); > + return ret; > } > > > @@ -1462,7 +1471,7 @@ > hpal = (HPALETTE) 0xFFFFFFFF; > } > } > - else > + else > { > hpal = BuildDIBPalette(bmi); > } > @@ -1563,7 +1572,7 @@ > * Get the info from a bitmap header. > * Return 0 for COREHEADER, 1 for INFOHEADER, -1 for error. > */ > -int > +int > FASTCALL > DIB_GetBitmapInfo( const BITMAPINFOHEADER *header, LONG *width, > LONG *height, WORD *planes, WORD *bpp, DWORD *compr, DWORD *size ) > @@ -1575,7 +1584,7 @@ > *height = core->bcHeight; > *planes = core->bcPlanes; > *bpp = core->bcBitCount; > - *compr = 0; > + *compr = BI_RGB; > *size = 0; > return 0; > } > @@ -1692,10 +1701,10 @@ > ppalEntries[i].peBlue = 0; > ppalEntries[i].peFlags = 0; > } > - > + > lpIndex++; > } > - > + > hpal = PALETTE_AllocPalette(PAL_INDEXED, nNumColors, (ULONG*)ppalEntries, 0, 0, 0); > > ExFreePoolWithTag(ppalEntries, TAG_COLORMAP); > > > >

14 years, 9 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 48461: [NTOSKRNL] - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions - Fix formatting - Patch by Pierre Schweitzer - Fixes everything See issue #5541 for more details.

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Aug 5 12:23:23 2010 > New Revision: 48461 > > URL: http://svn.reactos.org/svn/reactos?rev=48461&view=rev > Log: > [NTOSKRNL] > - Fixed FsRtlIsNameInExpression to make it properly handle * in expressions > - Fix formatting > - Patch by Pierre Schweitzer > - Fixes everything Could you add a test for this to one of our (Winetest-compatible) kernel-mode testing frameworks, so that nobody breaks this again? I know that we haven't decided on a radical test-based development approach yet, but it would certainly be helpful to avoid long trunk locks in the future. Cheers, Colin

14 years, 9 months

by Ged Murphy

14 years, 9 months

Trunk locked

by Aleksey Bragin

Hi, trunk is locked due to reaching critical level of regressions again. Currently the following people have write access: tkreuzer, sir_richard, fireball. If you would like to be on bugfix-committers team, please drop me a line. WBR, Aleksey Bragin.

14 years, 9 months

[ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BITMAPCOREINFO->

by James Tabor

Hi! BitmapCoreInfo !Should Be! handled in Gdi32 and converted there! The latest BitmapInfo "must be" handled in win32k. So not get it confused. James

14 years, 9 months

Re: [ros-dev] [ros-diffs] [fireball] 48380: - Fix incorrect function definitions. To be submitted upstream.

by Timo Kreuzer

fireball(a)svn.reactos.org schrieb: > - Fix incorrect function definitions. To be submitted upstream. > > I remember just recently joking about all our "Needs to be ...", "Someone should ...", "Please someone ..." commit messages, which usually mean "I'm too lazy to ..." and result in things never being done ;-) Timo

14 years, 9 months

Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.

by Ged Murphy

This may be a good time to restructure the tree? http://www.reactos.org/wiki/Techwiki:File_Layout <http://www.reactos.org/wiki/Techwiki:File_Layout> This will make ros much more modular and allow things like minwin to be built. Ged. On 24 July 2010 19:52, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sat Jul 24 18:52:44 2010 > New Revision: 48236 > > URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev > Log: > Create a branch for cmake bringup. > > Added: > branches/cmake-bringup/ (props changed) > - copied from r48235, trunk/reactos/ > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- bugtraq:logregex (added) > +++ bugtraq:logregex Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,2 @@ > +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? > +(\d+) > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:message = See issue #%BUGID% for more details. > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID% > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:ignore (added) > +++ svn:ignore Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,14 @@ > +*.iso > +makefile.auto > +makefile-*.auto > +config-*.rbuild > +obj-* > +output-* > +reactos > +reactos.* > +RosBE-Logs > +*.sln > +*.ncb > +*.suo > +versionreport.xml > +config.rbuild > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > --- svn:mergeinfo (added) > +++ svn:mergeinfo Sat Jul 24 18:52:44 2010 > @@ -1,0 +1,4 @@ > +/branches/header-work:45691-47721 > +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064 > +/branches/ros-amd64-bringup:36852 > > +/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882 > > Propchange: branches/cmake-bringup/ > > ------------------------------------------------------------------------------ > tsvn:logminsize = 10 > > >

14 years, 9 months

Re: [ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BI

by James Tabor

Hi! 2010/7/30 Jérôme Gardou <jerome.gardou(a)laposte.net>: > That's why I began to revert all of this stuff, which is horrible :-) > Regards. > Jérôme. > Oh! That is great news! Good work! James

14 years, 9 months

Rose server will be down for hardware maintenance

by Colin Finck

Hi all, After ongoing sudden crashes on our third server Rose (currently only serving the BuildBot and primary DNS), I highly suspect a hardware failure. This is why I'll let the hosting provider conduct a hardware stress test tomorrow and eventually replace broken parts. So don't be surprised if these services are down tomorrow. I'll do my best to get them up reliably again as soon as possible. Cheers, Colin

14 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev