conversation about libeio and win32 compatibility with the man himself

schmorp's dungeon

<tmpvar> hello
 <schmorp> hi
 <tmpvar> hey, have you heard of any success with getting libeio built/running on windows?
 <schmorp> no
 <schmorp> it's not supposed to work, really
 <schmorp> (windows doesn't support 99% or so of the required api)
 <tmpvar> hrm
 <tmpvar> yeah, good ol' windows.
 * _ry ([email protected]) has joined #schmorp
 <_ry> schmorp: what's wrong with libeio on windows?
 <schmorp> wrong?
 <schmorp> wlel, i guess, it works fine with e.g. cygwin
 <_ry>  <schmorp> (windows doesn't support 99% or so of the required api)
 <schmorp> (there actually is workaround code for bugs in cygwin)
 <schmorp> i assumed he meant native win32
 <_ry> yeah i want to use it with mingw
 <_ry> (i know very little about windows)
 <schmorp> then it's true
 <_ry> it seems libeio doesn't do anything that's very magical
 <_ry> except draining the queues at fork
 <schmorp> well, except call dozens of functions thta don'T exist under windows
 <schmorp> windows' doesn't even have the concept of a read or write to handle function
 <schmorp> i have no clue how much mingw hacks around behind the scenes, of course
 <_ry> you mean read(2), write(2) ? really?
 <tmpvar> mingw doesnt really do much, its more of an effort to port unix binaries to run on windows
 <schmorp> _ry: well, which one?
 <_ry> eiher, both?
 <_ry> i'm just not sure what you mean. that some of the eio wrappers doesn't exist on windows? 
 <schmorp> windows doesn't even have a read() function
 <schmorp> well, none exist on windows
 <_ry> wow.. how is that possible?
 <schmorp> some are probably provided by wingw
 <schmorp> mingw
 <schmorp> but they will unliekly be working with threadds _and_ all sorts of file descriptors
 <schmorp> windows itself doesn't have a generic I/O model
 <schmorp> i.e. there isno equivalent to read()
 <schmorp> WriteFile only really works on files, etc. etc.
 <tmpvar> there is a read() on windows, but its for fd's only.  socket() returns a SOCKET which is not an fd, although you can convert it to one using some low level api call
 <schmorp> tmpvar: no, there is no reaD() on windows
 <schmorp> tmpvar: you probably mean the libc of your compiler
 <schmorp> which is different for each compiler...
 <schmorp> cygwin has, of course, a read()
 <tmpvar> sure, we'll be using libc via msys w/ gcc
 <schmorp> so the quetsion is on what kind of "files" read and wirte even works
 <schmorp> under posix, they work on everything
 <schmorp> and if even read and write are missing
 <schmorp> then sttavfs/unlink etc. are missing, too
 <schmorp> windows, again, doesn't even have the very concept of unlinking files
 <schmorp> and then you need pthreads
 <schmorp> (but there is a workable pthreads library available)
 <_ry> http://msdn.microsoft.com/en-us/library/1c3tczd6(v=VS.80).aspx
 <schmorp> yes, but that doesn't unlink
 <schmorp> it just tries to delete the file
 <schmorp> besides, that one is called _unlink, not unlink...
 <schmorp> and it's also not part of windows
 <schmorp> as is clearly documented on that page
 <_ry> i don't know. seems like getting some rudimentary support on windows is possible
 <schmorp> sure
 <tmpvar> http://msdn.microsoft.com/en-us/library/aa298551(v=VS.60).aspx -- _read
 <schmorp> tmpvar: please do me the courtesy of not wasting my time, ok?
 <schmorp> tmpvar: read the page you gave yourself
 <schmorp> tmpvar: it clearly documents this as not aprt of windows
 <_ry> schmorp: :)
 <_ry> schmorp: does ev_async work on windows?
 <schmorp> grrr
 <schmorp> in theory
 <schmorp> the problem is that it relies on nonstandard extensions
 <schmorp> so in practise, it doesn'T work
 <schmorp> because read/write etc. doesn'T work on sockets
 <schmorp> (they work on pipes...)
 <_ry> ev_async only uses a pipe, right?
 <schmorp> cannot on windows
 <schmorp> windows doesn't even have the concept of unix-style pipes
 <_ry> so i odn't know how mingw works - but i imagine it has glibc?
 <schmorp> wow
 <schmorp> of course not
 <_ry> okay
 <_ry> i'm optimisic though - even if we have to #ifdef in a new ev_async
 <schmorp> ev_async doesn'T even exist in libeio
 <schmorp> i think you swithed topics
 <_ry> yeah but i use both
 <schmorp> libev works under window, with some love
 <schmorp> except that a number of people mentioned thta read/write doesn't work for them
 <schmorp> which makes sense, as windows doesn't have those
 <schmorp> so everybodies read/write comes from a different codebase that hacks around windows
 <schmorp> while it could reqaosnably be done by porting to a single such environment
 <schmorp> it's quite a diffeent thing to make ti work with all such
 <schmorp> as such, libeio is fully supported and works on windows
 <schmorp> as long as you use cygwin
 <tmpvar> thanks for your help
 <schmorp> good luck