build: add Windows CE / CeGCC support, with CI jobs

[vszakats]

Make it possible to build curl for Windows CE using the CeGCC toolchain.
With both CMake and autotools, including tests and examples, also in CI.
The build configuration is the default one with Schannel enabled. No
3rd-party dependencies have been tested.

Also revive old code to make Schannel build with Windows CE, including
certificate verification.

Builds have been throughougly tested. But, I've made no functional tests
for this PR. Some parts (esp. file operations, like truncate and seek)
are stubbed out and likely broken as a result. Test servers build, but
they do not work on Windows CE. This patch substitutes fstat() calls
with stat(), which operate on filenames, not file handles. This may or
may not work and/or may not be secure.

About CeGCC: I used the latest available macOS binary build v0.59.1
r1397 from 2009, in native mingw32ce build mode. CeGCC is in effect
MinGW + GCC 4.4.0 + old/classic-mingw Windows headers. It targets
Windows CE v3.0 according to its _WIN32_WCE value. It means this PR
restores portions of old/classic-mingw support. It makes the Windows CE
codepath compatible with GCC 4.4.0. It also adds workaround for CMake,
which cannot identify and configure this toolchain out of the box.

Notes:

• CMake doesn't recognize CeGCC/mingw32ce, necessitating tricks as seen
  with Amiga and MS-DOS.
• CMake doesn't set MINGW for mingw32ce. Set it and MINGW32CE
  manually as a helper variable, in addition to WINCE which CMake sets
  based on CMAKE_SYSTEM_NAME.
• CMake fails to create an implib for libcurl.dll, due to not
  recognizing the platform as a Windowsy one. This patch adds the
  necessary workaround to make it work.
• headers shipping with CeGCC miss some things curl needs for Schannel
  support. Fixed by restoring and renovating code previously deleted
  old-mingw code.
• it's sometime non-trivial to figure out if a fallout is WinCE,
  mingw32ce, old-mingw, or GCC version-specific.
• WinCE is always Unicode. With exceptions: no wmain,
  GetProcAddress().
• _fileno() is said to convert from FILE * to void * which is
  a Win32 file HANDLE. (This patch doesn't use this, but with further
  effort it probably could be.)
  https://stackoverflow.com/questions/3989545/how-do-i-get-the-file-handle-from-the-fopen-file-structure
• WinCE has no signals, current directory, stdio/CRT file handles, no
  _get_osfhandle(), no errno, no errno.h. Some of this stuff is
  standard C89, yet missing from this platform. Microsoft expects
  Windows CE apps to use Win32 file API and FILE * exclusively.
• revived CeGCC here (not tested for this PR):
  https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/

On UNDER_CE vs. _WIN32_WCE: (This patch settled on UNDER_CE)

• A custom VS2008 WinCE toolchain does not set any of these.
  The compiler binaries don't contain these strings, and has no compiler
  option for targeting WinCE, hinting that a vanilla toolchain isn't
  setting any of them either.
• UNDER_CE is automatically defined by the CeGCC compiler.
  https://cegcc.sourceforge.net/docs/details.html
• UNDER_CE is similar to _WIN32, except it's not set automatically
  by all compilers. It's not supposed to have any value, like a version.
  (Though e.g. OpenSSL sets it to a version)
• _WIN32_WCE is the CE counterpart of the non-CE _WIN32_WINNT macro.
  That does return the targeted Windows CE version.
• _WIN32_WCE is not defined by compilers, and relies on a header
  setting it to a default, or the build to set it to the desired target
  version. This is also how _WIN32_WINNT works.
• _WIN32_WCE default is set by windef.h in CeGCC.
• _WIN32_WCE isn't set to a default by MSVC Windows CE headers (the
  ones I checked at least).
• CMake sets _WIN32_WCE=<ver>, UNDER_CE, WINCE for MSVC WinCE.
• _WIN32_WCE seems more popular in other projects, including CeGCC
  itself. zlib is a notable exception amongst curl dependencies,
  which uses UNDER_CE.
• Since _WIN32_WCE needs "certain" headers to have it defined, it's
  undefined depending on headers included beforehand.
• curl/curl.h re-uses _WIN32_WCE's as a self-guard, relying on
  its not-(necessarily)-defined-by-default property:
  

  curl/include/curl/curl.h

  Line 77 in 25b445e

  #if defined(_WIN32) && !defined(_WIN32_WCE) && !defined(__CYGWIN__)

Toolchain downloads:

• Windows:
  https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_cygwin1.7_r1399.tar.bz2
• macOS Intel:
  https://downloads.sourceforge.net/cegcc/cegcc/0.59.1/cegcc_mingw32ce_snowleopard_r1397.tar.bz2

---

w/o whitespace: https://github.com/curl/curl/pull/15975/files?w=1

