[Zope-dev] Experiencing TypeError: The object is not a PySECURITY_ATTRIBUTES object

[Mark Hammond]

> All "recent" PySECURITY_ATTRIBUTES complaints I know about have come
> from people using both Zope and Plone.  I don't know anything about
> Plone installation, but it's natural to suspect that Plone is the
> source of the other pywin32 installation, and possibly of compounding
> sys.path convolutions too.
>
> So, a natural question based on this ignorance:  is it enough for just
> Zope to install build 205, if Plone also installs its own (older)
> pywin32 and mangles sys.path so that its pywin32 is also visible?
> I suspect (but don't know) that's what's happening.

When first reading this, I assumed we were talking about a Plone binary
build - which the following all applies to:

I believe the problem is that the Plone installer (like the Enfold Server)
copies pywintypes23.dll etc to system32 as part of the install.  This is
evil and is being addressed.

The issue isn't sys.path mangling as such, as pywintypes23.dll is never
imported directly by Python (ie, no one ever imports a module of that name).
The problem is that when pywintypes23.dll is in system32 *and* in the same
directory as the executable, the following things can happen:

'import pywintypes' - pywintypes.py explicitly looked for and loaded
pywintypes23.dll
'import win32api' - Windows looks for and loads pywintypes23.dll due to
win32api.pyd using symbols from the DLL.

The problem was that Windows was a little smarter than me :)  If 'import
pywintypes' has been done first, Windows would notice the module was already
loaded, so 'import win32api' would happily use that.  But when 'import
win32api' happens first, Windows has already loaded pywintypes23.dll.  If
the 'import pywintypes' followed, we did *not* reuse the already loaded
module - we (possibly) chose and loaded a new one.

The fix in pywin32 was to use a special .pyd file that was capable of
determining if pywintypes23.dll was already loaded, and if so, reuse that
(ironically, win32api itself could do that if only it didn't depend on
pywintypes23.dll itself!  This new .pyd obviously does not depend on that
DLL)

Moving forward: I have fixed the "Plone Community" installer released by
Enfold to copy nothing into system32, and confirmed that it does work even
when the DLL exists in system32, and this should be released soon.  I hope
to give our commercial offering "Enfold Server" the same treatment very
soon.  The older plone installers will probably not be fixed.

BUT - reading Chris's mail, it seems he installed a Zope binary package, and
manually added the Plone products to it.  In this case, I doubt Plone is
mangling much, nor would it be copying pywintypes23.dll around.  Thus,
unless there was a pre-existing pywintypes23.dll in system32, I don't see
how this problem could happen.  I've asked Chris to let me know if there was
that pre-existing DLL.

> It would be a lot
> better if a Plone user tested the proposed solution before we release
> another Windows Zope that may still turn out not to solve Plone's
> problems here.

I've mailed Chris the 2 relevant updated files to see if his problem goes
away.  I guess that is a good start :)

Cheers,

Mark