why folks

[Enrico Weigelt]

Hi folks,

a very general question:

why are you developing a completely new kernel instead of using an
existing one like linux or hurd and running reactos just as a 
subsystem, perhaps with some kernel improvements.

For example: linux brings very good memory management and filesystem.
If you want to use Xwindow, you can use a direct graphics backend 
for the UI. Console applications could run directly on stdio as
all unix console applications do.

Doing so lets you run the windows applications within a another
host operating system and integrating both together.

So what are the advantages of another own kernel against a subsystem
in another host operating system ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Robert Köpferl]

We want API and even ABI compatibility. And also semantic compatibility, 
which is very hard do gain with an emulation layer.
ABI = binary compatible

Enrico Weigelt schrieb:
>   Hi folks,
>  
>  a very general question:
>  
>  why are you developing a completely new kernel instead of using an
>  existing one like linux or hurd and running reactos just as a 
>  subsystem, perhaps with some kernel improvements.
>  
>  For example: linux brings very good memory management and filesystem.
>  If you want to use Xwindow, you can use a direct graphics backend 
>  for the UI. Console applications could run directly on stdio as
>  all unix console applications do.
>  
>  Doing so lets you run the windows applications within a another
>  host operating system and integrating both together.
>  
>  So what are the advantages of another own kernel against a subsystem
>  in another host operating system ?
>  
>  
>  cu

[Enrico Weigelt]

* Robert Köpferl <rob(a)koepferl.de> [2004-02-15 16:51:31 +0100]:

Hi,

>   We want API and even ABI compatibility. And also
> semantic compatibility, 
>  which is very hard do gain with an emulation layer. 
what's exactly the difference to an approach like win from this point ?
since NT has a microkernel, it shoulnd be so hard to get a wide range of 
drivers running in an emulation.


+ printer drivers (IMHO) normally operate as a GDI device and produce
  output for the interface devices (call appr. functions)
  --> should be runnable in a libwine-like environment
  
+ codecs, etc are (IMHO) normal userland dlls which already work in 
  some gnu or x-platform players.
  
+ video hardware drivers are a bit more trickier, but they mostly 
  do some IO-ops and operate in a framebuffer or somthing similar.
  IMHO they also have to allocate their resources from the kernel
  instead of doing hard direct hardware access (manipulatoing CPU, etc)
  so it should be possible to emulate this.
  
  
So what exactly makes the emulation so bad that you decided to write
a completely new kernel, which means rewriting most functionality of   
existing and heavily tested kernels like linux ?

(dont get me wrong - i dont want to call you stupid, but I just wanna
understand the reeasons why you start such a huge project instead of 
imporoving other quite good working ones)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Casper Hornstrup]

Same reason many companies don't bother to support Linux. Linux kernel-mode
APIs change very often and Linux APIs are usually not backwards compatible.
>  From kernel 2.6 you even need to compile your driver
> with the same compiler 
that is used to compile the kernel. So, if you want to
support two Linux
distributions which are compiled with different compilers, then you need to
distribute two binaries of your driver. If you want to support SMP
configuration (in addition to UP configuration), you need to distribute two
additional binaries.

Casper

-----Original Message-----
From: ros-general-bounces(a)reactos.com
[mailto:[e-mail]] On Behalf Of Enrico Weigelt
Sent: 15. februar 2004 16:31
To: ros-general(a)reactos.com
Subject: [ros-general] why folks


Hi folks,

a very general question:

why are you developing a completely new kernel instead of using an
existing one like linux or hurd and running reactos just as a 
subsystem, perhaps with some kernel improvements.

For example: linux brings very good memory management and filesystem.
If you want to use Xwindow, you can use a direct graphics backend 
for the UI. Console applications could run directly on stdio as
all unix console applications do.

Doing so lets you run the windows applications within a another
host operating system and integrating both together.

So what are the advantages of another own kernel against a subsystem
in another host operating system ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------
_______________________________________________
ros-general mailing list
ros-general(a)reactos.com
http://reactos.com/mailman/listinfo/ros-general

[Enrico Weigelt]

* Casper Hornstrup <chorns(a)users.sourceforge.net> [2004-02-15 17:16:50 +0100]:

>   Same reason many companies don't bother to support
> Linux. Linux kernel-mode
>  APIs change very often and Linux APIs are usually not backwards compatible. 
Well,
that's one reason where it gets its performance and flexibility from. 

BTW: the APIs for things which are interesting for hardware vendors dont change
very much (normally in one major release, the things stay the same - and they
dont change in less than a year)
Binary interfaces may change several times, but it just takes a recompile to
make it work. At least you have to ship two builds, one for smp + no-smp.
Also different builds for several architectures are required.

So you want to set up a buildfarm for those different targets. Once we have
one, it doesnt really matter if we have distinctions between kernel versions.

And if you really _need_ binary compatibility, its possible to plug in an 
ABI-adaptor, which allows running third-party binary modules.
This of course, takes away all these optimizations for those modules, but
they're working.

So it doesnt need to develop a new kernel just to have a consitent driver ABI.

<snip>
>   So, if you want to support two Linux distributions
> which are compiled with 
>  different compilers, then you need to distribute two binaries of your driver. 
>  If you want to support SMP configuration (in addition to UP configuration), 
>  you need to distribute two additional binaries. 
What's the problem ? 
Some hardware vendors are already doing it. 

If you really, really want one binary module (i.e. you feel you cannot
publish sourcecode due some contracts) you can write a very small wrapper
which loads the real binary driver. This wrapper will be opensource and 
built against the current kernel.

Have a look at nvidia's binary drivers. They went this way.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[KJK::Hyperion]

At 23.23 16/02/2004, you wrote:
>  Well, that's one reason where it gets its
> performance and flexibility from. 
[...]

don't insist. ReactOS is going South, and it's not heading back. We don't 
give a damn about the wonders and rivers of mead and fields of gold that 
lie North, everyone knows about those. We want to know what lies South. We 
really, positively, definitely do

Don't waste your time and ours, it's not like rationalizing yet more will 
make us change our minds after years of dedicated hard work. In fact, 
rationalizing _never works_ - either you get the concept right on the first 
shot, or you find yourself stuck in an exercise of dead horse dragging: not 
so fun to begin with, and it only gets worse

[Robert Köpferl]

Yea, our KJK.
Don't be so hard to guests.
However you are right. Guest: If we decided to do so for years, we will 
not make a 180° turn due to your apearing.

KJK::Hyperion schrieb:

>   At 23.23 16/02/2004, you wrote:
>  
> >   Well, that's one reason where it gets its
> > performance and flexibility 
> >  from. 
>  
>  [...]
>  
>  don't insist. ReactOS is going South, and it's not heading back. We 
>  don't give a damn about the wonders and rivers of mead and fields of 
>  gold that lie North, everyone knows about those. We want to know what 
>  lies South. We really, positively, definitely do
>  
>  Don't waste your time and ours, it's not like rationalizing yet more 
>  will make us change our minds after years of dedicated hard work. In 
>  fact, rationalizing _never works_ - either you get the concept right on 
>  the first shot, or you find yourself stuck in an exercise of dead horse 
>  dragging: not so fun to begin with, and it only gets worse
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general

[Enrico Weigelt]

* Robert Köpferl <rob(a)koepferl.de> [2004-02-17 01:09:07 +0100]:

>   Yea, our KJK.
>  Don't be so hard to guests.
>  However you are right.  
>   Guest: If we decided to do so for years, we will 
>  not make a 180° turn due to your apearing. 
I never wanted you to do so. I just
wanted to know your reasons.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Ge van Geldorp]

You seem to have the impression that the architecture of a kernel
doesn't matter for the apps you want to run on it. "Just plug in a
subsystem". It simply doesn't work that way. What you are suggesting is
taking a Harley Davidson motor cycle and a Ferrari and swap the engines.
"Hey, they're just engines, right?". Although you could maybe make it
work, the end result will be rather disappointing.

Gé van Geldorp.

[Enrico Weigelt]

* KJK::Hyperion <noog(a)libero.it> [2004-02-17 00:45:02 +0100]:

>   At 23.23 16/02/2004, you wrote:
> >  Well, that's one reason where it gets its
> > performance and flexibility from. 
>  [...]
>  
>  don't insist. ReactOS is going South, and it's not heading back. We don't 
>  give a damn about the wonders and rivers of mead and fields of gold that 
>  lie North, everyone knows about those. We want to know what lies South. We 
>  really, positively, definitely do 
What do you want to say with this ?

<snip>
>   Don't waste your time and ours, it's not like
> rationalizing yet more will 
>  make us change our minds after years of dedicated hard work. In fact,  
You
completely misunderstood me. I dont want to change your mind, I just
wanted to know you reasons for your decisions.
I'd just like to know, what existing OS'es dont have what you require.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Patrick Mauritz]

On Tue, Feb 17, 2004 at 02:31:35PM +0100, Enrico Weigelt wrote:
>   I'd just like to know, what existing OS'es
> dont have what you require. 
a post-1980 OS architecture, for a start.


patrick mauritz

[Enrico Weigelt]

* Patrick Mauritz <oxygene(a)studentenbude.ath.cx> [2004-02-17 14:53:26 +0100]:

>   On Tue, Feb 17, 2004 at 02:31:35PM +0100, Enrico
> Weigelt wrote:
> >   I'd just like to know, what existing
> > OS'es dont have what you require. 
>  a post-1980 OS architecture, for a start.
You didnt really answer the question. 

BTW the architecture of the Linux kernel is newer than 1980, although
it provides a unix-style userland vm. I dont see whats wrong with 
this, yet - but I'd like to hear your arguments.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Patrick Mauritz]

Am Dienstag, 17. Februar 2004 19:47 schrieb Enrico Weigelt:
>   You didnt really answer the question. 
sorry, I
guess there were too many, hidden in too many mails

>   BTW the architecture of the Linux kernel is newer than
> 1980, although
>  it provides a unix-style userland vm. I dont see whats wrong with
>  this, yet - but I'd like to hear your arguments. 
people tend to joke about the
change in WinNT4 where parts of the graphic 
driver were moved to kernelspace and point to the "superior" design of linux.

let's see:
 - fbdev: reduced functionality, unstable graphic drivers with a real
   management problem
 - DRM/DRI+agpgart: kernelguard with userspace module, 3D only
 - XFree86: drivers in userspace that get access to ring0 instructions
   (inb/outb), enumerate the pci bus by themselves (code duplication, bad
   design, potential problems), directly interact with hardware (which needs
   synchronization with the kernel in more than one way) - btw: these inb/outb
   things are accessible to each and every process running as root (and can
   program every hardware you have, read out your keyboard controller, rape
   your cat...)
 - directfb: works on top of fbdev, inherits its problems and needs root+ring0
   accessors, combining both the worst parts of fbdev and XFree86 (while
   solving the problems of its authors, so I guess that's ok)

what exactly is superior with that?

similar reasons apply to most other parts of the linux kernel: they're either 
_inferior_ to the WinNT design (maybe not in implementation but that's one of 
the things ReactOS must do different, by design) or plain incompatible. and 
before you start with "how about improving linux": with a strong
"benevolent 
dictator" it might be hard to get architectural improvements into linux, look 
for project UDI on lkml as reference what happens to people suggesting 
this...
also, reactos started with "real code" in 1997 or 1998 - what was the state of 
linux back then?
finally, the last 6 months were about the most successful months in the 
existance of ReactOS - a good reason to move on, instead of retargetting, or 
not?

there are a lot of things that went pretty good with linux, but using a 
remotely modern design (where are personalities, when you need them?) and 
subscribing to API contracts (see UDI discussions or the problems nvidia has 
to catch up with their drivers) are definitely not on their agenda.

grow up


patrick mauritz

[Enrico Weigelt]

* Patrick Mauritz <oxygene(a)studentenbude.ath.cx> [2004-02-17 20:45:49 +0100]:

<snip>
> >   BTW the
> > architecture of the Linux kernel is newer than 1980, although
> >  it provides a unix-style userland vm. I dont see whats wrong with
> >  this, yet - but I'd like to hear your arguments. 
>  people tend to joke about the
> change in WinNT4 where parts of the graphic 
>  driver were moved to kernelspace and point to the "superior" design of linux.
If you dont like it, why not writing something better for the linux kernel ?

>   similar reasons apply to most other parts of the linux
> kernel: they're either 
>  _inferior_ to the WinNT design (maybe not in implementation but that's one of 
>  the things ReactOS must do different, by design) or plain incompatible. and 
>  before you start with "how about improving linux": with a strong
> "benevolent 
>  dictator" it might be hard to get architectural improvements into linux, look 
>  for project UDI on lkml as reference what happens to people suggesting 
>  this... 
Why not a new kernel branche / inofficial patches ?
If the code is good, they'll someday take it into the official distro.

Many good kernel projects were developed outside of the main tree for a
very long time, i.e. isdn4linux, capi4linux, alsa, ...

>   also, reactos started with "real code" in
> 1997 or 1998 - what was the state of 
>  linux back then? 
Okay. 

<snip>
>   there are a lot of things that went pretty good with
> linux, but using a 
>  remotely modern design (where are personalities, when you need them?) and 
personalities ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Patrick Mauritz]

Am Mittwoch, 18. Februar 2004 20:57 schrieb Enrico Weigelt:
> >   people tend to
> > joke about the change in WinNT4 where parts of the graphic
> >  driver were moved to kernelspace and point to the "superior" design of
> >  linux. 
>  If you dont like it, why not writing something better for the linux kernel
kgi-wip.sf.net, #kgi on irc.freenode.org

also take a look for mentions of kgi on the linux-kernel mailing list. the 
situation is similar to UDI (you'll get _roasted_ from all sides)

>   Why not a new kernel branche / inofficial patches ?
>  If the code is good, they'll someday take it into the official distro. 
where
"someday" might be when epoch equals infinity, depending on who's toes 
you step on. (see kgi on lkml)

>   Many good kernel projects were developed outside of
> the main tree for a
>  very long time, i.e. isdn4linux, capi4linux, alsa, ... 
in which way is that
different to writing your own kernel, if you have to 
redesign or improve most of it, anyway - except for bootstrapping a working 
ReactOS system, which is done by now?
this discussion takes place at least two years too late for any constructive 
outcome.

>   personalities ? 
like on WinNT: Posix+, Win32,
OS/2, DOS - all of them are different 
personalities of the OS in the way that they represent a different interface 
to client applications, yet building on the same foundation.


patrick mauritz
-- 
there is no holy grail.

[Enrico Weigelt]

* Patrick Mauritz <oxygene(a)studentenbude.ath.cx> [2004-02-18 21:25:32 +0100]:

<snip>
>   kgi-wip.sf.net, #kgi on irc.freenode.org
>  
>  also take a look for mentions of kgi on the linux-kernel mailing list. the 
>  situation is similar to UDI (you'll get _roasted_ from all sides) 
Well, I know such things, i.e. when I was recently talking on the 
mplayer-dev-eng about moving out codecs to a general-purpose codec-lib.
(there's now such a project, called media-api, where matroska people
and some mplayer folks live peacefully ;-))

You shouldn't really care about this. 

At least you've got a killfile ;-)

> >   Why not a new
> > kernel branche / inofficial patches ?
> >  If the code is good, they'll someday take it into the official distro. 
>  where
> "someday" might be when epoch equals infinity, depending on who's toes 
>  you step on. (see kgi on lkml) 
Well, for me it doesnt matter. 
I've no trouble with patching the kernel. On many larger projects it is
quite normal (i.e. the MUA mutt has many "inofficial" patches, which are
good but not yet included in the main distributions). Often it is because
the maintainers feel the patches are not "good enought" for getting into
main branch. Thats no problem for me - and no real reason for starting
completely from scratch :)


<snip>
> >   Many good
> > kernel projects were developed outside of the main tree for a
> >  very long time, i.e. isdn4linux, capi4linux, alsa, ... 
>  in which way is that
> different to writing your own kernel, if you have to 
>  redesign or improve most of it, anyway - except for bootstrapping a working  
What's wrong with the memory management and the vm subsystem ?
What's wrong with the filesystem ?
What's wrong with the socket interface and the networking stuff ?

I can understand, if you dont like Xwindow - for just local applications
its perhaps a little bit bloated, but if you gonna use remote displays, 
you dont really want RDP ...

<snip>
> >   personalities
> > ? 
>  like on WinNT: Posix+, Win32, OS/2, DOS - all of them are different 
>  personalities of the OS in the way that they represent a different interface 
>  to client applications, yet building on the same foundation. 
Ah, several different
vm subsystems. 
There was something for some other unices, but I dont know if its still
in the kernel. 

On Linux those things are normally done in userland, but this doesn't 
necessarily have to be optimal ... that's what I meant with kernel 
support for wine.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Patrick Mauritz]

Am Mittwoch, 18. Februar 2004 21:55 schrieb Enrico Weigelt:
>   You shouldn't really care about this [flaming].
I care about it, if I intend to eventually get improvements in (which was the 
prerogative of the 'improve linux then' idea).
as for kgi, I just ignore linux - other XFree86-using systems are interested 
in jumping ship and eventually linux will need to face the decision again - 
under different circumstances. that option wouldn't exist for NT-on-Linux 
though due to its linux-specific nature.

>   Well, for me it doesnt matter.
>  I've no trouble with patching the kernel. On many larger projects it is
>  quite normal (i.e. the MUA mutt has many "inofficial" patches, which are
>  good but not yet included in the main distributions). Often it is because
>  the maintainers feel the patches are not "good enought" for getting into
>  main branch. Thats no problem for me - and no real reason for starting
>  completely from scratch :) 
they just want to extend some parts of the MUA. ReactOS
otoh couldn't rely on 
stable behaviour (or APIs) within linux to build a feature-by-feature, 
API-by-API copy of WinNT - quite a difference.
and not being able to follow the kernel in its track is a bad thing, too - see 
the 2.6.3/2.4.25 release with patches for exploits as example - do you really 
want to isolate all these all the time as you're unable to just merge with 
it?
that's a lot of work :)

>   What's wrong with the memory management and the vm
> subsystem ? 
hmm.. rewritten way to often to rely on it? (even within
"stable" kernel 
series)

>   What's wrong with the filesystem ? 
different
semantics from NT filesystems.
where are streams, OIDs, ...?

>   What's wrong with the socket interface and the
> networking stuff ? 
no problem, which is why it might be copied over.

>   I can understand, if you dont like Xwindow - for just
> local applications
>  its perhaps a little bit bloated, but if you gonna use remote displays,
>  you dont really want RDP ... 
X isn't bloated, au contraire, it lacks quite a
bunch of features. it's 
client/server design is pretty solid (and damn fast) though.

what I have a problem with is the architecture of their (and kernel's) drivers


>   Ah, several different vm subsystems.
>  There was something for some other unices, but I dont know if its still
>  in the kernel. 
icbs, and no, it should be gone. also, show me that it's
semantically similar 
to the way NT does it


the current ROS design is pretty much modelled after NT - which makes further 
compatibility easier. that wouldn't have been possible with a linux based 
system (except if it would look the same by now, which means that only 
bootstrapping were affected)


patrick mauritz

[Ricardo Ramalho]

Hi there!

<quote>
	people tend to joke about the change in WinNT4 where parts of the
graphic driver were 	moved to kernelspace and point to the "superior"
design of linux.

	let's see:
	 - fbdev: reduced functionality, unstable graphic drivers with a
real
	   management problem
	 - DRM/DRI+agpgart: kernelguard with userspace module, 3D only
	 - XFree86: drivers in userspace that get access to ring0
instructions
	   (inb/outb), enumerate the pci bus by themselves (code
duplication, bad
	   design, potential problems), directly interact with hardware
(which needs
	   synchronization with the kernel in more than one way) - btw:
these inb/outb
	   things are accessible to each and every process running as root
(and can
	   program every hardware you have, read out your keyboard
controller, rape
	   your cat...)
	 - directfb: works on top of fbdev, inherits its problems and needs
root+ring0
	   accessors, combining both the worst parts of fbdev and XFree86
(while
	   solving the problems of its authors, so I guess that's ok)
	
	what exactly is superior with that?
</quote>

Quite truthfull comments. No doubts. Just don't make them to Linux, make
those comments about *nix in general. *nix wasn't made for graphics. X was
an add-on. People are trying to put a client/server architecture working
fast. That needs hacking. But... Isn't Windows hacked in the same way? It
surely does not have these problems! It has some others.

I would say both systems are *equivalent* in this matter...

<quote>
	similar reasons apply to most other parts of the linux kernel:
they're either _inferior_ to 	the WinNT design (maybe not in
implementation but that's one of the things ReactOS must do 	different,
by design) or plain incompatible. and before you start with "how about
improving 	linux": with a strong "benevolent dictator" it might be hard
to get architectural 	improvements into linux, look for project UDI on
lkml as reference what happens to people 	suggesting this...
	also, reactos started with "real code" in 1997 or 1998 - what was
the state of linux back 	then?
	finally, the last 6 months were about the most successful months in
the existance of ReactOS 	- a good reason to move on, instead of
retargetting, or not?
	
	there are a lot of things that went pretty good with linux, but
using a remotely modern 	design (where are personalities, when you
need them?) and subscribing to API contracts (see 	UDI discussions or
the problems nvidia has to catch up with their drivers) are definitely 	not
on their agenda.

	grow up
	
	
	patrick mauritz
</quote>

Inferior in design? LOL! I will *not* comment that part... 

Continuing...

The binary driver thing "problem" is one and one only. The whole system is
open. Why should it be closed for drivers? Those drivers would use code
written with the hard work of others... It's not fair. Why shouldn't they
give the driver's code? 

You seem to hate Linux with all your nerves. You grow up. No system is
perfect! Some are better on some respects... Some are better on others. We
should all learn with what others do. 

Some people here are immensely *arrogant*! That's NOT good for the project.
Regardless of the quality of their work.

Sorry if I offended someone.

Just my 2 cents,

Ricardo

[Patrick Mauritz]

Am Mittwoch, 18. Februar 2004 21:14 schrieb Ricardo Ramalho:
>   Quite truthfull comments. No doubts. Just don't
> make them to Linux, make
>  those comments about *nix in general. *nix wasn't made for graphics. X was 
unix
in general has proper solutions to this problem: X with proper hardware 
abstraction in kernel. that just won't work right on x86 without strong 
support by hardware vendors .

>   an add-on. People are trying to put a client/server
> architecture working
>  fast. That needs hacking. But... Isn't Windows hacked in the same way? It 
the
client/server part of X11 is actually solved pretty nice and clean. it's 
the driver side (which is entirely unrelated to the client/server part) which 
is a mess. driver side, as in "kernel related".
this discussion started out with "why not use linux as base of reactos" (moved 
to some past form later-on), so of course, I'll only argue about kernel 
issues.

>   surely does not have these problems! It has some
> others.
>
>  I would say both systems are *equivalent* in this matter... 
do they have a
different set of problems or are they equivalent? I'm confused 
now.

>   Inferior in design? LOL! I will *not* comment that
> part... 
lack of arguments?

>   The binary driver thing "problem" is one and
> one only. The whole system is
>  open. Why should it be closed for drivers? Those drivers would use code
>  written with the hard work of others... It's not fair. Why shouldn't they
>  give the driver's code? 
because they have contractual obligations that prevent
them from doing it?

see, nvidia looks for me like a company that bought most of its "intellectual 
property" and thus _can't_ release specs or drivers under a half-way free 
license, even if they wanted (and there are claims that some of their 
technicians really, really want to do that) - just as an example.

still, their driver hugely boosts linux on the market, including the 
contributions of other people - why make it harder for them than necessary?

I'm _not_ talking about copying code verbatim, just about some reliable long 
term API/ABI contracts for drivers.

>   You seem to hate Linux with all your nerves. You grow
> up. No system is 
look at the headers of my mails: mailer on kde/linux, mail server
on netbsd, 
smarthost on linux - just to get the facts straight, I have _no_ win32 
installation here because I find the user accessible side of win32 
inconvenient (unlike the linux GUIs), while I can ignore the kernel 
weaknesses of linux as I don't need to do kernel hacking every day.

>   perfect! Some are better on some respects... Some are
> better on others. We
>  should all learn with what others do. 
linux is good on methodology (which leads to
a solid implementation), so 
ReactOS roughly models it. fine.
WinNT is good when employing a pretty solid, half-way modern design, so 
ReactOS models it, closely. also, fine.

so ReactOS learned, and I'm happy (even if I'm not a developer for ROS, due to 
other priorities). In the end, ROS is able to get a good development method, 
a solid implementation based on a working, reliable design - isn't that the 
goal?

>   Some people here are immensely *arrogant*! That's
> NOT good for the project.
>  Regardless of the quality of their work. 
I gather that in your opinion Linux
Fanboyism is not arrogant, yes? _that_ is 
NOT good for the deployment of the project as it make linux people look like 
zealots instead of reasonable people (which most of them are, but you now - 
guilty by association etc)


patrick mauritz

(if any of you consider this subtread offtopic, tell me off-list and I'll shut 
up)

[Enrico Weigelt]

* Patrick Mauritz <oxygene(a)studentenbude.ath.cx> [2004-02-18 21:51:59 +0100]:

<snip>
>   I'm _not_ talking about copying code verbatim,
> just about some reliable long 
>  term API/ABI contracts for drivers. 
Why not ? 
This could be done quite easily on top of the current architecture. 
A small opensource stub could be used to load/link the drivers and dispatch
some api calls which are probably not binary compatible. The ABI-loader
could be build so that it links those functions which match to the current
kernel directly and put small stubs between those which dont.
(i.e. a module i386-smp could directly match into a kernel built for 
i386-smp, but i686-nosmp perhaps wouldnt match and so has to be wrapped)

<snip>
>   WinNT is good when employing a pretty solid, half-way
> modern design, so 
>  ReactOS models it, closely. also, fine. 
What exactly on winnt do you consider
"modern design" ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[KJK::Hyperion]

At 22.14 18/02/2004, you wrote:
>  What exactly on winnt do you consider "modern
> design" ? 
no sweat, hon, I'm working on that part

[Enrico Weigelt]

* Ricardo Ramalho <rjsr(a)netcabo.pt> [2004-02-18 20:14:31 -0000]:

<snip>

>   The binary driver thing "problem" is one and
> one only. The whole system is
>  open. Why should it be closed for drivers? Those drivers would use code
>  written with the hard work of others... It's not fair. Why shouldn't they
>  give the driver's code?  
100% ACK.

But I can understand companies, which are forced to publish only binary
drivers because of domestic contracts with third parties (i.e. nvidia 
is in this bad situation). I dont like the idea of propretiary kernel 
drivers or root-only applications - for example they're big security
problems. 

btw: nvidia has found a moderate way of the trouble: they've written a
small opensource stub driver, which loads the real binary driver and
dispatches the calls to its own binary interface.

You could also write generic driver interfaces / ABIs for many device
types if you like / feel you require them. Of course this forbids many
compiler optimizations and so slows down a little bit in comparison
with "native" opensource drivers - but winnt has the same problem.

<snip>
>   You seem to hate Linux with all your nerves. You grow
> up. No system is
>  perfect! Some are better on some respects... Some are better on others. We
>  should all learn with what others do. 
>
>  Some people here are immensely *arrogant*! That's NOT good for the project.
>  Regardless of the quality of their work. 
ACK.
We've got the same problems in the mplayer project ... seems to be a quite
normal illness of coders ;-)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Patrick Mauritz]

Am Mittwoch, 18. Februar 2004 22:05 schrieb Enrico Weigelt:
>   btw: nvidia has found a moderate way of the trouble:
> they've written a
>  small opensource stub driver, which loads the real binary driver and
>  dispatches the calls to its own binary interface. 
which needs to be adapted for
more or less each single kernel revision. how 
many kernel revisions appeared over the lifetime of Win2K?
does the windows version of exactly the same driver (the linux binary stub 
models parts of the windows registry, so it's _really_ the same one) change 
for each of these revisions, too?

>   You could also write generic driver interfaces / ABIs
> for many device
>  types if you like / feel you require them. Of course this forbids many
>  compiler optimizations and so slows down a little bit in comparison
>  with "native" opensource drivers - but winnt has the same problem. 
driver
code (esp for hardware) usually is not the bottleneck - much time is 
spent in loops, waiting for the hardware, anyway.

>   ACK.
>  We've got the same problems in the mplayer project ... seems to be a quite
>  normal illness of coders ;-) 
no, maybe these people are just tired explaining
things over and over again 
and fighting the same battles uphill all the time..
it's easy to stand on top and laughing about those coming up to you while 
kicking yet another stone in their direction - even when they might be right 
(but you're only pretending to be interested in listening)

_that_ is why I'm getting pretty aggressive when I encounter behaviour that is 
similar to that of (linux) fanboys (no idea about hyperion's motives to react 
the way he does)


patrick mauritz

[Ricardo Ramalho]

Hi there again,

I said what I said about arrogance because of I read on this ml. Some people
are arrogant in the way they answer some questions. Some of the questions
may be somehow boring or even stupid at times, *but* in those cases it's
best to ignore them and not answer...

And I repeat what I said on my other mail. I'm really sorry if I offended
anyone.

As for being a "Linux Fanboy"... Wich I'm not! ;) I am a "OS
fanboy". I like
to learn. I like to experiment. Each OS has negative and positive points.
There's no holy grail of OS's.

BTW: ROS is looking cool. It's a bit on the slow side, but it's cool! :) 

Stay cool people,

---------------
Ricardo Ramalho
In Reply to: 

-----Original Message-----
From: ros-general-bounces(a)reactos.com
[mailto:[e-mail]] On Behalf Of Patrick Mauritz
Sent: quarta-feira, 18 de Fevereiro de 2004 21:47
To: weigelt(a)metux.de; ros-general(a)reactos.com
Subject: Re: [ros-general] why folks

