reactos-kernel

Re: [ros-kernel] Disk layout continued

[Aliberti E. <ea...@us...>]

On 23 May 2002 at 1:40, Casper Hornstrup wrote:

> What root are we talking about? The Object Manager root or the Win32
> shell namespace root? System drive? POSIX subsystem root? Other?
> 
> Yes, unix applications expect a certain disk layout. However the POSIX
> subsystem can emulate this layout so the unix applications are happy.
> 
> Now I'm confused. Which special file system object? Symbolic links are
> handled by the object manager in cooperation with it's clients.
> 
> The subsystem translates relative paths into fully qualified paths.
>
> Each subsystem can provide symbolic links to a central location.
>
> Just configure your subsystems to have the same view of your volumes
> then.


I simply reproduce verbatim what Casper wrote. What is apparently 
missing in the original dialog is what Casper tries (desperately;) to 
affirm with his comments. By dropping the dialog text, I hope that 
obscure thing pops up itself.
.
.
.
.
.
.
.
.
What we are talking about is a "name space". Of course there is only 
one name space in every OS. In NT, the name space is the system name 
space, the one generated and maintained by the Ob manager in the 
executive. Whatever you create in NT, unless it is unamed, it has a 
fully qualified name from the root "\" down to its own (relative) 
name. One of the important tasks in Os simulation is name space 
simulation. As I just recalled, every OS has its own name space, 
{directory|folder|library} separator convention, file name convention 
etc. Do you really belive that "A:" really exist in your very new XP 
pro box? It is just what the Win32 subsytem show to you (dear) my 
windows process. Therefore what we really need is not "where do I put 
my files?", but "what is a complete and correct mapping of the system 
name space to project it, in full or partially, in my os name 
space?". Also, keep in mind that Win32 can NOT see the whole system 
name space. Therefore it is NOT required an isomorphism between the 
system name space and your own subsystem's name space.

Re: [ros-kernel] csrss explained

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

At 00.46 22/05/2002, you wrote:
>A thing to keep in mind is that, at the origins of NT, there was a single 
>user-mode server that made environment subsystems live. That is why the 
>meta-server is still called "client/server runtime" (CSR) even if actually 
>now is the runtime exclusively for the Win32 server.
[...]

I like the old architecture more. I find it more flexible

Re: [ros-kernel] csrss explained

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

At 00.46 22/05/2002, you wrote:
>A thing to keep in mind is that, at the origins of NT, there was a single 
>user-mode server that made environment subsystems live. That is why the 
>meta-server is still called "client/server runtime" (CSR) even if actually 
>now is the runtime exclusively for the Win32 server.
[...]

I like the old architecture more. I find it more flexible, and it has less 
overhead, as it uses only one process. It can be programmatically 
controlled better. The subsystems can interoperate faster. I think it's 
generally better

>%SystemRoot%\system32\csrss.exe
>   ObjectDirectory=\Windows
>   SharedSection=1024,3072
>   Windows=On
>   SubSystemType=Windows
>   ServerDll=basesrv,1
>   ServerDll=winsrv:UserServerDllInitialization,3
>   ServerDll=winsrv:ConServerDllInitialization,2
>   ProfileControl=Off
>   MaxRequestThreads=16

Ever tried to modify some of the parameters? Just for fun?

Re: [ros-kernel] Problems building freeldr

[Nick D. <nic...@ya...>]

Hi Brian,

----- Original Message -----
From: "Brian Palmer" <br...@sg...>
To: <rea...@li...>
Sent: Tuesday, May 21, 2002 8:20 PM
Subject: RE: [ros-kernel] Problems building freeldr


> I believe that the latest version of NASM is v0.98.32. I have only used
> v0.98 however. It may be that the new version of NASM is trying to
> optimize my boot sector code for me and generating extra instructions in
> doing so. I'll download the new version of NASM and see what it is
> doing. In the mean time you should be able to assemble it just fine with
> v0.98.

Will try that. It does seem strange that the new version isn't backwardly
compatible with older source.

> As for the install/header file problems you are having that's because
> you are trying to compile it with DJGPP. You see, there are 3 parts to
> freeldr. The boot sectors (assemble with NASM), freeldr (compile with
> DJGPP), and the installer (compile with Mingw32). I really should remove
> the top-level makefile because it just seems to cause confusion, but it
> will be useful once freeldr can be compiled with Mingw32. So to solve
> your install/header file problems you will need to switch over to
> Mingw32 to compile the installer since it is Win32 code.

