pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Bugs-1799934 ] easy_install silently fails

[SourceForge.net <no...@so...>]

Bugs item #1799934, was opened at 2007-09-21 20:29
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: easy_install silently fails

Initial Comment:
If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works.

If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this:

$ python -c 'import win32process'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.


I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both.

Regards,

Zooko

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-12-03 12:07

Message:
Okay I just tested pywin32 212 with the latest trunk of setuptools
(0.6c10dev), and it worked!  However, the pywin32 package is not linked
from http://pypi.python.org/simple/pywin32 , so easy_install doesn't know
how to download it.  Please put a link on
http://pypi.python.org/simple/pywin32 pointing to the 212 binaries and this
ticket is done.

----------------------------------------------------------------------

Comment By: Hartmut Goebel (htgoebel)
Date: 2008-09-04 10:29

Message:
Logged In: YES 
user_id=376953
Originator: NO

There are actually two problems:

1) pywin32_postinstall.py can not be run manually when using eggs since it
does not use pkg_resources.

   This is fixed by patch 2092722
  
<http://sourceforge.net/tracker/index.php?func=detail&aid=2092722&group_id=78018&atid=551956>.

2) easy_install does not run pywin32_postinstall.py. It looks like there
is no mechanism to do this.

   This problem has been filed at
<http://bugs.python.org/setuptools/issue18>



----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-06-02 20:31

Message:
Logged In: YES 
user_id=52562
Originator: YES

This is the ticket on the setuptools issue tracker to track the progress
of fixing this in setuptools:

http://bugs.python.org/setuptools/issue18

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 01:30

Message:
Logged In: YES 
user_id=14198
Originator: NO

That installer is quite recent - you may need to get the latest setuptools
rather than the latest pywin32.  Either way, just grab the CVS sources,
install the Vista SDK, and execute "setup.py" - to get some basic
instructions printed.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-03 00:56

Message:
Logged In: YES 
user_id=52562
Originator: YES

Well, I'm afraid that
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe doesn't
work with the current setuptools -- setuptools v0.6 final.  Could you tell
me how to build pywin32 packages from CVS so I can experiment?  Thanks.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 00:39

Message:
Logged In: YES 
user_id=14198
Originator: NO

Try starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe.  Note
I'm not sure of the status of the bug I referred to - ie, I'm not sure if a
released version of setuptools has the bug fixed (but I assume you are
ontop of that :)

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-02 17:48

Message:
Logged In: YES 
user_id=52562
Originator: YES

Hi, I went to test this so I could definitely close this bug, but it turns
out that pywin32 build 211 isn't downloadable yet.


----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-23 02:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-04-08 21:20

Message:
Logged In: YES 
user_id=14198
Originator: NO

I believe PJE recently fixed a bug in setuptools that was causing problems
with pywin32 as an egg.  Please try again after build 211 is released.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-01-25 14:17

Message:
Logged In: YES 
user_id=52562
Originator: YES


See also:

http://mail.python.org/pipermail/distutils-sig/2007-July/007823.html


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-09-30 23:33

Message:
Logged In: YES 
user_id=14198
Originator: NO

I've no idea - that too is an easy_install question.  I've never used
easy_install to install pywin32, and I've never recommended anyone else do
it either.

----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2007-09-30 22:57

Message:
Logged In: YES 
user_id=52562
Originator: YES

I will see if I can make the pywin32_postinstall.py stuff get done
automatically upon easy_install.

In the meantime, is there some way to make this failure loud instead of
silent?  How do you tell easy_install: yes, there is a package in the
expected format (.zip) in the expected place (pypi), but it isn't actually
going to work?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-09-21 23:57

Message:
Logged In: YES 
user_id=14198
Originator: NO

After install, pywin32_postinstall.py needs to be run, but ezsetup
apparently does not provide a facility to do that.  You may like to ask
them for such a facility.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2370817 ] pywin32 doesn't compile on win xp

[SourceForge.net <no...@so...>]

Bugs item #2370817, was opened at 2008-12-01 14:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2370817&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32 doesn't compile on win xp

Initial Comment:
Due to many constants and missing functions that are only available on vista and not platform-checked.

