New Setup system

[David Hinz]

Hey guys,

at first I was shocked, when I read that you want to audit all code and 
will have to rewrite a lot of the old code, but then I realised, that 
this is a great chance for making improvements.

Here's one of my ideas:

We could create a completely new setup, that will have a gui (not really 
a new idea...).
But the second thing would be to create something similar to debians apt 
and debconf.
My idea was to create a new setup, that installs ReactOS in packets, 
that would look a bit like this:

A compressed archive (maybe bzip) that contains a folder with all the 
files, that need to be installed, one file that contains informations 
like e.g. where to put the files (%SYSTEMROOT% or %WINDIR%...) and one 
script file that looks a bit like a batch file. Maybe we could add a 
file, that contains some questions and hints, that can be interpreted by 
different configuration utilities.
That is, what is IN these archives, in addition to this the header of 
the file would contain uncompressed information about the dependencies, 
so that they are easier to read.

All this would give us some big advantages.
For example we would be able to create different distributions and 
repositories.
Companies would be able to have a mirror of our repository and could 
additionally have their own repositories, whose files depend on ours.
This would ease deployment in big companies and would be a big advantage 
  compared to Microsoft, as everything happens completely unattended, 
even if you upgrade from ReactOS 1.0 to 3.0.

I'm looking forward to read what you think about my idea.

Greets,

David Hinz

[Alex Ionescu]

David Hinz wrote:
> Hey guys,
>
> at first I was shocked, when I read that you want to audit all code 
> and will have to rewrite a lot of the old code, but then I realised, 
> that this is a great chance for making improvements.
>
> Here's one of my ideas:
>
> We could create a completely new setup, that will have a gui (not 
> really a new idea...).
> But the second thing would be to create something similar to debians 
> apt and debconf.
> My idea was to create a new setup, that installs ReactOS in packets, 
> that would look a bit like this:
>
> A compressed archive (maybe bzip) that contains a folder with all the 
> files, that need to be installed, one file that contains informations 
> like e.g. where to put the files (%SYSTEMROOT% or %WINDIR%...) and one 
> script file that looks a bit like a batch file. Maybe we could add a 
> file, that contains some questions and hints, that can be interpreted 
> by different configuration utilities.
> That is, what is IN these archives, in addition to this the header of 
> the file would contain uncompressed information about the 
> dependencies, so that they are easier to read.
>
> All this would give us some big advantages.
> For example we would be able to create different distributions and 
> repositories.
> Companies would be able to have a mirror of our repository and could 
> additionally have their own repositories, whose files depend on ours.
> This would ease deployment in big companies and would be a big 
> advantage  compared to Microsoft, as everything happens completely 
> unattended, even if you upgrade from ReactOS 1.0 to 3.0.
>
> I'm looking forward to read what you think about my idea.
>
> Greets,
>
> David Hinz
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft is 
working on. Not saying that's a bad thing, on the contrary, but why 
re-invent the wheel? We could just use their tools.

Best regards,
Alex Ionescu

[David Hinz]

Alex Ionescu schrieb:
> Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft is 
> working on. Not saying that's a bad thing, on the contrary, but why 
> re-invent the wheel? We could just use their tools.

And exactly that is what it's not. I've been looking a lot at the new 
Vista deployment tools and ximage in the last two weeks, and the 
difference is, that MS creates a file based image of the whole system 
partition, copies it onto the harddisk and starts the setup, and what I 
described is a bit more like the debian installer, everything is in 
packages, that depend on other packages (or not) and each of them has 
it's own configuration.
This is much more customizable and flexible than Microsofts ximage.

You can create one cd for the whole company, but when you have installed 
ReactOS you just have to connect to the repository server and select the 
repositories you need for this workstation. You will never ever have to 
touch this workstaion again, it will be automatically updated with 
exactly the things needed on this workstation.

Keep in mind, my idea is not to make the installation as fast as 
possible and to waste as less space on the installation medias as 
possible, I want to make the administrators job a bit easier.

Plus this has positive effects for home users too, as we have a system 
wide update manager and not one for every vendor.
> Best regards,
> Alex Ionescu

Greets,

David Hinz

[TwoTailedFox]

"ReactOS Update"

On 1/29/06, David Hinz [e-mail] wrote:
> Alex Ionescu schrieb:
> > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft is
> > working on. Not saying that's a bad thing, on the contrary, but why
> > re-invent the wheel? We could just use their tools.
>
> And exactly that is what it's not. I've been looking a lot at the new
> Vista deployment tools and ximage in the last two weeks, and the
> difference is, that MS creates a file based image of the whole system
> partition, copies it onto the harddisk and starts the setup, and what I
> described is a bit more like the debian installer, everything is in
> packages, that depend on other packages (or not) and each of them has
> it's own configuration.
> This is much more customizable and flexible than Microsofts ximage.
>
> You can create one cd for the whole company, but when you have installed
> ReactOS you just have to connect to the repository server and select the
> repositories you need for this workstation. You will never ever have to
> touch this workstaion again, it will be automatically updated with
> exactly the things needed on this workstation.
>
> Keep in mind, my idea is not to make the installation as fast as
> possible and to waste as less space on the installation medias as
> possible, I want to make the administrators job a bit easier.
>
> Plus this has positive effects for home users too, as we have a system
> wide update manager and not one for every vendor.
> > Best regards,
> > Alex Ionescu
>
> Greets,
>
> David Hinz
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

--
"I had a handle on life, but then it broke"

[Jerry]

I agree with David here. I think it is good to try to be better than MS 
in this area. I also think we need to work on a set up similar to debian 
(ie be able to download packages from the net). I also think for 
compatibility reasons we need to set up a way to have self-extracting 
packages.

I also think we need to have the setup to be able to install without a 
single reboot. This includes ReactOS being recognize devices, able to 
load, and  use the related drivers without a reboot.

David Hinz wrote:
> Alex Ionescu schrieb:
> > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > is working on. Not saying that's a bad thing, on the contrary, but 
> > why re-invent the wheel? We could just use their tools.
>
> And exactly that is what it's not. I've been looking a lot at the new 
> Vista deployment tools and ximage in the last two weeks, and the 
> difference is, that MS creates a file based image of the whole system 
> partition, copies it onto the harddisk and starts the setup, and what 
> I described is a bit more like the debian installer, everything is in 
> packages, that depend on other packages (or not) and each of them has 
> it's own configuration.
> This is much more customizable and flexible than Microsofts ximage.
>
> You can create one cd for the whole company, but when you have 
> installed ReactOS you just have to connect to the repository server 
> and select the repositories you need for this workstation. You will 
> never ever have to touch this workstaion again, it will be 
> automatically updated with exactly the things needed on this workstation.
>
> Keep in mind, my idea is not to make the installation as fast as 
> possible and to waste as less space on the installation medias as 
> possible, I want to make the administrators job a bit easier.
>
> Plus this has positive effects for home users too, as we have a system 
> wide update manager and not one for every vendor.
> > Best regards,
> > Alex Ionescu
>
> Greets,
>
> David Hinz
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

You must've misunderstood/confused AIK/XIMAGE with the Vista installer 
itself. I was not referring to the fact that Vista copies the entire 
image system partition and installes from there. The new installer 
technology allows a product to be split in any number of dependent or 
independent packages, which each OEM can decide on what to include. 
These packages can also be used to create a CD that has 5 Windows 
versions, with one "Base" package, the other packages being simply the 
different files. While Vista doesn't use this to its full potential (at 
least yet), nothing stops us from using it fully, and it would allow 
exactly this kind of debian packaging.

AIK itself is an administrator's dream, both from the installation 
viewpoint, as well as to being able to setup post-install patches/tools 
as part of the .XIM. It also supports internet updating.

Best regards,
Alex Ionescu

David Hinz wrote:
> Alex Ionescu schrieb:
> > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > is working on. Not saying that's a bad thing, on the contrary, but 
> > why re-invent the wheel? We could just use their tools.
>
> And exactly that is what it's not. I've been looking a lot at the new 
> Vista deployment tools and ximage in the last two weeks, and the 
> difference is, that MS creates a file based image of the whole system 
> partition, copies it onto the harddisk and starts the setup, and what 
> I described is a bit more like the debian installer, everything is in 
> packages, that depend on other packages (or not) and each of them has 
> it's own configuration.
> This is much more customizable and flexible than Microsofts ximage.
>
> You can create one cd for the whole company, but when you have 
> installed ReactOS you just have to connect to the repository server 
> and select the repositories you need for this workstation. You will 
> never ever have to touch this workstaion again, it will be 
> automatically updated with exactly the things needed on this workstation.
>
> Keep in mind, my idea is not to make the installation as fast as 
> possible and to waste as less space on the installation medias as 
> possible, I want to make the administrators job a bit easier.
>
> Plus this has positive effects for home users too, as we have a system 
> wide update manager and not one for every vendor.
> > Best regards,
> > Alex Ionescu
>
> Greets,
>
> David Hinz
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Jerry]

We could use 7zip compression (LGPL) which has some pretty good 
compression ratios. I think we should design the install system to be 
independent of reactos, ie be able to use it for installing other 
software on windows compatible OS's

Alex Ionescu wrote:
> You must've misunderstood/confused AIK/XIMAGE with the Vista installer 
> itself. I was not referring to the fact that Vista copies the entire 
> image system partition and installes from there. The new installer 
> technology allows a product to be split in any number of dependent or 
> independent packages, which each OEM can decide on what to include. 
> These packages can also be used to create a CD that has 5 Windows 
> versions, with one "Base" package, the other packages being simply the 
> different files. While Vista doesn't use this to its full potential 
> (at least yet), nothing stops us from using it fully, and it would 
> allow exactly this kind of debian packaging.
>
> AIK itself is an administrator's dream, both from the installation 
> viewpoint, as well as to being able to setup post-install 
> patches/tools as part of the .XIM. It also supports internet updating.
>
> Best regards,
> Alex Ionescu
>
> David Hinz wrote:
> > Alex Ionescu schrieb:
> > > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > > is working on. Not saying that's a bad thing, on the contrary, but 
> > > why re-invent the wheel? We could just use their tools.
> >
> > And exactly that is what it's not. I've been looking a lot at the new 
> > Vista deployment tools and ximage in the last two weeks, and the 
> > difference is, that MS creates a file based image of the whole system 
> > partition, copies it onto the harddisk and starts the setup, and what 
> > I described is a bit more like the debian installer, everything is in 
> > packages, that depend on other packages (or not) and each of them has 
> > it's own configuration.
> > This is much more customizable and flexible than Microsofts ximage.
> >
> > You can create one cd for the whole company, but when you have 
> > installed ReactOS you just have to connect to the repository server 
> > and select the repositories you need for this workstation. You will 
> > never ever have to touch this workstaion again, it will be 
> > automatically updated with exactly the things needed on this 
> > workstation.
> >
> > Keep in mind, my idea is not to make the installation as fast as 
> > possible and to waste as less space on the installation medias as 
> > possible, I want to make the administrators job a bit easier.
> >
> > Plus this has positive effects for home users too, as we have a 
> > system wide update manager and not one for every vendor.
> > > Best regards,
> > > Alex Ionescu
> >
> > Greets,
> >
> > David Hinz
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Ward]

If this new setup/package management type system gets implemented, I 
think 7-Zip/LZMA would be the best choice for compression. As for making 
it generic so it can be used on other windows systems, I think that 
would be a wasted effort and the focus should be, at least initially, 
strictly on ReactOS.

Jerry wrote:
> We could use 7zip compression (LGPL) which has some pretty good 
> compression ratios. I think we should design the install system to be 
> independent of reactos, ie be able to use it for installing other 
> software on windows compatible OS's
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Jerry]

I'm thinking on working on a new setup system (just the installing files 
part).

Here are some of the details I'm thinking of (in no particular order):

1) 7-zip compression. 7-zip provides good compression ratios.
2)  xml based package information. This could include registry 
information needed by the application.
3) Third parties will be able to use it.
4) ability to download packages off of a network. ( (S)FTP HTTP or Samba )
5) self installing packages.
6) auto compile from source and install.
7) dependencies.
8) auto update from the net (not sure about this one).

If you have any other ideas please add them.

If anybody is interested in it, please tell me, and I'll plan to start 
working on it one to two weeks from now.

