Bug #77525 for Win32-API: new release

Tue May 29 14:12:22 2012 bulk88(1) [...] hotmail.com - Ticket created

Subject:

new release - version 0.69

This is my upgrade to Win32::API. It includes the fixed by me original Callback.xs right before I tossed the original Callback.xs since my rewrite of Callback.xs is taking much longer than I thought so I put back the original fixed Callback.xs so it would not crash on -Od. I tested 0.69 on ActivePerl 5.10 32 bit, homebrew VC 5.12 32 bits, Strawberry Perl 5.12 32 bit, ActivePerl 5.14 64 bits, Strawberry Perl 5.14 64 bits. The 32 bit VC compiler was VS 2003. The 64 bit VC compiler was VS 2008. Strawberry Perls were whatever GCC they came with. The only problem with this patch is it doesn't include binary blob api_test.dlls. The existing ones in 0.68 wont work. There is a comment in the source that api_test dll should be compiled at the same time as Win32::API by the module user. I disagree, I think it should be distributed compiled, since the point of Win32::API is to use already compiled, source not available, DLLs. If a module user's compiler or his perl's Config.pm has different compiler flags than "normal" people or normal DLLs use, he can create a very broken Win32::API that passes all its tests since api_test got the exact same flags. I'm thinking of flags as default calling convention, TCHARs, bitfields, default alignment/packing on MSVC. Mingw/GCC has 1000s of compiler flags that can break Win32::API (turn all floats and doubles to SSE 128 bit FP nums, pass by pointer int 64s, a secret this pointer for return int64s instead of EAX EDX combo for example). A known good DLL is needed. I have the api_test dlls that I compiled myself. I compiled then with debugging on, so security cookie and runtime checks are on. I think those 2 features of VC are very useful for api_test, since they caught my own mistakes a couple times. I didn't change the VS-specific project/solution files for api_test on purpose so I don't accidentally upgrade them to VS 2008 format locking out older VSes so the patch doesn't touch those files. Do you want to compile api_test yourself or should I attach my 2 dlls and you'll include them in 0.69? My total rewrite of ::Callback will be another release and a higher version number, 0.70 I guess.

Subject:

patch069.diff

Message body is not shown because it is too large.

Sat Jun 09 07:06:20 2012 cosimo [...] cpan.org - Correspondence added

Hi, please do attach the DLLs if possible.

Sat Jun 09 07:06:23 2012 The RT System itself - Status changed from 'new' to 'open'

Sat Jun 09 07:20:25 2012 cosimo [...] cpan.org - Correspondence added 60 min

RT-Send-CC:

libwin32 [...] perl.org

I have read most of your patch. It's somewhat difficult to digest all the changes together. I think it would have been easier to get a series of commits, maybe in a forked git repository (hint :) I'm impressed by the amount of work you did. I'd like someone else to have a look at this patch, but my feedback is: * Not sure the Win32::API/Win32::API::More namespace split is the best solution. I'd suggest reaching out to Win32::API users to estimate how much work it would be to change "Ss" for short ints. * Please avoid the WIN32_API_SORRY_I_WAS_AN_IDIOT variable, and rename it to something that explains the purpose of it.

Sat Jun 09 07:20:27 2012 cosimo [...] cpan.org - Given to COSIMO

Sat Jun 09 10:38:01 2012 bulk88(1) [...] hotmail.com - Correspondence added

From:

bulk88(1) [...] hotmail.com

On Sat Jun 09 07:20:25 2012, COSIMO wrote: Show quoted text

> I have read most of your patch. > > It's somewhat difficult to digest all the changes together. > I think it would have been easier to get a series of commits, maybe in a > forked git repository (hint :) > > I'm impressed by the amount of work you did. I'd like someone else to > have a look at this patch, but my feedback is: > > * Not sure the Win32::API/Win32::API::More namespace split is the best > solution. I'd suggest reaching out to Win32::API users to estimate how > much work it would be to change "Ss" for short ints.

I did. http://perlmonks.org/?node_id=970481 http://perlmonks.org/?node_id=970206 ::API is more than 10 years old, ::More is required. If I get rid of ::More, all existing scripts that use Win32::API with a pointer to a number will break, and all existing scripts that used an unsigned prototype or unsigned type letter will start to get unsigned numbers rather than signed, so == comparisons will all fail, also all existing scripts that use S for structure will have to be changed. If you are willing take responsibility, I can move ::API::More's features/behavior to ::API and remove ::API::More. Show quoted text

