Implement directory object in wineserver.

[Robert Shearman]

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