David Hinz wrote:
> Alex Ionescu schrieb:
> > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > is working on. Not saying that's a bad thing, on the contrary, but 
> > why re-invent the wheel? We could just use their tools.
>
> And exactly that is what it's not. I've been looking a lot at the new 
> Vista deployment tools and ximage in the last two weeks, and the 
> difference is, that MS creates a file based image of the whole system 
> partition, copies it onto the harddisk and starts the setup, and what 
> I described is a bit more like the debian installer, everything is in 
> packages, that depend on other packages (or not) and each of them has 
> it's own configuration.
> This is much more customizable and flexible than Microsofts ximage.
>
> You can create one cd for the whole company, but when you have 
> installed ReactOS you just have to connect to the repository server 
> and select the repositories you need for this workstation. You will 
> never ever have to touch this workstaion again, it will be 
> automatically updated with exactly the things needed on this workstation.
>
> Keep in mind, my idea is not to make the installation as fast as 
> possible and to waste as less space on the installation medias as 
> possible, I want to make the administrators job a bit easier.
>
> Plus this has positive effects for home users too, as we have a system 
> wide update manager and not one for every vendor.
> > Best regards,
> > Alex Ionescu
>
> Greets,
>
> David Hinz
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Andrew Scott]

7-zip can be painfully slow to unpack on old computers.

Jerry wrote:
> I'm thinking on working on a new setup system (just the installing 
> files part).
>
> Here are some of the details I'm thinking of (in no particular order):
> 7-zip compression. 7-zip provides good compression ratios.
> xml based package information. This could include registry
>
> information needed by the application.
> 3) Third parties will be able to use it.
> 4) ability to download packages off of a network. ( (S)FTP HTTP or 
> Samba )
> 5) self installing packages.
> 6) auto compile from source and install.
> 7) dependencies.
> 8) auto update from the net (not sure about this one).
>
> If you have any other ideas please add them.
>
> If anybody is interested in it, please tell me, and I'll plan to start 
> working on it one to two weeks from now.
>
> David Hinz wrote:
> > Alex Ionescu schrieb:
> > > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > > is working on. Not saying that's a bad thing, on the contrary, but 
> > > why re-invent the wheel? We could just use their tools.
> >
> > And exactly that is what it's not. I've been looking a lot at the new 
> > Vista deployment tools and ximage in the last two weeks, and the 
> > difference is, that MS creates a file based image of the whole system 
> > partition, copies it onto the harddisk and starts the setup, and what 
> > I described is a bit more like the debian installer, everything is in 
> > packages, that depend on other packages (or not) and each of them has 
> > it's own configuration.
> > This is much more customizable and flexible than Microsofts ximage.
> >
> > You can create one cd for the whole company, but when you have 
> > installed ReactOS you just have to connect to the repository server 
> > and select the repositories you need for this workstation. You will 
> > never ever have to touch this workstaion again, it will be 
> > automatically updated with exactly the things needed on this 
> > workstation.
> >
> > Keep in mind, my idea is not to make the installation as fast as 
> > possible and to waste as less space on the installation medias as 
> > possible, I want to make the administrators job a bit easier.
> >
> > Plus this has positive effects for home users too, as we have a 
> > system wide update manager and not one for every vendor.
> > > Best regards,
> > > Alex Ionescu
> >
> > Greets,
> >
> > David Hinz
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Jerry]

I could add diferent compression formats, like tgz, zip, bz2 to the 
installer.

Andrew Scott wrote:
> 7-zip can be painfully slow to unpack on old computers.
>
> Jerry wrote:
> > I'm thinking on working on a new setup system (just the installing 
> > files part).
> >
> > Here are some of the details I'm thinking of (in no particular order):
> > 7-zip compression. 7-zip provides good compression ratios.
> > xml based package information. This could include registry
> >
> > information needed by the application.
> > 3) Third parties will be able to use it.
> > 4) ability to download packages off of a network. ( (S)FTP HTTP or 
> > Samba )
> > 5) self installing packages.
> > 6) auto compile from source and install.
> > 7) dependencies.
> > 8) auto update from the net (not sure about this one).
> >
> > If you have any other ideas please add them.
> >
> > If anybody is interested in it, please tell me, and I'll plan to 
> > start working on it one to two weeks from now.
> >
> > David Hinz wrote:
> > > Alex Ionescu schrieb:
> > > > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft 
> > > > is working on. Not saying that's a bad thing, on the contrary, but 
> > > > why re-invent the wheel? We could just use their tools.
> > >
> > > And exactly that is what it's not. I've been looking a lot at the 
> > > new Vista deployment tools and ximage in the last two weeks, and the 
> > > difference is, that MS creates a file based image of the whole 
> > > system partition, copies it onto the harddisk and starts the setup, 
> > > and what I described is a bit more like the debian installer, 
> > > everything is in packages, that depend on other packages (or not) 
> > > and each of them has it's own configuration.
> > > This is much more customizable and flexible than Microsofts ximage.
> > >
> > > You can create one cd for the whole company, but when you have 
> > > installed ReactOS you just have to connect to the repository server 
> > > and select the repositories you need for this workstation. You will 
> > > never ever have to touch this workstaion again, it will be 
> > > automatically updated with exactly the things needed on this 
> > > workstation.
> > >
> > > Keep in mind, my idea is not to make the installation as fast as 
> > > possible and to waste as less space on the installation medias as 
> > > possible, I want to make the administrators job a bit easier.
> > >
> > > Plus this has positive effects for home users too, as we have a 
> > > system wide update manager and not one for every vendor.
> > > > Best regards,
> > > > Alex Ionescu
> > >
> > > Greets,
> > >
> > > David Hinz
> > > _______________________________________________
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Kai Moonbourn]

7zip gives me a lot of problems when I want to extract archives of any
appreciable size; it's impossible to extract a single file(with any client
I've tested) without parsing through the entire archive, which can immensely
increase the amount of time to access even a trivially small file.

On 1/28/06, Jerry [e-mail] wrote:
> I could add diferent compression formats, like tgz, zip, bz2 to the
> installer.
>
> Andrew Scott wrote:
> > 7-zip can be painfully slow to unpack on old computers.
> >
> > Jerry wrote:
> > > I'm thinking on working on a new setup system (just the installing
> > > files part).
> > >
> > > Here are some of the details I'm thinking of (in no particular order):
> > > 7-zip compression. 7-zip provides good compression ratios.
> > > xml based package information. This could include registry
> > >
> > > information needed by the application.
> > > 3) Third parties will be able to use it.
> > > 4) ability to download packages off of a network. ( (S)FTP HTTP or
> > > Samba )
> > > 5) self installing packages.
> > > 6) auto compile from source and install.
> > > 7) dependencies.
> > > 8) auto update from the net (not sure about this one).
> > >
> > > If you have any other ideas please add them.
> > >
> > > If anybody is interested in it, please tell me, and I'll plan to
> > > start working on it one to two weeks from now.
> > >
> > > David Hinz wrote:
> > > > Alex Ionescu schrieb:
> > > > > Sounds a lot like the new Vista AIK and the XIMAGE system Microsoft
> > > > > is working on. Not saying that's a bad thing, on the contrary, but
> > > > > why re-invent the wheel? We could just use their tools.
> > > >
> > > > And exactly that is what it's not. I've been looking a lot at the
> > > > new Vista deployment tools and ximage in the last two weeks, and the
> > > > difference is, that MS creates a file based image of the whole
> > > > system partition, copies it onto the harddisk and starts the setup,
> > > > and what I described is a bit more like the debian installer,
> > > > everything is in packages, that depend on other packages (or not)
> > > > and each of them has it's own configuration.
> > > > This is much more customizable and flexible than Microsofts ximage.
> > > >
> > > > You can create one cd for the whole company, but when you have
> > > > installed ReactOS you just have to connect to the repository server
> > > > and select the repositories you need for this workstation. You will
> > > > never ever have to touch this workstaion again, it will be
> > > > automatically updated with exactly the things needed on this
> > > > workstation.
> > > >
> > > > Keep in mind, my idea is not to make the installation as fast as
> > > > possible and to waste as less space on the installation medias as
> > > > possible, I want to make the administrators job a bit easier.
> > > >
> > > > Plus this has positive effects for home users too, as we have a
> > > > system wide update manager and not one for every vendor.
> > > > > Best regards,
> > > > > Alex Ionescu
> > > >
> > > > Greets,
> > > >
> > > > David Hinz
> > > > _______________________________________________
> > > > Ros-dev mailing list
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Mike Swanson]

The default for 7-Zip is to make a "solid archive"-The concept that is pretty 
natural to Unix-like OSes (similar to making a tar of files and compressing 
it). It allows for _much_ better compression than a non-solid archive. A 
non-solid archive just compresses each file individually and wraps them up 
into a single file (like what Zip does).

On Saturday 28 January 2006 22:26, Kai Moonbourn wrote:
> 7zip gives me a lot of problems when I want to extract archives of any
> appreciable size; it's impossible to extract a single file(with any client
> I've tested) without parsing through the entire archive, which can
> immensely increase the amount of time to access even a trivially small
> file.
>
> On 1/28/06, Jerry [e-mail] wrote:
> > I could add diferent compression formats, like tgz, zip, bz2 to the
> > installer.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Mike
OpenPGP Public Key: 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1FFF814B

[Maarten Bosma]

I did already make the effort to create a package manager. The idea was 
to maintain only scripts which tell where to download the program and 
how to install it. So we do not have to waste our bandwidth for it.

Here are some informations:
http://www.reactos.org/wiki/index.php/ReactOS_Package_Manager

But we can drop if come up with something better.

Maarten Bosma

Mike Swanson schrieb:
> The default for 7-Zip is to make a "solid archive"-The concept that is pretty 
> natural to Unix-like OSes (similar to making a tar of files and compressing 
> it). It allows for _much_ better compression than a non-solid archive. A 
> non-solid archive just compresses each file individually and wraps them up 
> into a single file (like what Zip does).
>
> On Saturday 28 January 2006 22:26, Kai Moonbourn wrote:
> > 7zip gives me a lot of problems when I want to extract archives of any
> > appreciable size; it's impossible to extract a single file(with any client
> > I've tested) without parsing through the entire archive, which can
> > immensely increase the amount of time to access even a trivially small
> > file.
> >
> > On 1/28/06, Jerry [e-mail] wrote:
> > > I could add diferent compression formats, like tgz, zip, bz2 to the
> > > installer.

[David Hinz]

I personally would prefer a compression that uses solid archives, nobody 
needs to just extract one file, we need them all. Maybe we can create a 
new container format, that includes the dependencies of the package at a 
specified position at the beginning of the file and then the compressed 
archive.

I'm thinking of a xml based package, it would look a bit like this:

<rospckg version="1.0">
   <head>
     <package>ReactOS-base</package>
     <version>0.3.0</version>
     <dependencies>
       <+ package="freeldr"> //this package is required
         <minver>1.0</minver>  //it has to be at least this version
         <maxver>1.2.1</maxver>  //any version higher than this one is 
not allowed
         <notver>1.0.1b;1.2.0.3d;1.1.1-badver</notver>  //these versions 
are not allowed
       </+>
       <- package="ntldr">  //there is a conflict, these two packages 
can't be installed at the same time
         <exceptver>2.0.1-ros</exceptver>  //but this one IS allowed
       </->
     </dependencies>
     <description>
       <shortdesc>This is one sentence about this app</shortdesc>
       <extdesc>Put the long description here, there is no 
limit...</extdesc>
     </description>
   </head>
   <archives>
     <install base="%SYSTEMROOT%" type="7zip">
       Here will be one compressed archive that will be unzipped to 
%SYSTEMROOT%
     </install>
     <install base="%WHATEVER%" type="tar"
       And a tar archive...
     </install>
     <script type="registry">
       Some registry values...
     </script>
     <script type="batch">
       and a batchfile...
     </script>
   </archives>
</rospckg>

Greets,

David Hinz

Maarten Bosma schrieb:
> I did already make the effort to create a package manager. The idea was 
> to maintain only scripts which tell where to download the program and 
> how to install it. So we do not have to waste our bandwidth for it.
>
> Here are some informations:
> http://www.reactos.org/wiki/index.php/ReactOS_Package_Manager
>
> But we can drop if come up with something better.
>
> Maarten Bosma
>
> Mike Swanson schrieb:
> > The default for 7-Zip is to make a "solid archive"-The concept that is 
> > pretty natural to Unix-like OSes (similar to making a tar of files and 
> > compressing it). It allows for _much_ better compression than a 
> > non-solid archive. A non-solid archive just compresses each file 
> > individually and wraps them up into a single file (like what Zip does).
> >
> > On Saturday 28 January 2006 22:26, Kai Moonbourn wrote:
> > > 7zip gives me a lot of problems when I want to extract archives of any
> > > appreciable size; it's impossible to extract a single file(with any 
> > > client
> > > I've tested) without parsing through the entire archive, which can
> > > immensely increase the amount of time to access even a trivially small
> > > file.
> > >
> > > On 1/28/06, Jerry [e-mail] wrote:
> > > > I could add diferent compression formats, like tgz, zip, bz2 to the
> > > > installer.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Jerry]

I was thinking of a system that was ROS independent, ie can be used on 
other windows compatable platforms. I was also thinking of using an XML 
format that was already out there.

This (http://www.reactos.org/wiki/index.php/ReactOS_Package_Manager) was 
not really what  had in mind; although, it is a good start.

I'm thinking of putting my design ideas up on wiki so you can look at them.

David Hinz wrote:
> I personally would prefer a compression that uses solid archives, 
> nobody needs to just extract one file, we need them all. Maybe we can 
> create a new container format, that includes the dependencies of the 
> package at a specified position at the beginning of the file and then 
> the compressed archive.
>
> I'm thinking of a xml based package, it would look a bit like this:
>
> <rospckg version="1.0">
>   <head>
>     <package>ReactOS-base</package>
>     <version>0.3.0</version>
>     <dependencies>
>       <+ package="freeldr"> //this package is required
>         <minver>1.0</minver>  //it has to be at least this version
>         <maxver>1.2.1</maxver>  //any version higher than this one is 
> not allowed
>         <notver>1.0.1b;1.2.0.3d;1.1.1-badver</notver>  //these 
> versions are not allowed
>       </+>
>       <- package="ntldr">  //there is a conflict, these two packages 
> can't be installed at the same time
>         <exceptver>2.0.1-ros</exceptver>  //but this one IS allowed
>       </->
>     </dependencies>
>     <description>
>       <shortdesc>This is one sentence about this app</shortdesc>
>       <extdesc>Put the long description here, there is no 
> limit...</extdesc>
>     </description>
>   </head>
>   <archives>
>     <install base="%SYSTEMROOT%" type="7zip">
>       Here will be one compressed archive that will be unzipped to 
> %SYSTEMROOT%
>     </install>
>     <install base="%WHATEVER%" type="tar"
>       And a tar archive...
>     </install>
>     <script type="registry">
>       Some registry values...
>     </script>
>     <script type="batch">
>       and a batchfile...
>     </script>
>   </archives>
> </rospckg>
>
> Greets,
>
> David Hinz
>
> Maarten Bosma schrieb:
> > I did already make the effort to create a package manager. The idea 
> > was to maintain only scripts which tell where to download the program 
> > and how to install it. So we do not have to waste our bandwidth for it.
> >
> > Here are some informations:
> > http://www.reactos.org/wiki/index.php/ReactOS_Package_Manager
> >
> > But we can drop if come up with something better.
> >
> > Maarten Bosma
> >
> > Mike Swanson schrieb:
> > > The default for 7-Zip is to make a "solid archive"-The concept that 
> > > is pretty natural to Unix-like OSes (similar to making a tar of 
> > > files and compressing it). It allows for _much_ better compression 
> > > than a non-solid archive. A non-solid archive just compresses each 
> > > file individually and wraps them up into a single file (like what 
> > > Zip does).
> > >
> > > On Saturday 28 January 2006 22:26, Kai Moonbourn wrote:
> > > > 7zip gives me a lot of problems when I want to extract archives of any
> > > > appreciable size; it's impossible to extract a single file(with any 
> > > > client
> > > > I've tested) without parsing through the entire archive, which can
> > > > immensely increase the amount of time to access even a trivially small
> > > > file.
> > > >
> > > > On 1/28/06, Jerry [e-mail] wrote:
> > > > > I could add diferent compression formats, like tgz, zip, bz2 to the
> > > > > installer.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[mf]

Hiya!

David Hinz wrote:
> Here's one of my ideas:
>
> We could create a completely new setup, that will have a gui (not really 
> a new idea...).
> My idea was to create a new setup, that installs ReactOS in packets,

I think, *if* we are going to revamp our setup, we will have to look at 
a whole set of areas where improvement is possible. I have installed 
countless windozes from Win3.11 up to Server 2003 and Longhorn Beta 1, 
have also installed alternative operating systems *and* created 
installers for applications with varied levels of attendance (most of 
them only have two buttons, Install and Exit, but I've also done 
wizard-based stuff), so I think I've sort of got an idea what's needed.

Now, reboot count has already been mentioned. It would be really cool if 
we can require no more than 2 reboots for an entire system install. I 
don't know the technicalities behind driver detection and *why* Windows 
always needs to reboot 2 to 3 times, but I trust someone like Alex will 
come up and shoot the whole idea down (like usual :D).
Ideally, I would envision this as a realistic way of handling reboots:

Boot from CD: The LiveCD is booted into a WinPE-like environment, 
everything from copying files to detecting hardware and installing 
drivers is done in the same session, and after installation is complete 
setup reboots into the newly installed ReactOS system. (1 reboot total)

Install from running ReactOS/Windows session: Required files are copied 
to harddrive, and setup reboots into the installation environment, where 
everything from configuring the system to detecting hardware and 
installing drivers is done in the same session, and after installation 
is complete setup reboots into the newly installed ReactOS system. (2 
reboots total)

Packages have also been mentioned. This whole Vista thing sounds like a 
stupid idea, I smell a lot of reverse engineering in the air (it would 
be a joke to assume Microsoft would document everything properly), and a 
lot of limitations because we have to stick to something. Also, it would 
be assuming Microsoft has come up with something smart, and quite 
frankly I don't think they have. It's worthwhile to discuss a lot and 
come up with something well-thought about, seeing that package 
management is very prone to preference. I have seen people praise RPM 
into the heavens and others curse it for its dependancy hell, and the 
same goes for every other package system in existance.

Personally, I would like to see simplicity kept with a max of 
installation flexibility. Borrowing from Slackware's package system (the 
simplest package system in existance), a clever idea might be to have a 
single archive for a package containing all necessary files in a virtual 
directory structure that mimics the target structure (similar to 
Microsoft's $OEM$ dir on branded/slipstreamed Windows installation CDs), 
along with an install script in the root of the archive. Everybody's all 
in love with XML files, but personally I envision a script format more 
usable for this purpose. As for what compression format, it really 
doesn't matter much, but considering we're an FOSS operating system 
gearing towards a very pluriform hardware platform (ranging from 486 to 
Athlon64, and even other architectures), we'd be better off with 
something that doesn't need an overclocked rig to decompress with 
reasonable speed, so I'm thinking either tar-gzip or tar-bz2. The file 
extension would probably be best off renamed (so it's a tgz in disguise) 
to something like .RPKG.

I'm envisioning directory structure inside the archive like so:
{systemroot}\system32\somelib.dll
{targetdir}\someapp.exe
logo.bmp
package.rpkgscript

The rpkgscript should be able to invoke user interaction with simple 
javascript-like alerts asking for input, but the named variables for 
these should all be definable as arguments (and have default values, 
which in unattended mode will be used). So for instance, let's say we 
call a wizard dialog from our script:

wizardDlg(pathstr "targetdir", bmp "logo")
{
    <wizardbmp null, src="logo" />
    <static null, left="10px", width="*">Please enter the target directory 
you would like to install Some App into.</static>
    <br />
    <form dest, var="targetdir", type="path">
    <input null, type="text", left="10px", width="*">
    <button type="browse">Browse...</button>
    </form>
    <wizardctrl prev="1", next=dest?1:0, cancel="1" />
}

Now I hope you all like how much of a kludgy crossover between script 
and XML this is as I do! :D Let's dissect this into what gets parsed 
how. We call a standard function, wizardDlg, which creates a wizard 
dialog as we all know them, with an image on the left, and a 
prev/next/cancel button. The parameters for the function call indicate 
which variables from the dialog are imported and exported as global 
script variables. At the top of the script file, we have defined a 
default value for "targetdir", let's say it was "{programfiles}\Some 
App". "logo" has been defined as being "logo.bmp" in our archive, so we 
know all we need. The <wizardbmp> element defines the content of the 
bitmap on the left of the wizard. If not defined, it is a default 
generic image. The name "null" means it it can not be referenced, much 
like you can't get a return value from a function in C that has the type 
"void". The <static> element indicates static text just like in any 
other dialog scripting language. It is aligned 10 pixels from the left, 
and fills the remaining width of the dialog. The <form> element groups 
our <input> and <button> elements into the element "dest", which returns 
1 if the input is valid and 0 if not. The text put into the <input> 
element is put in the "targetdir" variable, which is returned to the 
script when the dialog exits. When the dialog aborts (cancel), all 
variables remain in their prior (default) values. The browse button is 
also of a prefabricated nature, it allows the user to browse for a path. 
  The <wizardctrl> element defines which buttons are active and which 
are disabled. The "next" button's state relies on the "dest" return 
value using a conditional statement, if it is 1 (valid path input) it is 
active, if else, it is disabled, and the user can't press next. After 
this dialog successfully exits, the script can proceed to install the 
files from the archive, and {targetdir} in the archive will be replaced 
by the value put in by the user. In unattended mode, all dialog calls 
are skipped and the default values for the variables used for 
installing. Calling a script with parameters (from the commandline or 
from another script) can be used to modify any of these variables.

This was just an example, but I'm sure you can all think of powerful 
things you can do with a scripting language like this. I got my 
inspiration from having written AVISynth scripts and making Wise 
Installation scripts. We can probably also learn from the way how NSIS 
(Nullsoft Installer) works. I'm thinking of using a more powerful 
version of the same scripting language for the entire ReactOS 
installation process, so that distributions, system administrators, etc 
can easily brand and modify the installer to slipstream, configure, and 
ask for user interaction exactly where and how they want to.

I've been playing with nLite and experimented with slipstreaming and 
tweaking certain things in the install, and with Windows' current 
install system it's a royal pain in the behind. With my proposition, to 
slipstream an application into ReactOS, the only thing you would have to 
do is include the rpkg file, and it will be included in the components 
list. If you want it to be an optional component or have it be silently 
installed, configure it in the master script file to either be optional 
or installed in unattended mode (with or without parameters).

Hm, seems this mail grew slightly out of hand in size, but I can't think 
of anything else I want to mention now. Looking forward to hearing your 
comments, and let's hope I didn't dive too much into details, I just 
always have a very detailed concept in my mind.

Cheers,

mf

[Casper Hornstrup]

MSI already solves that problem (or at least a large part of it).
Why not use that instead? Also, we get resources from the Wine
project to help implement it for free.

Casper
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of mf
> Sent: 30. januar 2006 22:04
> To: ReactOS Development List
> Subject: [ros-dev] Re: New Setup system
>
> Hiya!
>
> David Hinz wrote:
> > Here's one of my ideas:
> >
> > We could create a completely new setup, that will have a gui (not really
> > a new idea...).
> > My idea was to create a new setup, that installs ReactOS in packets,
>
> I think, *if* we are going to revamp our setup, we will have to look at
> a whole set of areas where improvement is possible. I have installed
> countless windozes from Win3.11 up to Server 2003 and Longhorn Beta 1,
> have also installed alternative operating systems *and* created
> installers for applications with varied levels of attendance (most of
> them only have two buttons, Install and Exit, but I've also done
> wizard-based stuff), so I think I've sort of got an idea what's needed.
>
> Now, reboot count has already been mentioned. It would be really cool if
> we can require no more than 2 reboots for an entire system install. I
> don't know the technicalities behind driver detection and *why* Windows
> always needs to reboot 2 to 3 times, but I trust someone like Alex will
> come up and shoot the whole idea down (like usual :D).
> Ideally, I would envision this as a realistic way of handling reboots:
>
> Boot from CD: The LiveCD is booted into a WinPE-like environment,
> everything from copying files to detecting hardware and installing
> drivers is done in the same session, and after installation is complete
> setup reboots into the newly installed ReactOS system. (1 reboot total)
>
> Install from running ReactOS/Windows session: Required files are copied
> to harddrive, and setup reboots into the installation environment, where
> everything from configuring the system to detecting hardware and
> installing drivers is done in the same session, and after installation
> is complete setup reboots into the newly installed ReactOS system. (2
> reboots total)
>
> Packages have also been mentioned. This whole Vista thing sounds like a
> stupid idea, I smell a lot of reverse engineering in the air (it would
> be a joke to assume Microsoft would document everything properly), and a
> lot of limitations because we have to stick to something. Also, it would
> be assuming Microsoft has come up with something smart, and quite
> frankly I don't think they have. It's worthwhile to discuss a lot and
> come up with something well-thought about, seeing that package
> management is very prone to preference. I have seen people praise RPM
> into the heavens and others curse it for its dependancy hell, and the
> same goes for every other package system in existance.
>
> Personally, I would like to see simplicity kept with a max of
> installation flexibility. Borrowing from Slackware's package system (the
> simplest package system in existance), a clever idea might be to have a
> single archive for a package containing all necessary files in a virtual
> directory structure that mimics the target structure (similar to
> Microsoft's $OEM$ dir on branded/slipstreamed Windows installation CDs),
> along with an install script in the root of the archive. Everybody's all
> in love with XML files, but personally I envision a script format more
> usable for this purpose. As for what compression format, it really
> doesn't matter much, but considering we're an FOSS operating system
> gearing towards a very pluriform hardware platform (ranging from 486 to
> Athlon64, and even other architectures), we'd be better off with
> something that doesn't need an overclocked rig to decompress with
> reasonable speed, so I'm thinking either tar-gzip or tar-bz2. The file
> extension would probably be best off renamed (so it's a tgz in disguise)
> to something like .RPKG.
>
> I'm envisioning directory structure inside the archive like so:
> {systemroot}\system32\somelib.dll
> {targetdir}\someapp.exe
> logo.bmp
> package.rpkgscript
>
> The rpkgscript should be able to invoke user interaction with simple
> javascript-like alerts asking for input, but the named variables for
> these should all be definable as arguments (and have default values,
> which in unattended mode will be used). So for instance, let's say we
> call a wizard dialog from our script:
>
> wizardDlg(pathstr "targetdir", bmp "logo")
> {
>    <wizardbmp null, src="logo" />
>    <static null, left="10px", width="*">Please enter the target
> directory
> you would like to install Some App into.</static>
>
>    <br />
>    <form dest, var="targetdir", type="path">
>    <input null, type="text", left="10px", width="*">
>    <button type="browse">Browse...</button>
>    </form>
>    <wizardctrl prev="1", next=dest?1:0, cancel="1" />
> }
>
> Now I hope you all like how much of a kludgy crossover between script
> and XML this is as I do! :D Let's dissect this into what gets parsed
> how. We call a standard function, wizardDlg, which creates a wizard
> dialog as we all know them, with an image on the left, and a
> prev/next/cancel button. The parameters for the function call indicate
> which variables from the dialog are imported and exported as global
> script variables. At the top of the script file, we have defined a
> default value for "targetdir", let's say it was "{programfiles}\Some
> App". "logo" has been defined as being "logo.bmp" in our archive, so we
> know all we need. The <wizardbmp> element defines the content of the
> bitmap on the left of the wizard. If not defined, it is a default
> generic image. The name "null" means it it can not be referenced, much
> like you can't get a return value from a function in C that has the type
> "void". The <static> element indicates static text just like in any
> other dialog scripting language. It is aligned 10 pixels from the left,
> and fills the remaining width of the dialog. The <form> element groups
> our <input> and <button> elements into the element "dest", which returns
> 1 if the input is valid and 0 if not. The text put into the <input>
> element is put in the "targetdir" variable, which is returned to the
> script when the dialog exits. When the dialog aborts (cancel), all
> variables remain in their prior (default) values. The browse button is
> also of a prefabricated nature, it allows the user to browse for a path.
>   The <wizardctrl> element defines which buttons are active and which
> are disabled. The "next" button's state relies on the "dest" return
> value using a conditional statement, if it is 1 (valid path input) it is
> active, if else, it is disabled, and the user can't press next. After
> this dialog successfully exits, the script can proceed to install the
> files from the archive, and {targetdir} in the archive will be replaced
> by the value put in by the user. In unattended mode, all dialog calls
> are skipped and the default values for the variables used for
> installing. Calling a script with parameters (from the commandline or
> from another script) can be used to modify any of these variables.
>
> This was just an example, but I'm sure you can all think of powerful
> things you can do with a scripting language like this. I got my
> inspiration from having written AVISynth scripts and making Wise
> Installation scripts. We can probably also learn from the way how NSIS
> (Nullsoft Installer) works. I'm thinking of using a more powerful
> version of the same scripting language for the entire ReactOS
> installation process, so that distributions, system administrators, etc
> can easily brand and modify the installer to slipstream, configure, and
> ask for user interaction exactly where and how they want to.
>
> I've been playing with nLite and experimented with slipstreaming and
> tweaking certain things in the install, and with Windows' current
> install system it's a royal pain in the behind. With my proposition, to
> slipstream an application into ReactOS, the only thing you would have to
> do is include the rpkg file, and it will be included in the components
> list. If you want it to be an optional component or have it be silently
> installed, configure it in the master script file to either be optional
> or installed in unattended mode (with or without parameters).
>
> Hm, seems this mail grew slightly out of hand in size, but I can't think
> of anything else I want to mention now. Looking forward to hearing your
> comments, and let's hope I didn't dive too much into details, I just
> always have a very detailed concept in my mind.
>
> Cheers,
>
> mf
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Ward]

Transparently supporting multiple compression formats would solve 
the various opinions here I think. I see no reason to limit the 
"package" manager to using only packages. It would be nice if it 
supported packages as well as "ports" (ports as in a recipe file that 
would have instructions for retrieving/building/installing apps). Add to 
that repository support with user definable locations on the net or 
local and you have one complete software management system :). Some 
people seem to think XML is to heavy for this (it doesn't bother me). 
There is a much lighter weight alternative available called YAML more 
information about YAML can be found here: http://www.yaml.org/

As for the installation part I have no thoughts on it because I 
think the package management aspect is much more important. Managing the 
database of installed software etc... It would also be nice if when 
upgrading configuration files were merged and only if a conflict arises 
would the user need to intervene, maybe there could be an option in the 
package/script to specify if this is safe to do or not and if its not 
safe then a backup (backups should be made with the merge as well) is 
made and the user notified that they need to update/check their settings.

just a few thoughts...
dralnix

mf wrote:
> <snip>_______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[David Hinz]

Sounds lie you are thinking just like crashfourit and me, so I think we 
three should be able to start with this project (even if I won't be of 
much use atm, as I'm just beginning to learn c++).

Actually there is one big difference between your idea and mine: You 
want these packages in addition to our current ReactOS base, I want 
everything to be package based. There would be a base package, a freeldr 
package and so on.

The thing with the live cd also crossed my mind and seems to be a good 
idea, the live-cd is just based on the ReactOS version you are about to 
install, so there should be no problem with driver detection and 
installation.

Basically you would do this: Put the install-cd into your cd-drive and 
boot from it. The live-cd will boot up and you will see a ReactOS that 
started a setup application instead of explorer.exe. Then you can choose 
between installing ReactOS or trying out ReactOS. If you press "Try" the 
setup app will close and start explorer.exe, if you press install, the 
setup will continue and start with the installation.

You will select a basic setup (e.g. server, home desktop, enterprise 
desktop...) and will then be able to (de)select different packages.
After this step setup knows how many space you will need on your 
harddisk and will start a partition manager (maybe something like 
qtparted, but at least as good as the MS solution, even if it should be 
a lot better...).

Now I have to describe a little thing: I want packages to have a flag 
that tells setup if there are any questions that can't be skipped by 
unattended installation.
Setup will scan the installation disk for such packages and will ask the 
questions, that can't be skipped.
After this all packages the user selected will be unpacked to the 
harddisk, execute all scripts included in the packages, and setup will 
reboot for the first time.
Now the new ReactOS will be booted and is ready for use!
Every device ReactOS has a driver for is already installed, all users 
you wanted to have are created, all applications are installed, isn't 
this nice?

For the internals, what you describe looks good, and I don't think we 
should talk about the script layout that much now, but we should define 
some basic things, like how we should store the basic information about 
this package (dependencies, ...) and the internalt folder structure.

And then we have to have a look at the ReactOS Package Manager.
But not today, I'm getting tired...

Greets,

David Hinz

mf schrieb:
> Hiya!
>
> I think, *if* we are going to revamp our setup, we will have to look at 
> a whole set of areas where improvement is possible. I have installed 
> countless windozes from Win3.11 up to Server 2003 and Longhorn Beta 1, 
> have also installed alternative operating systems *and* created 
> installers for applications with varied levels of attendance (most of 
> them only have two buttons, Install and Exit, but I've also done 
> wizard-based stuff), so I think I've sort of got an idea what's needed.
>
> Now, reboot count has already been mentioned. It would be really cool if 
> we can require no more than 2 reboots for an entire system install. I 
> don't know the technicalities behind driver detection and *why* Windows 
> always needs to reboot 2 to 3 times, but I trust someone like Alex will 
> come up and shoot the whole idea down (like usual :D).
> Ideally, I would envision this as a realistic way of handling reboots:
>
> Boot from CD: The LiveCD is booted into a WinPE-like environment, 
> everything from copying files to detecting hardware and installing 
> drivers is done in the same session, and after installation is complete 
> setup reboots into the newly installed ReactOS system. (1 reboot total)
>
> Install from running ReactOS/Windows session: Required files are copied 
> to harddrive, and setup reboots into the installation environment, where 
> everything from configuring the system to detecting hardware and 
> installing drivers is done in the same session, and after installation 
> is complete setup reboots into the newly installed ReactOS system. (2 
> reboots total)
>
> Packages have also been mentioned. This whole Vista thing sounds like a 
> stupid idea, I smell a lot of reverse engineering in the air (it would 
> be a joke to assume Microsoft would document everything properly), and a 
> lot of limitations because we have to stick to something. Also, it would 
> be assuming Microsoft has come up with something smart, and quite 
> frankly I don't think they have. It's worthwhile to discuss a lot and 
> come up with something well-thought about, seeing that package 
> management is very prone to preference. I have seen people praise RPM 
> into the heavens and others curse it for its dependancy hell, and the 
> same goes for every other package system in existance.
>
> Personally, I would like to see simplicity kept with a max of 
> installation flexibility. Borrowing from Slackware's package system (the 
> simplest package system in existance), a clever idea might be to have a 
> single archive for a package containing all necessary files in a virtual 
> directory structure that mimics the target structure (similar to 
> Microsoft's $OEM$ dir on branded/slipstreamed Windows installation CDs), 
> along with an install script in the root of the archive. Everybody's all 
> in love with XML files, but personally I envision a script format more 
> usable for this purpose. As for what compression format, it really 
> doesn't matter much, but considering we're an FOSS operating system 
> gearing towards a very pluriform hardware platform (ranging from 486 to 
> Athlon64, and even other architectures), we'd be better off with 
> something that doesn't need an overclocked rig to decompress with 
> reasonable speed, so I'm thinking either tar-gzip or tar-bz2. The file 
> extension would probably be best off renamed (so it's a tgz in disguise) 
> to something like .RPKG.
>
> I'm envisioning directory structure inside the archive like so:
> {systemroot}\system32\somelib.dll
> {targetdir}\someapp.exe
> logo.bmp
> package.rpkgscript
>
> The rpkgscript should be able to invoke user interaction with simple 
> javascript-like alerts asking for input, but the named variables for 
> these should all be definable as arguments (and have default values, 
> which in unattended mode will be used). So for instance, let's say we 
> call a wizard dialog from our script:
>
> wizardDlg(pathstr "targetdir", bmp "logo")
> {
>     <wizardbmp null, src="logo" />
>     <static null, left="10px", width="*">Please enter the target 
> directory you would like to install Some App into.</static>
>     <br />
>     <form dest, var="targetdir", type="path">
>     <input null, type="text", left="10px", width="*">
>     <button type="browse">Browse...</button>
>     </form>
>     <wizardctrl prev="1", next=dest?1:0, cancel="1" />
> }
>
> *I removed the rest, as it doesn't matter for my mail...*