Skip to content

Conversation

@NattyNarwhal
Copy link
Contributor

(Upstreaming a branch I've had kicking for a month or two. I have not rebased yet; caveat emptor)

I've been making a source control provider compatible with the APIs Microsoft has for it.

I've built up a patchset and this is a cleaned up version that should cleanly support the changes when possible. I can verify the gcc/amd64 Linux build isn't regressed by this. The changes to Vista+ should also be minimal, because everything is tidy ifdefs. (You should be able to test most of this by setting _WIN32_WINNT, which this PR makes changeable at the CMake level. Such a method could also be used to raise Windows versions supported if needed.) Many of the ifdefs handle the older SDK versions as well.

This should support Windows 2000 (primarily tested on XP) and Visual C++ 6 (with processor pack for align and 2003/02 Platform SDK); NT 4 should be trivial to support with 1. changing the version API checks 2. removing all flags for UTF-8 conversions since those were added in 2000 SP4/XP, but I have not added these just yet. Technically 9x is supportable, but it'd require Unicows to wrap wide APIs and I don't know if it supports \?.

Related, old VC++ does make for a good DeathStation 9000 in terms of no C89 or GNU extensions. I wonder if it might be possible to hack up CI with it considering some versions of it were freely available 🤔

A replacement is possible, but the code used to just load it at runtime
and returned -1 if it couldn't, so that'll work for now.
At least with VC++6 projects...
...like old MSVC.

(This should really be picked up from common.h; it seems that there
was a patch to make it so in http_parser.h, but it got clobbered by
syncing with upstream.)
This shim should keep the behaviour close.
#define git_error_set_after_callback(code) \
git_error_set_after_callback_function((code), __FILE__ ":" __LINESTRING__)
#endif
#else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since __func__ doesn't exist in C89 I'd personally prefer to have this one used for more cases and only use __func__ if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)

Considering that the tests uses __func__ a lot it could also be worth considering making a #define __func__ __FUNCTION__ in a include file somewhere for the windows case, and maybe even have your fallback as an alternative for C89 compliance.

Copy link
Member

@ethomson ethomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must admit to being less than excited about the prospect of supporting ancient versions of Windows. But if we have a maintainer for these ancient versions then I'm happier. I don't want to keep this support up myself.

How would CI work do you think? Do we just need an on MSVC on a new platform? Or do we really need to build on some old operating system with an old compiler? Coaxing the GitHub actions runner to run on win2k sounds tricky and is definitely a way that I don't want to spend my weekend.

return 0;
#else
/* Symlinks are unavailable before Vista. */
return git_futils_fake_symlink(target, path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not teach the posix emulation layer about git's notion of fake symlinks. Can we move this up a level and have whatever "can we do symlinks on this platform" check we have return false?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is actually a revert-commit-turned-into-ifdef from before libgit2 was taught about real Win32 symlinks. It's understandable, though I'll have to think of the best way to handle this, since it'll probably be useful for porting to other environments as well.

@NattyNarwhal
Copy link
Contributor Author

NattyNarwhal commented Aug 29, 2021

I totally understand if you don't want to merge this; I myself thought it might not have been worth it (both originally doing, then submitting here), but considered it anyways since I tried to keep the support clean enough I could maintain it. Being C89 kinda invites the possibility though.

I'll see what I can do about cleaning this up further. I wasn't too sure on what was actually C99 or just a GNU extension in a trenchcoat or not.

Regarding CI: I suspect you can just run under WINE an old MSVC toolchain (at least 2003 on were freely available) with an older Platform SDK. Failing that, you could just probably use the existing Windows build infrastructure with _WINNT_WIN32 set downlevel; it works much better than_XOPEN_SOURCE and friends.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants