<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 11/23/2010 3:55 AM, "Martin v. Löwis" wrote:
<blockquote cite="mid:4CEBABBA.9050002@v.loewis.de" type="cite">
<pre wrap="">Am 23.11.2010 11:55, schrieb Amaury Forgeot d'Arc:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
2010/11/23 Glenn Linderman <a class="moz-txt-link-rfc2396E" href="mailto:v+python@g.nevcal.com"><v+python@g.nevcal.com></a>:
</pre>
<blockquote type="cite">
<pre wrap=""> File "C:\Python32\lib\random.py", line 108, in seed
a = int.from_bytes(_urandom(32), 'big')
WindowsError: [Error -2146893818] Invalid Signature
</pre>
</blockquote>
<pre wrap="">
In the subprocess documentation <a class="moz-txt-link-freetext" href="http://docs.python.org/library/subprocess.html">http://docs.python.org/library/subprocess.html</a>
"""On Windows, in order to run a side-by-side assembly the specified
env *must* include a valid SystemRoot."""
</pre>
</blockquote>
<pre wrap="">
Indeed, setting SystemRoot might solve this problem. According to
<a class="moz-txt-link-freetext" href="http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/">http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/</a>
CrypoAPI, in Windows 7, requires this variable be set. Failure to
find the enhanced crypto provider would explain why the "random"
module of Python fails to work.
The specific cause is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Defaults\Provider\Microsoft
Strong Cryptographic Provider has as it's ImagePath value
%SystemRoot%\system32\rsaenh.dll
So the registry (and COM) do rely on environment variables.
Regards,
Martin
</pre>
</blockquote>
<br>
I find it sad but hilarious that after working so hard to remove the
need for environment variables from Windows that M$ has introduced
new dependencies on them.<br>
<br>
I wonder if this particular registry variable is simply an
oversight/bug on M$' part, that they will eventually fix, or if it a
turnaround toward the use of more environment variables in the
future. Hmm. Time will tell, I suppose. I'm unaware of any
benefits in _changing_ SystemRoot to other values, so not
pre-expanding it in that registry location seems only to add an
unnecessary dependency on the environment.<br>
<br>
Indeed, preserving that one environment variable allows my version
of http.server to proceed with, as far as initial testing can
determine, proper behavior. Thanks for your help in figuring this
out. That was a lot faster than a "binary search" to choose which
variable(s) to preserve.<br>
<br>
My purpose in such testing was two-fold: firstly, web servers, for
security purposes, generally limit the number of environment
variables that are seen by CGI programs, and secondly, in debugging
whether or not http.server was properly setting the necessary
environment variables, the many other environment variables were
cluttering up log dumps of all environment variables. It will be
nicer to limit the "passed through" environment variables to
SystemRoot, as see how things go.<br>
<br>
I have read some about side-by-side assemblies but had considered
them a good reason to stick with the outdated M$VC 6.0 compiler,
which doesn't seem to need to create them, and their myriad
requirements, which seem far from necessary for simply compiling a
program. I was disappointed to realize that Python was heading down
the path of using the newer tools that create side-by-side
assemblies, but I suppose using an old and crufty compiler like M$VC
6.0 cannot support some of the newer features of Windows, which may
seem to be necessary to some.... like 64-bit support, which does
seem necessary, even to me.<br>
<br>
I was well aware that shortcuts and the registry _may_ refer to
environment variables, and have a number of environment variables of
my own which leverage that capability, to avoid hard-coded drive
letters and paths in certain areas, and for the convenience of
shorting the specification of some of the long-winded path names
that Windows foists upon us (some of those have been significantly
shortened in Windows 6.1, and maybe 6.0 which I used only for 2
months with disgust; 6.1 has helped alleviate the disgust, but I
still recommend XP for people that don't need 64-bit capabilities).<br>
<br>
<br>
</body>
</html>