--- a/src/ChangeLog	Tue Dec 22 19:03:25 2009 +0900
+++ b/src/ChangeLog	Tue Dec 22 19:07:40 2009 +0900
@@ -1,3 +1,10 @@
+2009-11-27  Adrian Aichner  <adrian@xemacs.org>
+
+	* nt.c (mswindows_getdcwd): Check first whether drive is valid
+	with _getdrives() to avoid crash in _wgetdcwd(...) when linking
+	against msvcrt8.  This fix was taken from the Mozilla project
+	which experienced the same problem.
+
 2009-12-18  Jerry James  <james@xemacs.org>
 
 	* ppc.ldscript: Remove, obsolete.

--- a/src/nt.c	Tue Dec 22 19:03:25 2009 +0900
+++ b/src/nt.c	Tue Dec 22 19:07:40 2009 +0900
@@ -1815,7 +1815,27 @@
 {
   Extbyte *cwdext;
   Ibyte *cwd;
-
+  /* Following comment and two-liner fix comes from
+     https://bugzilla.mozilla.org/show_bug.cgi?id=419326 which
+     apparently fell prey to this feature of msvcrt8 as well. */
+  /* We need to worry about IPH, for details read bug 419326.
+   * _getdrives - http://msdn2.microsoft.com/en-us/library/xdhk0xd2.aspx 
+   * uses a bitmask, bit 0 is 'a:'
+   * _chdrive - http://msdn2.microsoft.com/en-us/library/0d1409hb.aspx
+   * _getdcwd - http://msdn2.microsoft.com/en-us/library/7t2zk3s4.aspx
+   * take an int, 1 is 'a:'.
+   *
+   * Because of this, we need to do some math. Subtract 1 to convert from
+   * _chdrive/_getdcwd format to _getdrives drive numbering.
+   * Shift left x bits to convert from integer indexing to bitfield indexing.
+   * And of course, we need to find out if the drive is in the bitmask.
+   *
+   * If we're really unlucky, we can still lose, but only if the user
+   * manages to eject the drive between our call to _getdrives() and
+   * our *calls* to _wgetdcwd.
+   */
+  if (!((1 << (drivelet - 1)) & _getdrives()))
+    return NULL;
   if (XEUNICODE_P)
     cwdext = (Extbyte *) _wgetdcwd (drivelet, NULL, 0);
   else