Re: Seeking info on wParam and lParam

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Wed, 24 Aug 2005 03:38:17 -0700, "Sam Hobbs"
<samuel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>"Tom Esh" <tjeshGibberish@xxxxxxxxxx> wrote in message
>news:99sng11iov9mgplaklt98aj8dvkpsusp3g@xxxxxxxxxx

>> I'd say the reason probably has to do with
>> the efficiency of pushing args into registers or the stack vs a
>> pointer. No doubt less significant today than back in the early days,
>> but I'd bet reading registers or popping values off the stack is still
>> faster than resolving a FAR pointer.

>It is not the pointer that is inefficient, it is the memory that must be
>allocated in the application's address space that is inefficient. The
>inefficiencies include fragmentation. Since there are so many messages
>processed by windows, allocation of memory for each message would be very
>inefficient, especially in systems that existed when Windows was developed.

>Whenever the mouse is moved, many WM_MOUSEMOVE messages are sent.
>Inefficient processing of that message could easily cause a system to be
>useless.

wParam and lParam come from 16 bit windows

In those days 16 bits were a lot more efficient than 32 bits, so the
wParam was a 'signal' on the stack and the lParam was a ES:SI type
pointer .. if needed

With Win32 (32 bit throughout) it is a lot more efficient to work with
multiples of 4 bytes (32 bits) so they simply lengthened the wParam (
Word Parameter )

Quite sensible, as few people would even notice

Realistically it was just an opportunity for 'fine tuning'
- also future development (widening wParam opens unused options)

Any speed changes would be insignificant
- a mouse move creates more havoc than 10,000 non optimally aligned
stack parameters



.

Relevant Pages

  • Re: Seeking info on wParam and lParam
    ... > but I'd bet reading registers or popping values off the stack is still ... > faster than resolving a FAR pointer. ... It is not the pointer that is inefficient, it is the memory that must be ...
    (microsoft.public.vb.winapi)
  • Re: Seeking info on wParam and lParam
    ... The book which I am reading covers ... >>> but I'd bet reading registers or popping values off the stack is still ... >>> faster than resolving a FAR pointer. ... >>allocated in the application's address space that is inefficient. ...
    (microsoft.public.vb.winapi)
  • Re: Inspecting messages
    ... Lines 171-175 copies registers onto the stack so they can be restored to ... destination address in edi. ... the pointer before doing an interrupt. ... What happens is that some values are pullled of the stack and stored in ax ...
    (comp.os.minix)
  • Re: how do threads work?
    ... You don't save all registers in every ... One convention would be that all registers are call ... pointer onto the stack and copy the stack pointer to the ...
    (comp.os.linux.development.system)
  • Re: Professional Forthers?
    ... Dedicated registers aren't required. ... Forth requires a stack pointer for each stack. ... correct instructions and operands from your cpu. ...
    (comp.lang.forth)