I'm going to try to tackle per-monitor high DPI support.

As most of you know, Winstep applications are *system* high DPI compatible (i.e. scaling, as in 100%, 125%, etc) but they are not *per-monitor* high DPI compatible (something that was introduced in Windows 10 just to complicate things at a time when applications were *just beginning* to become high DPI compatible).

In practice this means the Winstep application will correctly assume whatever DPI scaling is set for the primary monitor BUT will also use that same scaling on ALL other monitors, regardless of their actual scale setting.

The system will automatically scale up (or down) Winstep objects that have a scaling different from that of the monitor they are currently in (as it did in Windows 10 with all the blurriness that this implied) BUT that has a huge (and serious) drawback: at the same time Windows will LITERALLY lie to the Winstep application about the screen resolutions of the monitors that do not have the same DPI settings as the primary.

This can and will result in missing monitors in the list of available monitors, objects not appearing where they should, reserved screen areas that are either too large or too small, etc, etc...

In practice this means that on multi-monitor systems running a Winstep application ALL the monitors must have the SAME DPI settings (e.g. all 100% or all 125%) otherwise you will experience problems.

I am going to try to tackle this issue in the next release, but it's not going to be easy as the programming platform Winstep applications was written on was never prepared for this, and it involves resizing windows, screen objects and user controls "on the fly" as screen objects are moved from one monitor to the other.

Bit of progress report:

So the applications are now per-monitor DPI aware, and I have already gotten desktop modules to automatically scale themselves up or down as you move them between monitors with different DPIs.

Doing the same to docks, shelves, drawers and grid stacks should be relatively straightforward too as they share much of the same code.

However, this is still a very complex issue, the devil being in the details and with many details to take care of.

