Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
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: 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: 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: 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: 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: 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. |
|
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: Yuri P. <pro...@fr...> - 2002-05-14 17:45:29
|
On Tue, 14 May 2002 07:03:26 -0700 (PDT), Jason Filby 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? Please, don't mix _any_ subsystem with kernel. This is not clear and attracts other opearting systems' users. |
|
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: 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: 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: 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: 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: 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: 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: <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 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 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: 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: 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: David W. <we...@cw...> - 2002-05-14 06:45:56
|
On Tue, May 14, 2002 at 01:13:45AM +0200, Hartmut Birr wrote: > for testing, I've attached two patches. The first (fastmutex.patch) changes > the lock for the address space from a MUTEX to a FAST_MUTEX and calls > KeBugCheck, if there is a recursive locking for the same thread. After the > command 'gcc -o rdel.o rdel.c -o -pipe' occurs the recursive locking of a > address space. The call to KeBugCheck is only for printing a stack trace. > Without the call, there is a dead lock at this point. The second patch > (mdl-fix.patch) does add a KeRaiseIrql/KeLowerIrql for MmMapLockedPages/ > MmUnmapLockedPages. With this patch, gcc works. There exist more points > with a locked address space, which can also result in a corrupt memory area > list, if there is a thread switching and a next access to the address > space. > Are MmMapLockedPages/MmUnmapLockedPages the only places which lock an address space and which can be called at DISPATCH_LEVEL? |
|
From: James T. <jim...@ad...> - 2002-05-14 03:15:56
|
Rex Jolliff wrote: > > At 07:30 PM 5/13/02 +0200, you wrote: > >man, 2002-05-13 kl. 17:49 skrev Steven Edwards: > > > I am having a little problem with my wine porting work and was wondering > > > [...] > > > > > > Wine/include/ntddk.h defines > > > INT __cdecl wcstol(LPCWSTR,LPWSTR*,INT); > ^^^ > > > > While mingws include/stdlib.h defines > > > long wcstol (const wchar_t*, wchar_t**, int); > ^^^^ > > perhaps the ntddk version is incorrect, as this function should return > a long int (LONG), not an int. > > Rex Jolliff > re...@lv... > I notice that too. James |
|
From: James T. <jim...@ad...> - 2002-05-14 02:46:10
|
Hi, Steven Edwards wrote: > > > Since this is a standard C runtime library function, I > > consider the MinGW to be more correct. LPCWSTR etc. are WinNT > > types, not stdc types. Does the WINE team have a problem with > > changing their stdc prototypes? > > The solution that Alexandre will accept for the > Wine tree is this: > > > I think the right way would be to put that functionality in > > libwine_unicode, and follow the naming convention that we are > > using there (for instance wcstol would be strtolW). This way > > we are sure the prototypes won't conflict. > > This most likely will be the law of the land unless you can change > Alexandre's mind. <g> > I think he was implying for you to replace wcstol calls with strtolW. Hay! I've looked for it in the source and I can not find it. Not even in the Unicode headers. I guess the best way, is to make a static inline function in a header file. Ask Alex how to make strtolW and where he would like to have it, My guess, in the unicode directory. > > Steven > > Thanks, James |
8 messages has been excluded from this view by a project administrator.
