Never mind, this question is a duplicate. I might be able to figure this out from other sources.
I'm so so confused. I was working on my project and realised that the window created with CreateWindowEx() was bigger than I was specifying. I noticed the windows are bigger in release mode than in debug mode. Then I took the values of GetSystemMetrics(SM_CXSCREEN) and SM_CXFULLSCREEN and noticed that in debug mode it gives me 1920 x 1080, which is correct, but in release mode it gives me 1536 x 864.
Furthermore, if I just start a new Win32 project, which is up and ready to run just by pushing ctrl + F5, I get the wrong value in both debug AND release mode, same values as before, and the windows are bigger.
I don't see how providing any code might help, I could make a video of it, but... this just doesn't make sense. Could anyone maybe see if it happens to them by starting a new Win32 project, and seeing 1600 x 900 actually takes up that much space? Because 1600 x 900 takes up my entire screen when it shouldn't.
Thanks.
On further inspection, the 1536 x 864 resolution it gives me is 80% the size that it should be, or in other words it should be 1.25 times bigger, the reciprocal. Also if I change my desktop resolution to 1600 x 900 the metrics gives me 1280 x 720, which is again 80%, or the resolution is 1.25 bigger than what's given.
Well, this is a duplicate, but if this helps anyone I'll explain the problem of DPI scaling. Basically the default Windows setting is 96 DPI. There are options in Control Panel to "make stuff bigger", which is easier on the eyes. My slider is set to the middle one, which is equivalent to 125% bigger, or 120 dpi, which is why System Metrics was returning the wrong values, and my windows were bigger. The dpi gets bigger, so the system assumes it has to draw everything larger in proportion to the upscaling. If you consider someone programs a window to be 200 pixels across, when someone with a super duper double resolution display runs it, it's still going to be 200 pixels across, but half the physical size, say inch-wise. So by doubling the dpi "setting", not the dpi, but dpi "setting" from 96 to 194, or scaling it up 200% makes the window occupy 400 pixels across, but is the same size with respect to the original display.
Anyway, the easiest fix for this, if on Visual Studio, is simply through the project properties, go down to the "manifest" menu, then select "input/output", the last option should be DPI Awareness. Mine was on "None". It's only necessary in most cases to put it on "High DPI Aware", and that will fix the problem. The other option, which is "per monitor DPI awareness" means that it will adjust accordingly in a dynamic way, say for example the dpi scaling is changed while the app is running, or moving the window onto another monitor while it's running. The High DPI Aware setting will do a check at startup.
Interestingly, if you go to the properties of any exe, and under the compatibility tab, you can check "Disable display scaling on high DPI settings", and that will work also. Finally, there is a free program, now owned by Microsoft, called process explorer, which is basically like task manager with extra features, and you can select the DPI Awareness column and see which programs are DPI aware. Yes, DPI Awareness is a thing, I feel so dumb. There are also many other ways to do it, like with function calls and merging manifests, but I have no idea about that, and am too tired to even breathe now.