Question to WIN32 experts

[Michel]

By Googling I am unable to find the answer to the following.

If you use CreateProcess will the child process be able to use MsgWaitForMultipleObjects
on standard input (as it could if standard input were a console)?

Or does the parent process have to supply file handles to the child process which
were created in overlapped mode?

Michel

[trojanfoe]

WaitForMultipleObjects() won't work on anonymous pipes (it returns 'signalled' when in fact a ReadFile on the pipe will block) but it works fine for console input, which is confusing. I don't think you mean MsgWaitForMultpleObjects() which is oriented towards Windows GUI programs with a 'Message Loop' (if you do then appologies, but I think the same applies).

I ended up creating an input thread under Windows which sits in ReadFile 99.9% of its life and passes input to the main thread using a simple synchronised I/O queue.

See this post on my blog: http://chimpchess.blogspot.com/2008/11/ ... pipes.html.

Cheers,
Andy

[Michel]

Thank you for the reply.

don't think you mean MsgWaitForMultpleObjects() which is oriented towards Windows GUI programs with a 'Message Loop' (if you do then appologies, but I think the same applies).

As I understand it MsgWaitForMultpleObjects() allows you to wait for both GUI events
(e.g. console input) and kernel events (like data available on an asynchronously opened file handle). I have seen programs using it that way.

But anyway you seem to confirm what I feared. To emulate the select call in WIN32 you need to use threads. This is what the Cygwin implementation does I think.

[trojanfoe]

As I understand it MsgWaitForMultpleObjects() allows you to wait for both GUI events
(e.g. console input) and kernel events (like data available on an asynchronously opened file handle). I have seen programs using it that way.

Console input is not a GUI event (a console application and GUI application are different Window program classes). The MsgWaitForMultipleObjects() is like WaitForMultipleObjects() but allow you to be notified of WM_xxx and QS_xxx messages - if we are talking about a console application you wouldn't be interested in these and you will have no 'Window' (the Console in Windows is a device with it's own set of API functions and is not considered a Window).

But anyway you seem to confirm what I feared. To emulate the select call in WIN32 you need to use threads. This is what the Cygwin implementation does I think.

I don't know what Microsoft were thinking - WaitForMultipleObjects() is a fantastically powerful API, well beyond the capabilities of UNIX/Linux select() or poll() except of course they had to add several exceptions to what works and what doesn't in order to make life harder.

Good luck with your coding.

Cheers,
Andy

[Michel]

Console input is not a GUI event (a console application and GUI application are different Window program classes). The MsgWaitForMultipleObjects() is like WaitForMultipleObjects() but allow you to be notified of WM_xxx and QS_xxx messages - if we are talking about a console application you wouldn't be interested in these and you will have no 'Window' (the Console in Windows is a device with it's own set of API functions and is not considered a Window).

Ok thanks! Seems I had misunderstood some things.

I am a Linux guy but I recently discovered how easy it is to develop Windows applications on Linux without ever booting to Windows.

Code: Select all

apt-get install mingw32

Since then I have become more interested in understanding the WIN32 api. So far I find it a big mess!

Recent versions of Ubuntu will start windows applications transparently without the user ever knowing that Wine is behind it.

[trojanfoe]

My engine is primarily developed under Windows x64, however I also want to run it under Linux and so it flips between the two. I am now long past the stage where this matters, as I have abstracted the O/S specific elements behind class definitions and it's just a generic application that knows nothing about the O/S. This is obviously easier to do with a console application than with a GUI application, where a toolkit would have to be used.

Are you developing a chess engine yourself?

Cheers,
Andy

[Michel]

Are you developing a chess engine yourself?

Maybe sometime....For the moment I don't have time to do the coding, and more importantly all the testing involved in weighing different ideas. I wonder how some people here on this list manage to do this. They must be much more efficient than I.

No I have been cleaning the source of PG a bit, abstracting the _WIN32 and Linux differences.

One thing that bothers me is that the _WIN32 port uses polling. This takes more CPU time than it should since PG has to wake up periodically. So I have been thinking or rewriting it using asynchronous IO. It means I will need a separate thread to handle stdin.

It will be a nice excercise using WIN32 threads.

[Michel]

BTW. I read on your blog that your engine first supported PG books but that you have
now switched to some other (homegrown?) format.

Any reason for doing so?

Regards,
Michel

[trojanfoe]

I use my own position hash and I didn't want to have two sets of hashes - one for PolyGlot compliant and one for mine. My format is very similar but stores less data and uses my own hashes.

Cheers,
Andy

[Michel]

I use my own position hash and I didn't want to have two sets of hashes - one for PolyGlot compliant and one for mine. My format is very similar but stores less data and uses my own hashes.

Well you would have to create your own books and they would only be usable in your own engine.... There are many PG books around and there are good tools for creating them.

Computing the PG hash is only a few lines of C code. See e.g. here at the bottom
of this page for "pg_key.c" which is released in the public domain

http://alpha.uhasselt.be/Research/Algeb ... ormat.html

As to your format storing less data. I assume you are referring to the 32 bit reserved for learning information in PG books. This is indeed a waste, but there is nothing one can do about it now. But is only 4 bytes out of 20.