Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

Commit access for creating a branch
by Mohamed MEDIOUNI 03 Jan '16

03 Jan '16

Can I have commit access to !trunk branches for not forking to Git? (for reviving the POSIX subsystem with the Newlib C library and adding pthreads support) Thanks,

3 3

Re: [ros-dev] [ros-diffs] [tkreuzer] 70464: [WIN32K] Properly check the bitmap size in IntSetDIBits, taking into account that it might be set to 0, then we have to calculate it ourselves. Fixes a crash when invalid data is ...
by Thomas Faber 01 Jan '16

01 Jan '16

Timo, this is causing testbot to freak out since it now crashes during an apitest. Could you look into it? Thanks. On 2015-12-29 21:28, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Dec 29 20:28:23 2015 > New Revision: 70464 > > URL: http://svn.reactos.org/svn/reactos?rev=70464&view=rev > Log: > [WIN32K] > Properly check the bitmap size in IntSetDIBits, taking into account that it might be set to 0, then we have to calculate it ourselves. Fixes a crash when invalid data is passed to NtGdiCreateDIBitmapInternal. > [GDI32] > Convert COREINFOHEADER to BITMAPINFOHEADER before passing it to NtGdiCreateDIBitmapInternal, which doesn't support it. > CORE-10583 #resolve > > Modified: > trunk/reactos/win32ss/gdi/gdi32/objects/bitmap.c > trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > > Modified: trunk/reactos/win32ss/gdi/gdi32/objects/bitmap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/gdi32/objects/… > ============================================================================== > --- trunk/reactos/win32ss/gdi/gdi32/objects/bitmap.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/gdi32/objects/bitmap.c [iso-8859-1] Tue Dec 29 20:28:23 2015 > @@ -408,23 +408,30 @@ > // PDC_ATTR pDc_Attr; > UINT InfoSize = 0; > UINT cjBmpScanSize = 0; > - HBITMAP hBmp; > + HBITMAP hBmp = NULL; > NTSTATUS Status = STATUS_SUCCESS; > + PBITMAPINFO pbmiConverted; > + UINT cjInfoSize; > + > + /* Convert the BITMAPINFO if it is a COREINFO */ > + pbmiConverted = ConvertBitmapInfo(Data, ColorUse, &cjInfoSize, FALSE); > > /* Check for CBM_CREATDIB */ > if (Init & CBM_CREATDIB) > { > /* CBM_CREATDIB needs Data. */ > - if (!Data) > - { > - return 0; > + if (pbmiConverted == NULL) > + { > + DPRINT1("CBM_CREATDIB needs a BITMAINFO!\n"); > + goto Exit; > } > > /* It only works with PAL or RGB */ > if (ColorUse > DIB_PAL_COLORS) > { > + DPRINT1("Invalid ColorUse: %lu\n", ColorUse); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return 0; > + goto Exit; > } > > /* Use the header from the data */ > @@ -434,38 +441,48 @@ > /* Header is required */ > if (!Header) > { > + DPRINT1("Header is NULL\n"); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return 0; > + goto Exit; > } > > /* Get the bitmap format and dimensions */ > if (DIB_GetBitmapInfo(Header, &width, &height, &planes, &bpp, &compr, &dibsize) == -1) > { > + DPRINT1("DIB_GetBitmapInfo failed!\n"); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return NULL; > + goto Exit; > } > > /* Check if the Compr is incompatible */ > if ((compr == BI_JPEG) || (compr == BI_PNG) || (compr == BI_BITFIELDS)) > - return 0; > + { > + DPRINT1("invalid compr: %lu!\n", compr); > + goto Exit; > + } > > /* Only DIB_RGB_COLORS (0), DIB_PAL_COLORS (1) and 2 are valid. */ > if (ColorUse > DIB_PAL_COLORS + 1) > { > + DPRINT1("invalid compr: %lu!\n", compr); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return 0; > + goto Exit; > } > > /* If some Bits are given, only DIB_PAL_COLORS and DIB_RGB_COLORS are valid */ > if (Bits && (ColorUse > DIB_PAL_COLORS)) > { > + DPRINT1("Invalid ColorUse: %lu\n", ColorUse); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return 0; > + goto Exit; > } > > /* Negative width is not allowed */ > if (width < 0) > - return 0; > + { > + DPRINT1("Negative width: %li\n", width); > + goto Exit; > + } > > /* Top-down DIBs have a negative height. */ > height = abs(height); > @@ -473,13 +490,13 @@ > // For Icm support. > // GdiGetHandleUserData(hdc, GDI_OBJECT_TYPE_DC, (PVOID)&pDc_Attr)) > > - if (Data) > + if (pbmiConverted) > { > _SEH2_TRY > { > - cjBmpScanSize = GdiGetBitmapBitsSize((BITMAPINFO *) Data); > - CalculateColorTableSize(&Data->bmiHeader, &ColorUse, &InfoSize); > - InfoSize += Data->bmiHeader.biSize; > + cjBmpScanSize = GdiGetBitmapBitsSize(pbmiConverted); > + CalculateColorTableSize(&pbmiConverted->bmiHeader, &ColorUse, &InfoSize); > + InfoSize += pbmiConverted->bmiHeader.biSize; > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > @@ -490,8 +507,9 @@ > > if (!NT_SUCCESS(Status)) > { > + DPRINT1("Got an exception!\n"); > GdiSetLastError(ERROR_INVALID_PARAMETER); > - return NULL; > + goto Exit; > } > > DPRINT("pBMI %p, Size bpp %u, dibsize %d, Conv %u, BSS %u\n", Data, bpp, dibsize, InfoSize, > @@ -501,9 +519,18 @@ > hBmp = GetStockObject(DEFAULT_BITMAP); > else > { > - hBmp = NtGdiCreateDIBitmapInternal(hDC, width, height, Init, (LPBYTE) Bits, > - (LPBITMAPINFO) Data, ColorUse, InfoSize, cjBmpScanSize, 0, 0); > - } > + hBmp = NtGdiCreateDIBitmapInternal(hDC, width, height, Init, (LPBYTE)Bits, > + (LPBITMAPINFO)pbmiConverted, ColorUse, InfoSize, cjBmpScanSize, 0, 0); > + } > + > +Exit: > + > + /* Cleanup converted BITMAPINFO */ > + if ((pbmiConverted != NULL) && (pbmiConverted != Data)) > + { > + RtlFreeHeap(RtlGetProcessHeap(), 0, pbmiConverted); > + } > + > return hBmp; > } > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Tue Dec 29 20:28:23 2015 > @@ -259,11 +259,37 @@ > POINTL ptSrc; > EXLATEOBJ exlo; > PPALETTE ppalDIB = 0; > + ULONG cjSizeImage; > > if (!bmi) return 0; > > - if (bmi->bmiHeader.biSizeImage > cjMaxBits) > - { > + /* Check if the header provided an image size */ > + if (bmi->bmiHeader.biSizeImage != 0) > + { > + /* Use the given size */ > + cjSizeImage = bmi->bmiHeader.biSizeImage; > + } > + /* Otherwise check for uncompressed formats */ > + else if ((bmi->bmiHeader.biCompression == BI_RGB) || > + (bmi->bmiHeader.biCompression == BI_BITFIELDS)) > + { > + /* Calculate the image size */ > + cjSizeImage = DIB_GetDIBImageBytes(bmi->bmiHeader.biWidth, > + ScanLines, > + bmi->bmiHeader.biBitCount); > + } > + else > + { > + /* Compressed format without a size. This is invalid. */ > + DPRINT1("Compressed format without a size!"); > + return 0; > + } > + > + /* Check if the size that we have is ok */ > + if (cjSizeImage > cjMaxBits) > + { > + DPRINT1("Size too large! cjSizeImage = %lu, cjMaxBits = %lu\n", > + cjSizeImage, cjMaxBits); > return 0; > } > > @@ -273,7 +299,7 @@ > BitmapFormat(bmi->bmiHeader.biBitCount, > bmi->bmiHeader.biCompression), > bmi->bmiHeader.biHeight < 0 ? BMF_TOPDOWN : 0, > - bmi->bmiHeader.biSizeImage, > + cjSizeImage, > (PVOID)Bits, > 0); > if (!SourceBitmap) > @@ -314,6 +340,8 @@ > rcDst.right = psurfDst->SurfObj.sizlBitmap.cx; > ptSrc.x = 0; > ptSrc.y = 0; > + > + NT_ASSERT(psurfSrc->SurfObj.cjBits <= cjMaxBits); > > result = IntEngCopyBits(&psurfDst->SurfObj, > &psurfSrc->SurfObj, > @@ -1366,7 +1394,11 @@ > /* Undocumented flag which creates a DDB of the format specified by the bitmap info. */ > handle = IntCreateCompatibleBitmap(Dc, width, height, planes, bpp); > if (!handle) > + { > + DPRINT1("IntCreateCompatibleBitmap() failed!\n"); > return NULL; > + } > + > /* The palette must also match the given data */ > Surface = SURFACE_ShareLockSurface(handle); > ASSERT(Surface); > @@ -1430,6 +1462,7 @@ > safeBits = ExAllocatePoolWithTag(PagedPool, cjMaxBits, TAG_DIB); > if(!safeBits) > { > + DPRINT1("Failed to allocate %lu bytes\n", cjMaxBits); > EngSetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > } > @@ -1452,6 +1485,7 @@ > > if(!NT_SUCCESS(Status)) > { > + DPRINT1("Got an exception! pjInit = %p\n", pjInit); > SetLastNtError(Status); > goto cleanup; > } > @@ -1498,6 +1532,7 @@ > hdcDest = NtGdiCreateCompatibleDC(0); > if(!hdcDest) > { > + DPRINT1("NtGdiCreateCompatibleDC failed\n"); > return NULL; > } > } > @@ -1509,6 +1544,7 @@ > Dc = DC_LockDc(hdcDest); > if (!Dc) > { > + DPRINT1("Failed to lock hdcDest %p\n", hdcDest); > EngSetLastError(ERROR_INVALID_HANDLE); > return NULL; > } > >

