[ros-dev] Re: New Setup system

[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: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] 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
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev