[ros-dev] Re: New Setup system

David Hinz post.center at gmail.com
Mon Jan 30 23:10:21 CET 2006

Sounds lie you are thinking just like crashfourit and me, so I think we 
three should be able to start with this project (even if I won't be of 
much use atm, as I'm just beginning to learn c++).

Actually there is one big difference between your idea and mine: You 
want these packages in addition to our current ReactOS base, I want 
everything to be package based. There would be a base package, a freeldr 
package and so on.

The thing with the live cd also crossed my mind and seems to be a good 
idea, the live-cd is just based on the ReactOS version you are about to 
install, so there should be no problem with driver detection and 

Basically you would do this: Put the install-cd into your cd-drive and 
boot from it. The live-cd will boot up and you will see a ReactOS that 
started a setup application instead of explorer.exe. Then you can choose 
between installing ReactOS or trying out ReactOS. If you press "Try" the 
setup app will close and start explorer.exe, if you press install, the 
setup will continue and start with the installation.

You will select a basic setup (e.g. server, home desktop, enterprise 
desktop...) and will then be able to (de)select different packages.
After this step setup knows how many space you will need on your 
harddisk and will start a partition manager (maybe something like 
qtparted, but at least as good as the MS solution, even if it should be 
a lot better...).

Now I have to describe a little thing: I want packages to have a flag 
that tells setup if there are any questions that can't be skipped by 
unattended installation.
Setup will scan the installation disk for such packages and will ask the 
questions, that can't be skipped.
After this all packages the user selected will be unpacked to the 
harddisk, execute all scripts included in the packages, and setup will 
reboot for the first time.
Now the new ReactOS will be booted and is ready for use!
Every device ReactOS has a driver for is already installed, all users 
you wanted to have are created, all applications are installed, isn't 
this nice?

For the internals, what you describe looks good, and I don't think we 
should talk about the script layout that much now, but we should define 
some basic things, like how we should store the basic information about 
this package (dependencies, ...) and the internalt folder structure.

And then we have to have a look at the ReactOS Package Manager.
But not today, I'm getting tired...


David Hinz

mf schrieb:
> Hiya!
> 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" />
> }
> *I removed the rest, as it doesn't matter for my mail...*

More information about the Ros-dev mailing list