Re: [ros-dev] [ros-diffs] [sedwards] 40919: imported the MT snapshot of the GPL tftp-server for win32 from sourceforge. Minor changes such as formatting and renaming the files, totally untested except for building, will be used later to serve up Reac

[Steven Edwards]

On Thu, May 14, 2009 at 2:52 PM, KJK::Hyperion <hackbunny(a)reactos.org> wrote:
>   Ged wrote:
> >   Another unix like addition?
> >  Do we really need this and the previous telnet server in our source? 
>  to be fair, Windows does provide a command line TFTP client/server. So
>  far, I've only seen it used for malware spreading, but it's there and we
>  should provide one too 
Where I work we use dhcpd/tftp and PXEboot on both Linux and Windows
to do automagical deployment services. The end goal with all of this
is a ReactOS deployment system from a single image that can provision
ReactOS thinkclients/diskless workstations without the need of a Linux
or Windows host.

Pushing out a freeldr or grub+freeldr or even pxelinux+grub+freeldr
image with a blob containing a ROS ramdisk should be pretty simple
using isc-dhcpd/tftp on Linux but I'm more interested in the
infrastructure side of things right now. Currently the dhcpd with PXE
support is the only part we are really missing. We COULD do it from
Linux or Windows right now, but I want to get all the infrastructure
in place where we don't need any other OS.

Thanks
-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Timo Kreuzer]

Do we really need this in trunk? Sure, we can say "hey windows has
it...", but shouldn't we actually keep stuff in trunk that is necessary
for a basic core system? I'd rather import Samba TNG into trunk, as it's
very much more what normal users would expect from a Windows like OS
than some ftp or telnet server. I would rather import the VBox drivers
into trunk, but I don't even think of importing it into rosapps. I'd
rather import MPC. Please! Let's focus on stuff that is important for
the core instead of adding more and more 3rd party stuff. The people
that download and use reactos are either people that give a shit about
ftp servers or people that are experienced enough to install them
theirselves. IMO it shouldn't even be in rosapps, but if it was there I
could live with it, trunk: bad idea.
We are not Unix/Linux! You want server stuff? Great! Let's make the
XAMPP work properly and get good uptimes. Anything else is wasted space
and time.

Regards,
Timo

Steven Edwards schrieb:
>   On Thu, May 14, 2009 at 2:52 PM, KJK::Hyperion
> <hackbunny(a)reactos.org> wrote:
>    
> >   Ged wrote:
> >      
> > >   Another unix like addition?
> > >  Do we really need this and the previous telnet server in our source?
> > >         
> >  to be fair, Windows does provide a command line TFTP client/server. So
> >  far, I've only seen it used for malware spreading, but it's there and we
> >  should provide one too
> >       
>  Where I work we use dhcpd/tftp and PXEboot on both Linux and Windows
>  to do automagical deployment services. The end goal with all of this
>  is a ReactOS deployment system from a single image that can provision
>  ReactOS thinkclients/diskless workstations without the need of a Linux
>  or Windows host.
>
>  Pushing out a freeldr or grub+freeldr or even pxelinux+grub+freeldr
>  image with a blob containing a ROS ramdisk should be pretty simple
>  using isc-dhcpd/tftp on Linux but I'm more interested in the
>  infrastructure side of things right now. Currently the dhcpd with PXE
>  support is the only part we are really missing. We COULD do it from
>  Linux or Windows right now, but I want to get all the infrastructure
>  in place where we don't need any other OS.
>
>  Thanks
>

[Steven Edwards]

2009/5/14 Timo Kreuzer <timo.kreuzer(a)web.de>de>:
>   Do we really need this in trunk? Sure, we can say
> "hey windows has it...",
>  but shouldn't we actually keep stuff in trunk that is necessary for a basic
>  core system? I'd rather import Samba TNG into trunk, as it's very much more
>  what normal users would expect from a Windows like OS than some ftp or
>  telnet server. I would rather import the VBox drivers into trunk, but I
>  don't even think of importing it into rosapps. I'd rather import MPC.
>  Please! Let's focus on stuff that is important for the core instead of
>  adding more and more 3rd party stuff. The people that download and use
>  reactos are either people that give a shit about ftp servers or people that
>  are experienced enough to install them theirselves. IMO it shouldn't even be
>  in rosapps, but if it was there I could live with it, trunk: bad idea.
>  We are not Unix/Linux! You want server stuff? Great! Let's make the XAMPP
>  work properly and get good uptimes. Anything else is wasted space and time. 
I don't mind moving the stuff out to rosapps but I thought we were
going to adopt a targeted makefile system rather than a multi-tree
system.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Aleksey Bragin]

>   I don't mind moving the stuff out to rosapps but I
> thought we were
>  going to adopt a targeted makefile system rather than a multi-tree
>  system. 
That was the solution many seemed to agree to, just a couple of  
months ago in this same mailing list. Let's keep it and not start yet  
another "let's move that from trunk to rosapps, and bring something  
else from rosapps to trunk" move wars.

Consistency means consistency.


WBR,
Aleksey Bragin.

[Peter Millerchip]

Hi,

I've been lurking on this list for several years, but I have some
thoughts about this issue so I hope you don't mind me posting now.

It seems to me as though discussions like this are more of a
"distro-level" thing - if you consider how Linux does things, the
kernel is a separate project from the userland, and it's up to the
distros (like Ubuntu, Fedora, etc.) to decide whether to ship a tftp
server.

Now, I must admit I'm not an expert on the internals of ReactOS at
all, so please forgive me if this idea is not technically feasible,
but couldn't we make a similar kind of separation in ReactOS? As far
as I can see, there's no technical reason why even something like
USER32.DLL couldn't be a completely separate project from the ReactOS
kernel, using maybe a different branch of the source code and testing
on Windows XP. After all, the GNU tools were written in this way,
gradually replacing core components of various Unixes.

So, if we follow the same kind of development model as Linux, the
ReactOS kernel would be the sole ReactOS project. Then you would have
different maintainers for different parts, say USER32.DLL. Then you
would have someone who compiles "distros" of ReactOS, picking and
choosing the best pieces to go with the kernel itself. You could have
a "netboot-specialised" distro which included the tftp and PXE stuff,
or a more general "newbie" distro.

I would expect that many of the subprojects would share code in order
to make things a bit easier - but the important thing to realise is
that they wouldn't be forced to. Say if the USER32 maintainer decided
to do a Wine sync, but the kernel guys didn't want to, this would
actually be OK and would still work fine. The USER32 maintainer could,
if they wanted, have a completely separate source tree from the
ReactOS kernel. As long as the USER32 DLL worked on Windows XP, it
would be good - if the ReactOS kernel didn't work with it, it would be
a bug in the kernel.

So, is this idea feasible or is there some reason why it wouldn't
work? Please feel free to call me an idiot if I've missed some
important technical detail, but it seems to me that introducing this
kind of separation would really help the project to move forward very
quickly in the same way that Linux has.

Best regards,

Peter Millerchip.


2009/5/15 Aleksey Bragin <aleksey(a)reactos.org>rg>:
> >   I don't
> > mind moving the stuff out to rosapps but I thought we were
> >  going to adopt a targeted makefile system rather than a multi-tree
> >  system. 
>  That was the solution many seemed to agree to, just a couple of
>  months ago in this same mailing list. Let's keep it and not start yet
>  another "let's move that from trunk to rosapps, and bring something
>  else from rosapps to trunk" move wars.
>
>  Consistency means consistency.
>
>
>  WBR,
>  Aleksey Bragin.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

Hi!

On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip
<peter.millerchip(a)gmail.com> wrote:
>   Hi,
>
>  I've been lurking on this list for several years, but I have some
>  thoughts about this issue so I hope you don't mind me posting now.
>  
Cool!

Well, in short~ User32.dll~

We have managed to get most of Gdi32.dll to work with XP and it is
only halfway done, I haven't finished it yet. Now User32, it is hard
to say, Win32 and User32 use interchangeable shared structures such as
SERVERINFO and friends, not included, the ATOM callbacks. I had to sit
and think about it for a while and I've concluded it would take years
to work out and that was to long. So we are going to live with this
fact that it will only work with ReactOS. I have also considered using
known information about User32 structures, it is for the purpose of
education and to give ideas how things do work in the Win/User
interface.

We can have theming and things like that in different branches after
the smoke clears. I'm open to any ideas that would create a pleasant
UI.

Thanks,
James

[Javier Agustìn Fernàndez Arroyo]

"So we are going to live with this
fact that it will only work with ReactOS"

sad news

On Fri, May 15, 2009 at 2:59 PM, James Tabor <jimtabor.rosdev(a)gmail.com>wrote;wrote:

>   Hi!
>
>  On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip
>  <peter.millerchip(a)gmail.com> wrote:
> >   Hi,
> >
> >  I've been lurking on this list for several years, but I have some
> >  thoughts about this issue so I hope you don't mind me posting now.
> >  
>  Cool!
>
>  Well, in short~ User32.dll~
>
>  We have managed to get most of Gdi32.dll to work with XP and it is
>  only halfway done, I haven't finished it yet. Now User32, it is hard
>  to say, Win32 and User32 use interchangeable shared structures such as
>  SERVERINFO and friends, not included, the ATOM callbacks. I had to sit
>  and think about it for a while and I've concluded it would take years
>  to work out and that was to long. So we are going to live with this
>  fact that it will only work with ReactOS. I have also considered using
>  known information about User32 structures, it is for the purpose of
>  education and to give ideas how things do work in the Win/User
>  interface.
>
>  We can have theming and things like that in different branches after
>  the smoke clears. I'm open to any ideas that would create a pleasant
>  UI.
>
>  Thanks,
>  James
>   _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

Hi!

2009/5/15 Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>om>:
>   "So we are going to live with this
>  fact that it will only work with ReactOS"
>
>  sad news
>  
No not sad.... It is a testament of the hard work done by Thomas and
other developers, getting it to work with wine and working out the
issues of point to point API cross tests. This is not an easy task to
go into! The little information we have is not going to help in the
short term of getting user32 into a state of plug and run for XP or
any version of Windows. We just don't have the resources and time to
do the job right. I must add, the tools I had access to just is not
enough. We need to compromise and live with this fact. Over all we can
meet to an API level of compatibility and that is it. Walking away
with some understanding how this interface works at the end of the
day.

Thanks,
James

[Alexandru Lovin]

Would it be possible to do it after ReactOS already relaces Windows, it's
stable, smaller memory footprint, etc. ? I mean, by then everyone will be so
excited about it, everybody would have already heard of it (definitely) and
they would already be keen to help or something. At which point the devs
pull out a list of things that should be done right: a,b,c, d, etc.
James Tabor: I need to warn you that this will take years to do right. We
already learned to live with the feeling of knowing this only works on ROS.

I'm thinking ROS will have fanboys who will come hungry to help someone so
that they're noticed.

Mr. Tabor, your thoughts ?

On Fri, May 15, 2009 at 5:01 PM, James Tabor <jimtabor.rosdev(a)gmail.com>wrote;wrote:

>   Hi!
>
>  2009/5/15 Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>om>:
> >   "So we are going to live with this
> >  fact that it will only work with ReactOS"
> >
> >  sad news
> >  
>  No not sad.... It is a testament of the hard work done by Thomas and
>  other developers, getting it to work with wine and working out the
>  issues of point to point API cross tests. This is not an easy task to
>  go into! The little information we have is not going to help in the
>  short term of getting user32 into a state of plug and run for XP or
>  any version of Windows. We just don't have the resources and time to
>  do the job right. I must add, the tools I had access to just is not
>  enough. We need to compromise and live with this fact. Over all we can
>  meet to an API level of compatibility and that is it. Walking away
>  with some understanding how this interface works at the end of the
>  day.
>
>  Thanks,
>  James
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  


-- 
Alex Lovin - www.erasereality.3x.ro

[Zachary Gorden]

Not going to call you an idiot, but the methodology you propose would not be
appropriate for this project.  The objective is to create an entire
operating system and provide something that is usable for the end user, not
create a giant mess of parts that may or may not integrate well into each
other.  The work that a lot of distros do is quite frankly massively
overredundant, caused by all the projects pretty much doing whatever they
want.  And splitting into a bunch of "mini" projects doesn't solve the
fundamental issue of lack of manpower.  It just disperses what we do have
even more.

On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip <
peter.millerchip(a)gmail.com&gt; wrote:

>   Hi,
>
>  I've been lurking on this list for several years, but I have some
>  thoughts about this issue so I hope you don't mind me posting now.
>
>  It seems to me as though discussions like this are more of a
>  "distro-level" thing - if you consider how Linux does things, the
>  kernel is a separate project from the userland, and it's up to the
>  distros (like Ubuntu, Fedora, etc.) to decide whether to ship a tftp
>  server.
>
>  Now, I must admit I'm not an expert on the internals of ReactOS at
>  all, so please forgive me if this idea is not technically feasible,
>  but couldn't we make a similar kind of separation in ReactOS? As far
>  as I can see, there's no technical reason why even something like
>  USER32.DLL couldn't be a completely separate project from the ReactOS
>  kernel, using maybe a different branch of the source code and testing
>  on Windows XP. After all, the GNU tools were written in this way,
>  gradually replacing core components of various Unixes.
>
>  So, if we follow the same kind of development model as Linux, the
>  ReactOS kernel would be the sole ReactOS project. Then you would have
>  different maintainers for different parts, say USER32.DLL. Then you
>  would have someone who compiles "distros" of ReactOS, picking and
>  choosing the best pieces to go with the kernel itself. You could have
>  a "netboot-specialised" distro which included the tftp and PXE stuff,
>  or a more general "newbie" distro.
>
>  I would expect that many of the subprojects would share code in order
>  to make things a bit easier - but the important thing to realise is
>  that they wouldn't be forced to. Say if the USER32 maintainer decided
>  to do a Wine sync, but the kernel guys didn't want to, this would
>  actually be OK and would still work fine. The USER32 maintainer could,
>  if they wanted, have a completely separate source tree from the
>  ReactOS kernel. As long as the USER32 DLL worked on Windows XP, it
>  would be good - if the ReactOS kernel didn't work with it, it would be
>  a bug in the kernel.
>
>  So, is this idea feasible or is there some reason why it wouldn't
>  work? Please feel free to call me an idiot if I've missed some
>  important technical detail, but it seems to me that introducing this
>  kind of separation would really help the project to move forward very
>  quickly in the same way that Linux has.
>
>  Best regards,
>
>  Peter Millerchip.
>

[Imre Leber]

Well that is exactly the reason why linux is broken. Completely useless unless you pay
someone to make a distro.

Please make that kind of crap a thing of the past!

Imre



  On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip <peter.millerchip(a)gmail.com>
wrote:

    Hi,

    I've been lurking on this list for several years, but I have some
    thoughts about this issue so I hope you don't mind me posting now.

    It seems to me as though discussions like this are more of a
    "distro-level" thing - if you consider how Linux does things, the
    kernel is a separate project from the userland, and it's up to the
    distros (like Ubuntu, Fedora, etc.) to decide whether to ship a tftp
    server.

    Now, I must admit I'm not an expert on the internals of ReactOS at
    all, so please forgive me if this idea is not technically feasible,
    but couldn't we make a similar kind of separation in ReactOS? As far
    as I can see, there's no technical reason why even something like
    USER32.DLL couldn't be a completely separate project from the ReactOS
    kernel, using maybe a different branch of the source code and testing
    on Windows XP. After all, the GNU tools were written in this way,
    gradually replacing core components of various Unixes.

    So, if we follow the same kind of development model as Linux, the
    ReactOS kernel would be the sole ReactOS project. Then you would have
    different maintainers for different parts, say USER32.DLL. Then you
    would have someone who compiles "distros" of ReactOS, picking and
    choosing the best pieces to go with the kernel itself. You could have
    a "netboot-specialised" distro which included the tftp and PXE stuff,
    or a more general "newbie" distro.

    I would expect that many of the subprojects would share code in order
    to make things a bit easier - but the important thing to realise is
    that they wouldn't be forced to. Say if the USER32 maintainer decided
    to do a Wine sync, but the kernel guys didn't want to, this would
    actually be OK and would still work fine. The USER32 maintainer could,
    if they wanted, have a completely separate source tree from the
    ReactOS kernel. As long as the USER32 DLL worked on Windows XP, it
    would be good - if the ReactOS kernel didn't work with it, it would be
    a bug in the kernel.

    So, is this idea feasible or is there some reason why it wouldn't
    work? Please feel free to call me an idiot if I've missed some
    important technical detail, but it seems to me that introducing this
    kind of separation would really help the project to move forward very
    quickly in the same way that Linux has.

    Best regards,

    Peter Millerchip.



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Millerchip]

Oh I completely agree that the end objective of making a nice complete
OS for the end user is a very useful goal to have in mind. My point is
that I see that as matching up to the goals of a distro, say Ubuntu
for example. Something like a tftp server would, in Ubuntu's case,
simply be a package that you could download through the package
manager. Why not simply add the tftp server to ReactOS's downloader as
an optional package? That would seem to be the best place to put it,
as it is very obviously a completely optional userland tool.

Zachary's poin about the manpower issue is very important, though, and
I feel I should add my 2 cents to the discussion here. One of the
fundamental ways in which large projects can be made to work well with
more developers is for the project to split into smaller
"sub-projects" with well-defined interfaces between them and reduced
dependancies. This works no matter what kind of software project we're
referring to - for example, you have IRC clients as standalone
projects, and IRC servers as different projects, even though they are
each both completely useless without the other. Developers can work on
an IRC client and get to know it really well, without having to know
the faintest thing about how an IRC server handles multiple
connections and so forth.

Splitting things across well-defined boundaries makes it easier for
programmers to help out, not harder! Using our IRC example, a
programmer could delve deep into the code of their favourite IRC
client and not have to learn anything about the server. It means a
smaller amount of stuff to learn before a programmer becomes useful,
and this attracts developers to a project.

>  From people's answers beforehand in the thread. it
> seems that there 
may currently be technical reasons why a USER32 replacement
can't
currently be done (i.e. internal undocumented interfaces). I guess I
need to ask the experts out there - are there DLLs or components in
ReactOS that can be completely separated out? What parts could be run
on windows currently? What parts don't currently run, but could in
theory?

The other point to make about distros, is that nothing in the ReactOS
license prevents someone from starting a ReactOS distro. This means
that it is virtually guaranteed to happen as ReactOS matures, and we
need to be ready for it. For example, say if Debian wanted to do a
Debian/ROS distribution, like they do Debian/Hurd or Debian/FreeBSD at
the moment. Debian could take the ROS kernel and some other userland
bits and pieces. They might compile up some DLLs from Wine instead of
from ROS, if Wine has newer bugfixes. It would be technically possible
to port the "apt" package manager to ROS and offer packages for common
open source tools like OpenOffice, the GIMP, Firefox and so on.
There's nothing technically or legally that ROS can do to stop it, so
instead we should work out how we as a project are going to cope with
it WHEN (yes, when) it happens.

Would we be OK with that? How will we cope when a distro is shipping
our kernel, but with Wine's DLLs? Do we need to do anything
differently than how we do now? Do we need to make our build process
easier for distro packagers?

Best regards,

Peter Millerchip.


2009/5/15 Zachary Gorden <drakekaizer666(a)gmail.com>om>:
>   Not going to call you an idiot, but the methodology
> you propose would not be
>  appropriate for this project.  The objective is to create an entire
>  operating system and provide something that is usable for the end user, not
>  create a giant mess of parts that may or may not integrate well into each
>  other.  The work that a lot of distros do is quite frankly massively
>  overredundant, caused by all the projects pretty much doing whatever they
>  want.  And splitting into a bunch of "mini" projects doesn't solve the
>  fundamental issue of lack of manpower.  It just disperses what we do have
>  even more.
>
>  On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip
>  <peter.millerchip(a)gmail.com> wrote:
> >  
> >  Hi,
> >
> >  I've been lurking on this list for several years, but I have some
> >  thoughts about this issue so I hope you don't mind me posting now.
> >
> >  It seems to me as though discussions like this are more of a
> >  "distro-level" thing - if you consider how Linux does things, the
> >  kernel is a separate project from the userland, and it's up to the
> >  distros (like Ubuntu, Fedora, etc.) to decide whether to ship a tftp
> >  server.
> >
> >  Now, I must admit I'm not an expert on the internals of ReactOS at
> >  all, so please forgive me if this idea is not technically feasible,
> >  but couldn't we make a similar kind of separation in ReactOS? As far
> >  as I can see, there's no technical reason why even something like
> >  USER32.DLL couldn't be a completely separate project from the ReactOS
> >  kernel, using maybe a different branch of the source code and testing
> >  on Windows XP. After all, the GNU tools were written in this way,
> >  gradually replacing core components of various Unixes.
> >
> >  So, if we follow the same kind of development model as Linux, the
> >  ReactOS kernel would be the sole ReactOS project. Then you would have
> >  different maintainers for different parts, say USER32.DLL. Then you
> >  would have someone who compiles "distros" of ReactOS, picking and
> >  choosing the best pieces to go with the kernel itself. You could have
> >  a "netboot-specialised" distro which included the tftp and PXE stuff,
> >  or a more general "newbie" distro.
> >
> >  I would expect that many of the subprojects would share code in order
> >  to make things a bit easier - but the important thing to realise is
> >  that they wouldn't be forced to. Say if the USER32 maintainer decided
> >  to do a Wine sync, but the kernel guys didn't want to, this would
> >  actually be OK and would still work fine. The USER32 maintainer could,
> >  if they wanted, have a completely separate source tree from the
> >  ReactOS kernel. As long as the USER32 DLL worked on Windows XP, it
> >  would be good - if the ReactOS kernel didn't work with it, it would be
> >  a bug in the kernel.
> >
> >  So, is this idea feasible or is there some reason why it wouldn't
> >  work? Please feel free to call me an idiot if I've missed some
> >  important technical detail, but it seems to me that introducing this
> >  kind of separation would really help the project to move forward very
> >  quickly in the same way that Linux has.
> >
> >  Best regards,
> >
> >  Peter Millerchip. 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Zachary Gorden]

The analogy between comparing a Linux distro and ROS doesn't work, since the
components within ROS are interdependent pretty much by design.  One isn't
supposed to be developing them independently of each other.  The only major
component that can get away with it, specifically some of the user mode DLLs
for win32, are already being done by Wine, not us.  All those DLLs come from
Wine and we only occasionally modify them to fix a bug or an
incompatibility.

I'm getting the impression that people are confused as to what exactly the
ROS team develops.  The team works on essentially the kernel mode side of
things, which includes the kernel side of the Win32 subsystem, and the NT
kernel itself, along with the basic drivers one needs to get going.  On the
user mode side, we also need to do all the stuff that acts as the interface
between kernel and user mode.  This can't be split as some kind of third
party effort, as it's tied in too directly to the kernel design.  Would be
pretty much pointless since no one else would have a use for it and we would
need to guarantee compatibility between the two anyway.

The majority of user mode applications are all third party.  Paint and Calc
were done by people that frequent the ROS forum while the rest I'm pretty
sure are from Wine.  A lot of the user mode DLLs are also from Wine, as I
mentioned above, and Wine is doing their own stuff development wise.

The only thing that I can think of which could legitimately be split off
would be the explorer shell, but it literally is of no use to anyone except
us, since it's essentially duplicating the old Windows 2000 style.  It's not
radical or experimental or whatever, it is just a clone of the interface.

Quite frankly, there really aren't many ways to actually split ROS.  The
major components all are tied to each other and the smaller/other stuff
either are already completely third party or were done because no one else
out there was interested in it but we needed it.

[Timo Kreuzer]

Zachary Gorden wrote:
>   The analogy between comparing a Linux distro and ROS
> doesn't work, since the
>  components within ROS are interdependent pretty much by design.  One isn't
>  supposed to be developing them independently of each other.  
Uhhm... where did you
get that from? Heard of MinWin? MS has finally
addressed the issue of a huge interdependency mess and get a cleaner
layered design. Now you want to totally ignore it and repeat old
mistakes or make it even worse?

>    The only major
>  component that can get away with it, specifically some of the user mode DLLs
>  for win32, are already being done by Wine, not us.  All those DLLs come from
>  Wine and we only occasionally modify them to fix a bug or an
>  incompatibility.
>     
Probably all other dlls that we forked or always developed on our own
(except ntdll, gdi32, user32, kernel32) could be developed against Windows.
And what about drivers, services, cpls, shell extensions, explorer, cmd,
user mode apps,  ...

>   I'm getting the impression that people are
> confused as to what exactly the
>  ROS team develops.  The team works on essentially the kernel mode side of
>  things, which includes the kernel side of the Win32 subsystem, and the NT
>  kernel itself, along with the basic drivers one needs to get going.  On the
>     
Maybe that's the reason for discussing about things like an ftp server,
which is surely not a kernel or core component. ;-)
In earlier times I remember a kind of "if you need it, you can download
and install it" philosophy, but not anymore it seems.
Talking about "consistency": There's tons of stuff that Windows has,
where we could import 3rd party code. Where do we draw the line?
Drivers? Media stuff? Web browser? More server stuff? If we really
decide to put everything that windows has into the main folder we really
need a new build system or we will soon end up with unbearable
compilation times.
Talking about build system changes. We don't have them. Is anyone even
working on them? It is something that might be there in the future, but
not now. And will it help me updating selected components from svn? Will
it help builtbot to rebuild only that part of the code that the last
commit affected? I guess not.

>   user mode side, we also need to do all the stuff that
> acts as the interface
>  between kernel and user mode.  This can't be split as some kind of third
>  party effort, as it's tied in too directly to the kernel design. 
No it
isn't. NT doesn't need win32 and win32 can live without all those
fancy highlevel dlls. Network, sound DirectX, all of them optional.

>     Would be
>  pretty much pointless since no one else would have a use for it and we would
>  need to guarantee compatibility between the two anyway.
>     
Yes, that's what we need anyway. That's why we can split stuff. But the
discussion didn't start with the shell, but with an ftp server.

>   The majority of user mode applications are all third
> party.  Paint and Calc
>  were done by people that frequent the ROS forum while the rest I'm pretty
>  sure are from Wine.  A lot of the user mode DLLs are also from Wine, as I
>  mentioned above, and Wine is doing their own stuff development wise.
>
>  The only thing that I can think of which could legitimately be split off
>  would be the explorer shell, but it literally is of no use to anyone except
>  us, since it's essentially duplicating the old Windows 2000 style.  It's not
>  radical or experimental or whatever, it is just a clone of the interface.
>
>  Quite frankly, there really aren't many ways to actually split ROS.  The
>  major components all are tied to each other and the smaller/other stuff
>  either are already completely third party or were done because no one else
>  out there was interested in it but we needed it.   
It's not about whether
it's 3rd party, it's about if and where we put it
in our sources.
As an example: If I work on some stuff in win32k, I would like to
totally ignore all changes to the kernel or to wine dlls or to the
networking stuff. Because it doesn't affect my work. So I can do as
developers often seem to do: not update my local copy for weeks. That
works as long as you are the only dev working on a certain component.
But then another dev commits to that component or a related part. Say
someone changes a bunch of stuff in user32. I can't ignore that any
longer. I need to get my local copy in sync. And with this I am forced
to sync the whole of trunk. Including dozens of wine syncs, rbuild
changes, header changes, kernel changes, network changes, ftpservers....
forcing a full rebuild. Always. What for?
Every component added to trunk/reactos is one component more that gets
changed or synced and forces me to rebuild things, wasting my and every
other developers and the buildslaves time. That is why I'd like to keep
it small. I'd love to see a "MinRos" folder that includes only the core
and an independend win32core folder and a wine folder and a network
folder and an apps folder. I am not talking about splitting the project,
only about source reorganisation to reflect the actual
layers/dependencies instead of putting all modules that happen to have
the same file format into the same folder no matter what they are used for.

BTW: guess what I am currently doing. Compiling, because I wanted to
apply a small patch to win32k and a few changes to win32k/user32 forced
me to update and rebuild everything.

Regards,
Timo

PS: ReactOS is c0re! ;)

[Aleksey Bragin]

>   Probably all other dlls that we forked or always
> developed on our own
>  (except ntdll, gdi32, user32, kernel32) could be developed against  
>  Windows.
>  And what about drivers, services, cpls, shell extensions, explorer,  
>  cmd,
>  user mode apps,  ... 
That was the biggest mistake of ReactOS project from the beginning!  
Instead of developing against Windows, people developed against  
[broken] ReactOS. Wasted time.

WBR,
Aleksey Bragin.

[KJK::Hyperion]

Timo Kreuzer wrote:
>   BTW: guess what I am currently doing. Compiling,
> because I wanted to
>  apply a small patch to win32k and a few changes to win32k/user32 forced
>  me to update and rebuild everything. 
try setting ROS_RBUILDFLAGS to "-df" and see if incremental build times
improve. Someone IS working on the build system

[Imre Leber]

I think you mean it well, but say it wrong. I think what you mean is a team 
system like they have in haiku.

Imre

----- Original Message ----- 
From: "Peter Millerchip" <peter.millerchip(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: Friday, May 15, 2009 11:25 PM
Subject: Re: [ros-dev] [ros-diffs] [sedwards] 40919: imported the MTsnapshot 
of the GPL tftp-server for win32 from sourceforge.Minor changes such as 
formatting and renaming the files,totally untested except for building,will 
be used later to serve up Reac


Oh I completely agree that the end objective of making a nice complete
OS for the end user is a very useful goal to have in mind. My point is
that I see that as matching up to the goals of a distro, say Ubuntu
for example. Something like a tftp server would, in Ubuntu's case,
simply be a package that you could download through the package
manager. Why not simply add the tftp server to ReactOS's downloader as
an optional package? That would seem to be the best place to put it,
as it is very obviously a completely optional userland tool.

Zachary's poin about the manpower issue is very important, though, and
I feel I should add my 2 cents to the discussion here. One of the
fundamental ways in which large projects can be made to work well with
more developers is for the project to split into smaller
"sub-projects" with well-defined interfaces between them and reduced
dependancies. This works no matter what kind of software project we're
referring to - for example, you have IRC clients as standalone
projects, and IRC servers as different projects, even though they are
each both completely useless without the other. Developers can work on
an IRC client and get to know it really well, without having to know
the faintest thing about how an IRC server handles multiple
connections and so forth.

Splitting things across well-defined boundaries makes it easier for
programmers to help out, not harder! Using our IRC example, a
programmer could delve deep into the code of their favourite IRC
client and not have to learn anything about the server. It means a
smaller amount of stuff to learn before a programmer becomes useful,
and this attracts developers to a project.

>  From people's answers beforehand in the thread. it
> seems that there 
may currently be technical reasons why a USER32 replacement
can't
currently be done (i.e. internal undocumented interfaces). I guess I
need to ask the experts out there - are there DLLs or components in
ReactOS that can be completely separated out? What parts could be run
on windows currently? What parts don't currently run, but could in
theory?

The other point to make about distros, is that nothing in the ReactOS
license prevents someone from starting a ReactOS distro. This means
that it is virtually guaranteed to happen as ReactOS matures, and we
need to be ready for it. For example, say if Debian wanted to do a
Debian/ROS distribution, like they do Debian/Hurd or Debian/FreeBSD at
the moment. Debian could take the ROS kernel and some other userland
bits and pieces. They might compile up some DLLs from Wine instead of
from ROS, if Wine has newer bugfixes. It would be technically possible
to port the "apt" package manager to ROS and offer packages for common
open source tools like OpenOffice, the GIMP, Firefox and so on.
There's nothing technically or legally that ROS can do to stop it, so
instead we should work out how we as a project are going to cope with
it WHEN (yes, when) it happens.

Would we be OK with that? How will we cope when a distro is shipping
our kernel, but with Wine's DLLs? Do we need to do anything
differently than how we do now? Do we need to make our build process
easier for distro packagers?

Best regards,

Peter Millerchip.


2009/5/15 Zachary Gorden <drakekaizer666(a)gmail.com>om>:
>   Not going to call you an idiot, but the methodology
> you propose would not 
>  be
>  appropriate for this project. The objective is to create an entire
>  operating system and provide something that is usable for the end user, 
>  not
>  create a giant mess of parts that may or may not integrate well into each
>  other. The work that a lot of distros do is quite frankly massively
>  overredundant, caused by all the projects pretty much doing whatever they
>  want. And splitting into a bunch of "mini" projects doesn't solve the
>  fundamental issue of lack of manpower. It just disperses what we do have
>  even more.
>
>  On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip
>  <peter.millerchip(a)gmail.com> wrote:
> >  
> >  Hi,
> >
> >  I've been lurking on this list for several years, but I have some
> >  thoughts about this issue so I hope you don't mind me posting now.
> >
> >  It seems to me as though discussions like this are more of a
> >  "distro-level" thing - if you consider how Linux does things, the
> >  kernel is a separate project from the userland, and it's up to the
> >  distros (like Ubuntu, Fedora, etc.) to decide whether to ship a tftp
> >  server.
> >
> >  Now, I must admit I'm not an expert on the internals of ReactOS at
> >  all, so please forgive me if this idea is not technically feasible,
> >  but couldn't we make a similar kind of separation in ReactOS? As far
> >  as I can see, there's no technical reason why even something like
> >  USER32.DLL couldn't be a completely separate project from the ReactOS
> >  kernel, using maybe a different branch of the source code and testing
> >  on Windows XP. After all, the GNU tools were written in this way,
> >  gradually replacing core components of various Unixes.
> >
> >  So, if we follow the same kind of development model as Linux, the
> >  ReactOS kernel would be the sole ReactOS project. Then you would have
> >  different maintainers for different parts, say USER32.DLL. Then you
> >  would have someone who compiles "distros" of ReactOS, picking and
> >  choosing the best pieces to go with the kernel itself. You could have
> >  a "netboot-specialised" distro which included the tftp and PXE stuff,
> >  or a more general "newbie" distro.
> >
> >  I would expect that many of the subprojects would share code in order
> >  to make things a bit easier - but the important thing to realise is
> >  that they wouldn't be forced to. Say if the USER32 maintainer decided
> >  to do a Wine sync, but the kernel guys didn't want to, this would
> >  actually be OK and would still work fine. The USER32 maintainer could,
> >  if they wanted, have a completely separate source tree from the
> >  ReactOS kernel. As long as the USER32 DLL worked on Windows XP, it
> >  would be good - if the ReactOS kernel didn't work with it, it would be
> >  a bug in the kernel.
> >
> >  So, is this idea feasible or is there some reason why it wouldn't
> >  work? Please feel free to call me an idiot if I've missed some
> >  important technical detail, but it seems to me that introducing this
> >  kind of separation would really help the project to move forward very
> >  quickly in the same way that Linux has.
> >
> >  Best regards,
> >
> >  Peter Millerchip. 
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev