Implement directory object in wineserver.

Robert Shearman rob at
Wed Nov 23 12:05:05 CST 2005

Alexandre Julliard wrote:

>Vitaliy Margolen <wine-devel at> 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
>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