From b280a2d44d8826418e0231af6a7a13f1d91b6a5f Mon Sep 17 00:00:00 2001
From: Ryan Dahl <ry@tinyclouds.org>
Date: Tue, 11 Oct 2011 10:08:47 -0700
Subject: [PATCH] Remove ANOTHER old TODO list

---
 TODO.win32 | 88 ------------------------------------------------------
 1 file changed, 88 deletions(-)
 delete mode 100644 TODO.win32

diff --git a/TODO.win32 b/TODO.win32
deleted file mode 100644
index e8c9d98fe39..00000000000
--- a/TODO.win32
+++ /dev/null
@@ -1,88 +0,0 @@
-- Implement setenv / unsetenv
-
-- Implement other stuff missing in node.cc/process
-  Like getuid, getgid, setgid, kill etc.
-
-- Better `net` support
-  * getaddrinfo
-  * setMulticastTTL, setMembership, setLoopback
-  * pipe, socketpair
-  * A named pipe should be provided when a unix socket is requested.
-  * SendMsg and RecvMsg should be supported with named pipes.
-
-- New libev backend
-  The current libev backend supports sockets only. This complicates stuff like
-  child processes, stdio. Best would be if node_net switched from exposing
-  readyness notifications to using completion notifications, so on windows we
-  could use IOCP for sockets. Experts tell me that is really the fastest way
-  to work with sockets on windows.
-
-- Child process issues
-  * Communication between parent and child is slow; it uses a socketpair
-    where a pipe would be much faster. Replace it by a pipe when there
-    is a libev backend that supports waiting for a pipe.
-  * When a child process spawns the pid is not available straightaway.
-    On linux the pid is available immediately because fork() doesn't
-    block; on windows a libeio thread is used to call CreateProcess.
-    So this can't really be fixed, but it could be worked around by adding a
-    'spawn' or 'pid' event.
-  * passing socket custom_fds is not supported
-  * child_process.exec() only works on systems with msys installed.
-    It's because it relies on the 'sh' shell. The default windows shell
-    is 'cmd' and it works a little differently. Maybe add an option to
-    specify the shell to exec()?
-
-- Make colorful util.inspect work on windows.
-
-- Stdio: support passing sockets between master/child process
-  Normal windows applications wouldn't like this, but it can be useful for
-  communication between node processes. This requires 
-  stdio.isStdinBlocking/isStdoutBlocking to be smarter.
-
-- Skip/fix tests that can never pass on windows
-
-- Find a solution for fs.symlink / fs.lstat / fs.chown
-  Windows has different symlink types: file symlinks (vista+),
-  directory symlinks (vista+), junction points (xp+) 
-
-- Handle _open_osfhandle failures
-  E.g. currently we're using the construct _open_osfhandle(socket/open/accept(...)).
-  Now socket() can fail by itself and _open_osfhandle can fail by itself too.
-  If socket() fails it returns -1 so _open_osfhandle fails as well, but and we'll always return/throw EBADF.
-  If _open_osfhandle fails but socket doesn't, a stray handle is left open. It should be fixed.
-
-- Think about `make install`
-
-- Extensions
-  Should be DLLs on windows.
-
-- Link pthreads-w32 statically by default
-
-- Link Mingw libraries statically by default
-  Like libstdc++.dll, more maybe.
-  Microsoft libs are always there, no static linkage required (e.g. msvcrt, winsock2).
-
-- Make (open?)SSL work
-
-- Support using shared libs (libeio, v8, c-ares)
-  Need to link with with a stub library. Libraries should use `dllexport`,
-  headers must have `dllimport`.
-
-- V8: push MINGW32 build fixes upstream
-
-- Work around missing pread/pwrite more elegantly
-  Currently it's exported from libeio, while it wasn't intended to be exported.
-  The libeio workaround implementation sucks, it uses a global mutex.
-  It should be possible to implement pread and pwrite using winapi's ReadFile/Writefile
-  directly, passing an OVERLAPPED structure while not associating with an completion port.
-
-- Work around missing inet_pton/inet_ntop more elegantly
-  Currently it's exported from from c-ares, while it wasn't intended to be exported.
-  It prevents linking c-ares dynamically. 
-
-- See what libev/libeio changes can be pushed upstream
-
-- 64-bit build
-  Should be possible with MinGW-w64, it's pretty good.
-
-- ... much more probably
\ No newline at end of file