Ros-dev September 2008

ros-dev@reactos.org

24 participants
30 discussions

Re: [ros-dev] [ros-diffs] [sginsberg] 36428: - Add basic tracing to CmpReferenceKeyControlBlock, CmpDereferenceKeyControlBlock and CmpDereferenceKeyControlBlockWithLock
by Alex Ionescu 23 Sep '08

23 Sep '08

Do you think you could maybe turn OFF debugging by default so that not every build gets spammed with this code? On 23-Sep-08, at 10:15 AM, sginsberg(a)svn.reactos.org wrote: > Author: sginsberg > Date: Tue Sep 23 09:15:56 2008 > New Revision: 36428 > > URL: http://svn.reactos.org/svn/reactos?rev=36428&view=rev > Log: > - Add basic tracing to CmpReferenceKeyControlBlock, > CmpDereferenceKeyControlBlock and > CmpDereferenceKeyControlBlockWithLock > > Modified: > trunk/reactos/ntoskrnl/config/cmkcbncb.c > > Modified: trunk/reactos/ntoskrnl/config/cmkcbncb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/config/cmkcbncb.c… > = > = > = > = > = > = > = > = > ====================================================================== > --- trunk/reactos/ntoskrnl/config/cmkcbncb.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/config/cmkcbncb.c [iso-8859-1] Tue Sep 23 > 09:15:56 2008 > @@ -354,6 +354,9 @@ > NTAPI > CmpReferenceKeyControlBlock(IN PCM_KEY_CONTROL_BLOCK Kcb) > { > + CMTRACE(CM_REFERENCE_DEBUG, > + "%s - Referencing KCB: %p\n", __FUNCTION__, Kcb); > + > /* Check if this is the KCB's first reference */ > if (Kcb->RefCount == 0) > { > @@ -570,6 +573,8 @@ > { > LONG OldRefCount, NewRefCount; > ULONG ConvKey; > + CMTRACE(CM_REFERENCE_DEBUG, > + "%s - Dereferencing KCB: %p\n", __FUNCTION__, Kcb); > > /* Get the ref count and update it */ > OldRefCount = *(PLONG)&Kcb->RefCount; > @@ -602,6 +607,9 @@ > CmpDereferenceKeyControlBlockWithLock(IN PCM_KEY_CONTROL_BLOCK Kcb, > IN BOOLEAN LockHeldExclusively) > { > + CMTRACE(CM_REFERENCE_DEBUG, > + "%s - Dereferencing KCB: %p\n", __FUNCTION__, Kcb); > + > /* Sanity check */ > ASSERT_KCB_VALID(Kcb); > > Best regards, Alex Ionescu

2 2

Re: [ros-dev] [ros-diffs] [cwittich] 36368: sync msiexec with wine 1.1.5
by Aleksey Bragin 21 Sep '08

21 Sep '08

I wonder why this A/W mess? WBR, Aleksey. On Sep 21, 2008, at 4:00 PM, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Sun Sep 21 07:00:07 2008 > New Revision: 36368 > > URL: http://svn.reactos.org/svn/reactos?rev=36368&view=rev > Log: > sync msiexec with wine 1.1.5 > > Modified: > trunk/reactos/base/system/msiexec/msiexec.c > trunk/reactos/base/system/msiexec/service.c

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 36379: preprocess all spec files
by Aleksey Bragin 21 Sep '08

21 Sep '08

There is a big problem with this change, originally this was added only for "our own" .spec files, which don't have comments starting with #. Wine .spec files have such comments, and thus will be preprocessed incorrectly. WBR, Aleksey. On Sep 21, 2008, at 6:34 PM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sun Sep 21 09:34:48 2008 > New Revision: 36379 > > URL: http://svn.reactos.org/svn/reactos?rev=36379&view=rev > Log: > preprocess all spec files > > Modified: > branches/ros-amd64-bringup/reactos/tools/rbuild/backend/mingw/ > modulehandler.cpp > > Modified: branches/ros-amd64-bringup/reactos/tools/rbuild/backend/ > mingw/modulehandler.cpp > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/ > reactos/tools/rbuild/backend/mingw/modulehandler.cpp? > rev=36379&r1=36378&r2=36379&view=diff

2 2

who create the physical device object of scsi disk
by 钢陈 20 Sep '08

20 Sep '08

Hi, I just joined in the mail list and I want to ask a question. I have a question about scsiport module. I have seen the code scsiport.c and tried to find where it create the physical device object for scsi disk however I didn't find it. I just saw the function SpiScanAdapter which would send inquiry scsi command to scsi miniport driver. So I want to know who create the pdo for scsi disk? Gang Chen

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 36337: - Zero the memory after we allocate it
by Aleksey Bragin 20 Sep '08

20 Sep '08

