reactos-kernel

RE: [ros-kernel]ROS and Wine

[Mike S. <Mi...@qf...>]

> I'm working on it though I haven't actually done anything 
> since January. My
> general approach was to rewrite code from WINE to work in 
> win32k.sys. What
> advantage would be gained by moving to wineserver? I thought that all
> USER objects were unique to a process.

The wineserver stuff is just to make sure that the handles can be
used between different processes.  The ROS win32k.sys code probably
should use a handle table stored against the process desktop
rather than the process itself (it might do this - I haven't
looked extensively).

The nice thing about using the Wine approach is that all the USER
objects are allocated on the process heap so that you don't need
to go to ring0 just to call GetWindowLong (which will obviously
happen a lot).

I was just thinking that porting Wine rather than reworking it would
be a quicker (time wise) way to go.  I can see ways in which the
win32k.sys could be more efficient.

Mike.

Re: [ros-kernel]ROS and Wine

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

tir, 2002-04-23 kl. 16:39 skrev Mike Shepherd:
> Hi All,
> 
> Just started playing with ROS and thought I'd have a look
> at how Wine fits in.  It looks like there is some initial
> Wine code in the tree - I'm presuming that this is not
> being worked on?
> 
> Initial thoughts :-
> 
> 	- The current (incomplete) user32.dll code calls
> 	  into win32k.sys which then allocates ATOMs and
> 	  Window structures in NonPagedPool (and are thus
> 	  inaccessible from user mode).

An atom is just an integer which specifies an index into a string table.
So they are accessible from user-mode; that is, the ATOMs are, but the
strings they represent are not. But then again, they don't need to
because only win32k.sys uses the strings. ntdll.dll has a user-mode atom
implementation for user-mode applications.

> 
> 	- Wine uses a per-process user_handles array (global array
> 	  above 200K???) and allocates all ATOMs and Windows
> 	  on the local heap.  It allocates all handles via
> 	  RPC-like calls to the wineserver via Unix domain sockets.
> 
> 	- Wine's implementation of most Window classes relies on
> 	  dereferencing the Window structure allocated (using their
> 	  WIN_GetPtr function)
> 
> 	- Message queue functions like PostMessage use RPC calls to
> 	  wineserver to allow for handles from other processes.

WINE is different because it is mostly (fully?) implemented in
user-mode. The ReactOS window manager implementation should be in
kernel-mode to have better performance. The Windows NT team made this
mistake - we don't have to. Also using RPC here sounds much more
expensive than two kernel-mode/user-mode transitions. E.g. you have to
marshal/unmarshal parameters.

> 
> Implementation ideas :-
> 
> 	- Remove the current user32.dll code and associated code in
> 	  win32k.sys etc. and replace with the relevant code from
> 	  Wine.

This is not just a copy/paste job, so why bother? Using WINE for
something as low-level as the window manager puts restrictions on the
design of the ReactOS window manager. If I had to choose, I would much
rather spend the time needed for adapting the WINE code for ReactOS, on
designing the window manager code properly - even if it takes longer.
Sure we can learn from the WINE implementation, but using its design is
IMO not worth it.

> 
> 	- Implement the wineserver using LPC as an extension to CSRSS.exe
> 	  (or does this belong in WinLogon.exe?).  Obviously only a small
> 	  subset of the wineserver messages are needed (most are for
> 	  synchronisation primitives that ROS implements anyway).

Who would communicate with the wineserver then? What is the point of
having wineserver messages in ReactOS?

We can use WINE modules that only use the Win32 API without any need to
make changes specific to ReactOS. If we can agree with the WINE project
to use the same headers, ReactOS developers can develop on the shared
modules with less of a risk of breaking something for the WINE
developers (and vice-versa).

If we want to share lower-level user-mode modules we have to make the
kernel-mode APIs the same, which would mean having equal
ntdll/win32k.sys APIs. I'm not sure this is a good idea.

> 
> 	- Use existing ROS GDI infrastructure.
> 

This is required to have binary compatibility with Windows NT.

