reactos-kernel

Re: [ros-kernel] Use or not use

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

man, 2002-05-27 kl. 10:15 skrev Jason Filby:
> This actually opens a wider discussion about header files and
> copyright in general. The only choice we really have is to go ahead
> and use the header file information. Copy and paste doesn't make a
> difference - since any kind of transformation still violates
> copyright - even if you retype everything, it's still transformation.
> We will just have to, if the time comes, defend our right to use
> header file information for the sake of compatibility. Here's a paper
> related to this point of view:
> 
> http://eu.conecta.it/paper/Open_source_copyright_law.html
> 
> My opinion at least (and the author of the paper).
> 
> - Jason

I hope that last sentence is correct; that header files are not
completely copyrightable. Next month, I will be contributing a free
Windows XP DDK to MinGW which is mostly copy/pasted from the Windows DDK
documentation. Unfortunatly, some needed structures are not documented
in the Windows DDK documentation. There are three cases: 1) The
structures are not mentioned in the Windows DDK documentation, only in
the header files. I have left most of these out since they are usually
not important. 2) The structures are mentioned in the Windows DDK
documentation, but only referenced by name from other structures. I have
included these, copy/pasted them from the header files. 3) Microsoft
seems to have a policy that constants are only mentioned by name in the
Windows DDK documentation, and they are defined in the header files, so
I have copy/pasted them from there.
The Windows DDK documentation explicitly states that you may not copy
any information in it without permission, but they will probably just
state this in order to keep us from trying.

- Casper

Re: [ros-kernel] Use or not use

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

This actually opens a wider discussion about header files and
copyright in general. The only choice we really have is to go ahead
and use the header file information. Copy and paste doesn't make a
difference - since any kind of transformation still violates
copyright - even if you retype everything, it's still transformation.
We will just have to, if the time comes, defend our right to use
header file information for the sake of compatibility. Here's a paper
related to this point of view:

http://eu.conecta.it/paper/Open_source_copyright_law.html

My opinion at least (and the author of the paper).

- Jason

--- "Robert K." <ro...@ko...> wrote:
> Hi, I followex Yuri's suggestion and had a look at emx.
> And in deed, there is an os2.h-File that contains the whole BaseAPI
> oa2emx.h
> One can optain the package there:
> http://hobbes.nmsu.edu/pub/os2/dev/emx/v0.9d/emxdev1.zip
> 
> The readme talks about GNU license and the os2-header has also no
> (C).
> But it is nearly sure that it was copy'n'pasted.
> 
> Bevore I start using it, give your comment.
> And how and where will the os2ss-module continue, since it is
> separated?
> 
> 
> _______________________________________________________________
> 
> 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!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

RE: [ros-kernel] Forward: "ReactOS is too limited"

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

At 08.08 26/05/2002, you wrote:
>Limited? Tell her

the message was from some guy that noticed Juliet's signature. BTW, here's 
her signature:

  < http://www.reactos.com/ >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                               and beta testers are welcome!

>to go look at the design of linux/unix kernels and
>then come look at ReactOS. Unix is 30 years old and good I'm not
>knocking it, I'm just saying NT is a newer better design in "some"
>areas. NT would be the shit if it wasn't for M$.

while I perfectly agree, I don't want to start a flame ;-) you know or may 
have heard of how "flammable" Usenet is

I liked Juliet's reply:

 > the true alternative would rather be building a new user-friendly
 > frontend to Linux/FreeBSD/Hurd

horror. I wish it will never happen, probably it could be what will make
me quit with computers and go back to drawing comics. The fact that Apple
did it and accomplished it (very debatably) doesn't mean it's easy, or
the best thing, or even that it works

Re: [ros-kernel] Forward: "ReactOS is too limited"

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

Yes, I have considered that. IBM is another company, Oracle too.

- Jason

--- "Robert K." <ro...@ko...> wrote:
> Jason, have you already thought about talking to AOL?
> I don't like their umpf rrrk program, but it seems to be a mighty
> company.
> 
> Since they are in battle with M$, now. It would make sense to them
> to support a different Windows.
> 
> I just thought that.
> 
> Jason Filby schrieb:
> 
> > Your OS can only run on machines and with components that there
> are
> > drivers for. NT has an overwhelming amount of drivers out there -
> and
> > I gave up on Slackware after two video cards didn't work because
> of
> > driver problems. Detected the right drivers.. but they just
> didn't
> > work.
> >
> > Legal suits: ok something similar to this came up on the
> discussion
> > board of reactos.com. Simply ReactOS is going to be more than a
> > battle of code. The ReactOS Foundation - which is still coming -
> will
> > be a big shield for individual developers. Commercial companies
> based
> > off of projects like ReactOS have financial resources to back
> legal
> > battles. Look at Lindows based off of WINE - they're willing to
> even
> > fight over the Windows trademark!
> >
> > Besides, we like ReactOS - working on it, seeing it grow and take
> > shape - and it's not going to go away.
> >
> > - Jason
> >
> > --- "KJK::Hyperion" <no...@li...> wrote:
> > >my dear friend, klan-mate, and silent ReactOS advocate Juliet
> > >forwards me some criticism to our project from the sunny land of
> > >Usenet:
> > >IMHO Reactos is too limited, it's doomed to an eternal pursuit
> to
> > >the NT-based kernel functionalities, and whenever it will become
> a
> > >vague menace to M$, it would be badly put down with legal suits,
> > >the true alternative would rather be building a new
> user-friendly
> > >frontend to Linux/FreeBSD/Hurd, like Apple did, only this time
> the
> > >frontend must be  made open source, and errors such as the
> > >scattering of resources happening with Gnome vs. KDE must be
> > >avoided this time
> > >
> > >Comments?
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.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
> 
> 
> _______________________________________________________________
> 
> 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!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[ros-kernel] Use or not use

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

Hi, I followex Yuri's suggestion and had a look at emx.
And in deed, there is an os2.h-File that contains the whole BaseAPI
oa2emx.h
One can optain the package there:
http://hobbes.nmsu.edu/pub/os2/dev/emx/v0.9d/emxdev1.zip

The readme talks about GNU license and the os2-header has also no (C).
But it is nearly sure that it was copy'n'pasted.

Bevore I start using it, give your comment.
And how and where will the os2ss-module continue, since it is separated?

Re: [ros-kernel] Forward: "ReactOS is too limited"

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

Jason, have you already thought about talking to AOL?
I don't like their umpf rrrk program, but it seems to be a mighty company.

Since they are in battle with M$, now. It would make sense to them
to support a different Windows.

I just thought that.

Jason Filby schrieb:

> Your OS can only run on machines and with components that there are
> drivers for. NT has an overwhelming amount of drivers out there - and
> I gave up on Slackware after two video cards didn't work because of
> driver problems. Detected the right drivers.. but they just didn't
> work.
>
> Legal suits: ok something similar to this came up on the discussion
> board of reactos.com. Simply ReactOS is going to be more than a
> battle of code. The ReactOS Foundation - which is still coming - will
> be a big shield for individual developers. Commercial companies based
> off of projects like ReactOS have financial resources to back legal
> battles. Look at Lindows based off of WINE - they're willing to even
> fight over the Windows trademark!
>
> Besides, we like ReactOS - working on it, seeing it grow and take
> shape - and it's not going to go away.
>
> - Jason
>
> --- "KJK::Hyperion" <no...@li...> wrote:
> >my dear friend, klan-mate, and silent ReactOS advocate Juliet
> >forwards me some criticism to our project from the sunny land of
> >Usenet:
> >IMHO Reactos is too limited, it's doomed to an eternal pursuit to
> >the NT-based kernel functionalities, and whenever it will become a
> >vague menace to M$, it would be badly put down with legal suits,
> >the true alternative would rather be building a new user-friendly
> >frontend to Linux/FreeBSD/Hurd, like Apple did, only this time the
> >frontend must be  made open source, and errors such as the
> >scattering of resources happening with Gnome vs. KDE must be
> >avoided this time
> >
> >Comments?
> >
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.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

[ros-kernel] CVS Commit: reactos

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

Modified files:
    ntoskrnl/io/xhaldrv.c
    services/storage/atapi/atapi.c
    services/storage/cdrom/cdrom.c
    services/storage/class2/class2.c
    services/storage/scsiport/scsiport.c

Log message:
    Silenced debug messages.
    Implemented command retries.
    Improved error handling.
    Enabled drive letter assignment to removable drives.
    Always update a drive's geometry data.


Eric

RE: [ros-kernel] Restructuring CVS Take 2

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

Ok we can remove the WINE module.. but where to move those makefiles?
Perhaps we should keep the WINE module just to keep things nicely
organized?

- Jason

--- Steven Edwards <Ste...@ya...> wrote:
> >> * Move WINE related DLLs now?
> 
> Well the WINE related stuff can really be blown away. We should
> keep the
> current makefiles
> But everything else in our wine tree can be zapped. We need to
> write a
> shell script to take the wine makefiles and convert them in to
> ReactOS
> makefiles.
> 
> We still will not be able to use wine untill some internal
> non-win32
> functions are fixed in the wine tree. 
> 
> I have put together a little guide for Wine/ReactOS hacking. Once
> we get
> a little more along I will break the guide up and make a Mingw
> Developer
> Guide for the WINE project and a ReactOS wine Hacker guide.
> 
> I will email more tommrow I'm kinda in a rush.
> 
> Thanks
> Steven
> 
> "Every revolution was once a thought in one man's mind"
> - Ralph Waldo Emerson 
> 
> > This document should contain all of the information needed for
you
> to start 
> developing wine on the Mingw platform. Almost all information in
> this guide
> applys to both the Mingw on Cygwin and Mingw for ReactOS ports.
> 
> This document assumes you are using cygwin to configure and build
> WINE for 
> a Mingw Target. Cygwin is enviroment used due to a set of bugs
> within the 
> Mingw Unix Enviroment MSYS. Msys may work however it, the ReactOS
> build 
> system and and any other configurations are not supported by the
> WINE project.
> 
> 
> REACTOS DEVELOPERS: 
> The ReactOS Project will try to do quarterly imports of the WINE
> tree after
> each ReactOS release. 
> 
> If you need to import the WINE sources in to the ReactOS build
> system or 
> want to build ReactOS with a newer copy of the WINE sources follow 
> these directions
> 
> (1) Run importwineros.sh on the most current wine sources
> (2) set the enviomental varible ROS_BUILD_WINE=1
> (3) Rebuild ReactOS sources as normal  
> 
> If you are adding funcationality to WINE, such as implementing a
> function in 
> a WINE dll that is currently a stub, you MUST use the Cygwin on
> Mingw enviroment 
> with the most current WINE sources. Any patches that add
> funcationalty to the 
> WINE dlls MUST first be accepted by the WINE project and follow the
> WINE projects 
> coding standards.
> 
> DO NOT SEND REACTOS SPICIFC CHANGES TO THE WINE PROJECT. 
> YOU HAVE BEEN WARNED. =P
> 
> Any ReactOS Spicifice changes in the REACTOS fork must be clearly
> marked and 
> should not be used unless there is no other way to work around the
> problem.
> 
> Example:
> #ifdef __REACTOS__
> ReactOS Spacific code
> #endif
> 
> 
> DEVELOPING WINE USING MINGW ON CYGWIN.
> 
> To start hacking on Wine for Mingw, follow the directions at
> www.winehq.com
> to download the most current WINE sources. 
> 
> (1) ./configure --host=mingw32 --target=mingw32 --build=mingw32
> CFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" CC="gcc
> -mno-cygwin" CXX="gcc -mno-cygwin"
> 
> 	Note: you may also be able to add --disable-debug --disable-trace
> flags to this command line.
> 
> (2) make depend
> 
> (3) make tools
> 
> 	MAKE TOOLS BUGS:
> 	BUG: libwine.dll needs to be linked to libmsvcrt.a and will fail
> 	FIX: copy /usr/local/lib/mingw/libmsvcrt.a to
> /usr/local/lib/libmsvcrt.a 
> 	add -lmsvcrt to wine/library/Makefile
> 
> 	BUG: winedump uses mmap and munmap which Windows Lacks
> 	FIX: Remove winedump from wine/tools/makefile
> 	 
> 	BUG: wmc and wrc need to be linked to libberty.a (getopt, optarg,
> optan)
> 	FIX: add -liberty to wrc and wmc Makefiles
> 
> 	BUG: Cygwins libberty.a is buggy 
> 	FIX: use the one from normal mingw
> 
> (4) cd programs && make
> 
> 	MAKE PROGRAMS BUGS:
> 	BUG: regsrv and wineconsole fail
> 	FIX: Remove them
> 
> 	BUG: uninstaller is buggy on the mingw port
> 
> (5) Make dlls
> So we have (user32) GetSysColorPen/wvsnprintf and (ntdll)
> wine_get_unix_file_name That need to be fixed. 
> These are not part of the Win32 and must be corrected in wine
> 
> 
> 
> 
> shlwapi needs imports from user32 that are not part of the
> win32api.
> wvsnprintfA@16
> wvsnprintfW@16
> 
> We can currently build
> comcat.dll
> crtdll.dll
> msisys.ocx
> netapi32.dll
> oledlg32.dll
> riched32.dll
> serialui.dll
> twain_32.dll
> wintrust.dll
> 
> 
> 
> TODO:
> - Wine Tree
> 	Fix programs/uninstaller
> 	Debugging and testing of Mingw port
> 	Winehq Mingw develoepr HOWTO
> 
> - ReactOS fork
> 	Write importwineros.sh script to convert wine Makefiles to ReactOS
> makefile's when doing a import.
> 	Write ReactOS wine developer HOWTO
> 
> - Cygwin
> 	Email Cygwin developers about liberty.a issue when building as
> mingw
> 	
> - Mingw
> 	Email Mingw Developers about warnings in basetsd.h and stdlib.h
> 	Send patch to Mingw Project about missing exports in user32


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

Re: [ros-kernel] Forward: "ReactOS is too limited"

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

Your OS can only run on machines and with components that there are
drivers for. NT has an overwhelming amount of drivers out there - and
I gave up on Slackware after two video cards didn't work because of
driver problems. Detected the right drivers.. but they just didn't
work.

Legal suits: ok something similar to this came up on the discussion
board of reactos.com. Simply ReactOS is going to be more than a
battle of code. The ReactOS Foundation - which is still coming - will
be a big shield for individual developers. Commercial companies based
off of projects like ReactOS have financial resources to back legal
battles. Look at Lindows based off of WINE - they're willing to even
fight over the Windows trademark!

Besides, we like ReactOS - working on it, seeing it grow and take
shape - and it's not going to go away.

- Jason

--- "KJK::Hyperion" <no...@li...> wrote:
>my dear friend, klan-mate, and silent ReactOS advocate Juliet
>forwards me some criticism to our project from the sunny land of
>Usenet:
>IMHO Reactos is too limited, it's doomed to an eternal pursuit to
>the NT-based kernel functionalities, and whenever it will become a
>vague menace to M$, it would be badly put down with legal suits,
>the true alternative would rather be building a new user-friendly
>frontend to Linux/FreeBSD/Hurd, like Apple did, only this time the
>frontend must be  made open source, and errors such as the
>scattering of resources happening with Gnome vs. KDE must be
>avoided this time
> 
>Comments?
> 


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

[ros-kernel] V0.1 WINE Mingw and ReactOS porting and status guide.

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

I am out of town untill Monday evening but I've been trying to get my
documentation work done while on the road. 

If anyone is interested here it is. It has a list of some of my current
bugs plus room for people to test and play. 

All flames will be dumped in /dev/null on my return =P

Thanks
Steven

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

RE: [ros-kernel] Forward: "ReactOS is too limited"

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

> IMHO Reactos is too limited, it's doomed to an eternal pursuit to the 
> NT-based kernel functionalities, and whenever it will become 
> a vague menace 
> to M$, it would be badly put down with legal suits, the true 
> alternative 
> would rather be building a new user-friendly frontend to 
> Linux/FreeBSD/Hurd, like Apple did, only this time the 
> frontend must be 
> made open source, and errors such as the scattering of 
> resources happening 
> with Gnome vs. KDE must be avoided this time

Limited? Tell her to go look at the design of linux/unix kernels and
then come look at ReactOS. Unix is 30 years old and good I'm not
knocking it, I'm just saying NT is a newer better design in "some"
areas. NT would be the shit if it wasn't for M$.

As for scattering of resources waste, what a joke, there are 6 billion
people on this mud ball. If someone is worried about resources then take
the time to do what I do and SPREED THE WORD TO THE CODERS. How many
programmer come in the US on H1B visa's a year? The coders are out
there, but it is part of our duty to this project to help spreed the
word.

Steven

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

[ros-kernel] Forward: "ReactOS is too limited"

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

my dear friend, klan-mate, and silent ReactOS advocate Juliet forwards me 
some criticism to our project from the sunny land of Usenet:

IMHO Reactos is too limited, it's doomed to an eternal pursuit to the 
NT-based kernel functionalities, and whenever it will become a vague menace 
to M$, it would be badly put down with legal suits, the true alternative 
would rather be building a new user-friendly frontend to 
Linux/FreeBSD/Hurd, like Apple did, only this time the frontend must be 
made open source, and errors such as the scattering of resources happening 
with Gnome vs. KDE must be avoided this time

Comments?

Re: [ros-kernel] Restructuring CVS Take 2

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

At 19.42 25/05/2002, you wrote:
> > I like this approach. Same for csrss and winlogon, I hope
>Uh...
>csrss IS the Win32 subsystem, so it is like... already native, I hope.

See "csrss explained" to see what I'm referring to

Re: [ros-kernel] Restructuring CVS Take 2

[Frank D. E. Jr. <fd...@ya...>]

> I like this approach. Same for csrss and winlogon, I hope

Uh...

csrss IS the Win32 subsystem, so it is like... already native, I hope.


=====
=======
Frank D. Engel, Jr.
Please note my new address: fd...@ya...

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

[ros-kernel] CVS Commit: reactos

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

Modified files:
    include/ntos/disk.h
    ntoskrnl/io/xhaldrv.c
    services/storage/atapi/atapi.c
    services/storage/cdrom/cdrom.c
    services/storage/class2/class2.c
    services/storage/disk/disk.c
    services/storage/include/ntddscsi.h
    services/storage/scsiport/scsiport.c

Message log:
    Made NTFS-Partitions mountable.
    Fixed timeout for unpopulated ide channels.
    Fixed inquiry data block for unpopulated ide channels.
    Minor cleanup.


Eric

[ros-kernel] CVS Commit: reactos

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

Modified files:
    services/storage/atapi/atapi.c
    services/storage/include/srb.h

Message log:
    Fixed severe bug in drive detection code.
    Minor cleanup.


Eric

[ros-kernel] CVS Commit: reactos

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

Modified files:
    ntoskrnl/cm/rtlfunc.c
    lib/ntdll/rtl/registry.c
    subsys/smss/init.c
    system.hiv

Message log:
Fixed a severe bug in RtlQueryRegistryValues() and implemented support for
REG_EXPAND_SZ.
Read the system environment from the registry.


Eric

Re: [ros-kernel] Restructuring CVS Take 2

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

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

Hello Jason!

> Sorry about the late reply. I see you already checked in autochk,
> that's good, because you'd probably know best where to put it.

Okay!

> Pulling out psx* and os2* into their own modules, that's about it.
> Any other suggestions?

IMO, we should create two more subdirectories in 'apps', 'apps/testapps' and
'apps/utils'. 'apps/testapps' will contain the test applications from the
'apps' directory, for example 'hello' or 'mutex'. 'apps/utils' will contain
useful utilities for developers like 'objdir' or 'partinfo'.

> >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'.
>
> Yes we should rename it.

The 'services' directory should become the location for user-mode services,
like rpcss and eventlog.


Regards,
Eric

Re: [ros-kernel] Restructuring CVS Take 2

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

Hi Eric

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

Sorry about the late reply. I see you already checked in autochk,
that's good, because you'd probably know best where to put it.

>How do you plan to organize the sysbsys directory?

Pulling out psx* and os2* into their own modules, that's about it.
Any other suggestions?

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

Yes we should rename it.

- Jason







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

[ros-kernel] CVS Commit: reactos

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

New files:
    apps/system/autochk/autochk.c
    apps/system/autochk/autochk.rc
    apps/system/autochk/makefile

Modified files:
    install.bat
    Makefile
    ntoskrnl/cm/import.c
    ntoskrnl/io/fs.c
    subsys/smss/init.c
    subsys/smss/smapi.c
    subsys/smss/smss.c
    subsys/smss/smss.h

Messgage log:
    Added import of REG_EXPAND_SZ registry values.
    Added media change support.
    Added 'BootExecute'-feature to smss.
    Added autochk dummy application.


Eric

Re: [ros-kernel] csrss explained

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

crud. I ended up sending three copies of this. Apologies

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] Restructuring CVS Take 2

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

At 22.30 23/05/2002, you wrote:
> > 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'.
>services.exe loads kernel mode modules and Win32 services. I probably lost 
>any message in this thread, but is it expected to be turned into a native 
>application that can load any service-like (W32), daemon- like (PSX), 
>...-like, via external helpers (svcsys.dll, svcscm.dll, svcdaemon.dll, ...)?

I like this approach. Same for csrss and winlogon, I hope

Re: [ros-kernel] Disk layout continued

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

Though, the primary question is not what projection will a ss make to its
sheeps, but the actual
directory structure in the filesystem. I beleve that one partition's root
directroy is something
special. It is the highest level to divert the strucure. I think that
multiple installations on one
partition is a valuable thing.
No question, WinNT's dir struct has to be resembled in a way.
However I refuse to pollute the root dir with ss specivic dirs. For this
reason
I am for emulating these dirs in the sub system's namespace.

You may argument: Why not also emulate win32-dir struct?
The answer would be: It behaves nice, 'cos it needs only one Folder whose
name is choosable.
PS.
 I think noone either beleves that driveletters actually exist in NT nor
likes them.

Aliberti Emanuele schrieb:

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

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

On 23 May 2002 at 13:35, Eric Kohl wrote:

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

I'd remove only Win32 test applications. Applications that test 
undocumented or system specific functionalities should be kept.
 
> 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'.

services.exe loads kernel mode modules and Win32 services. I probably 
lost any message in this thread, but is it expected to be turned into 
a native application that can load any service-like (W32), daemon-
like (PSX), ...-like, via external helpers (svcsys.dll, svcscm.dll, 
svcdaemon.dll, ...)?