8:20 p.m.
I'm loading a DLL by name, but the DLL has to be in the XEmacs
process'
PATH for Windows to find it. The DLL comes from a plug-in we wrote, and
we want to be able to load it just by putting in some lines into a
user's .emacs file; rather than making them run a script that modifies
their PATH first, and then runs XEmacs.
Try M-x setenv and M-x getenv.
In lisp it might be something like:
(setenv "PATH" (concat (getenv "PATH") "xxx;"))
If it's in your init file it should be inherited by all buffers, and to any
sub-processes.
/J. Haglund
8:37 p.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
Unfortunately, setenv only affects subprocesses, not the XEmacs process
itself. And since XEmacs is the process loading my DLL, Windows looks at
its PATH, not PATHs for subprocesses.
Andrew
On Tuesday, October 23, 2001, at 12:20 PM, Jerker Haglund wrote:
> I'm loading a DLL by name, but the DLL has to be in the XEmacs process'
> PATH for Windows to find it. The DLL comes from a plug-in we wrote, and
> we want to be able to load it just by putting in some lines into a
> user's .emacs file; rather than making them run a script that modifies
> their PATH first, and then runs XEmacs.
Try M-x setenv and M-x getenv.
In lisp it might be something like:
(setenv "PATH" (concat (getenv "PATH") "xxx;"))
If it's in your init file it should be inherited by all buffers, and to
any sub-processes.
/J. Haglund
-----------
Andrew Begel
Computer Science Division
UC Berkeley
3:21 a.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
>>>> "Andrew" == Andrew Begel
<abegel(a)eecs.berkeley.edu> writes:
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.
5:51 a.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
"Stephen J. Turnbull" wrote:
>>>>> "Andrew" == Andrew Begel <abegel(a)eecs.berkeley.edu>
writes:
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?
yes, i agree, we should do it ourselves if possible to avoid unpredictable
library semantics.
We don't have a function that actually changes the environment. I
don't know why.
it's basically a matter of principle. we don't [didn't?] need it, so it
makes
for fewer surprises to always do things in process-environment and never the
actual environment.
e.g. in my mule ws i actually replaced all calls to getenv[] with egetenv[],
which checks process-environment, for encoding reasons.
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.
9:33 a.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
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:
"Stephen J. Turnbull" wrote:
>
>>>>>> "Andrew" == Andrew Begel
<abegel(a)eecs.berkeley.edu> writes:
>
> 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?
yes, i agree, we should do it ourselves if possible to avoid
unpredictable
library semantics.
>
> We don't have a function that actually changes the environment. I
> don't know why.
it's basically a matter of principle. we don't [didn't?] need it, so
it makes
for fewer surprises to always do things in process-environment and
never the
actual environment.
e.g. in my mule ws i actually replaced all calls to getenv[] with
egetenv[],
which checks process-environment, for encoding reasons.
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.
>
-----------
Andrew Begel
Computer Science Division
UC Berkeley
5:18 p.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
At 01:33 AM 10/24/2001 -0700, Andrew Begel wrote:
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.
One of the things I've been considering for a while is writing lisp
primitives that allow you to manipulate the windows registry. This would
then allow you to muck with AppPaths under windows which I think would
achieve what you want. Windows-specific though...
andy
5:37 a.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
>>>> "Andrew" == Andrew Begel
<abegel(a)eecs.berkeley.edu> writes:
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.
9:41 a.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
On Wednesday, October 24, 2001, at 09:37 PM, Stephen J. Turnbull wrote:
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.
There's one flaw in the logic. The above argument assumes that the ELL
is loading dependent DLLs via dlopen() (LoadLibrary() on Win32).
However, if you've merely mentioned the dependent DLL on the link line
for the ELL, Windows will load the dependent DLLs automagically as a
result of said dlopen() call. Thus, there's no time/place for the ELL to
modify the PATH, since it's not completely loaded by Windows yet, and
therefore can't run any of its own code.
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.
The alternative, suggested a few messages back, is that our application
installer modify the user's PATH during the installation process --
which effectively leads to the same effect as your last question in the
above paragraph. We impose the extra PATH on all Windows applications
that don't care about our DLL instead of just XEmacs. :)
Andy
-----------
Andrew Begel
Computer Science Division
UC Berkeley
1:16 p.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
>>>> "Andrew" == Andrew Begel
<abegel(a)eecs.berkeley.edu> writes:
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.
11:10 p.m.
New subject: How do you modify PATH on Windows XEmacs 21.4.3
Andrew Begel wrote:
On Wednesday, October 24, 2001, at 09:37 PM, Stephen J. Turnbull wrote:
>
> 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.
>
There's one flaw in the logic. The above argument assumes that the ELL
is loading dependent DLLs via dlopen() (LoadLibrary() on Win32).
However, if you've merely mentioned the dependent DLL on the link line
for the ELL, Windows will load the dependent DLLs automagically as a
result of said dlopen() call. Thus, there's no time/place for the ELL to
modify the PATH, since it's not completely loaded by Windows yet, and
therefore can't run any of its own code.
> 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.
The alternative, suggested a few messages back, is that our application
installer modify the user's PATH during the installation process --
which effectively leads to the same effect as your last question in the
above paragraph. We impose the extra PATH on all Windows applications
that don't care about our DLL instead of just XEmacs. :)
Well, munging the Autoexec.bat file and telling/forcing the user to
reboot is very common in Windoze (thru 98 anyway). Lots of "big names"
do that. The simplest way, if you've been careful with your dll names,
would be to park them in %windir%\SYSTEM because that is always searched.
The *first* directory searched when a *.exe references a .dll is the
directory from which Win loaded the .exe. I don't know what that means
when you do your own load. It would be nice if it were the same
directory from which the manually-loaded dll came; but Bill ain't that
friendly.
If it were me, I think I'd put all the dll's into a single library
directory and make sure that's in my path.
I'm not even sure that the system loader would honor changes to your
*own* environment block that are made after you are loaded; it might be
using the environment you were initially passed.
--
David A. Cobb, Software Engineer, Public Access Advocate, All around
nice guy.
New PGP key 09/13/2001:
:<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit&\
fingerprint=on>
:<http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=superbiskit&\
fingerprint=on>
Fingerprint=0x{E7C6_4EE2_6B75_5BA3_C52E__77FA_63C3_9366_DCFB_229B}
"By God's Grace I am a Christian man, by my actions a great sinner."
--The Way of a Pilgrim, R. M. French [tr.]
Potentially Viral Software is any software for which you are not allowed
to examine the source. Do not buy or use Potentially Viral Software!
8240
days inactive
8242
days old
9 comments
6 participants
participants (6)
-
Andrew Begel -
Andy Piper -
Ben Wing -
David A. Cobb -
Jerker Haglund -
Stephen J. Turnbull