[IDEA] The ReactOS Update

[nicoalta01]

Hi all,
I am nicoalta01.
I am a fan for ReactOS project and i try the wingup program for ReactOS project

What is WingUp program?
WinGup is a Generic Updater running under Windows environment.
The aim of WinGup is to provide a ready to use and configurable updater which downloads a update package then installs it.
By using cURL library and TinyXml module, GUP is capable to deal with http protocol and process XML data.

Why don't we use wingup for ReactOS update?

For example, when there will be reactos relase 0.4, the wingup will say: "Hey, there is a new version of ReactOS. Do you want to download?" "yes or no"

This program is free (GNU licence) and the author is Don Ho (the autor of notepad++ too) then we can use for ReactOS...
The link: https://github.com/gup4win/wingup
A screenshot of idea:

[ external image ]

is there a good idea?

Bye

PS: i don't see microsoft source code
Sorry for my bad english.

[oldman]

It is a good idea to have an updater, but it is much too early in the development of the OS for such things; you don't give a bicycle to a baby, because the baby cannot even walk, so it is of no value to it, until it as grown enough to use it.

It is released under the LGPL.

There is a dedicated topic for such suggestions, called Read this if you've found software useful to ReactOS.

[ImperialSpectre]

The Concept of the Idea is a good one but it is at the moment too early for developers to think about it and at the moment they're working towards 0.4 which if I'm not mistaken is basically nearing beta testing but certain components haven't been implemented yet like for example key components to get it to run on modern up-to-date computers and some keyboards/mouse aren't working 100% yet every time when trying the modern wired keyboards you get no-response from the keys - the best way to ask for feature requests though is at http://jira.reactos.org/secure/Dashboard.jspa and if you want to monitor what's being implemented you can look it up at https://git.reactos.org/?p=reactos.git;a=log this will get some detailed description of the updates.....

[dizt3mp3r]

A great idea for the future as an addition to RAPPS?

[Pi_User5]

Feel free to write this yourself.

[PurpleGurl]

Overall, we should use a strategy similar to Microsoft's. It doesn't have to be compatible since we will never have this connecting to Microsoft for updates. Just as long as things exposed to other software is compatible. Similar is true of System Restore, since if we implement it, it doesn't have to be 100% compatible in the implementation, but it will need compatible APIs for software that calls them.

By strategy, I mean the notion of doing it in package files and upgrading one subsystem or feature per package, and the ability to undo each one. I discussed a different strategy in the past and Z98 and others correctly pointed out that upgrading individual changed files as a whole (much like SFC does) could cause unintended consequences. For instance, maybe one change is compatible with your hardware or configuration, but another change is buggy or breaks things. So you should have the recourse of undoing the set of changes that caused the problems.

However, early on, it might be wise to offer upgrades of everything at once, since there are so many commits. But later, once it matures and the need to code becomes less frequent, that would be the time to do it more the Microsoft way and do it in patch sets that fix only one issue. The team could branch out the component in question, update it, then make it available. Then the update manager applies the patch, gets you to reboot if necessary, and you are on your way.

[erkinalp]

We should implement Windows Update APIs solely to return there are no Windows updates installed. APT and RPM do good job for Linux and jailbroken iOS and rooted Android. They also do dependency resolution and rebootless service upgrade easily. We can use them. APT and dpkg are readily ported for Windows now. Remains to create repository. 3rd parties may also create repositories for software who wish tighter integration and higher performance with ReactOS.

[Konata]

I like package managers like Choco that simply fetch the installer. I absolutely hate "dependency resolution" because that basically boils down to "install every package in the entire repository because shitty developers can't help but depend on as many packages as they can", one of the things I greatly disliked about Linux before ditching it forever. I very much appreciate how Windows does applications and updates. It's a single, isolated thing, and SxS takes care of DLL Hell very nicely, whereas package managers simply have to play a dangerous game of making sure every package is compatible and at the same version at all times, lest the entire package manager/system break (which happens a lot, especially in Arch). It's a terrible idea and a fine example of how literally every decision ever made about Linux was a bad and poorly thought-out one.

