FLTK 1.3 vs 1.4 on windows11 without X11

[Brian Emberling]

When I compile a simple app on cygwin/windows11 in FLTK 1.3.9, the app

opens a window11 window, but when the same app is compiled with

FLTK 1.4, it opens in an X11 window.

Is there any way to get FLTK1.4 to use the windows11 windows, not X11?

You can see the difference with fltk-config:

FLTK 1.3.9:   ./fltk-config --ldflags

-Lc:/fltk/lib -mwindows -lfltk -lole32 /usr/lib/w32api/libuuid.a -lcomctl32

 

FLTK 1.4.0 :  ./fltk-config --ldflags

-L/cygdrive/c/fltk/lib -L/usr/lib -lfltk -lm -lX11 -lXext -lpthread -lXft -lXrender -lm -lfontconfig -ldl

(using FLTK 1.3.9 flags trying to compile with FLTK 1.4.0 results in lots of link errors).

thanks for any help

[imm]

I've got nothing useful to say about cygwin, I'm sorry.

I gave up on it years ago as it caused me so many problems. There are others around here that still use cygwin sometimes I think, so hopefully they'll have useful things to say!

FWIW, building "native" WIN32 apps I pretty much always use mingw (or 64-bit variants thereof) and that's been robust (and it's not X11 of course !)

--
Ian
From my Fairphone FP3

[Albrecht Schlosser]

On 2/15/24 23:03 Brian Emberling wrote:

When I compile a simple app on cygwin/windows11 in FLTK 1.3.9, the app

opens a window11 window, but when the same app is compiled with

FLTK 1.4, it opens in an X11 window.

Is there any way to get FLTK1.4 to use the windows11 windows, not X11?

We need to know how you configured the FLTK build to answer your questions. Please post your full configure command line.

If you didn't build FLTK yourself, well, then it's even harder to tell. Did you use a Cygwin package to install FLTK?

You can see the difference with fltk-config:

FLTK 1.3.9:   ./fltk-config --ldflags

-Lc:/fltk/lib -mwindows -lfltk -lole32 /usr/lib/w32api/libuuid.a -lcomctl32

 

FLTK 1.4.0 :  ./fltk-config --ldflags

-L/cygdrive/c/fltk/lib -L/usr/lib -lfltk -lm -lX11 -lXext -lpthread -lXft -lXrender -lm -lfontconfig -ldl

(using FLTK 1.3.9 flags trying to compile with FLTK 1.4.0 results in lots of link errors).

I didn't use Cygwin for a long time and I don't have a working Cygwin installation on any of my usual systems. Maybe on an older system I'm not using anymore, but then this would be a *really* old Cygwin installation.

One important question: did you try configuring FLTK 1.4 with:

(a) CMake? If not this would be worth a try.
(b) configure --disable-cygwin ? If you used configure w/o this switch it's very likely that FLTK is built with X11 support.
(c) configure --disable-x11 ? If not: see (b).

thanks for any help

Please post more info so we can help you better. Of course it would be useful to see both the configure/CMake commandlines for FLTK 1.3 and FLTK 1.4.

[Brian Emberling]

thanks for the help.

Both FLTK 1.3.9 and 1.4 are the latest code downloaded yesterday from fltk.org and github respectively.

I'm compiling with cygwin  (GCC version 11.4.0)

To compile FLTK 1.3.9, I use:

    ./configure   --enable-localzlib --enable-localpng --prefix=c:/fltk

    make

    make install

To compile FLTK 1.4.0, i used:

        cmake .. -DCMAKE_INSTALL_PREFIX=/cygdrive/c/fltk -DFLTK_BUILD_GL=OFF -DFLTK_BACKEND_X11=OFF -DFLTK_GRAPHICS_GDIPLUS=ON

        (the FLTK_GRAPHICS_GDIPLUS seems to have no effect)

I've attached the logfile cmake created if that helps. 

This line looks suspicious - as if the only choices are X11 or wayland, not also win32/GDI ?

-- Use Wayland             : No (therefore, X11 is used)

[Albrecht Schlosser]

On 2/16/24 18:05 Brian Emberling wrote:

thanks for the help.

Welcome.

Both FLTK 1.3.9 and 1.4 are the latest code downloaded yesterday from fltk.org and github respectively.

