diff --git a/contrib/cygtermd/pty.h b/contrib/cygtermd/pty.h
index 523331b3..261fc41d 100644
--- a/contrib/cygtermd/pty.h
+++ b/contrib/cygtermd/pty.h
@@ -1,5 +1,5 @@
 /*
- * pty.h - FIXME
+ * pty.h - declare functions for pty setup
  */
 
 #ifndef CYGTERMD_PTY_H
diff --git a/unix/uxstore.c b/unix/uxstore.c
index 155f3647..84d8d4d6 100644
--- a/unix/uxstore.c
+++ b/unix/uxstore.c
@@ -282,14 +282,19 @@ void close_settings_w(settings_w *handle)
     sfree(handle);
 }
 
-/*
- * Reading settings, for the moment, is done by retrieving X
- * resources from the X display. When we introduce disk files, I
- * think what will happen is that the X resources will override
- * PuTTY's inbuilt defaults, but that the disk files will then
- * override those. This isn't optimal, but it's the best I can
- * immediately work out.
- * FIXME: the above comment is a bit out of date. Did it happen?
+/* ----------------------------------------------------------------------
+ * System for treating X resources as a fallback source of defaults,
+ * after data read from a saved-session disk file.
+ *
+ * The read_setting_* functions will call get_setting(key) as a
+ * fallback if the setting isn't in the file they loaded. That in turn
+ * will hand on to x_get_default, which the front end application
+ * provides, and which actually reads resources from the X server (if
+ * appropriate). In between, there's a tree234 of X-resource shaped
+ * settings living locally in this file: the front end can call
+ * provide_xrm_string() to insert a setting into this tree (typically
+ * in response to an -xrm command line option or similar), and those
+ * will override the actual X resources.
  */
 
 struct skeyval {
@@ -352,6 +357,11 @@ static const char *get_setting(const char *key)
     return x_get_default(key);
 }
 
+/* ----------------------------------------------------------------------
+ * Main code for reading settings from a disk file, calling the above
+ * get_setting() as a fallback if necessary.
+ */
+
 struct settings_r {
     tree234 *t;
 };
diff --git a/windows/version.rc2 b/windows/version.rc2
index 500f9002..5cc127a4 100644
--- a/windows/version.rc2
+++ b/windows/version.rc2
@@ -1,9 +1,12 @@
 /*
  * Standard Windows version information.
  * (For inclusion in other .rc files with appropriate macro definitions.)
- * FIXME: This file is called '.rc2' rather than '.rc' to avoid MSVC trying
- * to compile it on its own when using the project files. Nicer solutions
- * welcome.
+ *
+ * This file has the more or less arbitrary extension '.rc2' to avoid
+ * IDEs taking it to be a top-level resource script in its own right
+ * (which has been known to happen if the extension was '.rc'), and
+ * also to avoid the resource compiler ignoring everything included
+ * from it (which happens if the extension is '.h').
  */
 
 #include "version.h"
diff --git a/windows/win_res.rc2 b/windows/win_res.rc2
index 0c486ce5..503fa022 100644
--- a/windows/win_res.rc2
+++ b/windows/win_res.rc2
@@ -1,12 +1,16 @@
 /*
  * Windows resources shared between PuTTY and PuTTYtel, to be #include'd
  * after defining appropriate macros.
+ *
  * Note that many of these strings mention PuTTY. Due to restrictions in
  * VC's handling of string concatenation, this can't easily be fixed.
  * It's fixed up at runtime.
- * FIXME: This file is called '.rc2' rather than '.rc' to avoid MSVC trying
- * to compile it on its own when using the project files. Nicer solutions
- * welcome.
+ *
+ * This file has the more or less arbitrary extension '.rc2' to avoid
+ * IDEs taking it to be a top-level resource script in its own right
+ * (which has been known to happen if the extension was '.rc'), and
+ * also to avoid the resource compiler ignoring everything included
+ * from it (which happens if the extension is '.h').
  */
 
 #include "win_res.h"