On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote:
Sorry for the lack of response, I'm currently waiting for our lawyers to determine if it's ok to use code based on an oleview dump of a native typelib, as that situation is not clear from a copyright POV. I'm afraid I can't do more until they come to a conclusion on that point.
So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result). From http://www.winehq.org/pipermail/wine-devel/2007-March/054589.html (posted by Rob Shearman) this is what I understand the correct process to be (I would like to understand the process in detail so I don't do something wrong to "taint" the wine copyright):
As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??).
Also, what does one do for enums? It does not seem like there is anything that can be changed in this case, so it is alright just to re-create them verbatim (without copying and pasting, and of course the indentation will be prettier)?
Thank you very much for your help.
Misha
Misha Koshelev wrote:
On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote:
Sorry for the lack of response, I'm currently waiting for our lawyers to determine if it's ok to use code based on an oleview dump of a native typelib, as that situation is not clear from a copyright POV. I'm afraid I can't do more until they come to a conclusion on that point.
So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result).
What you can do is describe the IDL file in plain English (e.g. the first method is called "Foo" and takes an in argument of type VARIANT followed by an out argument of type VARIANT *...) and send it to wine-devel. Then me or someone else can go along and write the IDL out based on your description alone, and you can resubmit the remaining parts of your patches.
Hope this helps,
On Tue, 2007-04-03 at 16:54 +0100, Robert Shearman wrote:
Misha Koshelev wrote:
On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote:
Sorry for the lack of response, I'm currently waiting for our lawyers to determine if it's ok to use code based on an oleview dump of a native typelib, as that situation is not clear from a copyright POV. I'm afraid I can't do more until they come to a conclusion on that point.
So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result).
What you can do is describe the IDL file in plain English (e.g. the first method is called "Foo" and takes an in argument of type VARIANT followed by an out argument of type VARIANT *...) and send it to wine-devel. Then me or someone else can go along and write the IDL out based on your description alone, and you can resubmit the remaining parts of your patches.
Hope this helps,
That helps a lot. I think I should have that done sometime this month, hopefully sooner rather than later (I am going to be busy this month but not as busy as last month).
Misha
Misha Koshelev mk144210@bcm.tmc.edu writes:
As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??).
That would be fine, anything that is required by the interface can be the same, so that would mean essentially everything except parameter names and help strings. I don't think you need to change the order of attributes from what oleview shows.
On Thu, 2007-04-05 at 09:35 +0200, Alexandre Julliard wrote:
That would be fine, anything that is required by the interface can be the same, so that would mean essentially everything except parameter names and help strings. I don't think you need to change the order of attributes from what oleview shows.
So I am thinking of implementing some more OLE automation functions and just wanted to clarify one thing before I start doing this. Specifically, parameter names can be arbitrary as far as OLE automation in general is concerned, however for MSI in particular when you use the incorrect parameters for a method/property (for example one instead of two) it throws an exception whose description is "Methodname,Param1Name,Param2Name,etc". I had to make a todo_wine in my conformance test in this because our parameter names are currently different (intentionally as per instructions reference above).
I doubt that any application would depend on the exact description of such an exception, but nonetheless it might be confusing to get different parameter names, say, for a developer who is making an MSI (on Wine???) and is trying to debug his MSI script. In any case, I doubt it matters much but I just wanted to make sure if we should stick with using different parameter names or switch to the same ones (I don't know what kind of copyright issues this really raises or avoids). Otherwise, it would be a pain to change this later on if we already have everything implemented and we find that it is necessary to have the same exception string for some reason.
Thank you all for your comments and all your help with my code.
Misha
Misha Koshelev wrote:
So I am thinking of implementing some more OLE automation functions and just wanted to clarify one thing before I start doing this. Specifically, parameter names can be arbitrary as far as OLE automation in general is concerned, however for MSI in particular when you use the incorrect parameters for a method/property (for example one instead of two) it throws an exception whose description is "Methodname,Param1Name,Param2Name,etc". I had to make a todo_wine in my conformance test in this because our parameter names are currently different (intentionally as per instructions reference above).
I doubt that any application would depend on the exact description of such an exception, but nonetheless it might be confusing to get different parameter names, say, for a developer who is making an MSI (on Wine???) and is trying to debug his MSI script. In any case, I doubt it matters much but I just wanted to make sure if we should stick with using different parameter names or switch to the same ones (I don't know what kind of copyright issues this really raises or avoids). Otherwise, it would be a pain to change this later on if we already have everything implemented and we find that it is necessary to have the same exception string for some reason.
Actually, I forgot that with typelibs parameter names are part of the interface. For example, in some scripting languages (including VBScript and JScript I think) you can do the following:
Methodname(Param1Name=1, Param2Name=2)
This obviously won't work if the parameter names are different.
However, the procedure to cleanly implement an IDL file with compatible parameter names isn't clear to me. I would think we would need legal advice as to how to do this.
Robert Shearman rob@codeweavers.com writes:
This obviously won't work if the parameter names are different.
However, the procedure to cleanly implement an IDL file with compatible parameter names isn't clear to me. I would think we would need legal advice as to how to do this.
It's no different from the other elements of the interface, if the parameters are required for compatibility then there's no room for creativity and thus no copyright violation, you can look up the names in oleview and use the same ones when writing your IDL.
Hi, thank you very much for your help.
I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for that matter; specifically I made a little test to check every single type and find one that could be coerced to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I am using DispGetParam for everything else.
Thanks a lot for your advice.
Misha
Misha Koshelev wrote:
Hi, thank you very much for your help.
I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for that matter; specifically I made a little test to check every single type and find one that could be coerced to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I am using DispGetParam for everything else.
Dumb question: if you already have the variant why don't you use the V_VT() macro on it to its type?
bye michael
Michael Stefaniuc wrote:
Misha Koshelev wrote:
Hi, thank you very much for your help.
I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for that matter; specifically I made a little test to check every single type and find one that could be coerced to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I am using DispGetParam for everything else.
Dumb question: if you already have the variant why don't you use the V_VT() macro on it to its type?
to _get_ its type
/me needs more coffee.
bye michael
Misha Koshelev wrote:
Hi, thank you very much for your help.
I am implementing Installer::RegistryValue for MSI OLE automation and I need a way to tell apart a VT_EMPTY and a VT_I4 type variant with a value of 0 as these have two different behaviors for this function under Windows XP. I have not figured out a way to do this with DispGetParam (or VariantChangeType for that matter; specifically I made a little test to check every single type and find one that could be coerced to only from a VT_EMPTY but not from a VT_BSTR or a VT_I4 but it did not find any such types; a coercion to a VT_I4 succeeds and makes a variant of value 0 if coercing either a VT_EMPTY variant or a zero value VT_I4 variant). I can always just check directly in the DISPPARAMS structure but that seems to be a little dirty if I am using DispGetParam for everything else.
Installer::RegistryValue will probably be different from the vast majority of other functions in the MSI OLE automation interface because registry values themselves have different types. I would expect it to not use DispGetParam and for the following conversions to take place: VT_I4 -> REG_DWORD VT_BSTR -> REG_SZ VT_EMPTY -> REG_NONE? Everything else or just arrays -> REG_BINARY
-
Alexandre Julliard -
Michael Stefaniuc -
Misha Koshelev -
Misha Koshelev -
Robert Shearman