Menu
▾
▴
reactos-kernel
|
From: Aliberti E. <ea...@us...> - 2002-05-14 21:13:10
|
Hi David, > 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. But when the market said Windows 3.1 was the way to go, kernel people simply cloned csrss.exe and named it os2ss.exe, took os2srv.dll and made it loaded by os2ss.exe. csrss.exe was given three new plug-ins, which today we call Win32. But I agree with you: today, at least after the Windows 2000 debut, 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. I'd like to see a bare ReactOS system, that simply boots the kernel and runs a native shell with no subsystem at all. The really new part in the ReactOS project is IMHO the kernel part. One can dislike the Win32 API. One can dislike the POSIX API. One can dislike the OS/2 API or any other API. The advantage is that writing an OS that runs on top of the ReactOS does not require talking to the bare metal bat to the core API you are given. Win32 is NOT just another subsystem, as you say, but is the the state of the art subsystem. In this again I agree with you: Win32 should be developed by the same people that works on the core, because the Win32 API during the years apparenlty became a gentle projection of the core API. In this meaning I agree with you, when you say W32 is not distinct from NT. > 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. My proposal to split the source tree in reactos w32 psx os2 ... was only to clean "the layout of files" before the games turns big, not to say Win32 isn't the main environment subsystem of ReactOS. |
|
From: Jason F. <jas...@ya...> - 2002-05-14 21:33:14
|
Indeed, I was just about to send a mail about this. The proposed module seperation does _not_ mean anything about the goals or design of ReactOS. It is merely to make life easier for everyone by making the different parts of ReactOS more managable with regards to CVS. - Jason --- Aliberti Emanuele <ea...@us...> wrote: >My proposal to split the source tree in > >reactos >w32 >psx >os2 >... >>was only to clean "the layout of files" before the games turns big, >not to say Win32 isn't the main environment subsystem of ReactOS. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: David W. <we...@cw...> - 2002-05-14 23:17:21
|
On Tue, May 14, 2002 at 11:14:16PM +0200, Aliberti Emanuele wrote: > My proposal to split the source tree in > > reactos > w32 > psx > os2 > ... > > was only to clean "the layout of files" before the games turns big, > not to say Win32 isn't the main environment subsystem of ReactOS. > Right but the layout ought to reflect that win32 and the kernel are not really seperated; at least the system dlls (kernel32, user32, gdi32, advapi32), csrss and the security system should stay with the reactos module. |
|
From: Steven E. <Ste...@ya...> - 2002-05-14 23:40:09
|
> Right but the layout ought to reflect that win32 and the > kernel are not > really seperated; at least the system dlls (kernel32, user32, gdi32, > advapi32), csrss and the security system should stay with the reactos > module. This is what I have been saying, All of the low level win32 stuff should stay as it is and the w32 tree should be a close mirror of the wine tree. Everything else other then kernel32, user32, gdi32, advapi32, and the crt's almost be built stand alone. The biggest problem I am Having right now are A few unixism's in 2 or 3 wine dlls, the debugging interfaces they use, and mingw doesn't come with a ntdll.a import lib. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:38:41
|
At 01.40 15/05/2002, you wrote: [porting wine] >The biggest problem I am Having right now are a few unixism's in 2 or 3 >wine dlls, what kind of unixisms? |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:02:16
|
> what kind of unixisms? I have only found 2 dlls in the wine tree that are like this and they will be fixed soon. direct use of fork, getpid and similar "unixisms", direct access to unix file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix devices. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: James T. <jim...@ad...> - 2002-05-15 01:09:50
|
Steven Edwards wrote: > > > what kind of unixisms? > > I have only found 2 dlls in the wine tree that are like this and they > will be fixed soon. > direct use of fork, getpid and similar "unixisms", direct access to unix > file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix > devices. > I thought doing that in wine was a NO! NO! That is what Alex posted a year ago! James |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:13:42
|
Are you still online? If so jump on #reactos "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 James Tabor > Sent: Tuesday, May 14, 2002 9:10 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Steven Edwards wrote: > > > > > what kind of unixisms? > > > > I have only found 2 dlls in the wine tree that are like > this and they > > will be fixed soon. direct use of fork, getpid and similar > "unixisms", > > direct access to unix file system > (DOSFS_GetFullName/open/mmap/etc), > > direct access for unix devices. > > > I thought doing that in wine was a NO! NO! That is what Alex > posted a year ago! James > > _______________________________________________________________ > > 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:18:45
|
Steven Edwards wrote: > > Are you still online? If so jump on #reactos > > Yeah. were is #reactos? James |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:39:29
|
Irc.openprojects.net "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 James Tabor > Sent: Tuesday, May 14, 2002 9:19 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Steven Edwards wrote: > > > > Are you still online? If so jump on #reactos > > > > > Yeah. were is #reactos? > James > > _______________________________________________________________ > > 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: Steven E. <Ste...@ya...> - 2002-05-15 01:17:17
|
> I thought doing that in wine was a NO! NO! That is what Alex > posted a year ago! James It is, but there have been a few limited cases where he has broken his own rules. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: James T. <jim...@ad...> - 2002-05-15 01:05:26
|
Steven Edwards wrote: > > > Right but the layout ought to reflect that win32 and the > > kernel are not > > really seperated; at least the system dlls (kernel32, user32, gdi32, > > advapi32), csrss and the security system should stay with the reactos > > module. > > This is what I have been saying, All of the low level win32 stuff should > > stay as it is and the w32 tree should be a close mirror of the wine > tree. > Everything else other then kernel32, user32, gdi32, advapi32, and the > crt's > almost be built stand alone. The biggest problem I am Having right now > are > A few unixism's in 2 or 3 wine dlls, the debugging interfaces they use, > and mingw doesn't come with a ntdll.a import lib. > > Thanks > Steven > Steven, I think we need to come up with a patch for ming to include a import file for Libntdll.a. Look at and compare ROS with Wine and come up with a spec file to give to Ming. I still need your Wine source tree! Thanks, James |
|
From: Jason F. <jas...@ya...> - 2002-05-15 08:20:44
|
--- David Welch <we...@cw...> wrote: >Right but the layout ought to reflect that win32 and the kernel are >not really seperated; at least the system dlls (kernel32, user32, >gdi32, advapi32), csrss and the security system should stay with the >reactos module. Why not move out GUI related/higher level DLLs at least, that is, DLLs that are mainly ported from Wine (as Steven suggested)? This is unnecessary code for coders working on other subsystems and makes porting back and forth between Wine easier. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Casper H. <ch...@us...> - 2002-05-15 11:14:51
|
ons, 2002-05-15 kl. 01:56 skrev David Welch: > On Tue, May 14, 2002 at 11:14:16PM +0200, Aliberti Emanuele wrote: > > My proposal to split the source tree in > > > > reactos > > w32 > > psx > > os2 > > ... > > > > was only to clean "the layout of files" before the games turns big, > > not to say Win32 isn't the main environment subsystem of ReactOS. > > > Right but the layout ought to reflect that win32 and the kernel are not > really seperated; at least the system dlls (kernel32, user32, gdi32, > advapi32), csrss and the security system should stay with the reactos > module. 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. It might also be easier to develop new subsystems, because the Win32 API is a lot easier to work with than the native API. I included msafd.dll and ws2_32.dll in the list because it will be a lot easier to support a sockets API in a subsystem this way. I included services.exe because it provides functionality that you would expect from any OS (services) and also because it is tightly integrated with advapi32.dll (service API). |
|
From: KJK::Hyperion <no...@li...> - 2002-05-16 18:46:42
|
At 13.12 15/05/2002, you wrote: I know I said I didn't care anymore, but it's getting SURREAL. Like everyone suddenly forgot some small, yet ESSENTIAL details > > Right but the layout ought to reflect that win32 and the kernel are not > > really seperated; at least the system dlls (kernel32, user32, gdi32, > > advapi32), csrss and the security system should stay with the reactos > > module. >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, Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility crap, the crippled MS-DOS pathname semantics, those half-baked virtual terminal workalikes called consoles, a GUI API that is still half 16-bit (sure, it's VERY portable to pass two words packed as a single double word), a graphics API that believes to be object-oriented but really isn't. The best foundament to build your subsystem on, ain't it? Not even Microsoft believes in those anymore. See WinForms. See GDI+. See the whole .NET >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. It might also be easier to develop new subsystems, >because the Win32 API is a lot easier to work with than the native API. I propose this compromise: if some functionality makes sense to be available to all subsystems, extend the RTL API instead of feeding souls to the Win32 devil. The RTL API is almost perfect as it is for system services and libraries. Yes, you can't do interactive programs with just the RTL, but system services aren't really supposed to be interactive, right? >I included msafd.dll and ws2_32.dll in the list because it will be a lot >easier to support a sockets API in a subsystem this way. I'm fine with a native Winsock library. As long as you keep those atrocious WSA* calls in their separate pig pe--ooops, I mean "library" |
|
From: David W. <we...@cw...> - 2002-05-16 19:37:47
|
On Thu, May 16, 2002 at 06:11:19PM +0200, KJK::Hyperion wrote: > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > crap, the crippled MS-DOS pathname semantics, those half-baked virtual > terminal workalikes called consoles, a GUI API that is still half 16-bit > (sure, it's VERY portable to pass two words packed as a single double > word), a graphics API that believes to be object-oriented but really isn't. > The best foundament to build your subsystem on, ain't it? > Yes but if ReactOS is to be a non-NT OS that just happens to be able to run Win32 programs if you install that subsystem then I don't see what point there is in the project at all: Linux+Wine already does this quite admirably. > I propose this compromise: if some functionality makes sense to be > available to all subsystems, extend the RTL API instead of feeding souls to > the Win32 devil. The RTL API is almost perfect as it is for system services > and libraries. Yes, you can't do interactive programs with just the RTL, > but system services aren't really supposed to be interactive, right? > As I said before: there really isn't anything exposed through the native (including NTDLL) APIs that isn't also in Win32 and moreover I think it would be better to keep the code written for these APIs as small as possible (only smss uses native APIs exclusively and other system libraries and services only where strictly necessary) because: 1) they are inherently unportable even to proper NT so cygwin couldn't use them for example; 2) we want to keep the freedom to change them if required. I don't see what is wrong with requiring some parts of win32 to always be present - bearing in mind that (as with XP embedded) windowing, security, etc should be optional. At the moment I fear that the direction of the project is towards something that will still be too Win32-'crippled' to be of interest to UNIX programmers and not Win32 enough to be of any use for its original purpose. |
|
From: Jason F. <jas...@ya...> - 2002-05-16 20:13:50
|
--- David Welch <we...@cw...> wrote: >Yes but if ReactOS is to be a non-NT OS that just happens to be >able to run Win32 programs if you install that subsystem then I >don't see what point there is in the project at all: Linux+Wine >already does this quite admirably. Well splitting things up more wouldn't make ReactOS non-NT, only if you really leave out certain pieces when compiling a distro. >I don't see what is wrong with requiring some parts of win32 to >always be present - bearing in mind that (as with XP embedded) >windowing, security, etc should be optional. There's nothing wrong with it. Just that some people might feel it's not necessary for what they want to do with ReactOS. >At the moment I fear that the direction of the project is towards >something that will still be too Win32-'crippled' to be of interest >to UNIX programmers and not Win32 enough to be of any use for >its original purpose. I don't understand... the original thread was about how to make the source tree more modularized so that people don't checkout files they're not using. That's all.. did I miss something? - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: David W. <we...@cw...> - 2002-05-16 22:42:08
|
On Thu, May 16, 2002 at 01:12:52PM -0700, Jason Filby wrote: > Well splitting things up more wouldn't make ReactOS non-NT, only if > you really leave out certain pieces when compiling a distro. > Of course but the point was simply that if all that is wanted is a kernel with non-'crippled' semantics which can also run most Windows programs then there are much better easier ways to get it than our approach. > I don't understand... the original thread was about how to make the > source tree more modularized so that people don't checkout files > they're not using. That's all.. did I miss something? > I think it has been a touchstone for more fundamental issues about the direction of the project. |
|
From: Jason F. <jas...@ya...> - 2002-05-16 23:29:11
|
--- David Welch <we...@cw...> wrote: >On Thu, May 16, 2002 at 01:12:52PM -0700, Jason Filby wrote: >>Well splitting things up more wouldn't make ReactOS non-NT, only >>if you really leave out certain pieces when compiling a distro. >Of course but the point was simply that if all that is wanted is a >kernel with non-'crippled' semantics which can also run most Windows >programs then there are much better easier ways to get it than our >approach. What is absolutely essential is driver and application compatibility. Cloning NT, what we're doing thus far, is the best way to get the best end result. Subsystems are extensions to the project, and I think people should be allowed to make their subsystem any way they want to, as long as it doesn't touch our original goals. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Casper H. <ch...@us...> - 2002-05-16 19:52:23
|
tor, 2002-05-16 kl. 18:11 skrev KJK::Hyperion: > At 13.12 15/05/2002, you wrote: > > I know I said I didn't care anymore, but it's getting SURREAL. Like > everyone suddenly forgot some small, yet ESSENTIAL details > > > > Right but the layout ought to reflect that win32 and the kernel are not > > > really seperated; at least the system dlls (kernel32, user32, gdi32, > > > advapi32), csrss and the security system should stay with the reactos > > > module. > >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, > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > crap, Why do you think they are called kernel32.dll, gdi32.dll and user32.dll? Maybe because they are 32-bit DLLs? No 16-bit code here. the crippled MS-DOS pathname semantics, Wether DOS or unix style paths is 'the best' is a matter of taste and ReactOS can handle them both. those half-baked virtual > terminal workalikes called consoles, They do the job they were supposed to do, so why do they annoy you so much? > a GUI API that is still half 16-bit How do you define half 16-bit? > (sure, it's VERY portable to pass two words packed as a single double > word), a graphics API that believes to be object-oriented but really isn't. > The best foundament to build your subsystem on, ain't it? > Who said these modules would be mandatory for every subsystem? They would be an aid in creating new subsystems because their APIs are much more easy to work with than the native APIs. You must have experienced this when trying to create the POSIX+ subsystem. > Not even Microsoft believes in those anymore. See WinForms. See GDI+. See > the whole .NET One word for you: Evolution. I have yet to see an OS that is so good that it could not be improved upon. > > >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. It might also be easier to develop new subsystems, > >because the Win32 API is a lot easier to work with than the native API. > > I propose this compromise: if some functionality makes sense to be > available to all subsystems, extend the RTL API instead of feeding souls to > the Win32 devil. The RTL API is almost perfect as it is for system services > and libraries. Yes, you can't do interactive programs with just the RTL, > but system services aren't really supposed to be interactive, right? The native API will of course be extended when needed, but this would solve a different problem than what was suggested. Every functionality in the mentioned modules can be recreated in any other subsystem with the current native APIs. It will just require a lot of duplicate code. > > >I included msafd.dll and ws2_32.dll in the list because it will be a lot > >easier to support a sockets API in a subsystem this way. > > I'm fine with a native Winsock library. As long as you keep those atrocious > WSA* calls in their separate pig pe--ooops, I mean "library" If you don't need asynchronous socket operations, then don't use the WSA* APIs in your subsystem. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 01:02:29
|
At 21.49 16/05/2002, you wrote: > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > > crap, >Why do you think they are called kernel32.dll, gdi32.dll and user32.dll? >Maybe because they are 32-bit DLLs? No 16-bit code here. Nowhere I said "16 bit" > >the crippled MS-DOS pathname semantics, >Wether DOS or unix style paths is 'the best' is a matter of taste and >ReactOS can handle them both. My personal opinions apart, you can't force subsystem-specific pathname semantics on potentially all subsystems, especially such an inflexible syntax as Windows'. That's what native paths are for. That's what, again, the RTL is for. Essentially, I'm saying that Win32 abstracts too much to be a good subsystem support library > > a GUI API that is still half 16-bit >How do you define half 16-bit? Window messages parameters. It's clear that they simply lifted code from Windows 3.1 to Windows 95. It's been, I believe, the biggest obstacle to Win64 > > I propose this compromise: if some functionality makes sense to be > > available to all subsystems, extend the RTL API instead of feeding > souls to > > the Win32 devil. The RTL API is almost perfect as it is for system > services > > and libraries. Yes, you can't do interactive programs with just the RTL, > > but system services aren't really supposed to be interactive, right? >The native API will of course be extended when needed, but this would >solve a different problem than what was suggested. Every functionality in >the mentioned modules can be recreated in any other subsystem with the >current native APIs. It will just require a lot of duplicate code. Nope. I'm not talking about the native API (Nt* and Zw*), I'm talking about the RTL (Rtl*), they're orthogonal. All parts of Win32 <strong>that don't handle the user interface</strong> are thin wrappers (or worse, duplicates) of the RTL. But the RTL has the advantage of being *designed* to be subsystem-independent, unlike Win32 > > >I included msafd.dll and ws2_32.dll in the list because it will be a lot > > >easier to support a sockets API in a subsystem this way. > > I'm fine with a native Winsock library. As long as you keep those > atrocious > > WSA* calls in their separate pig pe--ooops, I mean "library" >If you don't need asynchronous socket operations, then don't use the WSA* >APIs in your subsystem. One word for you: WSAStartup Oh, and some more: artificial dependency from user32. Some of those WSA* calls use <shudder> window messages to notify threads (BTW, for asynchronous socket operations you don't need WSA*, you just use the asynchronous I/O calls you'd use with files) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 01:23:25
|
At 22.38 16/05/2002, you wrote: >On Thu, May 16, 2002 at 06:11:19PM +0200, KJK::Hyperion wrote: > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > > crap, the crippled MS-DOS pathname semantics, those half-baked virtual > > terminal workalikes called consoles, a GUI API that is still half 16-bit > > (sure, it's VERY portable to pass two words packed as a single double > > word), a graphics API that believes to be object-oriented but really > isn't. > > The best foundament to build your subsystem on, ain't it? >Yes but if ReactOS is to be a non-NT OS that just happens to be able to >run Win32 programs if you install that subsystem then I don't see what >point there is in the project at all: Linux+Wine already does this quite >admirably. The point was, AFAIK, to run NT device drivers. Personally, I'll consider ReactOS more than successful when this will be achieved: to the best of my knowledge, no other free OS has this goal, and it's not easy at all to achieve 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 And IIRC they're planning to eventually adopt a NT-like architecture, with all libraries based on ntdll.dll (Stephen, can you confirm?) > > I propose this compromise: if some functionality makes sense to be > > available to all subsystems, extend the RTL API instead of feeding > souls to > > the Win32 devil. The RTL API is almost perfect as it is for system > services > > and libraries. Yes, you can't do interactive programs with just the RTL, > > but system services aren't really supposed to be interactive, right? >As I said before: there really isn't anything exposed through the native >(including NTDLL) APIs that isn't also in Win32 and moreover I think it >would be better to keep the code written for these APIs as small as >possible (only smss uses native APIs exclusively and other system >libraries and services only where strictly necessary) because: 1) they are >inherently unportable even to proper NT so cygwin couldn't use them for >example; 2) we want to keep the freedom to change them if required. I don't know if the lowest level components of some operating system are even supposed to be portable. And I don't see the point in moving ReactOS system services on a NT kernel or viceversa, except for testing purposes >I don't see what is wrong with requiring some parts of win32 to always be >present - bearing in mind that (as with XP embedded) windowing, security, >etc should be optional. I'm ok with installing a basic subset of Win32, <strong>to support applications</strong>. Not to build system services on it. The native API, low level as it is, has enough overhead and pitfalls. Win32 adds even more >At the moment I fear that the direction of the project is towards >something that will still be too Win32-'crippled' to be of interest to >UNIX programmers and not Win32 enough to be of any use for its original >purpose. Can you explain? |
|
From: Casper H. <ch...@us...> - 2002-05-17 12:18:34
|
fre, 2002-05-17 kl. 03:19 skrev KJK::Hyperion: > The point was, AFAIK, to run NT device drivers. Personally, I'll consider > ReactOS more than successful when this will be achieved: to the best of my > knowledge, no other free OS has this goal, and it's not easy at all to achieve 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? > > 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. If ReactOS should abandon Win32 and leave it to WINE then you have changed the original goals of this project. IMO, a lot more than the votes of a few developers should be necesarry to do this. If ReactOS is not to provide Win32 compatibility, then ReactOS has no advantages over your average OSS OS project out there. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 17:16:48
|
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" |
|
From: Casper H. <ch...@us...> - 2002-05-17 17:40:48
|
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. |
