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

[pywin32-bugs] [ pywin32-Bugs-2391931 ] I wrote a COM server that is work in python 2.5 but not 2.6

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

Bugs item #2391931, was opened at 2008-12-05 18:27
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2391931&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Ricky Teng (rickyteng)
Assigned to: Nobody/Anonymous (nobody)
Summary: I wrote a COM server that is work in python 2.5 but not 2.6

Initial Comment:
Hi,

I wrote a COM server can be called by VB exe.
I wrote the COM server in python 2.5 and pywin32-212.win32-py2.5.exe.

When I change python to 2.6 and pywin32-212.win32-py2.6.exe, register the COM server I wrote. The error message is :

------------
Run-Time error '-2147024770 (8007007e)':

Automation error
The specified module could not be found
------------

But I roll back to python 2.5 and pywin32-212.win32-py2.5.exe, everything is ok.

The code of COM server I wrote is copy from "A Quick Start to Server Side COM"

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-01-31 10:24

Message:
You need to install a global copy of the MSVC2008 assemblies from Microsoft
for this to work.

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

Comment By: Ricky Teng (rickyteng)
Date: 2008-12-05 18:32

Message:
I forgot to say that I can use python as COM client to call the COM server.
No matter python 2.5 or 2.6

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

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

[pywin32-bugs] [ pywin32-Bugs-2488784 ] Unicode exception when using ie.Navigate after dispatch

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

Bugs item #2488784, was opened at 2009-01-06 08:11
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&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: Mounir (merrami)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode exception when using ie.Navigate after dispatch

Initial Comment:
The situation: When using a IE browser after dispatch and navigating to a particular URL, the exception at the end of this note is observed
Important information: this is from the user of a commercial python program (provided as an executable) called CiteSmart. The error is observed very likely because th user is using a Corean version of Windows XP. This bug couldn't be reproduced on an english plate-form.

> Traceback (most recent call last):
> File "win32com\server\policy.pyo", line 285, in _Invoke_
> File "win32com\server\policy.pyo", line 290, in _invoke_
> File "win32com\server\policy.pyo", line 658, in _invokeex_
> File "win32com\server\policy.pyo", line 653, in
> _transform_args_
> : 'ascii' codec can't encode
> characters in position 0-1: ordinal not in

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-01-31 10:22

Message:
This is very strange.  That error seems to be:

            elif not core_has_unicode and arg_type==UnicodeType:
                arg = str(arg)

and 'core_has_unicode' should *always* be True in recent builds.  What
version of Python are you using?  Can you please confirm that line 653 in
your transform.py does point at that code?

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

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

[pywin32-bugs] [ pywin32-Bugs-2496107 ] crash on File -> Open... (build 212)

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

Bugs item #2496107, was opened at 2009-01-10 04:04
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2496107&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on File -> Open... (build 212)

Initial Comment:
I just upgraded from Python 2.5 to 2.6.1 (I had also been using 2.6b2), and installed pywin32 build 212 for py2.6. At first, I elected not to Register Extensions, but then after some errors in Pythonwin (looking for some files in my Python25 dir and some in my Python26 dir), I re-ran the installer and changed it to Register Extensions. Ditto for Python 2.6--I made it the default Python. I'm on Vista (with most of the Avalon crap disabled).

Now, when I start Pythonwin.exe, and click either the "Open" toolbar button or select "File...Open" from the menu, Pythonwin immediately crashes without even showing the file selection dialog. Debug info:

Unhandled exception at 0x1e006c6d in Pythonwin.exe: 0xC0000005: Access violation reading location 0x00000004.

VS2003 jumped to "void * __cdecl _heap_alloc_base (size_t size)" in malloc.c. Here's the call stack:

 	python26.dll!1e006c6d() 	
 	win32ui.pyd!1e2bfc70() 	
 	win32ui.pyd!030031a8() 	
 	ntdll.dll!7756878a() 	
 	ntdll.dll!7752ec7e() 	
 	ntdll.dll!77562d96() 	
 	ntdll.dll!7752ec63() 	
>	msvcr71.dll!_heap_alloc(unsigned int size=2002134087)  Line 212 + 0x5	C
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562447() 	
 	ntdll.dll!7753c4d1() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!7753c652() 	
 	ntdll.dll!7756214c() 	
 	ntdll.dll!7756523f() 	
 	ntdll.dll!77565244() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561c21() 	
 	ntdll.dll!7756526c() 	
 	advapi32.dll!76180f7a() 	
 	advapi32.dll!76180efc() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	mfc71.dll!7c1de203() 	
 	win32ui.pyd!03003212() 	
 	win32ui.pyd!0300349d() 	
 	win32ui.pyd!0303f31b() 	
 	python25.dll!027af402() 	
 	python25.dll!027b0989() 	
 	python25.dll!0272a83d() 	
 	python25.dll!027c3217() 	
 	python25.dll!0272c1f2() 	
 	python25.dll!02752966() 	
 	python25.dll!027aed07() 	
 	python25.dll!027544a5() 	
 	python25.dll!0276cf6a() 	
 	python25.dll!0276cfa6() 	
 	python25.dll!0276abdf() 	
 	python25.dll!0277e137() 	
 	python25.dll!0272ad92() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!02729b9e() 	
 	python25.dll!0272ae02() 	
 	python25.dll!0272c5c1() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!0272dcdd() 	
 	python25.dll!0272dd42() 	
 	python25.dll!02769b22() 	
 	python25.dll!027dc52a() 	
 	python25.dll!0277e137() 	
 	python25.dll!027166dc() 	
 	python25.dll!02716786() 	
 	python25.dll!02716928() 	
 	python25.dll!0276bcb9() 	
 	python25.dll!0276be07() 	
 	python25.dll!027512d8() 	
 	python25.dll!027cbb8d() 	
 	python25.dll!02752680() 	
 	python25.dll!027525c3() 	
 	python25.dll!02752966() 	
 	python25.dll!0276c466() 	
 	python25.dll!0276c499() 	
 	python25.dll!0276c7ee() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!775616dc() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	kernel32.dll!771e7a7e() 	
 	msvcr71.dll!_heap_alloc(unsigned int size=45944068)  Line 212	C
 	msvcr71.dll!_heap_alloc(unsigned int size=)  Line 212 + 0x5	C

Why would pythonwin for 2.6 be calling python25.dll? Sadly, I'm not the C debugger I used to be (and don't have the patience for a debug build of Python), but I notice the "original symbol location" for the python25.dll is "c:\trentm\as\ActivePython-devel\build\py2_5_1-win32-x86-apy25-rrun\python\PCbuild\python25.pdb" and for win32ui.pyd just above that, it's "O:\src\pywin32\build\temp.win32-2.5\Release\win32ui.pdb". The calls above that seem to be OK.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-01-31 10:17

Message:
not much we can do about this I'm afraid.

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

Comment By: Robert Brewer (aminusfu)
Date: 2009-01-10 11:52

Message:
That was almost certainly the culprit. I had installed TortoiseHg
yesterday, which as far as I can tell, uses Python for its shell
extensions. Removing that made Pythonwin work just fine. :) Thanks!

I'll let you decide whether this could be mitigated in pywin32 or
not...and whether to close this ticket.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-01-10 10:24

Message:
It appears you have a shell extension, implemented using Python 2.5
installed.  Is that possible?

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

Comment By: Robert Brewer (aminusfu)
Date: 2009-01-10 04:07

Message:
By the way, I can open a file into Pythonwin by right-click, "Edit with
Pythonwin". Choosing a recent file works too, e.g.: "File -> 1.
threading.py". But the Open button still crashes.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2496107&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: Closed
>Resolution: Fixed
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: 2009-01-26 10:52

Message:
Thank you both!

Checking in win32/src/win32file.i;
new revision: 1.98; previous revision: 1.97
Checking in win32/test/test_win32file.py;
new revision: 1.28; previous revision: 1.27


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

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-Bugs-2523837 ] pywin32 installation error

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

Bugs item #2523837, was opened at 2009-01-20 09:49
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=2523837&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: Kevin Thomas (chalawu)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32 installation error

Initial Comment:
I have installed python 2.5.1 and I am receiving an installation error while trying to install pywin32-212.win32-py2.5.  

The error reported is.

Setup pywin32-212:pywin32-212.win32-py2.5.exe - entry point not found
The procedure entry point ?PyWinObject_AsHANDLE@@YAHPAU_object@@PAPAXH@Z could not be located in the dynamic link library pywintypes 25.dll

As suggested I searched for duplicates of pythonxx.dll, pywintypesxx.dll, or pythoncomxx.dll and removed any dups not within the system32 directory. I am running WindowsXP.

Thanks in advance for any suggestions!
Kevin



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

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

[pywin32-bugs] [ pywin32-Bugs-2496107 ] crash on File -> Open... (build 212)

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

Bugs item #2496107, was opened at 2009-01-09 17:04
Message generated for change (Comment added) made by aminusfu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2496107&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on File -> Open... (build 212)

Initial Comment:
I just upgraded from Python 2.5 to 2.6.1 (I had also been using 2.6b2), and installed pywin32 build 212 for py2.6. At first, I elected not to Register Extensions, but then after some errors in Pythonwin (looking for some files in my Python25 dir and some in my Python26 dir), I re-ran the installer and changed it to Register Extensions. Ditto for Python 2.6--I made it the default Python. I'm on Vista (with most of the Avalon crap disabled).

Now, when I start Pythonwin.exe, and click either the "Open" toolbar button or select "File...Open" from the menu, Pythonwin immediately crashes without even showing the file selection dialog. Debug info:

Unhandled exception at 0x1e006c6d in Pythonwin.exe: 0xC0000005: Access violation reading location 0x00000004.

VS2003 jumped to "void * __cdecl _heap_alloc_base (size_t size)" in malloc.c. Here's the call stack:

 	python26.dll!1e006c6d() 	
 	win32ui.pyd!1e2bfc70() 	
 	win32ui.pyd!030031a8() 	
 	ntdll.dll!7756878a() 	
 	ntdll.dll!7752ec7e() 	
 	ntdll.dll!77562d96() 	
 	ntdll.dll!7752ec63() 	
>	msvcr71.dll!_heap_alloc(unsigned int size=2002134087)  Line 212 + 0x5	C
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562447() 	
 	ntdll.dll!7753c4d1() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!7753c652() 	
 	ntdll.dll!7756214c() 	
 	ntdll.dll!7756523f() 	
 	ntdll.dll!77565244() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561c21() 	
 	ntdll.dll!7756526c() 	
 	advapi32.dll!76180f7a() 	
 	advapi32.dll!76180efc() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	mfc71.dll!7c1de203() 	
 	win32ui.pyd!03003212() 	
 	win32ui.pyd!0300349d() 	
 	win32ui.pyd!0303f31b() 	
 	python25.dll!027af402() 	
 	python25.dll!027b0989() 	
 	python25.dll!0272a83d() 	
 	python25.dll!027c3217() 	
 	python25.dll!0272c1f2() 	
 	python25.dll!02752966() 	
 	python25.dll!027aed07() 	
 	python25.dll!027544a5() 	
 	python25.dll!0276cf6a() 	
 	python25.dll!0276cfa6() 	
 	python25.dll!0276abdf() 	
 	python25.dll!0277e137() 	
 	python25.dll!0272ad92() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!02729b9e() 	
 	python25.dll!0272ae02() 	
 	python25.dll!0272c5c1() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!0272dcdd() 	
 	python25.dll!0272dd42() 	
 	python25.dll!02769b22() 	
 	python25.dll!027dc52a() 	
 	python25.dll!0277e137() 	
 	python25.dll!027166dc() 	
 	python25.dll!02716786() 	
 	python25.dll!02716928() 	
 	python25.dll!0276bcb9() 	
 	python25.dll!0276be07() 	
 	python25.dll!027512d8() 	
 	python25.dll!027cbb8d() 	
 	python25.dll!02752680() 	
 	python25.dll!027525c3() 	
 	python25.dll!02752966() 	
 	python25.dll!0276c466() 	
 	python25.dll!0276c499() 	
 	python25.dll!0276c7ee() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!775616dc() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	kernel32.dll!771e7a7e() 	
 	msvcr71.dll!_heap_alloc(unsigned int size=45944068)  Line 212	C
 	msvcr71.dll!_heap_alloc(unsigned int size=)  Line 212 + 0x5	C

Why would pythonwin for 2.6 be calling python25.dll? Sadly, I'm not the C debugger I used to be (and don't have the patience for a debug build of Python), but I notice the "original symbol location" for the python25.dll is "c:\trentm\as\ActivePython-devel\build\py2_5_1-win32-x86-apy25-rrun\python\PCbuild\python25.pdb" and for win32ui.pyd just above that, it's "O:\src\pywin32\build\temp.win32-2.5\Release\win32ui.pdb". The calls above that seem to be OK.

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

>Comment By: Robert Brewer (aminusfu)
Date: 2009-01-10 00:52

Message:
That was almost certainly the culprit. I had installed TortoiseHg
yesterday, which as far as I can tell, uses Python for its shell
extensions. Removing that made Pythonwin work just fine. :) Thanks!

I'll let you decide whether this could be mitigated in pywin32 or
not...and whether to close this ticket.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-01-09 23:24

Message:
It appears you have a shell extension, implemented using Python 2.5
installed.  Is that possible?

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

Comment By: Robert Brewer (aminusfu)
Date: 2009-01-09 17:07

Message:
By the way, I can open a file into Pythonwin by right-click, "Edit with
Pythonwin". Choosing a recent file works too, e.g.: "File -> 1.
threading.py". But the Open button still crashes.

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

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

[pywin32-bugs] [ pywin32-Bugs-2496107 ] crash on File -> Open... (build 212)

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

Bugs item #2496107, was opened at 2009-01-10 04:04
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2496107&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on File -> Open... (build 212)

Initial Comment:
I just upgraded from Python 2.5 to 2.6.1 (I had also been using 2.6b2), and installed pywin32 build 212 for py2.6. At first, I elected not to Register Extensions, but then after some errors in Pythonwin (looking for some files in my Python25 dir and some in my Python26 dir), I re-ran the installer and changed it to Register Extensions. Ditto for Python 2.6--I made it the default Python. I'm on Vista (with most of the Avalon crap disabled).

Now, when I start Pythonwin.exe, and click either the "Open" toolbar button or select "File...Open" from the menu, Pythonwin immediately crashes without even showing the file selection dialog. Debug info:

Unhandled exception at 0x1e006c6d in Pythonwin.exe: 0xC0000005: Access violation reading location 0x00000004.

VS2003 jumped to "void * __cdecl _heap_alloc_base (size_t size)" in malloc.c. Here's the call stack:

 	python26.dll!1e006c6d() 	
 	win32ui.pyd!1e2bfc70() 	
 	win32ui.pyd!030031a8() 	
 	ntdll.dll!7756878a() 	
 	ntdll.dll!7752ec7e() 	
 	ntdll.dll!77562d96() 	
 	ntdll.dll!7752ec63() 	
>	msvcr71.dll!_heap_alloc(unsigned int size=2002134087)  Line 212 + 0x5	C
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562447() 	
 	ntdll.dll!7753c4d1() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!7753c652() 	
 	ntdll.dll!7756214c() 	
 	ntdll.dll!7756523f() 	
 	ntdll.dll!77565244() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561c21() 	
 	ntdll.dll!7756526c() 	
 	advapi32.dll!76180f7a() 	
 	advapi32.dll!76180efc() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	mfc71.dll!7c1de203() 	
 	win32ui.pyd!03003212() 	
 	win32ui.pyd!0300349d() 	
 	win32ui.pyd!0303f31b() 	
 	python25.dll!027af402() 	
 	python25.dll!027b0989() 	
 	python25.dll!0272a83d() 	
 	python25.dll!027c3217() 	
 	python25.dll!0272c1f2() 	
 	python25.dll!02752966() 	
 	python25.dll!027aed07() 	
 	python25.dll!027544a5() 	
 	python25.dll!0276cf6a() 	
 	python25.dll!0276cfa6() 	
 	python25.dll!0276abdf() 	
 	python25.dll!0277e137() 	
 	python25.dll!0272ad92() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!02729b9e() 	
 	python25.dll!0272ae02() 	
 	python25.dll!0272c5c1() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!0272dcdd() 	
 	python25.dll!0272dd42() 	
 	python25.dll!02769b22() 	
 	python25.dll!027dc52a() 	
 	python25.dll!0277e137() 	
 	python25.dll!027166dc() 	
 	python25.dll!02716786() 	
 	python25.dll!02716928() 	
 	python25.dll!0276bcb9() 	
 	python25.dll!0276be07() 	
 	python25.dll!027512d8() 	
 	python25.dll!027cbb8d() 	
 	python25.dll!02752680() 	
 	python25.dll!027525c3() 	
 	python25.dll!02752966() 	
 	python25.dll!0276c466() 	
 	python25.dll!0276c499() 	
 	python25.dll!0276c7ee() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!775616dc() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	kernel32.dll!771e7a7e() 	
 	msvcr71.dll!_heap_alloc(unsigned int size=45944068)  Line 212	C
 	msvcr71.dll!_heap_alloc(unsigned int size=)  Line 212 + 0x5	C

Why would pythonwin for 2.6 be calling python25.dll? Sadly, I'm not the C debugger I used to be (and don't have the patience for a debug build of Python), but I notice the "original symbol location" for the python25.dll is "c:\trentm\as\ActivePython-devel\build\py2_5_1-win32-x86-apy25-rrun\python\PCbuild\python25.pdb" and for win32ui.pyd just above that, it's "O:\src\pywin32\build\temp.win32-2.5\Release\win32ui.pdb". The calls above that seem to be OK.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-01-10 10:24

Message:
It appears you have a shell extension, implemented using Python 2.5
installed.  Is that possible?

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

Comment By: Robert Brewer (aminusfu)
Date: 2009-01-10 04:07

Message:
By the way, I can open a file into Pythonwin by right-click, "Edit with
Pythonwin". Choosing a recent file works too, e.g.: "File -> 1.
threading.py". But the Open button still crashes.

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

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

[pywin32-bugs] [ pywin32-Bugs-2496107 ] crash on File -> Open... (build 212)

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

Bugs item #2496107, was opened at 2009-01-09 17:04
Message generated for change (Comment added) made by aminusfu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2496107&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on File -> Open... (build 212)

Initial Comment:
I just upgraded from Python 2.5 to 2.6.1 (I had also been using 2.6b2), and installed pywin32 build 212 for py2.6. At first, I elected not to Register Extensions, but then after some errors in Pythonwin (looking for some files in my Python25 dir and some in my Python26 dir), I re-ran the installer and changed it to Register Extensions. Ditto for Python 2.6--I made it the default Python. I'm on Vista (with most of the Avalon crap disabled).

Now, when I start Pythonwin.exe, and click either the "Open" toolbar button or select "File...Open" from the menu, Pythonwin immediately crashes without even showing the file selection dialog. Debug info:

Unhandled exception at 0x1e006c6d in Pythonwin.exe: 0xC0000005: Access violation reading location 0x00000004.

VS2003 jumped to "void * __cdecl _heap_alloc_base (size_t size)" in malloc.c. Here's the call stack:

 	python26.dll!1e006c6d() 	
 	win32ui.pyd!1e2bfc70() 	
 	win32ui.pyd!030031a8() 	
 	ntdll.dll!7756878a() 	
 	ntdll.dll!7752ec7e() 	
 	ntdll.dll!77562d96() 	
 	ntdll.dll!7752ec63() 	
>	msvcr71.dll!_heap_alloc(unsigned int size=2002134087)  Line 212 + 0x5	C
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562447() 	
 	ntdll.dll!7753c4d1() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!7753c652() 	
 	ntdll.dll!7756214c() 	
 	ntdll.dll!7756523f() 	
 	ntdll.dll!77565244() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561c21() 	
 	ntdll.dll!7756526c() 	
 	advapi32.dll!76180f7a() 	
 	advapi32.dll!76180efc() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	mfc71.dll!7c1de203() 	
 	win32ui.pyd!03003212() 	
 	win32ui.pyd!0300349d() 	
 	win32ui.pyd!0303f31b() 	
 	python25.dll!027af402() 	
 	python25.dll!027b0989() 	
 	python25.dll!0272a83d() 	
 	python25.dll!027c3217() 	
 	python25.dll!0272c1f2() 	
 	python25.dll!02752966() 	
 	python25.dll!027aed07() 	
 	python25.dll!027544a5() 	
 	python25.dll!0276cf6a() 	
 	python25.dll!0276cfa6() 	
 	python25.dll!0276abdf() 	
 	python25.dll!0277e137() 	
 	python25.dll!0272ad92() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!02729b9e() 	
 	python25.dll!0272ae02() 	
 	python25.dll!0272c5c1() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!0272dcdd() 	
 	python25.dll!0272dd42() 	
 	python25.dll!02769b22() 	
 	python25.dll!027dc52a() 	
 	python25.dll!0277e137() 	
 	python25.dll!027166dc() 	
 	python25.dll!02716786() 	
 	python25.dll!02716928() 	
 	python25.dll!0276bcb9() 	
 	python25.dll!0276be07() 	
 	python25.dll!027512d8() 	
 	python25.dll!027cbb8d() 	
 	python25.dll!02752680() 	
 	python25.dll!027525c3() 	
 	python25.dll!02752966() 	
 	python25.dll!0276c466() 	
 	python25.dll!0276c499() 	
 	python25.dll!0276c7ee() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!775616dc() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	kernel32.dll!771e7a7e() 	
 	msvcr71.dll!_heap_alloc(unsigned int size=45944068)  Line 212	C
 	msvcr71.dll!_heap_alloc(unsigned int size=)  Line 212 + 0x5	C

Why would pythonwin for 2.6 be calling python25.dll? Sadly, I'm not the C debugger I used to be (and don't have the patience for a debug build of Python), but I notice the "original symbol location" for the python25.dll is "c:\trentm\as\ActivePython-devel\build\py2_5_1-win32-x86-apy25-rrun\python\PCbuild\python25.pdb" and for win32ui.pyd just above that, it's "O:\src\pywin32\build\temp.win32-2.5\Release\win32ui.pdb". The calls above that seem to be OK.

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

>Comment By: Robert Brewer (aminusfu)
Date: 2009-01-09 17:07

Message:
By the way, I can open a file into Pythonwin by right-click, "Edit with
Pythonwin". Choosing a recent file works too, e.g.: "File -> 1.
threading.py". But the Open button still crashes.

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

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

[pywin32-bugs] [ pywin32-Bugs-2496107 ] crash on File -> Open... (build 212)

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

Bugs item #2496107, was opened at 2009-01-09 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=2496107&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on File -> Open... (build 212)

Initial Comment:
I just upgraded from Python 2.5 to 2.6.1 (I had also been using 2.6b2), and installed pywin32 build 212 for py2.6. At first, I elected not to Register Extensions, but then after some errors in Pythonwin (looking for some files in my Python25 dir and some in my Python26 dir), I re-ran the installer and changed it to Register Extensions. Ditto for Python 2.6--I made it the default Python. I'm on Vista (with most of the Avalon crap disabled).

Now, when I start Pythonwin.exe, and click either the "Open" toolbar button or select "File...Open" from the menu, Pythonwin immediately crashes without even showing the file selection dialog. Debug info:

Unhandled exception at 0x1e006c6d in Pythonwin.exe: 0xC0000005: Access violation reading location 0x00000004.

VS2003 jumped to "void * __cdecl _heap_alloc_base (size_t size)" in malloc.c. Here's the call stack:

 	python26.dll!1e006c6d() 	
 	win32ui.pyd!1e2bfc70() 	
 	win32ui.pyd!030031a8() 	
 	ntdll.dll!7756878a() 	
 	ntdll.dll!7752ec7e() 	
 	ntdll.dll!77562d96() 	
 	ntdll.dll!7752ec63() 	
>	msvcr71.dll!_heap_alloc(unsigned int size=2002134087)  Line 212 + 0x5	C
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!7756240b() 	
 	ntdll.dll!77562447() 	
 	ntdll.dll!7753c4d1() 	
 	ntdll.dll!77562054() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!7753c652() 	
 	ntdll.dll!7756214c() 	
 	ntdll.dll!7756523f() 	
 	ntdll.dll!77565244() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561c21() 	
 	ntdll.dll!7756526c() 	
 	advapi32.dll!76180f7a() 	
 	advapi32.dll!76180efc() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	advapi32.dll!76196578() 	
 	mfc71.dll!7c1de203() 	
 	win32ui.pyd!03003212() 	
 	win32ui.pyd!0300349d() 	
 	win32ui.pyd!0303f31b() 	
 	python25.dll!027af402() 	
 	python25.dll!027b0989() 	
 	python25.dll!0272a83d() 	
 	python25.dll!027c3217() 	
 	python25.dll!0272c1f2() 	
 	python25.dll!02752966() 	
 	python25.dll!027aed07() 	
 	python25.dll!027544a5() 	
 	python25.dll!0276cf6a() 	
 	python25.dll!0276cfa6() 	
 	python25.dll!0276abdf() 	
 	python25.dll!0277e137() 	
 	python25.dll!0272ad92() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!02729b9e() 	
 	python25.dll!0272ae02() 	
 	python25.dll!0272c5c1() 	
 	python25.dll!0272cdca() 	
 	python25.dll!0276090e() 	
 	python25.dll!0272dcdd() 	
 	python25.dll!0272dd42() 	
 	python25.dll!02769b22() 	
 	python25.dll!027dc52a() 	
 	python25.dll!0277e137() 	
 	python25.dll!027166dc() 	
 	python25.dll!02716786() 	
 	python25.dll!02716928() 	
 	python25.dll!0276bcb9() 	
 	python25.dll!0276be07() 	
 	python25.dll!027512d8() 	
 	python25.dll!027cbb8d() 	
 	python25.dll!02752680() 	
 	python25.dll!027525c3() 	
 	python25.dll!02752966() 	
 	python25.dll!0276c466() 	
 	python25.dll!0276c499() 	
 	python25.dll!0276c7ee() 	
 	ntdll.dll!77561843() 	
 	ntdll.dll!775616dc() 	
 	ntdll.dll!77562033() 	
 	ntdll.dll!77561843() 	
 	kernel32.dll!771e7a7e() 	
 	msvcr71.dll!_heap_alloc(unsigned int size=45944068)  Line 212	C
 	msvcr71.dll!_heap_alloc(unsigned int size=)  Line 212 + 0x5	C

Why would pythonwin for 2.6 be calling python25.dll? Sadly, I'm not the C debugger I used to be (and don't have the patience for a debug build of Python), but I notice the "original symbol location" for the python25.dll is "c:\trentm\as\ActivePython-devel\build\py2_5_1-win32-x86-apy25-rrun\python\PCbuild\python25.pdb" and for win32ui.pyd just above that, it's "O:\src\pywin32\build\temp.win32-2.5\Release\win32ui.pdb". The calls above that seem to be OK.

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

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

[pywin32-bugs] [ pywin32-Bugs-2489735 ] AttributeError: win32file.CreateSymbolicLink on Vista

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

Bugs item #2489735, was opened at 2009-01-06 19:56
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2489735&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: Out of Date
Priority: 5
Private: No
Submitted By: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError: win32file.CreateSymbolicLink on Vista

Initial Comment:
example:
------------------------------------------------------
import sys
import platform
import win32file

print "sys version:", sys.version
print "platform...:", platform.platform()

print "\n***\n"

win32file.CreateHardLink # ok
win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------


Output:


------------------------------------------------------
sys version: 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)]
platform...: Windows-Vista-6.0.6001-SP1

***

Traceback (most recent call last):
  File "test.py", line 14, in <module>
    win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-01-06 21:20

Message:
it should work with the most recent pywin32 build on any Python version on
vista.

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

Comment By: Jens Diemer (pylucid)
Date: 2009-01-06 20:59

Message:
Works with Python 2.6.1!

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

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

[pywin32-bugs] [ pywin32-Bugs-2489735 ] AttributeError: win32file.CreateSymbolicLink on Vista

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

Bugs item #2489735, was opened at 2009-01-06 09:56
Message generated for change (Comment added) made by pylucid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2489735&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: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError: win32file.CreateSymbolicLink on Vista

Initial Comment:
example:
------------------------------------------------------
import sys
import platform
import win32file

print "sys version:", sys.version
print "platform...:", platform.platform()

print "\n***\n"

win32file.CreateHardLink # ok
win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------


Output:


------------------------------------------------------
sys version: 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)]
platform...: Windows-Vista-6.0.6001-SP1

***

Traceback (most recent call last):
  File "test.py", line 14, in <module>
    win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------



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

>Comment By: Jens Diemer (pylucid)
Date: 2009-01-06 10:59

Message:
Works with Python 2.6.1!

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

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

[pywin32-bugs] [ pywin32-Bugs-2489735 ] AttributeError: win32file.CreateSymbolicLink on Vista

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

Bugs item #2489735, was opened at 2009-01-06 09:56
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=2489735&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: Jens Diemer (pylucid)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError: win32file.CreateSymbolicLink on Vista

Initial Comment:
example:
------------------------------------------------------
import sys
import platform
import win32file

print "sys version:", sys.version
print "platform...:", platform.platform()

print "\n***\n"

win32file.CreateHardLink # ok
win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------


Output:


------------------------------------------------------
sys version: 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)]
platform...: Windows-Vista-6.0.6001-SP1

***

Traceback (most recent call last):
  File "test.py", line 14, in <module>
    win32file.CreateSymbolicLink # AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
AttributeError: 'module' object has no attribute 'CreateSymbolicLink'
------------------------------------------------------



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

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

[pywin32-bugs] [ pywin32-Bugs-2488784 ] Unicode exception when using ie.Navigate after dispatch

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

Bugs item #2488784, was opened at 2009-01-05 15:11
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=2488784&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: Mounir (merrami)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode exception when using ie.Navigate after dispatch

Initial Comment:
The situation: When using a IE browser after dispatch and navigating to a particular URL, the exception at the end of this note is observed
Important information: this is from the user of a commercial python program (provided as an executable) called CiteSmart. The error is observed very likely because th user is using a Corean version of Windows XP. This bug couldn't be reproduced on an english plate-form.

> Traceback (most recent call last):
> File "win32com\server\policy.pyo", line 285, in _Invoke_
> File "win32com\server\policy.pyo", line 290, in _invoke_
> File "win32com\server\policy.pyo", line 658, in _invokeex_
> File "win32com\server\policy.pyo", line 653, in
> _transform_args_
> : 'ascii' codec can't encode
> characters in position 0-1: ordinal not in

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

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

[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: 2009-01-02 18:10

Message:
Having pywin32 hosted somewhere that easy_install will discover is needed
for the imminent release of tahoe-lafs v1.3.0.  However, if the current
release of pywin32 is not hosted on pypi, we can instead upload a copy of
the pywin32 package to a tahoe grid.  :-)

http://allmydata.org/trac/tahoe/ticket/566 # host tahoe dependencies on a
tahoe grid

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-12-29 17:19

Message:
Please upload pywin32 212 to http://pypi.python.org and then we can close
this ticket.

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

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-2164420 ] win32trace not working as expected: IIS 7

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

Bugs item #2164420, was opened at 2008-10-14 07:00
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&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: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32trace not working as expected: IIS 7

Initial Comment:
I'm using pywin32-212 on Python 2.5.2 (32-bit) on Windows Vista (64-bit).

I'm trying to wire up a WSGI application in IIS using isapi-wsgi, but I find that the win32traceutil isn't logging anything.

I've started the collector process using: python -m win32traceutil.

I've tested it by running: python -c "import win32traceutil; print 'working'"
and note that the collector prints the string.

I've installed IIS 7 with IIS 6 WMI compatibility.  I've created a 32-bit application pool.  I've created a web site assigned to a 32-bit application pool (called Legacy Development).

Then, I copy isapi/samples/test.py to /inetpub/isapi_test.  I modify it by adding the following to the section indicated by "default response":
            print 'This should show up in the trace util'

Then install the isapi test using:
.\test.py install "--server=Legacy Development"

The app installs correctly, so I browse to http://url.to.the.server/PyISAPITest and I get the default response in the browser, but nothing is logged to the win32trace collector.

I expect that "This should show up in the trace util" should appear in the collector.

What more can I do to investigate/workaround/resolve the issue?


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

>Comment By: Mark Hammond (mhammond)
Date: 2008-12-30 23:34

Message:
WFM with the following fix:

Checking in win32trace.cpp;
new revision: 1.19; previous revision: 1.18

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

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-15 03:43

Message:
Further testing confirms this problem does not exhibit itself on IIS 5.1
(Windows XP), so the problem appears to be isolated to IIS 7 (maybe 6) or
Windows Vista.

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

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-15 01:35

Message:
I've performed additional testing on a 32-bit Vista machine.  The behavior
is the same... win32traceutil does not receive any output from the ISAPI
process.  Therefore, the problem is not related to the 64-bit platform
aspects.

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

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

[pywin32-bugs] [ pywin32-Bugs-2475486 ] Dangerous autocompletes

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

Bugs item #2475486, was opened at 2008-12-29 19:35
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=2475486&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: Robert Brewer (aminusfu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dangerous autocompletes

Initial Comment:
I'm using pywin32 build 210. Some autocompletes are dangerous (and should be trapped in my opinion).

Try typing the following in Pythonwin:

  # Maybe we should use raw_input().
  f = input()

When you type the "." character in the comment, Pythonwin evaluates raw_input() in order to fetch its attributes, and pops up an input prompt.

Well, OK, not a huge problem. We can just cancel the prompt.

Now try this one:

  # Maybe we should use os._exit(0).
  sys.exit(0)

Pythonwin crashes hard. Obviously it's a dynamic language and you can't protect everyone from everything, but maybe these two could be trapped by the autocompleter and not evaluated.

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

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

[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-29 17:19

Message:
Please upload pywin32 212 to http://pypi.python.org and then we can close
this ticket.

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

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-2392746 ] GetNamedSecurityInfo crashes Python with SE_LMSHARE

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

Bugs item #2392746, was opened at 2008-12-05 14:21
Message generated for change (Comment added) made by tjgolden
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2392746&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: 9
Private: No
Submitted By: Tim Golden (tjgolden)
Assigned to: Roger Upole (rupole)
Summary: GetNamedSecurityInfo crashes Python with SE_LMSHARE

Initial Comment:
This code causes Python to crash completely. Python 2.6; pywin32 212; Win XP SP3. Haven't looked at the source yet nor run it through the debugger.

import win32security
win32security.GetNamedSecurityInfo (
  "C$",
  win32security.SE_LMSHARE,
  win32security.OWNER_SECURITY_INFORMATION
)

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

Comment By: Tim Golden (tjgolden)
Date: 2008-12-07 18:35

Message:
Thanks very much for fixing this, Roger. I did umm and ahh a bit as to what
the best approach would be (None, exception, etc.) but I do think any one
answer is compelling and I'm happy with a None.

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

Comment By: Roger Upole (rupole)
Date: 2008-12-07 18:05

Message:
This is fixed in the main branch now.


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

Comment By: Roger Upole (rupole)
Date: 2008-12-06 20:55

Message:
After looking at it for a while, I think returning None
is the most appropriate thing to do.  That way the caller
will at least know that the security descriptor was NULL,
as it may have some special significance that I'm not
aware of.


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

Comment By: Roger Upole (rupole)
Date: 2008-12-06 17:47

Message:
It appears the api function is returning NULL for the security descriptor
even though the call completed successfully.  Never seen this with any
other type of securable object, or even a normal non-administrative
share.  Usually if there is no info to be returned, you'll get an empty
security descriptor rather than null.

Any preferences on how to handle this?  We could 
a) raise an exception anyway
b) return None
c) construct and return an empty security descriptor to
     be consistent with how this function works everwhere else



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

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

[pywin32-bugs] [ pywin32-Bugs-2392746 ] GetNamedSecurityInfo crashes Python with SE_LMSHARE

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

Bugs item #2392746, was opened at 2008-12-05 09:21
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2392746&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: 9
Private: No
Submitted By: Tim Golden (tjgolden)
Assigned to: Roger Upole (rupole)
Summary: GetNamedSecurityInfo crashes Python with SE_LMSHARE

Initial Comment:
This code causes Python to crash completely. Python 2.6; pywin32 212; Win XP SP3. Haven't looked at the source yet nor run it through the debugger.

import win32security
win32security.GetNamedSecurityInfo (
  "C$",
  win32security.SE_LMSHARE,
  win32security.OWNER_SECURITY_INFORMATION
)

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

>Comment By: Roger Upole (rupole)
Date: 2008-12-07 13:05

Message:
This is fixed in the main branch now.


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

Comment By: Roger Upole (rupole)
Date: 2008-12-06 15:55

Message:
After looking at it for a while, I think returning None
is the most appropriate thing to do.  That way the caller
will at least know that the security descriptor was NULL,
as it may have some special significance that I'm not
aware of.


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

Comment By: Roger Upole (rupole)
Date: 2008-12-06 12:47

Message:
It appears the api function is returning NULL for the security descriptor
even though the call completed successfully.  Never seen this with any
other type of securable object, or even a normal non-administrative
share.  Usually if there is no info to be returned, you'll get an empty
security descriptor rather than null.

Any preferences on how to handle this?  We could 
a) raise an exception anyway
b) return None
c) construct and return an empty security descriptor to
     be consistent with how this function works everwhere else



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

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

[pywin32-bugs] [ pywin32-Bugs-2392746 ] GetNamedSecurityInfo crashes Python with SE_LMSHARE

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

Bugs item #2392746, was opened at 2008-12-05 09:21
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2392746&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: 9
Private: No
Submitted By: Tim Golden (tjgolden)
Assigned to: Roger Upole (rupole)
Summary: GetNamedSecurityInfo crashes Python with SE_LMSHARE

Initial Comment:
This code causes Python to crash completely. Python 2.6; pywin32 212; Win XP SP3. Haven't looked at the source yet nor run it through the debugger.

import win32security
win32security.GetNamedSecurityInfo (
  "C$",
  win32security.SE_LMSHARE,
  win32security.OWNER_SECURITY_INFORMATION
)

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

>Comment By: Roger Upole (rupole)
Date: 2008-12-06 15:55

Message:
After looking at it for a while, I think returning None
is the most appropriate thing to do.  That way the caller
will at least know that the security descriptor was NULL,
as it may have some special significance that I'm not
aware of.


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

Comment By: Roger Upole (rupole)
Date: 2008-12-06 12:47

Message:
It appears the api function is returning NULL for the security descriptor
even though the call completed successfully.  Never seen this with any
other type of securable object, or even a normal non-administrative
share.  Usually if there is no info to be returned, you'll get an empty
security descriptor rather than null.

Any preferences on how to handle this?  We could 
a) raise an exception anyway
b) return None
c) construct and return an empty security descriptor to
     be consistent with how this function works everwhere else



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

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

[pywin32-bugs] [ pywin32-Bugs-2392746 ] GetNamedSecurityInfo crashes Python with SE_LMSHARE

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

Bugs item #2392746, was opened at 2008-12-05 09:21
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2392746&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: 9
Private: No
Submitted By: Tim Golden (tjgolden)
>Assigned to: Roger Upole (rupole)
Summary: GetNamedSecurityInfo crashes Python with SE_LMSHARE

Initial Comment:
This code causes Python to crash completely. Python 2.6; pywin32 212; Win XP SP3. Haven't looked at the source yet nor run it through the debugger.

import win32security
win32security.GetNamedSecurityInfo (
  "C$",
  win32security.SE_LMSHARE,
  win32security.OWNER_SECURITY_INFORMATION
)

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

>Comment By: Roger Upole (rupole)
Date: 2008-12-06 12:47

Message:
It appears the api function is returning NULL for the security descriptor
even though the call completed successfully.  Never seen this with any
other type of securable object, or even a normal non-administrative
share.  Usually if there is no info to be returned, you'll get an empty
security descriptor rather than null.

Any preferences on how to handle this?  We could 
a) raise an exception anyway
b) return None
c) construct and return an empty security descriptor to
     be consistent with how this function works everwhere else



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

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

[pywin32-bugs] [ pywin32-Bugs-2392746 ] GetNamedSecurityInfo crashes Python with SE_LMSHARE

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

Bugs item #2392746, was opened at 2008-12-05 14:21
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=2392746&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: GetNamedSecurityInfo crashes Python with SE_LMSHARE

Initial Comment:
This code causes Python to crash completely. Python 2.6; pywin32 212; Win XP SP3. Haven't looked at the source yet nor run it through the debugger.

import win32security
win32security.GetNamedSecurityInfo (
  "C$",
  win32security.SE_LMSHARE,
  win32security.OWNER_SECURITY_INFORMATION
)

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

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

[pywin32-bugs] [ pywin32-Bugs-2391931 ] I wrote a COM server that is work in python 2.5 but not 2.6

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

Bugs item #2391931, was opened at 2008-12-05 15:27
Message generated for change (Comment added) made by rickyteng
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2391931&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: Ricky Teng (rickyteng)
Assigned to: Nobody/Anonymous (nobody)
Summary: I wrote a COM server that is work in python 2.5 but not 2.6

Initial Comment:
Hi,

I wrote a COM server can be called by VB exe.
I wrote the COM server in python 2.5 and pywin32-212.win32-py2.5.exe.

When I change python to 2.6 and pywin32-212.win32-py2.6.exe, register the COM server I wrote. The error message is :

------------
Run-Time error '-2147024770 (8007007e)':

Automation error
The specified module could not be found
------------

But I roll back to python 2.5 and pywin32-212.win32-py2.5.exe, everything is ok.

The code of COM server I wrote is copy from "A Quick Start to Server Side COM"

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

>Comment By: Ricky Teng (rickyteng)
Date: 2008-12-05 15:32

Message:
I forgot to say that I can use python as COM client to call the COM server.
No matter python 2.5 or 2.6

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

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

[pywin32-bugs] [ pywin32-Bugs-2391931 ] I wrote a COM server that is work in python 2.5 but not 2.6

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

Bugs item #2391931, was opened at 2008-12-05 15:27
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=2391931&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: Ricky Teng (rickyteng)
Assigned to: Nobody/Anonymous (nobody)
Summary: I wrote a COM server that is work in python 2.5 but not 2.6

Initial Comment:
Hi,

I wrote a COM server can be called by VB exe.
I wrote the COM server in python 2.5 and pywin32-212.win32-py2.5.exe.

When I change python to 2.6 and pywin32-212.win32-py2.6.exe, register the COM server I wrote. The error message is :

------------
Run-Time error '-2147024770 (8007007e)':

Automation error
The specified module could not be found
------------

But I roll back to python 2.5 and pywin32-212.win32-py2.5.exe, everything is ok.

The code of COM server I wrote is copy from "A Quick Start to Server Side COM"

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

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

[pywin32-bugs] [ pywin32-Feature Requests-2103779 ] Add Unicode versions for Registry functions

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

Feature Requests item #2103779, was opened at 2008-09-10 15:39
Message generated for change (Settings changed) made by wim_h
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2103779&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: Fixed
Priority: 5
Private: No
Submitted By: Wim (wim_h)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Unicode versions for Registry functions

Initial Comment:
pywin32 build 211 has additional functions added for Unicode strings, like: RegEnumKeyExW, RegQueryInfoKeyW.

However, RegOpenKeyExW and RegQueryValueExW are missing... causing problems on Japanese and Chinese Windows versions.


Please, please add RegOpenKeyExW and RegQueryValueExW...



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

>Comment By: Wim (wim_h)
Date: 2008-12-04 15:11

Message:
When will be the py3k release?

In the meantime, I'm encountering more and more issues with Japanese
systems...
Is is possible to release an interim release, with the RegOpenKeyExW and
RegQueryValueExW functions added?


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

Comment By: Roger Upole (rupole)
Date: 2008-10-02 00:02

Message:
win32api can now be built as full unicode, so that all the available
registry functions call the underlying wide-char api functions.
It hasn't been released this way yet, however.

When we finally have a py3k release, all the modules will be built
using unicode APIs.


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

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