On Wed, Jan 19, 2005 at 05:37:24PM -0600, Robert Shearman wrote:
Luke Kenneth Casson Leighton wrote:
On Wed, Jan 19, 2005 at 09:50:09PM +0000, Luke Kenneth Casson Leighton wrote:
- case statements where the switch variable is a char i
couldn't be bothered to find a way to let it be happy with case(1) it was bitching about 1 not being a char so i converted to a short and it stopped bitching.
postscript:
- i enabled the "expressioning" stuff and got this:
lkcl@highfield:~/src/wine-test/dcom-test/RpcTest$ /opt/dce/bin/dceidl test.idl Warning: Semantic checking prevented by other reported errors idl: File test.idl, line 99: void SubOneConformanceArrayIn([in] long size, [in, length_is(size-1)] unsigned char Array[10]); idl: Syntax error near "-1" Syntax error in attribute list idl: File test.idl, line 100: void CallbackConformanceArrayIn([in] long size, [in, length_is(size*2+1)] unsigned char Array[10]); Only simple expressions allowed for now
Yes, the function is named CallbackConformanceArrayIn because it is a complicated expression and MIDL creates a callback function in C which implements the complex expression, and then stores an index to execute it at runtime.
eek.
all the things 1-16 are not insurmountable problems - they've just not been necessary for the tasks to which dceidl has been put.
Of course, this is a purely academic test file. Many of those problems would not be encountered or could be worked around with real IDL interfaces.
... shall i carry on? :)
While you have demonstrated to me that the dceidl IDL compiler is very capable (and I did not doubt this), you still haven't demonstrated how this can benefit the Wine project. Yes, we can generate our own (probably) compatible client/server glue code (and this is ok for library-implemented functions like the registry or service functions), however we then lose focus on the applications for which we don't have source code for and depend on rpcrt4 being implemented. This is the most common use for Wine!
i understand.
okay - i understand the need [and the distinction], i don't have any knowledge [detailed knowledge] of what rpcrt4 does, other than i believe it to be used to interpret the "type string" tables.
would that be correct?
If you have any ideas on how we can solve this, please let me know.
okay. my initial feeling is that the APR team's example should be followed.
is the list of functions that you have in the wine cvs tree for the rpcrt4 dll a complete list?
things like RpcEpRegisterA in rpc_epmap.c, yes?
the simplest and probably the most naive approach that springs to mind would be to call the functions available in FreeDCE.
RpcEpRegisterA to call rpc_ep_register.
RpcServerInqBindings to call rpc_server_inq_bindings.
that sort of thing - just like they do in APR.
naive? almost certainly.
damn. if that's not easily done, you have a _really_ big job on your hands. at least another 200,000 lines of code into Wine, to support DCE/RPC "a la microsoft".
attached is an example - implementation of rpc_server_inq_bindings, in FreeDCE, for you to compare against RpcServerInqBindings.
_why_ microsoft, _why_ why _why_???