OK.

I think issue525 is the right issue to document and announce this; this issue
(with its previous title) seems to be rather resolved to me.

We still need to document how to run Fast Downward with MSVC under Windows and 
announce that this is now possible. I changed the title to reflect this.

What exactly is pending with this issue? I am not aware of what changes came in
with this issue and what still needs to be documented/announced at all.

Also we now plan to support MSVC, so setting up a documentation on how to use
Fast Downward under Windows at this moment seems to be unnecessary.

Assigning this to Silvan since he is also in charge of setting up the windows 
buildslave in issue480.

Thanks to both of you! However, I'm reopening this, since the documentation
changes and the mail to the Fast Downward group are still pending.

I think the only page that needs update is
http://www.fast-downward.org/ObtainingAndRunningFastDownward.

The changes have been merged.

Dear Prof. Helmert,
The issue should be ready for your review.
I hope you agree with my changes.

https://bitbucket.org/TheOneRing/hg.fast-downward.org/pull-
request/1/issue449/diff

I think you don't gain much by using cygwin.
Also if we need to support both it would be needed to change all 
OPERATING_SYSTEM == CYGWIN tests to 
OPERATING_SYSTEM == CYGWIN || OPERATING_SYSTEM == WIN.
But I'm fine with both solutions.

I would prefer to keep Cygwin support for now because some people have been
using it. We could ask on the mailing list about general interest for support of
various Windows environments. Would this make sense?

Add native Windows support.
Extended the make files to not link to rt on Windows, by detecting Msys as 
DOWNWARD_OS=win32.

Don't cast a pointer to unsigned long in src/search/landmarks/exploration, as 
long is always 32bit on Windows, an alternative to size_t would be uintptr_t.

Added an implementation for  double Timer::current_clock();

It is not possible to retrieve the peak memory on Windows but only the 
currently used memory. There would be the possibility to at least always return 
the maximum of the retrieved current memory usage.

One major issue is now, do we want to drop cygwin support completely, or add a 
separate OPERATING_SYSTEM because some of the extensions probably wont work in 
cygwin.