- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [hbelusca] 70674: [CMLIB]: Demote the DPRINT1 saying that we leak the security block descriptor to a DPRINT. People (Alex & me) working on cmlib already know this. "Fixes" timeout problems of the t...

by Alex Ionescu

I think you guys took more time to debug and mess with the DPRINT then it would've taken to implement the function. Come on guys. Best regards, Alex Ionescu On Mon, Feb 1, 2016 at 3:10 PM, <hbelusca(a)svn.reactos.org> wrote: > Author: hbelusca > Date: Mon Feb 1 23:10:38 2016 > New Revision: 70674 > > URL: http://svn.reactos.org/svn/reactos?rev=70674&view=rev > Log: > [CMLIB]: Demote the DPRINT1 saying that we leak the security block descriptor to a DPRINT. People (Alex & me) working on cmlib already know this. "Fixes" timeout problems of the testbots due to spamming this dprint. > > Modified: > trunk/reactos/lib/cmlib/cmkeydel.c > > Modified: trunk/reactos/lib/cmlib/cmkeydel.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/cmlib/cmkeydel.c?rev=7… > ============================================================================== > --- trunk/reactos/lib/cmlib/cmkeydel.c [iso-8859-1] (original) > +++ trunk/reactos/lib/cmlib/cmkeydel.c [iso-8859-1] Mon Feb 1 23:10:38 2016 > @@ -215,7 +215,7 @@ > } > > /* FIXME: This leaks the security desriptor! */ > - DPRINT1("Potentially leaking key security descriptor. Please call CmpFreeSecurityDescriptor\n"); > + DPRINT("Potentially leaking key security descriptor. Please call CmpFreeSecurityDescriptor\n"); > > /* Free the key body itself, and then return our status */ > if (!CmpFreeKeyBody(Hive, Cell)) return STATUS_INSUFFICIENT_RESOURCES; > >

9 years, 7 months

2
1
0 0

Re: [ros-dev] [BOOTLIB]: Cleanup, less magic.

by Love Nystrom

On 2016-01-24 19.00, ros-dev-request(a)reactos.org wrote: > + if (Length != Length) Now that's what we call an unlikely condition :-D The CPU branch predictor will have no problem. Magic indeed.. Hope it's not indicative.. L.

9 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ion] 70633: [BOOTLIB]: Cleanup, less magic.

by Timo Kreuzer

Am 21.01.2016 um 16:47 schrieb ion(a)svn.reactos.org: > Author: ion > Date: Thu Jan 21 15:47:14 2016 > New Revision: 70633 > > URL: http://svn.reactos.org/svn/reactos?rev=70633&view=rev > Log: > [BOOTLIB]: Cleanup, less magic. Looks like you forgot to cleanup this special piece of extra magic. > + if (Length != Length) > + { > + PartialSum += (unsigned __int8)Buffer[Length]; > + if (Flags & BL_UTL_CHECKSUM_COMPLEMENT) > + { > + PartialSum = (unsigned __int16)((PartialSum >> 16) + PartialSum); > + } > + } > +

9 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cfinck] 70507: [BOOTVID] Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro" font, which makes a nice 8x13 font. Blue Screens now look like this: http://fs5.d...

by Timo Kreuzer

For everyone who thinks this looks terrible: don't view it in your browser. Instead download it and open it with a proper image viewer. Then your eyes stop bleeding and it actually looks good :) Timo Am 06.01.2016 um 10:31 schrieb cfinck(a)svn.reactos.org: > Author: cfinck > Date: Wed Jan 6 09:31:53 2016 > New Revision: 70507 > > URL: http://svn.reactos.org/svn/reactos?rev=70507&view=rev > Log: > [BOOTVID] > Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro" font, which makes a nice 8x13 font. > Blue Screens now look like this: http://fs5.directupload.net/images/160106/ehv6245t.png > > [BOOTVID_FONT_GENERATOR] > In case you find an even better font, you now have a nice little tool to test that font and generate the corresponding FontData array for bootvid. > > Added: > trunk/rosapps/applications/devutils/bootvid_font_generator/ > trunk/rosapps/applications/devutils/bootvid_font_generator/CMakeLists.txt (with props) > trunk/rosapps/applications/devutils/bootvid_font_generator/bootvid_font_generator.c (with props) > Modified: > trunk/reactos/drivers/base/bootvid/arm/bootdata.c > trunk/reactos/drivers/base/bootvid/i386/bootdata.c > trunk/rosapps/applications/devutils/CMakeLists.txt > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/drivers/base/bootvid/arm/bootdata.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/arm/b… > > Modified: trunk/reactos/drivers/base/bootvid/i386/bootdata.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/… > > Modified: trunk/rosapps/applications/devutils/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/CMak… > > Added: trunk/rosapps/applications/devutils/bootvid_font_generator/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/boot… > > Added: trunk/rosapps/applications/devutils/bootvid_font_generator/bootvid_font_generator.c > URL: http://svn.reactos.org/svn/reactos/trunk/rosapps/applications/devutils/boot… > > >

