reactos-kernel

Re: [ros-kernel] Prototype conflicts in current wine port

[Rex J. <re...@lv...>]

At 07:30 PM 5/13/02 +0200, you wrote:
>man, 2002-05-13 kl. 17:49 skrev Steven Edwards:
> > I am having a little problem with my wine porting work and was wondering
> > [...]
> >
> > Wine/include/ntddk.h defines
> > INT __cdecl wcstol(LPCWSTR,LPWSTR*,INT);
      ^^^

> > While mingws include/stdlib.h defines
> > long  wcstol  (const wchar_t*, wchar_t**, int);
      ^^^^

perhaps the ntddk version is incorrect, as this function should return
a long int (LONG), not an int.


Rex Jolliff
re...@lv...

RE: [ros-kernel] Prototype conflicts in current wine port

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

> With my solution the trees won't need to differ. comdlg32 
> will simply use libwine_unicode on both platforms; and you 
> will need libwine_unicode on ReactOS anyway so this shouldn't 
> be a limitation.

This is true we will need libwine_unicode.dll to be able to use
Wrc to compile the resources before we feed them to windress.
 
> It could be possible later on to have an optimized version of 
> libwine_unicode on ReactOS that uses the msvcrt functions, 
> but that's probably not very high priority right now...

No its not. The high priority for us is the gcc self-hosing and 
Getting winhello working.

Thanks
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel] Prototype conflicts in current wine port

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

> Since this is a standard C runtime library function, I 
> consider the MinGW to be more correct. LPCWSTR etc. are WinNT 
> types, not stdc types. Does the WINE team have a problem with 
> changing their stdc prototypes?

The solution that Alexandre will accept for the
Wine tree is this: 

> I think the right way would be to put that functionality in 
> libwine_unicode, and follow the naming convention that we are 
> using there (for instance wcstol would be strtolW). This way 
> we are sure the prototypes won't conflict.

This most likely will be the law of the land unless you can change
Alexandre's mind. <g>

I will be starting bugs in wine's bugzilla when ever I find a 
Prototype conflict. This may be a case where the ReactOS projects 
Wine tree will differ. Right now I just want to get the damn thing 
Built right on mingw and I doubt I can make all of the changes that 
are needed anyway.

As of right now if we were to do a import of the wine tree the only 
Thing we would need to change is this, a few other prototypes and 
The debugging interfaces for the wine tree. The wine resources are 
no longer a issue nor is most of the mingw buggy-ness (Thanks again
Alexandre). 
I have only two small patches to mingws basetsd.h and windef.h 
to shutup some warnings. I will be submitting a TODO doc in the 
Next few days to outline where we are at and what is left to do.

Once again none of this really matters for us without simple windowing
(Hint,Hint)

Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

[ros-kernel] Port of the wine regression testing framework.

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

http://bugs.codeweavers.com/show_bug.cgi?id=528
Running C regression tests on Windows with Cygwin/MinGW

Alexandre Julliard commited changes for mingw-cross compiling and Jakob 
Eriksson is making additional changes. 

Once it is ready I will be doing testing of the mingw wine port and
David 
Kredba will be the tester of the framework for the Mingw/ReactOS port.

Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

Re: [ros-kernel] Prototype conflicts in current wine port

[Alexandre J. <jul...@wi...>]

"Steven Edwards" <Ste...@ya...> writes:

> > Since this is a standard C runtime library function, I 
> > consider the MinGW to be more correct. LPCWSTR etc. are WinNT 
> > types, not stdc types. Does the WINE team have a problem with 
> > changing their stdc prototypes?

We can't change the prototypes because wchar_t is 4 bytes under Unix,
but we really need 2 bytes WCHARs here. But yes, the problem is with
Wine, not with Mingw; we'll simply have to use different functions
here so that the prototypes don't conflict.

> I will be starting bugs in wine's bugzilla when ever I find a 
> Prototype conflict. This may be a case where the ReactOS projects 
> Wine tree will differ.

With my solution the trees won't need to differ. comdlg32 will simply
use libwine_unicode on both platforms; and you will need
libwine_unicode on ReactOS anyway so this shouldn't be a limitation.

It could be possible later on to have an optimized version of
libwine_unicode on ReactOS that uses the msvcrt functions, but that's
probably not very high priority right now...

-- 
Alexandre Julliard
jul...@wi...

AW: [ros-kernel] crash within MmOpenMemoryAreaByAddress

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

> -----Ursprungliche Nachricht-----
> Von:	we...@cw... [SMTP:we...@cw...]
> Gesendet am:	Montag, 13. Mai 2002 15:43
> An:	rea...@li...
> Betreff:	Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress
>
> I think it would be preferable to commit without known bugs. Why not post 
the
> code to the list or commit to a seperate branch of the repository so more
> people can help with debugging without having to break existing 
functionality.

Hi,

for testing, I've attached two patches. The first (fastmutex.patch) changes 
the lock for the address space from a MUTEX to a FAST_MUTEX and calls 
KeBugCheck, if there is a recursive locking for the same thread. After the 
command 'gcc -o rdel.o rdel.c -o -pipe' occurs the recursive locking of a 
address space. The call to KeBugCheck is only for printing a stack trace. 
Without the call, there is a dead lock at this point. The second patch 
(mdl-fix.patch) does add a KeRaiseIrql/KeLowerIrql for MmMapLockedPages/  
MmUnmapLockedPages. With this patch, gcc works. There exist more points 
with a locked address space, which can also result in a corrupt memory area 
list, if there is a thread switching and a next access to the address 
space.

- Hartmut

 

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

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

man, 2002-05-13 kl. 20:33 skrev Casper Hornstrup:
> man, 2002-05-13 kl. 15:43 skrev we...@cw...:
> > Quoting Casper Hornstrup <ch...@us...>:
> > > 
> > > This seem like a big change to the memory manager, so if nobody objects,
> > > then I would like to flush my changes to the memory manager to support a
> > > modified page writer. Unfortunatly the system, in it's current state, 
> > > deadlocks when the balance manager is run so it has to be disabled for now. 
> > > This means that paging to disk will not work until I or someone else get this 
> > > fixed. With the balancer disabled, it runs fine. Okay to commit?
> > > 
> > I think it would be preferable to commit without known bugs. Why not post the
> > code to the list or commit to a seperate branch of the repository so more
> > people can help with debugging without having to break existing functionality.
> 
> Yes, a seperate branch is better, I'll create one.

I have created a branch named "mpw" for this change.

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

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

man, 2002-05-13 kl. 15:43 skrev we...@cw...:
> Quoting Casper Hornstrup <ch...@us...>:
> > 
> > This seem like a big change to the memory manager, so if nobody objects,
> > then I would like to flush my changes to the memory manager to support a
> > modified page writer. Unfortunatly the system, in it's current state, 
> > deadlocks when the balance manager is run so it has to be disabled for now. 
> > This means that paging to disk will not work until I or someone else get this 
> > fixed. With the balancer disabled, it runs fine. Okay to commit?
> > 
> I think it would be preferable to commit without known bugs. Why not post the
> code to the list or commit to a seperate branch of the repository so more
> people can help with debugging without having to break existing functionality.

Yes, a seperate branch is better, I'll create one.

Re: [ros-kernel] Prototype conflicts in current wine port

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

man, 2002-05-13 kl. 17:49 skrev Steven Edwards:
> I am having a little problem with my wine porting work and was wondering
> if you guys could help with the solution. For the port of comdlg32 I
> have 1 error that must be fixed. 
> 
> Wine/include/ntddk.h defines
> INT __cdecl wcstol(LPCWSTR,LPWSTR*,INT);
> Which is a ntdll function.
> 
> 
> While mingws include/stdlib.h defines
> long	wcstol	(const wchar_t*, wchar_t**, int);
> Is based on msvcrt.
> 
> Any idea on how to fix it to use wines prototype or have another
> solution? I have at least 2 other cases I know about where the protoype
> is wrong.
> 
> Thanks
> Steven

Since this is a standard C runtime library function, I consider the
MinGW to be more correct. LPCWSTR etc. are WinNT types, not stdc types.
Does the WINE team have a problem with changing their stdc prototypes?

[ros-kernel] Prototype conflicts in current wine port

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

I am having a little problem with my wine porting work and was wondering
if you guys could help with the solution. For the port of comdlg32 I
have 1 error that must be fixed. 

Wine/include/ntddk.h defines
INT __cdecl wcstol(LPCWSTR,LPWSTR*,INT);
Which is a ntdll function.


While mingws include/stdlib.h defines
long	wcstol	(const wchar_t*, wchar_t**, int);
Is based on msvcrt.

Any idea on how to fix it to use wines prototype or have another
solution? I have at least 2 other cases I know about where the protoype
is wrong.

Thanks
Steven


"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

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

Quoting Casper Hornstrup <ch...@us...>:
> 
> This seem like a big change to the memory manager, so if nobody objects,
> then I would like to flush my changes to the memory manager to support a
> modified page writer. Unfortunatly the system, in it's current state, 
> deadlocks when the balance manager is run so it has to be disabled for now. 
> This means that paging to disk will not work until I or someone else get this 
> fixed. With the balancer disabled, it runs fine. Okay to commit?
> 
I think it would be preferable to commit without known bugs. Why not post the
code to the list or commit to a seperate branch of the repository so more
people can help with debugging without having to break existing functionality.

Moreover I'm not sure that Harmutt Birr's suggestion is the best way to fix the
problem: I would prefer to special case the Mm{Unmap,Map}LockedPages function
rather than burden large parts of the memory manager with having to run at
DISPATCH_LEVEL. Firstly we could have a identity map of the first 256MB to
map one page, low memory reguests very fast (as NT does) and secondly a
dedicated region with the page tables already set up which can be 
guarded with a spinlock.

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

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

s=F8n, 2002-05-12 kl. 13:50 skrev Hartmut Birr:
> Hi,
>=20
> sometimes ros does crash with assertions from MmOpenMemoryAreaByAddress.=20
> Normaly this can not occur because the address space is locked at any=20
> operation that will manipulate it. This does not work for recursive calls=
=20
> from the same thread, because the lock is a MUTEX. For testing I've it=20
> changed to a FAST_MUTEX and do print out the calling functions and the=20
> stack trace (KeBugCheck does this) at a recursive call from the same=20
> thread. A simple test with 'gcc -o rdel.o rdel.c -c -pipe' crashs ros. Th=
e=20
> recursive functions are MmUnmapLockedPages and MmMapLockedPages. It seems=
,=20
> that a locked address space also must disable the task switching. For=20
> testing, I've added a KeRaiseIrql/KeLowerIrql at each lock/unlock for the=
=20
> kernel address space. This solve the problem. I think we must change the=20
> handling for address spaces and memory areas. At many points, where the=20
> address space is locked (access and paging faults), there must be locked=20
> the memory area from the address space and not the address space itself.=20
> All changes within the address space must occur without thread switching=20
> (irql raise to DISPATCH_LEVEL). Some functions must be split for a short=20
> lock time of address spaces (MmFreeMemoryArea).
>=20
> Any ideas or comments?

This seem like a big change to the memory manager, so if nobody objects, th=
en
I would like to flush my changes to the memory manager to support a modifie=
d
page writer. Unfortunatly the system, in it's current state, deadlocks when=
 the
balance manager is run so it has to be disabled for now. This means that pa=
ging
to disk will not work until I or someone else get this fixed. With the bala=
ncer
disabled, it runs fine. Okay to commit?

RE: [ros-kernel] rosproj on reactos.dhs.org

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

Yeah I should modify it to give error messages. Did you create the
rosproj db in mysql? Run mysql and try "use rosproj" (without the
quotes). If it fails then the db hasn't been created properly - refer
to reactos.org/install.txt, I think it is.

- Jason

--- Steven Edwards <Ste...@ya...> wrote:
> OK I figured it out.
> http://reactos.dhs.org/rosproj/tables/tables.mysql.php doesn't give
> a
> error but it never builds the tables. Whats up with that? So of
> course
> the next step wont work. 
> Grrrr. Any ideas? When I run it from the command line php
> rosproj/tabels/tables.mysql.php I get this
> 
> root@www:/var/www/htdocs/rosproj/tables# php tables.mysql.php
> X-Powered-By: PHP/4.2.0
> Content-type: text/html
> 
> root@www:/var/www/htdocs/rosproj/tables#
> 
> Any help would be great.
> 
> Thanks
> Steven
> 
> "Every revolution was once a thought in one man's mind"
> - Ralph Waldo Emerson 
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> ban...@so...
> _______________________________________________
> 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] rosproj on reactos.dhs.org

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

Yes, inserts aren't using a very good style. I'll change it...
sometime. :)

- Jason

--- Rex Jolliff <re...@lv...> wrote:
> At 09:39 PM 5/12/02 -0400, you wrote:
> 
> > > Well, mysql (3.23.41) does not accept this (I just checked).
> > > Try putting NULL there (it is the project_id field).
> >
> >Put a NULL where? I looked in the initial_data.php and classes.inc
> but
> >couldn't find where I would need the NULL statement for project_id
> 
> You either need to specify data for all columns in the order they
> appear in 
> the table,
> or you need to specify the columns explicitly, for example (I don't
> know 
> column names,
> so ill make some up):
> 
> INSERT INTO modules
>    (module_id, insert_date, insert_user, module_name,
> module_description)
>    VALUES
>    (0, NULL, NULL, 'ReactOS', 'ReactOS');
> 
> Using this form, if you have nullable or defaultable columns, you
> dont need to
> specify them.  Also, you can add columns to a table without
> breaking all the
> code if explicit columns are used in inserts.
> 
> 
> >Thanks
> >Steven
> >
> >
> >_______________________________________________________________
> >
> >Have big pipes? SourceForge.net is looking for download mirrors.
> We supply
> >the hardware. You get the recognition. Email Us:
> ban...@so...
> >_______________________________________________
> >reactos-kernel mailing list
> >rea...@li...
> >https://lists.sourceforge.net/lists/listinfo/reactos-kernel
> 
> Rex Jolliff
> re...@lv...
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> ban...@so...
> _______________________________________________
> 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] rosproj on reactos.dhs.org

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

OK I figured it out.
http://reactos.dhs.org/rosproj/tables/tables.mysql.php doesn't give a
error but it never builds the tables. Whats up with that? So of course
the next step wont work. 
Grrrr. Any ideas? When I run it from the command line php
rosproj/tabels/tables.mysql.php I get this

root@www:/var/www/htdocs/rosproj/tables# php tables.mysql.php
X-Powered-By: PHP/4.2.0
Content-type: text/html

root@www:/var/www/htdocs/rosproj/tables#

Any help would be great.

Thanks
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel] rosproj on reactos.dhs.org

[Rex J. <re...@lv...>]

At 09:39 PM 5/12/02 -0400, you wrote:

> > Well, mysql (3.23.41) does not accept this (I just checked).
> > Try putting NULL there (it is the project_id field).
>
>Put a NULL where? I looked in the initial_data.php and classes.inc but
>couldn't find where I would need the NULL statement for project_id

You either need to specify data for all columns in the order they appear in 
the table,
or you need to specify the columns explicitly, for example (I don't know 
column names,
so ill make some up):

INSERT INTO modules
   (module_id, insert_date, insert_user, module_name, module_description)
   VALUES
   (0, NULL, NULL, 'ReactOS', 'ReactOS');

Using this form, if you have nullable or defaultable columns, you dont need to
specify them.  Also, you can add columns to a table without breaking all the
code if explicit columns are used in inserts.


>Thanks
>Steven
>
>
>_______________________________________________________________
>
>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>the hardware. You get the recognition. Email Us: ban...@so...
>_______________________________________________
>reactos-kernel mailing list
>rea...@li...
>https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Rex Jolliff
re...@lv...

RE: [ros-kernel] rosproj on reactos.dhs.org

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

> Well, mysql (3.23.41) does not accept this (I just checked). 
> Try putting NULL there (it is the project_id field).

Put a NULL where? I looked in the initial_data.php and classes.inc but
couldn't find where I would need the NULL statement for project_id

Thanks
Steven

Re: [ros-kernel] rosproj on reactos.dhs.org

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

s=F8n, 2002-05-12 kl. 17:47 skrev Rex Jolliff:
> At 03:50 PM 5/12/02 +0000, you wrote:
> >On Sun, May 12, 2002 at 01:00:30AM -0700, Steven Edwards=20
> >wrote:
> > > SQL: INSERT INTO modules VALUES (0, NULL, , NULL, 'ReactOS', 'ReactOS
> >                                            ^
> > > operating system.')
> > >
> >Doesn't something need to go there?
>=20
> Technically no, this form of INSERT implicitly selects all columns in the=
=20
> table
> for the insert.  But, it is usually a bad idea from a maintainability poi=
nt=20
> to use the
> abbreviated form of insert.  Similarly, its bad form to use '*' as a colu=
mn=20
> selector in
> a select statement.

Well, mysql (3.23.41) does not accept this (I just checked). Try putting
NULL there (it is the project_id field).

I executed the same script without errors btw.

Re: [ros-kernel] rosproj on reactos.dhs.org

[Rex J. <re...@lv...>]

At 03:50 PM 5/12/02 +0000, you wrote:
>On Sun, May 12, 2002 at 01:00:30AM -0700, Steven Edwards 
>wrote:
> > SQL: INSERT INTO modules VALUES (0, NULL, , NULL, 'ReactOS', 'ReactOS
>                                            ^
> > operating system.')
> >
>Doesn't something need to go there?

Technically no, this form of INSERT implicitly selects all columns in the 
table
for the insert.  But, it is usually a bad idea from a maintainability point 
to use the
abbreviated form of insert.  Similarly, its bad form to use '*' as a column 
selector in
a select statement.


Rex Jolliff
re...@lv...

Re: [ros-kernel] rosproj on reactos.dhs.org

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

On Sun, May 12, 2002 at 01:00:30AM -0700, Steven Edwards wrote:                                           
> SQL: INSERT INTO modules VALUES (0, NULL, , NULL, 'ReactOS', 'ReactOS 
                                           ^
> operating system.')
> 
Doesn't something need to go there?

Re: [ros-kernel] Re: Wineconf note I forgot to give you.

[Jakob E. <ja...@vm...>]

On Fri, May 10, 2002 at 09:46:15PM -0400, Steven Edwards wrote:
> 
> > Yeah, "only". :-)
> > That's the hard part for me. I've been avoiding configure
> > for years now, maybe it's time to take a bite...
> > If someone feels like helping out, please. :)
> 
> This is why I took a while to start submitting patches to wine. 
> I can hardly program as is and now am having to learn the whore
> That is GNU autoconf and Automake. I will try to help you port 
> The regression suite and Jason said he was interested also although
> I don't know how much time he can commit. 

Alexandre Julliard has hacked makefiles in Wine to allow crosscompiling
all of Wine. (But much wont compile of course. I have not tried it yet.)
So we are one step closer to automatic generation of EXEs of unit
tests for Windows and ReactOS.

-- 
regards,
Jakob Eriksson

The wages of sin
  is debugging.
		  	-- Ron Jeffries

AW: [ros-kernel] Need help with the file system mounting code!

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

Some times ago, I've tested vfatfs on NT. The mount procedure from vfatfs 
results in a BSOD. I've changed some lines in VfatMount (vfat/fsctl.c) for 
NT.

#ifdef __VFAT_NT__
  DeviceExt->StorageDevice = 
IrpContext->Stack->Parameters.Mount.DeviceObject;
  DeviceExt->StorageDevice->Vpb->DeviceObject = DeviceObject;
  DeviceExt->StorageDevice->Vpb->RealDevice = DeviceExt->StorageDevice;
  DeviceExt->StorageDevice->Vpb->Flags |= VPB_MOUNTED;
  DeviceObject->StackSize = DeviceExt->StorageDevice->StackSize + 1;
  DeviceObject->Flags &= ~DO_DEVICE_INITIALIZING;
#else
  DeviceObject->Vpb->Flags |= VPB_MOUNTED;
  DeviceExt->StorageDevice = IoAttachDeviceToDeviceStack(DeviceObject, 
IrpContext->Stack->Parameters.Mount.DeviceObject);
#endif

- Hartmut

[ros-kernel] crash within MmOpenMemoryAreaByAddress

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

Hi,

sometimes ros does crash with assertions from MmOpenMemoryAreaByAddress. 
Normaly this can not occur because the address space is locked at any 
operation that will manipulate it. This does not work for recursive calls 
from the same thread, because the lock is a MUTEX. For testing I've it 
changed to a FAST_MUTEX and do print out the calling functions and the 
stack trace (KeBugCheck does this) at a recursive call from the same 
thread. A simple test with 'gcc -o rdel.o rdel.c -c -pipe' crashs ros. The 
recursive functions are MmUnmapLockedPages and MmMapLockedPages. It seems, 
that a locked address space also must disable the task switching. For 
testing, I've added a KeRaiseIrql/KeLowerIrql at each lock/unlock for the 
kernel address space. This solve the problem. I think we must change the 
handling for address spaces and memory areas. At many points, where the 
address space is locked (access and paging faults), there must be locked 
the memory area from the address space and not the address space itself. 
All changes within the address space must occur without thread switching 
(irql raise to DISPATCH_LEVEL). Some functions must be split for a short 
lock time of address spaces (MmFreeMemoryArea).

Any ideas or comments?

- Hartmut

[ros-kernel] rosproj on reactos.dhs.org

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

Ok well its up....sorta. I dont know whats wrong but
when I run 
http://reactos.dhs.org/rosproj/initial_data.php
I get
Initial rights created
Initial roles created
Initial rights in roles created
Initial Projects created
Failed to insert into table: 1064: You have an error
in your SQL syntax near ' NULL, 'ReactOS', 'ReactOS
operating system.')' at line 1
SQL: INSERT INTO modules VALUES (0, NULL, , NULL,
'ReactOS', 'ReactOS operating system.')

http://reactos.dhs.org/rosproj/index.php runs but f
course there is no data.

Its 4 am. I need sleep
Peace

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

Re: [ros-kernel] reactos.com now in cvs!

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

At 19.04 11/05/2002, you wrote:
>ReactOS.com source is now available in cvs. Just cvs co reactos.com to 
>grab it. I didn't commit the sources for phorum because you can get that 
>off the web.

cool. It feels kind of strange "browsing" a site with CVS :-)
Just a quick remark: I think that index.html shouldn't be there. Much more 
tomorrow, I'm going to bed now

PS: BTW, I finally could get rosproj up and running. Yes, it required an 
updated PHP. Quick remark here too: the layout looks kind of funny in 
Opera. And I suggest you to write an exact specification of the workflow 
and behavior of rosproj while you still have control on it, otherwise we 
could end up with something like wwwGNATS: an usability nightmare. Joel 
Spolsky explains the importance of specifications better than I ever could 
dream of, and also gives useful hints on writing successful specs:
<http://www.joelonsoftware.com/navLinks/fog0000000247.html>