eg:
win32/src/win32inetmodule.cpp(1381) : error C2065: 'INTERNET_OPTION_CODEPAGE_PATH' : undeclared identifier
win32/src/win32inetmodule.cpp(1381) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1382) : error C2065: 'INTERNET_OPTION_CODEPAGE_EXTRA' : undeclared identifier
win32/src/win32inetmodule.cpp(1382) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1390) : error C2065: 'INTERNET_OPTION_IDN' : undeclared identifier
win32/src/win32inetmodule.cpp(1390) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1402) : error C2065: 'INTERNET_OPTION_HTTP_DECODING' : undeclared identifier
win32/src/win32inetmodule.cpp(1402) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1582) : error C2065: 'INTERNET_OPTION_CODEPAGE_PATH' : undeclared identifier
win32/src/win32inetmodule.cpp(1582) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1583) : error C2065: 'INTERNET_OPTION_CODEPAGE_EXTRA' : undeclared identifier
win32/src/win32inetmodule.cpp(1583) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1589) : error C2065: 'INTERNET_OPTION_IDN' : undeclared identifier
win32/src/win32inetmodule.cpp(1589) : error C2051: case expression not constant
win32/src/win32inetmodule.cpp(1614) : error C2065: 'INTERNET_OPTION_HTTP_DECODING' : undeclared identifier
win32/src/win32inetmodule.cpp(1614) : error C2051: case expression not constant
error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2

or

win32\src\win32processmodule_win32.cpp(2604) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier
win32\src\win32processmodule_win32.cpp(2606) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier
error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2370817&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 13:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 13:37

Message:
Thanks for your patience - I see what you mean and can't argue with it
<wink>, so yeah, I'm inclined to agree its pretty good to go.  I'd like to
wait for Roger to respond if that's OK, but I'll do something before the
next release.

A minor nit, the format string with "OO:getaddrinfo" isn't correct - the
Python exception would report the error was in getaddrinfo, which it's not.
 An option would be to just parse the args once - the top format string
changes from a simple "O" for the addrinfo to a "(OO)", and the second
PyArg_ParseTuple can die.  I'm mentioning this mainly so I remember when
applying it (but obviously feel free to add a new patch:)

Thanks


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 13:17

Message:
I don't see any necessary changes to the patch as one can easily use as a
workaround the family-specific addresses from the sockaddr in the tuple
from getaddrinfo

suppose, some addrinfo_i_want in socket.getaddrinfo(*someaddr)

i would use:
win32file.ConnectEx(sock, addrinfo_i_want[4], overlap)

Am I missing something?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 12:26

Message:
How many families do you think we will need support for?  If we just use
AF_INET and maybe AF_INET6, and don't try to perform name resolution in
ConnectEx (ie, stick closer to the API itself rather than "adding value" on
top of it), then it seems the amount of code duplicated could indeed be
quite small - 20 lines or so - as those structures are simple to unpack. 
Would that be reasonable?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 11:47

Message:
getaddrinfo returns a tuple (family, socktype, proto, canonname, sockaddr).

sockaddr is the useful part here, that's what should be used (other parts
of the tuple do not make much sense, and it doesn't feel exactly brilliant
to implement an pattern matching algorithm over family/socktype/proto in a
mere ConnectEx call wrapper). It needs to be encoded in a sockaddr struct.

However, the encoding routine might just be the getaddrinfo we don't like
- since the address is in IP dotted address format, we'll get the exact
sockaddr we want.
Looking at the problem like this all this discussion looks like nonsense
since if you want control of whatever address family ConnectEx will use you
can just pass the real address instead of a hostname to ConnectEx.

I hope this clarifies things.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 11:28

Message:
Thanks for the clarification and update to the test.  It still looks like a
*lot* of code to duplicate, and code that will not be easy to keep
up-to-date given all the platform-specific #ifdef's we'd probably want to
remove.  If we can avoid that, with the only cost being that ConnectEx
takes one "unnatural" arg, I'm still leaning towards "practicality beats
purity" in this case.  ConnextEx is somewhat "unnatural" in its own right
anyway.

I'd like to make sure I understand though (I've never done much serious
socket work in case you can't tell ;) - the "unnatural" nature would
specifically mean the code would change from doing:

        win32file.ConnectEx(s2, self.addr, ol, "some expected request")
to something along the lines of:
        win32file.ConnectEx(s2, socket.getaddrinfo(*self.addr)[0], ol,
"some expected request")

Is that correct, or is there still something I'm missing?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 10:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 22:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 22:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-08 05:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 09:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 09:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 01:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 23:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 20:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 13:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: ionel (ionel_mc)
Date: 2008-12-01 04:17