• add cmake GHA job.
• add autotools GHA job.
• fix pending compiler warnings.
• re-add HAVE_SIGNAL_H, HAVE_ERRNO_H? They are C89, yet WinCE chose not to support them.
  96c2990 build: delete checks for C89 standard headers #11940
  fe3463e build: assume errno.h is always available #9986
  SKIP, it's enough to do this once there is one more platform with such need.
• publish get_winapi_error() from lib to re-use in tests. (replacing the copy-pasted duplicate)
• split off unrelated changes to separate PRs.
• tidy up.
• settle on UNDER_CE vs. _WIN32_WCE. → UNDER_CE

[talregev]

Are you thinking to add vcpkg to compile with windows CE?

[vszakats]

Are you thinking to add vcpkg to compile with windowxe?

Does vcpkg support Windows CE via mingw32ce?

[talregev]

vcpkg support mingw in community. I can try to see if it works with that mingw.

[vszakats]

vcpkg support mingw in community. I can try to see if it works with that mingw.

Sounds good to me! This is a rather niche mingw (based on the old-mingw
aka mingw 1.0).

Another interesting challenge would be making a WinCE build with either
VS2008 or ideally with VS2015. I have no idea how to bring those toolchains
up and running, locally or CI.

There is also the "revived" mingw32ce, but it needs to be built from source
and doesn't seem to improve much on the old-mingw-style SDK headers, which
is one pain point with mingw32ce. But I haven't made a try with it.

Also, actually running any of these builds under an emulator would be interesting,
but to me, this amount of retro-computing was I think more than enough for
a while! :)

[talregev]

@vszakats why you run wince under macos? can you try on linux?
on macos there isn't vcpkg maintain (same problem for ios vcpkg).

[vszakats]

@vszakats why you run wince under macos? can you try on linux? on macos there isn't vcpkg maintain (same problem for ios vcpkg).

Pre-built CeGCC binaries are available for macOS and Windows.

Of these, the to unixy macOS runner is faster and easier to work
with, and also what I use locally for tests.

Linux would be nicer but this isn't officially packaged, external
binaries aren't available for download (sadly, this still isn't a thing
on Linux). Building from source is in theory an option, but
a separate project on itself, if someone is interested in this (I am
personally not). Maybe there is a docker image somewhere, but
I haven't really looked (and it's also an extra layer, that I prefer to
avoid if there is a way).

[talregev]

will you try from here?
https://sourceforge.net/projects/cegcc/files/cegcc/0.59.1/

[vszakats]

will you try from here? https://sourceforge.net/projects/cegcc/files/cegcc/0.59.1/

These are the binaries I was working with, and what's used in CI.
The direct links are in the PR message, to the specific archives in this directory.

[vszakats]

Forgot to mention it publicly:

With ./configure, I added the ac_cv_prog_cc_c99=no hack
to avoid these unexplained compiler warnings:

../../lib/ftp.c: In function 'Curl_GetFTPResponse':
../../lib/ftp.c:726: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
../../lib/ws.c: In function 'ws_dec_pass_payload':
../../lib/ws.c:304: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
../../lib/ws.c: In function 'ws_enc_write_head':
../../lib/ws.c:581: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'long int'

Maybe there is a better solution; I didn't explore this rabbit hole in depth.
Off hand it looks like a compiler issue and/or combined with mis(?)-detection
of C99 mode?

[jay]

warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'

As long ssize_t has a size of signed size_t type (int I'd assume in this case) I don't see a problem

[vszakats]

warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'

As long ssize_t has a size of signed size_t type (int I'd assume in this case) I don't see a problem

Yes, it should be the case.

Which made me think this is possibly a GCC bug and not worth addressing.
But it affects default autotools builds due to it detecting C99 and hitting this.

Maybe there is a #if combo to detect this case to set CURL_NO_FMT_CHECKS?

[vszakats]

test: #16492 (comment)

[vszakats]

This patch seems to work to fix (=silence) it: e6359ca

The next question is why does autotools want to detect C11 and C99 in these builds, and not in others:

checking whether /Users/runner/opt/mingw32ce/bin/arm-mingw32ce-gcc accepts -g... yes
checking for /Users/runner/opt/mingw32ce/bin/arm-mingw32ce-gcc option to enable C11 features... unsupported
checking for /Users/runner/opt/mingw32ce/bin/arm-mingw32ce-gcc option to enable C99 features... -std=gnu99
checking whether /Users/runner/opt/mingw32ce/bin/arm-mingw32ce-gcc -std=gnu99 understands -c and -o together... yes

https://github.com/curl/curl/actions/runs/13534146058/job/37822577315?pr=16492#step:6:74

vs. a normal mingw builds:

checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes

https://github.com/curl/curl/actions/runs/13534146058/job/37822579122?pr=16492#step:7:73