Skip to content

Comments

Winansi: Drop pre-Vista workaround#6109

Open
rimrul wants to merge 2 commits intogit-for-windows:mainfrom
rimrul:cleanup
Open

Winansi: Drop pre-Vista workaround#6109
rimrul wants to merge 2 commits intogit-for-windows:mainfrom
rimrul:cleanup

Conversation

@rimrul
Copy link
Member

@rimrul rimrul commented Feb 22, 2026

1edeb9a (Win32: warn if the console font doesn't support Unicode,
2014-06-10) introduced both code to detect the current console font on
Windows Vista and newer and a fallback for older systems to detect the
default console font and issue a warning if that font doesn't support
unicode.

Since we haven't supported any Windows older than Vista in almost a
decade, we don't need to keep the workaround.

This more or less fell out of #6108, but didn't quite fit into that PR.

There are also some other version specific hacks and workarounds I considered dropping, but decided against:

Git for Windows doesn't support anything prior to Windows 8.1 since 2.47.0
and Git followed along with commits like ce6ccba (mingw: drop Windows
7-specific work-around, 2025-08-04).

There is no need to pretend to the compiler that we still support Windows
Vista, just to lock us out of easy access to newer APIs. There is also no
need to have conflicting and unused definitions claiming we support some
versions of Windows XP or even Windows NT 4.0.

Bump all definitions of _WIN32_WINNT to a realistic value of Windows 8.1.
This will also simplify code for a followup commit that will improve cpu
core detection on multi-socket systems.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
1edeb9a (Win32: warn if the console font doesn't support Unicode,
2014-06-10) introduced both code to detect the current console font on
Windows Vista and newer and a fallback for older systems to detect the
default console font and issue a warning if that font doesn't support
unicode.

Since we haven't supported any Windows older than Vista in almost a
decade, we don't need to keep the workaround.

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
@dscho
Copy link
Member

dscho commented Feb 22, 2026

492f709

  • I'm unsure if this regression has ever been fixed or just become the new normal.

I'd say this doesn't hurt, so let's keep it. It's safer that way, anyway.

run-command: be helpful when Git LFS fails on Windows 7 #5042

  • So far this hasn't been an issue on Windows 8.1, but officially Go 1.21 and newer only support Windows 10 and newer. So this might become a problem at any point.

Right. I guess we should upstream this ASAP anyway. And then update as soon as even Git LFS on Windows 8.1 is broken.

#define WIN32_LEAN_AND_MEAN
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x403
#define _WIN32_WINNT 0x603
Copy link
Member

Choose a reason for hiding this comment

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

Technically, this is not ours to change, it's nedmalloc. We should probably upstream the mimalloc vendoring-in, and then drop compat/nedmalloc/ from upstream, too: It's woefully unsupported.

As far as this PR is concerned, let's keep this change, it makes it simpler to verify that we haven't missed any _WIN32_WINNT definition.

Copy link
Member Author

Choose a reason for hiding this comment

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

We should probably upstream the mimalloc vendoring-in, and then drop compat/nedmalloc/ from upstream, too

That would be great, but somehow I have my doubts about Junio loving the frequency of our mimalloc updates, the churn of our 4-commit update method or the (very useful) commit message of 266c6eb.

I think he might prefer something more like contrib/update-unicode/update_unicode.sh and the corresponding commits.

Copy link
Member

Choose a reason for hiding this comment

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

Heh. I can always try to upstream as-is 😁

# define WIN32_NATIVE
# if defined (_MSC_VER) && !defined(_WIN32_WINNT)
# define _WIN32_WINNT 0x0502
# define _WIN32_WINNT 0x0603
Copy link
Member

Choose a reason for hiding this comment

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

Technically, this is not ours to change, but I guess it could come back to bite us if we don't. So let's keep this change.

Copy link
Member Author

Choose a reason for hiding this comment

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

By "ours" do you mean Git for Windows or Git? Because it is a Git modification to the vendored code (git@56fb3dd), but I guess it makes sense to drop this all together, since git@e8dfcac made this obsolete.

Copy link
Member

Choose a reason for hiding this comment

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

I mean both Git and Git for Windows; Vendored-in code is harder to maintain if it is modified from the original version.

Copy link
Member Author

Choose a reason for hiding this comment

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

I could upstream a commit to drop this definition alltogether, which would reduce the modifications to vendored code, but I doubt we'll see many updates to the vendored code.

Copy link
Member

Choose a reason for hiding this comment

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

I doubt we'll see many updates to the vendored code.

True.

Comment on lines +9 to +11
#ifndef FLUSH_FLAGS_FILE_DATA_ONLY
#define FLUSH_FLAGS_FILE_DATA_ONLY 1
#endif
Copy link
Member

Choose a reason for hiding this comment

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

We could even drop this altogether, right? If we require a new-enough _WIN32_WINNT, we require this flag to be defined, no?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wasn't sure if that is always the case and we can reasonably expect this, so I thought wrapping it in #ifndef was the safe bet.

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me.

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.

2 participants