> 	- Presumably WinLogon or CSRSS need to do something like creation
> 	  of the Desktop and Desktop Window and monitor for Mouse and
> 	  Keyboard events and translate into Windows messages.
> 

In Windows NT, WinLogon creates the interactive windowstation and
desktops. Win32k.sys connects to mouse and keyboard.

> Doesn't look *too* difficult.  Does any of this sound at all sensible?
> Presumably I wouldn't be duplicating work here?
> 
> Mike.
> 
> [BTW: Shouldn't the list be setup with Reply-To being the list?]

No, because this puts more load on the mailing list servers. A decent
mail program has a reply-to-list funtion.

> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
> 

Re: [ros-kernel]ROS and Wine

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

Quoting Mike Shepherd <Mi...@qf...>:

> Hi All,
> 
> Just started playing with ROS and thought I'd have a look
> at how Wine fits in.  It looks like there is some initial
> Wine code in the tree - I'm presuming that this is not
> being worked on?
> 
I'm working on it though I haven't actually done anything since January. My
general approach was to rewrite code from WINE to work in win32k.sys. What
advantage would be gained by moving to wineserver? I thought that all
USER objects were unique to a process.

[ros-kernel]ROS and Wine

[Mike S. <Mi...@qf...>]

Hi All,

Just started playing with ROS and thought I'd have a look
at how Wine fits in.  It looks like there is some initial
Wine code in the tree - I'm presuming that this is not
being worked on?

Initial thoughts :-

	- The current (incomplete) user32.dll code calls
	  into win32k.sys which then allocates ATOMs and
	  Window structures in NonPagedPool (and are thus
	  inaccessible from user mode).

	- Wine uses a per-process user_handles array (global array
	  above 200K???) and allocates all ATOMs and Windows
	  on the local heap.  It allocates all handles via
	  RPC-like calls to the wineserver via Unix domain sockets.

	- Wine's implementation of most Window classes relies on
	  dereferencing the Window structure allocated (using their
	  WIN_GetPtr function)

	- Message queue functions like PostMessage use RPC calls to
	  wineserver to allow for handles from other processes.

Implementation ideas :-

	- Remove the current user32.dll code and associated code in
	  win32k.sys etc. and replace with the relevant code from
	  Wine.

	- Implement the wineserver using LPC as an extension to CSRSS.exe
	  (or does this belong in WinLogon.exe?).  Obviously only a small
	  subset of the wineserver messages are needed (most are for
	  synchronisation primitives that ROS implements anyway).

	- Use existing ROS GDI infrastructure.

	- Presumably WinLogon or CSRSS need to do something like creation
	  of the Desktop and Desktop Window and monitor for Mouse and
	  Keyboard events and translate into Windows messages.

Doesn't look *too* difficult.  Does any of this sound at all sensible?
Presumably I wouldn't be duplicating work here?

Mike.

[BTW: Shouldn't the list be setup with Reply-To being the list?]

Re: [ros-kernel]ReactOS Boot CD-ROM!

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

tir, 2002-04-23 kl. 14:50 skrev Eric Kohl:
> Hi!
> 
> We can now boot FreeLoader from a CD-ROM.
> 

Great! Nice work Eric!

> The bootsector uses the 'no emulation' mode and permits full access to the
> CD-ROM, just like the WinNT boot CD. Because the cdfs driver is not able to
> read files from a CD-ROM, we cannot boot ReactOS yet.
> 
> Some paths must be hardcoded into the bootsector (ISOBOOT.BIN) and
> bootloader (aka FREELDR.SYS). Therefore I would like to suggest the
> following directory structure for ReactOS CDs:
> 
> \REACTOS:
> Location for all kernel-mode components (ntoskrnl, hal, drivers,
> configuration files) that are used for booting. I don't think we need
> architecture-specific directories (i386, alpha, ppc, mips, ia64, etc.)
> because one CD should support only one architecture.
> 
> \REACTOS\SYSTEM32:
> Location for user-mode compoments (ntdll.dll and smss.sys) that are used for
> booting. In this case smss.exe is the renamed text-mode installation program
> usetup.exe.
> 

I agree with this.

> \INSTALL:
> Location for all packed installation files (.cab files?).
> 

I like the Win9X distribution method which uses .CAB files. The 10.000+
files on the Windows NT 4.0 CD-ROM are really anoying ;o) The Cabinet
Manager in CVS can create cabinet files. It can even split cabinets into
disks and we can control which files go where. It supports no
compression (raw) and MSZIP compression. With MSZIP compression, the
ReactOS distribution is about 1/3 of its original size.

I would like to use the MicroSoft Installer for installation. Has WINE
started implementing this or should we write this from scratch? WINE can
install MS Office which AFAIK uses MSI, but I'm not sure of the details.

> \ (Root directory):
> Location for remaining files (autorun.inf, readme.txt, etc.)
> 

Ok, but I would like to keep the number of files in the root directory
to a minimum.


I guess we will have ISO images of v0.0.20 for download then ;o)

