If I start from the command line with xemacs -vanilla, the same thing
happens. Likewise with xemacs -no-autoloads -no-packages. Note the
dialog that pops up has Cancel, Try Again, Continue: but Cancel doesn't.
It requires 11 sequences of dialog/hit Cancel to get past it.
I don't build the distribution, I use a binary, so I can't comment on
Interestingly, as Windows Vista continues to evolve on its own :-(, the
error message has recently changed: now it's "Exception Processing
Message 0xc00000013 Parameters <a few more hex numbers>".
From: Stephen J. Turnbull [mailto:stephen＠xemacs.org]
Sent: Tuesday, April 17, 2007 6:42 PM
To: Vin Shelton
Cc: Michael Sperber; xemacs-beta; Sean.Boisen(a)gmail.com
Subject: Re: [comp.emacs.xemacs] Re: M-x shell fails under Windows
Vin Shelton writes:
> the "\\e:" looks bogus to me.
I agree it's bogus, but under what conditions does Windows consider
"\e:" a drive letter? Does Windows say what it's looking for? (I'm
wondering if all the other backslashes disappear too, as they should
if something is interpreting those as Lisp or C string escapes.)
> In any case, something in the 21.5 startup code is looking for a
> file in the "e:" drive, which doesn't exist on Sean's system.
I still think that is a Microsoft bug, not an XEmacs bug (unless
there's a documented way to tell Windows not to prompt for missing
media, which we should use). It should be possible for a program to
probe for existence, access, etc of data without bothering the user.
Be that as it may, I guess we have to try to reduce the user pain...
Sean, have you tried starting up with -vanilla? How about with
-no-autoloads and -no-packages?
Do you build the distribution with "--with-prefix=no"?
Since there are no references to "e:" in the output of debug-paths, I
would consider the possibility of something in package auto-autoloads,
as well. Do you build a package distribution for use with the Windows
XEmacs-Beta mailing list