1 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 70408: [NTOSKRNL] - Raise the IRQL when enumerating device lists so it doesn't get edited mid-listing - Don't hardcode the pointer size when checking the buffer size
by Thomas Faber 30 Dec '15

30 Dec '15

Uhm... raising the IRQL is not a synchronization mechanism. Should there be a spinlock involved? On 2015-12-23 12:26, gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Wed Dec 23 11:26:28 2015 > New Revision: 70408 > > URL: http://svn.reactos.org/svn/reactos?rev=70408&view=rev > Log: > [NTOSKRNL] > - Raise the IRQL when enumerating device lists so it doesn't get edited mid-listing > - Don't hardcode the pointer size when checking the buffer size > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/device.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/device.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/device.c… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/device.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/device.c [iso-8859-1] Wed Dec 23 11:26:28 2015 > @@ -1088,6 +1088,10 @@ > { > ULONG ActualDevices = 1; > PDEVICE_OBJECT CurrentDevice = DriverObject->DeviceObject; > + KIRQL OldIrql; > + > + /* Raise to dispatch level */ > + KeRaiseIrql(DISPATCH_LEVEL, &OldIrql); > > /* Find out how many devices we'll enumerate */ > while ((CurrentDevice = CurrentDevice->NextDevice)) ActualDevices++; > @@ -1099,13 +1103,14 @@ > *ActualNumberDeviceObjects = ActualDevices; > > /* Check if we can support so many */ > - if ((ActualDevices * 4) > DeviceObjectListSize) > + if ((ActualDevices * sizeof(PDEVICE_OBJECT)) > DeviceObjectListSize) > { > /* Fail because the buffer was too small */ > + KeLowerIrql(OldIrql); > return STATUS_BUFFER_TOO_SMALL; > } > > - /* Check if the caller only wanted the size */ > + /* Check if the caller wanted the device list */ > if (DeviceObjectList) > { > /* Loop through all the devices */ > @@ -1123,6 +1128,9 @@ > DeviceObjectList++; > } > } > + > + /* Return back to previous IRQL */ > + KeLowerIrql(OldIrql); > > /* Return the status */ > return STATUS_SUCCESS; > >

3 6

[ros-diffs] [tkreuzer] 70464: [WIN32K] Properly check the bitmap size in IntSetDIBits, taking into account that it might be set to 0, then we have to calculate it ourselves. Fixes a crash when invalid data is ...
by James Tabor 29 Dec '15

29 Dec '15

I guess it take a decade to get things done in ReactOS? After a few had reverted some code and stuff. Like, Convert COREINFOHEADER to BITMAPINFOHEADER before passing it to NtGdiCreateDIBitmapInternal Yeah~! Very Original! Those that do not get it, research it! It's all in the mailing list! James

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 70405: [KDCOM] Do not use the "LoaderBlock->u.I386.CommonDataArea; " hack to use FreeLdr's DbgPrint function inside KDCOM, for the simple reason that while it works when KDCOM just initia...
by Timo Kreuzer 27 Dec '15

27 Dec '15

That doesn't seem to make much sense. Why enumerate from the end? It should rather enumerate from the start and skip the KdComPort. So far we used COM1 as debug port on MSVC builds and COM2 as terminal debug port for both freeldr and KDCOM. Preferably this should configurable. I really don't like this unintuitive and quite random behaviour. > +#ifdef KDDEBUG > + /* > + * Try to find a free COM port and use it as the KD debugging port. > + * NOTE: Inspired by reactos/boot/freeldr/freeldr/comm/rs232.c, Rs232PortInitialize(...) > + */ > + { > + /* > + * Start enumerating COM ports from the last one to the first one, > + * and break when we find a valid port. > + * If we reach the first element of the list, the invalid COM port, > + * then it means that no valid port was found. > + */ > + ULONG ComPort; > + for (ComPort = MAX_COM_PORTS; ComPort > 0; ComPort--) > + { > + /* Check if the port exist; skip the KD port */ > + if ((ComPort != ComPortNumber) && CpDoesPortExist(UlongToPtr(BaseArray[ComPort]))) > + break; > + } > + if (ComPort != 0) > + CpInitialize(&KdDebugComPort, UlongToPtr(BaseArray[ComPort]), DEFAULT_BAUD_RATE); > + } > +#endif > + > + KDDBGPRINT("KdDebuggerInitialize0\n"); > > >

