I pushed the new updated master config file to the master. 

The remaining updates of the Windows buildbot are linked to the cmake
integration and hence to issue67.

I think there is no separate issue, we could either reuse issue449 or make a new
one, but since there has been code merged for issue449, we should probably
create a new one.

Ok I could try that.
Is there an issue for msvc support?
I would guess we intend to support msvc2013 and later.
2013 is the first with real  c++11 support and 2015 is still a preview.

I think the main reason for creating a VS project file manually would be to move
forward with this issue without waiting for issue67. We could still switch
everything to cmake once we have a cmake setup.

it would be possible but I personally don't like project which use makefiles
makefiles/autotools and provide a visual studio project file.
Keep in mind you have to maintain both and I have seen to many projects where 
that didn't work.
And tool like cmake give you the possibility to have one setup with clean 
scripts which generate you your makefiles or ide project files.

We now have a running Windows computer in our office. We had quick discussion
yesterday and wondered whether we really need to have a cmake buildsystem or if
we cannot "simply" use the Visual Studio project management system to have a
Fast Downward project which can be compiled in Visual Studio (and hopefully also
from command line with the help of the project file). Patrick, do you think it
would be possible to setup a Visual Studio project with which we can compile
Fast Downward?

I have also started working on a cmake file for issue67; maybe we should try to
merge the two? Mine is not up to date right now (last worked on it in Oktober)
but we could reuse some if its ideas. For example, it deals with modules better
than the current makefile. Lets discuss this in issue67 or better yet, in person.

So without the gcc code it should be quite easy to port it to visual stuido 20
2013 or later.
The biggest stopper is the build system.
I have a working but hack cmake buildsystem for the core parts. Should I try to 
make it comnpile in visual studio?

Okay.

> And I still think all the efforts we undertake should be somewhat worth it,
> i.e. there should really be several people that would then use Fast Downward
> with Windows.

I think there is a good number of such people (not sure how many exactly, but
more than "several" ;-)). I have a regular influx of emails from people who
would like something like this (usually not from the planning community). It's
more on the "user" side than "researcher" side, although some of these users are
also researchers in other areas, where Windows is more commonly used, and who
would like to use the planner as a tool for their research.

(Regarding the admin side of things, let's discuss things further offline. Can
you remind me after the Easter holidays?)

Well, the first time I asked Philipp if he could setup a Windows machine, he
said something along the lines that they have more important things to do than
that (or he "hatte keinen Bock"). 

Regarding using Visual Studio, that would be the "real" Windows solution of
course, and if that was possible, it would be a nice thing. And I still think
all the efforts we undertake should be somewhat worth it, i.e. there should
really be several people that would then use Fast Downward with Windows.

Thanks for all your efforts so far!

Answering the last point first: we've had some forgettable experiences, but
there are also more appreciative people who have expressed interest in running
Fast Downward on Windows. For example, I think Robert Goldman was interested in
this at some point, and perhaps also Minh Do.

Regarding technical issues related to setting up the computer, please get in
touch with the admins. It shouldn't be us working on this. If there are hardware
issues, we should get rid of the machine -- IIRC, we have 1-2 spare ones anyway.
The network issues you mention are odd -- the buildslave shouldn't reconfigure
anything; it's a regular "user" of the internet that doesn't need to do anything
fancy. I wonder if the machine isn't registered properly in the department's DNS
setup. I remember faintly that two of our machines had the same name shown on
the stickers attached to them, which is a warning sign.

Regarding setting things up on the software side, I wonder if Patrick could work
on this as part of his hiwi job? It's nice to have the planner working with
msys, but now that we got rid of most/all gcc-isms, I wonder how difficult it
would be to make it work with Visual Studio.

Unfortunately, while compiling Fast Downward with MSYS is possible (thanks
Patrick for the help), I was unable to get a well-working Windows machine in our
office. Even after reinstalling Windows another time, internet is only working
sporadically and there are problems either with the graphics card or the
monitor, causing the latter to lose signal from time to time, which can be
"fixed" by un- and replugging it.

Also when I had the internet working for a while, running a buildslave instance
(not at all configured to work with FD yet, but a builslave instance after all),
it troubled the DNS settings so that I could not get back online when it was
running.

As my willingness to spend time into debugging Windows is somewhat limited, I
wanted to ask if anyone else feels that he might has the expertise to fix the
machine (or the setup in general), and if we really want to have official
Windows support for Fast Downward. I remember Malte having said that people,
even though they can compile Fast Downward on Windows, still complained that
"there exists no planner running on Windows".

We decided to try to get a Windows buildbot on our own machines. Patrick, could
you provide me with information how to setup Downward on Windows, both with
Cygwin and Mingw (also via email if you like)?

I'd be fine with either solution as long as we can connect it to our existing
build server. The task of maintaining the OS installation would be up to our
admins, and once you can get the source to compile, setting up a build slave is
generally very little work.

Sound like a good idea, but I don't think you need to outsource it.

I'd rather outsource this to a hosted build service like www.appveyor.com to 
avoid having to maintain Windows installations. I tried setting up automated 
builds there briefly, but don't know enough about the toolchain. Maybe Patrick 
and I can have a look at this together and polish the Windows installation 
instructions on the way.

We have unused machines that could be used for this. Providing a Windows license
is hopefully not a problem, but we should check with the admins. So the main
todo item here would be setting up the build slave.

In issue478 we saw again that we cannot preserve Windows compatibility if we 
don't test building on Windows. Therefore, we should discuss if we want to setup  
automated testing for Windows.