2 files changed, 119 insertions, 0 deletions
diff --git a/xpa/notes/osx.note b/xpa/notes/osx.note
new file mode 100644
index 0000000..6ba68a7
--- /dev/null
+++ b/xpa/notes/osx.note
@@ -0,0 +1,38 @@
+Mac OS X Leopard v10.5 (MB427Z/A)
+
+The process has forked and you cannot use this CoreFoundation
+
+http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html
+
+CoreFoundation and fork() Due to the behavior of fork(),
+CoreFoundation cannot be used on the child-side of fork(). If you
+fork(), you must follow that with an exec*() call of some sort, and
+you should not use CoreFoundation APIs within the child, before the
+exec*(). The applies to all higher-level APIs which use
+CoreFoundation, and since you cannot know what those higher-level APIs
+are doing, and whether they are using CoreFoundation APIs, you should
+not use any higher-level APIs either. This includes use of the
+daemon() function.
+
+Additionally, per POSIX, only async-cancel-safe functions are safe to
+use on the child side of fork(), so even use of lower-level
+libSystem/BSD/UNIX APIs should be kept to a minimum, and ideally to
+only async-cancel-safe functions.
+
+This has always been true, and there have been notes made of this on
+various Cocoa developer mailling lists in the past. But CoreFoundation
+is taking some stronger measures now to "enforce" this limitation, so
+we thought it would be worthwhile to add a release note to call this
+out as well. A message is written to stderr when something uses API
+which is definitely known not to be safe in CoreFoundation after
+fork(). If file descriptor 2 has been closed, however, you will get no
+message or notice, which is too bad. We tried to make processes
+terminate in a very recognizable way, and did for a while and that was
+very handy, but backwards binary compatibility prevented us from doing
+so.
+
+--------------
+
+This is the function you set a debug breakpoint on if you try to fork() in Leopard then call a CoreFoundation method:
+
+void __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__(void);
diff --git a/xpa/notes/winport.note b/xpa/notes/winport.note
new file mode 100644
index 0000000..fb7b46d
--- /dev/null
+++ b/xpa/notes/winport.note
@@ -0,0 +1,81 @@
+Documentation:
+
+The URL:
+
+    http://msdn.microsoft.com/library 
+
+has a good Unix Application Migration Guide as well as Win32 API. 
+
+				MINGW32
+Problems:
+
+client.c:
+
+The select() function does not work on stdio files, so xpaset cannot add
+stdio to select(). This means that "cat foo.fits | xpaset ds9" is not
+implemented. This is a client side problem and would not affect ds9 running
+as an xpa server.
+
+xpaio.c and others:
+
+Win32 does not support most Unix signal handling, and in particular, the
+SIGALRM signal. This means that XPA will hang indefinitely on a system
+call, i.e., there is no timeout support corresponding to XPA_LONG_TIMEOUT
+and XPA_SHORT_TIMEOUT. This affects both clients and servers.
+
+timedconn.c:
+
+Again, lack of support for SIGALRM means alrmconnect() is not implemented.
+For some reason, noblkconect() also did not work properly, so I had to
+use theregular connect() in client.c and hang until further notice. This
+is a client side problem and would not affect ds9 as an xpa server.
+
+launch.c:
+
+Without fork(), its not obvious how to make the code wait for the
+child to start. In the end, I used simply called win32 spawnvp(), put
+a short sleep into the parent, and hoped for the best.
+
+find.c:
+
+Couldn't find the access mode bits (S_IRUSR, S_IWUSR, S_IXUSR) in win32,
+so access checking in find() is not supported.
+
+Code Changes:
+
+xpa.c, client.c (sockets)
+
+Ironically, wsock64 has an FD_SETSIZE of 64 and I had to redefine this to
+8192 to make XPA sockets work.
+
+For wsock32 sockets, we must initialize wsock32 using:
+
+     WSADATA wsaData;
+     ...
+     if( WSAStartup(MAKEWORD(2,0), &wsaData) ) != 0 ) {handle error};
+
+and clean up at the time of exit:
+
+    WSACleanup();
+
+The close(sock) call is replaced by closesocket(sock).
+
+The call:
+
+    fcntl(sock, F_SETFD, FD_CLOEXEC);
+
+is not needed or implemented (since sockets do not survive across exec) and
+must be commented out.
+
+Calls to:
+
+    flags = fcntl(client->datafd, F_GETFL);
+    fcntl(client->datafd, F_SETFL, flags|NONBIO);
+
+get changed to:
+
+    int flags=1;
+    ioctlsocket(socket, FIONBIO, (u_long FAR *)&flags);
+
+
+