> * Please avoid the WIN32_API_SORRY_I_WAS_AN_IDIOT variable, and rename it > to something that explains the purpose of it.

I couldn't think of a aggressive enough name that explains that never to use this option so someone suggested that. There are 3 things that can be done about that flag. 1. Leave the flag documented, and can you think of a better name that truly discourages anyone from using the option? I predict this option will be very popular for alot of people with Win32::API code. Even 0.68's own test suite had 1 or 2 buffer overflows in its code that were caught. 2. Totally de-document the flag so someone would have to look through the source to find that it exists, and if they complain >0.68 broke all their scripts, they can be told about the flag. 3. This is a security fix. Remove the flag outright. There is no excuse for corrupted memory. Go use 0.68 from CPAN if you want buffer overflows that badly.

Sat Jun 09 10:53:40 2012 bulk88(1) [...] hotmail.com - Correspondence added

From:

bulk88(1) [...] hotmail.com

On Sat Jun 09 07:06:20 2012, COSIMO wrote: Show quoted text

> Hi, please do attach the DLLs if possible.

These 2 DLLs were built with "runtime checks" and debugging C lib and -O1. Runtime checks has a nice stack pointer vaildator that catches stdcall stack unwind or cdecl vs stdcall errors. x64 was made with Studio 2008, the 32 bit was made with Studio 2003. These dlls are from the 0.70 version of api-test (quads and lots of parameters funcs were added), but will work with 0.69 ::API.

Subject:

API_test64.dll

Download API_test64.dll
application/octet-stream 216k

Message body not shown because it is not plain text.

Subject:

API_test.dll

Download API_test.dll
application/octet-stream 196k

Message body not shown because it is not plain text.

Sat Jun 09 10:53:49 2012 bulk88(1) [...] hotmail.com - Correspondence added

From:

bulk88(1) [...] hotmail.com

On Sat Jun 09 07:06:20 2012, COSIMO wrote: Show quoted text

> Hi, please do attach the DLLs if possible.

These 2 DLLs were built with "runtime checks" and debugging C lib and -Od. Runtime checks has a nice stack pointer vaildator that catches stdcall stack unwind or cdecl vs stdcall errors. x64 was made with Studio 2008, the 32 bit was made with Studio 2003. These dlls are from the 0.70 version of api-test (quads and lots of parameters funcs were added), but will work with 0.69 ::API.

Sat Jun 09 11:28:11 2012 bulk88(1) [...] hotmail.com - Correspondence added

From:

bulk88(1) [...] hotmail.com

Also, you want to look in 0.70, https://rt.cpan.org/Public/Bug/Display.html?id=77728 I added a bunch of things to the TODO file for future authors to consider that I didn't/couldn't do. Most notably, I never added automatic UTF16 handling which I thought of doing but ran into time and design problems. Rather than "automatic" UTF16 handling, I decided some kind of generic perl sub callback API for parameter un/packing would be better as described in the TODO. The "friendly name" for raw function pointers is there so in the future a un/pack callback will be passed that name. Also I gave Win32::API::Type::Un/Pack the ::API object as the 1st parameter so Math::Int64 flag can be checked today, and also that very advanced un/packing designs can be implemented in the future, including per obj or per caller package type callbacks. Design problems were, what does "automatic" mean? whats the input CP? System ANSI? Perl UTF8 (check SV flag)? a special $? some variable from a perl pragma ? precomposed? and on output always convert to system ANSI CP? or always convert to UTF8 flaged SV, or use lpUsedDefaultChar to control whether output SV is UTF8 or legacy CP, or put utf8 in the SV without ever turning on the UTF8 SV flag? What about "shorts", do they stay numeric (0x41 not "A" not "\x41"), or do they become string like ("A" not 65) like the CHAR/char type? So thats why no automatic wide handling was added. The only "wide" feature I put in was that the buffer overflow sentinal is wide compatible and will wide null terminate all string. I did use Encode and there is a test and a api-test func to make sure binary gibberish scalars with UTF16 in them correctly wind up in a C func taking a Wide string and the C func validates the wide string. So yes, today, with some work on your own, ::API has no limitations that prevent you from using wide string apis.

Fri Oct 19 00:48:41 2012 BULKDD [...] cpan.org - Correspondence added

A 0.69 was never released on CPAN, a 0.71 and a 0.70_02 were released on CPAN.

Fri Oct 19 00:48:42 2012 BULKDD [...] cpan.org - Status changed from 'open' to 'rejected'

Bug #77525 for Win32-API: new release - version 0.69