Implement directory object in wineserver.
Robert Shearman
rob at codeweavers.com
Wed Nov 23 12:05:05 CST 2005
Alexandre Julliard wrote:
>Vitaliy Margolen <wine-devel at kievinfo.com> writes:
>
>
>
>>Basically event, mutex, section, timer, etc can go there with minor
>>changes to code. Named pipes, mail slots and winstations with desktops
>>are a bit different. They have their own name space, that I'm planning on
>>using current namespace mechanism for. With the sample code I've sent to
>>you some days ago to show how that would work with named pipes.
>>find_object_dir worked perfectly on named pipes. The problem is object
>>creation. Actually not a creation itself, but insertion into the local
>>name space. I need to call different functions to insert an object into
>>directory or local name space (struct namespace). To do that I will need
>>to know what object type are we creating and what object type is the
>>parent.
>>
>>
>
>Sorry, but that's wrong. You should *never* check the object type
>explicitly. You need a generic function to insert an object into a
>directory, and a generic directory type that can implement the various
>types of directories.
>
I think there is a bit of a communication problem here. Vitaliy isn't
proposing different types of directories. There will only every be one
type - one that holds zero or more objects of any type. I also don't see
any problem with what Vitaliy is doing with the object ops. Am I right
in think this function is the one that you are commenting on:
>+/* open a new handle to an existing object */
>+obj_handle_t open_object_dir( const struct object_attr *attr, const struct object_ops *ops,
>+ unsigned int access )
>+{
>+ obj_handle_t handle = 0;
>+ struct unicode_str name_left;
>+ struct object *obj;
>+
>+ if ((obj = find_object_dir( attr, &name_left )))
>+ {
>+ if (name_left.len) /* not fully parsed */
>+ set_error( STATUS_OBJECT_PATH_NOT_FOUND );
>+ else if (ops && obj->ops != ops)
>+ set_error( STATUS_OBJECT_TYPE_MISMATCH );
>+ else
>+ handle = alloc_handle( current->process, obj, access, attr->attributes & OBJ_INHERIT );
>+
>+ release_object( obj );
>+ free_unicode_str( &name_left );
>+ }
>+ return handle;
>+}
>
If so, I don't see much of a problem with it. Maybe we shouldn't return
a handle, but instead return a "struct object *" or a "void *", but
passing in struct object_ops * into the function isn't doing anything
other than eliminating common code in most of the objects. It doesn't
force anything to be exported outside of the implementation of the object.
--
Rob Shearman
More information about the wine-devel
mailing list