The feature is called "Multiple Display Monitors". Some docs can be found here...
https://learn.microsoft.com/en-us/windo ... -functions
above is only for "functions" (some web browsers are able to display a table of contents on the left of the browser window, with more multiple display monitor related chapters, not only the functions).
From what I can see, the feature does rely on a "primary screen", and additional screens that can be arranged at left or right or above or perhaps below of the "primary screen". As shown here:
https://learn.microsoft.com/en-us/windo ... ual-screen
Of those, the monitors left/above of the primary screen can have negative coordinates, which may cause problems for software that expects unsigned coordinates (although, even with a single monitor, it's possible to move a window to parts offscreen locations on left/top sides (the mouse arrow can't be move to negative coordinates on a single monitor though)).
For the fullscreen feature, the standard system metrics function reports only the size of the "primary screen". So I assume that no$xxx in fullscreen mode will properly display the game screen on that monitor at correct size.
DPI... I wasn't aware of such features. I've found something similar in win98, under Display Properties, Settings, Advanced, General, Font Size (Normal or Large, with 96 or 120 dpi).
That seems to be a driver specific setting, and it may be absent or different for other display drivers. The effect seems to be that some things like Dialog box units are getting zoomed (affecting captions, meno bars, tab controls, scrollbars - but not affecting any pixel sizes of owner drawn bitmaps). I am not sure if that is the same DPI feature as on windows 11 (?)
Some of those settings like menu bar and tab control height are important for positioning controls and child windows within another window. And no$xxx does assume that those settings are same for all windows. But even if the menu bar height varies by +/-10 pixels, that should only cause minor glitches.
---
Some more questions:
Is there still any need to fix the issue, or is it accepable simply not to use different DPI settings?
Does the problem occur on the "primary display"?
Does the problem occur on "non-primary displays"?
Or both on primary and non-primary displays?
And are the non-primary ones at negative coordinates (left/above of the primary)?
Does it make a difference to close and re-open the window after dragging it to another monitor?
Is it even possible to drag no$xxx windows to different monitors? Theoretically, my code should prevent to move windows to completely offscreen locations (whereas "offscreen" would mean outside of the primary display area) (or at least so when storing "offscreen" coordinates in the .ini file).
Speaking of the .ini file. It might be worth to have a look in there. If the display problem occurs, go to Options, Save Options in no$xxx, and then check in .ini file in a text editor. Especially these lines:
fsys_xsiz, fsys_ysiz --> Filesystem Viewer size
Vram_xsiz,Vram_ysiz --> VRAM Viewer size
Vram_xloc,Vram_yloc --> VRAM Viewer position
The size values should be always positve numbers, simething like 00000xxx.
The position should be usually positive, or negative if the window is parts offscreen, or on another display left/above of the primary display, so that might be 0000xxxx or FFFFxxxx.
Another problem would be if there any values like 0000Fxxx (negative 16bit).