9 years, 8 months

3
3
0 0

Commit access for creating a branch

by Mohamed MEDIOUNI

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,

9 years, 8 months

3
3
0 0

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

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; > } > >

9 years, 8 months

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

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; > >

9 years, 8 months

3
6
0 0

[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

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

9 years, 8 months

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

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"); > > >

9 years, 8 months

1
0
0 0

Fwd: Congratulations! Your project is a Project of the Week on SourceForge

by Alex Ionescu

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

9 years, 8 months

3
2
0 0

Something is wron again with getbuilds

by Alexander Rechitskiy

9 years, 9 months

3
2
0 0

Filesystem corruption in ReactOS when Firefox is updated

by Dimitrij Klingbeil

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

9 years, 9 months

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

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.

9 years, 9 months

1
0
0 0

kbswitch update

by Hans-Peter Diettrich

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

9 years, 9 months

6
7
0 0

wtf iso.reactos.org is down for ages?

by Alexander Rechitskiy

9 years, 9 months

7
11
0 0

Status Meeting (November 2015)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of a month, 26th of November, 19:00 UTC, as usual. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Please send agenda proposals to me before the meeting. Regards, Aleksey Bragin

9 years, 9 months

8
11
0 0

Patch situation

by Robert Naumann

Hey all. I have some thoughts about our current patch situation. After the last big strike regarding patches, which was around the Hackfest, The count of them increased amazingly. We got some new contributers, this year, which do a great work. Some of our old contributers are still hacking like fire and mostly this are small fixes with big impact. Easy to review. I summed up some of them, to show which could get some attention. There are also bigger patches, which would need a coordinated review, but add very nice features (Swyters vbox fix for example). I am sure that about 10 of them could make it. Patches that are currently under review or active development ============================================================= The following patches are the ones, which actually got some attention. They all are slightly bigger ones. CORE-10533 PATCH: Fix local network resolving CORE-10440 PATCH: Fix issues of ws2_32_new CORE-10367 Implement apphelp sdb layer (More or less) simple patches, that would be nice2have for 0.4 ============================================================== These are all the patches from our actual most active contributers. Most of them are very small and easy to understand. Let's not forget them because contributers can become developers, which we need so badly. It would be nice to have them in trunk before release, if they are correct. CORE-10550 clipbrd: Load the clipboard contents from a file CORE-10476 Add a placeholder machine owner at second stage installer to improve UX CORE-10438 [shell32] 'Empty Recycle Bin' should be disabled when no items are present CORE-10437 [console] Add missing DS_MODALFRAME CORE-10436 [shell32] OK button in run dialog should be disabled by default CORE-10410 [fdebug] Manifest and application title CORE-10393 [RAPPS] Small Database Update CORE-10310 Automatically format file size & assorted fixes for apps CORE-9721 [notepad] Let the user know when an opened file is modified CORE-9959 shell32: patch for SHFileOperation (delete-operation) CORE-6742 Can't dynamically change the resolution by resizing in VirtualBox Hacks(?) that would improve the look and feel in 0.4 ==================================================== These patches contain hacks but it would be nice to have them in release. I don't mean to apply them to trunk, but to the 0.4 branch. Important is that, if this happens, enough regression testing is done. CORE-9654 PATCH +Bugfix: UXTHEME draw text with shadows, fix GetThemeSysColor CORE-9533 Title icons are 32pixel downsized to 16pixel CORE-5644 mspaint: selection border isn't visible CORE-9689 Drive's properties theming problem CORE-8925 Start menu has classic border when themes are enabled Drive Type related patches ========================== The author of these patches did some effort to fix the bug, which shows the correct icon for specific drives. I feel like I saw more than this 2 patches but I am not sure and don't find more. We should collaborate with him and take care of this annoying bug, CORE-10221 Fix icons in My Computer CORE-9622 Improvement to GetDriveType() Function Victor's Patches ================ These patches are from Victor M. Calvo. He did a big effort to fix bugs, which affect specifig apps and caused registry curruption. He also proved his patches with apitests but almost nothing happened with the patches. CORE-9673 PATCH: BS_DIBPATTERN8x8 not supported CORE-9672 PATCH: Rewrite RegQueryInfoKeyW CORE-9666 PATCH: RegQueryValueExW fails to set properly the REG_NONE type CORE-9665 PATCH: RegQueryValueExW and RegQueryValueExA calls accept bytes not chars. CORE-9398 PATCH: Several fixes for SetupInstallServicesFromInfSectionExW CORE-8164 Fix a interexchanging values in Vga driver CORE-8157 Fix a memcpy in Dhcpclient using the length in bytes. CORE-8156 Fix a sanity check of a returned ConstructBitBlob CORE-8077 GetDiskFreeSpaceW fixes CORE-8076 SetVolumeLabelW and GetVolumeInformationW fixes Cheers Robert

9 years, 9 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 69936: [USER32] Implement now-documented MB_GetString. See: https://msdn.microsoft.com/en-us/library/windows/desktop/dn910915(v=vs.85).aspx and: http://undoc.airesoft.co.uk/user32.dll/MB...

by Michael Fritscher

Hi, > + > + /* The allowable IDs are between IDOK (0) and IDCONTINUE (11) > inclusive */ > + if (wBtn >= IDCONTINUE) > + return NULL; > + > + LoadStringW(User32Instance, wBtn, (LPWSTR)&btnStr, 0); > + return btnStr; If IDCONTINUE is inclusive then the check in the next line should be >, shouldn't it? Best regards, Michael

9 years, 10 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 69935: [USER32] MessageBoxIndirect fixes by Carlo Bramini: - Implemented loading of text and caption if they are detected as resource IDs. - Use direct resource string pointers with Load...

by Thomas Faber

Mixing formatting changes, changes that should and changes that shouldn't affect behavior, and making indentation inconsistent in the progress is my favorite. :\ On 2015-11-19 00:46, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Wed Nov 18 23:46:38 2015 > New Revision: 69935 > > URL: http://svn.reactos.org/svn/reactos?rev=69935&view=rev > Log: > [USER32] > MessageBoxIndirect fixes by Carlo Bramini: > - Implemented loading of text and caption if they are detected as resource IDs. > - Use direct resource string pointers with LoadStringW and use the returned string length. > - Dramatically improve the implementation of ID and resource string assignments, by using a little look up table. This removes some ugly, difficult to maintain copy-paste code. > - Fix the scaling of logical coordinates by making it aware of rounding, i.e. the size of the controls is now calculated correctly. > CORE-10352 #resolve #comment Thank you for the patch! :D

9 years, 10 months

1
0
0 0

Infrastructure problems today

by Colin Finck

Hi all, We suffered from several Infrastructure problems in one of our datacenters today, with the cause that multiple servers were temporarily unreachable. All problems should be finally fixed now though. If you still encounter related problems, please reply to my mail. Cheers, Colin

9 years, 10 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 69650: The c++ bool is 1 byte, not 4. Thanks Thomas

by Timo Kreuzer

In fact in this case it wouldn't make a difference, since the bool would be converted to a LONG. But using TRUE/FALSE seems to be appropriate here. Am 22.10.2015 um 19:37 schrieb gedmurphy(a)svn.reactos.org: > Author: gedmurphy > Date: Thu Oct 22 17:37:51 2015 > New Revision: 69650 > > URL: http://svn.reactos.org/svn/reactos?rev=69650&view=rev > Log: > The c++ bool is 1 byte, not 4. Thanks Thomas > > Modified: > trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.cpp > trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.h > > Modified: trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/devmgr/devmgmt/M… > ============================================================================== > --- trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.cpp [iso-8859-1] Thu Oct 22 17:37:51 2015 > @@ -786,7 +786,7 @@ > // we set a timer to run in 500ms, which should leave enough time for all > // the messages to come through. Wrap so we don't set multiple timers > // > - if (InterlockedCompareExchange((LONG *)&This->m_RefreshPending, true, false) == false) > + if (InterlockedCompareExchange((LONG *)&This->m_RefreshPending, TRUE, FALSE) == FALSE) > { > SetTimer(hwnd, REFRESH_TIMER, 500, NULL); > } > @@ -807,7 +807,7 @@ > KillTimer(hwnd, REFRESH_TIMER); > > // Allow more change notifications > - InterlockedExchange((LONG *)&This->m_RefreshPending, false); > + InterlockedExchange((LONG *)&This->m_RefreshPending, FALSE); > } > break; > } > > Modified: trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/devmgr/devmgmt/M… > ============================================================================== > --- trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/devmgr/devmgmt/MainWindow.h [iso-8859-1] Thu Oct 22 17:37:51 2015 > @@ -17,7 +17,7 @@ > HMENU m_hMenu; > HMENU m_hActionMenu; > int m_CmdShow; > - bool m_RefreshPending; > + BOOL m_RefreshPending; > > public: > CDeviceManager(void); > > >

9 years, 10 months

4
7
0 0

Files in press-media repository

by Colin Finck

Hi all, After Victor's commit of so many files to our press-media repository, I think we should establish some binding rules for it: * There is no need to have a single file in X different formats in the repository. Let's only keep it there in the best format. In particular, that means: Vector formats > Dynamic raster formats > Static raster formats E.g.: AI/SVG > PSD/TIFF > PNG The only exception to the rule can be made if one of the better formats is highly proprietary (like AI). In that case, an additional SVG file or (as a last resort) high-resolution PNG file may accompany it. I don't consider PSD proprietary anymore, because almost every Open-Source and Closed-Source graphics tool can work with them. Totally uncompressed formats (like BMP) have no reason to stay in the repository at all when better compressed formats (like PNG) are available. I would make the only exception to e.g. the BIOS logo for the MiniPC, because this one needs to be a BMP with special settings for technical reasons. * Only directly ReactOS-related media whose copyright is clarified should go there. Third-party graphics can pose a serious legal trouble. Additionally, Stock graphics can be found on many platforms. There is no need to let press-media become a repository for this. As long as there are no objections or additions, I would like Victor to remove some redundant files according to these rules. Cheers, Colin

9 years, 10 months

3
4
0 0

Status meeting today

by Alex Bragin

I am in traffic in the very centre of Moscow right now and most probably won't be on time for the meeting start. Please start the meeting without me, and first topic of agenda which I would like you to start with is the release plans. I will join you ASAP Regards, Aleksey

9 years, 10 months

1
0
0 0

Status Meeting (October 2015)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of a month, 29th of October, 19:00 UTC, as usual. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Please send agenda proposals to me before the meeting. Regards, Aleksey Bragin

9 years, 10 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 69683: [CRT] Fix NTDLL implementation of mbstowcs() and wcstombs() so that they return length in caracters and not in bytes. This fixes last failing *to* CRT apitests CORE-10390

by Michael Fritscher

Hi, > Modified: trunk/reactos/lib/sdk/crt/string/mbstowcs_nt.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/mbstowc… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/string/mbstowcs_nt.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/string/mbstowcs_nt.c [iso-8859-1] Sun Oct 25 > 09:28:57 2015 > @@ -60,7 +60,7 @@ > if (!NT_SUCCESS(Status)) > return -1; > > - return (size_t)Size; > + return (size_t)(Size / sizeof(wchar_t));; > } > > /* EOF */ Tiny, not critical typo: Two semicolons ;-) Best regards, Michael Fritscher

9 years, 10 months

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