Node.js libeio In MSVC++
Alan Gutierrez
to happen sooner or later, so I am starting the process, in a way that I
hope will outlive my interest in the topic.
I've created a MSVC++ build environment for libeio, as Step 1, Sub Step
a, of a Windows port of Node.js.
http://github.com/bigeasy/node/tree/windows
My understanding is that if you completely port libeio and libev to
Windows, the rest is mostly downhill.
I also understand that Windows doesn't have the same asynchronous I/O
capacities as UNIXen, that porting is a challenge, some of the async
will be faked, performance will suffer, etc.
I created a MSVC++ build in a windows sub-directory of the libeio
directory. This MSVC++ compiles eio.c, but does not link. It is merely
to inventory the methods missing from Windows required by libeio.
http://github.com/bigeasy/node/blob/windows/deps/libeio/windows/missing.h
The MSVC++ build is in Visual Studio.
1) Install Visual Studio C++ 2008 Express.
2) Install pthreads win32 (download headers and dll to a directory
somewhere).
3) Open project.
4) Adjust pthreads include directory.
5) Press F7.
You will see only linker errors. You will have a Microsoft C++
development environment for libeio. You can start hacking.
Note that, I made only three line changes to eio.c itself, to code
within the _WIN32 ifdef branch, in the hopes that this Windows port will
someday be contained entirely in the windows sub-directory and not alter
libeio in any way, so that merges of upstream libeio changes don't break
the UNIX build any more than they would otherwise.
I created a wiki page that I'll be updating with the relevant knowledge
that is actually useful in the port.
http://github.com/ry/node/wiki/Windows-Port-%28MSVC%29
Feedback is welcome. Telling me exactly what to do in order to implement
async I/O on Windows is more than welcome.
--
Alan Gutierrez - al...@blogometer.com - http://twitter.com/bigeasy
Bert Belder
I´m not sure myself. I played with node and VS2010-ultimate for a
while but ran into just a little too much trouble. Compiling under
cygwin however is pretty straightforward, and if we manage to mod out
all posix dependency it should compile into a mingw binary just as
easy.
On the other hand, rumours are that msvc generates better executables.
/ Bert
On 18 aug, 16:38, Alan Gutierrez <a...@blogometer.com> wrote:
> I'm starting out on a port of Node.js to native Windows, which has got
> to happen sooner or later, so I am starting the process, in a way that I
> hope will outlive my interest in the topic.
>
> I've created a MSVC++ build environment for libeio, as Step 1, Sub Step
> a, of a Windows port of Node.js.
>
> http://github.com/bigeasy/node/tree/windows
>
> My understanding is that if you completely port libeio and libev to
> Windows, the rest is mostly downhill.
>
> I also understand that Windows doesn't have the same asynchronous I/O
> capacities as UNIXen, that porting is a challenge, some of the async
> will be faked, performance will suffer, etc.
>
> I created a MSVC++ build in a windows sub-directory of the libeio
> directory. This MSVC++ compiles eio.c, but does not link. It is merely
> to inventory the methods missing from Windows required by libeio.
>
> The MSVC++ build is in Visual Studio.
>
> 1) Install Visual Studio C++ 2008 Express.
> 2) Install pthreads win32 (download headers and dll to a directory
> somewhere).
> 3) Open project.
> 4) Adjust pthreads include directory.
> 5) Press F7.
>
> You will see only linker errors. You will have a Microsoft C++
> development environment for libeio. You can start hacking.
>
> Note that, I made only three line changes to eio.c itself, to code
> within the _WIN32 ifdef branch, in the hopes that this Windows port will
> someday be contained entirely in the windows sub-directory and not alter
> libeio in any way, so that merges of upstream libeio changes don't break
> the UNIX build any more than they would otherwise.
>
> I created a wiki page that I'll be updating with the relevant knowledge
> that is actually useful in the port.
>
> http://github.com/ry/node/wiki/Windows-Port-%28MSVC%29
>
> Feedback is welcome. Telling me exactly what to do in order to implement
> async I/O on Windows is more than welcome.
>
> --
Elijah Insua
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Alan Gutierrez
> On Wed, Aug 18, 2010 at 12:54 PM, Bert Belder <bertb...@gmail.com
> <mailto:bertb...@gmail.com>> wrote:
>>> Alan Gutierrez wrote:
>>> I've created a MSVC++ build environment for libeio, as Step 1, Sub Step a
>> Do you think msvc is better than mingw-targeted gcc, for any reason?
>> I�m not sure myself. I played with node and VS2010-ultimate for a
>> while but ran into just a little too much trouble. Compiling under
>> cygwin however is pretty straightforward, and if we manage to mod out
>> all posix dependency it should compile into a mingw binary just as
easy.
>> On the other hand, rumours are that msvc generates better executables.
The strategy for the port is to first port libeio, then port libev, then
port the rest of it, assuming that challenges will be in descending
order this way.
Once libeio and libev are ported, we're in V8 land, which already builds
under MSVC++.
libeio is the most complicated and it is still under 2,000 lines of C
code. 2,000 lines of C is not a lot of C, really. The collection of
missing methods are the file system and network methods you'd expect to
be missing.
So, taking one deps at a time, with a VisualStudio project for each dep,
is going to be easier than doing a full build of all of Node.js, then
weeding through blocking things out. I have a clear inventory of what is
missing and therefore needs to be written.
Most importantly, we'll have the compromises made, the async fakery, in
a single file, within the project, well documented, so we can read that
file and understand the compromises we made to get Node.js running on
Windows.
libeio already provides a nice interface / abstraction layer. We need to
pull the best hacks out of other UNIX to Windows ports into our libeio
port and then we can have something familiar to native Windows developers.
> I think if we are working building support for windows, a visual studio
> project is the best way to go. Lower barrier for windows developers,
> and vs is the best debugging tool I've ever used.
Yes.
I reformatted this message to show the virtues of bottom posting.
Dean Landolt
Elijah Insua wrote:
On Wed, Aug 18, 2010 at 12:54 PM, Bert Belder <bertb...@gmail.com <mailto:bertb...@gmail.com>> wrote:
>>> Alan Gutierrez wrote:
I've created a MSVC++ build environment for libeio, as Step 1, Sub Step a
>> Do you think msvc is better than mingw-targeted gcc, for any reason?The strategy for the port is to first port libeio, then port libev, then port the rest of it, assuming that challenges will be in descending order this way.
>> I´m not sure myself. I played with node and VS2010-ultimate for a
>> while but ran into just a little too much trouble. Compiling under
>> cygwin however is pretty straightforward, and if we manage to mod out
>> all posix dependency it should compile into a mingw binary just as easy.
>> On the other hand, rumours are that msvc generates better executables.
Once libeio and libev are ported, we're in V8 land, which already builds under MSVC++.
libeio is the most complicated and it is still under 2,000 lines of C code. 2,000 lines of C is not a lot of C, really. The collection of missing methods are the file system and network methods you'd expect to be missing.
So, taking one deps at a time, with a VisualStudio project for each dep, is going to be easier than doing a full build of all of Node.js, then weeding through blocking things out. I have a clear inventory of what is missing and therefore needs to be written.
Most importantly, we'll have the compromises made, the async fakery, in a single file, within the project, well documented, so we can read that file and understand the compromises we made to get Node.js running on Windows.
Alan Gutierrez
Tell me more of this .NET of which you speak. It has been years since I
looked at Windows. Is .NET just sitting there ready to go? I recall
having to explicitly install it.
http://msdn.microsoft.com/en-us/library/system.io.stream.beginread%28v=VS.71%29.aspx
It seemed that, for File I/O from C I'd use something like:
http://msdn.microsoft.com/en-us/library/aa365748%28v=VS.85%29.aspx
Dean Landolt
Dean Landolt wrote:Tell me more of this .NET of which you speak. It has been years since I looked at Windows. Is .NET just sitting there ready to go? I recall having to explicitly install it.
On Wed, Aug 18, 2010 at 3:10 PM, Alan Gutierrez <al...@blogometer.com <mailto:al...@blogometer.com>> wrote:
Most importantly, we'll have the compromises made, the async fakery,
in a single file, within the project, well documented, so we can
read that file and understand the compromises we made to get Node.js
running on Windows.
.NET has async i/o -- is that also accomplished through sys-level fakery?
Alan Gutierrez
>
>
> On Wed, Aug 18, 2010 at 3:32 PM, Alan Gutierrez <al...@blogometer.com
> <mailto:al...@blogometer.com>> wrote:
>
> Dean Landolt wrote:
>
>
>
> On Wed, Aug 18, 2010 at 3:10 PM, Alan Gutierrez
> <al...@blogometer.com <mailto:al...@blogometer.com>
>
> Most importantly, we'll have the compromises made, the async
> fakery,
> in a single file, within the project, well documented, so we can
> read that file and understand the compromises we made to get
> Node.js
> running on Windows.
>
>
> .NET has async i/o -- is that also accomplished through
> sys-level fakery?
>
>
> Tell me more of this .NET of which you speak. It has been years
> since I looked at Windows. Is .NET just sitting there ready to go? I
> recall having to explicitly install it.
>
>
> You do have to install it, at least you did on XP, but by now I bet it's
> wiggled its way onto pretty much every windows box (and ironically, all
> gnome boxes by default -- thanks Novell)...
>
> Still, I wasn't suggesting node/windows depend on .NET, just that the
> implementation may offer some guidance. But hell, if you're a purist
> you're probably not all that interested in node/windows in the first
> place. So if a .NET dependency is more expedient and/or efficient it's
> probably worth considering.
It appears as though it is just a thin wrapper around C API calls anyway.
Alan Gutierrez
> I'm starting out on a port of Node.js to native Windows, which has got
> to happen sooner or later, so I am starting the process, in a way that I
> hope will outlive my interest in the topic.
>
> I've created a MSVC++ build environment for libeio, as Step 1, Sub Step
> a, of a Windows port of Node.js.
>
>
> The MSVC++ build is in Visual Studio.
>
> 1) Install Visual Studio C++ 2008 Express.
> 2) Install pthreads win32 (download headers and dll to a directory
> somewhere).
> 3) Open project.
> 4) Adjust pthreads include directory.
> 5) Press F7.
The setup is even simpler now. All paths are relative. Just place
pthreads in a directory next to the node directory. Setup instructions
are now found in the windows sub-directory README.
http://github.com/bigeasy/node/tree/windows/deps/libeio/windows/
Colin Teal
--
Olly
difficulty will be interfacing with V8 and implementing the event
driven structure, as from what i remember .NET relies heavily on
threads for async operations. V8 compiles natively in MSVC if i
remember correctly (unlike cygwin (and mingw?)).
Any further thoughts? Otherwise great job Alan.
On Aug 18, 10:00 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> Alan Gutierrez wrote:
> > I'm starting out on a port of Node.js to native Windows, which has got
> > to happen sooner or later, so I am starting the process, in a way that I
> > hope will outlive my interest in the topic.
>
> > I've created a MSVC++ build environment for libeio, as Step 1, Sub Step
> > a, of a Windows port of Node.js.
>
> > The MSVC++ build is in Visual Studio.
>
> > 1) Install Visual Studio C++ 2008 Express.
> > 2) Install pthreads win32 (download headers and dll to a directory
> > somewhere).
> > 3) Open project.
> > 4) Adjust pthreads include directory.
> > 5) Press F7.
>
> The setup is even simpler now. All paths are relative. Just place
> pthreads in a directory next to the node directory. Setup instructions
> are now found in the windows sub-directory README.
>
> http://github.com/bigeasy/node/tree/windows/deps/libeio/windows/
>
> --
Alan Gutierrez
I prefer the Windows C API. I suspect that .NET is just a wrapper over
the C API at the I/O level. If it does have faked async, then I am sure
we're better off with our own implementation of faked async, informed by
Cygwin, because we can see what is going on. It is going to be very
important to Node.js, so I'd rather it wasn't behind another abstraction
layer.
It appears as though libeio is already faking async for operations that
are synchronous, such as mkdir.
If it the case that eio.c has universal fakery implemented, the first
step might be to create a low performance, all fakery native build of
libeio on Windows and then implement using native Windows APIs where
they exist, on files and sockets.
The next steps for me are to build eio.c on Linux and step through the
demo.c file, see how it works, and then attempt to port any one
operation in libeio, most likely mkdir, since I assume that is a faked
async operation, and should be very simple to implement in Windows.
--
Alan Gutierrez - al...@blogometer.com - http://twitter.com/bigeasy
*** Bottom posting is a good thing. ***
r...@tinyclouds.org
That sounds good - if by "faking" you mean doing the operation in the
thread pool.
Note there is eio has nothing to do with socket i/o. That's done non-blocking.
It would be good to get these change accepted upstream as well.
Alan Gutierrez
> On Wed, Aug 18, 2010 at 3:35 PM, Alan Gutierrez <al...@blogometer.com> wrote:
>> Olly wrote:
>>> On Aug 18, 10:00 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> If it the case that eio.c has universal fakery implemented, the first step
>> might be to create a low performance, all fakery native build of libeio on
>> Windows and then implement using native Windows APIs where they exist, on
>> files and sockets.
>
> That sounds good - if by "faking" you mean doing the operation in the
> thread pool.
>
> Note there is eio has nothing to do with socket i/o. That's done non-blocking.
I don't understand. I was under the impression that libeio provided the
async I/O operations for Node.js. It does everything but sockets? That
is, it does process piping and file I/O and network I/O is a different
beast?
r...@tinyclouds.org
It does all the non-pipe non-socket I/O. It only deals with file system stuff.
FuzzYspo0N
stuff here on windows? I can see alot of the stuff really easily
handled in boost, obviously its another dep (that can be stripped
right down to as little as needed) but its a dep none the less.
On Aug 19, 3:24 am, r...@tinyclouds.org wrote:
> > r...@tinyclouds.org wrote:
>
r...@tinyclouds.org
> What would be the downside of using boost to do all the lower level
> stuff here on windows? I can see alot of the stuff really easily
> handled in boost, obviously its another dep (that can be stripped
> right down to as little as needed) but its a dep none the less.
Downside? Three months of refactoring to crane lift node 10 stories
onto a C++ nightmare. If we're talking about crane lifting - the only
library I would consider is libevent2