30 Jan
2006
30 Jan
'06
10:10 p.m.
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...*