Ros-dev

ros-dev@reactos.org

5788 discussions

by Aleksey Bragin

Hello! As per discussion during the last status meeting, I proposed to set up a deadline for having a 0.3.14 Release Candidate available by the time of the next meeting. Olaf, Amine and others were kind enough to make an up-to-date list of critical bugs and regressions to be fixed. It's available here: http://www.reactos.org/wiki/Buglist (indeed this page should be in your web browser's Favorites!) . I want to ask all of you to concentrate on fixing regressions and critical/blocker bugs first, before going into fancy features or implementing something else. It's really important, we need to make 0.3.14 as the last release before switching to 0.4. We have all necessary prerequisites, and just need to sit down and fix regressions. I personally put off all of my ReactOS-related "fancy" projects because I want a solid trunk first, and I am working only on stuff which is urgently needed - fixing remaining LDR rewrite regressions, special pool to catch pool corruptions, etc. It's meaningless to work on something else now if regressions aren't fixed. Hopefully you will follow my advice and we will have a wonderful bugfixing week(s)! Thank you! WBR, Aleksey Bragin.

12 years, 11 months

freeldr.ini now is overwritten by newly generated (livecd)

by Minas Abrahamyan

Hi all, Previously I used edited version of freeldr.ini to build livecd ISOs, it is in \output-i386\livecd\ Now freeldr.ini is becoming overwritten in make process by newly generated "standard" one, and it is overwriting my manually edited version. So 1) what is now the correct way is to have custom freeldr.ini in iso image? 2) For what are these new automagical erase-and-newly-generate scripts? Although I can now manually edit (in iso image) what has been done earlier automatically, replace the file, but, at my PoV something goes wrong. -- Best Regards, M.A.

12 years, 11 months

[ros-diffs] [rharabien] 54006: [WIN32K] - Rewrite keyboard input processing to match windows behavior -

by James Tabor

Hi! Well if anyone cares! This commit message is a lie! In IntKeyboardInput I added support for KF_DLGMODE and KF_MENUMODE ! BTW is used! In Dialog.c DF_DIALOGACTIVE! So someone will fix it right? Okay, James

12 years, 11 months

CMake adoption

by caemyr＠myopera.com

You might know me as a stout supporter of CMake transition, but a single experience shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with a cmake iso. The results were horrendous. The backtrace was lenghty, but on rbuild such task would take around 15 mintues for me, having all files extracted and prepped log.. At the present moment, cmake bt resolving is a total mess and practically prevents anyone doing such log. I might not be a programmer, but was somewhat skilled in my testers duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i hate it: 1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command 2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that... 3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually. 4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so? This HAS to be resolved before rbuild is put to retirement. Amine was talking about getting back to rsym - sure, why not? Anything that works will be better than current situation. -- With best regards Caemyr

12 years, 11 months

Re: [ros-dev] [ros-diffs] [jimtabor] 54044: [Win32k] - Implement get atom name for user32.

by Timo Kreuzer

Am 07.10.2011 15:56, schrieb jimtabor(a)svn.reactos.org: > > +DWORD > +APIENTRY > +NtUserGetAtomName( > + ATOM nAtom, > + PUNICODE_STRING pBuffer) > +{ > + DWORD Ret; > + UNICODE_STRING CapturedName = {0}; > + UserEnterShared(); > + _SEH2_TRY > + { > + CapturedName = ProbeForReadUnicodeString(pBuffer); > + Ret = IntGetAtomName((RTL_ATOM)nAtom, CapturedName.Buffer, (ULONG)CapturedName.Length); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Ret = 0; > + } > + _SEH2_END > + UserLeave(); > + return Ret; > +} IntGetAtomName must not be called from inside SEH, if it throws you'll be left with a locked atom table. Timo

12 years, 11 months

Re: [ros-dev] [ros-diffs] [cgutman] 54016: [HAL] - Implement support for scatter/gather DMA - Tested with Intel's NDIS 5.1 PRO/1000 driver (but more testing would be helpful to weed out bugs) [NDIS] - Report NDIS 5.1 now si...

by Colin Finck

cgutman(a)svn.reactos.org wrote: > - Implement support for scatter/gather DMA This commit deserves a huge LIKE button, thanks! Will try it out as soon as I have access to my ReactOS laptop again. Finally a chance for getting its Ethernet port to work :-) - Colin

12 years, 11 months

[ros-diffs] [gadamopoulos] 53751: [comctl32]

by James Tabor

Hi!! This is wrong, 8^( + class.style |= CS_GLOBALCLASS; + class.hInstance = COMCTL32_hModule; The point in THEMING_Initialize was to get the current global classes and make locals for each process. So that process could have it. Not the whole system! Note from a msdn blog, "If you pass the CS_GLOBALCLASS flag when registering the class, then the window manager will ignore the instance handle when looking for your class. All of the USER32 classes are registered as global." I spent a week now looking through it all, ReactOS is handling the class registration correctly. My best guess, if themes is active do as the original code had it before and use IsThemeActive like it is setup. Keep class.hInstance = COMCTL32_hModule; and don't use CS_GLOBALCLAS so you can find it again. Thanks, James

12 years, 11 months

Proposal for deletion

by Pierre Schweitzer

Hi, today, after looking at the daily source analysis we have, I found out that all that stuff could be improved by lightening trunk. We have huge amount of unused code (even not linked in CMake) rotting in trunk. I'm mainly talking about icu4ros. AFAIK it was an attempt from KJK for I even don't recall what. Here is my proposal: we do a branch for this. And then, we remove it from trunk. This will make things lighter, without loosing code. Any objections/comments? Regards, Pierre

12 years, 11 months

Re: [ros-dev] [ros-bugs] [Bug 6535] Sync gdi32+kernel32 winetests to git head

by caemyr＠myopera.com

With this attempt Thomas proved that it is possible to use patchbot for both trunk and rostests patching. Ask him how he did it:> On Wednesday, October 05, 2011 9:05 AM, ReactOS.Bugzilla(a)reactos.org wrote: > --- Comment #1 from ThFabba <thfabba(a)gmx.de> 2011-10-05 09:05:44 CET --- > Created an attachment (id=6782) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=6782) > patch 2 > > Maybe this works :p > -- With best regards Caemyr

12 years, 11 months

Setupapi & VBox additions

by Thomas Faber

Hi, I've been looking at VirtualBox 4.1.x guest additions, which don't install in ROS [1] and came up with a patch [2] that seems to fix them. While patchbot says this is okay [3] (and the last hunk even fixes a few setupapi tests), I am very unsure about the SP_COPY_NOOVERWRITE part. The correct solution might instead be to handle SetupCopyOEMInf returning ERROR_FILE_EXISTS or I might be "fixing" something in the completely wrong place. It would be great if someone with some insight into setupapi (Eric? Hervé? ;]) could review this and give some pointers. Thanks! -Thomas [1] http://www.reactos.org/bugzilla/show_bug.cgi?id=6522 [2] http://www.reactos.org/bugzilla/attachment.cgi?id=6753 [3] http://www.reactos.org/testman/compare.php?ids=8272,8294,8303,8305 Patch explanation: - The first hunk isn't really required, but I guess it shouldn't break anything, and seems to find what it's looking for this way. - The second hunk is in the code path used by VBox guest additions setup. It is apparently called with an already-existing inf file, but I have no idea why. :| - The third hunk is a trivial bug that our CreateService just didn't complain about before r53872/r53886

12 years, 11 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