1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
- Implement setenv / unsetenv
- Implement other stuff missing in node.cc/process
Like getuid, getgid, setgid, kill etc.
- Implement missing `net` methods
A pressing issue is: how do we work with windows api functions that are not utf8 aware?
E.g. getaddrinfo() is ansi-only; GetAddrInfoW is utf16-only. Can we get utf16 straight out of v8?
Are unix sockets similar to windows named pipes? If so, should they be supported? -> currently: no. Complication: they block.
- Child processes
Should not be too hard using CreatePipe, CreateProcessW and GetExitCodeProcess.
When customFds are specified, should we support hooking up to a socket fd?
How can we distinguish between the exit code and exception number after calling GetExitCodeProcess?
- Stdio (make TTY's / repl / readline work)
This will be hard: there is no ANSI escape code support in windows.
Select() doesn't work on TTYs -- use a dedicated `getchar()` thread
that relays everything to an internal socket?
Also verify writeError and isStdoutBlocking correctness.
- Think about exposing the platform through the process object
It sucks but it may be necessary to know which platfom you're running on, e.g.
you can't do spawn('grep') on windows (unless there's msys).
Something like process.os or process.platform?
- 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.
- Check error number mappings.
Winsock errnos are sometimes different.
- 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 MING32 build fixes upstream
- Work with the V8 team to get the stack corruption bug fixed
- 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.
- 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
|
