Ros-dev

ros-dev@reactos.org

5788 discussions

[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

8 years, 8 months

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

8 years, 8 months

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

8 years, 9 months

Something is wron again with getbuilds

by Alexander Rechitskiy

8 years, 9 months

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

8 years, 9 months

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.

8 years, 9 months

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

8 years, 9 months

wtf iso.reactos.org is down for ages?

by Alexander Rechitskiy

8 years, 9 months

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

8 years, 9 months

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

8 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev