News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Attention, Win10 != Win7

Started by jj2007, August 30, 2022, 10:05:17 PM

Previous topic - Next topic

jj2007

The WM_DRAWITEM message gives you in lParam a pointer to a DRAWITEMSTRUCT.
The itemState member can assume, under Win7-64, one or more of these values:

ODS_SELECTED                         equ 1h
ODS_GRAYED                           equ 2h
ODS_DISABLED                         equ 4h
ODS_CHECKED                          equ 8h
ODS_FOCUS                            equ 10h
ODS_DEFAULT                       equ 20h
ODS_COMBOBOXEDIT                  equ 1000h
ODS_HOTLIGHT                      equ 40h
ODS_INACTIVE                      equ 80h


Here are some not contained in Windows.inc:
#if(WINVER >= 0x0500)
#define ODS_HOTLIGHT        0x0040
#define ODS_INACTIVE        0x0080
#if(_WIN32_WINNT >= 0x0500)
#define ODS_NOACCEL         0x0100
#define ODS_NOFOCUSRECT     0x0200


When clicking on a pushbutton, on Win7-64 I get one of these two item states:

10h=ODS_FOCUS
11h=ODS_FOCUS or ODS_SELECTED


On Win10, it's different:

310h=ODS_FOCUS or ODS_NOACCEL or ODS_NOFOCUSRECT
311h=ODS_FOCUS or ODS_SELECTED or ODS_NOACCEL or ODS_NOFOCUSRECT


The practical relevance is limited, but I guess it's good to know :cool:

daydreamer

Quote from: jj2007 on August 30, 2022, 10:05:17 PM
The WM_DRAWITEM message gives you in lParam a pointer to a DRAWITEMSTRUCT.
The itemState member can assume, under Win7-64, one or more of these values:

ODS_SELECTED                         equ 1h
ODS_GRAYED                           equ 2h
ODS_DISABLED                         equ 4h
ODS_CHECKED                          equ 8h
ODS_FOCUS                            equ 10h
ODS_DEFAULT                       equ 20h
ODS_COMBOBOXEDIT                  equ 1000h
ODS_HOTLIGHT                      equ 40h
ODS_INACTIVE                      equ 80h


Here are some not contained in Windows.inc:
#if(WINVER >= 0x0500)
#define ODS_HOTLIGHT        0x0040
#define ODS_INACTIVE        0x0080
#if(_WIN32_WINNT >= 0x0500)
#define ODS_NOACCEL         0x0100
#define ODS_NOFOCUSRECT     0x0200


When clicking on a pushbutton, on Win7-64 I get one of these two item states:

10h=ODS_FOCUS
11h=ODS_FOCUS or ODS_SELECTED


On Win10, it's different:

310h=ODS_FOCUS or ODS_NOACCEL or ODS_NOFOCUSRECT
311h=ODS_FOCUS or ODS_SELECTED or ODS_NOACCEL or ODS_NOFOCUSRECT


The practical relevance is limited, but I guess it's good to know :cool:
curious if its possible to solve with compability options?
my none asm creations
https://masm32.com/board/index.php?topic=6937.msg74303#msg74303
I am an Invoker
"An Invoker is a mage who specializes in the manipulation of raw and elemental energies."
Like SIMD coding

TimoVJL

May the source be with you

jj2007

#3
Nice page, Timo :thumbsup:

Raymond Chen is always a good read. The next article is about SSE registers:

QuoteThere are a few ways to load constants into SSE registers.

Load them from memory.
Load them from general purpose registers via movd.
Insert selected bits from general purpose registers via pinsr[b|w|d|q]
...
    pxor    xmm0, xmm0 ; set all bits to zero

    pcmpeqd xmm0, xmm0 ; set all bits to one
    psrld  xmm0, 31    ; all 32-bit lanes contain 0x00000001
...
Intel suggests loading 1 into all lanes with the sequence

    pxor    xmm0, xmm0 ; xmm0 = { 0, 0, 0, 0 }
    pcmpeqd xmm1, xmm1 ; xmm1 = { -1, -1, -1, -1 }
    psubd   xmm0, xmm1 ; xmm0 = { 1, 1, 1, 1 }

zedd151

Quote from: jj2007 on August 31, 2022, 02:06:28 AM
Raymond Chen is always a good read.
I fully agree.
Quote
There are a few ways to load constants into SSE registers.
Cool, I'll look at using some of that for if/when I revisit my Prime Sieve algorithm.  :biggrin:
Edit == correction


Side note: Thank god that Windows 7 != Windows 10. I'd have to leap off a bridge.  :tongue:
As a side side note: Too bad that Windows xp is no longer a viable option.


jj2007

Quote from: Swordfish on August 31, 2022, 02:15:45 AMSide note: Thank god that Windows 7 != Windows 10.

For the last 20 years or so, you could be sure that older programs behaved exactly the same on every new version of Windows. This is the first time that this rule is not true...

P.S.: Raymond at its best:

QuoteThe Find­Resource­Ex function is an extension of the Find­Resource function in that it allows you to specify a particular language fork in which to search for the resource. Calilng the Find­Resource function is equivalent to calling Find­Resource­Ex and passing zero as the wLanguage.

Except for the horrible nasty gotcha: The second and third parameters to Find­Resource­Ex are in the opposite order compared to the second and third parameters to Find­Resource!

I just tested that because I couldn't believe it, and it's true :rolleyes:

NoCforMe

Quote from: jj2007 on August 31, 2022, 03:27:56 AM
QuoteThe Find­Resource­Ex function is an extension of the Find­Resource function in that it allows you to specify a particular language fork in which to search for the resource. Calilng the Find­Resource function is equivalent to calling Find­Resource­Ex and passing zero as the wLanguage.

Except for the horrible nasty gotcha: The second and third parameters to Find­Resource­Ex are in the opposite order compared to the second and third parameters to Find­Resource!

I just tested that because I couldn't believe it, and it's true :rolleyes:

Yes, pretty astounding. I thought that even at Micro$oft the Prime Directive was always "Don't break shit!*" Apparently not ...

* At least this is the impression one gets from reading Raymond's blog.
Assembly language programming should be fun. That's why I do it.