1.5 - Pen support on Windows build query

[imacarthur]

Matt,

Can I ask what checks cmake is doing to determine whether pen support is available under Windows?

(This is mainly just laziness, I didn't try and look...)

I was just rebuilding things, and _some_ of my build setups work just fine, pen support is detected and built (and works) but a few of my older mingw setups don't - basically cmake says it's not supported.

At first glance, this appears to be because, although the compiler involved is fairly recent, it uses the mingw headers and they are woefully outdated, so I suspect they are missing a few symbols that we now need.

[Gonzalo Garramuño]

On 6/17/26 07:58, imacarthur wrote:
> Matt,
>
> Can I ask what checks cmake is doing to determine whether pen support
> is available under Windows?
> (This is mainly just laziness, I didn't try and look...)
>
> I was just rebuilding things, and _some_ of my build setups work just
> fine, pen support is detected and built (and works) but a few of my
> older mingw setups don't - basically cmake says it's not supported.
>

On Windows there's only a single check done:


/* We require Windows 8 or later features for Pen/Tablet support */

# if !defined(WINVER) || (WINVER < 0x0602)
#  ifdef WINVER
#   undef WINVER
#  endif
#  define WINVER 0x0602
# endif
# if !defined(_WIN32_WINNT) || (_WIN32_WINNT < 0x0602)
#  ifdef _WIN32_WINNT
#   undef _WIN32_WINNT
#  endif
#  define _WIN32_WINNT 0x0602
# endif

#include <windows.h>

int main() {
    return POINTER_CHANGE_FIRSTBUTTON_DOWN; /* required symbol */
}

[imacarthur]

On Wednesday, 17 June 2026 at 12:12:11 UTC+1 Gonzalo wrote:

On Windows there's only a single check done:


/* We require Windows 8 or later features for Pen/Tablet support */

# if !defined(WINVER) || (WINVER < 0x0602)
#  ifdef WINVER
#   undef WINVER
#  endif
#  define WINVER 0x0602
# endif
# if !defined(_WIN32_WINNT) || (_WIN32_WINNT < 0x0602)
#  ifdef _WIN32_WINNT
#   undef _WIN32_WINNT
#  endif
#  define _WIN32_WINNT 0x0602
# endif

#include <windows.h>

int main() {
    return POINTER_CHANGE_FIRSTBUTTON_DOWN; /* required symbol */
}

Thanks Gonzalo,

Yeah, I guess that would do it.

The WINVER/_WIN32_WINNT check looks pretty normal (the mingw toolchain is notoriously bad at setting anything useful for WINVER, so that seems sensible. I use basically that stanza all over the code for those builds...)

However, there's no trace of the POINTER_CHANGE_* enum in the (really old) mingw32 headers, whereas later mingw variants (mingw64 et al) do have it.

That said, we don't actually use the  POINTER_CHANGE_* values - I assume they are being used in the check as a surrogate for checking the POINTER_INFO struct etc...

Anyway, I don't think we can realistically fill in all the missing pieces, so I guess that toolchain is a lost cause!

Cheers....

[Albrecht Schlosser]

On 6/17/26 14:13 imacarthur wrote:
> we don't actually use the POINTER_CHANGE_* values - I assume they are
> being used in the check as a surrogate for checking the POINTER_INFO
> struct etc...
>
> Anyway, I don't think we can realistically fill in all the missing
> pieces, so I guess that toolchain is a lost cause!

You can disable pen support entirely by using CMake option
"FLTK_OPTION_PEN_SUPPORT - default ON". This *should* disable
compilation of all pen support code. If this doesn't help, then this is
supposedly a bug in our source code.

[imacarthur]

On Thursday, 18 June 2026 at 08:02:56 UTC+1 Albrecht wrote:

>
> Anyway, I don't think we can realistically fill in all the missing
> pieces, so I guess that toolchain is a lost cause!

You can disable pen support entirely by using CMake option
"FLTK_OPTION_PEN_SUPPORT - default ON". This *should* disable
compilation of all pen support code. If this doesn't help, then this is
supposedly a bug in our source code.

There's no problem with the FLTK build as such (other than pen support not working.)

It actually builds fine with FLTK_OPTION_PEN_SUPPORT either set or unset - so there's no "bug" as such (other than with the migw32 headers being Too Old, which is not our fault!)

I was poking at this yesterday specifically because I have a number of devices with pen or stylus support, and was planning on doing some tests for a wee project I had in mind.

FWIW, looking back at my notes, it appears I already _knew_ this was broken in the old mingw headers; but it rather seems I had forgotten and "discovered" it all over again!

[Albrecht Schlosser]

On 6/18/26 10:16 imacarthur wrote:

On Thursday, 18 June 2026 at 08:02:56 UTC+1 Albrecht wrote:

[Ian wrote]

> Anyway, I don't think we can realistically fill in all the missing
> pieces, so I guess that toolchain is a lost cause!

You can disable pen support entirely by using CMake option
"FLTK_OPTION_PEN_SUPPORT - default ON". This *should* disable
compilation of all pen support code. If this doesn't help, then this is
supposedly a bug in our source code.

There's no problem with the FLTK build as such (other than pen support not working.)

It actually builds fine with FLTK_OPTION_PEN_SUPPORT either set or unset - so there's no "bug" as such (other than with the migw32 headers being Too Old, which is not our fault!)

FWIW, looking back at my notes, it appears I already _knew_ this was broken in the old mingw headers; ...

Yes, I remember that it was your report that made me add the compilation test *and* the CMake option. The former should work OOTB to discover missing pieces, the latter should be a last resort if it doesn't build for any (other)reason on any platform.

None of these mechanisms would help to enable pen/table t support on such old systems as yours though.

It's a pity that the old ("classic") MinGW system is no longer maintained. It looks like you have to use MSYS2/MinGW-w64 to build under Windows with GNU tools nowadays.

While we're at it, do you have any information about the maintenance of the old MinGW toolchain? The last time I checked I could still download the "latest" version (i.e. my old status) with `mingw-get`, but it's probably no longer possible to install the toolchain from scratch. Their website is (was) gone. What do you think, should we remove instructions on building with "classic" MinGW from our docs?

[melcher....@googlemail.com]

Sorry for the late reply. I was busy IRL. Yes, I think the previous explanations are right. This is just to add that I fixed a lot of stuff in the Windows driver as of an hour ago.

External testing with a small app would be really helpful, Ian. Feel free to post your findings as an Issue on GitHub, bugs, unexpected behavior, missing features, etc. . I am not a regular tablet/pen user, and my old Wacom PTH-450 does not get any driver support port by Wacom anymore, so I can't test it on my ARM64 machine. 

 - Matthias

[imacarthur]

On Saturday, 20 June 2026 at 12:51:32 UTC+1 Albrecht-S wrote:

It's a pity that the old ("classic") MinGW system is no longer maintained. It looks like you have to use MSYS2/MinGW-w64 to build under Windows with GNU tools nowadays.

Yes, it appears so.

And that, it transpires, brings its own issues (more on that in a reply to Matt later...)

 

While we're at it, do you have any information about the maintenance of the old MinGW toolchain? The last time I checked I could still download the "latest" version (i.e. my old status) with `mingw-get`, but it's probably no longer possible to install the toolchain from scratch. Their website is (was) gone. What do you think, should we remove instructions on building with "classic" MinGW from our docs?

It's a shame, because I quite liked the old Mingw32 stuff, but yes, it seems to be "dead" for all practical purposes. We probably should remove it from the docs, or at the very least mark it as being deprecated in some way.

My situation is "odd" in that we have a lot of "old" PCs (many of them 32-bit, hence the ongoing use of 32-bit builds) that are running test sets on isolated, standalone networks. Since these machines cannot be (have never been) connected to the internet, the mingw installation they have is "cloned" from a reference build, rather than downloaded online, so that's quite unlike what most users would do.

 

[imacarthur]

On Saturday, 20 June 2026 at 14:11:39 UTC+1 Matt wrote:

External testing with a small app would be really helpful, Ian. Feel free to post your findings as an Issue on GitHub, bugs, unexpected behavior, missing features, etc. . I am not a regular tablet/pen user, and my old Wacom PTH-450 does not get any driver support port by Wacom anymore, so I can't test it on my ARM64 machine. 

I'll give it a whirl, time permitting, but it might not be promptly... (Sorry)

Like you, the tablets I have are older, so somewhat unsupported on my "new" machines.

They tend to be attached to older machines (many of them 32-bit OS versions of Windows, hence the ongoing use of mingw32).

FWIW, I had a poke at the DLLs on one of these, and it looks as if the requisite API are present; the issue is really just that the mingw32 headers do not expose them, rather than any issue with the target PCs per se.

But... here's the tricky bit: I can use the mingw64 tools to build 32-bit Windows code, but it turns out that the version of the mingw64 tools I have implements C++ threads as pthreads, and does this on Windows by wrapping winpthreads.

Now, I'm not using C++ threading at all in my code, but the compiled exe seems to be dragging it in at link time anyway.

My older "standalone" machines don't have any winpthread DLL of course, so then the code won't run. Agh!

There's ostensibly some compile / link time flag (e.g. "-no-pthread" or something, forget the details) that's supposed to help dodge that issue, but it didn't seem to work for me. The other option seems to be to download and static-link a winpthread stub, but I've not tried that yet.

Anyway, the upshot is that I can build a 32-bit Windows version to test, using the mingw64 tooling, but I can't currently run the resulting binary on the machines where I can test it...

(And, FWIW, 64-bit binaries built with that mingw64 tooling are similarly afflicted when subsequently run on Win64 machines that do not have winpthreads - which is most of them,,,)

[Albrecht Schlosser]

On 6/22/26 12:26 imacarthur wrote:

[...] here's the tricky bit: I can use the mingw64 tools to build 32-bit Windows code, but it turns out that the version of the mingw64 tools I have implements C++ threads as pthreads, and does this on Windows by wrapping winpthreads.

Same here.

Now, I'm not using C++ threading at all in my code, but the compiled exe seems to be dragging it in at link time anyway.

My older "standalone" machines don't have any winpthread DLL of course, so then the code won't run. Agh!

Workaround #1: you can find the MinW-w64 winpthread DLL and install it side by side with your executable. This *should* work, but it's only a workaround.

There's ostensibly some compile / link time flag (e.g. "-no-pthread" or something, forget the details) that's supposed to help dodge that issue, but it didn't seem to work for me. The other option seems to be to download and static-link a winpthread stub, but I've not tried that yet.

Neither did I.

Anyway, the upshot is that I can build a 32-bit Windows version to test, using the mingw64 tooling, but I can't currently run the resulting binary on the machines where I can test it...

(And, FWIW, 64-bit binaries built with that mingw64 tooling are similarly afflicted when subsequently run on Win64 machines that do not have winpthreads - which is most of them,,,)

Workaround #2: once I tried to remove (rename) the conflicting DLL linker stubs (winpthread*.dll.a file(s)) - maybe more than one - before linking. Since the DLL stubs can't be found, the code was statically linked in, et voilà, it worked. This is error-prone though, and re-installing the MSYS2/MinGW-w64 stuff restores the *.dll.a files, and you have to repeat what you did before.

Finally, my SOLUTION (off the top of my head, and IIRC): I assume you are using linker flags "-static-libgcc -static-libstdc++" anyway. You can add "-static" after these flags, and it "magically" works to link everything statically, as far as possible. I believe I'm doing it like this in the first CMake execution:

  $ cmake -G "..." -D CMAKE_EXE_LINKER_FLAGS_INIT="-static-libgcc -static-libstdc++ -static" ...

and this seems to do it. Note that I didn't try if "-static" alone works, and I don't know if any of this has any notable side effects (except executable size, of course).

I don't have my Win10 VM running right now, but I think this is mostly correct. I could even execute the binaries on WinXP !

BTW: my plausibility check (except running `ldd` on the binaries) is to open the Windows explorer and double-click on the respective binaries. It's important to ensure that no MinGW directories are in the PATH though, which I avoid like the plague (setting the PATH only in the respective MSYS2/MinGW environment).


I hope this helps, and I'd appreciate all feedback or better proposals. My intention is to add something like this to our docs.


Disclaimer: I can't tell if this would also work for tablet/pen support. You'd likely need to provide one of the Windows DLL's to the target system as well. Maybe.

[Albrecht Schlosser]

On 6/22/26 14:45 schrieb 'Albrecht Schlosser' wrote:

Finally, my SOLUTION (off the top of my head, and IIRC): I assume you are using linker flags "-static-libgcc -static-libstdc++" anyway. You can add "-static" after these flags, and it "magically" works to link everything statically, as far as possible. I believe I'm doing it like this in the first CMake execution:

  $ cmake -G "..." -D CMAKE_EXE_LINKER_FLAGS_INIT="-static-libgcc -static-libstdc++ -static" ...

and this seems to do it. Note that I didn't try if "-static" alone works, and I don't know if any of this has any notable side effects (except executable size, of course).

I should add that I didn't find a way to build FLTK DLL's with similar flags. If I set "CMAKE_SHARED_LINKER_FLAGS_INIT=..." I get lots of linker errors (multiply defined symbols or whatever). I gave up, but if anybody can help, that would be appreciated.

And, FWIW, this is not an issue if you use the Visual Studio to build.