Though I haven't downloaded the previous version of NASM, I followed your
instructions anyway. Unfortunately, none of the 3 parts will compile. There
seems to be a problem with freeldr\freeldr\makefile and manual attempts at
command line to build the freeldr bit (under DJGPP) throw up a screen full
of errors. Attempting to make install with mingw32 does a similar thing. Do
you want me to see if I can get it to work hack the makefiles (and paths in
the source if necessary)?

If you like I can report back if and when I get freeldr to build.

Just one other thing - can freeldr boot from a second primary partition?
It's just that my WinXP bootsector is quite important! :-)

Thanks for your help.

Nick.

--
Nick Date
Bath, England, UK


> > -----Original Message-----
> > From: rea...@li...
> [mailto:reactos-kernel-
> > ad...@li...] On Behalf Of Nick Date
> > Sent: Tuesday, May 21, 2002 7:11 AM
> > To: rea...@li...
> > Subject: Re: [ros-kernel] Problems building freeldr
> >
> > Hi Casper,
> >
> > ----- Original Message -----
> > From: "Casper Hornstrup" <ch...@us...>
> > To: <rea...@li...>
> > Sent: Tuesday, May 21, 2002 1:01 PM
> > Subject: Re: [ros-kernel] Problems building freeldr
> >
> > [snip]
> >
> > > > I have no idea whatsoever what the "TIMES value is negative" error
> is
> > all
> > > > about. My assembler knowledge is very limited. The line in FAT.ASM
> > reads
> > ...
> > > >
> > > >     times 510-($-$$) db 0   ; Pad to 510 bytes
> > > >
> > >
> > > I have never seen this before. Which nasm version are you using? My
> best
> > > guess is that fat.asm assembles to a binary larger than 510 bytes.
> >
> > I'm using the latest version of NASM (3.0.5?). I've managed to compile
> the
> > freeldr part of the program and have found that the problem with the
> TIMES
> > value is related to the bootsect directory and the missing/bad path
> for
> > header problems is related to the install part of freeldr.
> >
> > Where's Brian Palmer when you need him? :-) If and when I get freeldr
> > working I'll submit any tweaks here so that someone can update the
> CVS.
> > It's
> > just a pity that loadros doesn't seem to be in the tree anymore cos I
> > can't
> > load ros! ;-)
> >
> > Thanks again for your help, Casper.
> >
> > Nick.
> >
> > --
> > Nick Date
> > Bath, England, UK


---
Outgoing mail is certified virus free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.363 / Virus Database: 201 - Release Date: 21/05/2002


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [ros-kernel] Bootloaders

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

"Robert K." <ro...@ko...> wrote:


>  Thanks. Is Brian Palmer the author of freeloader?  And who wrote loadros?

Brian Palmer wrote most of the FreeLoader code. I made a few minor
contributions.

Loadros was written by Rex Jolliff, David Welch and a few others. Have a
look at the cvs history.


Eric

Re: [ros-kernel] Bootloaders

[Robert K. <ro...@ko...>]

> Thanks. Is Brian Palmer the author of freeloader?  And who wrote loadros?

> Hello Robert!
>
> None of the existing loaders uses Flat-Real-Mode.
>
> 1) Loadros:
> Part of the reactos cvs module. DOS program, written in assembly language
> and thus hard to maintain. Does not (an will never) have the ability to
> detect hardware or analyze the system hive. Works reliably.
>
> 2) FreeLoader:
> Main part of the freeldr cvs module. Boot loader/manager that includes boot
> code for three filesystems (FAT12/16, FAT32 and ISO9660/CDFS). Written in
> assembly language and C. Hardware detection can (and will) be added. The
> flat-text system hive (system.hiv) is read and used for loading boot start
> drivers. Still got several bugs in the boot code.
>
> 3) GRUB (GRand Unified Bootloader):
> GNU utility (www.gnu.org). Mainly developed for *NIX OSs, like Linux or
> *BSD. Can load kernel and drivers but cannot detect hardware and cannot
> analyze the system hive. I don't use it so I cannot comment on the quality
> of the code.
>
> I hope this answers your question.
>
> Eric
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Restructuring CVS Take 2

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

tor, 2002-05-23 kl. 13:35 skrev Eric Kohl:
> Btw, where will user-mode services be located in the cvs tree. IMHO, the
> services-directory is not the right place. It should be renamed to 'drivers'
> to minimize the confusion about the term 'service'.

I agree.

Re: [ros-kernel] Restructuring CVS Take 2

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

"Jason Filby" <jas...@ya...> wrote:


> apps/*: removing apps/test, move apps/system to subsys

As part of my current work on smss I wrote a dummy autochk.exe. Should I
commit it to apps/system/autochk or somewhere else?

How do you plan to organize the sysbsys directory?

Btw, where will user-mode services be located in the cvs tree. IMHO, the
services-directory is not the right place. It should be renamed to 'drivers'
to minimize the confusion about the term 'service'.


Eric

Re: [ros-kernel] Bootloaders

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

"Robert K." <ro...@ko...> wrote:

> Is it possible for you to give me a short introduction about which
> loaders
> exist for ROS,
> why and why not they work,
> who wrote them,
> if they use Flat-Real-Mode
> and Dis/Advances?

Hello Robert!

None of the existing loaders uses Flat-Real-Mode.

1) Loadros:
Part of the reactos cvs module. DOS program, written in assembly language
and thus hard to maintain. Does not (an will never) have the ability to
detect hardware or analyze the system hive. Works reliably.

2) FreeLoader:
Main part of the freeldr cvs module. Boot loader/manager that includes boot
code for three filesystems (FAT12/16, FAT32 and ISO9660/CDFS). Written in
assembly language and C. Hardware detection can (and will) be added. The
flat-text system hive (system.hiv) is read and used for loading boot start
drivers. Still got several bugs in the boot code.

3) GRUB (GRand Unified Bootloader):
GNU utility (www.gnu.org). Mainly developed for *NIX OSs, like Linux or
*BSD. Can load kernel and drivers but cannot detect hardware and cannot
analyze the system hive. I don't use it so I cannot comment on the quality
of the code.

I hope this answers your question.

Eric

[ros-kernel] CVS Commit: reactos

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

Modified files:
    ntoskrnl/io/create.c
    services/fs/cdfs/fsctl.c
    services/fs/ext2/super.c
    services/fs/minix/mount.c
    services/fs/template/template.c
    services/fs/vfat/fsctl.c

Log message:
    Use NT-compatible (VPB-based) mounting mechanism.


Eric

Re: [ros-kernel] NT-compatible filesystem mount mechanism

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

"Hartmut Birr" <har...@te...> wrote:

> It seems, that the problem comes from IoCreateStreamFileObject. Vfat calls
> this function with the disk-driver-object and the resulting file object
> must point to the fsd-driver-object. The cache manager use this file
object
> for reading from disk. Currently, there is attached the
disk-driver-object.
> The parsing of each directory starts at offset 0. This is the boot sector
> from disk- device-object.

Sure! I guess I overlooked this one. I'll commit it as soon as possible.


Thanks a lot,
Eric

Re: [ros-kernel] NT-compatible filesystem mount mechanism

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Eric Kohl [SMTP:ek...@rz...]
> Gesendet am:	Mittwoch, 22. Mai 2002 19:41
> An:	ReactOS Kernel
> Betreff:	[ros-kernel] NT-compatible filesystem mount mechanism
>
> Unfortunately ReactOS still doesn't boot properly. I found that the 
vfat-fs
> driver starts searching for files from the boot sector instead of the 
root
> directory. It seems that the start sector (or cluster) of the root 
directory
> is not initialized properly but set to zero. The debug output in the 
mount
> code returns the correct value for 'RootStart'.
>
It seems, that the problem comes from IoCreateStreamFileObject. Vfat calls 
this function with the disk-driver-object and the resulting file object 
must point to the fsd-driver-object. The cache manager use this file object 
for reading from disk. Currently, there is attached the disk-driver-object. 
The parsing of each directory starts at offset 0. This is the boot sector 
from disk- device-object.

- Hartmut

 

Re: [ros-kernel] Disk layout continued

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

tor, 2002-05-23 kl. 00:35 skrev Robert K.:
> Hi, I'd like to warm up the theme about Directory structure and multiple
> installations, again.
> 
> Hyper and I had a discussion in this context, and I want to give us a base
> via posting it.
> Conclusion up to now is:
> -very different views for some ss
> -multiple distinct installations should be possible on one partition but
> cause dir-inconsistency (who has the true view)

There should be no trouble with multiple installations on one parition
unless you run badly behaving applications that expect \windows and
\program files to be there. Well-written applications use the OS APIs to
get these paths (which ultimately is saved in the registry).

> 
> Let's start clearing this problem.,
> 
> KJK::Hyperion: about Unix dirs...
> I think they *really* should stay in the disk root. All systems with a
> POSIX subsystem (MacOS/X, QNX, BeOS) do that, I don't see why we have to
> differ

The unix standard directories will show up in all subsystems then?

> NonVolatil: I don't want to pollute the root
> KJK::Hyperion: the root is no-one's land

What root are we talking about? The Object Manager root or the Win32
shell namespace root? System drive? POSIX subsystem root? Other?

> NonVolatil: AND I want to have a subdir for each sub system, also win32
> KJK::Hyperion: Win32 can, by design, be installed everywhere
> Unix systems cannot. They have a rigid structure, and more important
> there's no way to determine dynamically the location of directories

Yes, unix applications expect a certain disk layout. However the POSIX
subsystem can emulate this layout so the unix applications are happy.

> NonVolatil: thats ok and unchangeable. But with virtual dirs there is a
> possibility to locate the real dirs under the OS' dir
> KJK::Hyperion: virtual directories are an administration and programming
> hell
> NonVolatil: i don't think so
> NonVolatil: 'cos a programmer of a certain ss knows what he knows
> KJK::Hyperion: they introduce yet another special file system object, for
> example

Now I'm confused. Which special file system object? Symbolic links are
handled by the object manager in cooperation with it's clients.

> KJK::Hyperion: do they take in account all the possible paths?
> X:\dir\..\config.sys? X:\config.sys.? X:\dir1\dir2\..\..\config.sys?
> NonVolatil: OS/2's config.sys resides in the boot drives root
> KJK::Hyperion: what if some program reads it with an "indirect" path like
> those? do you have to check every damn file open?
> NonVolatil: whats an indierect path?
> KJK::Hyperion: the dot and double-dot entries, for example
> NonVolatil: the ss's open implementation has to monitor if a special file
> is opened and treat that differently.  - Its possible but hard
> KJK::Hyperion: X:\..\..\dir\.\dir2\..\.\..\config.sys....
> this is the same as X:\config.sys

The subsystem translates relative paths into fully qualified paths.

> KJK::Hyperion: there's another problem with the "every SS has its root"
> approach. That they cannot work together

Each subsystem can provide symbolic links to a central location.

> KJK::Hyperion: if they share the same root, file paths can be exchanged
> freely with little or no processing required

Just configure your subsystems to have the same view of your volumes
then.

Re: [ros-kernel] Problems with the last changes (mdl.c..)

[David W. <we...@cw...>]

On Tue, May 21, 2002 at 09:58:22PM +0200, Hartmut Birr wrote:
> This means, at each position where KeAttacheProcess is called, there must 
> be disable all thread switching.
>
I don't think that is possible since a KeAttachProcess'ed thread can 
access user space, in fact this is its main use.
 
> The patch solves my problem. But there exist two other problems. The patch 
> does not check if the stack is in kernel or in user space and there exist a 
> problem if the stack is located over a 4MB boundary. I think the real 
> problem is, that the mapping for the stack is created within the wrong 
> proccess context. My second patch solve this problem, but it must disable a 
> warning for bad mappings.
> 
I don't think there are any circumstances where a thread's kernel stack
could be in user-space however the 4MB boundary problem needs solving. 
I've attached a new more complete patch:

Index: ntoskrnl/include/internal/ps.h
===================================================================
RCS file: /CVS/ReactOS/reactos/ntoskrnl/include/internal/ps.h,v
retrieving revision 1.33
diff -u -r1.33 ps.h
--- ntoskrnl/include/internal/ps.h	14 May 2002 21:19:17 -0000	1.33
+++ ntoskrnl/include/internal/ps.h	22 May 2002 22:35:22 -0000
@@ -32,6 +32,7 @@
  * Defines for accessing KPCR and KTHREAD structure members
  */
 #define KTHREAD_INITIAL_STACK     0x18
+#define KTHREAD_STACK_LIMIT       0x1C
 #define KTHREAD_TEB               0x20
 #define KTHREAD_KERNEL_STACK      0x28
 #define KTHREAD_PREVIOUS_MODE     0x137
Index: ntoskrnl/ke/i386/tskswitch.S
===================================================================
RCS file: /CVS/ReactOS/reactos/ntoskrnl/ke/i386/tskswitch.S,v
retrieving revision 1.9
diff -u -r1.9 tskswitch.S
--- ntoskrnl/ke/i386/tskswitch.S	15 Jan 2002 02:51:32 -0000	1.9
+++ ntoskrnl/ke/i386/tskswitch.S	22 May 2002 22:35:25 -0000
@@ -29,9 +29,10 @@
 #include <internal/i386/segment.h>
 #include <internal/ps.h>
 #include <ddk/i386/tss.h>
-			
+#include <internal/ntoskrnl.h>
+		
 /* FUNCTIONS ****************************************************************/
-
+	
 .globl _Ki386ContextSwitch
 _Ki386ContextSwitch:
 /* 
@@ -97,6 +98,7 @@
 	movl	%esp, KTHREAD_KERNEL_STACK(%ebx)	
 	movl	8(%ebp), %ebx
 	movl	KTHREAD_KERNEL_STACK(%ebx), %esp
+	movl	KTHREAD_STACK_LIMIT(%ebx), %edi
 
 	/*
 	 * Set the stack pointer in this processors TSS
@@ -110,8 +112,25 @@
 	 */
 	movl	ETHREAD_THREADS_PROCESS(%ebx), %ebx
 	movl	KPROCESS_DIRECTORY_TABLE_BASE(%ebx), %eax
-	movl	%eax, %cr3 
+	movl	%eax, %cr3
 
+	/*
+	 * Set up the PDE for the top of the new stack.
+	 */
+	movl	$0, %ebx
+.L2:	movl	%edi, %esi
+	shr	$22, %esi
+	movl	0xF03C0000(,%esi, 4), %eax
+	cmpl	$0, %eax
+	jne	.L1
+	movl	_MmGlobalKernelPageDirectory(,%esi, 4), %eax
+	movl	%eax, 0xF03C0000(,%esi, 4)
+.L1:
+	addl	$4096, %edi
+	incl	%ebx
+	cmp	$(MM_STACK_SIZE / 4096), %ebx
+	jl	.L2
+		
 	/*
 	 * FIXME: Restore floating point state
 	 */

[ros-kernel] Disk layout continued

[Robert K. <ro...@ko...>]

Hi, I'd like to warm up the theme about Directory structure and multiple
installations, again.

Hyper and I had a discussion in this context, and I want to give us a base
via posting it.
Conclusion up to now is:
-very different views for some ss
-multiple distinct installations should be possible on one partition but
cause dir-inconsistency (who has the true view)

Let's start clearing this problem.,


do you think we should continue that discussion about directory structure?

NonVolatil: yes
KJK::Hyperion: I have five queued messages
maybe we should ask first :-)
NonVolatil: I think we should define the structure as early as possible
and diverge the sturcute to have no overfilled dirs
*** KJK::Hyperion signed off at Wed Apr 24 21:38:43 2002.
*** KJK::Hyperion signed on at Wed Apr 24 21:38:53 2002.
KJK::Hyperion: yes, I agree
the earlier, the better
KJK::Hyperion: about Unix dirs...
I think they *really* should stay in the disk root. All systems with a
POSIX subsystem (MacOS/X, QNX, BeOS) do that, I don't see why we have to
differ
NonVolatil: here agein
KJK::Hyperion: heh
NonVolatil: moment I have a call......
KJK::Hyperion: that's ok
NonVolatil: Here I am again. Female phone partners never find an end
KJK::Hyperion: hehehehehehehehe
how true
NonVolatil: what now............
NonVolatil: I don't want to pollute the root
KJK::Hyperion: the root is no-one's land
NonVolatil: This is one of the advances of NT over OS/2 for example. You
can install multiple installations on one parttion
NonVolatil: W2k gave this adv. away in some parts
NonVolatil: AND I want to have a subdir for each sub system, also win32
KJK::Hyperion: Win32 can, by design, be installed everywhere
Unix systems cannot. They have a rigid structure, and more important
there's no way to determine dynamically the location of directories
NonVolatil: thats ok and unchangeable. But with virtual dirs there is a
possibility to locate the real dirs under the OS' dir
KJK::Hyperion: virtual directories are an administration and programming
hell
NonVolatil: i don't think so
NonVolatil: 'cos a programmer of a certain ss knows what he knows
KJK::Hyperion: they introduce yet another special file system object, for
example
NonVolatil: not needed
*** Error while sending IM: Rate to client
NonVolatil: for example NT's os2 ss does souch a thing with CONFIG.SYS
NonVolatil: The os2 ss creates a virtual config.sys form a key in the
registry.
KJK::Hyperion: this is hideous
NonVolatil: So every NT installation has its own config.sys - which was
the intention
NonVolatil: hideous?
KJK::Hyperion: horrible
KJK::Hyperion: what path has this fake config.sys?
NonVolatil: X:\
NonVolatil: ?
NonVolatil: I know...you are imaging yourself a posix only version
KJK::Hyperion: do they take in account all the possible paths?
X:\dir\..\config.sys? X:\config.sys.? X:\dir1\dir2\..\..\config.sys?
NonVolatil: OS/2's config.sys resides in the boot drives root
KJK::Hyperion: what if some program reads it with an "indirect" path like
those? do you have to check every damn file open?
NonVolatil: whats an indierect path?
KJK::Hyperion: the dot and double-dot entries, for example
NonVolatil: the ss's open implementation has to monitor if a special file
is opened and treat that differently.  - Its possible but hard
KJK::Hyperion: X:\..\..\dir\.\dir2\..\.\..\config.sys....

this is the same as X:\config.sys
NonVolatil: oh, yes, they are
NonVolatil: I don't know if it is possible in nt
NonVolatil: but it is pain
KJK::Hyperion: with a little sacrifice no more problems
NonVolatil: Its difficult if you think of a posix or os2 only version. But
this would mean that you can boot different systems with win32 but the
other ss remain the same - or even more evil refuse to function in the
other version
KJK::Hyperion: there's another problem with the "every SS has its root"
approach. That they cannot work together
NonVolatil: was it you who told us about the other POSIX 2 compiant ss
taken by M$
NonVolatil: if they share the same root ?
KJK::Hyperion: if they share the same root, file paths can be exchanged
freely with little or no processing required
NonVolatil: what do you mean with  that?
KJK::Hyperion: POSIX+ for example already accepts both the backslash and
forward slash as path separator. A path like \home\hyperion\desktop is
both a valid Win32 and a valid POSIX path
NonVolatil: lets talk baout your ss. which dirs are required?
KJK::Hyperion: technically, none. Only the root and /tmp. But for an
usable system, it needs /bin, /dev, /etc, /lib and /sbin. For full FHS
compliance, /boot, /home, /mnt and /opt are also required
KJK::Hyperion: and /usr, and /var, by the way
NonVolatil: tmp and usr may share the root. the others I think not
NonVolatil: dev may exist but be 'filled' by the ss
KJK::Hyperion: why not? I can guarantee you that it poses no problem at
all for existing programs
NonVolatil: The parallel install thing.
 And, as you said, other ss that use the same names
KJK::Hyperion: no other subsystem uses these names
NonVolatil: I can imagine a carbon ss. This will have tmp as darwin has
one
KJK::Hyperion: Darwin is Unix
NonVolatil: yes and so it requires different usr var etc etc.
NonVolatil: I don't like this either
KJK::Hyperion: but Carbon doesn't define standard directories
NonVolatil: Do you know MacOS? I don't
NonVolatil: But take for example the Cocoa API
*** Error while sending IM: Rate to client
KJK::Hyperion: A bit. It has directories like System, Applications, and a
few others. I think, apart from System, that other directories have no
special meaning
NonVolatil: is this for os X true, too?
KJK::Hyperion: yes. The root is something like this:
/bin
/etc
/lib
...
/Applications
...
NonVolatil: so darwin+MacOS
KJK::Hyperion: it's just that /bin, /etc, /lib, etc. are hidden
KJK::Hyperion: yes. They effectively have four concurrent subsystems:
POSIX, Carbon (old Mac), Cocoa (NeXTStep) and Aqua (new Mac)
KJK::Hyperion: and they use a single root
NonVolatil: ? I thought Carbon are old but  improved binarys. They use
Aqua for display. Cocoa are native apps and they use also Aqua for
display. Aqua is not a subsystem
KJK::Hyperion: Aqua is the subsystem, the display is called Quartz
and to support the old Mac they both have an emulation subsystem with
binary compatibility (Classic) and a native subsystem with source
compatibility (Carbon)

[ros-kernel] NT-compatible filesystem mount mechanism

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

This is the patch for the NT-compatible mount mechanism. You can use the old
mechanism by commenting-out the '#define NT_MOUNT' lines.

Eric

[ros-kernel] NT-compatible filesystem mount mechanism

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

Hi!

Hartmut Birr provided some useful hints about mounting filesystems in an
NT-compatible way. I modified ntoskrnl/io/create.c and
services/fs/vfat/fsctl.c to implement the NT-compatible mount mechanism.

Unfortunately ReactOS still doesn't boot properly. I found that the vfat-fs
driver starts searching for files from the boot sector instead of the root
directory. It seems that the start sector (or cluster) of the root directory
is not initialized properly but set to zero. The debug output in the mount
code returns the correct value for 'RootStart'.

I want to commit the required modifications so that anyone can check it. The
modifications can be enabled/disabled via '#define NT_MOUNT'.

Any ideas or comments?


Eric

[ros-kernel] CVS Commit: reactos

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

Modified files:
    system.hiv
    subsys/smss/init.c
    subsys/smss/smss.c
    subsys/smss/smss.h

Read settings from the registry.

Eric

[ros-kernel] Re: csrss explained

[Aliberti E. <ea...@us...>]

> /* Pseudo code for a call:
> 
> CSR_CCS svrapi;
> NTSTATUS Status;
> DWORD data[16];
> 
> svrapi.ServerId = CSR_SERVER_WINDOWS_CONSOLE;
> svrapi.Index = 0x0208; // GetConsoleMode()
> 
> Status = CsrClientCallServer (data, NULL, svrapi, sizeof data);
> 
> */

I made a mistake: for 1/0x0208 the correct data size is

DWORD data[4];

that is 16 bytes.

[ros-kernel] csrss explained

[Aliberti E. <ea...@us...>]

CSRSS Explained
---------------

This is very basic overview of the csrss.exe internals.

A thing to keep in mind is that, at the origins of NT, there was a 
single user-mode server that made environment subsystems live. That 
is why the meta-server is still called "client/server runtime" (CSR) 
even if actually now is the runtime exclusively for the Win32 server.

Today you can see its command line in

HKLM\SYSTEM\CurrentControlSet\Control\
  Session Manager\Subsystems\Windows

I write it down here (from an NT 4.0 system):

%SystemRoot%\system32\csrss.exe
  ObjectDirectory=\Windows
  SharedSection=1024,3072
  Windows=On
  SubSystemType=Windows
  ServerDll=basesrv,1
  ServerDll=winsrv:UserServerDllInitialization,3
  ServerDll=winsrv:ConServerDllInitialization,2
  ProfileControl=Off
  MaxRequestThreads=16

In those days, if I was going to write a new environment subsystem, I 
just needed to write a DLL and add one more parameter to that key

ServerDll={module}[:{entrypoint}],{subsystem_id}

where

{module} is the server DLL file name without ".dll" suffix;

{entrypoint} is optional and needs to be specified only if the DLL 
does not export the symbol "ServerDllInitialization" (winsrv.dll 
contains two servers);

{subsystem_id} is a nonnegative integer to be used in 
NTDLL.CsrClientCallServer to specify the subsystem to the which the 
LPC message is sent to:

The key element in this entry is the subsystem_id, because it allows 
the client side DLLs to communicate with a server side DLL loaded by 
csrss.exe.

Id 0 is only used in NTDLL.DLL itself to call service code in 
CSRSS.EXE;

Id 1 and 2 are used in KERNEL32.DLL;

Id 3 is used in USER32.DLL and probably other libraries.

To call service number n in a server DLL loaded with server number m 
you just need to fill a CSR_CCS object and pass it (by value) as the 
3rd parameter of NTDLL.CsrClientCallServer().

/* CSRSS basics */

typedef struct _CSR_CCS
{
    WORD  Index;	   // API number 
    WORD  ServerId;  // Server's ID

} CSR_CCS, * PCSR_CCS;

#define CSR_SERVER_INTERNAL         0
#define CSR_SERVER_WINDOWS_BASE     1
#define CSR_SERVER_WINDOWS_CONSOLE  2
#define CSR_SERVER_WINDOWS_USER     3

NTSTATUS STDCALL
CsrClientCallServer(
    PVOID   RequestData,
    PVOID   Unknown OPTIONAL, // Csr capture facility related
    CSR_CCS SvrApi,
    ULONG   SizeOfRequestData
    );

/* Pseudo code for a call:

CSR_CCS svrapi;
NTSTATUS Status;
DWORD data[16];

svrapi.ServerId = CSR_SERVER_WINDOWS_CONSOLE;
svrapi.Index = 0x0208; // GetConsoleMode()

Status = CsrClientCallServer (data, NULL, svrapi, sizeof data);

*/

Just like in ReactOS, in NT, NTDLL.CsrClientCallServer() uses the LPC 
facility.

Re: [ros-kernel] Freeldr path fixes.

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

The problem was with FreeDOS' processing of boot.bat (batch file
processing). It's now fixed - if you download ReactOS + Bochs on
reactos.com, one of the boot disks available in the package boots
FreeDOS.

- Jason

--- Eric Kohl <ek...@rz...> wrote:
> 
> "Nick Date" <nic...@ya...> wrote:
> 
> > Ah, I see the error of my ways - I didn't set up the makefile to
> build
> > loadros. Just one thing, though - I know there were some issues
> booting
> ROS
> > from FreeDOS. Do you know if this has been resolved yet or if
> it's just
> one
> > of those things?
> 
> I never tried FreeDOS and I don't know about FreeDOS-related bugs
> in
> loadros. Sorry!
> 
> Eric
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas --
> http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: [ros-kernel] Problems with the last changes (mdl.c..)

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	David Welch [SMTP:we...@cw...]
> Gesendet am:	Dienstag, 21. Mai 2002 02:23
> An:	rea...@li...
> Betreff:	Re: [ros-kernel] Problems with the last changes (mdl.c..)
>
> I don't think this fixes all the
> problems however since, in principle, a thread could be switched to while 

> it is attached to a different process.

This means, at each position where KeAttacheProcess is called, there must 
be disable all thread switching.

> Would it be possible to try the
> attached patch instead?

The patch solves my problem. But there exist two other problems. The patch 
does not check if the stack is in kernel or in user space and there exist a 
problem if the stack is located over a 4MB boundary. I think the real 
problem is, that the mapping for the stack is created within the wrong 
proccess context. My second patch solve this problem, but it must disable a 
warning for bad mappings.

- Hartmut


 

[ros-kernel] CVS Commit: reactos

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

Modified files:
    include/ddk/iotypes.h

Fixed Unload routine prototype.


Eric

RE: [ros-kernel] Problems building freeldr

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

I believe that the latest version of NASM is v0.98.32. I have only used
v0.98 however. It may be that the new version of NASM is trying to
optimize my boot sector code for me and generating extra instructions in
doing so. I'll download the new version of NASM and see what it is
doing. In the mean time you should be able to assemble it just fine with
v0.98.

As for the install/header file problems you are having that's because
you are trying to compile it with DJGPP. You see, there are 3 parts to
freeldr. The boot sectors (assemble with NASM), freeldr (compile with
DJGPP), and the installer (compile with Mingw32). I really should remove
the top-level makefile because it just seems to cause confusion, but it
will be useful once freeldr can be compiled with Mingw32. So to solve
your install/header file problems you will need to switch over to
Mingw32 to compile the installer since it is Win32 code.

Brian

> -----Original Message-----
> From: rea...@li...
[mailto:reactos-kernel-
> ad...@li...] On Behalf Of Nick Date
> Sent: Tuesday, May 21, 2002 7:11 AM
> To: rea...@li...
> Subject: Re: [ros-kernel] Problems building freeldr
> 
> Hi Casper,
> 
> ----- Original Message -----
> From: "Casper Hornstrup" <ch...@us...>
> To: <rea...@li...>
> Sent: Tuesday, May 21, 2002 1:01 PM
> Subject: Re: [ros-kernel] Problems building freeldr
> 
> [snip]
> 
> > > I have no idea whatsoever what the "TIMES value is negative" error
is
> all
> > > about. My assembler knowledge is very limited. The line in FAT.ASM
> reads
> ...
> > >
> > >     times 510-($-$$) db 0   ; Pad to 510 bytes
> > >
> >
> > I have never seen this before. Which nasm version are you using? My
best
> > guess is that fat.asm assembles to a binary larger than 510 bytes.
> 
> I'm using the latest version of NASM (3.0.5?). I've managed to compile
the
> freeldr part of the program and have found that the problem with the
TIMES
> value is related to the bootsect directory and the missing/bad path
for
> header problems is related to the install part of freeldr.
> 
> Where's Brian Palmer when you need him? :-) If and when I get freeldr
> working I'll submit any tweaks here so that someone can update the
CVS.
> It's
> just a pity that loadros doesn't seem to be in the tree anymore cos I
> can't
> load ros! ;-)
> 
> Thanks again for your help, Casper.
> 
> Nick.
> 
> --
> Nick Date
> Bath, England, UK
> 
> 
> 
> 
> ---
> Outgoing mail is certified virus free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.363 / Virus Database: 201 - Release Date: 21/05/2002
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Freeldr path fixes.

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

"Nick Date" <nic...@ya...> wrote:

> Ah, I see the error of my ways - I didn't set up the makefile to build
> loadros. Just one thing, though - I know there were some issues booting
ROS
> from FreeDOS. Do you know if this has been resolved yet or if it's just
one
> of those things?

I never tried FreeDOS and I don't know about FreeDOS-related bugs in
loadros. Sorry!

Eric