Add MingW64 makefile

[RamonUnch]

First I would like to thanks you for this program, it is quite helpful for me!
I wanted to make my own build (I like to have control on the binary), so I tried to build with MinGW64 and encountered very few problems, so I decided to share them.

The code just needed a few adjustments to build on MinGW64 some are actually corrections.
The main limitation is that mingw64 does not have a complete header+lib for the PROPSYS.DLL file. nor for the CLSID_InternetShortcut I just made a define in the source to supress inclusion of PROPSYS stuff.

hopefully MinGW64 gets his headers and lib files updated at some point...

I think supporting more than one compiler is useful for people to be able to easily help with development as well as giving more options to the users.

Fixes (ctd = C++17)

• A class is its always its own friend (see CoPtr).
• SendMessage cannot have its last parameter to be NULL, it must integer-type (tolerated with proper gcc parameter, but better fix it).
• a function declaration inside a class must not specify classname::, it is invalid in c++ and strangely accepted by VC++, not gcc.

[guilryder]

Thanks for doing all the legwork, this is very helpful!

Starting from your patch I was able to achieve full MinGW compatibility, draft in the mingw branch: https://github.com/guilryder/clavier-plus/tree/mingw

If it looks good to you I will do another pass on the flags, warnings, etc. and merge the branch into main.

Details:

• MSVC++ needs a CoPtr friend declaration to allow access across template types e.g. CoPtr<X> accessing CoPtr<Y>.
• MinGW can support propsys.dll functions and UUIDs after declaring them manually.
• MinGW doesn't seem to have an equivalent for the fancy VC++ manifest generator/minifier, so I simply included the raw manifest as-is in resources. It's important for look-and-feel.

The Makefile doesn't cover the tests and compiles all the files at once therefore is a bit slow (especially without precompiled headers), but that's good enough if not used for iterative development. Tweaks:

• removed 32bit support: Clavier+ has been 64bit-only for a while and doesn't guarantee 32bit compatibility
• moved the output files to a subdirectory; caveat: I couldn't find a standard way (Powershell-compatible) to create directories

[RamonUnch]

Very nice, for me it works.
with mingw you get mkdir, so the normal way would be to add just after the default::

default: $(OUTDIR)\Clavier.exe

PRE:
	-@if not exist output       mkdir output
	-@if not exist $(OUTDIR)    mkdir $(OUTDIR)

Strangely it does not work with PowerShell not sure why (works with sh and cmd.exe). So you could just add in the comments that the output\mingw directory has to be manually created.

About the .manifest it seems that you do not use dpi-awareness is there a reason for this?
My usual .manifest file contains the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="XP style" type="win32" />

<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32"
      name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
      processorArchitecture="*" publicKeyToken="6595b64144ccf1df"
      language="*" />
  </dependentAssembly>
</dependency>

<asmv3:application>
  <asmv3:windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
  </asmv3:windowsSettings>

</asmv3:application>

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
  <application>
    <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
    <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
    <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
  </application>
</compatibility>

</assembly>

This way I get theme applied plus nice dpi-scaling on non-96dpi monitors plus; thanks to the <compatibility ..> section, I get the real windows version when using GetVersionEx, otherwise you are lied to since Windows 10. It is not necessary in your case though.
All the rest is good for me. I was hesitant to look for the GUID hex value and add it because I did not know if you would be interested in a mingw build.

[guilryder]

Thanks, it has been a while since I've written a Makefile and it's coming back slowly... The shell executes mkdir, not make, so I picked a solution that works with both cmd.exe and Powershell (but not sh): a single plain mkdir without -p.

About the manifest: I simply didn't know about DPI awareness, as I use only 96 DPI displays or configured as such :)

I tested with 2 monitors at different DPI. Clavier+ seems to work fine in PerMonitorV2 mode: no blurry text, and the configuration dialog resizes itself automatically when dragged across monitors. It's encouraging; I will conduct more extensive tests as Clavier+ hard-codes pixel coordinates, uses small bitmaps, etc. and I wrote most of the code before DPI-aware APIs existed. Code changes could be required.

[RamonUnch]

The real improvement on dpi is the per-monitor dpi scaling. On older windows versions dpi scaling has always been a thing (even in Win3.1). However newer Windows assumes that by default your program can only handle 96dpi. Older Windows versions always assumed your program was dpi aware.

Back in the Win3x days most programs where careful with dpi because on most monitors pixels where not even square so you had different vertical and horizontal dpi settings, however starting with Windows 95 the default dpi setting for 99% of people was 96dpi. Because it stayed this way for so long Microsoft felt the need to let the program imagine it is in 96dpi and rescale accordingly for the display.

I advise you keep the per-monitor v1 fallback, because Windows 8 only supports this one.
on the line
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
it means PerMonitorV2 and fallback to PerMonitor if v2 not available

[guilryder]

Tested DPI awareness, added in 5477085.