[ros-kernel]ReactOS Boot CD-ROM

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

Hi!

We can now boot FreeLoader from a CD-ROM.

The bootsector uses the 'no emulation' mode and permits full access to the
CD-ROM, just like the WinNT boot CD. Because the cdfs driver is not able to
read files from a CD-ROM, we cannot boot ReactOS yet.

Some paths must be hardcoded into the bootsector (ISOBOOT.BIN) and
bootloader (aka FREELDR.SYS). Therefore I would like to suggest the
following directory structure for ReactOS CDs:

\REACTOS:
Location for all kernel-mode components (ntoskrnl, hal, drivers,
configuration files) that are used for booting. I don't think we need
architecture-specific directories (i386, alpha, ppc, mips, ia64, etc.)
because one CD should support only one architecture.

\REACTOS\SYSTEM32:
Location for user-mode compoments (ntdll.dll and smss.sys) that are used for
booting. In this case smss.exe is the renamed text-mode installation program
usetup.exe.

\INSTALL:
Location for all packed installation files (.cab files?).

\ (Root directory):
Location for remaining files (autorun.inf, readme.txt, etc.)




HOW TO create a bootable ReactOS CD-ROM
---------------------------------------

I suggest you use a CD-RW rather than a CD-R because you can reuse the
former one. This is important when you want to participate in writing the
startup (FreeLoader.sys) and install (usetup.exe) code.

This description is based on a german NERO 5.0 and 5.5, so some terms might
not be translated properly. Other programs, like WinOnCD, should provide
similar functionality.

1.) Create a new 'disk'. If the disk wizard pops up, close it and choose
'CD-ROM (boot)' on the left side of the dialog.

2.) Click the 'boot options' tab, click 'Image file' and select
'isoboot.bin' from your 'freeldr/bootsect' directory. Then change the
emulation type to 'no emulation' and the 'number of boot sectors' to 4.
(Note: IMO, this is a bug because the sector size of a CD-ROM is 2048 bytes,
not 512 bytes. The number of bootsectors should be 1.)

3.) Click the 'create' button to close the dialog. A new browser window for
the CD-ROM opens.

4.) Create a new directory 'I386' in the CD-ROM browser window.

5.) Add the files FREELDR.SYS and I386 directory and add FREELDR.INI to the
root directory of the CD-ROM.

6.) Now you can save your settings.

7.) Write the CD-ROM.

When you boot the CD, you should see the well known FreeLoader boot menu.
The suggested directory structure and the instructions to create a bootable
CD differ a little due to the hardcoded paths in the bootsector and
bootloader.

I can provide a packed iso image if you don't dare to build your own CD.


Comments, ideas and suggestions are welcome!


Regards,
Eric Kohl

[ros-kernel]CVS Commit: freeldr

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

Added files:
    freeldr/fs/iso.c
    freeldr/fs/iso.h

Modified files:
    freeldr/disk/partition.c
    freeldr/fs/fs.c
    freeldr/fs/Makefile
    freeldr/disk.h
    freeldr/fs.h

Added ISO-9660 support.


Eric

[ros-kernel]test again

