News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Recent posts

#61
Windows Graphics Programming / setting the Title bar color of...
Last post by LordAdef - April 22, 2025, 05:04:00 AM
Hi fellow Masmers!

I have no idea, but I reckon this is the place to ask this. Modertor, correct me if I'm wrong

I need to change the color of my Title bar window, or.. make my window dark style.

I don't know if Microsoft makes things like this just to torture us, but it shouldn't be that hidden.

Anyway, any help would be very appreciated!
Alex
#62
MASM64 SDK / Re: Masm64 SDK ignores "uses"
Last post by jj2007 - April 21, 2025, 09:35:12 PM
With an AMD:
AMD Athlon Gold 3150U with Radeon Graphics
*
pushing took 1109 ms
moving  took 1110 ms
nc pushing took 1140 ms
nc moving  took 1110 ms
pushing took 1125 ms
moving  took 1125 ms
nc pushing took 1140 ms
nc moving  took 1125 ms
pushing took 1125 ms
moving  took 1125 ms
nc pushing took 1140 ms
nc moving  took 1125 ms
pushing took 1125 ms
moving  took 1141 ms
nc pushing took 1140 ms
nc moving  took 1141 ms

In short: no difference, and the justification of this horrible ABI that "moving is faster than pushing" is bulls*it.
#63
MASM64 SDK / Re: Masm64 SDK ignores "uses"
Last post by zedd - April 21, 2025, 10:12:31 AM
Quote from: jj2007 on August 29, 2023, 11:27:19 PMIntel(R) Core(TM) i5-2450M CPU @ 2.50GHz
*
pushing took 983 ms
moving  took 1139 ms
nc pushing took 1030 ms
nc moving  took 936 ms
pushing took 1045 ms
moving  took 1139 ms
nc pushing took 1014 ms
nc moving  took 952 ms
pushing took 998 ms
moving  took 1201 ms
nc pushing took 1014 ms
nc moving  took 936 ms
pushing took 967 ms
moving  took 1263 ms
nc pushing took 1030 ms
nc moving  took 951 ms

IMHO there should be a call, since we are talking about the best way to implement "uses rsi rdi". Anyway, it's an interesting result :cool:

Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
*
pushing took 594 ms
moving  took 610 ms
nc pushing took 593 ms
nc moving  took 610 ms
pushing took 593 ms
moving  took 625 ms
nc pushing took 594 ms
nc moving  took 578 ms
pushing took 610 ms
moving  took 609 ms
nc pushing took 594 ms
nc moving  took 594 ms
pushing took 609 ms
moving  took 609 ms
nc pushing took 610 ms
nc moving  took 593 ms
:biggrin:  I'm kinda bored atm.
#64
MASM64 SDK / Re: Masm64 SDK ignores "uses"
Last post by zedd - April 21, 2025, 10:09:26 AM
Quote from: zedd151 on August 29, 2023, 07:22:29 AMIntel(R) Core(TM)2 Duo CPU    E8400  @ 3.00GHz
pushing took 1716 ms
moving  took 2091 ms
pushing took 1794 ms
moving  took 2090 ms
pushing took 1779 ms
moving  took 2090 ms
pushing took 1763 ms
moving  took 1934 ms

Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
pushing took 969 ms
moving  took 985 ms
pushing took 953 ms
moving  took 1000 ms
pushing took 968 ms
moving  took 985 ms
pushing took 969 ms
moving  took 984 ms
I like beating my old, slow machine.  :azn:
#65
The Campus / Re: Windows 11?
Last post by wjr - April 21, 2025, 08:07:52 AM
Ramon, on the ECPendulum issue, this would be related to the calls to DrawEllipse with the BlackWidth floating point parameter, which with the 64-bit calling convention should be passed through an XMM register.
#66
Windows API / Re: Dialog units vs. screen un...
Last post by NoCforMe - April 20, 2025, 06:56:58 AM
I think the RECT structure fit the purposes of most of those early Windows functions the best.
(In other words, Micro$oft's programmers weren't stupid.)
#67
Windows API / Re: Dialog units vs. screen un...
Last post by zedd - April 20, 2025, 06:22:22 AM
Quote from: NoCforMe on April 20, 2025, 06:15:31 AM
Quote from: zedd151 on April 20, 2025, 06:11:19 AM
Quote from: NoCforMe on April 20, 2025, 06:08:07 AM[1] Which I assume is the window size, not the client size.
Exactly - Sounds ambiguous.
Easy enough to find out which it is--just use WinSpy.

No need. I have run my tests.

Why RECT structures anyway? (Rhetorical question) Some functions need x,y,width,height. Which to me is more immediately useful information. Why not a structure for x, y, width, height instead? (Another Rhetorical question btw, no reply needed)

Using a RECT, you'd have to fiddle  :eusa_boohoo:  around to get the width and height. I guess it's pronounced "wrecked" for a reason.  :joking:
#68
Windows API / Re: Dialog units vs. screen un...
Last post by NoCforMe - April 20, 2025, 06:15:31 AM
Quote from: zedd151 on April 20, 2025, 06:11:19 AM
Quote from: NoCforMe on April 20, 2025, 06:08:07 AM[1] Which I assume is the window size, not the client size.
Exactly - Sounds ambiguous.
Easy enough to find out which it is--just use WinSpy.
#69
Windows API / Re: Dialog units vs. screen un...
Last post by zedd - April 20, 2025, 06:11:19 AM
Quote from: NoCforMe on April 20, 2025, 06:08:07 AM[1] Which I assume is the window size, not the client size.
Exactly - Sounds ambiguous.
#70
Windows API / Re: Dialog units vs. screen un...
Last post by NoCforMe - April 20, 2025, 06:08:07 AM
Quote from: zedd151 on April 20, 2025, 05:58:48 AM
Quote from: NoCforMe on April 20, 2025, 05:54:07 AMGetWindowRect() gives you the location of the window in relation to the "real world" (i.e., the desktop)...

For some reason that is what I originally thought that MapDialogRect was supposed to do. I don't remember reading anywhere that it fills in the RECT structure with the client area... if it is the MS docs, I had missed it.
It doesn't do that.
All it does is convert the dialog's coordinates in dialog units to screen units. These can give you the size[1] of the dialog by subtracting .top from .bottom and .left from .right.

QuoteConverts the specified dialog box units to screen units (pixels). The function replaces the coordinates in the specified RECT structure with the converted coordinates, which allows the structure to be used to create a dialog box or position a control within a dialog box.

[1] Which I assume is the window size, not the client size.