4.5.4
=====
- NANT: Ignore the compiler warnings for the winrt and winprt platforms.
- Tool-side: Sometimes the GameTalkServer install can potentially not complete in the time it takes for the InstallServer method to return - so added a second connect attempt in the case that the Connect fails and we did in fact install the server.

4.5.3
=====
- NANT: removed mention of the mobile platform from Gametalk.build.

4.5.2
=====
- Runtime: allow users to override the target name + provide new platform names in their gametalkuserinclude.h

4.5.1
=====
- Tool-side: The .NET assemblies didn't get generated properly in 4.5.0 - fixed.
- NANT: minor updates to NANT script - one to accommodate mobile another to accommodate a compiler warning (specifically -wd4371).
- Tool-side: fix UnregisterMessageHandler - had a couple of problems - wasn't graceful if the message handler hadn't been registered and more importantly wasn't thread-safe.  Thanks to Steven Scherrelies for the fix.
- Runtime: increase reliability of connections and reconnections.  Especially in regards to UTFSockets - prevent random disconnects when traffic volume grows very large.  Thanks to Regis Locas.

4.5.0
=====
- Tool-side: updated all GameTalk assemblies to .NET 4.5
- Tool-side: Named Pipes - for those who dislike the GameTalkServer communicating with the GameTalkMonitor using logs on the file-system - you can now switch this logging implementation to "named pipes".

4.3.1
=====
- Tool-side: missed the 4.2.4 update (in 4.3.0) that disables the USB plugin by default.

4.3.0
=====
- Runtime: GameTalkInstance: better handling (more reliable/robust) of GameTalkProtocols that take longer to initiate a connection.  Since we use non-blocking sockets - establishing a connection can take a non-trivial amount of time - so we simply defer the sending of our initialization information to the GameTalkServer until that connection is established (i.e. not necessarily at the moment the GameTalkInstance is constructed).
- Runtime: IGameTalkProtocol: take ownership of the memory associated with the IP address that is handed to the GameTalkProtocol being used.
- Runtime: UTFSockets: A few years ago the "auto-reconnect" feature was added to GameTalk (was tested and working on DirtySock, WinSock, etc) - this allows users to shut-down and start-up the GameTalkServer (example when the GameTalkServer is upgraded) and the game/runtime should then auto-reconnect.  The UTFSockets GameTalkProtocol needed some work to get it to this point - tested on Xenon, PS3 and Windows (32 and 64 bit).

4.2.4
=====
- Tool-side: GameTalk.dll: disabled USB plugin by default.  It can be enabled by one of the GameTalkInstance constructor overloads.

4.2.3
=====
- Tool-side: GameTalk.dll: gracefully fail if the application is unable to load the interop.iwshruntimelibrary at runtime

4.2.2
=====
- Tool-side: GameTalkWin32 (tool-side C++ project): Fixed the GameTalkWin32 project so that it includes the new dll (IWshRuntimeLibrary.dll).
- Tool-side: GameTalk.dll: If users register multiple handlers on the same channel name - only tell the server if there are no other handlers still registered on that channel - fixed.
- Tool-side: GameTalkServer: when user initially enters an IP address and port number that coincides with the running GameTalkServer (on the user's local PC) then switches it (after seeing the conflict) - the GameTalkServer needs to be restarted to "see that change" - fixed.

4.2.1
=====
- Runtime: Endian determination: removed a bunch of platform logic that resides in EA Platform - specifically determination of endian now relies on the user defining a value for the config define USER_GAMETALK_IS_LITTLE_ENDIAN or they need to include EABase (which defines EA_SYSTEM_BIG_ENDIAN or EA_SYSTEM_LITTLE_ENDIAN).
- Runtime: remove reference to ppc intrinsic on OS X - since there are flavors of OS X that are intel based and others that aren't.
- Runtime: DirtySock: Previously we were ignoring a compiler warning on PS3 concerning multi-char - now just added macro to perform int creation from multi-char's in platform agnostic fashion.
- Tool-side: GameTalkServer and GameTalk: switching the GameTalkServer to 32 bit was introducing some issues - namely passive connections weren't working because the Server was looking at the wrong place in the registry (thank you very much MS virtualization/redirection of RegistryKey locations).
- Runtime: DirtySock: fix a compiler warning about multi-char.
- Tool-side: FileTalkInstaller: added a manifest so that Windows doesn't generate this stupid error dialog "this program may not have installed correctly".
- Runtime: GameTalkMessages: Synchronous Messaging: We had a non 64 bit friendly bit of code in there - fixed by Daniel Sewell

4.2.0
=====
- Tool-side: GameTalkServer: Thanks to Hitesh Shah - iOS devices can send GameTalkMessages over USB!
- Tool-side: GameTalkServer: Addition of a plugin infrastructure - such that users can drop their IGameTalkService and Listeners into the plugins folder and the GameTalkServer will load them at runtime.
- Tool-side: GameTalkServer and GameTalkMonitor: updated so that the GameTalkMonitor should display any start-up issues the GameTalkServer experiences.
- Tool-side: GameTalkMonitor and GameTalkServer: allow users to switch GameTalkServer between 64 and 32 bit process.  At present the only reason the user would want the GameTalkServer to be 32 bit is to be able to use the new USB functionality added by Hitesh Shah.
- Runtime: fix up null delimiters to use the appropriate null char (instead of NULL - since in later versions of C++ - NULL provides pointer type safety - instead of just resolving to 0).
- Runtime: remove reference to ppc intrinsic on OS X - since there are flavors of OS X that are intel based and others that aren't.

4.1.0
=====
- Tool-side: GameTalkServer: Added Listener abstraction.

4.0.0
=====
- Upgraded GameTalk to .NET Framework 4.0.  Skipped a few versions of GameTalk just so we line up with the .NET version we've upgraded it to.
- Tool-side: GameTalkMonitor: when the user double clicks on the GameTalkMonitor in the system tray - bring the window to the front.  In previous versions of GameTalk if the user has already maximized the GameTalkMonitor form/window, then they put an application in front of it - double clicking on the GameTalkMonitor in the system tray would not bring the form/window to the front of all other applications on top it.

3.5.0
=====
- Upgraded GameTalk to .NET Framework 3.5.  Skipped a few versions of GameTalk just so we line up with the .NET version we've upgraded it to.

3.1.0
=====
- Runtime: Win32: updated the USER_GAMETALK_ASSERT that were being passed a hard-coded false to use USER_GAMETALK_FAIL.  
- Runtime: Win32: Since the win32 and xenon GameTalkProtocols differed only in a few statements - thus the functionality for both has been aggregated into the single Win32 GameTalkProtocol - it was a pain keeping both sets of code up to date (in sync with fixes/updates).
- Runtime: Win32: Ensured that the sockets were always set to non-blocking
- Runtime: updated GameTalkManager::CreateInstance to expose the receive string buffer size argument/parameter
- Tool-side: further work to reduce requirement for GameTalk to be run as administrator: updated the logging directory from c:\program files\gametalkserver to <CommonApplicationData>\GameTalkServer\
- Tool-side: GameTalkMonitor/GameTalkViewer: put a short-cut to the GameTalkMonitor executable in the user's start-up folder so the user doesn't have to run a GameTalk application to get the GameTalkMonitor to start
- Tool-side: GameTalkMonitor/GameTalkViewer: fixed a bug that makes the GameTalkMessages look a little strange in the GameTalkMonitor (a couple of the columns weren't getting populated).
- Pipeline: Joshua English fixed the GameTalkConfig application so that it only uses a PC's IP v4 address - since currently the GameTalkServer doesn't support IP V6.

3.0.2
=====
- Fixed/suppressed various warnings
- Move body of GameTalk.h into a new GameTalkBase.h header, for backwards compatibility with
  GameTalk 2.x.   External packages build against GameTalk-2.x expect to include "GameTalk.h",
  not the multiple headers which GameTalk 3.x exposes.   This remodelled also addressed some
  circular-dependency issues in the header files.   These changes are compatible with both
  the GameTalk-3.00.00 include patterns and the GameTalk-2.x include patterns.

3.0.1
=====
- GameTalkServer: By default the GameTalkServer will not shutdown if the PC (it is running on) loses its network connection.
- Scripts: Added EATech's code stripper python script to the scripts directory.
- Runtime: fix a PC/windows only memory stomp.


3.0.0
=====
- Added new serialization layer to GameTalkMessage - users can now add and get arrays of native types (floats, ints, etc).
- Runtime: Changed indexing in GameTalkMessage from size_t to int (to make it consistent with tool-side) - users should be aware this will likely require them to update the code that uses GameTalk.
- NANT: remove EA_DEBUG = 1 from UTFSockets config section (from GameTalk.build).
- Runtime: Fixed propagation of reconnect parameter to GameTalkManager to GameTalkInstance.
- GameTalkServer: bound server to IpAddress.Any so that users can connect to localhost or 127.0.0.1.
- GameTalkServer: prevent reregisteration of registered targets on the same channel.
- GameTalkServer: made the connection initiator more fair - previously it gave more attention (and had greater latencies) to recipients that get many messages.
- GameTalkMonitor: provide same copy-paste feature in misc/comment panel as already exists in the messages panel.
- ChunkBlocks: User can now append arbitrarily sized blobs of data onto GameTalkMessages - methods GameTalkMessage::AddChunkData and GameTalkMessage::GetChunkData.
- GameTalkMessage: the GameTalkServer will now append the the sender onto a GameTalkMessage - this is exposed through Sender property (tool-side) or GetSender() method (runtime side).
- FileTalk: users can set file root of a target that isn't connected. That file root will remain even after the client disconnects.
- GameTalkServer: Better handling of a non intialized connection disconnecting.
- Runtime: UTFSockets: In certain optimized builds - the initial send (of initialization information) could fail (because the connection has not yet been established).
- Runtime: GameTalkInstance: We should handle the situation of not being able to send the initialization information to the GameTalkServer better now.
- Runtime: The size of the receiving string buffer handed to a particular GameTalkInstance is now configurable either at a global level (by the user defining GAMETALK_RECEIVE_STRING_BUFFER_SIZE) or by simply providing the size explicitly to the GameTalkInstance they are instantiating.
- GameTalkServer: The server was crashing with the message "Cannot write to a closed TextWriter" - could be a result of unsafe logging code - should be fixed.
- Runtime: Removed assert from GetContentWithKey(const char*) and made the return value from GameTalkInstance::RegisterMessageHandler return true if there was room for the callback in the local list AND if it was successfully sent to the GameTalkServer.
- Runtime: Added the ability to register multiple synchronous message handlers on different channels.
- Runtime: UTFSockets: Removed dependency on eaassert.
- Runtime: Fixed some 64 bit compiler issues.
- GameTalkServer: Prior to 2.9.0 we had a feature to notify the user when they were sending messages to a registered target that was on the local pc and using the same port as the GameTalkServer - this was accidentally disabled in 2.9.0 - re-enabled/fixed.
- GameTalkServer/GameTalkMonitor: The IP address and port number of the GameTalkServer are displayed in the status-bar of the GameTalkMonitor.  Also, if the port number of the GameTalkServer is anything other than 9876 the background color of the GameTalkMonitor will be altered.
- GameTalkServer/GameTalkMonitor: abstracted the configuration layer (targets, whether the GameTalkServer should parse messages, etc) so that we can more easily change where that information is read/written.
- Tool-side/GameTalkServer: Added a new method to the tool-side GameTalkInstance.RegisterTarget - so that users can send a message to the GameTalkServer and update the list of registered targets.  Currently there is no way to remove targets - but if the target already exists it should be possible to use to the same method to overwrite/update an existing target.
- Tool-side: updated .NET usage from 2 to 3.5.
- Tool-side: Added a GameTalkInstance constructor overload that allows users to request that the GameTalkServer and the GameTalkMonitor not be installed/started locally.
- NANT: added Bob Summerwill's updates to accomodate building custom GameTalkProtocols (not distributed with the GameTalk package).
- Runtime: Win32 + Xenon GameTalkProtocols: Added timed out to list of acceptable conditions in GameTalkProtocol::Connect function.
- Runtime: updated a couple of things for building GameTalk for iPhone.
- C++ Tool-side (NOT using GameTalkProtocol): fixed a 64 bit compliance issue, getting the number of bytes from GameTalkManager::SendMessage + handling the meta-data portion of the key/content pairs correctly.
- Tool-side: Client-side: When used in single-threaded mode: Franklin Cho provided a bug fix related to parsing messages off the wire.
- runtime: integrated EAM's changes: better mobile support + fixed a couple of compiler warnings/errors.
- Tool-side: applied bug fixes (courtesy of EAM) to GameTalkMessage's type-safe serialization layer.
- Runtime: Update to GameTalk.build to allow bulk build.
- Tool-side: allow users to start GameTalkServer and FileTalkServer as application (instead of as a service).

2.9.1
=====
- Tool-side: Update GameTalkMonitor to not depend on Microsoft.DevKits.Xenon - instead directly depends on XDevkit.dll and then switched the project to AnyCPU instead of x86 (this should make it a 64 bit application on 64 bit machines and thus access the same area of registry as GameTalkServer on Vista).
- Tool-side: If the user deleted a target from the target manager and then readds it - it could mess up connections with that target - fixed.
- Tool-side: GameTalk + GameTalkServer: If the server or client is 64 bit we now redundantly write to the Wow6432Node registry location (so 32 bit GameTalk app's know GameTalk is installed, its version and the port the server is using).
- Runtime: UTFSockets GameTalkProtocol: minor update to get rid of compiler warnings.

2.9.0
=====
- Tool-side: GameTalkMonitor + GameTalkServer: The GameTalkMonitor will now start processes if the GameTalkServer logs the necessary "process start" data.  It requires that both the client/target sending the request to start an application and the GameTalkMonitor to use the same password.
- Tool-side: We had a limitation previously - if a user sent multiple successive messages (very quickly) to an unconnected registered target the first message would always get through - but one or two subsequent messages could be dropped - fixed.  This required a major reworking of the connection and message sending code of the GameTalkServer.  We still have an awkward lag if there has been a lot of messages being sent quickly.  This is due to the fact that the component of the GameTalkServer that initiates the connection is on a low priority thread and often gets far behind the messages being sent.  Also because initiating a connection can take a few seconds.
- Tool-side: GameTalkServer: added DateTime stamp to comments.
- Runtime: Made the runtime handle GameTalkMessages with NULL content (in a key/content pair) better.
- Runtime: DirtySock: removed namespace semi-colon.

2.8.2
=====
- Tool-side: GameTalkMonitor: TargetManager: Previously user could press update when no target was loaded into the various text fields (most importantly the target name field) - fixed.
- Tool-side: GameTalkServer: made logger more thread-safe.
- Tool-side: GameTalk Installer: we'll only use the current tool's GameTalkMonitor if the GameTalkMonitor isn't running or if the GameTalkServer was installed.  Previously you could end up having an older GameTalkMonitor being run with a more up to date GameTalkServer - it is still possible - just far less likely (with this change).

2.8.1
=====
- Runtime: Removed a fair chunk of code from the UTFSockets GameTalkProtocol (tested on the wii/NDev - which was the platform this code had to be added for).  This should speed up performance.
- Tool-side: GameTalkMonitor: clearing the comments when they hit 500 - since the memory becomes onerous.
- Runtime: Useless assert in KeyContentBuffer constructor - fixed.
- Tool-side: added the "CLSCompliant" attribute to the assembly.cs - to flag that we're not using any of the less cross-language-compatible types in the public API.
- Runtime: screwed up a null delimiter of a string in SendSynchronousMessage - fixed.
- Runtime: Reset incoming buffer index to zero upon disconnnection (in the various GameTalkProtocols).

2.8.0
=====
- Runtime: updated the DirtySock, WinSock and UTFSockets GameTalkProtocols to allow "graceful reconnection" - so if they lose their connection with the GameTalkServer they will immediately reestablish the connection when the GameTalkServer is available again (for both active and passive mode).  Of course in passive mode another message will have to be sent to the game/runtime in order for the connection to be reestablished.  The update to the UTFSocket GameTalkProtocol relies on the existence of a new function Socket::IsConnected - which doesn't actually exist in the UTFSockets package yet.  If a different name is chosen for this function - the code in the GameTalkProtocol will have to be changed to accomodate that.
- Runtime: Allow the name of the connected target to be updated at runtime using the GameTalkInstance::UpdateTargetName member function.
- Tool-side: GameTalkMonitor: Copy/paste in the GameTalkMonitor!  Now users can send messages they see in the GameTalkMonitor to other users.
- Tool-side: GameTalkMonitor: Clear the existing listing of GameTalkMessages.
- Tool-side: GameTalkMonitor: The GameTalkMonitor now logs the sender of messages + the channel the message was sent on (in their own columns).
- Tool-side: GameTalkMonitor: Select which channels you don't want to appear in the GameTalkMonitor "Message Logs" section.
- Tool-side: GameTalkServer: Using the new GameTalkInstance::StartSendingMessageToRegisteredTargets and GameTalkInstance::StopSendingMessageToRegisteredTargets - users can have the GameTalkServer send a particular message repetitively to a specified target.  This background messaging will automatically be shut-off as soon as the requesting client disconnects.
- Tool-side: GameTalkMonitor: TargetManager: Allow user to update existing entries.
- Tool-side: GameTalkMonitor: TargetManager: If there is already an entry that corresponds to your default xenon's ip-address and port number, it will not be readded by TargetManager.
- Tool-side: GameTalkMonitor: The FileTalkServer can be stopped and started in the same way the GameTalkServer can be (through the GameTalkMonitor globe in the system tray).

2.7.6
=====
- Runtime: updated DirtySock GameTalkProtocol to handle when there is no connection.
- Tool-side: updated all projects (except the GameTalkMonitor) to be AnyCPU - so that 64 bit applications can use 64 bit versions of GameTalk.  Only the GameTalkMonitor needs to be set to x86 because of its dependency on the xenon dll.
- Tool-side: GameTalkServer will now log a message if a message is sent to a target and that target isn't registered on the necessary channel.
- Tool-side: GameTalkServer: There hasn't been much testing of how the GameTalkServer handles targets with the same name.  But, there likely was an issue with registering server-side channels for targets with the same name.  Now all connected targets with the same name should have the same set of registered server side channels.
- Tool-side: GameTalkServer: In 2.6.8 a fix was added to address the TCP buffer filling.  However, there remained an edge case that could still cause the TCP buffer to fill and for the GameTalkServer not to shut down that connection (thus freeing the resources that connection had claimed).
- Runtime: updated all GameTalkProtocols to check that there is sufficient room in the incoming buffer for data off the wire.  This was causing misleading asserts and issues to arise.

2.7.5
=====
- Updated all managed projects to use x86 in release - it was an oversight that this wasn't applied to both debug and release.
- Runtime: Removed const qualifier from value (non pointer) return types.

2.7.4
=====
- Tool-side: Got rid of first chance exception that would occur when users shut-down GameTalk.  Note: This exception is only visible to users who have a debugger attached to their application.
- Runtime: updated the RealComm (6 and 7) GameTalkProtocols with the API updates made to IGameTalkProtocol many versions ago.
- Runtime: GameTalkInstance wasn't deregistering the synchronous gametalk handler - fixed.
- Runtime: the binary alignment code was broken - fixed.
- GameTalkMonitor: Gave users the option to set the logging to never.  One user noticed that GameTalkMonitor is reading from files a lot using process monitor.  A future improvement to reduce file I/O even further would be to use FileSystemWatcher to let the GameTalkMonitor know if there were any changes since the last read (since even just checking the file's size is logged by process monitor).

2.7.3
=====
- Runtime: Got rid of a bunch of compiler warnings.
- Tool-side: Beefed up testing.
- GameTalkServer: After 25 megs of logging had been written the GameTalkMonitor would stop reading the logs - fixed.
- The FileTalkServer would sometimes acquire over a thousand windows handles - have inserted some cautionary code to reduce the liklihood of this.
- Added a new method to the tool-side that lets the user request the list of currently connected targets GameTalkInstance.GetAllConnectedTargets().

2.7.2
=====
- All updates done in 2.6.8 (see below) were applied to 2.7.2.
- Urgent bug fix to the GameTalkServer - previously with high volumes of data/messages (messages being frequently sent) - the GameTalkServer could fail badly (this was a result of a bug that was introduced in 2.7.0) - fixed.

2.7.1
=====
- GameTalkMonitor: TargetManager: users have been complaining that the TargetManager is resolving to the wrong IP address - so provided them an option to disable the "auto-resolve of IP address" feature.

2.7.0
=====
- Runtime + Tool-side: Synchronized messages!  Added a visio of the API for Synchronous messages.
- NANT: Update to GameTalk.build for revolution and ps3 support - thanks to Daniel Bekins.
- Runtime: bunch of compiler warnings for various platforms - fixed.
- Package: Most of the testbed examples/samples have been moved into their own package.
- FileTalkServer: increased performance by between three to four times (and also increased consistency).  A 120 meg file can be transferred to the PC in under 15 seconds.
- Runtime: Data alignment - Since 2.5.6 GameTalk was switched to perform zero memory allocations for incoming messages.  This had the unfortunate side-effect of creating data type misalignment for binary data sent to the runtime - we now default to sixteen byte memory alignment (configurable) through padding.
- Tool-side: Updated the client-side code so that clients of GameTalk can recurse on the processing thread code from within their callback (GameTalkInstance.Poll).
- GameTalkServer: vastly simplified the network layer code in the GameTalkServer - very similar to the update to the tool-side client network code update.
- Tool-side: Got rid of some extraneous error messages that can sometimes appear in the GameTalkMonitor.
- GameTalkServer: improved the performance of multi-directional messaging - the user can recognize even greater gains by shutting off messaging in the GameTalkMonitor.
- Runtime: fixed some more compiler warnings - small changes to API - switching uint32_t to size_t in a couple of instances.
- Runtime: added static GameTalkProtocol::InitNetwork and GameTalkProtocol::ShutdownNetwork functions for users that want to use GameTalk to initialize their network layer.
- GameTalkServer: If there is an error when trying to send data to a particular connection - we will log the GameTalkMessage that failed to be sent.  A certain type of error can result in us killing that connection.
- GameTalkServer: minor update to the GameTalkMessage.ToString() - this slightly changes the appearance of GameTalkMessages in the GameTalkMonitor - [(key 1) (content 1)] [(key 2) (content 2)] etc.
- GameTalkServer: new addition to target matching semantics - if user prefixes the target they are sending to with "@." - this message will ONLY be sent to the target(s) with that precise name.
- Tool-side: Client code: users can now request that GameTalk operate in single-threaded mode when instantiating GameTalkInstance.
- GameTalkServer: Easier for users to create their own custom GameTalkRouters.
- FileTalk: Both tool-side and runtime client code: added the ability to index into a file and get a portion of it using the index and numBytes parameters to FileTalkManager::CreateGetFileTransaction.
- Runtime + Tool-side: the format portion of each key/content in a GameTalkMessage is 32 bits.  Currently the only two options are string and binary.  The reading and writing of this format was previously using the entire 32 bits - now we only use the least significant bit.  However, at present there is no other proposal for how to use the other 31 bits.
- Runtime: added GameTalkInstance::SendShutdown function - this will let the GameTalkServer know that the client intends to shut-down its connection.  Previously, the runtime would simply disconnect - the GameTalkServer would only realize this once it could no longer ping the client/application.

2.6.8
=====
- GameTalkServer: handle TCP buffer filling more robustly.
- tool-side: Client will properly auto-reconnect if the user sends a message after the client has already been disconnected.
- FileTalk: tool-side: client-side: GetFileTransaction: this transaction was failing if you try to get multiple fragments (because it wasn't updating the fragment index on the client-side)

2.6.7
=====
- Runtime: signed/unsigned warning fix.

2.6.6
=====
- Runtime: User can determine when the GameTalkInstance that their FileTalkManager is using doesn't send the requested transaction.
- Runtime: Added FileTalkManager::GetGameTalkInstance() accessor member to allow users to get a reference to the specific GameTalkInstance that FileTalk is using.
- Runtime: When users haven't implemented the TLS functionality - the GameTalkManager::ReleaseInstance wasn't properly resetting the sGameTalkInstance member to NULL.

2.6.5
=====
- Tool-side: GameTalkServer: fixed a bug in getting the port that the GameTalkServer should sit on.  This bug is fairly severe in that machines that have never had the GameTalkServer will end up with the GameTalkServer sitting on an arbitrary port.
- Package: slimmed down the package to exclude some files that were out of date - the largest reduction was a result of removing the sandcastle binaries.

2.6.4
=====
- Runtime: Added a work-around for a conflict that can occur with the undef of windows SendMessage macro and when users include windows.h.
- Tool-side: Made the GameTalkServer handle the situation where the user sends an empty string for the name of the target/client they are sending to - previously the GameTalkServer would get screwed up by this.
- Runtime: Changed GameTalkManager's AdoptInstance, GetAdoptedInstance and AssignGameTalkInstanceToStaticMember to static members.

2.6.3
=====
- Runtime: Made the default TLS configuration work by using a static GameTalkInstance in the GameTalkManager.
- Tool-side: GameTalkServer and GameTalk client: Increased the consistency of round-trip messages over GameTalk.  Previously round-trip messages would only take one millisecond.  However, if the user burst consecutive messages - the variance in latency was between 1 to 42 milliseconds (even for small messages).  This fix should keep the average to a millisecond or less.

2.6.2
=====
- Runtime: Updated the DirtySock GameTalkProtocol - messed up the name scoping on the GameTalkProtocol::RegisterReceiverCallback member in the GameTalkProtocol.h file - fixed.

2.6.1
=====
- Fixed some possible recursive issues that could arise in the use of the various GameTalkProtocols.  If your code's callback was invoking the Poll - the various GameTalkProtocols should handle this situation without issue.
- Runtime: Fixed IGameTalkProtocol destructor to properly free allocated memory.
- Runtime: We no longer assert if a user unloads the FileTalkManager instance (FileTalkManager::ReleaseInstance) when it still houses FileTalk transactions - we just silently delete and deregister them.
- Runtime: DirtySDK GameTalkProtocol: Increased the timeout for large sends to five seconds instead of one second - since one second was failing for my large file send test case.
- Runtime: GameTalkManager now properly uses the TLS (Thread Local Storage) macros that were created.
- Runtime: Created a VERY simple win32 sample GameTalk application.  Hoping we can one day merge the xenon and win32 GameTalkProtocols.

2.6.0
=====
- Runtime and Tool-side: Update GameTalk to be multiply instantiable.  That is, now each application can create multiple GameTalk connections (using GameTalkInstance) rather than being forced to use the GameTalkManager singleton.
- Runtime and Tool-side: Related to the aforementioned change - FileTalkManager (both in tool-side and runtime) takes a GameTalkInstance as an argument.
- Runtime: Added Thread Local Storage (TLS) macros to allow users to drop in their own version of TLS (EA Thread, Microsoft's, etc).
- tool-side: GameTalkServer can have the port it sits on changed by modifying the Port subkey of registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Electronic Arts Inc.\GameTalkServer.
- tool-side: Can now specify the port to connect to the GameTalkServer on.  The only reason the user should want to specify the port is if someone creates a custom GameTalkRouter (using the GameTalkRouter project).  This would allow their GameTalkRouter to co-exist on the same machine as GameTalkServer.
- tool-side: Added a test app for showing users how to extend GameTalkRouter - to create their own custom GameTalkRouters.
- tool-side: GameTalkServer: user found that GameTalkServer was leaking windows handles.  The server would grow to about 1000 handles and then return back to about 300-400 - fixed.

2.5.10
=====
- Runtime: changed some char * assignments to const char * assignments for picky compilers.

2.5.9
=====
- Runtime: Updated the DirtySock GameTalkProtocol - had to reorder the includes in EasyTCP.cpp and messed up the name scoping on the GameTalkProtocol::RegisterReceiverCallback member in the GameTalkProtocol.h file - fixed.

2.5.8
=====
- Runtime: member initialization ordering for picky compilers (i.e. ps3).
- NANT: update to the GameTalk.build file to ignore multi-char - not entirely sure why.

2.5.7
=====
- Runtime: Slightly altered the way Utility::Parser is being used to facilitate less static members in GameTalkManager (in preparation for GameTalkManager's subclass GameTalkInstance).
- Runtime: as mentioned in previous point - reduced number of static members in GameTalkManager.
- Tool-side: If using debug version of FileTalkServer - FileTalkServer will now clear its log file when it starts to get large.
- Tool-side: Fixed a threading issue that can arise when shutting down GameTalk on either the client-side or in the GameTalkServer.
- Tool-side: Made the GameTalk installer kill the GameTalkMonitor process if the graceful restart fails (the benefit to a graceful restart is to clear the spurious GameTalkMonitor that remains in the system tray).

2.5.6
=====
- Runtime: GameTalkManager::Poll returns an int to indicate the number of bytes received from the wire.  This required a similar update to the IGameTalkProtocol::Poll.
- Runtime: Made all GameTalkProtocols (except MacOSX and bfunc) use the new Utility parsing functionality.  Previously some of the GameTalkProtocol's wouldn't support recursing upon themselves upon receipt of messages.  The new Utility parsing functionality supports this scenario/usage-pattern.
- Runtime: Made an option in the GameTalkManager to free the GameTalkProtocol it was using when user invoked GameTalkManager::ReleaseInstance(bool).
- Runtime: Zero dynamic memory allocations for incoming messages.
- Tool-side: Made the GameTalk client actually check the version of GameTalk currently being run and reinstall the server based on that.

2.5.5
=====
- Runtime: Exposed GAMETALK_AUTO_IDLE_NETWORK_LAYER preprocessor in NANT GameTalk.build
- Tool-side: In 2.2.0 we increased the performance of both the client and server side of GameTalkServer - now that performance gain is consistent and therefore a round-trip message should always be made in less than a millisecond.

2.5.4
=====
- Runtime: ps3 optimized fix for big/little endian management (thanks to Daniel Craig, Michael Malone and Lisa Streit).
- Runtime: FileTalk: we had some code in a USER_GAMETALK_ASSERT macro (specifically in FileTalkManager::DeregisterTransaction) - which users don't always have defined and therefore could potentially not get executed - fixed.
- GameTalkMonitor fix for IP address lookup.  Move from Dns.GetHostEntry to Dns.GetHostAddresses.
- Get GameTalk to function on IPV6 - by default Vista has IPV6 installed - therefore this will fix issues that Vista machines are having.

2.5.3
=====
- GameTalkServer: Reduced cost of managing the ConnectionInitiator queue.  This change will not have an effect on users who aren't sending data at high frequency through GameTalk.
- Fixed PS3 warnings.


2.5.2
=====
- Update to the UTFSocket's GameTalkProtocol::Send - it is more robust in its handling of the local socket send buffer being full.  Previously corrupt data could actually be sent due to incomplete sends - however, this would only occur with high volumes of data being sent frequently.
- Added FileTalk::Transaction::GetTransactionID() - to facilitate debugging - can't think of any real reason the user should need the transaction ID for anything other than debugging.
- Updated the testing code for GameTalk (both tool-side and runtime side).
- Updated the GameTalkServer to once again be more aggressive in its reclaiming of memory.  In this case, GTS was getting to be very large when a large volume of data was being sent through it at high frequency.

2.5.1
=====
- Runtime: update to the UTFSockets GameTalkProtocol to remove the definition of EA_DEBUG_BREAK.
- NANT: Apparently the UTFSockets config in gametalk.build was missing a property - added it.
- Runtime: Somehow back in the 2.4.1 attempt to rid myself of compiler warnings I totally missed a ton of FileTalk ones - should be warning free now.
- Updated the packaging script to copy the scripts directory to the top-level (read: NANT/BuildManager/Framework 2.x improvements).
- Added some additional configuration settings to the initialize.xml (read: NANT/BuildManager/Framework 2.x improvements).

2.5.0
=====
- Runtime: update to the UTFSockets GameTalkProtocol so that no code that needs to be executed will be contained in the asserts - since asserts can be conditionally compiled (i.e. compiled out).
- Runtime: Added a GameTalkMessage::GetSize overload that uses the key string as the parameter (instead of the numerical index of the key).
- Tool-side: Changed all assemblies to use x86 for their build configuration target platform in the hopes of getting this working on Vista.

2.4.1
=====
- Runtime: Got rid of a bunch of compiler warnings.
- Runtime: Put in a fix for when the target name is null.

2.4.0
=====
- If a client sends a partial name to a client that is not connected, but that is registered - we will use the existing partial target name matching semantics to connect to all matching clients.
- Tool-side: made the code that shuts down the client-side work more quickly.

2.3.2
=====
- Forcing the GameTalkServer to be a bit more rigorous in its freeing of memory since it seems to be holding memory that it doesn't really need.
- Made the xenon sample app's compile and run in release mode.  There were rumours of GameTalk failing when optimization was turned on - wasn't able to reproduce it in our sample app's.
- Made GameTalkServer shut itself down gracefully if it doesn't have an internet connection.  This was previously causing problems when someone would restart their computer without an internet connection - GameTalkServer would continue to run even though it had lost its connection.  Therefore, the user would have to restart GameTalkServer to get it to start accepting connections again.
- Made the "connection cleaner" thread in GameTalkServer run quicker - so that disconnected clients are recognized by GameTalkServer more quickly (within a second instead of ten seconds).
- Fixed a couple of runtime bugs - unregistering gametalk channel being used by FileTalkManager and making the GameTalk name reassignment actually work (this feature is important since FileTalk has a dependency on it).
- Stopped the target manager (contained in GameTalkMonitor) from erroneously updating the IP address of a user's xenon if they use a name other than game.xenon.

2.3.1
=====
- Made a fix to the FileTalkServer when the user is using SendFileTransactions and overwriting existing files.

2.3.0
=====
- Runtime: the runtime no longer requires the user to specify a gametalkuserinclude.h - the default (out of box) set-up will work as long as you have eabase.
- Removed printf's from the xenon GameTalkProtocol.
- Tool-side: we now generate docs for both the FileTalk and GameTalk API (using SandCastle).
- Added Initialize.xml to GameTalk to be more NANT/BuildManager/Framework 2.0 compliant.
- Updated the GameTalk xenon sample app's test-code to make it easier to test/profile the various aspects of GameTalk/FileTalk
- Made FileTalkServer write files to the file-system in a streaming manner instead of holding all the data in memory until the entire file is received and then writing it out.  I've left non-streaming code in the FileServer in case users only want a SendFileTransaction to be written out if all data is received.
- Made the C++ tool-side resolve 127.0.0.1 and localhost to the local system's "true" hostname.
- Please visit our wiki
http://globaltechdocs.ea.com/GameTalk:TOC

Specifically there should be some good information here:
http://globaltechdocs.ea.com/GameTalk:FAQ


2.2.0
=====
- Tool-Side: Slim down the GameTalkViewer/GameTalkMonitor's memory profile - it can get pretty big (over 100 megs) when there is lots of traffic being sent at high frequency and it stays that big until it is restarted.
- Tool-Side: improved the GameTalkServer's performance by switching one of the members from an ArrayList to a List<byte []>.
- Tool-side: Client side update to make receipt of messages quicker.

2.1.0
=====
- updated the tool-side GameTalkManager to only send the platform if the user has set it - otherwise the GameTalkServer will write the "there was no data in the platform keyword message from the client" and users get worried when they see error messages.
- runtime: fix to StrIEqual (previously on certain platforms it wasn't doing a full string comparison - i.e. only comparing every other character) - also renamed the function to StrIsEqual.
- FileTalk: Runtime: The user is now guaranteed to have their transactions sent to the FileTalkServer in the order that they submit/create them.

2.0.9
=====
- FileTalk runtime update - two minor updates to remove casting warnings
- FileTalk tool-side - signed the FileTalk and FileTalkMessages projects/dlls

2.0.8
=====
- DirtySock GameTalkProtocol: added definition check for GAMETALK_AUTO_IDLE_NETWORK_LAYER.  If this is defined then we won't do the DirtySock NetConnIdle().
- Made GameTalkServer description of "message size recorded incorrectly" more descriptive.

2.0.7
=====
- Updated runtime to accomodate users creating multiple transactions followed by a single FileTalkManager::Update (ensures all transactions in pool have a unique ID).
- Updated FileTalkServer to be more thorough in its clearing of memory when a client disconnection is detected.

2.0.6
=====
- Rearranged the initialization ordering for picky compilers.
- Fixed bug when C++ runtime tries to set the file root for FileTalk - this requires updating both the tool-side (FileTalkServer) and runtime.
- Updated DirtySock GameTalkProtocol to more gracefully handle issues when trying to send data.  Specifically added timeout in case connection is lost while trying to send a message - this used to result in infinite loop, but we will now just give up after allotted (one second) timeout.
- Fixed bug in the runtime/game-side handling of allocation/deallocation of error message.  Also, FileTalkServer can now handle use case of sending multiple SendFileTransactions to the same file followed by a single FileTalkManager::Update invocation.

2.0.5
=====
- Better support for BuildManager/Framework 2.x/NANT.
- More standard auto-install behavior by the C++ tool-side since the C++ tool-side now just executes FileTalkInstaller (behind the scenes).

2.0.4
=====
- Tool-side - Updated all executable projects to be x86 to ensure platform compatibility with 64 bit machines
- Added a bit some paranoid/safety checks in GameTalkMonitor to ensure it doesn't crash if it doesn't find the data it is looking for.
- There were some latent dependencies in 2.0.3 to XBox (not 360/xenon) that have been removed - so that tool-side everything will build.

2.0.3
=====
- Now teams can build their own custom GameTalkServers with custom behavior, by using the GameTalkRouter project.
- Removed all dependency on xbox (not 360/xenon) - previously we had a dependency on xbox to help us determine the user's default xbox.
- Updated the package to include a scripts directory which contains initialize.xml - for NANT.
- The wii sample was previously 400 megs because of all of its dependent files.  This is apparently prohibitively large for people to download/use from the package server.  So now the wii sample just includes the code for the application and binaries from building it (none of the dependent libs, source files - i.e. you'll need to contact me to get the files necessary to make it buildable).

2.0.2
=====
- Small fix to EA::FileTalk::Transaction destructor to make it compatible with one of the non-Microsoft compilers.
- Updated the version number of the FileTalk assembly so that the newer version of GameTalk will get used by it when someone runs a tool that uses GameTalk 2.0.2.  In other words, if ever an important change is made to GameTalk - FileTalk should have its assembly version number increased so that the newer version of GameTalk will be used by the FileTalkServer.
- Updated the DirtySock/DirtySDK GameTalkProtocol to address a bug that would result in the "read buffer index" not getting incremented if the callback ended up calling itself (indirectly).
- Added a new method to the GameTalkManager (tool-side) named SendIsAlivePing that can be used to see if the user is still connected to the GameTalkServer.  Otherwise the IsConnected method may return true even though the GameTalkServer has been shutdown/crashed since they first made their connection.  FileTalkServer is already using this to determine the moment it loses its connection with the GameTalkServer (and will thus shut itself down gracefully when this happens).
- Fixed up the GameTalkProtcol implementations for both UTFSockets and DirtySock to get rid of any compiler warnings.
- Simplified the default behavior/logic if the user doesn't define USER_GAMETALK_INCLUDE (i.e. doesn't provide a gametalkuserinclude.h).
- Made GameTalk buildable with Framework 2 of BuildManager/NANT.

2.0.1
=====
- Made a couple of changes to UTFSockets lib such that it is more reliable - updated the wii sample app to use that updated version of the lib
- Minor update to the GameTalk Installer to hopefully improve its reliability.
- GameTalk C++ tool-side - GameTalkManager::Send returns a bool and provided a new function GameTalkManager::IsConnected.
- Added fix to C++ tool-side for buffer overflow issue noticed by Skate


2.0.0
=====
- GameTalk compiles and runs (in both Debug and Release) using .NET 2.0
- Added support for storing/recording the platform (XBox, PS2, etc) explicitly - instead of implicitly storing it in the target name
- As a result of supporting separate storage of platform - now users can have multiple clients on the same platform defined in the target manager.  The GameTalkServer will push the name of the client (stored in the target manager) to that client.
- Added support for storing/recording the version of GameTalk in use by a client.
- Updated the message content for connected and/or registered targets - basically each target returned will have a key that is the target name and key content that is the platform.  Use the const strings in the GameTalkMessage class to parse the GameTalkMessages
- Provided backward compatibility with previous target naming and the new platform specification for a target - the TargetManager will automatically parse each entry target name (that don't have a platform) and automatically populate the platform entry.  This will occur when GameTalkMonitor is initially started.
- Also, in the instance that a Game is operating as a client to the GameTalkServer - upon initialization GameTalk will automatically send the platform information to the GameTalkServer (as part of its initialization packet) - assuming the user has properly defined the OS specific macros.
- Runtime now allows user to specify target name - 90% of the reason this was added was to allow multiple clients to connect to the GameTalkServer that happen to be on the same platform.
- GameTalkMonitor was cutting off the end of messages - initial prognosis was that it was due to message length - in fact it was due to a parsing (of the GameTalkServer log files) error.
- Fixed bug that resulted in the GameTalkMonitor/GameTalkViewer to not start-up.  The problem was due to the TargetManager throwing an exception if the person has misconfigured their xbox/xenon settings.  We now handle this gracefully.  This bug was created in version 1.9.2 when we made the GameTalkMonitor dynamically reassign a new IP address when GameTalkMonitor loads.
- Fixed bug in runtime - Playstation 3 platform define has changed the naming convention (established for playstation 2) - so we have left both versions
- We now explicitly control the size of the GameTalkServer log files (which are used by the GameTalkMonitor) to ensure they do not exceed fifty megabytes in size - user can turn this on or off in GameTalkMonitor.
- GameTalkServer - now broadcasts (with target set to "*") will also get sent back to the client that sent the broadcast.
- We now only have one implementation of GameTalkProtocol for DirtySock - this version is about 30 times faster than the previous version because we previously were relying solely on their callback to inform us of newly arrived packets.
- Slight updates to messaging of previously available functionality associated with clients disconnecting and buffering of messages for a client.
- GameTalk support for Wii!  Along with sample/test app that uses GameTalk that builds and runs on NDev.
- User can now pass (void *) user data to their GameTalk message handler - so that they can do instance/object passed logic.
- Minor GameTalk and DirtySock specific runtime updates - StrIEqual is now a macro that users can provide, constructor initialization list reordering for strict compilers, carriage returns at bottom of files for ps3.
- Fixed bug: DirtySock runtime wasn't using GameTalk allocators previously - but does now.
- Server-side channel filtering - now when a client registers to listen on a channel - that will be sent to the GameTalkServer and the GameTalkServer will perform filtering for the client.  Note: to support backward compatibility - we add old GameTalk clients to all channels - since they don't know to send the GameTalkServer the channels they want to register on.
- Partial channel matching - if you register a client on channel "ToolABC" and you receive a message on channel "ToolABC.script" or "ToolABC.config" - you will get both messages.
- Level of logging and parsing that GameTalkServer does can now be configured using the GameTalkMonitor.  At low parse and file IO - performance can be improved by a factor of 10 times.
- Fixed bug in GameTalkProtcol::Send for both Win32 and Xenon.  Previously, if a user tried to send more data than would fit in the transport system - a partial message would be sent and the function would return false.  This has been corrected so that people can perform tight-loop sends with any amount of data they choose.
- GameTalkWin32 execution of GameTalkMonitor (specifically CreateProcess) no longer inherits handles from parent process.
- GameTalkServer will understands two types of recipient tokens "*" and "*!".  "*" means to just broadcast to everyone.  While, "*!" means to broadcast to everyone except the sender.
- Fixed bug in GameTalkMonitor that would result in it cutting off the end of comments that it displays.
- If you happen to be creating a client of GameTalkServer that is a service (not a stand-alone application) then a new Initialize method has been added that allows you to tell GameTalkServer - this ensures that a service doesn't try to start an application (specifically GameTalkMonitor).
- Fixed bug - this was a harmless bug that just annoyed some of our users that would debug their GameTalk client applications.  It resulted in an exception being thrown when the client would disconnect.  But the exception was being handled within GameTalk - so it would only be noticed if the user was stepping through the code with exceptions turned on.
- GameTalkServer will broadcast all connected and disconnected client(s) in the same format which includes their name, platform and version.
- Added GetPlatformFromTargetMetaData and GetVersionFromTargetMetaData to the tool-side version of GameTalkManager.
- FileTalk Service! FileTalk is essentially just another client to the GameTalkServer.  It provides file services to any clients that request them.  FileTalk works on the basis of a transactional model on both the C++/runtime side and the C#/tool-side.  Currently implemented transactional classes include FileInfoTransaction, GetFileTransaction, SendFileTransaction and FileNotificationTransaction.
- GetFileTransaction - user must provide their own custom allocator class that extends our EA::FileTalk::IHeapAccessor.  Also when user invokes GetFile function on GetFileTransaction - they will be responsible for freeing that from memory.
- FileNotificationTransaction is a slightly different animal from the other transactions - thus it warrants its own point.  FileNotificationTransaction is unique in that a single instance of it can be passed to the user's FileTalk callback multiple times.  However, each time the user gets their callback invoked with a particular instance of FileNotificationTransaction they will need to explicitly reenable it (FileTalkManager::Reenable())- so that the FileTalkServer will send the most recent file notification that it has buffered.  The buffer of notifications the FileTalkServer keeps is guaranteed to be unique - that is, at no time will there be more than one notification of a particular type (renamed, changed, etc) on the same file in the buffer.
- All transactions can be deleted directly by the user.  The Transaction destructor will notify the FileTalkManager to remove them from its listing of them.
- FileTalkServer is installed and started (if not already) by any local clients of GameTalk (in the same manner as GameTalkServer and GameTalkMonitor).  This requires tool-size/C# users to reference the FileTalk.dll and invoke the FileTalkManager.Initialize method (as per the GameTalkZ sample).
- FileTalk service will gracefully abort itself if it loses its connection with the GameTalkServer.  Thus if a user wants to shut-down/disable GameTalkServer and FileTalkServer, they can simply stop the GameTalkServer service (from within their services or by right clicking on the GameTalkMonitor).
- FileTalkServer is multi-threaded, but only on a per client basis.  That is to say, each client of FileTalkServer gets a single thread within FileTalkServer.
- Applications that use FileTalk can set the "root path" of other clients of FileTalk - i.e. a tool could set the root path for a game.
- FileTalkServer will return error code to Transactions - so users can determine if something went in the execution of their transaction.
- The debug FileTalkServer.exe will log to the same directory as GameTalk (C:\Program Files\GameTalkServer).  The release version will not create any log files.  However, both versions of FileTalkServer.exe can be passed a command-line argument and be used as a stand-alone application instead of as a service.
- FileTalk installer command-line tool (aptly named FileTalkInstaller.exe).  This tool can also be used to set the root file path for any given client of FileTalk.
- NOTE CONCERNING USE OF FILETALK - Users MUST invoke FileTalk::ReleaseInstance before GameTalkManager::ReleaseInstance, otherwise FileTalk will fail badly.  Since FileTalk's singular dependency is on GameTalk it is essential that GameTalk be properly initialized and functioning.

1.9.2
=====
- Added the ability for GameTalk to request the server version from the server running. This can help the clients find out if there is a mismatch.
- Added a Xenon\GameTalkProtocol - nearly identical to our Win32 implementation except that we need to clear xenon security (for connections to transfer non-secure data).  Also added the ability for our Xenon\GameTalkProtocol to work as a server - instead of only being able to directly connect to the GameTalkServer.
- Added a sample xenon application that uses GameTalk on top of DirtySock.  Now we have two sample xenon GameTalk app's - one that uses WinSock and the other uses DirtySock.
- Added better error checking to our GameTalkProtocol code that sits atop DirtySock
- Fixed a bug that would occur if we had a registered client app that was set up as a server.  When the GameTalkServer initiated the connection the first message sent to the registered client would be lost (this no longer occurs).  
- Fixed a bug when the GameTalkServer attempts to reconnect to a registered client that it had already successfully connected to.  
- Fixed a bug to stop the server from trying to look up a registered client with the name "*".
- Added a feature to allow C# GameTalk clients to connect to a server on a different machine than the machine they reside on - useful for remote control of clients connected to a different user's GameTalkServer.
- Fixed a bug (in both the C# and C++ Installer) that resulted in the GameTalkMonitor not being updated if the user didn't update their application's assembly version, but DID update the version of GameTalk they are using.  This was fixed by changing the install location of server and monitor to a GameTalk-version directory rather than the application's directory.  This also allows multiple applications to share the same set of GameTalk assemblies.
- Overhauled the TargetManager so that users have full freedom to specify targets.  Only current constraint is that if the user doesn't have a default xenon or xbox specified (game.xenon and game.xbox respectively) - those targets will be auto-added if they aren't specified - this is done to save the user the effort of manually specifying them.
- Added GameTalkManager.ClientVersion property to C# and GameTalkManager::ClientVersion function to C++
- Applied version fix completed in 1.9.1 in C++ Installer class - the fix done in 1.9.1 was only done in the C# Installer class.
- Added	USER_GAMETALK_STRLEN, USER_GAMETALK_STRCPY and USER_GAMETALK_TOLOWER macros so that users can define their own implementation of the standard C functions strlen, strcpy and tolower
- Fixed bug that would effectively disable GameTalkManager's UnregisterMessageHandler method
- Put the two macros RECEIVE_BUFFER_SIZE and MAX_BUFFER_SIZE into IGameTalkProtocol - so that users can take our GameTalkProtocol implementations and simply define their own numbers for those macros.  MAX_BUFFER_SIZE just dictates the largest GameTalkMessage that the game could handle.
- TargetManager will now update all IP-Addresses (by doing a DNS Lookup) whenever either GameTalkMonitor is started or the TargetManager is opened from within the GameTalkMonitor.  This will resolve issues with systems getting assigned new IP address via DHCP.
- GameTalkServer will now dynamically increase the size of its buffer to handle GameTalkMessages that are larger than its existing buffer.  This allows users to send GameTalkMessages of any size and the server's buffer should just grow to accomodate it.
- Like the GameTalkServer, the C# client will also dynamically resize its buffer if necessary.
- Added "GameTalk::" prefix to names used in allocators in a namespace'esque fashion


1.9.1
=====
- Clients can now request the server to buffer messages for clients that are not yet connected - so that when those unconnected clients connect they will get all their buffered messages.
- Refined the Target matching algorithm so that targets can be matched on partial names - example: client sends a message to "Game" - this will be sent to all clients with a name that starts with "Game." - but will not be sent to a client whose name is "Games.Server".
- On some computers, when the GameServer is initially installed the ImagePath registry key is invalid (from the InstallUtil process) - so we've just added a post install step to update the registry key with quotation marks around the current value.
- If the revision number (major.minor.revision.build) is newer - GameTalk server will now install itself.  Previously it would only install itself if the major and minor number were higher.
- Fixed small bug that would result in the Server being reinstalled even if collectively the major and minor numbers didn't result in a higher version.  I.E. if the version being run was 2.1.0.0 and the version wanting to run was 1.9.0.0 - 1.9.0.0 would get run.
- We now not only notify all currently connected clients of all other clients that are connecting or disconnecting.  But we now also send the complete list of clients that are connected to any client that connects.  This list is sent on the "Server Message" channel.

1.9.0
=====
- Ability to run server as an application for debugging.
- Added Xenon sample programs to test with a console application.
- GameTalk Viewer improvements for memory usage and CPU utilization.
- GameTalk Server now uses asynchronous sends so that it doesn't block on sending messages.
- GameTalk Connection (client side) uses Producer and Consumer threads to increase the throughput.
- GameTalkXCPP client is now able to parse and validate messages from the GameTalk test app.
- GameTalk Viewer/Monitor now only does checks on the log file based on the timer - previously it would do it when the file would get updated - but at high volumes of messages this is unnecessarily quick (and thus processor intensive).
- Added a new channel that the GameTalkServer will use to broadcast messages to clients.  This is currently only used to broadcast connections and disconnections by clients - so that all clients know whenever any other client connects or disconnects.
- GameTalkServer logs to multiple log files and GameTalkViewer/Monitor is able to read from them.  This allows GameTalkViewer/Monitor to instantly determine who is connected and display the most recent traffic without impacting the processor or memory.
- Fixed spike in memory when log files are particularly large and GameTalkViewer/Monitor gets shut-down and then restarted.

1.8.1
=====
- Added the ability to specify the update time for the GameTalk viewer to prevent CPU spike during high traffic.
- Lower the timeout on events for the Win32 client to improve performance.
- A gametalkuserinclude.h is now required. If not specified with USER_GAMETALK_INCLUDE macro, an error will occur.
- Added a test project for testing the game implementation of GameTalk.

1.8.0
=====
- Added ability to connect to a remoted GameTalk server.
- Fixed a bug in the GameTalk server for receiving messages.
- Updated GameTalk.h comments to ensure the proper types are defined for the package.
- Updated RealComm GameTalkProtocols (version 6 & 7) to properly handle partial messages.
- Updated all GameTalkProtocol to have the temp buffer as a member rather than a local array.
- Updated GameTalk Sever to allow messages sent from a target to be sent to itself if desired.
- Added a DirtySock GameTalkProtocol for version 4.2.2.
- Added a couple more macros to allow teams to provide their endian and memcpy methods through gametalkuserinclude.h.
- Unified types and provided a system to have teams provide its own types through gametalkuserinclude.h.
- GameTalk C# client is now strongly named.
- Fixed a bug in the Win32 client where the thread would not close on shutdown.

1.7.0
=====
- Fixed a bug in the GameTalk server when a message was being processed but not all the data
had arrived yet.
- Improved performance of GameTalk server for handling packets received and processing them.
- Added Win32 GameTalkProtocol for game.
- Fixed DirtySock GameTalkProtocol to be more responsive and to better handle partial messages.

1.6.0
=====
- Improve the interface for the GameTalkMessage to clearly identify the parameter for either a string or a binary message
- Fixed a bug in the tool GameTalk manager when there are no network setup on the PC.
- Updated the GameTalk server to provide more information if there is a problem internally.
- Improved the GameTalk monitor to only update the internal list when the monitor is open.

1.5.1
=====
- Fixed compiler warnings for the run-time code.
- Fixed platform define compiler error.
- Fixed a compiler error in the assert macro.
- Added a line at the end of some source files for PS3 compiler.

1.5.0
=====
- Fixed a bug with broadcasting to all targets by using "" (empty string) for the target
- Made some parameters const in the GameTalk class
- Added PS3 target
- Fixed a bug when parsing the log to be displayed in the GameTalk Monitor
- Fixed a non-critical exception when adding a target
- Fixed a non-critical exception when exiting GameTalk Monitor
- Change the tool client (C# and Win32) to specify a listener per channel as opposed to one 
listener for everything.
- Split the GameTalkWin32 into multiple files for simplicity. The user has everything needed to use
GameTalk in one header

1.4.0
=====
*** 1.4.0 is not compatible with earluer 1.3.x versions ***
- Added a port attribute to targets. The port is optional, and used by the target only when the targets
wish to have GameTalk connect to them, rather than connecting to GameTalk itself.
- Updated the GameTalkMessage interface to handle binary content.
- The Win32 client is now completely native Win32 with no managed code.
- Updated the GameTalkMessage to reallocate the key/value pair array when too small.

1.3.8
=====

- Win32 client had a handle leak that was fixed.
- Improved the internal setup logic for the Game Talk Monitor for both Win32 and C# clients.
- Fixed a few classes in GameTalk's run-time allocation to go through the game's provided allocations.
- Fixed a bug where the tcp client could not write to the stream.

1.3.7
=====

- Win32 client cleaned up. Some console specific code was still present which doesn't
work so well in multi-threaded application.
- Server will only install when the major or minor version has increased
- Removed a warning in RealComm7 GameTalkProtocol
- Added IsConnected() method to GameTalk

1.3.6
=====

- Fixed a bug in the game's GameTalk module where a buffer could contain more than one
message but only the first one was handled.
- Added a re-install server menu item to the monitor to provide an easy way for the users
to re-install the server when needed.
- Fixed a bug in the Target Manager after an item is released from the list the button
to add another would not enable again.

1.3.5
=====

- Made the GameTalk Monitor window icon not show up when alt-tabbing since it's minimized. 
When display, the icon will show up in the task bar.

1.3.4
=====

- Move the includes from include to include\GameTalk
- Set the port to 9876 by default in the constructor
