(fltk-1.5) Issues with the new PEN support code under Win32 with mingwXX compilers

[imacarthur]

I've been having issues with the new pen support code on WinXX, mainly because I'm using older compilers, and not using MSVC at all,  I suspect.

So: On a Win11 box, but using a mingw64 toolchain to compile the current tip of fltk-1.5, I get:

d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:187:32: error: 'POINTER_BUTTON_CHANGE_TYPE' was not declared in this scope
 static State button_to_trigger(POINTER_BUTTON_CHANGE_TYPE button, bool down) {

This with the toolchain: 

$ g++ -v
Using built-in specs.
COLLECT_GCC=d:\TDM-GCC-64\bin\g++.exe
COLLECT_LTO_WRAPPER=d:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 5.1.0 (tdm64-1)

Now, poking about in the headers, in winuser.h I find that POINTER_TOUCH_INFO is defined, but only if WINVER/_WIN32_WINNT are set to 0x0602 or greater (i.e. Win8 or later) but it seems the TDM compiler is "conservative" in this regard and so WINVER is NOT set > 0x0602...

Forcing WINVER in my cmake configure helps a bit, in that it gets further before it fails; as far as :

 Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx.obj
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx: In function 'LRESULT fl_win32_tablet_handler(MSG&)':
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:223:49: error: 'WM_POINTERROUTEDRELEASED' was not declared in this scope
   if (message < WM_NCPOINTERUPDATE || message > WM_POINTERROUTEDRELEASED) {
                                                 ^
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:262:10: error: 'DM_POINTERHITTEST' was not declared in this scope
     case DM_POINTERHITTEST:
          ^
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:263:10: error: 'WM_POINTERROUTEDTO' was not declared in this scope
     case WM_POINTERROUTEDTO:
          ^
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:264:10: error: 'WM_POINTERROUTEDAWAY' was not declared in this scope
     case WM_POINTERROUTEDAWAY:
          ^
d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:265:10: error: 'WM_POINTERROUTEDRELEASED' was not declared in this scope
     case WM_POINTERROUTEDRELEASED:
          ^

But that looks harder to dodge around, since these values are not defined in the TDM win headers at all, AFAICT, and MSDN says they are only valid with Win10 or later, which may explain why my "older" compiler is struggling.

In parallel I was looking at a legacy 32-bit build using a mingw32 compiler, 

$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

But the mingw32 win headers seem to be _really_ out of date, they do not even define POINTER_TOUCH_INFO at all, let alone the related WM_ events that we use with it... (FWIW the mingw32 stuff seems to be mainly dead now, so I assume that will never be fixed...)

On a related note, how do we envisage the "Fl::Pen::DETECTED" and related items working? They seem to be taking the same values as existing FLTK event codes, so I'm not sure how that works.

They are included, for example, in names.h, so I'm not sure how to distinguish between, say, FL_RELEASE and Fl::Pen::DETECTED which will both be 2 at that point..?

I'm missing something here?

[imacarthur]

FWIW, I've poked at this a little bit, and now have a few wee tweaks that are sufficient to make the code compile with the "old" 64-bit TDM mingw64 compiler. All the changes are dodging issues with the compiler headers, not changes to FLTK per se.

I think I'm going to have to give up on the mingw32 port though, it's just Too Old now and seems to be mainly dead. Which is a pity as I have a lot of stuff that uses that toolchain...!

 

On a related note, how do we envisage the "Fl::Pen::DETECTED" and related items working? They seem to be taking the same values as existing FLTK event codes, so I'm not sure how that works.

They are included, for example, in names.h, so I'm not sure how to distinguish between, say, FL_RELEASE and Fl::Pen::DETECTED which will both be 2 at that point..?

I'm missing something here?

Still not got my head around this bit though...

 

[Manolo]

Le jeudi 8 janvier 2026 à 11:35:55 UTC+1, imacarthur a écrit :

On a related note, how do we envisage the "Fl::Pen::DETECTED" and related items working? They seem to be taking the same values as existing FLTK event codes, so I'm not sure how that works.

DETECTED in used twice in file pen_events.H:

-once as a pen "event" with value 0x1000 quite distinct from other event codes;

-once as a pen "trait" with value 2, which needs not be compared with event values.

[imm]

Ohhh! Right.

That makes sense now!

Cheers Manolo.

I guess we still need to keep an eye on the event numbers, if it's not all in one place in future though?

--
Ian
From my Fairphone FP3

[melcher....@googlemail.com]

Hi guys,

thanks for looking at the code and letting me know what compiles and what doesn't. It was clear that very old versions of teh SDK would not compile, and there is already some version number based defined #ifdef in the code, but commented out because I wanted to finish the implementation before disabling things again for compatibility.

I have still a bunch of changes in Fluid that I will push over the next days. After that, I am on break until February. I will look into all that when I am back.

[Albrecht Schlosser]

On 1/7/26 16:28 imacarthur wrote:
> I've been having issues with the new pen support code on WinXX, mainly
> because I'm using older compilers, and not using MSVC at all,  I suspect.
>
> So: On a Win11 box, but using a mingw64 toolchain to compile the
> current tip of fltk-1.5, I get:
>
> d:/Support/fltk-1.5/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:187:32:
> error: 'POINTER_BUTTON_CHANGE_TYPE' was not declared in this scope
>  static State button_to_trigger(POINTER_BUTTON_CHANGE_TYPE button,
> bool down) {
>
> This with the toolchain:
> $ g++ -v
> Using built-in specs.
> COLLECT_GCC=d:\TDM-GCC-64\bin\g++.exe

[...]

> Now, poking about in the headers, in winuser.h I find
> that POINTER_TOUCH_INFO is defined, but only if WINVER/_WIN32_WINNT
> are set to 0x0602 or greater (i.e. Win8 or later) but it seems the TDM
> compiler is "conservative" in this regard and so WINVER is NOT set >
> 0x0602...
>
> Forcing WINVER in my cmake configure helps a bit, in that it gets
> further before it fails; as far as :

I know that we did similar things (redefine WINVER and/or define some
unknown symbols) in other source files. We might need to do that in our
pen related source files as well ...

> But that looks harder to dodge around, since these values are not
> defined in the TDM win headers at all, AFAICT, and MSDN says they are
> only valid with Win10 or later, which may explain why my "older"
> compiler is struggling.

With my almost current MSYS2/MinGW-w64 build system everything compiles
fine on Windows 10.

Since you're using Win11 it looks as if TDM-gcc is the culprit. (?)

> In parallel I was looking at a legacy 32-bit build using a mingw32
> compiler,
>
> $ gcc -v
> Using built-in specs.

> [...]

> Thread model: win32
> gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
>
> But the mingw32 win headers seem to be _really_ out of date, they do
> not even define POINTER_TOUCH_INFO at all, let alone the related WM_
> events that we use with it...

I have a much more recent MinGW version installed on my Win10 system:

$ gcc -v
Using built-in specs.

[...]
Thread model: win32
gcc version 9.2.0 (MinGW.org GCC Build-2)

I pulled the latest updates some weeks or months ago, but see below.

Nevertheless I can't build FLTK 1.5 as well, for two reasons:

(1) same as you, Ian, above: missing symbols in headers

(2) we need to set `CMAKE_CXX_EXTENSIONS:BOOL=ON` if we use C++11 (to
build FLTK 1.5), as I found out by using internet searches, because
otherwise Microsoft's "extensions" like '_strdup' and other functions
with leading underscore are disabled.

> (FWIW the mingw32 stuff seems to be mainly dead now, so I assume that
> will never be fixed...)

Yes, unfortunately. :-(

I also noticed this. But I'd like to support using the classic MinGW to
build FLTK in the future, as long as possible.

Therefore I decided to create a CMake option to enable or disable pen
support at build time (default: ON!). My first tests using MinGW were
successful, but I need to do some more work for all platforms. Note to
Matthias: I know that we discussed adding an option and I didn't want to
do this to avoid having even more options. However, to avoid build
problems, it seems necessary, and I'm working on it.

Ian, this should keep you going with "classic" (32-bit) MinGW for now
... unless your older version has even more issues.

Please watch my commits, pull the latest Git version once I committed
the option, and let us know how it works for you. Don't forget to set
`CMAKE_CXX_EXTENSIONS:BOOL=ON` if you get errors like `_strdup() not
declared`.

I'll post here when I pushed my commit.

[Albrecht Schlosser]

On 1/8/26 18:26 'Albrecht Schlosser' wrote:

... I decided to create a CMake option to enable or disable pen support at build time (default: ON!). ...

Ian, this should keep you going with "classic" (32-bit) MinGW for now ... unless your older version has even more issues.

Please watch my commits, pull the latest Git version once I committed the option, and let us know how it works for you. Don't forget to set `CMAKE_CXX_EXTENSIONS:BOOL=ON` if you get errors like `_strdup() not declared`.

I'll post here when I pushed my commit.

Done:

commit 4908dfd72a343ee7c35bc55a55ad860052e21fae
Author: Albrecht Schlosser <...>
Date:   Thu Jan 8 21:22:03 2026 +0100

    Add CMake option FLTK_OPTION_PEN_SUPPORT (default: ON)
    
    This option can be used to disable pen/tablet support if there are
    build problems on a particular platform or build system (e.g. MinGW)
    so users can continue to build FLTK 1.5.
    
    Users can also choose to disable pen support if they don't need it.

[imacarthur]

On Thursday, 8 January 2026 at 17:26:25 UTC Albrecht-S wrote:

I know that we did similar things (redefine WINVER and/or define some
unknown symbols) in other source files. We might need to do that in our
pen related source files as well ...

Yeah: I'll post the "tweak" I used to test this, for reference, though I'm not really proposing we deploy this "fix"...

Two files, a patch to Fl_WinAPI_Pen_Driver.cxx and a small header. This is "enough" to get the code to build/work reliably with my old TDM mingw64, but is not enough to make it work with the mingw32. (Note that this patch "pre-dates" Albrecht's addition of an option to disable the pen support in the code, though is orthogonal to it so doesn't conflict.)

Since you're using Win11 it looks as if TDM-gcc is the culprit. (?)

Yes, certainly so, it's not the OS or the code per se.

Indeed, being pedantic about it, it is not even the compilers, it is the WIN API header files shipped with the compiler that are at fault here.

In both cases (the TDM mingw64 and the old mingw32-6.0.2) if I contrive to "fix" the WIN API header files then it all compiles just fine.

 

Therefore I decided to create a CMake option to enable or disable pen
support at build time (default: ON!). My first tests using MinGW were
successful, but I need to do some more work for all platforms. Note to
Matthias: I know that we discussed adding an option and I didn't want to
do this to avoid having even more options. However, to avoid build
problems, it seems necessary, and I'm working on it.

Ian, this should keep you going with "classic" (32-bit) MinGW for now
... unless your older version has even more issues.

Please watch my commits, pull the latest Git version once I committed
the option, and let us know how it works for you. Don't forget to set
`CMAKE_CXX_EXTENSIONS:BOOL=ON` if you get errors like `_strdup() not
declared`.

OK, tested with the PEN support set to off, compiles and works fine with both of the old toolchains, so that's good.

 

[imacarthur]

On Friday, 9 January 2026 at 10:37:06 UTC imacarthur wrote:

On Thursday, 8 January 2026 at 17:26:25 UTC Albrecht-S wrote:

I know that we did similar things (redefine WINVER and/or define some
unknown symbols) in other source files. We might need to do that in our
pen related source files as well ...

Yeah: I'll post the "tweak" I used to test this, for reference, though I'm not really proposing we deploy this "fix"...

Two files, a patch to Fl_WinAPI_Pen_Driver.cxx and a small header. This is "enough" to get the code to build/work reliably with my old TDM mingw64, but is not enough to make it work with the mingw32. (Note that this patch "pre-dates" Albrecht's addition of an option to disable the pen support in the code, though is orthogonal to it so doesn't conflict.)

Second attempt to post the tweaked files for this test - first one was blocked. Dunno why; here's hoping!

[imacarthur]

FWIW, and just to add to what Albrecht said earlier - if I use a "more recent" mingw (in this case MSYS2 / Mingw64)

$ gcc -v
Using built-in specs.

  <snip>
gcc version 15.2.0 (Rev8, Built by MSYS2 project)

(That's what I ended up with after doing "pacman -Suy" just now...)

Then it Just Works, with the pen support compiled in, but only if I set WINVER to a "big enough" value. I set  "-DWINVER=0x0A00" in this case (Win10 basically).

If I don't explicitly set WINVER, the build still chokes for want of the later API being visible in the headers.

[Albrecht Schlosser]

On 1/9/26 11:37 imacarthur wrote:

On Thursday, 8 January 2026 at 17:26:25 UTC Albrecht-S wrote:

I know that we did similar things (redefine WINVER and/or define some
unknown symbols) in other source files. We might need to do that in our
pen related source files as well ...

Yeah: I'll post the "tweak" I used to test this, for reference, though I'm not really proposing we deploy this "fix"...

Seen your patches in your next post: that's the same technique we used elsewhere, hence I think it would be fine to do this here too.

Two files, a patch to Fl_WinAPI_Pen_Driver.cxx and a small header. This is "enough" to get the code to build/work reliably with my old TDM mingw64, but is not enough to make it work with the mingw32. (Note that this patch "pre-dates" Albrecht's addition of an option to disable the pen support in the code, though is orthogonal to it so doesn't conflict.)

It's a shame it doesn't work with your old MinGW(-32) version. I'll try it with my version later when I have time.

Since you're using Win11 it looks as if TDM-gcc is the culprit. (?)

Yes, certainly so, it's not the OS or the code per se.

Indeed, being pedantic about it, it is not even the compilers, it is the WIN API header files shipped with the compiler that are at fault here.

Sure.

In both cases (the TDM mingw64 and the old mingw32-6.0.2) if I contrive to "fix" the WIN API header files then it all compiles just fine.

But I guess it wouldn't work on "older" Windows versions anyway, as we read already, some of the features require Win8, others require Win10. So I think either disabling pen support by build option or loading DLL's dynamically would be required to make it work on older systems. I'd really prefer not to add even more dynamic DLL loading for features that many users won't need (which means: after all I'd prefer the build option).

Therefore I decided to create a CMake option to enable or disable pen

support at build time (default: ON!). ...

Ian, this should keep you going with "classic" (32-bit) MinGW for now
... unless your older version has even more issues.

Please watch my commits, pull the latest Git version once I committed
the option, and let us know how it works for you. Don't forget to set
`CMAKE_CXX_EXTENSIONS:BOOL=ON` if you get errors like `_strdup() not
declared`.

OK, tested with the PEN support set to off, compiles and works fine with both of the old toolchains, so that's good.

Thanks for confirmation.

Did you need to set `CMAKE_CXX_EXTENSIONS:BOOL=ON` or did it work w/o setting this?

[Albrecht Schlosser]

On 1/9/26 11:48 imacarthur wrote:

Second attempt to post the tweaked files for this test - first one was blocked. Dunno why; here's hoping!

Hmm, there's one point in your patch that makes me wonder why you did this:

 // Some versions of MinGW now require us to explicitly include winerror to get S_OK defined
-#include <winerror.h>
+//#include <winerror.h>

As the comment above the line in question says, there were reasons that we had to `#include <winerror.h>`, but you commented this line out. Why did you do that, what did it fix, or ... ? Is it possible that one of your build systems doesn't provide `winerror.h` ?

[imacarthur]

On Friday, 9 January 2026 at 13:12:33 UTC Albrecht-S wrote:

Two files, a patch to Fl_WinAPI_Pen_Driver.cxx and a small header. This is "enough" to get the code to build/work reliably with my old TDM mingw64, but is not enough to make it work with the mingw32. (Note that this patch "pre-dates" Albrecht's addition of an option to disable the pen support in the code, though is orthogonal to it so doesn't conflict.)

It's a shame it doesn't work with your old MinGW(-32) version. I'll try it with my version later when I have time.

The _really_ old mingw32 headers need more stuff added, beyond the handful of #defines I added. In particular, they need a few structs added, and I didn't want to (re-)define those structs without first checking to see if they were already defined - which isn't easy to do at compile time (it's easy to check for #defines at compile though...)

If I do add the missing structs, then the old toolchain works.

It really is just the the WIN API headers are so very out of date...

In both cases (the TDM mingw64 and the old mingw32-6.0.2) if I contrive to "fix" the WIN API header files then it all compiles just fine.

But I guess it wouldn't work on "older" Windows versions anyway, as we read already, some of the features require Win8, others require Win10. So I think either disabling pen support by build option or loading DLL's dynamically would be required to make it work on older systems. I'd really prefer not to add even more dynamic DLL loading for features that many users won't need (which means: after all I'd prefer the build option).

Yup - the older versions of user32.dll don't all have the added API calls, so runtime can still be an issue here.

 

Did you need to set `CMAKE_CXX_EXTENSIONS:BOOL=ON` or did it work w/o setting this?

Sorry yes, good point - I did have   `CMAKE_CXX_EXTENSIONS:BOOL=ON` during these tests.

[imacarthur]

On Friday, 9 January 2026 at 13:18:54 UTC Albrecht-S wrote:

Hmm, there's one point in your patch that makes me wonder why you did this:

// Some versions of MinGW now require us to explicitly include winerror to get S_OK defined -#include <winerror.h> +//#include <winerror.h> As the comment above the line in question says, there were reasons that we had to `#include <winerror.h>`, but you commented this line out. Why did you do that, what did it fix, or ... ? Is it possible that one of your build systems doesn't provide `winerror.h` ?

Sorry, that's untidiness on my part - I was commenting out various header files during my tests just to see what was in scope etc... Forgot to restore that.

None of my builds needed it so I didn't notice it was missing...

[Albrecht Schlosser]

On 1/9/26 14:32 imacarthur wrote:

On Friday, 9 January 2026 at 13:12:33 UTC Albrecht-S wrote:

Two files, a patch to Fl_WinAPI_Pen_Driver.cxx and a small header. This is "enough" to get the code to build/work reliably with my old TDM mingw64, but is not enough to make it work with the mingw32. (Note that this patch "pre-dates" Albrecht's addition of an option to disable the pen support in the code, though is orthogonal to it so doesn't conflict.)

It's a shame it doesn't work with your old MinGW(-32) version. I'll try it with my version later when I have time.

The _really_ old mingw32 headers need more stuff added, beyond the handful of #defines I added. In particular, they need a few structs added, and I didn't want to (re-)define those structs without first checking to see if they were already defined - which isn't easy to do at compile time (it's easy to check for #defines at compile though...)

Yes, indeed. This would (AFAICT) require a CMake compile test to decide whether the structs exist.

If I do add the missing structs, then the old toolchain works.

It really is just the the WIN API headers are so very out of date...

Did you consider to update your toolchain, or are you not able/allowed to upgrade the toolchain for your projects?

The last time I tried it, I noticed that it still worked, even though the MinGW project seemed to have been abandoned. I think the `mingw-get` tool still works because it fetches the updates from sourceforge but I'm not sure. Maybe today it doesn't work anymore. Maybe it's the last chance to upgrade before the project is completely lost...

Backup recommended, of course, but you know that.

Did you need to set `CMAKE_CXX_EXTENSIONS:BOOL=ON` or did it work w/o setting this?

Sorry yes, good point - I did have   `CMAKE_CXX_EXTENSIONS:BOOL=ON` during these tests.

OK, thanks again for the confirmation.

Meanwhile I checked again, and there seems to be another option we can try to enable the "Microsoft extensions" within MinGW:

AI generated answer: "Alternatively, defining _CRT_NONSTDC_NO_DEPRECATE in the preprocessor settings can suppress warnings and allow the use of non-standard functions."

I'll give that a try as well. CMAKE_CXX_EXTENSIONS:BOOL=ON would enable all "GNU extensions" (and likely as a side effect also the MS extensions) whereas _CRT_NONSTDC_NO_DEPRECATE would be Microsoft specific. I don't know which one would be the better choice if both worked.

[Albrecht Schlosser]

Thanks, that's good to know.

Without checking the git history I don't know when this `#include` was added, although ISTR that I added it. Maybe that fix was needed for some ("recent", at that time) MinGW (header file) versions and it was fixed later by a MinGW update, I don't know.