Re: [ros-kernel] ReactOS not booting correctly

[Casper H. <ch...@us...>]

tor, 2002-06-27 kl. 12:56 skrev Eric Kohl:
> 
> "Casper Hornstrup" <ch...@us...> wrote:
> 
> 
> > I was confused about the messages about the modules not beeing found.
> Maybe we should
> > change this message to something like "<module> not found. Trying to
> load...".
> 
> What about "<module> not loaded yet. Loading...".

Yes this is better.

> 
> > Actually the failure to open the symbolic link was non-critical. I think
> the OBJ_OPENLINK flag is missing so it should be:
> >
> > --- symlink.orig Thu Jun 27 02:20:04 2002
> > +++ symlink.c Thu Jun 27 01:22:24 2002
> > @@ -192,6 +192,8 @@
> >    DPRINT("NtOpenSymbolicLinkObject (Name %wZ)\n",
> >   ObjectAttributes->ObjectName);
> >
> > +  ObjectAttributes->Attributes |= OBJ_OPENLINK;
> > +
> >    return(ObOpenObjectByName(ObjectAttributes,
> >       IoSymbolicLinkType,
> >       NULL,
> >
> > --- arcname.orig Thu Jun 27 02:19:14 2002
> > +++ arcname.c Thu Jun 27 01:36:29 2002
> > @@ -291,7 +291,7 @@
> >    /* Check whether '\SystemRoot'(LinkName) can be opened */
> >    InitializeObjectAttributes(&ObjectAttributes,
> >        &LinkName,
> > -      0,
> > +      OBJ_OPENLINK,
> >        NULL,
> >        NULL);
> >
> >
> > But, with the following patch, NtOpenSymbolicLinkObject() makes more
> > sense to me. Comments?
> 
> No! If the OBJ_OPENLINK attribute is set, a link object will be opened
> instead of the target it points to. So you have to use OBJ_OPENLINK if you
> want to retrieve link's target path, change a link's target path or delete a
> link object but not the object it points to. But if you want to open the
> target of a link OBJ_OPENLINK must not be set.

And opening the target is intended here? But should
NtOpenSymbolicLinkObject() be used here then? It's name suggest that it
does just that - opens the link object itself and not the target. What
does the NT implementation do?

Then there is another problem. When trying to open the target object
here, NtOpenSymbolicLinkObject() fails because the file system is not
mounted yet and the file system is not mounted by this request. IIRC it
is only mounted on the first create request. Should the call to
NtOpenSymbolicLinkObject() cause the filesystem to be mounted?

> 
> In the current case NtOpenSymbolicLink() is used to check whether
> \SystemRoot points to an existing target by trying to open the target.
> Opening the link object instead will cause the call to succeed even if the
> link's target does not exist or cannot be opened for some other reason.
> 
> 
> > The real problem was with the new MinGW runtime (1.5). There are several
> issues related
> > issues related to this. If we make a release now, we should make a note
> > in the release notes that MinGW runtime 1.5 currently cannot be used to
> > compile ReactOS.
> 
> Ooops!

I should have said MinGW runtime 2.0 here. Newest w32api is 1.5.

> 
> 
> Eric