For instance, the automatic multi-monitor profiles should also take into account changes in monitor DPI (as objects will grow smaller or larger according to the current DPI, so their relative position might have to change, as in the case of desktop modules). Doing this, however, means that we will probably lose backwards compatibility with the monitor profiles of older versions (still trying to think of a way to prevent this, but I am not sure if it's possible).

If we are doing that, then perhaps we should also take into account Virtual Desktops (now would be a good time, but I am not sure I want to add yet another layer of complexity to what is already a complex process).

My guess is that the most complicated thing - and the reason I am leaving it for last - will be resizing the Preferences screens with all those controls, etc, as the user moves them between monitors with different DPIs.

EDIT: Menus are now per monitor DPI compatible too.

Holy smoke, that's a heck of a lot of work Jorge, well done. As re: backward compatibility, How difficult/practical would it be to have two different versions - one that's still backwards compatible, and one that's got the bells and whistles? (Never mind, I can see that this would be a real PITA long term, maintaining two separate versions.)

In re: Virtual Desktops and per VD DPI - I can see that would be another can of worms. Perhaps best to wait and see if the per monitor DPI stuff throws up any problems with users first and tackle VDs later?

Goodness knows also what crap Win 11 might yet throw into the works of VDs! :

Abandoned VDs under Win almost straight away myself, although under Linux I tend to use them extensively - far superior implementation.

Docks, shelves, drawers, grid stacks, menus and desktop modules are all per-monitor high DPI compatible now. If you drag one of the those objects onto a monitor with a different DPI, it will now automatically resize according to the DPI of the target monitor.

Alarm pop ups, balloon tooltips, dock labels, are now per-monitor high DPI compatible too.

Monitor profiles now take the DPI settings of each monitor into account too...

Still a lot to do, but trodding along.

Ok, WorkShelf/Nexus Ultimate/Nexus done (except for the GUI), now going to start focusing on NextSTART screen objects (menus are already done, so that means taskbar, tasklist, system tray - what's left of it after what Microsoft did - and hotspot buttons on the desktop).

Once that is done I will finally focus on making the actual GUI per-monitor high DPI compatible. That is where I anticipate the most problems.

In the mean time I was forced to eat humble pie regarding backward compatibility of Winstep applications. You see, certain features depend on the Windows version the Winstep software is running under, for instance; OS support for blur behind for irregular shapes only became available in Vista and was removed (!!!) by Microsoft in Windows 10.

I was always VERY careful in the code to only use certain features and Windows API calls if the version of Windows the software was running under supported them. This ensured backwards compatibility all the way back to Windows 2000/XP, i.e. some features might be missing if you decided to run a Winstep application on, say, Windows XP but the program would still run and not crash.

The problem is that at a certain point Microsoft started using OLE interfaces rather than pure WIn32 API calls to perform most new functions. Given the age and limitations of the programming environment used to develop Winstep applications, which does not offer native support for the newer (at the time) Windows OLE interfaces, at some point I made a decision to use 3rd party TLB files for interface and API definitions rather than in-code Declare statements (very tricky to define interfaces and their methods via the latter system).

if a certain API call defined in the code via a Declare statement does not exist in the target OS and you attempt to use it, an error will occur during application runtime - this error can be (silently) trapped and execution resumed, the user being none the wiser (or you can do like I did and only call those functions if the current OS supports them, skipping them if not).

While apparently the same thing (and I had no reason to think otherwise), what I did not know at the time - and mind blowingly enough only found out very recently - is that the application will actually crash at startup with an 'Entry point not found' error if you use an API call or interface defined by a TLB file rather than by an in-code Declare statement. In other words, in that case the application won't even get to run.

Unfortunately in the most recent releases I am using a method defined by a TLB file that is only supported from Windows 7 onward. As a result, Nexus, Nexus Ultimate, WorkShelf and NextSTART will all crash at startup if you try to run them on any version of Windows prior to Windows 7.

Much to my chagrin I was forced to update the compatibility list for those Winstep applications on the website and remove Vista and Windows XP from the compatibility list. I could still try to fix the issue by attempting to convert those specific TLB references into actual code, but it would be a huge effort and for what? I mean, how many people are still running Windows XP these days?

That's a real bummer re: TLB files. As for XP, I know some people who still use XP and regularly come across others still running that and even the odd Win 2K. I myself have a miniscule XP partition on my main Linux box, needed for support of a piece of peripheral hardware.

Oops, forgot to mention that none of the obscure OS users are Winstep users. (Apart from myself. ) I'd think that we'd probably have heard quite some time back if there had been any pre-Win 7 users with problems...

Long time users, sure, but first time users, nah. They install, run, get an immediate error, uninstall and never go back until they upgrade their version of Windows to something more recent.

NextSTART taskbar, the tasklist and hotspot buttons are now also *per-monitor* high DPI compatible.

In the process of revising the code (some of it very old!) I found - and fixed - multiple bugs, some related to the per monitor taskbars (e.g. secondary taskbars might not be colorized properly 'on the fly') and some related to high DPI compatibility (e.g. hotspot buttons would retain the same size regardless of monitor DPI).

In the mean time I have come to the conclusion that the systray part of NextSTART has to be completely re-written in order to make it *per-monitor* high DPI compatible. Given that it still features code going back two decades (when the OS was very different), it is better to rewrite it than to try to glue very old stuff together with spit.

In other news, some of you may have noticed that Stardock's Wincustomize (the main repository for Winstep themes, linked to from the Winstep website) has been down for over two weeks due to what at this point looks like the result of a catastrophic cyber-attack.

Hopefully Stardock will be able to fully recover from this and the site will be back up soon.

This being indeed due to a cyber-attack, it angers me no end how a bunch of low end criminals can put the livelihood of so many people - and indeed a whole company - at risk like this. I can only imagine the stress the people who work at Stardock have been going through for the past couple of weeks - I wish them all the best.

On a personal level, Brad, Stardock's CEO and owner who created what is today a multi-million dollar company from his university dorm room, certainly did not deserve this (nor would anyone, but...).

With DeviantArt these days focusing on their own thing, Wincustomize being gone forever would signal the end of an entire era, as it is the last of the big skins/themes repository sites. Let's hope it does not come to that.

The possibility of 3rd party repositories for Winstep themes suddenly disappearing (although I would never imagine this exact reason in a million years) is exactly why Winstep some years ago created a local "bare-bones" Winstep themes gallery into which some hand picked authors have uploaded all their themes (it now stores over 160 different themes, which still does not compare to the nearly 750 Winstep themes stored at Wincustomize).

This gallery is not yet open to the public for various reasons - mainly because although fully functional, it is indeed bare bones and also lacking in the cosmetics department - but at least not all would be lost, as it happened many years ago to hundreds of NextSTART themes when Skinz.org closed due to the eFront scandal (old timers will remember this story).

WinCustomize is back up!

For the moment still in "read-only" mode, but what matters is that it has been raised from the dead.

On Tuesday, April 1st, Winstep also had its own hiccup (and no, it wasn't an April Fools joke eheh): as announced, there was a scheduled intervention on the Winstep server to replace the 7 year old SSD where the OS is installed with a brand new and larger SSD.

To cut a long story short, what was supposed to take less than an hour ended up taking nearly 10 hours, with the Winstep website (and the server) offline for most of that time.

A simple and quick disk cloning operation turned into a situation where it became necessary to fully restore from a previous backup. Fortunately the backup was less than a day old and therefore data loss was minimal.

Ok, I think I may have "fixed" a situation where WorkShelf was using a bit more CPU than what it normally did under Windows 11 until a couple of versions ago.

I suspect this had to do with with using performance counters to get CPU usage data for "System Interrupts" and to get the CPU Utility value (the total CPU Usage value reported by the Windows Task Manager under Windows 11) which was being retrieved even when 'Use Legacy Mode' setting was enabled in the CPU Meter module settings.

On my 12900K system with 24 virtual cores (8 physical performance cores + 8 physical efficient cores + 8 hyper threaded cores) WorkShelf was using about 1.4% while idle. Now, let's not make a big deal out of this has 1.4% out of 24 cores is pretty negligible, but that is still about 35% of a single core, much more than it should have been.

With the changes I applied WorkShelf is now back to using less than about 0.4% while idle (or about 10% of a single core). This with Wanda swimming on the desktop, multiple desktop modules open that need to be refreshed sometimes multiple times per second, etc...

Talking about CPU usage I would like to remind users of the existence of the 'Power Saving Mode' internal command and feature.

Primarily intended to save battery power on laptop systems, this is accomplished by reducing the CPU usage of the Winstep application, which in turn is accomplished by reducing the frequency in which things are updated, disabling non critical animations, etc... (see full list of what it does by clicking on the link above). If CPU usage of the Winstep applications is one of your concerns (really?) then running the application with the Power Saving Mode set to Normal rather than the default disabled might be for you.

Pressing the SHIFT key while right clicking an item in a dock/shelf/etc will now display the FULL right click menu even if this has been disabled in Preferences.

Also added a new 'Activate All' internal command to WorkShelf and Nexus which shows all enabled docks, shelves, drawers and desktop modules and brings them all to the foreground. The difference between this and the existing 'Bring WorkShelf Forward' IC is that this, besides bringing them to the foreground, will also show any hidden docks/desktop modules and expand shelves and drawers.

Work also continues on making Winstep applications per-monitor high DPI compatible (warned it was not going to be a simple thing).