Good.

I'm compiling with cygwin  (GCC version 11.4.0)

To compile FLTK 1.3.9, I use:

    ./configure   --enable-localzlib --enable-localpng --prefix=c:/fltk

    make

    make install

That looks fine.

To compile FLTK 1.4.0, i used:

        cmake .. -DCMAKE_INSTALL_PREFIX=/cygdrive/c/fltk -DFLTK_BUILD_GL=OFF -DFLTK_BACKEND_X11=OFF -DFLTK_GRAPHICS_GDIPLUS=ON

        (the FLTK_GRAPHICS_GDIPLUS seems to have no effect)

This option would only be useful if GDI was used. Obviously we don't come to this point at all.

I've attached the logfile cmake created if that helps. 

This line looks suspicious - as if the only choices are X11 or wayland, not also win32/GDI ?

-- Use Wayland             : No (therefore, X11 is used)

Yes, what you say is correct. I'm still in the process of reworking the CMake build system to use "Modern CMake", and for the addition of Wayland support on Unix/Linux we concentrated on these platforms.

I'm sorry, this is not the answer I would like to give, but please try the same build type you used for FLTK 1.3.9 because FLTK 1.4.0 does not (yet) support Cygwin in the CMake build. I'll try to fix this in the near future, but for now I'd appreciate if you tried same you did for 1.3.9 and reported if this worked. If it doesn't work OOTB, please try to add one of (a) '--disable-x11' or (b) '--disable-cygwin' or both. This makes a total of four different builds (no option, option a, b, or both) but since I can't test this myself your tests would be very much appreciated.

BTW, how "old" is your Cygwin installation, is it up-to-date? I'm asking because I *might* try to install Cygwin on one of my systems for testing purposes. Since my disk space (in a VM) is very limited, can you estimate how large a Cygwin installation that allows to build FLTK would be?

Thanks in advance

Albrecht

[imm]

On Fri, 16 Feb 2024, 17:40 Brian wrote:

I've attached the logfile cmake created if that helps. 

This line looks suspicious - as if the only choices are X11 or wayland, not also win32/GDI ?

-- Use Wayland             : No (therefore, X11 is used)

Hmm, that looks very much like cmake thinks your a POSIX system (which I suppose cygwin is, kinda...)

Is there some magic incantation we can give to cygwin to make it be "Windows native"? I'm sure there used to be but it's been so long that I don't remember.

Or... Maybe try just using the autoconf configure scheme instead of cmake?

Autoconf isn't as "smart" as cmake so maybe it'll make fewer (wrong) assumptions?

Dunno...

[Albrecht Schlosser]

On 2/16/24 19:08 imm wrote:

On Fri, 16 Feb 2024, 17:40 Brian wrote:

I've attached the logfile cmake created if that helps. 

This line looks suspicious - as if the only choices are X11 or wayland, not also win32/GDI ?

-- Use Wayland             : No (therefore, X11 is used)

Hmm, that looks very much like cmake thinks your a POSIX system (which I suppose cygwin is, kinda...)

It should be similar to MinGW and MSYS2 which are based on Cygwin as well. But these systems don't support X11 anyway IIRC.

The main questions are:

- which CMake version is executed (is it from a Cygwin package or maybe a Windows version?)
- what does the executed CMake version deduct from its environment?
- what does our CMake script do with this information.

CMake provides e.g. the variable CYGWIN which means that the current target system is Cygwin, and I see that we're checking it at some places, like in:

  CMake/options.cmake:688: if(WIN32 AND NOT CYGWIN)

but I assume that we don't do this consequently. I can't remember to have read Cygwin related questions for a long time which probably means that nobody tested FLTK + CMake on Cygwin recently.

Is there some magic incantation we can give to cygwin to make it be "Windows native"? I'm sure there used to be but it's been so long that I don't remember.

If you mean "on the Cygwin level", then I assume the answer is "no".

I believe that we can use the CMake option FLTK_BACKEND_X11=OFF to say: I'm building on Cygwin but I don't want X11, build for Windows/GDI instead. This would be similar to using 'configure --disable-x11' when using Cygwin.

Or... Maybe try just using the autoconf configure scheme instead of cmake?

Autoconf isn't as "smart" as cmake so maybe it'll make fewer (wrong) assumptions?

