Andrew> Unfortunately, setenv only affects subprocesses, not the Andrew> XEmacs process itself. And since XEmacs is the process Andrew> loading my DLL, Windows looks at its PATH, not PATHs for Andrew> subprocesses. In general Emacs prefers to handle these things itself. Doesn't `module-load-path' have the documented semantics under Windows? We don't have a function that actually changes the environment. I don't know why. I don't see why that would be dangerous, but I'm not an expert on hairy process stuff. It's plausible that it just got omitted because it's a noop in an Emacs without dl capability. I do know that Ben is rewriting the process stuff, see comments in src/callproc.c, so you should coordinate with him on any addition. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

module-load-path works for finding the dll that load-module() loads, but doesn't handle any dependent DLL libraries that are linked into the dll. Basically, our project has an XEmacs DLL external module which is dependent on a few DLLs that we provide; but we need to put these DLLs into the PATH so that the dlopen() of the external module DLL succeeds. Otherwise you get a nice dialog box from Windows stating that it couldn't find such-and-such.dll in the PATH. We could modify setenv to take an optional boolean arg that would indicate whether this change affects the Xemacs process, or just subprocesses. Default would be false, and just affect the subprocesses (the current behavior). True would cause a change to the XEmacs process as well as causing XEmacs to reload that environment variable into the lisp variable for the environment. Thoughts? Andrew On Tuesday, October 23, 2001, at 09:51 PM, Ben Wing wrote: ----------- Andrew Begel Computer Science Division UC Berkeley

Andrew> module-load-path works for finding the dll that Andrew> load-module() loads, but doesn't handle any dependent DLL Andrew> libraries that are linked into the dll. OK. Andrew> Basically, our project has an XEmacs DLL external module Andrew> which is dependent on a few DLLs that we provide; but we Andrew> need to put these DLLs into the PATH so that the dlopen() Andrew> of the external module DLL succeeds. Otherwise you get a Andrew> nice dialog box from Windows stating that it couldn't find Andrew> such-and-such.dll in the PATH. Isn't this an abuse of PATH searching? PATH searching is intended to provide a way for applications to find executable code that they _don't_ provide themselves. But you already know where those DLLs are, you found the ELL (XEmacs-specific DLL) there, right? This works fine for XEmacs itself, and has the additional advantage of avoiding version skew (or breakage of delay-loaded modules) if the user should do something like manipulate PATH themselves. Or the ELL could just call the platform's setenv(3) itself. This has its own problems, namely possible name conflicts for other ELLs that abuse PATH searching in the same way. But since you're changing the fundamental assumption that XEmacs makes about `process-environment' anyway, why not? This has the advantage from my point of view that _all_ non-module XEmacs functionality will work the same way it ever did, because your PATH-munging will be totally ignored by XEmacs. Andrew> We could modify setenv to take an optional boolean arg Andrew> that would indicate whether this change affects the Xemacs Andrew> process, or just subprocesses. I don't much like this off-hand. It will be another gratuitous API incompatibility with GNU Emacs. What's wrong with just defining new primitive functions, say `{get,set}-real-environment', and in a module of their own? Also, why impose the extra path in PATH on subprocesses etc that just don't care about your DLLs? See above. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Andrew> There's one flaw in the logic. The above argument assumes Andrew> that the ELL is loading dependent DLLs via dlopen() Andrew> (LoadLibrary() on Win32). However, if you've merely Andrew> mentioned the dependent DLL on the link line for the ELL, Well, yes, that is what I'm assuming. I consider that usage in this context a mild abuse. YMMV and pretty clearly it does. Andrew> We impose the extra PATH on all Windows applications that Andrew> don't care about our DLL instead of just XEmacs. :) I actually like that better, since you'll see it in a PATH command. If somebody tells me "maybe your PATH is wrong", strangely enough my instinct is not to type xemacs -batch -eval '(prin1 (getenv "PATH"))' -kill. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.