Long term TODO list for Quake II on Windows
-------------------------------------------

1. Test various windows version in different
   localizations. 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
   based "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. Be aware, that this problem only affects the
   SDL sound-backend and not the default OpenAL backend!

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 have 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.