Re: Implement directory object in wineserver.

[Robert Shearman]

Alexandre Julliard wrote:
> Vitaliy Margolen  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.