1 0

Fwd: Congratulations! Your project is a Project of the Week on SourceForge
by Alex Ionescu 22 Dec '15

22 Dec '15

Do you guys get these e-mails too? I think I'm still listed as the admin ;-) Best regards, Alex Ionescu ---------- Forwarded message ---------- From: Cherith Janes <cjanes(a)slashdotmedia.com> Date: Fri, Dec 18, 2015 at 10:09 PM Subject: Congratulations! Your project is a Project of the Week on SourceForge To: communityteam(a)sourceforge.net Hello, My name is Cherith Janes and I am a content editor for SourceForge. I am writing to inform you that your project is a featured Project of the Week and will be listed on the front page of our site next week. This means your project may be included in this month's Community Project of the Month vote, depending on the number of downloads it gets. Projects are chosen based on a variety of considerations, such as recent releases, interesting blog activity, or other related things. Front page features tend to result in increased traffic to your project page so you may want to take this opportunity to make sure you have the latest project description, screenshots, and project logo. And, here is the link to the blog post (*that will go live Monday*) notifying the community of your accomplishment: http://sourceforge.net/blog/project-of-the-week-december-21-2015 Here are all of the *Projects of the Week* for December 21, 2015: akelpad <https://sourceforge.net/projects/akelpad/> filebot <https://sourceforge.net/projects/filebot/> winpython <https://sourceforge.net/projects/winpython/> moneymanagerex <https://sourceforge.net/projects/moneymanagerex/> reactos <https://sourceforge.net/projects/reactos/> cmusphinx <https://sourceforge.net/projects/cmusphinx/> outlookcaldavsynchronizer <https://sourceforge.net/projects/outlookcaldavsynchronizer/> winpenpack <https://sourceforge.net/projects/winpenpack/> <https://sourceforge.net/projects/maxima/>jedit-plugins <https://sourceforge.net/projects/jedit-plugins/> Thanks for being part of the SourceForge community! And best of luck. Cherith Janes Content Editor SourceForge.net

3 2

Something is wron again with getbuilds
by Alexander Rechitskiy 16 Dec '15

16 Dec '15

3 2

Filesystem corruption in ReactOS when Firefox is updated
by Dimitrij Klingbeil 12 Dec '15

12 Dec '15

