2 files changed, 0 insertions, 119 deletions
diff --git a/xpa/notes/osx.note b/xpa/notes/osx.note
deleted file mode 100644
index 6ba68a7..0000000
--- a/xpa/notes/osx.note
+++ /dev/null
@@ -1,38 +0,0 @@
-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
deleted file mode 100644
index fb7b46d..0000000
--- a/xpa/notes/winport.note
+++ /dev/null
@@ -1,81 +0,0 @@
-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);
-
-
-