Message:
I don't see any necessary changes to the patch as one can easily use as a
workaround the family-specific addresses from the sockaddr in the tuple
from getaddrinfo

suppose, some addrinfo_i_want in socket.getaddrinfo(*someaddr)

i would use:
win32file.ConnectEx(sock, addrinfo_i_want[4], overlap)

Am I missing something?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 03:26

Message:
How many families do you think we will need support for?  If we just use
AF_INET and maybe AF_INET6, and don't try to perform name resolution in
ConnectEx (ie, stick closer to the API itself rather than "adding value" on
top of it), then it seems the amount of code duplicated could indeed be
quite small - 20 lines or so - as those structures are simple to unpack. 
Would that be reasonable?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 02:47

Message:
getaddrinfo returns a tuple (family, socktype, proto, canonname, sockaddr).

sockaddr is the useful part here, that's what should be used (other parts
of the tuple do not make much sense, and it doesn't feel exactly brilliant
to implement an pattern matching algorithm over family/socktype/proto in a
mere ConnectEx call wrapper). It needs to be encoded in a sockaddr struct.

However, the encoding routine might just be the getaddrinfo we don't like
- since the address is in IP dotted address format, we'll get the exact
sockaddr we want.
Looking at the problem like this all this discussion looks like nonsense
since if you want control of whatever address family ConnectEx will use you
can just pass the real address instead of a hostname to ConnectEx.

I hope this clarifies things.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 02:28

Message:
Thanks for the clarification and update to the test.  It still looks like a
*lot* of code to duplicate, and code that will not be easy to keep
up-to-date given all the platform-specific #ifdef's we'd probably want to
remove.  If we can avoid that, with the only cost being that ConnectEx
takes one "unnatural" arg, I'm still leaning towards "practicality beats
purity" in this case.  ConnextEx is somewhat "unnatural" in its own right
anyway.

I'd like to make sure I understand though (I've never done much serious
socket work in case you can't tell ;) - the "unnatural" nature would
specifically mean the code would change from doing:

        win32file.ConnectEx(s2, self.addr, ol, "some expected request")
to something along the lines of:
        win32file.ConnectEx(s2, socket.getaddrinfo(*self.addr)[0], ol,
"some expected request")

Is that correct, or is there still something I'm missing?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 01:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 13:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 15:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 13:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 12:26

Message:
How many families do you think we will need support for?  If we just use
AF_INET and maybe AF_INET6, and don't try to perform name resolution in
ConnectEx (ie, stick closer to the API itself rather than "adding value" on
top of it), then it seems the amount of code duplicated could indeed be
quite small - 20 lines or so - as those structures are simple to unpack. 
Would that be reasonable?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 11:47

Message:
getaddrinfo returns a tuple (family, socktype, proto, canonname, sockaddr).

sockaddr is the useful part here, that's what should be used (other parts
of the tuple do not make much sense, and it doesn't feel exactly brilliant
to implement an pattern matching algorithm over family/socktype/proto in a
mere ConnectEx call wrapper). It needs to be encoded in a sockaddr struct.

However, the encoding routine might just be the getaddrinfo we don't like
- since the address is in IP dotted address format, we'll get the exact
sockaddr we want.
Looking at the problem like this all this discussion looks like nonsense
since if you want control of whatever address family ConnectEx will use you
can just pass the real address instead of a hostname to ConnectEx.

I hope this clarifies things.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 11:28

Message:
Thanks for the clarification and update to the test.  It still looks like a
*lot* of code to duplicate, and code that will not be easy to keep
up-to-date given all the platform-specific #ifdef's we'd probably want to
remove.  If we can avoid that, with the only cost being that ConnectEx
takes one "unnatural" arg, I'm still leaning towards "practicality beats
purity" in this case.  ConnextEx is somewhat "unnatural" in its own right
anyway.

I'd like to make sure I understand though (I've never done much serious
socket work in case you can't tell ;) - the "unnatural" nature would
specifically mean the code would change from doing:

        win32file.ConnectEx(s2, self.addr, ol, "some expected request")
to something along the lines of:
        win32file.ConnectEx(s2, socket.getaddrinfo(*self.addr)[0], ol,
"some expected request")

Is that correct, or is there still something I'm missing?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 10:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 22:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 22:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-08 05:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 09:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 09:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 01:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 23:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 20:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 13:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: ionel (ionel_mc)
Date: 2008-12-01 02:47

Message:
getaddrinfo returns a tuple (family, socktype, proto, canonname, sockaddr).

sockaddr is the useful part here, that's what should be used (other parts
of the tuple do not make much sense, and it doesn't feel exactly brilliant
to implement an pattern matching algorithm over family/socktype/proto in a
mere ConnectEx call wrapper). It needs to be encoded in a sockaddr struct.

However, the encoding routine might just be the getaddrinfo we don't like
- since the address is in IP dotted address format, we'll get the exact
sockaddr we want.
Looking at the problem like this all this discussion looks like nonsense
since if you want control of whatever address family ConnectEx will use you
can just pass the real address instead of a hostname to ConnectEx.

I hope this clarifies things.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 02:28

Message:
Thanks for the clarification and update to the test.  It still looks like a
*lot* of code to duplicate, and code that will not be easy to keep
up-to-date given all the platform-specific #ifdef's we'd probably want to
remove.  If we can avoid that, with the only cost being that ConnectEx
takes one "unnatural" arg, I'm still leaning towards "practicality beats
purity" in this case.  ConnextEx is somewhat "unnatural" in its own right
anyway.

I'd like to make sure I understand though (I've never done much serious
socket work in case you can't tell ;) - the "unnatural" nature would
specifically mean the code would change from doing:

        win32file.ConnectEx(s2, self.addr, ol, "some expected request")
to something along the lines of:
        win32file.ConnectEx(s2, socket.getaddrinfo(*self.addr)[0], ol,
"some expected request")

Is that correct, or is there still something I'm missing?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 01:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 13:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 15:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 13:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 11:28

Message:
Thanks for the clarification and update to the test.  It still looks like a
*lot* of code to duplicate, and code that will not be easy to keep
up-to-date given all the platform-specific #ifdef's we'd probably want to
remove.  If we can avoid that, with the only cost being that ConnectEx
takes one "unnatural" arg, I'm still leaning towards "practicality beats
purity" in this case.  ConnextEx is somewhat "unnatural" in its own right
anyway.

I'd like to make sure I understand though (I've never done much serious
socket work in case you can't tell ;) - the "unnatural" nature would
specifically mean the code would change from doing:

        win32file.ConnectEx(s2, self.addr, ol, "some expected request")
to something along the lines of:
        win32file.ConnectEx(s2, socket.getaddrinfo(*self.addr)[0], ol,
"some expected request")

Is that correct, or is there still something I'm missing?

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 10:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 10:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 22:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 22:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-08 05:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 09:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 09:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 01:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 23:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 20:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 13:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:49

Message:
No, I don't mean borrow the getaddrinfo implementation in the python socket
module, rather reuse the getsockaddrarg implementation in socketmodule.c
and keep functionality in line with whatever is in the python standard
library. I don't see anywhere in the socket module any connect method that
takes a sockaddr struct as an argument so all this idea of passing a
sockaddr of your own choosing seems unnatural.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 01:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 13:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 15:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: ionel (ionel_mc)
Date: 2008-12-01 01:43

Message:
File Added: test_connectex.py

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 01:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 13:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 15:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 13:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-12-01 10:39

Message:
Even if you borrowed Python's getaddrinfo, wouldn't you still be in the
situation that Roger mentions - getaddrinfo() natively returns a pointer to
a linked list, while Python's implementation returns a Python list - which
binding in either of the lists are you going to use?  It appears you will
always use the first?

getaddrinfo() returns a list of tuples, which each tuple being fairly
simple to unpack (ints and strings IIUC).  So if you just accept one of
these tuples it should be quite easy to unpack this into an addrinfo struct
- just a few lines, and much simpler than either the current code or trying
to borrow and adapt Python's implementation.

I was about to have a go at modifying your patch to do that (there might
be something I don't understand, so that was the best way to find out :),
but then noticed that there seems to be no test for ConnectEx() - do you
have any code available we can use as a test case for that?  Otherwise it
will be impossible for me to verify it actually works.

Thanks

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-11-24 22:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 22:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-08 05:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 09:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 09:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 04:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-14 01:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 23:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 20:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 13:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

[SourceForge.net <no...@so...>]

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

----------------------------------------------------------------------

>Comment By: ionel (ionel_mc)
Date: 2008-11-24 13:46

Message:
I would rather not do that - too much parameter grunt work.

I would rather get the getsockaddrarg implementation from the python's
socketmodule and plug it in here. What do you think ?


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-25 15:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

----------------------------------------------------------------------

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2319977 ] Dead docu links

[SourceForge.net <no...@so...>]

Bugs item #2319977, was opened at 2008-11-21 10:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2319977&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: struppimoppi (struppimoppi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dead docu links

Initial Comment:
The links at http://starship.python.net/crew/mhammond/win32/ in the section

"""
There is also some (old) documentation you may like to check out. For some details on Pythonwin (including embedding it in your own MFC application and some MFC concepts) see http://www.python.org/windows/pythonwin/. For some overviews of the Win32 API as exposed to Python, see http://www.python.org/windows/win32/
"""

are dead.

Searching for "win32" at python.org brings up http://www.python.org/ftp/python/win32/ which just says

"""
Do yourself a favor and pick up a newer Python download for Windows!

Go to http://www.python.org/download/ for the latest versions.
"""

Not very helpfull too.

Is there win32 API doc online somewhere?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2319977&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2318014 ] inproc server cannot find pythoncom25.dll

[SourceForge.net <no...@so...>]

Bugs item #2318014, was opened at 2008-11-20 17:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2318014&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas Sodeur (andreas_sodeur)
Assigned to: Nobody/Anonymous (nobody)
Summary: inproc server cannot find pythoncom25.dll

Initial Comment:
I am using an automation add-in for Excel implemented in Python. Excel cannot locate pythoncom25.dll unless the registry key {CLSID}\InprocServer32 contains the full pathname of pythoncom25.dll.

It looks like changing line 210 in win32com\server\register.py to:
dllName = pythoncom.__file__ 
will fix the problem. However I am not sure if this will cause problems elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2318014&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2310121 ] GetDlgItemText fails with no contents

[SourceForge.net <no...@so...>]

Bugs item #2310121, was opened at 2008-11-18 17:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Golden (tjgolden)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetDlgItemText fails with no contents

Initial Comment:
win32gui.GetDlgItemText returns an error if there is nothing in the control in question. I'm not sure if this is "correct" (since the docs say that zero is returned on failure) but I can't see how else to determine that the control has no contents.

I can work around the issue by catching the exception and assuming that there are no contents.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2303797 ] PythonService.exe working under Python 2.5.2 but not 2.6

[SourceForge.net <no...@so...>]

Bugs item #2303797, was opened at 2008-11-17 18:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2303797&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Python Nutter (pythonnutter)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonService.exe working under Python 2.5.2 but not 2.6

Initial Comment:
I have done a PythonService.exe /register

Under Python 2.5.2 (with Stackless) and gone through all the Python script as a service scripts in M.H's book and on the net.

They install and start/stop and remove with no problems when I am using Python 2.5.2 on Windows XP.

When I use Python 2.6 and do a PythonService.exe /register under Python 2.6 I have no errors.

When I then do a service install it installs the service. However when I try to start the service I get the familiar 'red herring' error message that is basically a message saying that the service has not responded in time and could not start.

Using standard windows net start commands on the service name says the service is failing to respond to commands sent to it to start.

Switching back to Python 2.5.2 on the same machine and the same exact python as service scripts load, start, stop, and remove just fine with no errors.

I'm completely stumped on this one. I can not get any python scripts to load and run as services when using Python 2.6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2303797&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2279538 ] win32com.mapi.exchange missing in 212

[SourceForge.net <no...@so...>]

Bugs item #2279538, was opened at 2008-11-14 10:44
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32com.mapi.exchange missing in 212

Initial Comment:
If I install 211 on a machine that has never had pywin32 installed before, the exchange.pyd and exchdapi.pyd files are not installed.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-11-14 11:52

Message:
Hi Tony,
  The problem is the SDKs are moving so quickly I've lost the ability to
build them currently.   I think its just a matter of me downloading the
exchange SDK in whatever form that comes in these days.  You are the first
to have complained so far :)

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2008-11-14 11:07

Message:
Hmm.  Actually, if I go back to the oldest 2.4 version I can find I don't
get these installed.  So now I don't know how I got them in the first place
(unless it was running a special build Mark gave me at some point).

Maybe this is therefore not valid.  I see that the .i file is still in
CVS, so maybe it is.  Apologies if this is not a real issue!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2279538 ] win32com.mapi.exchange missing in 212

[SourceForge.net <no...@so...>]

Bugs item #2279538, was opened at 2008-11-14 12:44
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32com.mapi.exchange missing in 212

Initial Comment:
If I install 211 on a machine that has never had pywin32 installed before, the exchange.pyd and exchdapi.pyd files are not installed.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2008-11-14 13:07

Message:
Hmm.  Actually, if I go back to the oldest 2.4 version I can find I don't
get these installed.  So now I don't know how I got them in the first place
(unless it was running a special build Mark gave me at some point).

Maybe this is therefore not valid.  I see that the .i file is still in
CVS, so maybe it is.  Apologies if this is not a real issue!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2279538 ] win32com.mapi.exchange missing in 212

[SourceForge.net <no...@so...>]

Bugs item #2279538, was opened at 2008-11-14 12:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32com.mapi.exchange missing in 212

Initial Comment:
If I install 211 on a machine that has never had pywin32 installed before, the exchange.pyd and exchdapi.pyd files are not installed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2279538&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2271571 ] Browse PythonPath fails

[SourceForge.net <no...@so...>]

Bugs item #2271571, was opened at 2008-11-12 20:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2271571&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Richard Stockford (rstockford)
Assigned to: Nobody/Anonymous (nobody)
Summary: Browse PythonPath fails

Initial Comment:
With Python 2.5.2 and PyWin 2.5.2, both installed cleanly on a new XP SP2 machine, everything works as before except Browse PythonPath on the PyWin Tools menu, which gives the following error.  (Edit Python Path produces a blank screen also.)

>>> Failed to execute command:
from pywin.tools import browseProjects;browseProjects.Browse()
Traceback (most recent call last):
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line 103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in <module>
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\browseProjects.py", line 251, in DockablePathBrowser
    bar.CreateWindow(win32ui.GetMainFrame(), DockableBrowserCreator, "Path Browser", 0x8e0a)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\docking\DockingBar.py", line 72, in CreateWindow
    self.dialog = apply(childCreator, (self,) + childCreatorArgs)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\browseProjects.py", line 245, in DockableBrowserCreator
    list = hl.HierInit (parent, control)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 93, in HierInit
    self.AcceptRoot(self.root)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 221, in AcceptRoot
    subItems = self.GetSubList(root)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 269, in GetSubList
    return self.DelegateCall(item.GetSubList)
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 256, in DelegateCall
    return fn()
  File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\browseProjects.py", line 178, in GetSubList
    hKey = win32api.RegOpenKey(regutil.GetRootKey(), keyStr)
error: (2, 'RegOpenKeyEx', 'The system cannot find the file specified.')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2271571&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-12 05:01
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
Assigned to: Mark Hammond (mhammond)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack!

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-11-11 11:02

Message:
Thanks guys!

Checking in win32timezone.py; new revision: 1.10; previous revision: 1.9
Checking in win32timezone.py; new revision: 1.11; previous revision: 1.10


----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-11-07 07:40

Message:
Thanks to Antoine for testing the changes.

Mark, can you check in the changes?  I've included two patches, the first
which just cleans up whitespace.  The second addresses the issue in this
bug and deprecates several functions (while attempting to maintain backward
compatibility).  You're welcome to just apply changes together, but it will
be a cleaner CVS history if the patches are committed separately.

----------------------------------------------------------------------

Comment By: Antoine LECA (antoinel)
Date: 2008-11-07 07:00

Message:
OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4
server I am still using (but we are talking about retirement). Of course
now I have to deal with the fact the strings I got on this box are
Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY
problem.

Thanks again, and hope it will fly many years. 

Notes for the report: this server has pywin32 v.210 running on Python 2.5.
I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and
it works OK.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-25 08:14

Message:
Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias
for the default sort order.  I think this new version should be a drop-in
replacement for most users.  It works for me in Windows Vista.  Can you
test it in your NT4 environment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-11 13:01
Message generated for change (Settings changed) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
>Assigned to: Mark Hammond (mhammond)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack!

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-11-06 15:40

Message:
Thanks to Antoine for testing the changes.

Mark, can you check in the changes?  I've included two patches, the first
which just cleans up whitespace.  The second addresses the issue in this
bug and deprecates several functions (while attempting to maintain backward
compatibility).  You're welcome to just apply changes together, but it will
be a cleaner CVS history if the patches are committed separately.

