Re: 3 Win32::API bugs
On 05/10/2012 06:00 PM, bulk 88 wrote: I still don't know what letter to use for shorts. $ has no lower case version for signed short. H is too closed to hex numbers and pack's existing H unpack feature letter (H="Half"), someone might want to put in a 'H' type code one day to get strings back in ASCII HEX from Win32::API rather than binary gibberish. T (T="shorT", also "strucT", but sturct is S already), isn't used by pack, W (W="Word") is used for BER numbers by pack, and I've never seen those anywhere, so W or T I think are safe choices. note that Win32::API letters have nothing to do with Perl's pack/unpack. I know, I know, it would be nice to keep it consistent, but this is not necessary. furthermore, the C-like prototype feature completely hides the letters used. you could simply say that using Win32::API with letters is deprecated, and choose whatever ugly letter you want :-) heck, you can even use compound type identifiers, eg. "I" for int and "UI" for unsigned int, or something like that. The unsigned features I'm not sure how to implement, I dont think it makes any sense for in parameters, since on a C level, a function can't tell if it got a signed or unsigned. The only kind of pointer fill supported by Win32::API is fill a string pointer, so for a pointer to int or pointer to handle you still have to unpack it yourself (I think, I've only used Win32::API for a few days). For the return parameter currently I thinking of a bit flag field for T_NUMBER and T_INTEGER that gets masked off for the switch, and then the flag is check on whether to make an IV or a UV. If the return unsigned bug is fixed, small but I think irrelevant risk of breakage complaints. regarding pointers, if you define a type (eg. Win32::API::Type->typedef), Win32::API creates a corresponding "LP" type that is packed/unpacked for you. if I remember correctly :-) Implementing the short feature is the most difficult I think. I made a test for the Dll handle leak and fixed that already. *I think* I fixed Callback. A couple problems with Callback was the ILT jump table, all the functions are 1 opcode long with the ILT jump table, shannons law has been broken by MS. Fixed that. The biggest problem I think was, assuming that the compiler will always copy the fake global vars which are replaced with EBP stack reads, into EDX. Any, slight, tiny, change of the compiler by MS can, and probably has in the past, broken it. I rewrote it that any mov from fake global pointer to any register will be caught and replaced. Also, under -Od, VC didn't use the traditional mov opcode, it used one specific for EAX (ask intel about that one), fixed that. I also reworked the optimization pragma to be more specific what ::Callback wants (dont toss the 0XC0DEs) to CallbackTemplate, and CallbackTemplate can be compiled with O1 O2 and Od now. as you may have realized, Win32::API::Callback is pure evil :-) I wouldn't spend too much time on it, it has always been more of a proof of concept than real working code. as the documentation goes, "highly experimental". I don't know of any code (or CPAN module) that relies on callbacks. good that you fixed some of the awkwardness, but I'm afraid the whole concept is too fragile to be *really* fixed. In 00_API.t, there are a bunch of cdecl tests that are commented out. They refer to functions like c_call_sum_int c_call_sum_int_dbl? Does anyone have these, they aren't in API_test.cpp. no idea about this one, sorry. cheers, Aldo
RE: 3 Win32::API bugs
> To: d...@perl.it; libwin32@perl.org; bul...@hotmail.com > Subject: Re: 3 Win32::API bugs > Date: Thu, 10 May 2012 10:53:45 +0200 > From: cos...@streppone.it > > Or should I forget about callback and try and fix the 3 other bugs (func > > not found dll handle leak, no unsigned return values, no shorts) which > > are easier targets to kill than Callback and then try Callback if I have > > the time? > > I would tend to agree with this. > > -- > Cosimo I still don't know what letter to use for shorts. $ has no lower case version for signed short. H is too closed to hex numbers and pack's existing H unpack feature letter (H="Half"), someone might want to put in a 'H' type code one day to get strings back in ASCII HEX from Win32::API rather than binary gibberish. T (T="shorT", also "strucT", but sturct is S already), isn't used by pack, W (W="Word") is used for BER numbers by pack, and I've never seen those anywhere, so W or T I think are safe choices. The unsigned features I'm not sure how to implement, I dont think it makes any sense for in parameters, since on a C level, a function can't tell if it got a signed or unsigned. The only kind of pointer fill supported by Win32::API is fill a string pointer, so for a pointer to int or pointer to handle you still have to unpack it yourself (I think, I've only used Win32::API for a few days). For the return parameter currently I thinking of a bit flag field for T_NUMBER and T_INTEGER that gets masked off for the switch, and then the flag is check on whether to make an IV or a UV. If the return unsigned bug is fixed, small but I think irrelevant risk of breakage complaints. Implementing the short feature is the most difficult I think. I made a test for the Dll handle leak and fixed that already. *I think* I fixed Callback. A couple problems with Callback was the ILT jump table, all the functions are 1 opcode long with the ILT jump table, shannons law has been broken by MS. Fixed that. The biggest problem I think was, assuming that the compiler will always copy the fake global vars which are replaced with EBP stack reads, into EDX. Any, slight, tiny, change of the compiler by MS can, and probably has in the past, broken it. I rewrote it that any mov from fake global pointer to any register will be caught and replaced. Also, under -Od, VC didn't use the traditional mov opcode, it used one specific for EAX (ask intel about that one), fixed that. I also reworked the optimization pragma to be more specific what ::Callback wants (dont toss the 0XC0DEs) to CallbackTemplate, and CallbackTemplate can be compiled with O1 O2 and Od now. In 00_API.t, there are a bunch of cdecl tests that are commented out. They refer to functions like c_call_sum_int c_call_sum_int_dbl? Does anyone have these, they aren't in API_test.cpp.
RE: 3 Win32::API bugs
> Date: Thu, 10 May 2012 11:55:02 -0700 > From: dbec...@roadrunner.com > To: bul...@hotmail.com > CC: libwin32@perl.org > Subject: Re: 3 Win32::API bugs > By the way - not to make your job more difficult or anything, but > there's a situation that isn't currently being handled. Some OS calls > can return a pointer to another function which you would then use to > call that function to get more info. > > An example would be IShellFolder::BindToObject which returns a 'void > **ppvOut' parameter that is to then be used to iterate over the objects > in question. What would need to be done is to treat that returned ptr > as though it were a named library routine that could be looked up in > the DLL and instead just assume it has already been looked up and just > use the returned address and associate it with the name supplied. .. > I wanted to use this technique to iterate over the Recycle bin and > look for a specific item or optionally list the items found using > Win32API calls but got short-circuited by that returned function > ptr and no way to use it. > Read my post from the other day. Win32::API can already do this with some runtime package namespace messing. http://perlmonks.org/?node_id=969555 I highly suggest you write an XS library though. C or C++ for your COM code.
Re: 3 Win32::API bugs
On 05/09/2012 07:10, bulk 88 wrote: Since Callback is crashing, I dont know whether to try to fix it, so I have a question, did 02_Callback.t ever not crash with a certain version number of Win32::API, with a certain compiler, etc? Or should I forget about callback and try and fix the 3 other bugs (func not found dll handle leak, no unsigned return values, no shorts) which are easier targets to kill than Callback and then try Callback if I have the time? By the way - not to make your job more difficult or anything, but there's a situation that isn't currently being handled. Some OS calls can return a pointer to another function which you would then use to call that function to get more info. An example would be IShellFolder::BindToObject which returns a 'void **ppvOut' parameter that is to then be used to iterate over the objects in question. What would need to be done is to treat that returned ptr as though it were a named library routine that could be looked up in the DLL and instead just assume it has already been looked up and just use the returned address and associate it with the name supplied. IShellFolder interface method: Method Description BindToObjectRetrieves a handler, typically the Shell folder object that implements IShellFolder for a particular item. Optional parameters that control the construction of the handler are passed in the bind context. In order to iterate over these objects, you need to be able to treat that returned pointer from BindToObject as a new API function addr. I would think it would be pretty easy to do - just bypass all the code that looks up the function name in the DLL and use the pointer (and an arbitrary name supplied by the caller to associate the pointer to) as though it had actually been looked up (maybe check for 0 etc). Here's an AutoIt example of using the IShellFolder interface (note the use of the returned function ptr $IEnumIDList to iterate further into the shell interface): ; Create an IDispatch-Object for the IShellFolder Interface $IShellFolder = ObjCreateInterface( $pParentFolder, $sIID_IShellFolder, $dtagIShellFolder ) ; $pIEnumIDList is the address that receives an IEnumIDList interface pointer of the enumeration object If $IShellFolder.EnumObjects( $NULL, BitOR( $SHCONTF_FOLDERS, $SHCONTF_INCLUDEHIDDEN ), $pIEnumIDList ) = $S_OK Then ; Create an IDispatch-Object for the IEnumIDList Interface $IEnumIDList = ObjCreateInterface( $pIEnumIDList, $sIID_IEnumIDList, $dtagIEnumIDList ) ; Enumerate the folders ; Param 1 [in] : Step value as in a For-loop While $IEnumIDList.Next( 1, $pidlRel, $iFetched ) = $S_OK ; Param 2 [out]: PIDL relative to parent folder $iFolders += 1; Param 3 [out]: 0 if no more PIDLs, 1 else ... ... ... WEnd EndIf I wanted to use this technique to iterate over the Recycle bin and look for a specific item or optionally list the items found using Win32API calls but got short-circuited by that returned function ptr and no way to use it.
RE: 3 Win32::API bugs
> From: bul...@hotmail.com > To: cos...@streppone.it; libwin32@perl.org; d...@perl.it > Subject: RE: 3 Win32::API bugs > Date: Thu, 10 May 2012 12:00:57 -0400 > I still don't know what letter to use for shorts. $ has no lower case version > for signed short. H is too closed to hex numbers and pack's existing H unpack > feature letter (H="Half"), someone might want to put in a 'H' type code one > day to get strings back in ASCII HEX from Win32::API rather than binary > gibberish. T (T="shorT", also "strucT", but sturct is S already), isn't used > by pack, W (W="Word") is used for BER numbers by pack, and I've never seen > those anywhere, so W or T I think are safe choices. > Another serious backwards compatibility problem. Win32::API's documentation official states only the flags that exist (I N F D C P S K) are all upper case, but in pack() upper case is unsigned number. In Win32::API::Type types are correctly mirrored as unsigned to upper case, signed to lower case. How is this supposed to be solved? API versioning "use Win32::API 0.69;" and an internal to Win32::API flag to invert the meaning of upper and lower case and turn on unsigned support? Time to fork Win32::API under a new name? or make a new PM called Win32::API::V2 or something that turned on unsigned support and inverts meaning of upper and lower case?
