Ros-dev April 2010

ros-dev@reactos.org

28 participants
35 discussions

Regression fixing
by Aleksey Bragin 12 May '10

12 May '10

Hello, as you all know we have quite a lot of regressions recently, and recently they only add up to one another causing annoyances of testers and developers. There is a strong need to change this situation as soon as possible, otherwise the project's future is undetermined. I want to propose a step-by-step approach. Our brave testing team has created a good overview of the most important regressions and bugs we have so far: http://www.reactos.org/wiki/Buglist . Now, very important(!): For the first step I would like ALL developers to drop their current ReactOS-related work, including all work in branches or wherever else and focus ONLY on fixing regressions from that list. The goal is to fix all confirmed regressions that have been introduced, starting from the most recent and going down to the most ancient. All possible ways to remove a regression could be used: starting from a proper fix and finishing with a total revert or commenting out even good code. Process coordination: feel free to commit proper fixes right away, however as for reverts, I, and/or comittee of our core devs, would like to have a final say on whether something should be reverted. I repeat, all other non-regression related commits to the official ReactOS SVN repository are forbidden, even to branches. The only exception may be developers whose access is restricted to branches only. Thank you for understanding, Aleksey Bragin.

6 14

[ros-diffs] [mjmartin] 47059: [win32k] - Fix a problem where application that used WH_CBT hook procedures were receiving destroy window notification on windows that were never created.
by James Tabor 30 Apr '10

30 Apr '10

Michael! Good work!!!! Do you think this might be one of the reasons we are reentering co_UserDestroyWindow? The DCE is cleared and (not cached) at first then we go back a second time and hit the assert...? http://www.reactos.org/bugzilla/show_bug.cgi?id=5320

2 1

USetup meets NewInfLib
by Roel Messiant 28 Apr '10

28 Apr '10

Hey, This one's mostly for Eric Kohl. Newinflib seems to be causing some issues for usetup, accessing memory it shouldn't. Attached are some patches that solve this. The newinflib one fixes some pointer arithmetic, which ended up lying about a buffer size. This was already fixed in the host code, so I just applied the same fix to the ros code. The usetup patch is a hackfix. The issue here is that usetup fetches a line from a section, but the line is blank. Usetup treats it as a data line, and reading the data from it results in NULL .. which usetup tries to dereference. I just hackfixed that one because the code hasn't changed, so it must've worked fine with the previous inflib. So the question end up as: is newinflib wrong here by not trying to skip the blank line, or should usetup keep in mind such lines can exist.. or some third option? WBR, Roel Messiant PS: I know patches belong in bugzilla, but the perceived urgency on my side won the decision on where to post them.

2 1

I need help fixing rbuild and testing builds on *nix machines!
by Eric Kohl 27 Apr '10

27 Apr '10

Hi! In order to fix bug #2482 I needed to make inflib Unicode-aware. My local ReactOS setup is curently able to build Boot-CD and Live-CD using Unicode hive*.inf files. Rbuild is the only tool that still uses the original inflib. Could someone who knows more about C++ and STL than I do have a look at rbuild and make it work with the new inflib? I can provide a patch that includes newinflib (Unicode-aware inflib) and my changes to usetup and mkhive. I also need someone who can test the whole patch on a *nix machine. Any volunters? Regards, Eric

3 4

Live-CD broken!
by Eric Kohl 25 Apr '10

25 Apr '10

Hi! Could someone who is building ReactOS on a Linuy system have a look at why mkhive fails when Live-CD is built? Unfortunately I don't have a Linux system for testing. Thanks in advance! Eric

1 0

Re: [ros-dev] Regression since rev. 46042 from sir_richard
by mrnobo1024 25 Apr '10

25 Apr '10

This bug is a lot older than that, I can't remember thread list ever not being crash-prone. From 0.3.11 livecd: ←[7h♣Entered debugger on embedded INT3 at 0x0008:0x808c6fb6. kdb:> proc list PID State Filename *0x00000004 In Memory System 0x00000044 In Memory smss.exe 0x0000007c In Memory csrss.exe 0x000000a0 In Memory winlogon.exe 0x000000bc In Memory services.exe 0x000000c4 In Memory lsass.exe 0x000000f0 In Memory eventlog.exe 0x0000010c In Memory spoolsv.exe 0x00000120 In Memory dhcp.exe 0x0000013c In Memory rpcss.exe 0x00000180 In Memory umpnpmgr.exe 0x00000290 In Memory explorer.exe kdb:> proc attach 0xa0 Attached to process 0x000000a0, thread 0x000000a4. kdb:> thread list TID State Prior. Affinity EBP EIP *0x000000a4 Waiting 8 0x00000001 0x0063fecc 0x7c90697a Assertion 'TempPte.u.Long != 0' failed at ARM┬│::PAGFAULT line 161 Entered debugger on embedded INT3 at 0x0008:0x808c6fb6. *** Fatal System Error: 0x0000001e (0x80000003,0x808C6FB6,0x80957048,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808c6fbc.

2 1

Regression since rev. 46042 from sir_richard
by Olaf Siejka 25 Apr '10

25 Apr '10

Revision 46042: [KERNEL32/CSRSS]: Register new Win32 threads with CSRSS. Add a bunch of lookup, creation, allocation, hashing and CSR thread management routines from the unused CSRSRV in trunk. [CSRSS]: Bang in the new thread support in a bunch of places, including creating static server threads. It's very hacked and handle duplication doesn't work 100% reliably, but it gets the job done. [CSRSS]: Add CsrGetProcessLuid, CsrImpersonateClient, CsrRevertToSelf, CsrShutdownProcesses, CsrFindProcessForShutdown required for user-mode shutdown. Right now we are able to reliably enumerate user apps (in the user LUID) and then service/system apps (in the LOCAL SYSTEM LUID). triggers regression described here: http://www.reactos.org/bugzilla/show_bug.cgi?id=5318 (KDBG: Thread list command ASSERTs after attaching to process with PID A0 or higher)

