Re: Seeking info on wParam and lParam

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

"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.


.

Relevant Pages

  • Re: Seeking info on wParam and lParam
    ... >> wParam was a 'signal' on the stack and the lParam was a ES:SI type ... >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)