Re: [ros-dev] [ros-diffs] [ion] 24595: - Implement DbgkpQueueMessage. This is the main bi-directional communication routine for the newer non-LPC Debug Object. - Implement DbgkPostFakeProcessCreateMessages (and stub DbgkpPostFakeThreadMessages and DbgkpPostFakeModuleMessages). These are required when attaching to a process after threads have been created and modules loaded, so that the debugger can have a valid state. - Still missing the two functions to Set/Clear the Debug Object, will do these next.

[Thomas Weidenmueller]

>   -        RtlCopyMemory(StateChange,
>  +        /* Return our wait state change structure */
>  +        RtlMoveMemory(StateChange,
>                         &WaitStateChange,
>                         sizeof(DBGUI_WAIT_STATE_CHANGE)); 
RtlMoveMemory doesn't really make sense as the destination and source
are never overlapping, resulting in unnecessary overhead.

- Thomas

[Alex Ionescu]

Thomas Weidenmueller wrote:
> >  -       
> > RtlCopyMemory(StateChange,
> > +        /* Return our wait state change structure */
> > +        RtlMoveMemory(StateChange,
> >                        &WaitStateChange,
> >                        sizeof(DBGUI_WAIT_STATE_CHANGE)); 
>  
>  
>  RtlMoveMemory doesn't really make sense as the destination and source
>  are never overlapping, resulting in unnecessary overhead.
>  
>  - Thomas
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   
Exactly, isn't RtlCopy *slower* because it handles overlapping cases,
and Move is faster because it doesn't?

-- 
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS

[Alex Ionescu]

Alex Ionescu wrote:
>   Thomas Weidenmueller wrote:
>  
> > >  -       
> > > RtlCopyMemory(StateChange,
> > > +        /* Return our wait state change structure */
> > > +        RtlMoveMemory(StateChange,
> > >                       &WaitStateChange,
> > >                       sizeof(DBGUI_WAIT_STATE_CHANGE)); 
> >
> > RtlMoveMemory doesn't really make sense as the destination and source
> > are never overlapping, resulting in unnecessary overhead.
> >
> > - Thomas
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  
>  
>  Exactly, isn't RtlCopy *slower* because it handles overlapping cases,
>  and Move is faster because it doesn't?
>   
Well since Thomas never replied I'll do it myself. RtlCopy is, in fact,
the faster variant. I was about to change all the Nt code but Thomas did it.

-- 
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS

[Thomas Weidenmueller]

>   Well since Thomas never replied I'll do it myself.
> RtlCopy is, in fact,
>  the faster variant. I was about to change all the Nt code but Thomas did it. 
Oops, in fact I did reply. I just used the wrong email address so it
never got through :(

Yes, RtlCopyMemory <=> memcpy doesn't handle overlapping regions and is
faster. RtlMoveMemory <=> memmove handles overlapping regions.

- Thomas