1 0

Re: [ros-dev] [ros-diffs] [sir_richard] 46977: [NTOS]: Enable MmPageEntireDriver by implementing MiSetPagingOfDriver. [NTOS]: Call MiEnablePagingOfDriver from MmLoadSystemImage and implement it. All the work is done other than actually enabling paging, which requi
by Gabriel ilardi 24 Apr '10

24 Apr '10

Hi, After this commit ac97 doesn't install anymore, device wizard remains in a loop and the debug log shows: (drivers/wdm/audio/filters/kmixer/kmixer.c:99) KMixer.sys loaded (drivers/wdm/audio/filters/kmixer/kmixer.c:48) KMix_InstallDevice called (drivers/wdm/audio/filters/kmixer/kmixer.c:83) KMix_InstallDevice result 0 (ntoskrnl/io/pnpmgr/pnpmgr.c:202) Warning: Starting a device node without DNF_ADDED Thanks. Gabriel. > Date: Wed, 21 Apr 2010 14:06:01 +0000 > To: ros-diffs(a)reactos.org > From: sir_richard(a)svn.reactos.org > Subject: [ros-diffs] [sir_richard] 46977: [NTOS]: Enable MmPageEntireDriver by implementing MiSetPagingOfDriver. [NTOS]: Call MiEnablePagingOfDriver from MmLoadSystemImage and implement it. All the work is done other than actually enabling paging, which requires system working set support. [NTOS]: Implement MiWriteProtectSystemImage and MiComputeDriverProtection. All the work is done other than actually setting the bits on the pages, since I wanted to avoid too many changes. [NTOS]: MmCheckSystemImage returns STATUS_INVALID_IMAGE_PROTECT, not STATUS_INVALID_IMAGE_FORMAT, so the branch in MmLoadSystemImage needs to check for the correct status code. [NTOS]: Support FLG_SHOW_LDR_SNAPS for the kernel loader. > _________________________________________________________________ Messenger e Hotmail in tasca. Provali sul tuo cellulare! http://new.windowslivemobile.msn.com/it-it/Default.aspx

1 0

[ros-diffs] [tkreuzer] 46998: Disable gdi batch for SelectObject with fonts. Fixes font regression.
by James Tabor 23 Apr '10

23 Apr '10

Not surprised! I guess ReactOS new polices are for hiding the real issues and not fixing them and revert all the correct code. Since the kernel rewrites and the new order of coding, these oddities have now surfaced. The TEB, is inaccessible from kernel mode as in bug 5265 and 5314, and the strange processes access issues in bug 5310. This revert silliness will result in moving the project back to post windows 95 architecture (arwinss). ReactOS is about moving forward and taking chances with innovations from learned information then moving away to make it work even better. Personally, I hope someone will take up where this left off and move on. Good luck! Reference: http://www.reactos.org/bugzilla/show_bug.cgi?id=5265 http://www.reactos.org/bugzilla/show_bug.cgi?id=5310 http://www.reactos.org/bugzilla/show_bug.cgi?id=5314

3 3

Re: [ros-dev] ShellExecuteEx
by Love Nystrom 23 Apr '10

23 Apr '10

Gregor Schneider <grschneider(a)gmail.com> wrote: > That made me think: what happens to this field if the ShellExecuteEx > call succeeds and the flag SEE_MASK_NOCLOSEPROCESS is not set? Since > this check was thought to forward the actual result of the execution i > switched to a simpler and (in my eyes) more reliable code. Plus the > original code did not use the flag noted in the specification. > The link you provided on the other hand makes it look like > ShellExecuteEx always sets this field indendent of any flags passed to > the function. > > To find out the truth one would have to write test cases. It might > well be that the implementation we use is partially incorrect. > Especially when looking at testman (it works again :-O ) @ > shell32_winetest shlexec which still has some failures. Hi Greg, Perhaps You already know, but let's spell it out anyway: hInstApp inherits it's traits from WinExec and LoadModule. WinExec used to be declared HINSTANCE WinExec( LPCSTR CmdLine, UINT CmdShow ), and LoadModule also returned a HINSTANCE. At that time they did return the instance handle, i.e the load address, and it was safe to use these low values as error codes, because they were impossible load addresses (they still are). Even though WinExec/LoadModule's signatures have changed, and we've been given CreateProcess to exert better control, somewhere in the bowels of Microsoft's code I'm convinced it still percolates down to basically the same code to load/launch a module, so the traits remain. And since the shell APIs are mostly just alternate wrappings for standard Win32 APIs, it percolates to there as well. I don't think we need to bother with test cases for this, we could apply some common sense instead. A quick test shows that both WinExec and LoadModule actually just return 33 when they succeed, so we could(/should?) let hInstApp always reflect load status the same way that WinExec/LoadModule does, regardless of the flags. That's the most polite to users of ShellExecuteEx. Then they can error branch on either one. In case of doubt, always wear both belt and suspenders ;) if (ShellExecuteExW( &sei ) == FALSE) return E_FAIL; if ((INT) sei.hInstApp <= 32) return E_UNEXPECTED; Best Regards // Love victor martinez <vicmarcal(a)hotmail.com <mailto:vicmarcal@hotmail.com>> wrote: > > - if (sei.hInstApp <= (HINSTANCE)32) > + if ((INT)sei.hInstApp <= 32) > > As you see i am just learning, so thanks in advance. > To enlighten You: If you look at the assembly listing, You'll see that those two variants generate exactly the same code. Best Regards // Love

1 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 April 2010