Yes, that's what I proposed as well so we can see if this works at least. As I wrote already, I'm still working on the "Modern CMake" switch, and Cygwin didn't have priority during the last months (not tested by me at all because I don't have a running system with Cygwin).

[Brian Emberling]

My CYGWIN install is up to date (update yesterday).

CMAKE is from cygwin:

    % which cmake

     /usr/bin/cmake

    % cmake --version

         cmake version 3.25.3

Trying to build FLTK 1.4 with "configure"

    autoconf

    ./configure   --enable-localzlib --enable-localpng --prefix=c:/fltk

    make

  

Dies pretty early with:

    Compiling Fl_Browser.cxx...
    In file included from Fl.cxx:22:
    ../FL/platform.H:68:8: error: ‘Window’ does not name a type; did you mean ‘Fl_Window’?
       68 | inline Window fl_xid(const Fl_Window* w) { Fl_X *xTemp = Fl_X::flx(w); return xTemp ? (Window)xTemp->xid : 0; }
          |        ^~~~~~
          |        Fl_Window
    ../FL/platform.H:74:29: warning: ‘fl_find’ initialized and declared ‘extern’
       74 | extern FL_EXPORT Fl_Window* fl_find(Window xid);
          |                             ^~~~~~~
    ../FL/platform.H:74:37: error: ‘Window’ was not declared in this scope
       74 | extern FL_EXPORT Fl_Window* fl_find(Window xid);

...

I've attached the config.log from './configure' if it helps.

(unrelated but strange/annoying:  CMAKE detects 'system zlib & png', while './configure' always picks 'built-in zlib & png')

[Mo_Al_]

The official cygwin port builds fltk against xlib:

https://cygwin.com/packages/summary/fltk-src.html

The config.log you attached shows you're building for the x86_64-unknown-cygwin target, so the default build against libX11 seems correct. Anyways I tried building FLTK with cygwin's gcc-g++ package (which targets x86_64-unknown-cygwin) after modifying the CMake files to include the windows driver and it fails on several win32 calls like _wopen and _wputenv.

It also lacks the <direct.h> header, but can be replaced with dirent.h.

I'm guessing that the fact that fltk 1.3.9 builds with win32 support is just a happy coincidence. configure from autotools on msys2  I'm guessing!

The fltk-config output from 1.3.9 doesn't seem to be compatible with cygwin since I don't think it's shell understands c:/fltk/lib but I'm not sure!

[Albrecht Schlosser]

On 2/16/24 21:43 Brian Emberling wrote:

My CYGWIN install is up to date (update yesterday).

CMAKE is from cygwin:

    % which cmake

     /usr/bin/cmake

    % cmake --version

         cmake version 3.25.3

Thanks.

Trying to build FLTK 1.4 with "configure"

    autoconf

    ./configure   --enable-localzlib --enable-localpng --prefix=c:/fltk

    make

  

Dies pretty early with:

    Compiling Fl_Browser.cxx...
    In file included from Fl.cxx:22:
    ../FL/platform.H:68:8: error: ‘Window’ does not name a type; did you mean ‘Fl_Window’?
       68 | inline Window fl_xid(const Fl_Window* w) { Fl_X *xTemp = Fl_X::flx(w); return xTemp ? (Window)xTemp->xid : 0; }
          |        ^~~~~~
          |        Fl_Window
    ../FL/platform.H:74:29: warning: ‘fl_find’ initialized and declared ‘extern’
       74 | extern FL_EXPORT Fl_Window* fl_find(Window xid);
          |                             ^~~~~~~
    ../FL/platform.H:74:37: error: ‘Window’ was not declared in this scope
       74 | extern FL_EXPORT Fl_Window* fl_find(Window xid);

...

I've attached the config.log from './configure' if it helps.

I'm not sure, but anyway, thanks for that as well.

Well, your error message above looks like configure detected a Unix (X11) system environment. That's not what we want.

... digging in my faint memory ... now ISTR that I used the mingw-w64 cross tools under Cygwin to build FLTK for native Windows with configure -long, long ago.

Something like './configure --host=x86_64-w64-mingw32' or './configure --target=x86_64-w64-mingw32'. This requires that you installed the mingw cross-compiler tools under Cygwin. With these tools installed the build *might* work. Note that my experience with Cygwin may be 10 years old, I'm not sure about nothing. ;-)

