[ros-dev] Re: New Setup system

[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