Issue 95028 - python.exe does not call WSAStartup
Summary: python.exe does not call WSAStartup
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOO300m9
Hardware: PC Windows, all
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: joergbudi
QA Contact: issues@udk
: 87894 (view as issue list)
Depends on:
Reported: 2008-10-16 16:48 UTC by Stephan Bergmann
Modified: 2010-02-22 15:26 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2008-10-16 16:48:48 UTC
This is discussed at
<> ("However,
when..."), with a workaround ("import socket") presented at
<>.  See also
issue 95024.

The correct solution would be to let pyuno/zipcore/python.cxx:1.4 implement
SAL_IMPLEMENT_MAIN_WITH_ARGS instead of plain main/wmain, so that
sal/osl/w32/salinit.cxx:1.3 sal_detail_initialize is called at startup (which
calls WSAStartup).  However, that would need further rework, as brand-layer
python.exe does not find URE-layer sal3.dll (rather, python.exe expands the PATH
so that subsequent programs do find it).
Comment 1 joergbudi 2008-10-16 21:44:16 UTC

I think, it won't be enough to put this in the wrapper, the child process needs
to call WSAStartup again, doesn't it?

The call to WSAStartup was removed from sal with i77184 in sal/osl/w32/dllentry

Was this removal really necessary ? There are other circumstances, where
SAL_IMPLEMENT_MAIN_WITH_ARGS cannot be used(e.g. think of sal lib running as
internet explorer plugin, etc.). 


Comment 2 Stephan Bergmann 2008-10-17 08:59:11 UTC
@jbu:  Right, the call to WSAStartup would have to be done in the "final"
executable (which is the external python-core-*\bin\python.exe, so this would
become really hacky).  The call to WSAStartup was moved from sal
/osl/w32/dllentry.c (called upon loading sal3.dll) to sal/osl/w32/salinit.cxx
(called from SAL_IMPLEMENT_MAIN) when we experimented with delay-loading
libraries, see
"It turned out _RawDllMain in sal/osl/w32/dllentry.c:1.29 does things that
cannot be done in DllMain."  It needs to be re-evaluated whether the call to
WSAStartup can be moved back.
Comment 3 Stephan Bergmann 2008-10-17 08:59:45 UTC
Comment 4 Stephan Bergmann 2008-11-20 09:47:56 UTC
fixed as cws/sb101/pyuno/source/module/, simply adding "import
socket" there
Comment 5 Stephan Bergmann 2008-11-26 13:01:59 UTC
*** Issue 87894 has been marked as a duplicate of this issue. ***
Comment 6 Stephan Bergmann 2008-12-03 10:48:43 UTC
@jbu: please verify
Comment 7 joergbudi 2008-12-07 21:05:55 UTC
verified on sb101
Comment 8 thorsten.ziehm 2010-02-22 15:26:42 UTC
This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues :