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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 19:42

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

I believe there are two problems:

(1) MS's registry code works strangely
(2) python and pywin32 assume that the functions are returning sizes in
bytes, whereas the API documentation clearly says unicode characters (or in
some places, TCHARS.)

This happens to work by accident on Latin character set systems b/c they
usually use utf-8 or similar 8-byte systems. Korean and Japanese systems do
not.
The following is output of a C++ program I wrote to examine the
functionality of the registry functions on a 64-bit japanese localized
system:

C:\temp>\\tsclient\dev\registry_test.exe
info:          number of subkeys: 2
   maximum length of subkey name: 8
                number of values: 0
    maximum length of value name: 0
info: read key name:
  size before call: 9
   size after call: 5
     buffer growth: 0
          contents: agent
warn: the buffer allocated was not large enough:
  size before call: 9
   size after call: 9
       resizing to: 10
warn: the buffer allocated was not large enough:
  size before call: 10
   size after call: 10
       resizing to: 12
warn: the buffer allocated was not large enough:
  size before call: 12
   size after call: 12
       resizing to: 15
info: read key name:
  size before call: 15
   size after call: 12
     buffer growth: 3
          contents: \x8c\xc2\x82\xcc\x83t\x83@\x83C\x83\x8b
info: done

== Some explanation:

Size before call is the size of the buffer we allocated in order retrieve
the results of RegEnumKeyEx.
Size after call is what RegEnumKeyEx wrote back INTO the buffer size
parameter after the RegEnumKeyEx call.
Resizing to is the size in bytes of the buffer that has been enlarged to
potentially fit the contents.
buffer growth is the increment over the value returned by RegEnumKeyEx in
the lpcbName buffer.


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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 14:33

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

I should also clarify - this is a problem with key and value NAMES. Not
the data.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:24

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

I have attached a registry key that causes the failure that I posted below
for your debugging pleasure.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:23

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

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 14:33

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

I should also clarify - this is a problem with key and value NAMES. Not
the data.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:24

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

I have attached a registry key that causes the failure that I posted below
for your debugging pleasure.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:23

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

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1963786 ] MFC71.dll Not packaged

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

Bugs item #1963786, was opened at 2008-05-14 14:25
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=1963786&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: RoadieRich (roadierich)
Assigned to: Nobody/Anonymous (nobody)
Summary: MFC71.dll Not packaged

Initial Comment:
Installer states that a file, MFC71.dll is required for PyWin to function.  File is not included in installer.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:24

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

I have attached a registry key that causes the failure that I posted below
for your debugging pleasure.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:23

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

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:23

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

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 21:11
Message generated for change (Comment added) made by neverjade
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 13:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 12:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 11:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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-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-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 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 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-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 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 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-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 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 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-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 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 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-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 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 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-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 patch

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

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
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 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 :)

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

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

[pywin32-bugs] [ pywin32-Patches-1937527 ] win32file.ConnectEx patch

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

Patches item #1937527, was opened at 2008-04-08 12:32
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&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.ConnectEx patch

Initial Comment:
A patch for ConnectEx.

called as follows:
win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj])

here's an example:
import socket, win32file, pywintypes
s = socket.socket()
ol = pywintypes.OVERLAPPED()
s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand

print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n")
print win32file.GetOverlappedResult(s.fileno(), ol, 1)
ol = pywintypes.OVERLAPPED()
buff = win32file.AllocateReadBuffer(20480)
print win32file.WSARecv(s, buff, ol, 0)
print win32file.GetOverlappedResult(s.fileno(), ol, 1)        
print buff


I've tested this on win xp.
I use getaddrinfo to process the (host, port) tuple.

Please review.


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

>Comment By: ionel (ionel_mc)
Date: 2008-05-09 03:36

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

To be completely honest I don't really know how to use the tuples returned
from the socket.getaddrinfo - since they are very far from the C addrinfo
struct I need to use in the ConnectEx call, also, i don't think the python
function call overhead to get that addrinfo and make whatever conversions
back to the struct is worth it.

I would add some sort of demo but i need some suggestions (it seems I lack
imagination right now).

I don't cover the corner cases (like bad params) in the test_connectex.




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

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

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

File Added: test_connectex.py

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

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

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

This looks pretty good.  I'd probably prefer for getaddrinfo() to be
called by the user of this function, and the necessary info passed in - is
there a reason not to do that?  Also, would you be so kind as to add
something to the win32\test directory (and maybe even the win32\Demos
directory :) that covers this?

Thanks!

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

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

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

wops, forgot something
File Added: win32file.i-4.patch

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

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

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

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

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

[pywin32-bugs] [ pywin32-Patches-1937527 ] win32file.ConnectEx patch

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

Patches item #1937527, was opened at 2008-04-08 12:32
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&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.ConnectEx patch

Initial Comment:
A patch for ConnectEx.

called as follows:
win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj])

here's an example:
import socket, win32file, pywintypes
s = socket.socket()
ol = pywintypes.OVERLAPPED()
s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand

print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n")
print win32file.GetOverlappedResult(s.fileno(), ol, 1)
ol = pywintypes.OVERLAPPED()
buff = win32file.AllocateReadBuffer(20480)
print win32file.WSARecv(s, buff, ol, 0)
print win32file.GetOverlappedResult(s.fileno(), ol, 1)        
print buff


I've tested this on win xp.
I use getaddrinfo to process the (host, port) tuple.

Please review.


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

>Comment By: ionel (ionel_mc)
Date: 2008-05-09 03:25

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

File Added: test_connectex.py

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

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

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

This looks pretty good.  I'd probably prefer for getaddrinfo() to be
called by the user of this function, and the necessary info passed in - is
there a reason not to do that?  Also, would you be so kind as to add
something to the win32\test directory (and maybe even the win32\Demos
directory :) that covers this?

Thanks!

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

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

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

wops, forgot something
File Added: win32file.i-4.patch

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

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

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

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

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

[pywin32-bugs] [ pywin32-Bugs-1960311 ] 'None' returned for COM string constants

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

Bugs item #1960311, was opened at 2008-05-09 01:01
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=1960311&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: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: 'None' returned for COM string constants

Initial Comment:
String constants in an IDL file have none returned.  Eg, an IDL file has:

  module Constants {
    const char CharTest = -1;
    const LPWSTR StringTest = L"Hello Loraine";
  };

and the generated .py file will have:

  class constants:
    CharTest   =-1         # from enum Constants
    StringTest ='None'     # from enum Constants

Attaching a patch that demonstrates the problem, but I don't see the problem yet.


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

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

[pywin32-bugs] [ pywin32-Bugs-1920299 ] arrayOfVariantOfBSTR in Python

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

Bugs item #1920299, was opened at 2008-03-20 09:45
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1920299&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: Mustafa (goermezer)
Assigned to: Nobody/Anonymous (nobody)
Summary: arrayOfVariantOfBSTR in Python

Initial Comment:
Hi,

I have problem with an application which I try to automate with win32com. My problem is now, that a GetListOfDependantFile expects a arrayOfVariantOfBSTR byreference. I think this must be a list of strings. The VB Code is this:

Set Send1 = CATIA.CreateSendTo()
Call Send.SetInitialFile(myfile)
ReDim arrayOfVariantOfBSTR(500)
Call Send1.GetListOfDependantFile(arrayOfVariantOfBSTR)

How can I write this in Python for win32com ?

best regards

Mustafa Görmezer

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 23:16

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

Just noting this is also being discussed in
http://www.mail-archive.com/com...@li.../msg00144.html

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

Comment By: Mustafa (goermezer)
Date: 2008-03-25 00:58

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

Hi marc,

this is my code:

import win32com.client
app=win32com.client.Dispatch('Catia.Application')
sendto=app.CreateSendTo()
sendto.SetInitialFile('c:\\...igteil.CATPart')
refs=sendto.GetListOfDependantFile()
print refs

When I use no params I get a type error or type conflict (with makepy):

Traceback (most recent call last):
  File
"C:\Python25\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py",
line 310, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Dokumente und Einstellungen\mgo\Desktop\px1.py", line 9, in
<module>
    refs=sendto.GetListOfDependantFile()
  File
"C:\DOKUME~1\mgo\LOKALE~1\Temp\gen_py\2.5\14F197B2-0771-11D1-A5B1-00A0C9575177x0x0x0\SendToService.py",
line 49, in GetListOfDependantFile
    return self._ApplyTypes_(1610940417, 1, (24, 0), ((8204, 3),),
'GetListOfDependantFile', None,oDependant
  File "C:\Python25\Lib\site-packages\win32com\client\__init__.py", line
448, in _ApplyTypes_
    dispid, 0, wFlags, retType, argTypes, *args),
com_error: (-2147352571, 'Typkonflikt.', None, 1)

When I give a list as the param, the function returns the param as a
tuple:

GetListOfDependantFile([])
returns ()
GetListOfDependantFile(['hello'])
returns (u'hello',)


Here is the traceback without makepy:

Traceback (most recent call last):
  File "C:\Dokumente und Einstellungen\mgo\Desktop\px1.py", line 6, in
<module>
    refs=sendto.GetListOfDependantFile()
  File "<COMObject CreateSendTo>", line 2, in GetListOfDependantFile
  File "C:\Python25\Lib\site-packages\win32com\client\dynamic.py", line
258, in
_ApplyTypes_
    result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType,
argTypes
) + args)
pywintypes.com_error: (-2147352567, 'Ausnahmefehler aufgetreten.', (0,
'CATIASen
dToService', 'Das Verfahren GetListOfDependantFile ist fehlgeschlagen',
None, 0,
 -2147024809), None)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-03-24 18:49

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

If you run makepy, you should be able to pass no params - the strings will
be returned.  Please show the code you use and the exception you see.

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-17 07:11
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 22:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 21:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Patches-1806435 ] registring a win32com server with non admin privilges only

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

Patches item #1806435, was opened at 2007-10-03 02:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&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: Robert Langmeier (rlangmeier)
Assigned to: Nobody/Anonymous (nobody)
Summary: registring a win32com server with non admin privilges only

Initial Comment:
I produced this patch to be able to register and use a COM server with insufficient privileges.

A little explanation:
- As a non admin user, you cannot write HKEY_CLASSES_ROOT, but you can register a COM server into HKEY_CURRENT_USER
- HKEY_CLASSES_ROOT is a consolidated view of HKEY_LOCAL_MACHINE  and HKEY_CURRENT_USER (see MSDN)
- The client can always read the registry keys in HKEY_CLASSES_ROOT

It would be great if it can be integrated in a future build. Some check has to be done for parts i'm not using. Registring and unregistring "Standard" servers is correct and functionning.

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 21:00

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

Note that _get_classe_hkey() can probably go - just checking if you can
open the key with KEY_ALL_ACCESS should work.  Note too that the CVS
version of register.py takes a different approach - it attempts to elevate
and retry.  This means we would probably need to add a new cmdline option
to specify which behaviour you desire.  Finally, it would be great if you
can send me a "diff" which compares the old and new files (use "diff -u") -
otherwise it is very hard to determine what changes you made.

Thanks

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

Comment By: Robert Langmeier (rlangmeier)
Date: 2007-10-12 07:00

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

just corrected a bug in _get_classe_hkey and modified RegisterServer
File Added: register-patch.py

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

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

[pywin32-bugs] [ pywin32-Patches-1937527 ] win32file.ConnectEx patch

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

Patches item #1937527, was opened at 2008-04-08 19:32
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&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.ConnectEx patch

Initial Comment:
A patch for ConnectEx.

called as follows:
win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj])

here's an example:
import socket, win32file, pywintypes
s = socket.socket()
ol = pywintypes.OVERLAPPED()
s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand

print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n")
print win32file.GetOverlappedResult(s.fileno(), ol, 1)
ol = pywintypes.OVERLAPPED()
buff = win32file.AllocateReadBuffer(20480)
print win32file.WSARecv(s, buff, ol, 0)
print win32file.GetOverlappedResult(s.fileno(), ol, 1)        
print buff


I've tested this on win xp.
I use getaddrinfo to process the (host, port) tuple.

Please review.


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

>Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 20:33

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

This looks pretty good.  I'd probably prefer for getaddrinfo() to be
called by the user of this function, and the necessary info passed in - is
there a reason not to do that?  Also, would you be so kind as to add
something to the win32\test directory (and maybe even the win32\Demos
directory :) that covers this?

Thanks!

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 18:22

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

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 18:22

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

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 17:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 17:57

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

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

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