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