diff --git a/TODO b/TODO
deleted file mode 100644
index 3c1914c2..00000000
--- a/TODO
+++ /dev/null
@@ -1,67 +0,0 @@
-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 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.
-
-5. 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.