Re: [PATCH] Fix 16 bit StringFromGUID2 to not use wide characters
"Michael Karcher" <wine(a)mkarcher.dialup.fu-berlin.de> wrote:
+INT WINAPI StringFromGUID2_16(REFGUID id, LPSTR str, INT cmax) +{ + char xguid[80]; + int len; + + if (WINE_StringFromCLSID( id, xguid )) + return 0; + + len = strlen( xguid ) + 1; /* The terminating zero counts */ + if (len > cmax) + return 0; + + strcpy( str, xguid ); + return len; +}
This is not an equivalent of the old implementation, is it really supposed to fail if the buffer length is shorter than the guid? -- Dmitry.
Am Montag, den 19.05.2008, 19:58 +0900 schrieb Dmitry Timoshkov:
+INT WINAPI StringFromGUID2_16(REFGUID id, LPSTR str, INT cmax) +{ + char xguid[80]; + int len; + + if (WINE_StringFromCLSID( id, xguid )) + return 0; + + len = strlen( xguid ) + 1; /* The terminating zero counts */ + if (len > cmax) + return 0; + + strcpy( str, xguid ); + return len; +}
This is not an equivalent of the old implementation, is it really supposed to fail if the buffer length is shorter than the guid?
http://msdn.microsoft.com/en-us/library/ms683893(VS.85).aspx says so. I will test Microsoft's native implementation when I get around to. Regards, Michael Karcher PS: is it possible to test 16 bit API function in the wine test suite? I suppose not, as it should be compilable in a 32 bit Windows environment, so we don't even have LoadLibrary16.
"Michael Karcher" <wine(a)mkarcher.dialup.fu-berlin.de> wrote:
This is not an equivalent of the old implementation, is it really supposed to fail if the buffer length is shorter than the guid?
http://msdn.microsoft.com/en-us/library/ms683893(VS.85).aspx says so. I will test Microsoft's native implementation when I get around to.
That's the description of 32-bit implementation, 16-bit one may differ.
PS: is it possible to test 16 bit API function in the wine test suite? I suppose not, as it should be compilable in a 32 bit Windows environment, so we don't even have LoadLibrary16.
Of course Wine has LoadLibrary16, and a working 16-bit implementation. Although there is no built-in support for 16-bit tests, there is a way to build them: http://www.winehq.org/pipermail/wine-devel/2008-February/062566.html -- Dmitry.
Am Montag, den 19.05.2008, 20:41 +0900 schrieb Dmitry Timoshkov:
"Michael Karcher" <wine(a)mkarcher.dialup.fu-berlin.de> wrote:
http://msdn.microsoft.com/en-us/library/ms683893(VS.85).aspx says so. I will test Microsoft's native implementation when I get around to. That's the description of 32-bit implementation, 16-bit one may differ. Of course. That's why I am going to test.
PS: is it possible to test 16 bit API function in the wine test suite? I suppose not, as it should be compilable in a 32 bit Windows environment, so we don't even have LoadLibrary16. Of course Wine has LoadLibrary16, and a working 16-bit implementation. I know. I already used it for a toy implementation of regsvr (16 bit version). But the wine testsuite has the policy to be compilable with MSVC too, so no wine specific code allowed, if I understand it correctly. And *they* don't have LoadLibrary16 available in their include files.
Although there is no built-in support for 16-bit tests, there is a way to build them: http://www.winehq.org/pipermail/wine-devel/2008-February/062566.html Thanks for the pointer. So openwatcom is the way to go to write real 16 bit tests. I wondered what open source compiler would compile 16 bit code and started thinking of some embedded x86 compiler.
Regards, Michael Karcher
Am Montag, den 19.05.2008, 19:58 +0900 schrieb Dmitry Timoshkov:
"Michael Karcher" <wine(a)mkarcher.dialup.fu-berlin.de> wrote:
+INT WINAPI StringFromGUID2_16(REFGUID id, LPSTR str, INT cmax) +{ + char xguid[80]; + int len; + + if (WINE_StringFromCLSID( id, xguid )) + return 0; + + len = strlen( xguid ) + 1; /* The terminating zero counts */ + if (len > cmax) + return 0; + + strcpy( str, xguid ); + return len; +}
This is not an equivalent of the old implementation, is it really supposed to fail if the buffer length is shorter than the guid?
It is, in fact, an equivalent implementation of the old one. MultiByteToWideChar is also failing (return value of zero) if the buffer length is to short, exactly as the new implementation does. I am adding that case to the 32 bit testsuite (but I also tested it on 16 bits) Regards, Michael Karcher
participants (2)
-
Dmitry Timoshkov -
Michael Karcher