Menu
▾
▴
reactos-kernel
|
From: KJK::Hyperion <no...@li...> - 2002-05-18 07:17:28
|
At 19.37 17/05/2002, you wrote: > > >You earlier said that you were not trying to turn ReactOS into a *nix > like > > >OS. Well I still get the feeling that you are. > > Sorry, but I think you don't get the difference between "ReactOS not > having > > Win32" and "ReactOS not needing Win32" >Maybe I did not explain it correctly before. I said we could turn the >low-level Win32 DLLs into native DLLs so that subsystem programmers had >the *option* of using their services and thus make it easier to implement >new subsystems. Nevermind, I got a bit carried away. I'm perfectly fine with maintaining and releasing Win32, heck, even as part of the base system. Makes things much easier for everyone However, I don't see the point in making those DLLs native. Does the subsystem bit really matter for DLLs? isn't it just for EXEs? for example, ntdll.dll in Windows NT is marked as Win32-Console (???) |
|
From: Casper H. <ch...@us...> - 2002-05-18 11:49:16
|
l=F8r, 2002-05-18 kl. 09:16 skrev KJK::Hyperion: > At 19.37 17/05/2002, you wrote: > > > >You earlier said that you were not trying to turn ReactOS into a *ni= x=20 > > like > > > >OS. Well I still get the feeling that you are. > > > Sorry, but I think you don't get the difference between "ReactOS not=20 > > having > > > Win32" and "ReactOS not needing Win32" > >Maybe I did not explain it correctly before. I said we could turn the=20 > >low-level Win32 DLLs into native DLLs so that subsystem programmers had=20 > >the *option* of using their services and thus make it easier to implemen= t=20 > >new subsystems. >=20 > Nevermind, I got a bit carried away. I'm perfectly fine with maintaining=20 > and releasing Win32, heck, even as part of the base system. Makes things=20 > much easier for everyone >=20 > However, I don't see the point in making those DLLs native. Does the=20 > subsystem bit really matter for DLLs?=20 The only effect is semantics. Does it make sense to use Win32 only modules in a POSIX application? I don't think so. isn't it just for EXEs? for example,=20 > ntdll.dll in Windows NT is marked as Win32-Console (???) Your right. Probably an indication that MS does not want to support other subsystems than Win32. They know it's a winner ;o) |
|
From: Robert K. <ro...@ko...> - 2002-05-18 12:18:37
|
I would prefer to use NTdll to implement the OS/2 API. But maybe I get lazy some day. However I dont like more and even more redundancy, that will come with flipping these bits Casper Hornstrup schrieb: > fre, 2002-05-17 kl. 18:57 skrev KJK::Hyperion: > > At 14.15 17/05/2002, you wrote: > > > > About Win32: let's leave it to the Wine guys. They've done an impressive > > > > job, and they're undoubtably way ahead of us on this. I'm talking not only > > > > of code, but also experience: the extensive research on undocumented > > > > features and bugs they've done > > >You earlier said that you were not trying to turn ReactOS into a *nix like > > >OS. Well I still get the feeling that you are. > > > > Sorry, but I think you don't get the difference between "ReactOS not having > > Win32" and "ReactOS not needing Win32" > > Maybe I did not explain it correctly before. I said we could turn the > low-level Win32 DLLs into native DLLs so that subsystem programmers had > the *option* of using their services and thus make it easier to > implement new subsystems. I never said that every subsystem should use > these DLLs. They are optional because you can always reimplement the > functionality in kernel32, user32, etc. in your own subsystem libraries > and thus not need these modules. > > _______________________________________________________________ > > Hundreds of nodes, one monster rendering program. > Now thats a super model! Visit http://clustering.foundries.sf.net/ > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Casper H. <ch...@us...> - 2002-05-18 12:34:39
|
l=F8r, 2002-05-18 kl. 14:19 skrev Robert K.: > I would prefer to use NTdll to implement the OS/2 API. > But maybe I get lazy some day. However I dont like more and even more red= undancy, > that will come with flipping these bits It is the opposite way around. If the low-level user-mode modules are shared between subsystem, then there will be less redundancy. E.g. One winsock stack (with a thin subsystem specific wrapper) vs. x (=3D #subsystems) winsock stacks communicating with network protocols using a TDI (Transport Driver Interface) which is very generic and hard to work with. One user-mode graphics library for all subsystems. Etc. |
|
From: Robert K. <ro...@ko...> - 2002-05-18 12:53:08
|
> > It is the opposite way around. If the low-level user-mode modules are > shared between subsystem, then there will be less redundancy. E.g. One > winsock stack (with a thin subsystem specific wrapper) vs. x (= > #subsystems) winsock stacks communicating with network protocols using a > TDI (Transport Driver Interface) which is very generic and hard to work > with. One user-mode graphics library for all subsystems. Etc. > This is an argument. Reimplementing a socket lib is not trivial and a windowing system requires a common lib (and window space ). Up to now my plans for allowing PM-os2-apps are to use a win32 server program, which wouldn't be required with user32 as native dll. In that far I'd prefer Casper's suggestion > > _______________________________________________________________ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Robert K. <ro...@ko...> - 2002-05-18 12:23:30
|
> > Please read this again: > http://www.reactos.com/rosdocs/tutorials/bk01pt01ch01.html > > The original goal was to clone Windows 95 to run Windows applications. > This was later changed to clone Windows NT because it was superior to > Windows 95. > > What good is Windows NT driver compatibility, if you cannot run Windows > applications? IMO ReactOS should of course implement a win32ss and all necesary services and so on in win32 but I'd like to see a minimal ReactOS system as well. This minimal system should be something like the mach-kernel. An OS-Kernel with a big range of drivers and without a GUI and services. This is a thing for a subsystem / OS -architect. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:11
|
At 23.14 14/05/2002, you wrote: > > Win32 isn't distinct from NT; >from a historical point of view, it is. I'd rather say OS/2 is not >distinct from NT, being that one the original user mode API MS was going >to provide to the final developer. Heh. Speaking of that, tonight I found something in the NT 4 DDK ntddk.h that made me smile: // // Thread Environment Block (and portable part of Thread Information Block) // // // NT_TIB - Thread Information Block - Portable part. // // This is the subsystem portable part of the Thread Information Block. // It appears as the first part of the TEB for all threads which have // a user mode component. // // This structure MUST MATCH OS/2 V2.0! // // There is another, non-portable part of the TIB which is used // for by subsystems, i.e. Os2Tib for OS/2 threads. SubSystemTib // points there. // "MUST"! he-hee |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:04
|
At 22.34 14/05/2002, you wrote: >In fact I would be put the distinction exactly the opposite anyway round: >developers should know that ReactOS is win32 (possibly with a few extra >primitives like fork to make things easier) but users or distributors >should be able to leave out windowing, security, some system dlls etc if >they only want to use ReactOS for specific purpose such as running Java. Whatever. I call myself out of this shit |
|
From: <we...@cw...> - 2002-05-15 11:46:09
|
Quoting Casper Hornstrup <ch...@us...>: > > We will obviously never agree on this, so I suggest the following > compromise. We flip some bits in the subsystem id field of the > following low-level module images so they become native DLLs/applications: > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS btw.)), > winlogon.exe and services.exe. Then we designate these as subsystem > support modules and keep them in the reactos CVS module. If they are > native, they can be used in any subsystem that wants to use them. > This is all that I am suggesting anyway; perhaps in any case restrictions on executables of one subsystem using the dlls of another should just be removed. |
|
From: Casper H. <ch...@us...> - 2002-05-15 12:27:01
|
ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > Quoting Casper Hornstrup <ch...@us...>: > > > > We will obviously never agree on this, so I suggest the following > > compromise. We flip some bits in the subsystem id field of the > > following low-level module images so they become native DLLs/applications: > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS btw.)), > > winlogon.exe and services.exe. Then we designate these as subsystem > > support modules and keep them in the reactos CVS module. If they are > > native, they can be used in any subsystem that wants to use them. > > > This is all that I am suggesting anyway; perhaps in any case restrictions > on executables of one subsystem using the dlls of another should just > be removed. I am okay with native <-> subsystem dependencies (*), but not with subsystem <-> subsystem dependencies, because it encourages developers to create subsystems that depend on other subsystems. If this happens, then you loose a bit of flexibility to customize your distribution (one reason why companies like linux so much). If there are modules that are generic enough to be used in several subsystems, then we should IMO distribute them with the reactos module as native modules that any subsystem can use. This way, a subsystem can depend on the module always beeing installed on a ReactOS distribution. * -> only if the dependancy is optional. For instance ws2_32.dll supports Winsock service providers and should be able to use existing service providers written for the Win32 API. Another example is services.exe which should be able to execute in-process services (like the usere-mode PnP manager) that belong to any subsystem. |
|
From: Jason F. <jas...@ya...> - 2002-05-15 20:47:15
|
Ok which parts of win32 can we move out of ReactOS? - Jason --- Casper Hornstrup <ch...@us...> wrote: > ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > > Quoting Casper Hornstrup <ch...@us...>: > > > > > > We will obviously never agree on this, so I suggest the > following > > > compromise. We flip some bits in the subsystem id field of the > > > following low-level module images so they become native > DLLs/applications: > > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS > btw.)), > > > winlogon.exe and services.exe. Then we designate these as > subsystem > > > support modules and keep them in the reactos CVS module. If > they are > > > native, they can be used in any subsystem that wants to use > them. > > > > > This is all that I am suggesting anyway; perhaps in any case > restrictions > > on executables of one subsystem using the dlls of another should > just > > be removed. > > I am okay with native <-> subsystem dependencies (*), but not with > subsystem <-> subsystem dependencies, because it encourages > developers > to create subsystems that depend on other subsystems. If this > happens, > then you loose a bit of flexibility to customize your distribution > (one > reason why companies like linux so much). If there are modules that > are > generic enough to be used in several subsystems, then we should IMO > distribute them with the reactos module as native modules that any > subsystem can use. This way, a subsystem can depend on the module > always > beeing installed on a ReactOS distribution. > > * -> only if the dependancy is optional. For instance ws2_32.dll > supports Winsock service providers and should be able to use > existing > service providers written for the Win32 API. Another example is > services.exe which should be able to execute in-process services > (like > the usere-mode PnP manager) that belong to any subsystem. > > > > _______________________________________________________________ > > 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 |
|
From: Casper H. <ch...@us...> - 2002-05-15 21:16:11
|
ons, 2002-05-15 kl. 22:46 skrev Jason Filby: > Ok which parts of win32 can we move out of ReactOS? > > - Jason IMO, the following should be moved out of the reactos module: apps/* lib/bzip2 lib/crtdll lib/dflat32 lib/fmifs lib/msvcrt lib/ole32 lib/oleaut32 lib/psapi lib/shell32 lib/version lib/zlib subsys/os2/* subsys/psx/* I think we should eventually dump the DLLs that are also in WINE and use the WINE versions instead. |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 21:20:23
|
So where should bzip2, crtdll and msvcrt go? Shouldn't they stay with the kernel? Bzip2 is for the ramdisk driver and I don't think we can use wines crtdll/msvcrt. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Casper H. <ch...@us...> - 2002-05-15 22:45:30
|
ons, 2002-05-15 kl. 23:20 skrev Steven Edwards: > So where should bzip2, crtdll and msvcrt go? Shouldn't they stay with > the kernel? Bzip2 is for the ramdisk driver and I don't think we can use > wines crtdll/msvcrt. Oh yes, bzip2 is a kernel mode driver. How about moving it to services/lib? I forgot about the modules in apps/system/. IMO we should make these native applications and move them away from there. To subsys maybe? csrss is already there. If we make winlogon a native application we can have a unified logon system no matter which subsystems are installed. Of course, logon is still customizable by GINAs. |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 23:21:13
|
> Oh yes, bzip2 is a kernel mode driver. How about moving it to > services/lib? > > I forgot about the modules in apps/system/. IMO we should > make these native applications and move them away from there. > To subsys maybe? csrss is already there. If we make winlogon > a native application we can have a unified logon system no > matter which subsystems are installed. Of course, logon is > still customizable by GINAs. I think your right, if Donald ports libW11 then the PSX subsytem Will be using Win32K anyway so we might as well have a unified login System that isnt dependant on Win32 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: David W. <we...@cw...> - 2002-05-15 22:19:18
|
On Wed, May 15, 2002 at 11:13:23PM +0200, Casper Hornstrup wrote: > apps/* > lib/bzip2 > lib/crtdll > lib/dflat32 > lib/fmifs > lib/msvcrt > lib/ole32 > lib/oleaut32 > lib/psapi > lib/shell32 > lib/version > lib/zlib > subsys/os2/* > subsys/psx/* > apps/shell should be left but mingw32, rpcrt4 can be moved as well. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 22:22:24
|
At 23.13 15/05/2002, you wrote: [...] >lib/bzip2 [...] >lib/zlib Not sure on these |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 21:16:48
|
In reactos/lib we can remove Ole and ole32. I'm not 100% sure be we might be able to use wines Psapi and rpcrt. Eric can you comment? Also you can rm -fr reactos/apps/tests. These were taken from the wine tree a long time back And wont be needed once we have the regression testing suite. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson > -----Original Message----- > From: rea...@li... > [mailto:rea...@li...] On Behalf > Of Jason Filby > Sent: Wednesday, May 15, 2002 4:47 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Ok which parts of win32 can we move out of ReactOS? > > - Jason > > --- Casper Hornstrup <ch...@us...> wrote: > > ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > > > Quoting Casper Hornstrup <ch...@us...>: > > > > > > > > We will obviously never agree on this, so I suggest the > > following > > > > compromise. We flip some bits in the subsystem id field of the > > > > following low-level module images so they become native > > DLLs/applications: > > > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS > > btw.)), > > > > winlogon.exe and services.exe. Then we designate these as > > subsystem > > > > support modules and keep them in the reactos CVS module. If > > they are > > > > native, they can be used in any subsystem that wants to use > > them. > > > > > > > This is all that I am suggesting anyway; perhaps in any case > > restrictions > > > on executables of one subsystem using the dlls of another should > > just > > > be removed. > > > > I am okay with native <-> subsystem dependencies (*), but not with > > subsystem <-> subsystem dependencies, because it encourages > developers > > to create subsystems that depend on other subsystems. If this > > happens, > > then you loose a bit of flexibility to customize your distribution > > (one > > reason why companies like linux so much). If there are modules that > > are > > generic enough to be used in several subsystems, then we should IMO > > distribute them with the reactos module as native modules that any > > subsystem can use. This way, a subsystem can depend on the module > > always > > beeing installed on a ReactOS distribution. > > > > * -> only if the dependancy is optional. For instance ws2_32.dll > > supports Winsock service providers and should be able to > use existing > > service providers written for the Win32 API. Another example is > > services.exe which should be able to execute in-process services > > (like > > the usere-mode PnP manager) that belong to any subsystem. > > > > > > > > _______________________________________________________________ > > > > 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 > > _______________________________________________________________ > > 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 > |
|
From: Eric K. <ek...@rz...> - 2002-05-15 22:10:06
|
"Steven Edwards" <Ste...@ya...> wrote: > In reactos/lib we can remove Ole and ole32. I'm not 100% sure be we > might be able to use wines > Psapi and rpcrt. Eric can you comment? I'm sure we can use Wine's psapi. The rpcrt stuff might be a bit more difficult but it should usable too. Eric |
|
From: David W. <we...@cw...> - 2002-05-14 19:36:25
|
On Tue, May 14, 2002 at 03:50:08PM +0200, Casper Hornstrup wrote: > No, win32k.sys is useless if there is no user-mode interface library for > other subsystems. > Of course the same code to interface to win32k.sys could be written another 3 or 4 times: my point is that if we acknowledge what is in fact the case, that the main point of ReactOS is to run win32 programs, we avoid useless duplication of code and effort by trying to seperate win32. |
|
From: Casper H. <ch...@us...> - 2002-05-14 20:44:29
|
tir, 2002-05-14 kl. 21:59 skrev David Welch: > On Tue, May 14, 2002 at 03:50:08PM +0200, Casper Hornstrup wrote: > > No, win32k.sys is useless if there is no user-mode interface library for > > other subsystems. > > > Of course the same code to interface to win32k.sys could be written > another 3 or 4 times: my point is that if we acknowledge what is in fact > the case, that the main point of ReactOS is to run win32 programs, we > avoid useless duplication of code and effort by trying to seperate win32. Of course it would have to be written several times (once per subsystem to be exact) because it is the glue code between the ReactOS graphics architecture, which graphics driver know of and the subsystem applications, which expect certain APIs to work with. You cannot share this because the specific subsystem implementations will differ greatly. Just because Windows NT has adopted GDI as its graphics API, it does not mean that you cannot use it from other subsystems. |
|
From: Aliberti E. <ea...@us...> - 2002-05-14 21:46:10
|
On 14 May 2002 at 22:41, Casper Hornstrup wrote: > Just because Windows NT has adopted GDI as its graphics API, > it does not mean that you cannot use it from other subsystems. Moving the core GDI in kernel mode (NT351-NT40) changed the GDI state itself. I think its API should be considered part of the system API. |
|
From: Nick J. D. <nic...@ya...> - 2002-05-19 15:22:20
|
Hi guys, ----- Original Message ----- From: <we...@cw...> To: <rea...@li...> Sent: Tuesday, May 14, 2002 2:23 PM Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs repository before starting reactos.org > Quoting Casper Hornstrup <ch...@us...>: > > > > I consider win32k.sys as part of the Windows NT executive architecture > > and not part of the Win32 subsystem. Therefore I believe win32k.sys > > should be in the reactos module. I however, see no reason for building > > the Win32 subsystem if you are not developing or distributing this > > part, so the Win32 subsystem should go in it's own module. > > > I think that's an artifical distinction: win32k is useless without user32 > or gdi32 both of which require kernel32 and indirectly csrss and so on. The > project ought to recognize that, if reactos has a use at all, then running > win32 programs is it. POSIX and OS/2 subsystems are interesting but if this > functionality is all that is required then there are already operating systems > that do it better. I know I've been away for a while and I'm butting straight in, but I see exactly what David means. The aim of ReactOS is to provide an open source operating system that is compatible with Windows NT apps and drivers. In my interpretation this means that anything else is nice, but by the by. I have no problem with people creating other subsystems (a POSIX subsystem for example would be great), but I think the focus should be kept on getting the WIN32 API up and running and making the kernel as bug free as possible. If an OS/2 project wants to use the ROS kernel and write an OS/2 compatible API then fine. But it won't be ROS. ROS is an NT compatible OS. Full stop. Just as an aside, IMHO WinNT driver/app compatibility doesn't even mean trying to write an NTFS driver. A Linux type filesystem would be just as compatible (providing your not using any disk fixing/editing programs) and would have all the security of a Linux box's FS. Well, that's my twopence worth. ;-) Nick. -- Nick Date Bath, England, United Kingdom --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.362 / Virus Database: 199 - Release Date: 07/05/2002 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Casper H. <ch...@us...> - 2002-05-19 16:10:09
|
s=F8n, 2002-05-19 kl. 17:21 skrev Nick J. Date: > Just as an aside, IMHO WinNT driver/app compatibility doesn't even mean > trying to write an NTFS driver.=20 I agree, that drivers are not necesarry for compatibility, but ReactOS will not be as fun without certain drivers like IDE VGA, TCP/IP, etc. MS provided helper drivers and support library libraries like NDIS and storage stack support libraries would be necesarry because OEM drivers depend on them and nobody will create them.=20 A Linux type filesystem would be just as > compatible (providing your not using any disk fixing/editing programs) an= d > would have all the security of a Linux box's FS. Ext2fs security will be enough for some, but not for all. |
|
From: Robert K. <ro...@ko...> - 2002-05-28 00:20:43
|
> I have another view for all of you. What about considdering win32k with its drivers and gdi.dll.... as a (native) graphics _sub system_. A ss that has a kernelpart for doing some i/o ;-) Winlogon is not essential for running programs. They're then run with all privileges, but if some developer wants, he can write an BeOS ss and write a logon for it. Why bother? Things like novell aren't possible then, but its his choice > > > I consider win32k.sys as part of the Windows NT executive architecture > and not part of the Win32 subsystem. Therefore I believe win32k.sys > should be in the reactos module. I however, see no reason for building > the Win32 subsystem if you are not developing or distributing this part, > so the Win32 subsystem should go in it's own module. > > _______________________________________________________________ > > 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 |
