I've read some of your posts, and wanted to say a thing here. Don't make it to complicated at first. The Updater should work, okay. When it crashes the system in 95% of all update-processes - then there are bugs, which have to be squashed. But it'll be a pretty straight forward updater at first. And one thing "The loader copies files and if the first boot didn't work it rescues the system". Well no. There are several mistakes in your thinking. First: I will not rewrite the loader and I will not hack stuff, just to get a system to work (again), which will most probably crash during establishing the WinSocks or HTTP-Connections to the server.
If there are files that have been modified by the user, he will probably not want to update the system at all - and espacially not with my updater. The first thing: there is no user-interaction involved while updating. The User will start the updater and it does it's job. The User will not decide which files have to be updated and which not. He will most likely break the system by doing that.
The last post in this thread is about a month ago. But for any further writers: Don't do the second step before the first. I hope to have a working trial for Chemnitzer Linux Tag (Chemnitz's Linux days) on 16th March.
There are two things I'd like to know: What attributes does freeldr.ini take for Ros? -> SystemPath. Kernel? Hal/hal? Please tell me the right writing. By the way, these information have to be in the wiki, not on forum. Could someone(tm) take care of that.
I want to add a thing:
And in version 3.0 we can implement a BITS technology so the downloads are done on idle moments not stealing bandwith when the user is "using"it.
ReactOS crahes when I start Opera and begin doing stuff with it. How exactly will Ros manage to stay up long enough to even get when the bandwidth ain't used? Please think in proportions - Ros ain't anywhere near usable - so why should the "first" versions of my Updater? 3.0 is still in the future, but don't dream that much... Stay in here and now.