It's very likely possible to build FLTK under Cygwin, but there are easier and less error prone ways if you just want to build Windows programs with free tools, for instance MinGW or MSYS/mingw-w64.

That said, it's very likely that you would also have to setup a toolchain file to use the mingw-w64 cross-compiler toolchain if you try to build with CMake under Cygwin. I'm cross-compiling regularly on my Linux host to build FLTK for Windows - to avoid starting my VM or a real Windows system. Cygwin should work similar in this regard.

How to setup a toolchain file for the mingw-w64 cross-compiler is described in the file README.CMake.txt in section 2.7, including an example toolchain file. You could try this after installing the toolchain packages, likely 'mingw64-x86_64-gcc-g++' and/or some other packages with a similar name. You would need to adjust the paths in the toolchain file though, but the required changes should be obvious.

Yes, it's true, if you want to build "native" Windows programs under Cygwin you need to use a cross-compiler! The Cygwin environment is like a Linux host and the target is (native) Windows. This is also mentioned in README.Windows.txt:

 The Tools
-----------

There are currently three main configurations supported by
FLTK with the GNU tools:

    1. Cygwin: Built using the Cygwin toolset and using the Unix-like
       POSIX compatibility layer provided by the Cygwin DLL.
       License: GPL or non-free commercial license (ask Redhat).

    2. Cygwin using the MinGW cross compiler suite: Built using
       the Cygwin tools but not using the Cygwin DLL.
       License: freely distributable on all Windows systems.

    3. MinGW: Built using the MinGW utilities, compiler and tools. This
       is, in many aspects, analogous to (2.). This is the recommended
       one if you want to build native Windows programs only.
       License: freely distributable on all Windows systems.

Point 2 above is what I was talking about.

(unrelated but strange/annoying:  CMAKE detects 'system zlib & png', while './configure' always picks 'built-in zlib & png')

It depends on which headers you installed and where the tools search. This is not relevant for now, until you get the right setup to build FLTK. Then it matters whether you "find" the right headers and libs. Under Cygwin you should always use the bundled libs rather than system libs because the latter will likely not be compatible with "native" Windows, i.e. you would need a Cygwin environment to execute the programs which you may not want.

[ed.vi...@gmail.com]

Hi

I am having the same issue. With 1.3.x, the configure script worked beautifully when compiling to use the native Windows.

With fltk 1.4.x under Cygwin, I get the same window error as above.

Will this issue be fixed, or is the release of 1.5 (using cmake) imminent enough to not warrant it?

Cheers

Ed

[Albrecht Schlosser]

On 1/3/26 14:09 ed.vi...@gmail.com wrote:

I am having the same issue. With 1.3.x, the configure script worked beautifully when compiling to use the native Windows.

First of all: are you sure that FLTK 1.3 "configure" still works on your current Cygwin setup? Maybe the Cygwin guys changed something, and maybe you updated your Cygwin installation?

With fltk 1.4.x under Cygwin, I get the same window error as above.

I'm not sure what to suggest except what has already been written. Unfortunately, the original author of the old thread has not given any feedback after my last post.

After reading the thread again I think it might be worth to configure with `--disable-cygwin` additionally to what I wrote before, like this:

  $ ./configure --enable-localzlib --enable-localpng --enable-localjpeg --disable-cygwin --disable-x11 ...

IMHO the "problem" with Cygwin was that the Cygwin maintainers didn't want to make it easy to produce "native Windows" executables in favor of executables built for the Cygwin eco-system, i.e. with X11 and using the Cygwin DLL. This may have changed, I don't know. I didn't follow Cygwin development for years.

IIRC: if you use (explicitly or implicitly) `--enable-cygwin` then the required compiler macro `_WIN32`[¹] is not defined which would likely result in the build error you posted, i.e. detecting a Unix / X11 system (build target) rather than native Windows.
[¹] in FLTK 1.3 we used `WIN32` - without the underscore! This had to be defined by the build system which we don't do anymore since 1.4. Maybe this is the underlying cause, but changing this by defining `_WIN32` is definitely not the solution. Believe me.

Note: even at the time I used Cygwin (many years ago) the "correct" way to build "native Windows" programs (i.e. those w/o X11 and "portable" to bare (non-Cygwin) Windows systems) was to install the MinGW or MinGW-w64 cross compiler tools (yes, indeed!) as a cross-compiler (sic!) and to use this to build native Windows programs. And I did this successfully when I still used Cygwin on my old Windows systems. With configure this would require to use `--host` or `--target` commandline switches and this *should* still work with FLTK 1.4. I wrote before (citing myself):

> Something like './configure --host=x86_64-w64-mingw32' or './configure --target=x86_64-w64-mingw32'.¹
> This requires that you installed the mingw cross-compiler tools under Cygwin. With these tools installed
> the build *might* work. Note that my experience with Cygwin may be 10 years old,

IIRC the former (--host=...) is the correct solution. You should try this if you really want to build FLTK 1.4 with configure, but I strongly recommend to use CMake instead.

Will this issue be fixed, or is the release of 1.5 (using cmake) imminent enough to not warrant it?

There are no plans to "fix" anything in the `configure/Make` build system, or generally speaking; in FLTK 1.4 (unless we find serious bugs). It's probably not even necessary if you configure with the correct switches.

That said, there is currently no schedule for FLTK 1.5. There are some new features we want to implement in 1.5 (e.g. touch screens with multi-finger gestures) that may take some (yet unkown) time to do.

However, FLTK 1.4 and 1.5 can both be used with CMake and for cross-compiling as described in README.CMake.txt. Since FLTK 1.5 doesn't support configure anymore this would be a good time to try CMake with 1.4 so you are well prepared for FLTK 1.5. Any feedback would be appreciated.

Note: I'm regularly testing the cross-compiler build with the above mentioned MinGW-w64 compiler toolchain under Linux which should be very similar to that you may want to use on Cygwin. The built Windows executables can be executed with `wine` under Linux and even in my ancient WinXP virtual machine as standard Windows executables (tested recently).

I hope this helps, and I'm looking forward for your feedback. TIA.

Yes, it's true, if you want to build "native" Windows programs under Cygwin you need to use a cross-compiler! The Cygwin environment is like a Linux host and the target is (native) Windows. This is also mentioned in README.Windows.txt ...

[ed.vi...@gmail.com]

Hi

I think the change lies in fltk 1.4.x. configure under 1.3.8 worked with my original cygwin version. 1.4.4 did not. I updated cygwin and the situation remained the same. I had not updated my windows at any time during this.

I tried a cmake build of 1.4.4. I set FLTK_BACKEND_X11 off. It compiled but still built X11. I think it tried to build wayland and failed so it fell back to X11. Is there another setting that I am missing?

The program "works" under X11 though there are issues.

Cheers

Ed 

[Albrecht Schlosser]

On 1/10/26 11:09 ed.vi...@gmail.com wrote:

 think the change lies in fltk 1.4.x. configure under 1.3.8 worked with my original cygwin version. 1.4.4 did not. I updated cygwin and the situation remained the same. I had not updated my windows at any time during this.

Thanks for this info. As I wrote before I don't have a current Windows system with Cygwin anymore, hence I can't test it. Obviously there are not many Cygwin + FLTK users anymore, or other users managed to build FLTK and didn't ask for help. Maybe I can try installing Cygwin but I'm currently short of disk space in my VM which means some extra work to get this done, so please don't hold your breath... 

I tried a cmake build of 1.4.4. I set FLTK_BACKEND_X11 off. It compiled but still built X11. I think it tried to build wayland and failed so it fell back to X11. Is there another setting that I am missing?

Probably not. This configuration (CMake under Cygwin +/- X11) has not been tested by the FLTK Team.

As I wrote before, the way to build FLTK w/o X11 under Cygwin is to "cross-compile" it with the MinGW-w64 cross-build toolchain. Sorry, I won't repeat that fact anymore. See advice in the cited previous reply (below). Please try this first, before we (i.e. I) continue to investigate further build options.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/5f90e8e8-4d9c-4087-b7a8-9e576812a878n%40googlegroups.com.

[Albrecht Schlosser]

Correction / addition:

On 1/10/26 17:01 'Albrecht Schlosser' wrote:
> On 1/10/26 11:09 ed.vi...@gmail.com wrote:
>>  think the change lies in fltk 1.4.x. configure under 1.3.8 worked
>> with my original cygwin version. 1.4.4 did not. I updated cygwin and
>> the situation remained the same. I had not updated my windows at any
>> time during this.
>
> Thanks for this info. As I wrote before I don't have a current Windows
> system with Cygwin anymore, hence I can't test it. Obviously there are
> not many Cygwin + FLTK users anymore, or other users managed to build
> FLTK and didn't ask for help. Maybe I can try installing Cygwin but
> I'm currently short of disk space in my VM which means some extra work
> to get this done, so please don't hold your breath...
>
>> I tried a cmake build of 1.4.4. I set FLTK_BACKEND_X11 off. It
>> compiled but still built X11. I think it tried to build wayland and
>> failed so it fell back to X11. Is there another setting that I am
>> missing?
>
> Probably not. This configuration (CMake under Cygwin +/- X11) has not
> been tested by the FLTK Team.

Note: I'm aware that I suggested to try this, so thanks for doing this.
Obviously there are issues with CMake though.

> As I wrote before, the way to build FLTK w/o X11 under Cygwin

[add:] using configure + make

>  is to "cross-compile" it with the MinGW-w64 cross-build toolchain.
> Sorry, I won't repeat that fact anymore. See advice in the cited
> previous reply (below). Please try this first, before we (i.e. I)
> continue to investigate further build options.

Note that I appreciate your help to figure this out, but lacking a
Cygwin installation and with my limited time I can't test this for you.
Sorry.

[ed.vi...@gmail.com]

Hi

I got closer to compiling with cygwin with configure on 1.4.4. There is an issue in FL/platform.H. If I force it to include "win32.H" it solves the Window issue. 

it seems that _WIN32 is not defined at that point.

BTW, I have a fork() in my code so I cannot follow the MinGW route unless I get around that.

Cheers

Ed

[Albrecht Schlosser]

On 1/12/26 15:51 ed.vi...@gmail.com wrote:

I got closer to compiling with cygwin with configure on 1.4.4. There is an issue in FL/platform.H. If I force it to include "win32.H" it solves the Window issue. 

it seems that _WIN32 is not defined at that point.

OK, this is (somehow) expected. If you configure with Cygwin ("--enable-cygwin") either by default or explicitly, then neither WIN32 nor _WIN32 are defined by the compiler toolchain IIRC. This indicates that the build is intended to be used in a Posix environment like Unix/Linux or Cygwin with its own X11 capabilities etc.. Consequently our FL/platform.H includes the X11 and not the Windows headers. That would likely explain what you see.

BTW, I have a fork() in my code so I cannot follow the MinGW route unless I get around that.

OK, then I assume that you need the Cygwin DLL as well. But if this is the only reason then I think it's possible to replace this with Windows functions under conditional compilation. However, if you have more Unix/Posix calls you need to support, then it's more difficult.

You wrote above:"If I force it to include "win32.H" it solves the Window issue". What if you build your FLTK library with defining "_WIN32" as a commandline option. There are several ways, but here's one that I would try (whether it does what you want to achieve I can't tell though):

$ CXXFLAGS="-D_WIN32" ./configure ... (other options).

Good luck.

[Ian MacArthur]

On Monday, 12 January 2026 at 14:51:25 UTC Ed wrote:

Hi

I got closer to compiling with cygwin with configure on 1.4.4. There is an issue in FL/platform.H. If I force it to include "win32.H" it solves the Window issue. 

it seems that _WIN32 is not defined at that point.

BTW, I have a fork() in my code so I cannot follow the MinGW route unless I get around that.

FWIW, I got so fed up with cygwin that (I suspect like Albrecht) that I uninstalled it.

I don't think I have a cygwin dev environment on any of my Windows machines now, they're all Msys(2)/mingw(64) now...

That's made a lot of stuff simpler!

And fork() notwithstanding, it's generally been a lot better - the generated code _seems_ to be smaller and faster, but that may not be so (I don't have robust metrics for this).

However, it has made my DLL management much less painful.

There are implementations of fork() done by wrapping WIN32 native calls, so if that is the only posix-like API you are using then converting over maybe fairly painless.

[ed.vi...@gmail.com]

My build stopped when compiling files in /src/drivers/WinAPI. There are a bunch of Windows only functions (_wfopen, _waccess, etc) that are not available in Cygwin.

I guess Cygwin with native windows was not considered.

[Ian MacArthur]

On Tuesday, 13 January 2026 at 21:36:52 UTC Ed wrote:

My build stopped when compiling files in /src/drivers/WinAPI. There are a bunch of Windows only functions (_wfopen, _waccess, etc) that are not available in Cygwin.

I guess Cygwin with native windows was not considered.

Hi Ed,

Yeah - this sort of thing is why I gave up on cygwin in the end (aside from the DLL mess I got into, of course...)

Back in the day (sometime last century) I was suing cygwin a lot, and it was real easy to build "native" Win32 apps using it, and it was my preferred toolchain for a long time.

But somewhere along the way, it started to become harder and harder to build "native" Win32 code using cygwin.

In discussions at the time, I had the sense this was a conscious choice - as best I can tell, they were focused on providing a toolchain that was intended for building "posix-like" code for the Windows target, and were not all that concerned about providing "native" Win32 support (there being other tools to do that...) In particular, it (my cygwin build) started trying to pull in X11 deps and so forth. This really did not help!
So I moved over to mingw, and that worked well enough that I'd not go back. (Also, though this was getting on for 20 years ago, I had metrics that I collected that suggested that my cygwin build was _substantially_ slower than the "same code" compiled with mingw, so that kinda put the nail in the coffin then...)

Now, it is still possible to build "native" Windows code with cygwin, but it is, as Albrecht said, basically about setting up a cross-compiler environment and using that (i.e. pretty much what you'd do to build Win32 code on Linux with mingw, say.)

Now, most of my work is compiling for embedded systems so I'm not afraid of a cross-compiler toolchain. But it just seems an infeasibly scrappy way to build native Win32 code now.

There are implementations of pthreads and fork and so forth that work with mingw and for me that's been adequate to get stuff going.

[ed.vi...@gmail.com]

Hi Ian

Thanks for the response. 

When I first chose FLTK decades ago as my widget set for my project (meshalyzer, which is still running), one of the reasons was because it looked the same on all platform windowing systems.

I would like to have a stable method for compiling under windows to use the native system, making it easy to build a stand-alone executable to be distributed without extra requirements. In particular, I use fork() and System V IPC in my code. If mingw is the way to go, I am fine with that.

Cheers

Ed

[Ian MacArthur]

On Thursday, 15 January 2026 at 09:58:43 UTC Ed wrote:

When I first chose FLTK decades ago as my widget set for my project (meshalyzer, which is still running), one of the reasons was because it looked the same on all platform windowing systems.

I would like to have a stable method for compiling under windows to use the native system, making it easy to build a stand-alone executable to be distributed without extra requirements. In particular, I use fork() and System V IPC in my code. If mingw is the way to go, I am fine with that.

First of, sorry for slow reply - I went off looking for the old "pseudo-fork" code I had used on Windows "in the past" but I can't find it now. 

Over the intervening time, I've moved away from using fork() (a lot of the environments I code for, especially embedded ones, just don't support that idiom at all, really) and code that did use it has been "ported" (with some judicious use of #ifdef) to try and use "native" API to the equivalent ends...

So: the code I did have, I found somewhere on the internet back in the distant past. My recollection (such as it is) was that it used the Win32 NtCreateProcess API to emulate the fork() behaviour. Note that NtCreateProcess is quite a different thing from the normal Win32 API CreateProcess and apparently was added to NT as part of the legacy Posix API they had. The details elude my now, but I feel I did understand this at the time...

Anyway, my current code, on the WinXX builds, uses "native" API calls instead, mainly variations on the "spawn" API - note that MS provide about 8 different flavours of spawn so you need to pick the one that fits bets in each case! (Why are MS API so fiddly?) Sometimes I use the "exec" API type instead (again in various flavours). It depends...

For threads I use _beginthreadex - with a little bit of fiddling about it's not too hard to make that look like a pthread_create call.

As regards SysV IPC, I don't have anything useful. I was mainly using either pipes (which WinXX will support) or BSD sockets so that code mostly Just Worked with only a little bit of poking.

So... well, I hope that helps anyway.