Ros-dev December 2015

ros-dev@reactos.org

19 participants
10 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] [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

wtf iso.reactos.org is down for ages?
by Alexander Rechitskiy 07 Dec '15

07 Dec '15

7 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2015