The enclosed patch against package version 1.06 of w3 makes w3 mostly work on the native mswindows build of XEmacs. The patched function url-basepath has actually changed since 1.06 so this patch won't apply, but that's OK beause I'm really just asking for advice. The problem that the patch fixes is that w3 calls XEmacs path handling functions on URL paths. That doesn't work under mswindows because these path handling functions convert path separators into '\\' because that is the native path separator on Win32. The attached patch replaces two occurrences in url-basename of such calls with manual string-matches. There are a lot more calls to XEmacs path handling functions in w3. Many of these calls are fine on mswindows because they're being called on local pathnames of files. Probably there are other calls where the pathname in question is actually the pathname component of a URL, and these will break on mswindows. Is there any structuring in the w3 files that will enable me to go about identifying all such calls that will break, or do I really have to examine _every_ single call to XEmacs path handling functions? Alternatively, is there a better approach than manually replacing selective calls to XEmacs path handling functions with string matches? Jonathan. -- Jonathan Harris | jhar(a)tardis.ed.ac.uk London, England | Jonathan.Harris(a)symbian.com --- url.el.bak Tue Apr 28 04:05:23 1998 +++ url.el Thu Jul 30 18:39:36 1998 ＠＠ -1233,8 +1233,13 ＠＠ "Return the base pathname of FILE, or the actual filename if X is true" (cond ((null file) "") - (x (file-name-nondirectory file)) - (t (file-name-directory file)))) + (x + (if (string-match "[^/]*$" file) + (match-string 0 file) + file)) + (t + (if (string-match ".*/" file) + (match-string 0 file))))) (defun url-parse-query-string (query &optional downcase) (let (retval pairs cur key val)