Re: Seeking info on wParam and lParam

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

On Wed, 24 Aug 2005 19:32:32 -0700, "Sam Hobbs"
<samuel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>"J French" <erewhon@xxxxxxxxxx> wrote in message
>news:430c6fb3.103511928@xxxxxxxxxxxxxxxxxxxxxxx
>>
>> 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
>
>What signal on what stack? I sure have not heard of a Windows message having
>any relevance to a stack.
>
>I think you mean "segment:offset" instead of "ES:SI". ES (Extra Segment) is
>one of several segment registers and SI (Source Index) is one of several
>offset registers. Far pointers can exist in a combination of other registers
>and in memory in segment:offset format. The format used for storing far
>pointers in memory (segment:offset) is used in messages as well. It is not
>possible to use registers in messages.
>
>In the 16-bit (real mode) world, all far pointers are segment:offset type of
>pointers.
>
>> 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 )
>
>It is certainly more useful to have 32 bits instead of 16 bits, but I can't
>think of any significant performance improvements. For example, 32 bits
>allow more data in an edit control (text box). Also, 32 bits allow greater
>scroll limits for scroll boxes.
>
>> Realistically it was just an opportunity for 'fine tuning'
>> - also future development (widening wParam opens unused options)
>
>Yes, it did simplify future development. I believe that 64-bit Windows has
>64 bits for wParam and lParam. It was probably relatively easy to make that
>improvement, since most of the work necessary for it (generalization of the
>headers is a large part of that) was done in the conversion from 16-bits to
>32-bits.

Yawn

Someone has never heard of DWORD alignment
.

Relevant Pages

  • Re: Seeking info on wParam and lParam
    ... > wParam was a 'signal' on the stack and the lParam was a ES:SI type ... What signal on what stack? ... one of several segment registers and SI is one of several ... pointers in memory is used in messages as well. ...
    (microsoft.public.vb.winapi)
  • Re: @Result and parameter addresses read not from stack
    ... from the stack. ... Now these pointers are loading only from registers which are ...
    (borland.public.delphi.language.basm)
  • Re: 8051 development board in India
    ... >> One thing gcc can't handle is when pointers to different types ... first one or two parameters are often passed in registers. ... in general gcc expects to be able to use a stack for parameters ...
    (comp.arch.embedded)
  • Re: Bounds checked arrays
    ... The pointers themselves need not grow ... a stack oriented machine will have an entry for the ... Exit from a stack frame will ...
    (comp.lang.c)
  • Re: Question about value types
    ... Variables and constants are storage locations with names. ... Variables can be located on the heap or on the stack. ... Pointers are stored on the stack, ...
    (microsoft.public.dotnet.languages.csharp)