Hi all I'd like to report a bug, but can't figure out how to do this properly. Jira requires being a registered user but does not tell how exactly one is supposed to get that registration. I hope you have some other, more user-friendly way for reporting bugs by "normal" users - people not so intimate with the ReactOS development - or that you at least plan to provide such a way in the near future. Anyway, here's what I think warrants looking into in more detail: Apparently there is still something that corrupts fastfat - triggerable from user-mode programs. The automatic update function of Firefox (as well as other derivatives like Pale Moon) seems to trigger a particularly nasty instance of that. I think that if a new ReactOS version is going to be released now, it will cause a lot of spurious bug reports from users that install Firefox (it's a popular program after all), and wreck FastFAT during an update in the background. In fact, many users may not be aware of the connection as Firefox tends to update itself in a stealthy way and the user does not really get to see what happens. Steps to reproduce: - install Firefox (or Palemoon, any version from the last couple of years, except of course the latest one) - open the about dialog in it - it will start downloading an update - it will copy the update into a temporary dir in the firefox install dir - it will prompt the user for a restart - look into the Firefox install dir, you will find (among other things) an "update" subdir with temporary files, but so far everything looks OK - now click restart in prompt - it will do some filesystem operations for some seconds, quit, but not restart - look into the install dir again, now it will be a horrible mess of unintelligible things with completely broken filenames - you may not always be able to take that last look as ReactOS may lock-up when you open the folder in explorer (or when you hit F5 if it was already opened) - in any case, ReactOS won't stay very stable for significant time afterwards, even if it survives the look - if it does stay stable for a while, you won't be able to delete the directory nor any items in it, an attempt to delete them will fail, often causing a lock-up Affected versions of Firefox - seemingly all from the recent decade Affected SVN builds of ReactOS - everything from recent years as far as I can tell, but see notes below Additional notes - I've only tested builds made from SVN with RosBE on Windows - but many versions - this bug seems to be always changing when FastFAT is touched in various ROS SVN builds - about half a yer ago it was always leading to a hard lock-up and the filesystem was badly broken, even without opening the folder in Explorer, the crash would not be far away - some 3-4 months ago, the "survival" (no-crash) rate rose somewhat, but the folder still got "filled" with various rubbish - a month or 2 ago the filesystem at least tended to survive and the Firefox directory seemed to be "empty" after an update - although it could not be deleted even though nothing could be "seen" inside it, also a reinstall into the same folder tended to work without crashing - in the recent 1-2 weeks one FastFAT update brought back the bad old times, after the failed update the Firefox directory is again getting filled with broken items, and the number of those items that end up in there, seems to have increased by a lot Regards Dimitrij Klingbeil

1 0

Re: [ros-dev] [ros-diffs] [rnaumann] 70314: [EXPLORER]Initialize the propInfo structure before using it. Spotted by Mark Jansen. See CORE-10560
by Thomas Faber 09 Dec '15

09 Dec '15

On 2015-12-08 23:54, rnaumann(a)svn.reactos.org wrote: > --- trunk/reactos/base/shell/explorer/trayprop.cpp [iso-8859-1] (original) > +++ trunk/reactos/base/shell/explorer/trayprop.cpp [iso-8859-1] Tue Dec 8 22:54:33 2015 > @@ -338,7 +338,7 @@ > VOID > DisplayTrayProperties(IN HWND hwndOwner) > { > - PROPSHEET_INFO propInfo; > + PROPSHEET_INFO propInfo = {0}; > PROPSHEETHEADER psh; > PROPSHEETPAGE psp[2]; > WCHAR szCaption[256]; I would find this code much easier to understand if you passed 0 as the start menu page's lParam, since it's not making use of it anyway. Having it in both made me worry quite a lot about double frees and such that would happen if both pages used the same structure.

1 0

kbswitch update
by Hans-Peter Diettrich 07 Dec '15

07 Dec '15

Hi all, I'm just digging into kbswitch and have several questions (later). The major issue: kbswitch affects all windows at once, while it should change the input language only for the current (focused) window. I assume that kbswitch must preserve the active window, so that it can know where to apply changes, and to re-activate that window when done. As I don't know what's already implemented, I wrote a simple test program, using GetForegroundWindow() to determine the active window (hwnd), GetWindowThreadProcessId() to get the related process handle, and GetKeyboardLayout() to get the keyboard/language handle (hkl). Tested on WinXP and ReactOS, the output looks correct. The hkl seems to be composed of two words (hi: language and low: layout), which are always the same on ReactOS. On XP a different keyboard layout can be used for a language, but I cannot decipher the resulting encoding of the layout. As soon as I try to change the layout for a language on ReactOS, kbswitch shows the *layout* name, not the *language* name. Q: Can somebody try to find out how to convert a HKL into language and layout id's and/or names? (see GetLayoutIDByHkl) Q: Is kbswitch notified of focus changes, and if so: how? Then above sequence can be used to identify the related thread's setting, and update the tray icon and menu accordingly. Q: Is every process/thread already assigned a *private* hkl? If not, this feature must be implemented before further updates. So much for now DoDi

6 7

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