Am Mittwoch, 18. Februar 2004 22:05 schrieb Enrico Weigelt:
>   btw: nvidia has found a moderate way of the trouble:
> they've written a 
>  small opensource stub driver, which loads the real binary driver and 
>  dispatches the calls to its own binary interface. 
which needs to be adapted for
more or less each single kernel revision. how
many kernel revisions appeared over the lifetime of Win2K?
does the windows version of exactly the same driver (the linux binary stub
models parts of the windows registry, so it's _really_ the same one) change
for each of these revisions, too?

>   You could also write generic driver interfaces / ABIs
> for many device 
>  types if you like / feel you require them. Of course this forbids many 
>  compiler optimizations and so slows down a little bit in comparison 
>  with "native" opensource drivers - but winnt has the same problem. 
driver
code (esp for hardware) usually is not the bottleneck - much time is
spent in loops, waiting for the hardware, anyway.

>   ACK.
>  We've got the same problems in the mplayer project ... seems to be a 
>  quite normal illness of coders ;-) 
no, maybe these people are just tired explaining
things over and over again
and fighting the same battles uphill all the time..
it's easy to stand on top and laughing about those coming up to you while
kicking yet another stone in their direction - even when they might be right
(but you're only pretending to be interested in listening)

_that_ is why I'm getting pretty aggressive when I encounter behaviour that
is similar to that of (linux) fanboys (no idea about hyperion's motives to
react the way he does)


patrick mauritz
_______________________________________________
ros-general mailing list
ros-general(a)reactos.com
http://reactos.com/mailman/listinfo/ros-general

[KJK::Hyperion]

At 22.46 18/02/2004, you wrote:
>  (no idea about hyperion's motives to react the way
> he does) 
Normally here I'd spew some witticisms, collect the applause, bow and go 
home. I'll try, instead, to (gasp!) rationalize. Let's say I ask you "are 
you eterosexual?", and after you reply I ask you, with the straightest 
face, "why?", and won't take "because" as a reply (because, hey,
you've 
invested your whole life on your sexual orientation, and you're telling me 
you put no planning or risk assessment in the choice?). How would *you* react?

[Vizzini]

On Wed, 2004-02-18 at 20:11, KJK::Hyperion wrote:
>   At 22.46 18/02/2004, you wrote:
>  >(no idea about hyperion's motives to react the way he does) 
<snip>

>   face, "why?", and won't take
> "because" as a reply (because, hey, you've 
>  invested your whole life on your sexual orientation, and you're telling me 
>  you put no planning or risk assessment in the choice?). How would *you* react?  
Stuff like this is the reason i haven't procmailed this thread into the
bit bucket. :-)

[James Tabor]

KJK::Hyperion wrote:
>   At 22.46 18/02/2004, you wrote:
>  
> >   (no idea about hyperion's motives to react
> > the way he does) 
>  
>  
>  Normally here I'd spew some witticisms, collect the applause, bow and go 
>  home. I'll try, instead, to (gasp!) rationalize. Let's say I ask you 
>  "are you eterosexual?", and after you reply I ask you, with the 
>  straightest face, "why?", and won't take "because" as a reply
> (because, 
>  hey, you've invested your whole life on your sexual orientation, and 
>  you're telling me you put no planning or risk assessment in the 
>  choice?). How would *you* react? 
LOL! Oh my!

Everyone leave Hyperion alone,
James

[Patrick Mauritz]

Am Donnerstag, 19. Februar 2004 03:11 schrieb KJK::Hyperion:
>   At 22.46 18/02/2004, you wrote:
>  >(no idea about hyperion's motives to react the way he does) 
that wasn't
a question, just a small factoid that the explanation I wrote 
before might or might not apply to you, as I just don't know what your 
motives are.


patrick mauritz

[KJK::Hyperion]

At 09.02 19/02/2004, you wrote:
> >  >(no idea
> > about hyperion's motives to react the way he does) 
> that wasn't a question,
> just a small factoid that the explanation I wrote 
> before might or might not apply to you, as I just don't know what your 
> motives are. 
my reply stands nevertheless :-)

[KJK::Hyperion]

At 16.30 15/02/2004, you wrote:
>  why are you developing a completely new kernel instead
> of using an 
> existing one like linux or hurd and running reactos just as a subsystem, 
> perhaps with some kernel improvements. 
because we feel like it. Each of us for different reasons

>  For example: linux brings very good memory management
> and filesystem. 
(both of which happen to be completely incompatible with those of Windows. 
You picked bad examples. The whole of Linux is a bad example of how Windows 
can be implemented)

>  So what are the advantages of another own kernel
> against a subsystem in 
> another host operating system ? 
it makes us 63.2% cooler

[Enrico Weigelt]

* KJK::Hyperion <noog(a)libero.it> [2004-02-16 22:46:21 +0100]:

<snip>
>   At 16.30 15/02/2004, you wrote:
> >  why are you developing a completely new kernel
> > instead of using an 
> > existing one like linux or hurd and running reactos just as a subsystem, 
> > perhaps with some kernel improvements. 
>  
>  because we feel like it. Each of us for different reasons 
I'd like to hear what reasons that are.

> >  For example:
> > linux brings very good memory management and filesystem. 
>  
>  (both of which happen to be completely incompatible with those of Windows.  
Where are the (conceptional) differences ? 

example 1: filesystem
windows also brings an API for filesystem access. it uses \ instead
of / as path delimiter, but most of the functions are quite the same.

example 2: memory mangement
on both systems each process has its own memory range (thats just the
concept of the protected mode) and the application may request more
memory from the kernel, and those memory areas are layign on some address.

win16 had the distinction between "local" and "global" memory - IMHO
local 
memory will be freed when a task dies, global one doesnt. 
does winnt also have this ?


<snip>
>   You picked bad examples. The whole of Linux is a bad
> example of how 
>  Windows can be implemented) 
Why bad example ? 
And why implement _Windows_ and not a good system which allows running
old windows applications ?

<snip>
> >  So what are the
> > advantages of another own kernel against a subsystem in 
> > another host operating system ? 
>  
>  it makes us 63.2% cooler  
ah, no rational reason, just for fun.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[KJK::Hyperion]

At 23.17 16/02/2004, you wrote:
> >  because we feel
> > like it. Each of us for different reasons 
> I'd like to hear what reasons that
> are. 
for me it's finally and actually learning Windows. Just giving up and using 
another system? _how convenient_. And it's not like just for wanting to 
develop an open source operating system you *must* contribute to Linux - 
what makes people think that? I hate Linux, why should I care?

>  Where are the (conceptional) differences ? 
you really *don't want* to get in a discussion with *me* about differences 
between Windows and Linux. I'm pretty much doomed to be always right about 
the topic, having spent countless hours of my life studying it. Let's put 
it this way: they are roughly *equivalent*, but in no way *interchangeable*

>  And why implement _Windows_ and not a good system which
> allows running old 
> windows applications ? 
ReactOS *is* meant as "a good system which allows running old windows 
applications"

> > >  So what are the advantages of another own kernel
> > > against a subsystem in 
> > > another host operating system ? 
> > it makes us 63.2% cooler 
> ah, no rational
> reason, just for fun. 
no, I'm just saying it to confuse you

[Vizzini]

On Mon, 2004-02-16 at 17:33, KJK::Hyperion wrote:
> > > >  So what are the
> > > > advantages of another own kernel against a subsystem in 
> > > > another host operating system ? 
> > > it makes us 63.2% cooler 
> > ah, no rational
> > reason, just for fun. 
>  
>  no, I'm just saying it to confuse you  
Hyperion for president.

>   At 23.17 16/02/2004, you wrote:
> > >  because we
> > > feel like it. Each of us for different reasons 
> > I'd like to hear what reasons
> > that are. 
>  
well, my main reason is that i use linux for servers in schools,
but there
is a vast amount of specialist educational software that needs to run on
desktop windows, on fairly low spec machines. what i want is something i
can plug in as a direct, free replacement for windows that looks the same,
works the same, and does not need high spec (expensive) machines to cope
with a bloaty os + subsystem.

don't get me wrong, i love linux/samba, it saves the schools i work for a
fortune in server licences, but it is geting bigger and more demanding in
terms of hardware.

les

[Enrico Weigelt]

* ros(a)xzite.fsnet.co.uk <ros(a)xzite.fsnet.co.uk> [2004-02-17 02:24:07 -0000]:

<snip>
>   well, my main reason is that i use linux for servers
> in schools, but there
>  is a vast amount of specialist educational software that needs to run on
>  desktop windows, on fairly low spec machines.  
Okay, you need a slim operating
system which can run windows applications.
(but a new kernel ?)

>   what i want is something i
>  can plug in as a direct, free replacement for windows that looks the same,
>  works the same, and does not need high spec (expensive) machines to cope
>  with a bloaty os + subsystem. 
Why has underlying OS and a subsystem to be expensive
?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Enrico Weigelt]

* KJK::Hyperion <noog(a)libero.it> [2004-02-17 00:33:47 +0100]:

Hi folks,

>   for me it's finally and actually learning Windows.
> Just giving up and using 
>  another system? _how convenient_. And it's not like just for wanting to 
>  develop an open source operating system you *must* contribute to Linux - 
>  what makes people think that?  
Well, I just thought about GNU/Linux since its one
of the most used 
opensource operating systems. 

I personally migrated to GNU/Linux some years ago, because its architecture
is much better for my tasks than windows - for me windows is too desktop-centric
But I also like to run many windows applications on my system, as long as 
they're not available for GNU/Linux.

>   I hate Linux, why should I care? 
Why exactly do
you hate it ?

<snip>
> >  Where are the
> > (conceptional) differences ? 
>  
>  you really *don't want* to get in a discussion with *me* about differences 
>  between Windows and Linux. I'm pretty much doomed to be always right about 
>  the topic, having spent countless hours of my life studying it. Let's put 
>  it this way: they are roughly *equivalent*, but in no way *interchangeable* 
For me
the differences are important since I'd like to use windows applications
on other platforms like GNU/Linux or BSD.

> >  And why
> > implement _Windows_ and not a good system which allows running old 
> > windows applications ? 
>  
>  ReactOS *is* meant as "a good system which allows running old windows 
>  applications" 
Perhaps it was a misunderstanding. I meant a "good operating system" which
can be used for many tasks, not just running windows applications.
So this would end up in a windows subsystem.

Well, let me ask the question in a diffrent way:

What are the existing kernels/operating systems are missing that you
require a completely new kernel. Writing a good operating system from scratch
is a very huge job - i.e. linux has taken many years to come to the point
where it is.


<snip>
> > > >  So what are the
> > > > advantages of another own kernel against a subsystem in 
> > > > another host operating system ? 
> > > it makes us 63.2% cooler 
> > ah, no rational
> > reason, just for fun. 
>  
>  no, I'm just saying it to confuse you  
*lol*


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

Enrico Weigelt wrote:

> > >  And why implement _Windows_ and not a good system which
> > > allows running old 
> > > windows applications ?
> > >       
> > >  
> > ReactOS *is* meant as "a good system which allows running old windows 
> > applications"
> >     
> >  
> Perhaps it was a misunderstanding. I meant a "good operating system" which
> can be used for many tasks, not just running windows applications.
> So this would end up in a windows subsystem.
>
> Well, let me ask the question in a diffrent way:
>
> What are the existing kernels/operating systems are missing that you
> require a completely new kernel. Writing a good operating system from scratch
> is a very huge job - i.e. linux has taken many years to come to the point
> where it is.
>   
>  
You can also see this in a different way: We are working together with 
the Wine project. This project is already quite old and it's still in 
it's alpha phase, so developments aren't really going hard...
This project has a good potential of becoming a very fast developing 
project since there are a lot of windows developers outthere.
Now the situation is that the ReactOS project hugely consumes of the 
knowledge of the Wine project, but in a year or so the situation could 
have changed in the other way around! Then it is time to finally build a 
_good_ windows subsystem for linux!
 From my point of view the ReactOS project is no more then a step 
between the situation now and having a good Windows subsystem in Linux.
Hope that that cleared something.

Emil

[Enrico Weigelt]

* ROS(a)Q-collective.org <ROS(a)q-collective.org> [2004-02-17 16:54:30 +0100]:

Hi,

>   From my point of view the ReactOS project is no more
> then a step 
>  between the situation now and having a good Windows subsystem in Linux.
>  Hope that that cleared something. 
so we could state, that reactos is a native kernel for a windows-style
environment, while wine is a emulation layer on top of another OS.
Much of the code could be used in both projects, so perhaps someday
we could have three projects:
    + native kernel (reactos)
    + subsystem/emulation (wine)
    + userland applications
    
    
cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Robert Köpferl]

Have you read Windows 2000 inside by David Solomon and Russinovic.
I can recommend it to you.
NT and linux are different.

Enrico Weigelt schrieb:

>   * ROS(a)Q-collective.org <ROS(a)q-collective.org>
> [2004-02-17 16:54:30 +0100]:
>  
>  Hi,
>  
>  
> >  From my point of view the ReactOS project is no
> > more then a step 
> > between the situation now and having a good Windows subsystem in Linux.
> > Hope that that cleared something. 
>  
>  
>  so we could state, that reactos is a native kernel for a windows-style
>  environment, while wine is a emulation layer on top of another OS.
>  Much of the code could be used in both projects, so perhaps someday
>  we could have three projects:
>      + native kernel (reactos)
>      + subsystem/emulation (wine)
>      + userland applications 
In reality the ros-kernel is a kernel for no apps and it is also a 
unofficial project ( kernel to build sub system ontop)
We have the win32 sub system as the win-app server
>        

>        
> cu

[Gunnar André Dalsnes]

>   Much of the code could be used in both projects, so
> perhaps someday
>  we could have three projects:
>      + native kernel (reactos)
>      + subsystem/emulation (wine)
>      + userland applications
>      
>       
Yes, IMO this would be the ideal solution!

The current situation where we port/borrow/fork code from wine is really
bad. Much work is done twice. The ideal solution would be to work with
the Wine project (where possible) instead of forking it into ros.
Keeping shell32 in synch seem to work well thou, but most shared
components are not synched. 

My dream is to move/merge most of ros umode stuff into Wine. This
includes everything inside the ros\lib source tree. Differences between
ros and wine would be put into libraries, create a ntoskrnl.dll and
win32k.dll wrapper for wine etc.

-Gunnar

[Steven Edwards]

--- Gunnar_Andr�_Dalsnes <hardon(a)online.no> wrote:
>   My dream is to move/merge most of ros umode stuff into
> Wine. This
>  includes everything inside the ros\lib source tree. Differences
>  between
>  ros and wine would be put into libraries, create a ntoskrnl.dll and
>  win32k.dll wrapper for wine etc. 
I want to do this sometime soon but Alexandre just things it will be to
much work. I think keeping things in sync is more work than writting
wrappers for Win32k/Ntoskrnl and using winehq release built for Mingw
directly. 

I am planning on getting Mingw binarys setup soon from Winehq for each
new WINE release. Maybe we can look at working more with them and not
forking the code around 0.3 or something. For the time being it is
better to fork and get ReactOS up to the current state WINE is.

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

[Enrico Weigelt]

* Gunnar André Dalsnes <hardon(a)online.no> [2004-02-17 20:32:25 +0100]:

<snip>
>   The current situation where we port/borrow/fork code
> from wine is really
>  bad. Much work is done twice. The ideal solution would be to work with
>  the Wine project (where possible) instead of forking it into ros.
>  Keeping shell32 in synch seem to work well thou, but most shared
>  components are not synched.  
Where are the problems ?
Did you ever talk to them or do you fear being hit in the back ? ;-)

I'll subscribe to the wine list(s) and have a look at the code.
Perhaps you could tell me, which parts are used by both projects.

<snip>
>   My dream is to move/merge most of ros umode stuff into
> Wine. This
>  includes everything inside the ros\lib source tree. Differences between
>  ros and wine would be put into libraries, create a ntoskrnl.dll and
>  win32k.dll wrapper for wine etc. 
Yes, this sounds ideal. There should be a core module (either ros kernel
or wine in userland), which provides generic kernel interfaces, loads
binaries, memory mangement, ... i.e. the ros-kernel could be configured to
support .so-libraries or not (for windows-only environments they're not
needed, but perhaps its useful someday), also the wine core could support
several binary formats. 

On top of this core the should sit several services, like device handling
window manager, widget libraries, ... 
Each interface (from within the win-env seen as one dll) could be provided
by several module - at least one pure-win32 implementation (i.e. widgets)
and others which work as adapters to other stuff, especially in the 
wine-environment (i.e uses gtk for widget rendering).

An interesting setup where both projects share much stuff would be a 
console-wine: it could use a simple framebuffer or libsvga output device
and widget rendering/window manager from the shared codebase.
(whether the code comes from windows-dlls or .so's doesnt really matter
at this point).

This would be "windows on console" - something very interesting for me.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     [phone]         www:       http://www.metux.de/
  fax:       [phone]         email:     contact(a)metux.de
  cellphone: [phone]
---------------------------------------------------------------------
 DSL-Zugang ab 0 Euro. -- statische IP -- DSL-Flatfrate            --
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
---------------------------------------------------------------------

[Richard Campbell]

Want your reasons?  go ask linus why he wrote linux.

Enrico Weigelt wrote:

>  * KJK::Hyperion <noog(a)libero.it> [2004-02-16
> 22:46:21 +0100]:
>
> <snip>
>   
>
> >  At 16.30 15/02/2004, you wrote:
> >     
> >
> > >  why are you developing a completely new kernel
> > > instead of using an 
> > > existing one like linux or hurd and running reactos just as a subsystem, 
> > > perhaps with some kernel improvements.
> > >       
> > >  
> > because we feel like it. Each of us for different reasons
> >     
> >  
> I'd like to hear what reasons that are.
>
>   
>
> > >  For
> > > example: linux brings very good memory management and filesystem.
> > >       
> > >  
> > (both of which happen to be completely incompatible with those of Windows. 
> >     
> >  
> Where are the (conceptional) differences ? 
>
> example 1: filesystem
> windows also brings an API for filesystem access. it uses \ instead
> of / as path delimiter, but most of the functions are quite the same.
>
> example 2: memory mangement
> on both systems each process has its own memory range (thats just the
> concept of the protected mode) and the application may request more
> memory from the kernel, and those memory areas are layign on some address.
>
> win16 had the distinction between "local" and "global" memory - IMHO
> local 
> memory will be freed when a task dies, global one doesnt. 
> does winnt also have this ?
>
>
> <snip>
>   
>
> >  You picked bad examples. The whole of Linux is a
> > bad example of how 
> > Windows can be implemented)
> >     
> >  
> Why bad example ? 
> And why implement _Windows_ and not a good system which allows running
> old windows applications ?
>
> <snip>
>   
>
> > >  So what
> > > are the advantages of another own kernel against a subsystem in 
> > > another host operating system ?
> > >       
> > >  
> > it makes us 63.2% cooler 
> >     
> >  
> ah, no rational reason, just for fun.
>
>
> cu
>   
>