Issue 95028

Summary:	python.exe does not call WSAStartup
Product:	udk	Reporter:	Stephan Bergmann <stephan.bergmann.secondary>
Component:	code	Assignee:	joergbudi
Status:	CLOSED FIXED	QA Contact:	issues@udk <issues>
Severity:	Trivial
Priority:	P3	CC:	ahz001, issues, joergbudi
Version:	OOO300m9
Target Milestone:	OOo 3.1
Hardware:	PC
OS:	Windows, all
Issue Type:	DEFECT	Latest Confirmation in:	---
Developer Difficulty:	---

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