[ros-kernel] Re: Ros-kernel Digest, Vol 12, Issue 3

Lucio Diaz reactos_translate at yahoo.es
Fri Sep 3 16:15:33 CEST 2004


 --- ros-kernel-request at reactos.com escribió: 
> Send Ros-kernel mailing list submissions to
> 	ros-kernel at reactos.com
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	http://reactos.com/mailman/listinfo/ros-kernel
> or, via email, send a message with subject or body
> 'help' to
> 	ros-kernel-request at reactos.com
> 
> You can reach the person managing the list at
> 	ros-kernel-owner at reactos.com
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Ros-kernel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: CVS HEAD build failure - windows host -
> mingw 3.4.1
>       (filip?) (Filip Navara)
>    2. Re: PCH dependency check (James Tabor)
>    3. Re: /CONSOLE switch (Aliberti Emanuele)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 01 Sep 2004 13:36:28 +0200
> From: Filip Navara <xnavara at volny.cz>
> Subject: Re: [ros-kernel] CVS HEAD build failure -
> windows host -
> 	mingw 3.4.1	(filip?)
> To: ReactOS Kernel List <ros-kernel at reactos.com>
> Message-ID: <4135B43C.5010200 at volny.cz>
> Content-Type: text/plain; charset=us-ascii;
> format=flowed
> 
> Royce Mitchell III wrote:
> 
> > Filip, you changed this file on Aug 25... any
> ideas?
> 
> No... Wait, i have one idea, if you have
> ntoskrnl/include/ntoskrnl.h.gch 
> file, delete it.
> 
> Regards,
> Filip
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 01 Sep 2004 14:37:20 +0000
> From: James Tabor
> <jimtabor at adsl-64-217-116-74.dsl.hstntx.swbell.net>
> Subject: Re: [ros-kernel] PCH dependency check
> To: ReactOS Kernel List <ros-kernel at reactos.com>
> Message-ID:
> 
>
<4135DEA0.7000608 at adsl-64-217-116-74.dsl.hstntx.swbell.net>
> Content-Type: text/plain; charset=us-ascii;
> format=flowed
> 
> Hartmut Birr wrote:
> >>Sorry Hartmut,
> >>I could not patch to the current cvs. Can you send
> a new patch?
> >>Thanks,
> >>James
> > 
> > 
> > Hi,
> > 
> > helper.mk was outdated. Please try it again.
> > 
> > - Hartmut 
> > 
> It compiles with Linux gcc 3.3.1, w/o any problems.
> Thanks,
> James
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 01 Sep 2004 22:48:57 +0200
> From: Aliberti Emanuele <ea at iol.it>
> Subject: Re: [ros-kernel] /CONSOLE switch
> To: ReactOS Kernel List <ros-kernel at reactos.com>
> Message-ID: <413635B9.4090603 at iol.it>
> Content-Type: text/plain; charset=ISO-8859-1;
> format=flowed
> 
> Hi Gé,
> 
> I am sorry for the late reply. I posted a message
> yesterday, but I used 
> an address that can not post.
> 
> >> <>My plan was to have ntoskrnl set a registry
> value based on the presence
> >> or absence of /CONSOLE. That would be the end of
> the involvement of the
> >> kernel. The winlogon behaviour described above
> would then be keyed on
> >> that registry value. I'm not sure if I understand
> you correctly, but are
> >> you saying that I should scrap the ntoskrl part
> but the winlogon part is
> >> ok (just need another method to set the registry
> key)? That would kill
> >> one of the nice features: being able to boot into
> console mode on a
> >> system which normally runs in graphics mode, for
> the purpose of making
> >> repairs. Also note that there is some "prior art"
> wrt. boot options and
> >> registry values: this is exactly what the NT4
> /BASEVIDEO switch does.
> >>
> I am sorry for my bad English: this adds noise to
> what I write.
> 
> I support booting in text mode since the beginning
> and voted against 
> dropping it when the GUI was to take off.
> 
> That said, making the winlogon perform its i/o in
> graphic mode or in 
> text mode, IMHO, should not depend on a bare value
> stored in the 
> registry by the kernel. Instead each system
> component should be prepared 
> to run in both modes (or, if not possible at all, to
> die), depending on 
> the value returned by a specific API available in
> the SM - say the 
> server registered at slot # 1 in the SM (slot # 0 is
> for the SM itself). 
> This does not mean every process should query the
> SM, but that it exists 
> a way to broadcast a global mode switching to every
> subsystem. In fact 
> it is the SM that loads win32k.sys (in the real NT,
> is that event an on 
> demand event [CSRS rings the SM: "Hi boss, please
> load a piece of mine 
> in the kernel!"], or a predefined event?).
> 
> That behaviour - properly switching from GUI to text
> mode and back, 
> keeping the full context, whenever possible - should
> be a real 
> innovation compared to NT. NT had text mode at the
> beginning, when the 
> dominant subsystem was OS/2. If you look at the OS/2
> subsystem 
> components in NT, you see that they are similar to
> the CSRSS plus the 
> W32 plug-ins. OS/2 is text mode only, unless you buy
> the PM for NT (it 
> used to be available ages ago from MS). Unices and
> Linux have both text 
> and graphic mode (various flavours), and you can
> switch between.
> 
> Booting in text mode is not only nice when you need
> to do repairs. It'd 
> be also very useful in a system that runs *normally*
> in text mode, that 
> can be switched in GUI mode for maintenance, and
> then downgraded to text 
> mode again for its normal running. Does it look like
> typing startx and 
> pressing return? Not exactly. If I am in a vim
> session and shell out to 
> run startx, what I get is not a gvim blocked waiting
> for me to type exit 
> in a xterm. Ros would impress users if, started in
> text mode, after 
> running three of four cmds, switching on the GUI
> would show three or 
> four windows with a cmd each inside.
> 
> For compatibility, /BASEVIDEO should make the system
> behave like in NT 
> 5.x (using the VGA video mode).
> 
> /CONSOLE recalls the "console" concept, which is the
> default I/O 
> character device the operator can choose at the
> beginning of the 
> boostrap process (AIX prints something like "press 1
> here to make this 
> terminal the system console", on every terminal
> physically attached to 
> the planar). If we want to add such an option, it
> souldn't be boolean; 
> it should at least be possible to force the kernel
> to 
=== message truncated === 

Impresive if you manage it!


		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es


More information about the Ros-kernel mailing list