[James T. <jim...@ad...>]

test

[ros-kernel]FW: Changes in ke\timer.c for handling system time ajusting

[Genadi V. Z. <mg...@po...>]

static VOID
HandleExpiredTimer(PKTIMER current, BOOLEAN Relative)
{
	// ..............................

	// ..............................

	if (current->Period != 0)
	{
		if (Relative)
			current->DueTime.QuadPart -= (LONGLONG) current->Period *
SYSTEM_TIME_UNITS_PER_MSEC;
		else
			current->DueTime.QuadPart += (LONGLONG) current->Period *
SYSTEM_TIME_UNITS_PER_MSEC;
	}
	// ..............................

	// ..............................

}

VOID KeExpireTimers(VOID)
{
	LARGE_INTEGER SystemTicks;	/* this tick's time */
	LARGE_INTEGER CurrentTime;
	PLIST_ENTRY Entry;
	PLIST_ENTRY Next;
	KIRQL oldlvl;

	KeQueryTickCount(& SystemTicks);	/* for relative time. */
	KeQuerySystemTime(& CurrentTime);		/* for absolute time. */

	KeRaiseIrql(HIGH_LEVEL, & oldlvl);
	KeAcquireSpinLockAtDpcLevel(& TimerListLock);

	for (Entry = TimerListHead.Flink; Entry != & TimerListHead; Entry = Next)
	{
		PKTIMER Timer = CONTAINING_RECORD(Entry, KTIMER, TimerListEntry);
		const PLARGE_INTEGER pDueTime = (PLARGE_INTEGER) & Timer->DueTime;
		Next = Entry->Flink;

		if (RtlLargeIntegerLessThanZero(* pDueTime))
		{
			/* relative due time */
			if (RtlLargeIntegerLessThanZero(RtlLargeIntegerAdd(SystemTicks, *
pDueTime)))
				continue;
			/* work with expired timer object */
			HandleExpiredTimer(Timer, TRUE);
		}
		else
		{
			/* absolute due time */
			if (RtlLargeIntegerLessThan(CurrentTime, * pDueTime))
				continue;
			/* work with expired timer object */
			HandleExpiredTimer(Timer, FALSE);
		}
	}
	KeReleaseSpinLock(& TimerListLock, oldlvl);
}

NTKERNELAPI
BOOLEAN
KeSetTimerEx(
    IN PKTIMER Timer,
    IN LARGE_INTEGER DueTime,
    IN LONG Period OPTIONAL,	/* milliseconds */
    IN PKDPC Dpc OPTIONAL
    )
{
	KIRQL oldlvl;

	//DPRINT("KeSetTimerEx(Timer %x), DueTime: \n",Timer);
	KeAcquireSpinLock(& TimerListLock, & oldlvl);

	Timer->Dpc = Dpc;

#if 1
	Timer->DueTime.QuadPart = DueTime.QuadPart;
#else
	// todo: need handling system time ajusting.
	if (DueTime.QuadPart < 0)
	{
		LARGE_INTEGER SystemTime;	/* this tick's time */

		KeQuerySystemTime(& SystemTime);
		Timer->DueTime.QuadPart = SystemTime.QuadPart - DueTime.QuadPart;
	}
	else
		Timer->DueTime.QuadPart = DueTime.QuadPart;
#endif

	Timer->Period = Period;
	Timer->Header.SignalState = FALSE;
	if (! IsListEmpty(& Timer->TimerListEntry))
	{
		KeReleaseSpinLock(&TimerListLock, oldlvl);
		return TRUE;
	}
	InsertTailList(& TimerListHead, & Timer->TimerListEntry);
	KeReleaseSpinLock(& TimerListLock, oldlvl);

	return FALSE;
}

[ros-kernel]Changes in ke\timer.c for handling system time ajusting

[Genadi V. Z. <mg...@po...>]

static VOID
HandleExpiredTimer(PKTIMER current, BOOLEAN Relative)
{
	// ..............................

	// ..............................

	if (current->Period != 0)
	{
		if (Relative)
			current->DueTime.QuadPart -= (LONGLONG) current->Period *
SYSTEM_TIME_UNITS_PER_MSEC;
		else
			current->DueTime.QuadPart += (LONGLONG) current->Period *
SYSTEM_TIME_UNITS_PER_MSEC;
	}
	// ..............................

	// ..............................

}

VOID KeExpireTimers(VOID)
{
	LARGE_INTEGER SystemTicks;	/* this tick's time */
	LARGE_INTEGER CurrentTime;
	PLIST_ENTRY Entry;
	PLIST_ENTRY Next;
	KIRQL oldlvl;

	KeQueryTickCount(& SystemTicks);	/* for relative time. */
	KeQuerySystemTime(& CurrentTime);		/* for absolute time. */

	KeRaiseIrql(HIGH_LEVEL, & oldlvl);
	KeAcquireSpinLockAtDpcLevel(& TimerListLock);

	for (Entry = TimerListHead.Flink; Entry != & TimerListHead; Entry = Next)
	{
		PKTIMER Timer = CONTAINING_RECORD(Entry, KTIMER, TimerListEntry);
		const PLARGE_INTEGER pDueTime = (PLARGE_INTEGER) & Timer->DueTime;
		Next = Entry->Flink;

		if (RtlLargeIntegerLessThanZero(* pDueTime))
		{
			/* relative due time */
			if (RtlLargeIntegerLessThanZero(RtlLargeIntegerAdd(SystemTicks, *
pDueTime)))
				continue;
			/* work with expired timer object */
			HandleExpiredTimer(Timer, TRUE);
		}
		else
		{
			/* absolute due time */
			if (RtlLargeIntegerLessThan(CurrentTime, * pDueTime))
				continue;
			/* work with expired timer object */
			HandleExpiredTimer(Timer, FALSE);
		}
	}
	KeReleaseSpinLock(& TimerListLock, oldlvl);
}

NTKERNELAPI
BOOLEAN
KeSetTimerEx(
    IN PKTIMER Timer,
    IN LARGE_INTEGER DueTime,
    IN LONG Period OPTIONAL,	/* milliseconds */
    IN PKDPC Dpc OPTIONAL
    )
{
	KIRQL oldlvl;

	//DPRINT("KeSetTimerEx(Timer %x), DueTime: \n",Timer);
	KeAcquireSpinLock(& TimerListLock, & oldlvl);

	Timer->Dpc = Dpc;

#if 1
	Timer->DueTime.QuadPart = DueTime.QuadPart;
#else
	// todo: need handling system time ajusting.
	if (DueTime.QuadPart < 0)
	{
		LARGE_INTEGER SystemTime;	/* this tick's time */

		KeQuerySystemTime(& SystemTime);
		Timer->DueTime.QuadPart = SystemTime.QuadPart - DueTime.QuadPart;
	}
	else
		Timer->DueTime.QuadPart = DueTime.QuadPart;
#endif

	Timer->Period = Period;
	Timer->Header.SignalState = FALSE;
	if (! IsListEmpty(& Timer->TimerListEntry))
	{
		KeReleaseSpinLock(&TimerListLock, oldlvl);
		return TRUE;
	}
	InsertTailList(& TimerListHead, & Timer->TimerListEntry);
	KeReleaseSpinLock(& TimerListLock, oldlvl);

	return FALSE;
}

Re: AW: [ros-kernel]Fw: Boot problem with CVS changes from friday/saturday.

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

[A bit more explanation.]

Quoting we...@cw...:
> Yes, I agree. The problem is that the irq is unmasked then the
> interrupt flag is set then we go on to do a lot more processing. 
>
The same interrupt can then occur again before we have executed the handler
eventually overflowing the stack for a frequently occuring event.
 
> 1. Set per-interrupt flag.
> 2. If per-interrupt flag was already set, increment per-interrupt
> counter and
> return.
> 3. Enable interrupts.
> 4. Call device handler.
> 5. Check the per-interrupt counter, if greater than zero then goto to
> step 4.
> 6. Clear the per-interrupt flag.
> 7. Execute DPCs, APCs and thread dispatching.
> 
This is safe since: a) no more one (and a bit) instances of each interrupt
handler can be active at a time; b) DPCs and thread dispatches is done at
DISPATCH_LEVEL, APCs at APC_LEVEL so these can never be executed. 

The per-interrupt flag can be reduced to just a check that the irql level
is currently less than the priority of the interrupt and the interrupt
handler epilog can also check for queued instances of lower priority
interrupts.

Re: AW: [ros-kernel]Fw: Boot problem with CVS changes from friday/saturday.

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

Quoting Hartmut Birr <har...@te...>:

> I get the some crash at bochs and on real hardware withe adifferent
> error 
> message. The problem comes from the changes in ntoskrnl/ke/i386/irq.c,
> 
> ntoskrnl\ps\idle.c and hal\halx86\irql.c.
> 
Yes, I agree. The problem is that the irq is unmasked then the interrupt
flag is set then we go on to do a lot more processing. For a quick fix we could 
move the cli/enable interrupt/sti sequence after the DPC/thread processing but
then the latency of individual interrupts would increase. The long term
solution is to process interrupts as NT (or at least the uniprocessor HAL) 
does; never touch the ISA PIC after initialization, set a flag during an
interrupt prolog set a flag saying that the handler is active and then enable 
interrupts, if another interrupt occurs while the handler is active then 
queue the interrupt up to be executed by the original handler, after the
original device handler and all queued interrupts have executed clear the flag
and do any non-interrupt specific processing like executing DPCs:-

1. Set per-interrupt flag.
2. If per-interrupt flag was already set, increment per-interrupt counter and
return.
3. Enable interrupts.
4. Call device handler.
5. Check the per-interrupt counter, if greater than zero then goto to step 4.
6. Clear the per-interrupt flag.
7. Execute DPCs, APCs and thread dispatching.

AW: [ros-kernel]Fw: Boot problem with CVS changes from friday/saturday.

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

I get the some crash at bochs and on real hardware withe adifferent error 
message. The problem comes from the changes in ntoskrnl/ke/i386/irq.c, 
ntoskrnl\ps\idle.c and hal\halx86\irql.c.

- Hartmut

[ros-kernel]Fw: Boot problem with CVS changes from friday/saturday.

[art y. <ay...@gm...>]

Begin forwarded message:

Date: Sun, 21 Apr 2002 22:24:54 -0500
From: art yerkes <ay...@on...>
To: rea...@li...
Subject: Boot problem with CVS changes from friday/saturday.


I get the following stack trace when booting reactos on a clean build from
CVS.  My boot.lst is attached.  I was running on bochs-1.4, the latest
release from bochs.sf.net.

'cvs update -D "2 days ago" ntoskrnl' does not exhibit this problem, but
'cvs update -D "1 day ago" ntoskrnl' does.  The files modified during that
time were:

P ntoskrnl/io/flush.c
P ntoskrnl/io/rw.c
P ntoskrnl/io/vpb.c
P ntoskrnl/ke/i386/irq.c

The problem seems to be related to the stack depth at this point, but
I'm a little confused by the multiple _irq_handler_14 (ntoskrnl.exe:2f6e)
calls.  Could this be a difference in the simulated ide controller on
bochs 1.4?

(ldr/loader.c:1798) Module name is: \Modules\keyboard.sys                       
                                                                                
Loading blue.sys...                                                             
Stack underflow (tf->esp c008fff0 Limit c0090000)                               
Stack Segment Fault Exception: 12(0)                                            
CS:EIP 8:c00fd617 <hal.dll: 5617>                                               
cr2 c008ffec cr3 0 Proc: c015718a Pid: 1 <SYSTEM> Thrd: c0157aae Tid: 1         
DS 10 ES 10 FS 30 GS 10                                                         
EAX: 0000000d   EBX: cc98d4b8   ECX: 0000020d                                   
EDX: 0000000d   EBP: c0090010   ESI: 00000000                                   
EDI: c01c2cd8   EFLAGS: 00010097 kESP c008fff0 kernel stack base c0090000       
ESP c008fff0                                                                    
Frames: <ntoskrnl.exe: 2231>{<ntoskrnl.exe: 2f6e>}*29<ntoskrnl.exe: 2cc0>{<ntosk
rnl.exe: 2f6e>}*2<hal.dll: 54bd><hal.dll: 54db><ntoskrnl.exe: fb0f><\Modules\scs
iport.sys: 1daa><ntoskrnl.exe: 35a6f><\Modules\scsiport.sys: 1a1d><ntoskrnl.exe:
 328dc><ntoskrnl.exe: 32907><\Modules\class2.sys: 2d26><ntoskrnl.exe: 328dc><nto
skrnl.exe: 32907><\Modules\vfatfs.sys: 1080><\Modules\vfatfs.sys: 6b02><\Modules
\vfatfs.sys: 9bac><\Modules\vfatfs.sys: acb0><\Modules\vfatfs.sys: bc2c><\Module
s\vfatfs.sys: bdfc><ntoskrnl.exe: 328dc><ntoskrnl.exe: 32907><ntoskrnl.exe: 333e
1><ntoskrnl.exe: 16ac1><ntoskrnl.exe: 17073><\Modules\vfatfs.sys: 995f><\Modules
\vfatfs.sys: acb0><\Modules\vfatfs.sys: bc2c><\Modules\vfatfs.sys: bdfc><ntoskrn
l.exe: 328dc><ntoskrnl.exe: 32907><ntoskrnl.exe: 35ff1><ntoskrnl.exe: 3d6fa><nto
skrnl.exe: 3d313><ntoskrnl.exe: 3d008><ntoskrnl.exe: 3d258><ntoskrnl.exe: e695><
ntoskrnl.exe: e711><ntoskrnl.exe: ea76><ntoskrnl.exe: 117c>                     
                                                                                

[ros-kernel]CVS Commit: freeldr

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

Added files:
    bootsect/.cvsignore
    bootsect/isoboot.asm

Modified files:
    bootsect/Makefile
    notes.txt


Added cdrom bootsector.

[ros-kernel]CVS Commit: reactos

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

Modified files:
    ntoskrnl/io/device.c
    ntoskrnl/io/fs.c

Fixed a silly bug! I forgot to move an #include line. :-/

Eric

[ros-kernel]CVSWeb is working again!

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

Hi!

The CVSWeb (http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/ ) and Wiki pages
(http://mok.lvcm.com/cgi-bin/reactos/roswiki) are working again! :-)

Thanks a lot Rex!!

Eric

Re: [ros-kernel]CDROM bootsector

[Daniel G. <da...@fp...>]

On Fri, 19 Apr 2002 12:33:26 +0200
"Eric Kohl" <ek...@rz...> wrote:

> 
> "Daniel Gryniewicz" <da...@fp...> wrote:
> 
> > Well, there's always the fact that, once you've booted the CD, you
> generally
> > need to be able to access it to install or whatever.  For that, you need
> an
> > ISO driver.  Many up and coming OSs don't have ISO drivers (reactos among
> them
> > for now) so they, in the early stages, use Linux on their bootable CDs to
> > install.  All that takes is writing a driver for their prefered FS if
> Linux
> > does not already have one.
> 
> IMO there is no reason to use Linux to install ReactOS because a ISO-9660
> file system driver (cdfs.sys) is currently under construction.
> 
> 
> Eric Kohl
> 

Oh, I definitely agree.  I was merely mentioning why some OS projects use
Linux on bootable CD-ROMs.  If you have a ISO-9660 driver and an ATAPI driver,
you should definitely use your own and not someone elses. :)  (You here being
whoever is writing an OS)

Daniel
--- 
Recursion n.:
        See Recursion.
                        -- Random Shack Data Processing Dictionary

Re: [ros-kernel]CVS Commit(s): reactos

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

"Robert Collins" <rob...@it...> wrote:

> Seems to me that that could be useful for mounting ISO's.... is the
> restriction parameterised?

Yes, the restriction is parameterised as follows:
- FILE_DEVICE_DISK_FILE_SYSTEM can only be mounted to FILE_DEVICE_DISK and
FILE_DEVICE_VIRTUAL_DISK.
- FILE_DEVICE_CD_ROM_FILE_SYSTEM can only be mounted to FILE_DEVICE_CD_ROM.
- FILE_DEVICE_TAPE_FILE_SYSTEM can only be mounted to FILE_DEVICE_TAPE.
- FILE_DEVICE_NETWORK_FILE_SYSTEM can only be mounted to
FILE_DEVICE_NETWORK.

So the 'raw' file system driver will have to create one file system object
for each file system class (RawCdrom, RawDisk, RawIp, RawTape) to handle raw
mounts.


Regards,
Eric Kohl

Re: [ros-kernel]CDROM bootsector

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

"Daniel Gryniewicz" <da...@fp...> wrote:

> Well, there's always the fact that, once you've booted the CD, you
generally
> need to be able to access it to install or whatever.  For that, you need
an
> ISO driver.  Many up and coming OSs don't have ISO drivers (reactos among
them
> for now) so they, in the early stages, use Linux on their bootable CDs to
> install.  All that takes is writing a driver for their prefered FS if
Linux
> does not already have one.

IMO there is no reason to use Linux to install ReactOS because a ISO-9660
file system driver (cdfs.sys) is currently under construction.


Eric Kohl

RE: [ros-kernel]CVS Commit(s): reactos

[Robert C. <rob...@it...>]

> -----Original Message-----
> From: Eric Kohl [mailto:ek...@rz...]=20
> Sent: Friday, April 19, 2002 8:12 PM
> To: ReactOS-Kernel
> Subject: [ros-kernel]CVS Commit(s): reactos
>=20
>=20
> Modified Files:
>     ntoskrnl/io/device.c
>     ntoskrnl/io/fs.c
>=20
> Restricted mounting of file systems (e.g. don't try to mount=20
> a cdrom file system to a harddisk).

Seems to me that that could be useful for mounting ISO's.... is the
restriction parameterised?

Rob

[ros-kernel]CVS Commit(s): reactos

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

Modified Files:
    ntoskrnl/io/device.c
    ntoskrnl/io/fs.c

Restricted mounting of file systems (e.g. don't try to mount a cdrom file
system to a harddisk).
Moved helper functions of IoVerifyVolume().
Minor improvements to IoVerifyVolume().


Eric

[ros-kernel]CVS Commit: reactos

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

Modified file:
    ntoskrnl/io/xhaldrv.c

Fixed a typo that caused cdfs mounts to fail ('CdRom0' vs 'Cdrom0'). :-/
Removed old drive letter assignment code.


Eric

Re: [ros-kernel]CDROM bootsector

[Daniel G. <da...@fp...>]

On Wed, 17 Apr 2002 13:51:47 +0200
"Eric Kohl" <ek...@rz...> wrote:

> 
> "Michael Rich" <alp...@al...> wrote:
> 
> 
> > Here's an MS KB article on the subject.
> >
> >
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;q167685
> >
> 
> Modern cd-writer software does that for you. If your software supports the
> creation of bootable cds (El Torito format) you don't need to deal with
> this. IMO it seems to be a workaround for cd-writer software that doesn't
> support bootable cds.
> 
> Eric

Well, there's always the fact that, once you've booted the CD, you generally
need to be able to access it to install or whatever.  For that, you need an
ISO driver.  Many up and coming OSs don't have ISO drivers (reactos among them
for now) so they, in the early stages, use Linux on their bootable CDs to
install.  All that takes is writing a driver for their prefered FS if Linux
does not already have one.

Daniel

Re: [ros-kernel]CDROM bootsector

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

"Michael Rich" <alp...@al...> wrote:


> Here's an MS KB article on the subject.
>
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q167685
>

Modern cd-writer software does that for you. If your software supports the
creation of bootable cds (El Torito format) you don't need to deal with
this. IMO it seems to be a workaround for cd-writer software that doesn't
support bootable cds.

Eric