Add a TODO with the 6 remaining "problems"

TODO

@@ -0,0 +1,77 @@
+Long term TODO list for Quake II on Windows
+-------------------------------------------
+
+1. Test various windows version. At least:
+   - Windows XP [done]
+   - Windows XP 64
+   - Windows 2003
+   - Windows Vista 
+   - Windows 2008
+   - Windows 7 [done]
+   - Windows 8 Preview [done]
+
+2. The "dsound" sound system issue:
+   By default SDL uses the "waveout" sound driver which
+   needs to many buffers to be usable with Quake II. There
+   is no easy way to work around this, we can neither call
+   the sound system more often nor generate more sound per
+   call. The short term solution is to force the DirectX 5
+   bases "dsound" driver. But "dsound" is unavailable for
+   64 bit applications on 64 bit Windows and on Windows 8.
+   SDL 2.0 has the new DirectX 8 based "directsound" driver
+   but that would require a port of Yamagi Quake II to the
+   still unstable SDL 2.0. Another soultion would be a 
+   custom SDL.dll with the new driver backported to SDL
+   1.2.15.
+
+3. The keyboard layout issue:
+   SDL 1.2 has a bug which results in untranslated keycodes
+   on non qwerty layouts. The consequence is, that Quake II
+   uses always the english keyboard layout, regardless of it's
+   real layout and the layout setting in the windows control
+   pannel. The recommendet work around is to switch SDL into
+   unicode mode and read unicode characters instead of the
+   raw keycodes. But implementing this into Quake II would 
+   be a real PITA due to the rather complex differences
+   between the internal input system and SDL. ioQuake3 uses
+   unicode input for the console and raw input for the key
+   bingings, has therefor a correct layout in the console 
+   but an english layout on normal key bindings. Their 
+   implementation is rather invasive into the console
+   subsystem and I don't think that it's worth the efford.
+
+4. The unicode issue:
+   Quake II only allows ASCII characters, internally all
+   characters are represented as "char". But Windows uses
+   unicode quite often. This may lead to problems. The big
+   question is: "What happens, if the path to the home dir
+   contains unicode characters?" At what can we do to prevent
+   problems without rewriting the whole game to be unicode
+   aware? This may be a problem on Linux and FreeBSD too,
+   but at least on FreeBSD unicode characters in the user-
+   name are a bad idea and for things to work correctly
+   the homedir-name should be the same as the username...
+
+5. The debug / stdout issue:
+   At the moment no stdout is readable on windows, the only
+   way is to scroll in the console. This is a problem, because
+   without the game output problems are hard to debug. Enabling
+   the console log by default might migitate the problem, but 
+   the early startup is not convered by it. One solution would
+   be to redirect stdout into a file (like dhewm). Daniel
+   suggested to implement a console window like the orginal
+   Quake III Arena client had.
+   It would be nice, if the Windows crash handler would be 
+   invoced at every crash and not only sometimes. In theory
+   the crash handler is able to create crash dumps and send
+   them to a remore location (only Micorsoft or anybody?).
+   While I'm not sure that gdb can read Windows crashdumps,
+   it may be worth to take a deeper look into this.
+
+6. The CR-LF issue:
+   At the moment all files habe LF line endings, which are
+   incompatible with most Windows software. This isn't a
+   problem for the code itself (at least with MinGW), but
+   for the documentation. A possible solution is to use git
+   to convert the file endings at checkout. This would leave
+   the repo at LF and enable CR-LF for Windows.