I think if it's a generic buffer-allocating function, its callers should not rely on the memory being zeroed. (like they don't rely on pool and heap allocations, unless called with zero-heap flag). At least the comments to the function does not say "it returns a zeroed buffer". WBR, Aleksey. On Sep 20, 2008, at 4:31 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Sep 19 19:31:02 2008 > New Revision: 36337 > > URL: http://svn.reactos.org/svn/reactos?rev=36337&view=rev > Log: > - Zero the memory after we allocate it > > Modified: > branches/aicom-network-fixes/drivers/network/tcpip/tcpip/pool.c

1 0

Re: [ros-dev] [ros-diffs] [janderwald] 36295: - Update Status Icon when there is activity - Also update the Taskbar Notification Icon
by gedmurphy 18 Sep '08

18 Sep '08

Our LoadIcon is broken and can result in badly drawn / ugly icons. You should use LoadImage instead. LoadIcon is deprecated anyway, no one should be using it anymore. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of janderwald(a)svn.reactos.org Sent: 17 September 2008 22:59 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [janderwald] 36295: - Update Status Icon when there is activity - Also update the Taskbar Notification Icon + hIcon = NULL; + if (pContext->dwInOctets == IfEntry.dwInOctets && pContext->dwOutOctets == IfEntry.dwOutOctets && pContext->Status != 0) + { + hIcon = LoadIcon(netshell_hInstance, MAKEINTRESOURCE(IDI_NET_IDLE)); + pContext->Status = 0; + } + else if (pContext->dwInOctets != IfEntry.dwInOctets && pContext->dwOutOctets !=

1 0

On the use of stabs
by Samuel serapion 17 Sep '08

17 Sep '08

In my recent endeavors into porting ReactOS to the amd64 architecture I have discovered that the the x86_64-pc-mingw32 target uses DWARF debugging symbols by default. The reason for this change was very simple, stabs are strictly 32bit. A stabs record only has 32 bits to represent an address, it represents less information, was never properly standardized, so gdb is pretty much the only debugger which can handle gcc stabs in their full glory, and it is larger to boot. DWARF is better in every aspect. There is no reason to use stabs these days. encoded • does i386-mingw32 support DWARF2 ? NightStrike • the plan is that gcc4.3 will NightStrike • more specifically, it will also drop support for sjlj Dwarf 2 Unwind frames for mingw32/cygwin patch<http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html> mingw32-gcc4.3 packages are so patched afaics: http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304 Right now ReactOS has a tool called rsym that parses stabs and coff symbol data. arty • rsym was made to keep compact line number info Ask yourself: Could we eliminate an entire build step that is imposed on all ros binaries? How hard would it be to teach the kernel about DWARF? (If we really wanted to) sedwards • wine dbghelp supports pdb too sedwards • CV, PDB, Stabs and Dwarf sedwards • as far as I know Reading Material: http://dwarfstd.org/dwarf-2.0.0.pdf http://dwarfstd.org/Dwarf3.pdf

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 36275: - Add ADDRINFOW
by gedmurphy 17 Sep '08

17 Sep '08

All these recent umode network commits need to be reverted. Public definitions don't belong in a private header. As I said in my original commit " It won't build yet as it will rely on a rewrite of the network headers". When the header rewrites are committed (maybe a week from now) everything will build. It's at this point that people can get involved in getting the new umode architecture working in ros. Cheers, Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org Sent: 17 September 2008 04:07 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cgutman] 36275: - Add ADDRINFOW Author: cgutman Date: Tue Sep 16 22:07:15 2008 New Revision: 36275 URL: http://svn.reactos.org/svn/reactos?rev=36275&view=rev Log: - Add ADDRINFOW Modified: branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h Modified: branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h URL: http://svn.reactos.org/svn/reactos/branches/umode-network-branch/dll/win32/… ============================================================================== --- branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] (original) +++ branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] Tue Sep 16 22:07:15 2008 @@ -21,6 +21,18 @@ WsAsyncGetServByPort, WsAsyncTerminate, } WSASYNCOPS; + +typedef struct _ADDRINFOW +{ + INT ai_flags; + INT ai_family; + INT ai_socktype; + INT ai_protocol; + SIZE_T ai_addrlen; + PWSTR ai_canonname; + struct SOCKADDR *ai_addr; + struct ADDRINFOW *ai_next; +} ADDRINFOW, *PADDRINFOW; typedef struct _WSASYNCBLOCK {

1 0

test, please ignore
by Aleksey Bragin 16 Sep '08

16 Sep '08

Test of mailing list system operability.

1 0

Re: [ros-dev] [ros-diffs] [cwittich] 36188: sync most of rpcrt4 to wine 1.1.4
by Aleksey Bragin 13 Sep '08

13 Sep '08

I would prefer to have a log message saying what was NOT synced too. On Sep 13, 2008, at 7:52 PM, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Sat Sep 13 10:52:50 2008 > New Revision: 36188 > > URL: http://svn.reactos.org/svn/reactos?rev=36188&view=rev > Log: > sync most of rpcrt4 to wine 1.1.4

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 September 2008