Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

msvc: require VS2005 for large file support #15958

Closed
wants to merge 6 commits into from

Conversation

vszakats
Copy link
Member

@vszakats vszakats commented Jan 9, 2025

Large file support requires _fseeki64(). This function is offered in
VS2005 and upper.

VS2003 has it in the static CRT only, with declaration missing from
headers, so it's not usable.

Ref: https://archive.org/details/X10-38445 (MS Visual Studio .NET 2003)
Ref: 8b76a8a #15526

@vszakats vszakats added build Windows Windows-specific labels Jan 9, 2025
@jay
Copy link
Member

jay commented Jan 9, 2025

I have Visual C++ 6.0 and 7.1 installed in an XP VM but as far as I know they cannot build curl. We removed support for those versions some time ago I thought?

Anyway I am not sure about the _fseeki64 declaration. I cannot find it in the DLLs used by those versions which is probably why it's not declared? It is in the static versions of the CRT though which is odd. For example in 7.1 I created a test project and set the CRT via C/C++ > Code Generation > Runtime Library to Multi-threaded debug DLL but I could not reference _fseeki64. Such an application uses msvcr71d.dll which does not have _fseeki64. You can use dependency walker (depends.exe) to see all the exports. This wasn't an exact test now that I think about it because I built the unit as C++ and not C but I think the point is the same

Capture

@vszakats
Copy link
Member Author

vszakats commented Jan 9, 2025

You're right, it's indeed only in these static libs: libcmtd.lib, libcmt.lib,
libc.lib, libcd.lib.

In that case, we can guard it for _MSC_VER >= 1400, where it should
probably exist (I haven't verified with an actual toolchain). But that may
not be enough, and USE_WIN32_LARGE_FILES also needs to be disabled
for earlier versions.

I could find no information in repo about the minimum MSVC version
we require. Also can't remember which one we settled in earlier
discussions. Maybe we should figure it out and it put it somewhere in docs?

@vszakats vszakats marked this pull request as draft January 9, 2025 20:45
@jay
Copy link
Member

jay commented Jan 9, 2025

I could find no information in repo about the minimum MSVC version
we require. Also can't remember which one we settled in earlier
discussions. Maybe we should figure it out and it put it somewhere in docs?

Well it's more like over time we kind of whittled it down. The project generator in projects/ used to support Visual Studio 2008 or Visual C++ versions VC6 - VC9 (1998-2008) but they became too old to maintain and were removed years ago. winbuild still supports those old versions because we didn't really need to do anything special for them except this so there was no additional maintenance.

Somehow 0.4% of people are still using libcurl in Windows CE according to the 2024 survey but the Windows CE SDK I think only works for Visual Studio 2008 and earlier. I don't have the Windows CE stuff installed and I don't know how to build libcurl for Windows CE unless there is some private build method we don't know about. Sounds theoretical but someone may still be using lib/config-win32ce.h just in some way I can't figure out

@vszakats
Copy link
Member Author

vszakats commented Jan 9, 2025

I could find no information in repo about the minimum MSVC version
we require. Also can't remember which one we settled in earlier
discussions. Maybe we should figure it out and it put it somewhere in docs?

Well it's more like over time we kind of whittled it down. The project generator in projects/ used to support Visual Studio 2008 or Visual C++ versions VC6 - VC9 (1998-2008) but they became too old to maintain and were removed years ago. winbuild still supports those old versions because we didn't really need to do anything special for them except this so there was no additional maintenance.

Somehow 0.4% of people are still using libcurl in Windows CE according to the 2024 survey but the Windows CE SDK I think only works for Visual Studio 2008 and earlier. I don't have the Windows CE stuff installed and I don't know how to build libcurl for Windows CE unless there is some private build method we don't know about. Sounds theoretical but someone may still be using lib/config-win32ce.h just in some way I can't figure out

Windows CE is a mystery to me too! I've been fixing up WinCE issues for
a long time in another project, and it seems unlikely curl builds out of the
box as it is. Possibly with patches and/or a narrow configuration
that tries to avoid problematic code? It also seems likely by looking at the
code that WinCE support is MSVC-specific, i.e. cegcc, the mingw-based
toolchain (dead for a long time) is not supported. There is also Pelles C
with CE support, but that compiler support itself is another mystery.

The strangest is there is never a report/submission about WinCE.

I'd be glad to see how a WinCE build is done, and ideally we should have
a job for it in CI.

As for desktop Windows, I'm referring to this article:
https://datagirl.xyz/posts/wolfssl_curl_w2k.html
an attempt to build curl 8.x for Win95. It hits some interesting problems,
but even they didn't attempt to use a compiler older than VS2003.

That's why I was holding VS2003 as a last supported version, a "random"
choice I admit, half just for fun.

I'm fine with making VS2010 the minimal required version, but I think
it'd be nice to put that somewhere for everyone to see and remember.

What would be a good place for it?

@bagder
Copy link
Member

bagder commented Jan 9, 2025

I've been fixing up WinCE issues for a long time in another project, and it seems unlikely curl builds out of the box as it is

I worked with a customer just a few years ago who built and used curl just fine on WinCE. I mean, to the extent anything can be fine there. They used libcurl instead of native solutions because they needed a modern TLS version and winCE offers no such thing natively.

@vszakats
Copy link
Member Author

vszakats commented Jan 9, 2025

I've been fixing up WinCE issues for a long time in another project, and it seems unlikely curl builds out of the box as it is

I worked with a customer just a few years ago who built and used curl just fine on WinCE. I mean, to the extent anything can be fine there. They used libcurl instead of native solutions because they needed a modern TLS version and winCE offers no such thing natively.

No doubt they did it, but it leaves me wondering, how? Is it a recent curl
version? What build tool is it using?

WinCE must also use Unicode, except at a few places, like GetProcAddress
curl doesn't have logic to handle that for example. It seems plausible that
a WinCE build requires a certain old MSVC compiler. It'd be useful to know
which one, to consider it when dropping old versions.

A casual search hinted that VS2008 is the last version supporting CE.
That may be a reason to keep it, or even restore it in CI. It also gets
back to the stdint.h discussion.

@jay
Copy link
Member

jay commented Jan 10, 2025

No doubt they did it, but it leaves me wondering, how? Is it a recent curl
version? What build tool is it using?

I just asked on the libcurl mailing list.

@vszakats
Copy link
Member Author

Meanwhile confirmed that VS2005 headers do declare _fseeki64().
_MSC_VER >= 1400 is OK. That might also be a reasonable MSVC
minimum. (We lose the fun option to build for Win95 with MSVC, but
mingw-w64 might still do that.)

Ref: https://archive.org/details/en_vs_2005_cd

@MarcelRaad
Copy link
Member

the Windows CE SDK I think only works for Visual Studio 2008 and earlier

Windows CE got renamed to Windows Embedded Compact later. Windows Embedded Compact 2013 applications can be built with Visual Studio 2015:
https://www.microsoft.com/en-us/download/details.aspx?id=38819

@vszakats
Copy link
Member Author

Found out there is also a CeGCC cross-toolchain for macOS:
https://master.dl.sourceforge.net/project/cegcc/cegcc/0.59.1/cegcc_mingw32ce_snowleopard_r1397.tar.bz2

The CeGCC project being dead isn't so much of an issue, because
CE didn't change much in the last 2 decades. These binaries are x86_64,
and still do run. Date is 2009. Also since it's a self-contained package,
and seems easy to run (also CI). The official MS toolchain I admit I never
managed to make work locally. The MSVC once working is a frankenstein
toolchain built by someone else.

Anyhow the build launches now with CMake + CeGCC, and it looks like
a long way to clear all the build failures.

@vszakats vszakats changed the title msvc: declare _fseeki64() for VS2003 msvc: require VS2005 for large file support Jan 11, 2025
@vszakats vszakats marked this pull request as ready for review January 11, 2025 02:04
@jay
Copy link
Member

jay commented Jan 11, 2025

There was one reply on the mailing list from someone who builds libcurl for Windows CE. They said they can provide info on how to build it. So I'd wait for that to see how they're doing it before any decisions are made.

@vszakats
Copy link
Member Author

There was one reply on the mailing list from someone who builds libcurl for Windows CE. They said they can provide info on how to build it. So I'd wait for that to see how they're doing it before any decisions are made.

Thanks! I suppose this PR is valid regardless? It was not my intention to change the cutoff version or anything like it. Just to fix this build case.

@jay
Copy link
Member

jay commented Jan 11, 2025

Yes, no objections. I meant we should wait before we make any decisions on minimum MSVC. Requiring cegcc to build libcurl for Windows CE might not work, so if it were me I would not put time into it until we hear from this guy that was successful using Visual Studio 2008 but we don't know exactly how yet.

@vszakats
Copy link
Member Author

vszakats commented Jan 11, 2025

Yes, no objections. I meant we should wait before we make any decisions on minimum MSVC. Requiring cegcc to build libcurl for Windows CE might not work, so if it were me I would not put time into it until we hear from this guy that was successful using Visual Studio 2008 but we don't know exactly how yet.

Agreed, CeGCC is not a solution to replace MSVC for WinCE.

But, it has nice properties as an extra option:

  • works without a Windows machine.
  • may be easy to make it work in CI too. (it should run on ARM macOS runners as an x86_64 binary, if Rosetta is installed there. If that fails, there Windows runner can work.)
    (Setting up MSVC + CE in CI looks hopeless, for me at least.)

I went ahead with CeGCC. It brings back the pain as I remembered. There is no errno in Windows CE for example. fileno() returns void *.

I'm down to 15 warnings, no more errors, and static/shared libs, curl.exe generated with CMake.

The CRT has this function but its declaration is missing from headers.
(This may be true for VS2002 or earlier versions but I didn't check.)

Confirmed by looking at the public CRT source, headers and libs, but
haven't made an actual build.
This reverts commit a0e24ce.

It's only in the static CRT.
@vszakats vszakats closed this in 0ad30f0 Jan 12, 2025
@vszakats vszakats deleted the old-msvc-fseeki64 branch January 12, 2025 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Windows Windows-specific
Development

Successfully merging this pull request may close these issues.

4 participants