You could spend all the time the universe has existed so far and still not find the real cause. Just shrug, say "Win 11 and 24H2 are the biggest pile of steaming, mal-odious manure in the universe", and forget about it and live in peace, Jorge.

Yeah, *I* could do that, but then a new Windows 11 user would install a Winstep application, see that it is using more CPU than he personally feels comfortable with (and indeed much more than it should), happily blame the application rather than Windows 11 24H2, and uninstall it.

Users rarely realize - or indeed even care - if a bug or issue is actually not the fault of the application itself, but some 3rd party stuff or yet another change Microsoft has made to Windows.

Given how disruptive the blank UWP app icons are and since I just fixed the issue here, I decided to issue another private beta (Beta 2) soon after the first.

Ok, here are the links to the betas:

WARNING: These are updates and MUST be installed ON TOP of an EXISTING Nexus Ultimate v25.2 or Winstep Xtreme v25.2 installation. Please make sure your license keys will still work with the new betas.

DO NOT install these betas if you have multiple monitors running with different DPIs, work on adding per-monitor high DPI support is not finished yet.

To install the betas, download the relevant file for you from the links below then EXIT all running Winstep applications before running Setup.

Winstep Xtreme v25.6 BETA 2:

https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate v25.6 BETA 2:

https://www.winstep.net/ultimate-beta.zip

just fiddling around with workshelf. I see around a 3% drop in cpu usage if i disable the internet adapter.

Does that happen if you do that on the setup you have?

Not really.

Then again it's not at that phase where it is using >1% of CPU usage.

Yeah, I got to learn about that problem way back in the '90s, in my beta testing and coding days in unices (NeXT, Solaris, etc.). Luckily, users there were mostly a bit more intelligent and at least would report the problem, and we then were able to disabuse them of their ideas that the app was to blame when really it was another 3rd party app or, extremely rarely, some anomaly in the OS. To some degree the same could be said for OS/2 Warp users.

*But*, you still could end up hunting for the cause till the cows come home and still never find the answer Jorge. Such is the perversity of Win 11.

More good news!

The most difficult part - getting the GUI to support per-monitor high DPI settings and automatically re-size itself when moving it between monitors with different DPIs - is nearly completed, what is left is mostly "grunt" work.

Nearly there!

WorkShelf is nearly done. Boy, has this been a lot of work! WorkShelf has nearly 150 different windows/dialog boxes which must be tweaked one by one in order to support per-monitor high DPI settings.

Some dialogs/windows (mostly the settings dialogs) are pretty straightforward and most of the work is automated (e.g. window sizes and controls are repositioned and resized automatically when they cross from one monitor to the other) others are a complete nightmare to get to work properly, especially if they are 100% graphical or have bitmap components.

In the end it will be worth it, but boy oh boy...

Have a cold beer and a break from time to time Jorge - I can well imagine what exhausting work this all is! Holy smoke!

Be nice though to be able to use different resolutions and DPIs, especially in re: this new laptop. I hate that little 14 in. screen with a passion, never had any 14 in. laptops or screens before. It's really awkward using its two highest resolutions when I connect it to the external monitor and duplicate the display. With the variable High DPIs I can then use different resolutions and don't have to put up with the quite small displays in the VMs any more.

So definitely worthwhile in the end.

Yeah, it is actually pretty intense lol Anyway, WorkShelf/Nexus Ultimate/Nexus is completely done! Now on to the NextSTART UI...

Phew, major kudos to you Jorge! And in this heat, too. Thank goodness NS UI should be a bit less work, although still more than enough if I'm not mistaken.

Time for a break! You and me both. Mine's going to be a half a pint of warm beer aka Real Ale - always drunk at room temperature. Alas, I can't drink much because of medication, and at this rate what's left of my flagon of ale might go off.

---

#The Lunatics, have taken over the Asylum# - Funboy Three/The Specials

Ok, WorkShelf, NextSTART, Nexus Ultimate and Nexus are now ALL per monitor DPI compatible. Only a few loose ends to take care of.

Move a dock, menu, etc, or dialog to a monitor with a different DPI and it will resize automatically accordingly to that monitors current DPI settings. All screen objects (docks, shelves, taskbar, etc) will size themselves automatically according to the DPI of the monitor they are currently on.

If you change the DPI settings of a secondary monitor, any object(s) in it will also resize automatically.

This said, there is ONE MAJOR (?) LIMITATION: if you change the DPI of the *primary* monitor while the Winstep application is running (or make another monitor primary and this new primary monitor has another DPI) then the Winstep application MUST be restarted.

This is because the Development Environment itself used to develop Winstep applications is old and not per-monitor DPI compatible. As such, it internally caches the DPI of the primary monitor (system DPI) and doesn’t auto-update. If the Winstep application continues to run under this condition it becomes visually broken (although docks, etc, will resize appropriately, any dialogs shown in the primary monitor will appear at the wrong size, etc...).

In theory it is possible to work around this, but it would be a lot of work (a bit like rowing against the tide) and a potential source of many insidious bugs... and is it worth it? I mean, how many times do users change the DPI settings of their primary monitors?

So, what I intend to do - and, again, only if the user changes the DPI of the Primary monitor while the Winstep application is running - is prompt the user when the application detects this event with a message like "The display scale setting of the primary monitor has changed. This application must restart to continue working properly (it will restart automatically in a moment).” and then automatically restart the application(s) after a short 2-3 second delay.

Upon restarting the application will assume the new DPI setting of the primary monitor and adjust accordingly.

What do you guys think?

2-3 secs is way too short - why not let the user configure a time in Prefs, if that's not a lot of hassle to do? Otherwise, I'd suggest somewhere between 5 and 10 secs perhaps.

Oh, and a workaround defo sounds way too much hassle.