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