The problem/use-case that the feature addresses
Windows is a popular operating system, even its Server version is popular.
My main target is to have the same tech stack on the server deployment as the local development environment. So no additional levels of abstraction (virtual machines, Docker, etc.).
Description of the feature
Port to MSVC
Alternatives you've considered
Contribute to https://github.com/tporadowski/redis;
Or start from scratch… with a CMake + automerge with redis master focus;
Or give up!
Additional information
https://github.com/tporadowski/redis/issues/108
Looks like there's a lot of issues with keeping up to date with your master. But if we can merge Windows support into your master…
Comment From: oranagra
@SamuelMarks what about WSL2? doesn't it solve this problem? if not, what are the downsides?
Merging the massive amount of (not so sleek) changes that are required to support Windows into redis is not really an option. First it is a lot of work (we have other priorities), but more importantly it would cause the redis code to be very much bloated, and slow down or cause complications or overheads for any future change we wanna introduce. Redis is designed for POSIX, and one of the key guidelines is clean and maintainable code. We do merge small adjustments that are needed for some OSes, but for windows these adjustments are not small at all.
Comment From: SamuelMarks
@oranagra Good to see you communicating with @tporadowski on the referenced issue.
Native MSVC build of Redis is expected to be far more performant than Cygwin, MSYS, or even WSL2.
If one is careful, there will just need to be a bunch of guards and at most some file splits (at worst: ${name}_windows.h, ${name}.h / common /, ${name}_posix.h; at best: ${name}_windows.h, ${name}.h).
Again, there's enough interest that the community can [probably] prepare a PR for you to merge. The question is, will you consider merging?
Comment From: oranagra
If the changes were small and clean, yes we would accept them, like we did for Solaris, FreeBSD and others.
But the problem with windows is that the changes won't be very clean or small. So merging such a PR is likely to have the following disadvantages: 1. a massive amount of lines in the code will be modified (adding macros or aliased types and so on), this will cause some pain. the blame log will be harder to follow and track down the original reason for some change. it would cause conflicts for old PRs, when backporting fixes to old releases, and for people who maintain forks of redis to upgrade to new versions. 2. a lot of portions of the code will need to be refactored and split into segments so parts of them can have their windows / posix variants, and there will be a big mass of code in redis just to support windows. this will make the code mode convoluted and harder to follow and maintain. 3. some future changes in redis will be more complicated and harder to create or maintain since we'll now be obligated to consider the windows parts and take care of them too, or avoid breaking the windows part when editing other parts and overlooking windows specific concerns. 4. we'll obviously need to test everything on windows, and even need to debug problems that are reported on windows and may be due to windows specific concerns.
Comment From: yossigo
@zkteco-home Your comment was deleted because it was referring users to your repository that: 1. Claims to be an official port of Redis to Windows, even though it is not affiliated with the Redis open source project. 2. Claims to be a port of Redis 7.0, even though this version was not yet released. 3. Provides only compiled binaries and no source code or insight into what these binaries contain.
You were already asked in the past to avoid this, but you are ignoring our requests and forcing us to take more decisive actions. If you feel there's a misunderstanding here or wish to discuss this further, please reach us at redis@redis.io. Thank you!
Comment From: yossigo
Closing for inactivity.