----------------------------------------------------------------------

Comment By: Antoine LECA (antoinel)
Date: 2008-11-06 15:00

Message:
OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4
server I am still using (but we are talking about retirement). Of course
now I have to deal with the fact the strings I got on this box are
Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY
problem.

Thanks again, and hope it will fly many years. 

Notes for the report: this server has pywin32 v.210 running on Python 2.5.
I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and
it works OK.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-24 17:14

Message:
Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias
for the default sort order.  I think this new version should be a drop-in
replacement for most users.  It works for me in Windows Vista.  Can you
test it in your NT4 environment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-11 13:01
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
Assigned to: Jason R. Coombs (jaraco)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack!

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-11-06 15:40

Message:
Thanks to Antoine for testing the changes.

Mark, can you check in the changes?  I've included two patches, the first
which just cleans up whitespace.  The second addresses the issue in this
bug and deprecates several functions (while attempting to maintain backward
compatibility).  You're welcome to just apply changes together, but it will
be a cleaner CVS history if the patches are committed separately.

----------------------------------------------------------------------

Comment By: Antoine LECA (antoinel)
Date: 2008-11-06 15:00

Message:
OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4
server I am still using (but we are talking about retirement). Of course
now I have to deal with the fact the strings I got on this box are
Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY
problem.

Thanks again, and hope it will fly many years. 

Notes for the report: this server has pywin32 v.210 running on Python 2.5.
I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and
it works OK.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-24 17:14

Message:
Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias
for the default sort order.  I think this new version should be a drop-in
replacement for most users.  It works for me in Windows Vista.  Can you
test it in your NT4 environment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-11 19:01
Message generated for change (Comment added) made by antoinel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
Assigned to: Jason R. Coombs (jaraco)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack!

----------------------------------------------------------------------

>Comment By: Antoine LECA (antoinel)
Date: 2008-11-06 21:00

Message:
OK, great job Jason, now it works perfectly on this great 'ld Spanish NT4
server I am still using (but we are talking about retirement). Of course
now I have to deal with the fact the strings I got on this box are
Unicode'd, with plently of beautiful accentuated vowels :-), but that is MY
problem.

Thanks again, and hope it will fly many years. 

Notes for the report: this server has pywin32 v.210 running on Python 2.5.
I just dropped the win32timezone.py inside win32lib, masked the .py[oc] and
it works OK.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-24 23:14

Message:
Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias
for the default sort order.  I think this new version should be a drop-in
replacement for most users.  It works for me in Windows Vista.  Can you
test it in your NT4 environment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2227431 ] Debugger don't reinitialize on new debug session

[SourceForge.net <no...@so...>]

Bugs item #2227431, was opened at 2008-11-06 12:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2227431&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Florin Jurca (flojur)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger don't reinitialize on new debug session

Initial Comment:
Debugger don't reinitialize on new debug session

pywin32-212.win32-py2.5.exe on python-2.5.2.msi
packages

Debugger if detect an error in the first debug session do not reinitialize for all future next debug sessions. Still raise same error even if the error it is fixed in the script.

The editor must be closed and opened again. 

The error is showing with regularity with no exceptions.

It is very disturbing to work as if I have only one legg when I try to go up on some scale.

Please help me with a solution if it is not a bug or if it is allready exist a solution for this.

Thanks a lot.

flo...@gm...

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-11-06 12:46

Message:
This is due to pythonwin running scripts in the same process.  The same
issue applies when running without the debugger.  You need to 'reload' the
changed modules - see documentation for Python's reload() function.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2227431&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2227431 ] Debugger don't reinitialize on new debug session

[SourceForge.net <no...@so...>]

Bugs item #2227431, was opened at 2008-11-06 03:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2227431&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Florin Jurca (flojur)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger don't reinitialize on new debug session

Initial Comment:
Debugger don't reinitialize on new debug session

pywin32-212.win32-py2.5.exe on python-2.5.2.msi
packages

Debugger if detect an error in the first debug session do not reinitialize for all future next debug sessions. Still raise same error even if the error it is fixed in the script.

The editor must be closed and opened again. 

The error is showing with regularity with no exceptions.

It is very disturbing to work as if I have only one legg when I try to go up on some scale.

Please help me with a solution if it is not a bug or if it is allready exist a solution for this.

Thanks a lot.

flo...@gm...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2227431&group_id=78018