Issue 95028 - python.exe does not call WSAStartup
python.exe does not call WSAStartup
Status: CLOSED FIXED
Product: udk
Classification: Code
Component: code
OOO300m9
PC Windows, all
: P3 trivial (vote)
: OOo 3.1
Assigned To: joergbudi
issues@udk
:
: 87894 (view as issue list)
Depends on:
Blocks:
  Show dependency treegraph
 
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 on: ---
Developer Difficulty: ---


Attachments

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
<http://udk.openoffice.org/servlets/ReadMsg?list=dev&msgNo=4146> ("However,
when..."), with a workaround ("import socket") presented at
<http://udk.openoffice.org/servlets/ReadMsg?list=dev&msgNo=4147>.  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
Hi,

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
r1.30->1.31. 

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.). 

Bye,

Joerg
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
<http://wiki.services.openoffice.org/w/index.php?title=ODF_Toolkit/Efforts/OOo_without_URE&oldid=59459>
"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/uno.py@264034, 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 :
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues