RE: [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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev