Menu
▾
▴
reactos-kernel
|
From: Jason F. <jas...@ya...> - 2002-05-14 08:38:39
|
Hey all Emanuele proposed that we should start splitting up the modules ASAP. I agree, but we need to agree on how this will be done. Two issues I had: o Should all the header files go with the reactos module? o Should w32k stick with the reactos module since it's quite close to the way NT graphics drivers work? (win32k.sys that is). Comments please. Thanks - Jason Note: forwarded message attached. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Yuri P. <pro...@fr...> - 2002-05-14 09:07:50
|
On Tue, 14 May 2002 01:38:38 -0700 (PDT), Jason Filby wrote: >Emanuele proposed that we should start splitting up the modules ASAP. >I agree, but we need to agree on how this will be done. Two issues I >had: >o Should all the header files go with the reactos module? Subsystems headers to subsystem modules, ros headers to reactos module. >o Should w32k stick with the reactos module since it's quite close to >the way NT graphics drivers work? (win32k.sys that is). _If_ win32k proposed as graphical subsystem of ros, then answer is yes. If as win32ss part, then in subsystem module. |
|
From: <we...@cw...> - 2002-05-14 09:48:13
|
Quoting Jason Filby <jas...@ya...>: > > Emanuele proposed that we should start splitting up the modules ASAP. > I agree, but we need to agree on how this will be done. Two issues I > had: > I don't agree; the main purpose of the ReactOS kernel is to support win32 programs and there isn't any clean seperation between the two parts, for example win32 USER/GDI is needed to for winlogon and other security facilities. So both win32 and the kernel should be kept in the same module. |
|
From: Casper H. <ch...@us...> - 2002-05-14 11:55:16
|
tir, 2002-05-14 kl. 11:48 skrev we...@cw...: > Quoting Jason Filby <jas...@ya...>: > > > > Emanuele proposed that we should start splitting up the modules ASAP. > > I agree, but we need to agree on how this will be done. Two issues I > > had: > > > I don't agree; the main purpose of the ReactOS kernel is to support win32 > programs and there isn't any clean seperation between the two parts, for > example win32 USER/GDI is needed to for winlogon and other security facilities. > So both win32 and the kernel should be kept in the same module. 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. |
|
From: <we...@cw...> - 2002-05-14 13:23:22
|
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. |
|
From: Casper H. <ch...@us...> - 2002-05-14 13:52:44
|
tir, 2002-05-14 kl. 15:23 skrev we...@cw...: > 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. No, win32k.sys is useless if there is no user-mode interface library for other subsystems. If developers want to improve on ReactOS because they want to run non-Win32 applications, then I wellcome the extra developers. Yes, you can dual boot and trible boot a computer, if you need to run other applications, but this is kind of annoying. Especially if you want to copy/paste between applications ;o) |
|
From: Steven E. <Ste...@ya...> - 2002-05-14 14:55:36
|
I tend to agree with Capser.
I would think that the user mode pure win32 parts of win32 should be in
there own tree.
Take a look at the current wine fork and how we are doing it. It needs
to be self-contained
If at all possible. Once I am doing getting the wine tree up 2 date all
someone will need to
Do to upgrade win32 (not counting win32k, user32, and kernel32) is to
run rosmakefile.sh
on the wine tree to convert the Wine makefiles in to Makefile.ros, drop
the current wine tree
In and rebuild.
Currently we have almost no need to fork the wine tree for win32. Here
is the results of my current porting work.
Wine Resources can now compile, Winelib programs cleanly build on a
stand alone mingw install.
And Here is the status of the wine/dlls
You have 3 sets of Results.
1. prototypes conflict -
wcstol is the main problem. _wtoi is the only other problem. Who
is the current
libwine_unicode person to talk to about making the changes
Alexandre suggested?
2. "unixisms" -
I'm not going in to the debate about how to work around this
yet.
3. No Problems (all objects compile with no errors/warnings)
I'm not counting the (snprintf warning)'s or the TWAIN.DLL warnings as a
bug because I
will be fixing those problems in my next set of patches.
1)----------------prototypes
conflict----------------------------------------------
comctl32 - (snprintf warning)
comctl32undoc.c:70: conflicting types for `_wtoi'
/usr/include/mingw/stdlib.h:284: previous declaration of `_wtoi'
make: *** [comctl32undoc.o] Error 1
In file included from ipaddress.c:31:
../../include/ntddk.h:762: conflicting types for `wcstol'
/usr/include/mingw/stdlib.h:290: previous declaration of
`wcstol'
make: *** [ipaddress.o] Error 1
commdlg - (snprintf warning)
In file included from filedlg95.c:59:
../../include/ntddk.h:762: conflicting types for `wcstol'
/usr/include/mingw/stdlib.h:290: previous declaration of
`wcstol'
filedlg95.c: In function `FILEDLG95_HandleCustomDialogMessages':
filedlg95.c:799: warning: implicit declaration of function
`snprintf'
make: *** [filedlg95.o] Error 1
ole32 -
In file included from stg_stream.c:32:
../../include/ntddk.h:762: conflicting types for `wcstol'
/usr/include/mingw/stdlib.h:290: previous declaration of
`wcstol'
make: *** [stg_stream.o] Error 1
oleaut -
In file included from tmarshal.c:43:
../../include/ntddk.h:762: conflicting types for `wcstol'
/usr/include/mingw/stdlib.h:290: previous declaration of
`wcstol'
make: *** [tmarshal.o] Error 1
psapi -
In file included from ../../include/wine/server_protocol.h:11,
from ../../include/wine/server.h:27,
from psapi_main.c:24:
/usr/include/mingw/stdlib.h:290: conflicting types for `wcstol'
../../include/ntddk.h:762: previous declaration of `wcstol'
setupapi -
In file included from parser.c:30:
../../include/ntddk.h:762: conflicting types for `wcstol'
/usr/include/mingw/stdlib.h:290: previous declaration of
`wcstol'
make: *** [parser.o] Error 1
2)-----------"unixisms" below
shell32 - (snprintf warning)
shelllink.c: In function `IPersistFile_fnSave':
shelllink.c:687: warning: implicit declaration of function
`fork'
shelllink.c:719: warning: implicit declaration of function
`execvp'
shelllink.c:723: warning: implicit declaration of function
`waitpid'
netapi32 -
netapi32.c:37: sys/ioctl.h: No such file or directory
mpr -
wnet.c:24: pwd.h: No such file or directory
rpcrt -
rpcrt4_main.c:43: sys/ioctl.h: No such file or directory
3)-----------No Real Problem
twain32 -
twain.h:59: warning: `WIN32' redefined
*Initialization*:1: warning: this is the location of the
previous definition
twain.h:60: warning: `_WIN32' redefined
*Initialization*:1: warning: this is the location of the
previous definition
twain.h:61: warning: `__declspec' redefined
*Initialization*:1: warning: this is the location of the
previous definition
msacm - All Objects compile (snprintf warning)
serialui - All Objects compile (snprintf warning)
msdmo - All Objects compile
msvideo - All Objects compile
odbc32 - All Objects compile
urlmon - All Objects compile
version - All Objects compile
shlwapi - All Objects compile
tapi32 - All Objects compile
shdocvw - All Objects compile
rasapi - All Objects compile
richedit - All Objects compile
ddraw - All Objects compile
dinput - All Objects compile
dplayx - All Objects compile
dsound - All Objects compile
imagehlp - All Objects compile
imm32 - All Objects compile
lzexpand - All Objects compile
mapi32 - All Objects compile
olecli - All Objects compile
oledlg - All Objects compile
olesrv - All Objects compile
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 Casper Hornstrup
> Sent: Tuesday, May 14, 2002 9:50 AM
> To: rea...@li...
> Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs
> repository beforestarting reactos.org
>
>
> tir, 2002-05-14 kl. 15:23 skrev we...@cw...:
> > 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.
>
> No, win32k.sys is useless if there is no user-mode interface
> library for other subsystems. If developers want to improve
> on ReactOS because they want to run non-Win32 applications,
> then I wellcome the extra developers. Yes, you can dual boot
> and trible boot a computer, if you need to run other
> applications, but this is kind of annoying. Especially if you
> want to copy/paste between applications ;o)
>
>
>
> _______________________________________________________________
>
> 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: David W. <we...@cw...> - 2002-05-14 19:36:23
|
On Tue, May 14, 2002 at 10:56:01AM -0400, Steven Edwards wrote: > Do to upgrade win32 (not counting win32k, user32, and kernel32) > Also gdi32 and advapi32. |
|
From: Robert K. <ro...@ko...> - 2002-05-21 12:48:02
|
And what about the earlier mentioned Idea of someone: o Let win32k.sys as it is ( graphics ss with other stuff) o Leave win32-core libs as win32-dlls o Create a native win32k.dll that interfaces with sys. o Make the win32 core libs base on win32k.dll David Welch schrieb: > On Tue, May 14, 2002 at 10:56:01AM -0400, Steven Edwards wrote: > > Do to upgrade win32 (not counting win32k, user32, and kernel32) > > > Also gdi32 and advapi32. > > _______________________________________________________________ > > 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: James T. <jim...@ad...> - 2002-05-15 01:01:45
|
Steven Edwards wrote:
>
> I tend to agree with Capser.
>
> I would think that the user mode pure win32 parts of win32 should be in
> there own tree.
> Take a look at the current wine fork and how we are doing it. It needs
> to be self-contained
> If at all possible. Once I am doing getting the wine tree up 2 date all
> someone will need to
> Do to upgrade win32 (not counting win32k, user32, and kernel32) is to
> run rosmakefile.sh
> on the wine tree to convert the Wine makefiles in to Makefile.ros, drop
> the current wine tree
> In and rebuild.
>
> Currently we have almost no need to fork the wine tree for win32. Here
> is the results of my current porting work.
>
> Wine Resources can now compile, Winelib programs cleanly build on a
> stand alone mingw install.
> And Here is the status of the wine/dlls
>
> You have 3 sets of Results.
>
> 1. prototypes conflict -
> wcstol is the main problem. _wtoi is the only other problem. Who
> is the current
> libwine_unicode person to talk to about making the changes
> Alexandre suggested?
>
> 2. "unixisms" -
> I'm not going in to the debate about how to work around this
> yet.
>
> 3. No Problems (all objects compile with no errors/warnings)
>
> I'm not counting the (snprintf warning)'s or the TWAIN.DLL warnings as a
> bug because I
> will be fixing those problems in my next set of patches.
>
> 1)----------------prototypes conflict----------------------------------------------
>
> comctl32 - (snprintf warning)
> comctl32undoc.c:70: conflicting types for `_wtoi'
> /usr/include/mingw/stdlib.h:284: previous declaration of `_wtoi'
> make: *** [comctl32undoc.o] Error 1
>
> In file included from ipaddress.c:31:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [ipaddress.o] Error 1
>
> commdlg - (snprintf warning)
> In file included from filedlg95.c:59:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> filedlg95.c: In function `FILEDLG95_HandleCustomDialogMessages':
> filedlg95.c:799: warning: implicit declaration of function
> `snprintf'
> make: *** [filedlg95.o] Error 1
>
#ifdef __REACTOS__
_snprintf((LPSTR)lParam,(int)wParam,"%s\\%s",lpstrCurrentDir,lpstrPath);
#else /* !__REACTOS__ */
snprintf((LPSTR)lParam,(int)wParam,"%s\\%s",lpstrCurrentDir,lpstrPath);
#endif /* __REACTOS__ */
Can you make it work for ming the same way we made wine work with ROS? Example above....
> ole32 -
> In file included from stg_stream.c:32:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [stg_stream.o] Error 1
>
> oleaut -
> In file included from tmarshal.c:43:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [tmarshal.o] Error 1
>
> psapi -
> In file included from ../../include/wine/server_protocol.h:11,
> from ../../include/wine/server.h:27,
> from psapi_main.c:24:
> /usr/include/mingw/stdlib.h:290: conflicting types for `wcstol'
> ../../include/ntddk.h:762: previous declaration of `wcstol'
>
> setupapi -
> In file included from parser.c:30:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [parser.o] Error 1
>
> 2)-----------"unixisms" below
>
> shell32 - (snprintf warning)
> shelllink.c: In function `IPersistFile_fnSave':
> shelllink.c:687: warning: implicit declaration of function
> `fork'
> shelllink.c:719: warning: implicit declaration of function
> `execvp'
> shelllink.c:723: warning: implicit declaration of function
> `waitpid'
>
> netapi32 -
> netapi32.c:37: sys/ioctl.h: No such file or directory
> mpr -
> wnet.c:24: pwd.h: No such file or directory
> rpcrt -
> rpcrt4_main.c:43: sys/ioctl.h: No such file or directory
>
> 3)-----------No Real Problem
>
> twain32 -
> twain.h:59: warning: `WIN32' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> twain.h:60: warning: `_WIN32' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> twain.h:61: warning: `__declspec' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> msacm - All Objects compile (snprintf warning)
> serialui - All Objects compile (snprintf warning)
> msdmo - All Objects compile
> msvideo - All Objects compile
> odbc32 - All Objects compile
> urlmon - All Objects compile
> version - All Objects compile
> shlwapi - All Objects compile
> tapi32 - All Objects compile
> shdocvw - All Objects compile
> rasapi - All Objects compile
> richedit - All Objects compile
> ddraw - All Objects compile
> dinput - All Objects compile
> dplayx - All Objects compile
> dsound - All Objects compile
> imagehlp - All Objects compile
> imm32 - All Objects compile
> lzexpand - All Objects compile
> mapi32 - All Objects compile
> olecli - All Objects compile
> oledlg - All Objects compile
> olesrv - All Objects compile
>
> Thanks
> Steven
>
I need your source tree to help! Give me an URL okay!
James
|
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:12:24
Attachments:
Building Wine using Mingw.txt
|
> Can you make it work for ming the same way we made wine work > with ROS? Example above.... > I already made the change in wine/port.h #define _snprintf snprintf Now its just making sure port.h is included everytime that happens > I need your source tree to help! Give me an URL okay! > James I'm just working out of the current wine tree right now. You will Need cygwin installed to do the hacking as Msys is a little buggy. Once we have all of the porting issues fixed in wine then we can do a new import of the wine source tree and make the reactos makefiles. Attached are the current directions to start hacking on wine for Mingw Plus my personal todo list. You will need to edit some of the Makefiles Once configured to either add or remove some import libs such as ntdll, Liberty, libwine and a few others. I will write I more compleate guide soon. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Yuri P. <pro...@fr...> - 2002-05-14 17:45:21
|
On Tue, 14 May 2002 14:23:19 +0100 (BST), we...@cw... wrote: >> 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. If win32k will be used by any and all subsystems then win32k not a part of win32ss. So win32k must be a kernel part. > 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 consider win32 kernel part (win32k.sys) must be used for all subsystems for windowing. So win32k can and must be used for graphical subsystems of reactos subsystems. If win32k will be represented as _graphical subsystem of reactos_ then any subsystem will use its for subsystems graphic.. POSIX and OS/2 subsystems not only interesing, but also _part_ os reactos. May be I can describe my minds good, but if all of you want to make reactos multisubsystems the don't mix any subsystem with kernel. Mix only kernel parts (like win32k.sys) on wich another subsystems can be builded. IMHO, of couse. |
|
From: Yuri P. <pro...@fr...> - 2002-05-14 17:45:21
|
On 14 May 2002 13:52:39 +0200, Casper Hornstrup wrote: >tir, 2002-05-14 kl. 11:48 skrev we...@cw...: >> Quoting Jason Filby <jas...@ya...>: >> > >> > Emanuele proposed that we should start splitting up the modules ASAP. >> > I agree, but we need to agree on how this will be done. Two issues I >> > had: >> > >> I don't agree; the main purpose of the ReactOS kernel is to support win32 >> programs and there isn't any clean seperation between the two parts, for >> example win32 USER/GDI is needed to for winlogon and other security facilities. >> So both win32 and the kernel should be kept in the same module. > >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 agree. All subsystems kernel parts _must_ be represented as kernel part. Any subsystem allows use any kernel part of subsystems. Any subsystem's kernel extensions must be native part of reactos. But subsystems (gdi32, user32, kernel32 for win32ss) must be separated/independed modules. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:19
|
At 06.27 15/05/2002, you wrote: > >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 agree. All subsystems kernel parts _must_ be represented as kernel part. >Any subsystem allows use any kernel part of subsystems. Any subsystem's >kernel extensions >must be native part of reactos. I don't agree. If I'll ever write the POSIX kernel extensions - and this may surprise those that believe that I want to make ReactOS "yet another Unix" - I'll never try to sneak them into the main tree: I realize that POSIX signals (the main, if not sole purpose of POSIX kernel extensions) are *hardly* to be considered part of an NT kernel (ok, I *do* believe that a system is handicapped if it doesn't implement signals) |
|
From: Yuri P. <pro...@fr...> - 2002-05-15 05:00:24
|
On Wed, 15 May 2002 01:53:23 +0200, KJK::Hyperion wrote: >At 06.27 15/05/2002, you wrote: >> >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 agree. All subsystems kernel parts _must_ be represented as kernel part. >>Any subsystem allows use any kernel part of subsystems. Any subsystem's >>kernel extensions >>must be native part of reactos. >I don't agree. If I'll ever write the POSIX kernel extensions - and this >may surprise those that believe that I want to make ReactOS "yet another >Unix" - I'll never try to sneak them into the main tree: I realize that >POSIX signals (the main, if not sole purpose of POSIX kernel extensions) >are *hardly* to be considered part of an NT kernel (ok, I *do* believe that >a system is handicapped if it doesn't implement signals) Ok. If subsystems kernel extension used more than by one subsystem then this extension must be moved to kernel and interpreted as kernel part but not subsystem part. |
|
From: Jason F. <jas...@ya...> - 2002-05-14 14:03:27
|
Sounds good, keeping the kernel and win32 in the same module. But POSIX and OS/2 should have their own modules, shouldn't they? - Jason --- we...@cw... wrote: > Quoting Jason Filby <jas...@ya...>: > > > > Emanuele proposed that we should start splitting up the modules > ASAP. > > I agree, but we need to agree on how this will be done. Two > issues I > > had: > > > I don't agree; the main purpose of the ReactOS kernel is to support > win32 > programs and there isn't any clean seperation between the two > parts, for > example win32 USER/GDI is needed to for winlogon and other security > facilities. > So both win32 and the kernel should be kept in the same 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 __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-14 14:14:12
|
Wait.. I think I may agree with Casper. Some other projects want to make use of the ReactOS kernel (for instance, JOS, the Java OS project) and they don't need the user win32 part. - Jason --- Jason Filby <jas...@ya...> wrote: > Sounds good, keeping the kernel and win32 in the same module. But > POSIX and OS/2 should have their own modules, shouldn't they? > > - Jason > > --- we...@cw... wrote: > > Quoting Jason Filby <jas...@ya...>: > > > > > > Emanuele proposed that we should start splitting up the modules > > ASAP. > > > I agree, but we need to agree on how this will be done. Two > > issues I > > > had: > > > > > I don't agree; the main purpose of the ReactOS kernel is to > support > > win32 > > programs and there isn't any clean seperation between the two > > parts, for > > example win32 USER/GDI is needed to for winlogon and other > security > > facilities. > > So both win32 and the kernel should be kept in the same 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 > > > __________________________________________________ > 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 __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Iain S. <iai...@me...> - 2002-05-14 16:12:13
|
On 5/14/02 7:14 AM, "Jason Filby" <jas...@ya...> wrote: > Wait.. I think I may agree with Casper. Some other projects want to > make use of the ReactOS kernel (for instance, JOS, the Java OS > project) and they don't need the user win32 part. I'll ping in as one of those JOS people. :) It will be much easier to gain support for ReactOS as the platform for our primary development (Linux, FreeBSD, and eCos are other candidates) if the Win32 subsystem can be separated and loaded (or not) depending on our needs. We are interested in the basic kernel (mem management, process management, etc), drivers, and GDI, but many other aspects will be specific to our subsystem (we won't need win32, security, etc in the normal JOS stack). On the other hand, we certainly would understand if the division makes your Win32 stuff much harder to develop and you decide to make it monolithic. I agree that Win32 is going to be the primary use of ReactOS. However, Java apps are becoming quite common so would probably make the second most likely app family that would be nice to support... -iain |
|
From: David W. <we...@cw...> - 2002-05-14 19:41:26
|
On Tue, May 14, 2002 at 08:56:17AM -0700, Iain Shigeoka wrote: > I'll ping in as one of those JOS people. :) It will be much easier to gain > support for ReactOS as the platform for our primary development (Linux, > FreeBSD, and eCos are other candidates) if the Win32 subsystem can be > separated and loaded (or not) depending on our needs. > I'm not sure that ReactOS is a good choice for you in any case: we are not really even in alpha at the moment and a usable OS is still some years away. I don't know much about eCos but either Linux or FreeBSD would seem a much better choice. |
|
From: Iain S. <iai...@me...> - 2002-05-14 20:52:29
|
On 5/14/02 1:42 PM, "David Welch" <we...@cw...> wrote: > On Tue, May 14, 2002 at 08:56:17AM -0700, Iain Shigeoka wrote: >> I'll ping in as one of those JOS people. :) It will be much easier to gain >> support for ReactOS as the platform for our primary development (Linux, >> FreeBSD, and eCos are other candidates) if the Win32 subsystem can be >> separated and loaded (or not) depending on our needs. >> > I'm not sure that ReactOS is a good choice for you in any case: we are not > really even in alpha at the moment and a usable OS is still some years > away. I don't know much about eCos but either Linux or FreeBSD would seem > a much better choice. Understood. There are a few critical advantages to ReactOS however. First we can use standard windows development and debugging tools, and can do both on regular windows platforms... only integration testing back down onto ReactOS as needed. Assuming ReactOS is windows compatible this seems very reasonable. In other words, we'll spend a lot of time now in full blown MS Windows, but we'll make regular attempts at running on ReactOS. This seems like a mutually beneficial situation as we get work done now, and you get real feedback on your compatibility. Second and most critical for an OS project, drivers are going to be our #1 long term issue in getting adoption. There is only 1 real option for getting decent driver support for our OS: be Windows driver compatible. -iain |
|
From: Yuri P. <pro...@fr...> - 2002-05-14 17:45:17
|
On Tue, 14 May 2002 10:48:10 +0100 (BST), we...@cw... wrote: >Quoting Jason Filby <jas...@ya...>: >> >> Emanuele proposed that we should start splitting up the modules ASAP. >> I agree, but we need to agree on how this will be done. Two issues I >> had: >> >I don't agree; the main purpose of the ReactOS kernel is to support win32 >programs and there isn't any clean seperation between the two parts, for >example win32 USER/GDI is needed to for winlogon and other security facilities. >So both win32 and the kernel should be kept in the same module. I don't agree. Or reactos multisubsystems os or onesubsystem os. If reactos going to be multisubsystem, then all subsystems must be searated. If not, then many peoples will not interesting for reactos, because win32 only system. Yes. For most peoples main goal is win32ss. But don't mix subsustems, please, if react os is going to be multisubsystem os. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-14 17:26:41
|
At 10.38 14/05/2002, you wrote: >o Should all the header files go with the reactos module? only the DDK and internal header files, IMHO >o Should w32k stick with the reactos module since it's quite close to the >way NT graphics drivers work? (win32k.sys that is). Nobody says NT *needs* graphics. win32k.sys is Win32, only Win32 needs it, etc. So win32k.sys should go with Win32, together with DDI drivers. Let's make clear for *developers* that Win32 is distinct from NT. Of course the standard distribution for *users* will include Win32 |
|
From: Jason F. <jas...@ya...> - 2002-05-14 18:40:08
|
--- "KJK::Hyperion" <no...@li...> wrote: >Nobody says NT *needs* graphics. win32k.sys is Win32, only Win32 >needs it, etc. So win32k.sys should go with Win32, together with >DDI drivers. Let's make clear for *developers* that Win32 is >distinct from NT. Of course the standard distribution for *users* >will include Win32 NT graphics drivers and win32k.sys are pretty much inseperable - they work together. So if another subsystem wants graphics they generally have to talk to win32k.sys. That's why I think it should be in the reactos module. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Robert K. <ro...@ko...> - 2002-05-16 20:09:19
|
I want to remember OS/2: Os2 came out with no graphical UI. Then there was PM with km-drivers that are of course specific to PM A few years ago someone ported XFree86 to OS/2. then PM is disabled and one is using an X-server. What I want to say is: This is applicable to reactos, too. If you want to make a UN*X system, you don't need win32k with all its drivers. Disadvantage is that you have to rewrite all win32-dependent services or whatever. But this would match the original goal of the OS-writer much more. He has just a kernel with dirvers and a mighty IOCTL-API.....and a lot of work. However, I'll base the os2ss on GDI and SMSS.EXE Jason Filby schrieb: > --- "KJK::Hyperion" <no...@li...> wrote: > >Nobody says NT *needs* graphics. win32k.sys is Win32, only Win32 > >needs it, etc. So win32k.sys should go with Win32, together with > >DDI drivers. Let's make clear for *developers* that Win32 is > >distinct from NT. Of course the standard distribution for *users* > >will include Win32 > > NT graphics drivers and win32k.sys are pretty much inseperable - they > work together. So if another subsystem wants graphics they generally > have to talk to win32k.sys. That's why I think it should be in the > reactos module. > > - Jason > > __________________________________________________ > 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: David W. <we...@cw...> - 2002-05-14 19:36:22
|
On Tue, May 14, 2002 at 07:24:07PM +0200, KJK::Hyperion wrote: > Nobody says NT *needs* graphics. win32k.sys is Win32, only Win32 needs it, > etc. So win32k.sys should go with Win32, together with DDI drivers. Let's > make clear for *developers* that Win32 is distinct from NT. Of course the > standard distribution for *users* will include Win32 > Win32 isn't distinct from NT; there are very few facilities provided by the kernel which aren't directly exposed through the win32 API. We already know that this API is general enough to run POSIX programs (including emulation of Linux binaries), text-mode OS/2 programs, interpreted and native code Java programs, etc. It seems sheer 'multi-subsystem' dogmatism to pretend that this isn't the case and to pretend that win32 is just another subsystem. 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. |
