-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
build: add Windows CE / CeGCC support, with CI jobs
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: https://github.com/curl/curl/blob/25b445e4796bcbf9f842de686a8c384b30f6c2a2/include/curl/curl.h#L77 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 Closes curl#15975
- Loading branch information
Showing
89 changed files
with
943 additions
and
237 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.