Updated ...md (markdown)

...md.md

@@ -12,16 +12,31 @@ As stated earlier, the main goal is side by side Windows support in the portable
 
 Guidelines
 -----------
-To prevent any regressions in main and to enable easier review of the changes coming from win32-fork, there will be no "main" code moving or refactoring. There are multiple places where platform abstraction makes sense (auth, console to name a few), but this wont be addressed in the fork as it would lead to significant code churn. This will be done post integration once we have stable Windows supported version with significant test coverage living in main repo. Crypto support using Windows [CNG](https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx) has been tested out in fork but will be undone as it needed reasonable changes to "main" code. This means that the Windows supported version potentially available mid this year will rely on OpenSSL's crypto (exception is SSP for key-based authentication that will use CNG - more details later).
+To prevent any regressions in main and to enable easier review of the changes coming from win32-fork, there will be no "main" code moving or refactoring. There are multiple places where platform abstraction makes sense (auth, console to name a few), but this wont be addressed in the fork as it would lead to significant code churn. This will be done post integration once we have stable Windows supported version with significant test coverage living in main repo. Crypto support using Windows [CNG](https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx) has been tested out in fork but will its changes will be reverted\undone as it needed reasonable modifications to "main" code. This means that the Windows supported version potentially available mid this year will rely on OpenSSL's crypto (exception is SSP for key-based authentication that will use CNG - more details later).
 
 Design details
 -------------
 ### Transport Layer - POSIX IO
 This layer of protocol implementation in OpenSSH consists of mainly IO, parsing and crypto code. The aim it keep this layer mostly common between Windows and Unix by implementing a POSIX IO wrapper on top of Win32 async File IO (parsing is common for both, crypto will remain common for this milestone). This wrapper strictly implements the POSIX IO needs of OpenSSH keeping the code differences in transport layer to a minimum. Note that the wrapper implements only the calls needed by OpenSSH (and not all defined in POSIX standard). Specifically, the wrapper implements
 + IO calls creating file descriptors - open, creat, socket, accept, socketpair, pipe
-+ operations on a single file descriptor - fd_set, FD_* macros, read, write, recv, send, fstat, fdopen, close
++ operations on a single file descriptor - fd_set, FD_* macros, read, write, recv, send, fstat, fdopen, close, dup and dup2
 + operations on multiple file descriptors - select
 + signal semantics on these operations - ex. select (or any blocking IO call) returning EINTR
++ SIGABRT, SIGTERM, SIGCHLD, SIGINT, SIGPIPE and SIGALRM
+
+Brief design details of POSIX wrapper
++ Single threaded (not thread safe based on current needs but can be made so if needed going forward). 
++ Maintains file descriptor table and its state. Table stores mapping between file descriptors (int) and associated Windows IO state (handle, buffers, async call state, etc). 
++ Calls underlying Win32 APIs that provide [Overlapped](https://en.wikipedia.org/wiki/Overlapped_I/O) semantics. 
++ "select" and blocking IO calls go through a common "wait_for_any" function that wakes up on
+  - IO completions
+  - Signals
+  - Timers
++ All underlying Win32 IO API calls are made asynchronous (non-blocking). Blocking semantics are implemented within the wrapper by an explicit wait for IO to complete.
++ Uses [APCs](https://msdn.microsoft.com/en-us/library/windows/desktop/ms681951(v=vs.85).aspx) wherever available and minimzing use of [events](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682655(v=vs.85).aspx). This simplifies code and has performance benefits.
++ Maintains internal buffers to accommodate an underlying fundamental difference between POSIX and Win32 IO APIs - IOReady Vs IOComplete (Ex for a Read operation, POSIX APIs signal when IO is ready - date will be subsequently, explicitly read, Win32 APIs signal when IO has completed - data is already copied to a user provided buffer.
+ 
+