Also, I believe it's an unfortunate side-effect of the architecture of Windows NT that causes updates to require a restart. I recall something about every service needing to be restarted, which basically means to just restart the entire system, so I don't think a change in update management would fix that. I don't know if there's a workaround for that, or if ReactOS itself plans to work around that. Maybe a dev on the forums can answer that.

And referring to the image in the OP, a pop-up is a bad idea to notify the user of updates. That was the first thing I turned off in Ubuntu. Again, Windows does a better job of just making use of the notification center and letting you get to it on your own time.

[erkinalp]

I like package managers like Choco that simply fetch the installer. I absolutely hate "dependency resolution" because that basically boils down to "install every package in the entire repository because shitty developers can't help but depend on as many packages as they can", one of the things I greatly disliked about Linux before ditching it forever. I very much appreciate how Windows does applications and updates. It's a single, isolated thing, and SxS takes care of DLL

Package manager can deal with sxs too alongside resolving and installing dependencies. RPM, for example, allows to implement a policy to allow multiple versions of a package, where eeach package may have its own multi-version policy and in case of conflict, latest one's policy applies. SxS does not have to be all-versions always-around way.

Also, I believe it's an unfortunate side-effect of the architecture of Windows NT that causes updates to require a restart. I recall something about every service needing to be restarted, which basically means to just restart the entire system, so I don't think a change in update management would fix that.

Unix services are different, usually restarting one by one suffices for them. However, services.exe may be crafted for hot-restarts.

[hbelusca]

Also, I believe it's an unfortunate side-effect of the architecture of Windows NT that causes updates to require a restart. I recall something about every service needing to be restarted, which basically means to just restart the entire system, so I don't think a change in update management would fix that.

Unix services are different, usually restarting one by one suffices for them. However, services.exe may be crafted for hot-restarts.

Guess what... services (~daemons) can be restarted on Windows too. But obviously, if your update concerns for example the services.exe (the service control manager, ie. who controls the services) itself, then indeed the update will require a restart. (Also, same story for kernel updates).

[erkinalp]

if your update concerns for example the services.exe (the service control manager, ie. who controls the services) itself,

systemd can restart itself without full reboot. It delegates process supervisorship to newly replaced version by a kernel flag(process reaper flag, something possible on *nix) and then jumps to it as the new system supervisor.

[hbelusca]

We can always imagine modifying (most of) the subsystems components of NT (I have in mind the following ones: lsass.exe, services.exe, winlogon.exe, csrss.exe, ...) to be somewhat restartable.

[Z98]

People need to stop proposing that Linux systems and design constructs be somehow repurposed for usage in an operating system that implements the NT architecture. Such proposals go completely against the stated objective of the project since by their very nature they are basically advocating for breaking things in the NT design. If you want Linux behavior, then just use Linux instead of trying to get the developers to bastardize NT. If you think there is a feature that would be nice to have in ReactOS, then come up with a proposal for how to incorporate it that does not require modification of the underlying architecture instead of using examples of how it works on Linux as the standard you want implemented.

[PurpleGurl]

One solution to restarts in terms of drivers has been done starting with Vista, and/or 7. That is including a driver framework which acts a bit like a middleman (not much different from having HAL as opposed to doing things there the Win 9X sort of way), and thus it manages and initializes the drivers. So that makes things more flexible and support PNP devices better. Thus network and sound drivers don't need a reboot.

Now, the issue here is updates. I imagine things could be made to have less restarts, but we still have to remain NT compatible.

[erkinalp]

Less reboots will not recover us in a production server, hence I said rebootless hotpatching and replacement of kernel and service supervisor. In addition, what does winlogon do in service management?

then come up with a proposal for how to incorporate it that does not require modification of the underlying architecture instead of using examples of how it works on Linux

They were, just, examples, as you said. In fact, Linux has a more monolithic architecture than us, where they strive harder to keep the system working. Windows-like OS can make appropriate changes to make hot updates more easily because of componentisation(unfortunately losing parts of compatibility, but not much).
Problem breaks down to three pieces:
1. ReactOS kernel needs to be modified to get able to restart and transfer control of service manager.
2. Subsystems need to be modified in order to be able to be notified by new instance of service manager.
3. Service manager needs to be modified in order to be able to be replaced and delegate to lower tiers of management if necessary.
These three changes will make all service management hot-(even live-)restartable.