Skip to content

Lack of native Windows support #238

MS-Interop opened this Issue Dec 6, 2011 · 10 comments

9 participants


We have received a growing number of requests for Redis to run on Windows, even more so as we announced Windows support for Node.js.

We love the idea of running Redis natively on the Windows platform, and this is why in past few weeks a team in Microsoft spent some time to make Redis to run natively on Windows using LibUV (high performance I/O abstraction library developed by the node.js community that allows high-throughput and high-concurrency scenarios in both Windows and *nix).

By leveraging dmajkic’s work ( we created a patch that, once applied on top of Redis 2.4 provides a way to compile an executable for Windows (and Linux).
The patch (with instructions) is available at


This is awesome, but there is zero reason to use Patchfiles here, just submit a Pull Request. Ping me at if you need help

benatkin commented Dec 8, 2011

@xpaulbettsx they probably mainly want feedback from the project maintainers at this stage, and the project maintainers can apply a patch just about as easily as they could apply a pull request. (It's so big that the web view isn't likely to be useful.) Also this will probably be going into a new branch if anywhere, so does a pull request to an existing branch (which is all that's possible AFAIK) even make sense?

spicyj commented Dec 8, 2011

For convenience in reviewing, etc., I split this into a patch for libuv: spicyj/libuv@e0894e5 and a patch for Redis: spicyj/redis@809c231.

antirez commented Dec 8, 2011

Cool to see work in that direction. I decided to avoid merging it, for the same reason I was not actively seeking a win32 port in the past: it is a lot of work and more complexity for the main Redis project, and it is not clear how this will benefit the Redis community given that most people are interested in running Redis under POSIX environments, and especially Linux, and even systems developed using Microsoft technologies can easily access a Redis server running under Linux.

However people need to run Redis under win32 at least for testing / development, and they already do it with the current port. If there will be a better win32 port, it will be welcomed, and I'll be happy to stay in touch with the developers to collaborate. Not just that, I'll be very happy to create a win32 page in our web site and link to an official "Redis win32" project, that has a different repository, a different page for issues, and is not directly supported by me (and the "main" Redis project).

My opinion is that the development of the win32 port should be focused on handling the persistence better. Also I think it could be simpler to port ae.c to win32 adding an ae_win32.c backend since libuv is a complex piece of code and you are currently using only a subset of it, and more importantly, Redis is not using the libev API currently. But as this would be a separated project it is your choice, this is just my 2 cents.

In general since I'm not merging the code it will be wise to create a code layout that will make merging from the "posix Redis" as simple as possible.

Thanks for your contribution, Salvatore.


@benatkin Pull Requests are actually a great way to do this - the maintainer doesn't have to merge it, you get general comments as well as line-based comments, and it gives the submitter a chance to add more commits to fix issues in the original PR. If you're Doing GitHub Right™, you should actually open the PR before you've even written a single line of code!

benatkin commented Dec 9, 2011

@xpaulbettsx good point...pull requests are cheap. But since you mentioned Doing GitHub Right™ why on earth is your username so long and difficult to remember? You work for GitHub, and pbetts is available. BTW I know the guy who got paul. :)

german commented Dec 9, 2011

"Not just that, I'll be very happy to create a win32 page in our web site and link to an official "Redis win32" project, that has a different repository, a different page for issues, and is not directly supported by me"



Today we released a new version of our prototype.

The implementation is now based on a fork that we will be using for our prototypes moving forward.
The new code can be found at

The new version has some improvements to the ‘save on disk’ process but we are not happy yet so we will release a new prototype soon with a better solution (more details on the README)

Suggestions and comments are welcome.


One more token,,, for a native windows

Any chance to get a unique branch and use gyp in order to get the Visual Solution.

I will be happy to work on this task, porting code from Linux/Windows and back port the work done by the MS-Interop team.

For the following reasons:
1. Grow the community of redis by having a native version of Windows
2. In a near future offer in azure a redis solution like mongo-db (currently offered)
3. No code difference between Linux/Windows and better maintenance with git hub

My 2 cents

tj commented Feb 2, 2014

gyp is also pretty brutal IMO, I love that redis compiles cleanly without anything like that

@mattsta mattsta closed this May 30, 2014
@JackieXie168 JackieXie168 pushed a commit that referenced this issue Sep 16, 2014
@timmaxw timmaxw Removed the threadsafe_cond_t from get_result_t; using the data_provi…
…der_t's destructor as the signal instead. Closes #238.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.