reactos-kernel

Re: [ros-kernel] midl compiler

[KJK::Hyperion <no...@li...>]

At 01.23 28/06/2002, you wrote:
> > cool. One more step towards build environment self-sufficiency. Does it
> > compile TLB resources too? or it does just RPC stubs?
>Please read the whole thread before you start jumping around with a wide 
>grin on your face, just like pacman. Otherwise you might make a fool of 
>yourself. ;-)

it's called "hope"

>Although the ReWind IDL compiler is the best I have seen yet, I don't feel 
>comfortable with contributing to ReWind.

Why not? technical, political or personal reasons?

Re: [ros-kernel] (no subject)

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

fre, 2002-06-28 kl. 11:35 skrev Jurgen Van Gael:
> Hi everyone,
> (same message accidentaly sent to old mailing lists)
> 
> 
> I was trying to boot the current build with bochs, but after I install
> all files and copy them to harddrv.img and boot bochs, I get the error
> message "no boot drivers available". It also seems as freeldr does not
> load ide.sys and vfatfs.sys.
> 
> I went on to experiment and it seems it doesn't boot after I install the
> system.hiv to bochs. Any clues on what goes wrong?
> 
> Jurgen

You need a newer version of FreeLoader. I have put up a snapshot of
FreeLoader for download. You can get a precompiled version (i386) here:
http://reactos.wox.org/download.php?id=22

and sources from here:
http://reactos.wox.org/download.php?id=23

Casper

RE: [ros-kernel] packet in makefile

[Mike L. <mi...@ho...>]

Apologies for replying to my own question, looking further I see that they
are two separate items. I had assumed that it was an error introduced by the
recent moving things around. However the top level makefile seems to be
confused with them having the same name, I am referring to the following
warnings

	makefile:671: warning: overriding commands for target `packet'
	makefile:526: warning: ignoring old commands for target `packet'
	makefile:674: warning: overriding commands for target `packet_implib'
	makefile:529: warning: ignoring old commands for target `packet_implib'
	makefile:677: warning: overriding commands for target `packet_clean'
	makefile:532: warning: ignoring old commands for target `packet_clean'
	makefile:680: warning: overriding commands for target `packet_install'
	makefile:535: warning: ignoring old commands for target `packet_install'
	makefile:683: warning: overriding commands for target `packet_dist'
	makefile:538: warning: ignoring old commands for target `packet_dist'

regards

Mike Lerwill

> -----Original Message-----
> From: rea...@li...
> [mailto:rea...@li...]On Behalf Of Mike
> Lerwill
> Sent: 28 June 2002 16:28
> To: Ros-Kernel
> Subject: [ros-kernel] packet in makefile
>
>
> packet currently appears in two places, user mode libraries and
> kernel mode
> networking drivers.
>
> Can someone tell me which is the correct place for it.
>
> Mike Lerwill
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>

[ros-kernel] packet in makefile

[Mike L. <mi...@ho...>]

packet currently appears in two places, user mode libraries and kernel mode
networking drivers.

Can someone tell me which is the correct place for it.

Mike Lerwill

Re: [ros-kernel] midl compiler

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

fre, 2002-06-28 kl. 14:00 skrev Jason Filby:
> Then fork it here. But is not contributing to ReWind worth the
> additional effort to take a step backwards for ReactOS?
> 
> - Jason

As Steven pointed out, we can fork it with a more restrictive license.

Casper

Re: [ros-kernel] midl compiler

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

Ooops, I should have read your mail more carefully...

fre, 2002-06-28 kl. 14:10 skrev Casper Hornstrup:
> fre, 2002-06-28 kl. 14:00 skrev Jason Filby:
> > Then fork it here. But is not contributing to ReWind worth the
> > additional effort to take a step backwards for ReactOS?
> > 
> > - Jason

For me it is, but it may not be for others. In any case, an LGPL fork
can still use the X11 licensed patches from ReWind.

> 
> As Steven pointed out, we can fork it with a more restrictive license.
> 
> Casper

Casper

Re: [ros-kernel] CmiVerifyHiveHeader asserting on current CVS build

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

fre, 2002-06-28 kl. 08:35 skrev Robert Dickenson:
> The function CmiVerifyHiveHeader(PHIVE_HEADER Header) in module 
> ntoskrnl/cm/regfile.c
> is giving the following error on my current build updated with latest CVS. 
> This is after removing
> the assert on each condition failure. ReactOS then boots ok.
> 
> Loading 
> Ndis...
> (ldr/loader.c:1431) DriverBase: 
> dca16000
> Running 
> autocheck...
> Autochk 
> 0.0.1
>    Checking drive 
> C:      OK
> - - - -
> Unused3 is 00000003 (must be 
> 1)
> Unused4 is 00000000 (must be 
> 3)
> Unused5 is 00000001 (must be 
> 0)
> Unused7 is 00000000 (must be 
> 1)
> - - - -
> repeated four times
> - - - -
> (ldr/loader.c:1431) DriverBase: 
> dca88000
> SMSS: Loaded win32k.sys (Status 
> 0)
> 
> 
> Can anybody advise as to what has changed here. Looks like some index is 
> now off by one.
> 
> Thanks and regards, Robert.

Are your registry hives created by ReactOS or Windows NT? If they are
created by Windows NT, there may be some incompatibility. Have you tried
removing \reactos\system32\config\*.hiv (except the text file
system.hiv) and any .alt files there may be and boot reactos again?
Maybe run a scandisk first just to be sure they are not corrupted.

Casper

Re: [ros-kernel] midl compiler

[Jason F. <jas...@ya...>]

Then fork it here. But is not contributing to ReWind worth the
additional effort to take a step backwards for ReactOS?

- Jason

--- Casper Hornstrup <ch...@us...> wrote:
> fre, 2002-06-28 kl. 01:23 skrev Eric Kohl:
> 
> > 
> > Although the ReWind IDL compiler is the best I have seen yet, I
> don't feel
> > comfortable with contributing to ReWind.
> > 
> > Eric
> 
> Same feelings here.
> 
> Casper
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [ros-kernel] midl compiler

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

fre, 2002-06-28 kl. 01:23 skrev Eric Kohl:

> 
> Although the ReWind IDL compiler is the best I have seen yet, I don't feel
> comfortable with contributing to ReWind.
> 
> Eric

Same feelings here.

Casper

[ros-kernel] (no subject)

[Jurgen V. G. <jur...@st...>]

Hi everyone,
(same message accidentaly sent to old mailing lists)


I was trying to boot the current build with bochs, but after I install
all files and copy them to harddrv.img and boot bochs, I get the error
message "no boot drivers available". It also seems as freeldr does not
load ide.sys and vfatfs.sys.

I went on to experiment and it seems it doesn't boot after I install the
system.hiv to bochs. Any clues on what goes wrong?

Jurgen

[ros-kernel] CmiVerifyHiveHeader asserting on current CVS build

[Robert D. <od...@pn...>]

The function CmiVerifyHiveHeader(PHIVE_HEADER Header) in module 
ntoskrnl/cm/regfile.c
is giving the following error on my current build updated with latest CVS. 
This is after removing
the assert on each condition failure. ReactOS then boots ok.

Loading 
Ndis...
(ldr/loader.c:1431) DriverBase: 
dca16000
Running 
autocheck...
Autochk 
0.0.1
   Checking drive 
C:      OK
- - - -
Unused3 is 00000003 (must be 
1)
Unused4 is 00000000 (must be 
3)
Unused5 is 00000001 (must be 
0)
Unused7 is 00000000 (must be 
1)
- - - -
repeated four times
- - - -
(ldr/loader.c:1431) DriverBase: 
dca88000
SMSS: Loaded win32k.sys (Status 
0)


Can anybody advise as to what has changed here. Looks like some index is 
now off by one.

Thanks and regards, Robert.

[ros-kernel] CVS Commit: freeldr

[Brian P. <br...@sg...>]

Changes in v1.4 (6/27/2002)  
  
- Added separate configuration for a SETUPLDR version  
  
Modified Files:  
     freeldr/Makefile freeldr/freeldr.c freeldr/include/reactos.h   
     freeldr/include/version.h   
Added Files:  
     freeldr/CHANGELOG freeldr/bootmgr.c freeldr/include/bootmgr.h   
     freeldr/reactos/setupldr.c   
Removed Files:  
     CHANGELOG   
 

Re: [ros-kernel] midl compiler

[Steven E. <ste...@ya...>]

> Although the ReWind IDL compiler is the best I have
> seen yet, I don't feel
> comfortable with contributing to ReWind.
> 
> Eric

Simple dude....adopt it to the winehq tree and make it
lgpl. Alexandre hasnt added it because no one has sent
him patches. Unless you just dont want to piss Eric P
or Ove off. =) If its a license thing with ReWind
remeber we can "do what thou wilt"

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [ros-kernel] midl compiler

[Eric K. <ek...@rz...>]

"KJK::Hyperion" <no...@li...> wrote:

> cool. One more step towards build environment self-sufficiency. Does it
> compile TLB resources too? or it does just RPC stubs?

Please read the whole thread before you start jumping around with a wide
grin on your face, just like pacman. Otherwise you might make a fool of
yourself. ;-)

Our IDL 'compiler' is only an incomplete scanner/parser combination without
a code generator. It is very far form being usable. The best IDL compiler I
have seen is widl from the ReWind project (X11 Wine fork).

Although the ReWind IDL compiler is the best I have seen yet, I don't feel
comfortable with contributing to ReWind.

Eric

Re: [ros-kernel] FreeLoader & setup loader

[Steven E. <ste...@ya...>]

> Everyone please keep in mind that when you change
> the freeldr.sys module
> code you need to update the version and add an entry
> in the changelog.

Has anyone looked in to why the binary is hosed when
you build with mingw rather then djgpp? This is the
only thing that keeps me from using freeldr rather
then loadros. Casper has been submitting a lot of
patches to mingw of late, so mabey they would be
willing to help us fix whatever we need to get it
going.

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [ros-kernel] midl compiler

[KJK::Hyperion <no...@li...>]

At 15.53 26/06/2002, you wrote:
>I hacked the idl compiler to build properly on Windows.

cool. One more step towards build environment self-sufficiency. Does it 
compile TLB resources too? or it does just RPC stubs?

>For the past few days I was searching the net for alternative idl compilers:

well, you were luckier than me :-) I could only find IDL compilers for CORBA

[ros-kernel] Leading underscores when compiling under Linux

[Brian P. <br...@sg...>]

I have modified the FreeLoader makefile so that it will compile
FreeLoader correctly under all intel versions of gcc. But when I try to
compile under linux it won't link because I have put leading underscores
on my assembly language function names. Apparently the linux version of
gcc does not want the leading underscore. Does anyone have any idea how
I can solve this problem?
 
Brian

[ros-kernel] FreeLoader & setup loader

[Brian P. <br...@sg...>]

 
I'm going to add a new target to the FreeLoader Makefile that will
generate a setup loader version of FreeLoader. I will also modify the
code to not include the code to boot multiple operating systems in the
setup loader version.
 
Everyone please keep in mind that when you change the freeldr.sys module
code you need to update the version and add an entry in the changelog.
 
Brian

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

ntoskrnl/io/arcname.c
    Fixed SystemRoot accessibility check.

ntoskrnl/io/symlink.c
    Added missing OBJ_OPENLINK attribute in IoDeletesymbolicLinkObject().

ntoskrnl/ke/main.c
    Stop the system if SystemRoot cannot be created or is not accessible.

ntoskrnl/io/driver.c
ntoskrnl/ldr/loader.c
    Added check for loaded module prior to loading it.

Eric

Re: [ros-kernel] ReactOS not booting correctly

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

tor, 2002-06-27 kl. 17:20 skrev Eric Kohl:
> 
> "Casper Hornstrup" <ch...@us...> wrote:
> 
> > I should have said MinGW runtime 2.0 here. Newest w32api is 1.5.
> 
> Well, runtime 2.0 is still in beta state, isn't it. Does runtime 1.5 work?

The previous release mingw-runtime 1.3 works fine.

> 
> Eric

Re: [ros-kernel] ReactOS not booting correctly

[Eric K. <ek...@rz...>]

"Casper Hornstrup" <ch...@us...> wrote:

> > 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?
Yes, I want to check whether 'C:\reactos' exists and can be opened.

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?

You're right! Using NtOpenFile() instead of NtOpenSymbolicLinkObject() is
much more appropriate. I checked NtOpenSymbolicLink() and it doesn't set the
OBJ_OPENLINK attribute. But instead IoDeleteSymbolicLink() needs to be
changed. It needs to open the specified link using the OBJ_OPENLINK
attribute.

> 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?

The filesystem should be mounted. In case the filesystem cannot be mounted,
the system should issue an INACCESSIBLE_BOOT_DEVICE error and stop (BSOD).


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

Well, runtime 2.0 is still in beta state, isn't it. Does runtime 1.5 work?

Eric

Re: [ros-kernel] midl compiler

[Eric K. <ek...@rz...>]

"Steven Edwards" <ste...@ya...> wrote:

Hi Steven!

> Have you taken a look at the ReWind projets IDL
> compiler?

I had a look at the ReWind IDL compiler. At present it can generate DCOM
proxy stubs only, but this is no surprise. IMO it is the most advanced IDL
compiler, wrt its design.

Eric

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

Re: [ros-kernel] ReactOS not booting correctly

[Eric K. <ek...@rz...>]

"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...".

> 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.

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!


Eric

Re: [ros-kernel] ReactOS not booting correctly

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

ons, 2002-06-26 kl. 23:18 skrev Eric Kohl:
> 
> "Casper Hornstrup" <ch...@us...> wrote:
> 
> 
> > With latest FreeLoader I cannot successfully boot latest ReactOS.
> >
> > "\SystemRoot" is not created, but all boot drivers are loaded and
> initialized.
> >
> [...]
> > (ke/main.c:714) CommandLine: multi(0)disk(0)rdisk(0)partition(1)\reactos
> /DEBUGPORT=COM1 /BAUDRATE=115200
> > (io/arcname.c:304) NtOpenSymbolicLinkObject() failed to open '\SystemRoot'
> (Status c0000001)
> 
> I rebuilt the current ReactOS and FreeLoader but I cannot reproduce this
> bug.
> Do you have the latest DJGPP?
> If not, get it! I couldn't get the latest FreeLoader running with an older
> DJGPP.
> 
> Eric

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...".

Actually the failure to open the symbolic link was non-critical. I think the OBJ_OPENLINK flag is missing so it should be:

--- 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?

--- 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,

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.

Casper