ReactOS Update

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

ReactOS Update

Post by naums »

Hey there.

I like ReactOS very much, well you might know that already. I'm testing the newest revisions of ReactOS but it sucks, that I have to install the new revision again, and the next again... that's just ... ass. So how about a 'ReactOS Update' (like Windows Update, yeah, pretty innovative, I know), so the users don't have to install their ReactOSes over and over again? If you do that don't copy the Windows Update but do it the linux-way. (choose whether stable or backports something like that) :)

I hope I'm helping you guys.

MfG Naums

gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Re: ReactOS Update

Post by gabrielilardi »

You can update without formatting if you want, as for your question, see this topic.

Pisarz
Posts: 375
Joined: Sat May 12, 2007 9:29 am

Re: ReactOS Update

Post by Pisarz »

There is no need for update system until ReactOS is in beta stage.
Last edited by Pisarz on Wed Jun 29, 2011 7:37 pm, edited 2 times in total.

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: ReactOS Update

Post by naums »

RoS is in Alpha-stage right now. Well maybe it's not needed right now, but what's done is done :). And reinstalling (and even updating Ros in first stage of installation) sucks ;)

MfG Naums

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: ReactOS Update

Post by PurpleGurl »

Pisarz wrote:There is no need for update system until ReactOS is in beta stage.
Yes, I'd love to see a Reactos Update. Something like Windows Update, but not copying all the mistakes, duplicates, file bloat, registry bloat, etc. Just query the involved files for their checksums and replace what doesn't match, and any prerequisite files, and then just replace what needs replaced. In a number of ways, the Win98 way wasn't as complicated and bloaty as the XP way. But at least this is one of those areas where we could take liberties, since it is pretty much impossible to provide full compatibility with MS, and only MS and a handful of system management tools would need that.

The biggest issue is getting it to where everyone can install their network drivers, run installers, etc., and be able to get online. Right now, most of us have to upgrade manually using another OS which can go online. Once most users can get online, that would be the time to start on that, IMHO.

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Re: ReactOS Update

Post by Haos »

Yes sure, make something as complicated, as update for Windows system and make it perfect out of the box. I must say I am pretty tired of certain legends being made popular by general repeating. First of all, i hate when someone is using the word "bloat", defined as "something i never used and have no idea what is it for". Ignorance should never be used as an argument.
Something like Windows Update, but not copying all the mistakes, duplicates, file bloat, registry bloat, etc.
Excuse me, but are you by any mean qualified to distinguish "bloat" from something that is there for a reason? Can you name at least one thing which is not necessary in WU and explain why it is "bloat"? Can you point us any mistake?
Just query the involved files for their checksums and replace what doesn't match, and any prerequisite files, and then just replace what needs replaced.
Had you a thorough look through windows update process, you would certainly notice that it is doing precisely what you are describing above, plus several safeguards.
In a number of ways, the Win98 way wasn't as complicated and bloaty as the XP way.
Win 3.11 was not as complicated and "bloaty" as Win98. If you look for less "bloat", why dont get back to DOS or even typing machine code commands?
But at least this is one of those areas where we could take liberties, since it is pretty much impossible to provide full compatibility with MS, and only MS and a handful of system management tools would need that.
As we should copy only good desings, i think that WU will be something to seriously look into.

dmex
Posts: 1
Joined: Sun Apr 10, 2011 10:41 pm

Re: ReactOS Update

Post by dmex »

An updater for ReactOS would be handy, IMO it would probably be easier to be a bootable image that runs outside of the installation. Downloading/Updating of the core files while keeping configuration points and also able to still run if an update was corrupted or if the latest update was broken would be really good.
Something like Windows Update, but not copying all the mistakes, duplicates, file bloat, registry bloat, etc. Just query the involved files for their checksums and replace what doesn't match, and any prerequisite files, and then just replace what needs replaced.
Windows Update is a COM component (single dll, registered as a COM component via the registry), It downloads a file called 'Wsusscn2.cab' which contains a xml schema and signature for each available patch (some details can be found here: http://support.microsoft.com/kb/927745).

WU will then check for the existence of the listed package and does a signature check, if found its installed and skipped for update else listed as new and displayed for download.

WU then utilizes the BITS service to initiate downloading of the update, once completed it moves the original files into SxS (or backup folder), begins the install using the File and Registry Transaction API's and lastly saves the package in its cache.

AFAIK, Step 1 is checking, Step 2 is installing, Step 3 is veryfying.

This is done so a patch for say ntoskrnl.exe doesn't fail in such a way that the file used for booting is not corrupted. The way Windows Update worked before Vista was horribly unreliable and every patch did it's own things in it's own way and this is not good for numerous reasons.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: ReactOS Update

Post by PurpleGurl »

Haos wrote:Yes sure, make something as complicated, as update for Windows system and make it perfect out of the box. I must say I am pretty tired of certain legends being made popular by general repeating. First of all, i hate when someone is using the word "bloat", defined as "something i never used and have no idea what is it for". Ignorance should never be used as an argument.
Something like Windows Update, but not copying all the mistakes, duplicates, file bloat, registry bloat, etc.
Excuse me, but are you by any mean qualified to distinguish "bloat" from something that is there for a reason? Can you name at least one thing which is not necessary in WU and explain why it is "bloat"? Can you point us any mistake?
Just query the involved files for their checksums and replace what doesn't match, and any prerequisite files, and then just replace what needs replaced.
Had you a thorough look through windows update process, you would certainly notice that it is doing precisely what you are describing above, plus several safeguards.
In a number of ways, the Win98 way wasn't as complicated and bloaty as the XP way.
Win 3.11 was not as complicated and "bloaty" as Win98. If you look for less "bloat", why dont get back to DOS or even typing machine code commands?
But at least this is one of those areas where we could take liberties, since it is pretty much impossible to provide full compatibility with MS, and only MS and a handful of system management tools would need that.
As we should copy only good desings, i think that WU will be something to seriously look into.
What I said was all in the hypothetical. But have you actually observed the behavior of WU? I am a power user and have done manually registry and file clearings, so I know what needs to be there, and what is optional. I haven't done a "suicidal reduction" of windows files like a couple of guys I read of. They had a Windows file deletion contest to see whose machine crashed first. But they gained valuable information during their exercise of frivolity.

As a power user and PC builder, even professionally for a time, I define bloat a whole lot differently than the stereotype you have of those who use the term.

I don't have to justify my statements, but probably can, though maybe not to the extent you ask. For instance, there is no easy way to clean up after known successful upgrades (though maybe we shouldn't make that easy in case there are incompatibilities the user doesn't catch until later). So I delete the backup folders manually and then remove all references to those locations from the registry. I did the registry cleanup using one of the few registry tools I trust from personal experience. I once tried many. For most people, they should heed Mark R's advice (Microsoft Developer, formerly SysInternals) and leave such program's alone.

Back on track, I have seen the bulk of registry keys and how it recognizes updates as sets. Personally, I think tracking them as individual files might be more efficient. You could do that in the registry, but you could just as easily create a CRC list on the Reactos site and have a client side application to get the CRCs of the files and replace the ones that don't match the official ones (unless overrides are set, like if you have a personally patched file for some reason). That would double as not only upgrading, but recovering from corruption (viruses, replacements in ignorance, drive trouble), thus doing the jobs of Reactos Update and SFC in one. As long as we keep the distributions light this would not be too much trouble. For site load issues, you could have it to where first, the app downloads the official manifest with the checksums and files. The it would check the files on the system against the list (consuming no Reactos.org server resources during the comparisons). Then the updater requests the files that need replacing/updating, perhaps zipping them first if that would help server load and placing them on the user's system. I guess some sort of backup could be done just in case the new files are not compatible with the specific machine.

Okay, I just talked my way through why Windows does it as it does. Doing it my way is probably fine as I test it out in my mind, but I see the shortcomings. If you treat it as individual files then what if there are incremental upgrades? Sure the MS method would take up more bandwidth in that scenario, since files overwrite files that overwrite other files, so in the middle, there would be duplicate work. But, if only one upgrade set is bad, you can just remove the one. It is a complicated, tangled, mess, but it is a better fail safe system. Mine would be fine I am sure, but if an incompatible upgrade is installed and you don't know which one it was, well, you may be forced to manually copy everything from the backup folder in a safe command line mode, or reinstalling (and possibly hosing things again the next update, or finding the next stable version doesn't work on that hardware at all). So as bulky as the MS way is, it does allow for partial upgrades better. The MS way could cause the same files to get downloaded multiple times (in different revisions), but that is necessary if you need things in an intermediate state. Plus my proposed method could be more likely in rare cases to cause incompatible and untested file combinations, since things would be upgraded by the file rather than the set. As for the registry stuff, if you have all the backups split into sets in different folders, then it does make sense to tell the Install/Remove code what the stuff is and where it is. So it is a lot of stuff, but I think the package approach requires that if something goes wrong.

So we could do things more efficiently, but not necessarily better nor safer. MS probably had a similar discussion and decided on what they felt was the best balance and decided on the package approach over the individual file approach. Yes, both use a checksum system, but in different ways. Mine would be to check EVERY file on the system in a vacuum and then request the individual files (maybe in an an on the fly generated package). Theirs is more like deciding what packages to download.

Yes, I understand your "sliding slope" logic well. Windows 3.1 had no updater per se. Updates came on diskettes. As for MS-DOS, you either used the updater with the new version, or you would Sys the drive, copy command.com over (on an earlier version since 5.0+ sys.com made sure that not only io.sys and msdos.sys got copied, but command.com too), then copy the system command utilities to the DOS directory. I tended to prefer hand upgrading DOS where possible. But I won't go back to using Edlin and Debug. LOL!!! I've coded that way before, and I remember using Debug for loading controller card code. G=c800:ccc for some, and g=c800:5 with others (assuming XP compatible card, AT compatible MFM or RLL card would be at segment CC00). I am surprised I remember that far back! I was in another thread telling someone about the keyboard IO ports, but since I never coded for protection mode, I didn't realize that didn't apply to ring 3.

One problem I had with Windows Upgrade for 95 was that it wasn't that thorough. I mean, there were a number of necessary fixes that you wouldn't get unless you searched MS-KB for the problem in question. Of course, they addressed those issues by 98SE. I was hit with one of those bugs. I built a 500 Mhz AMD system (socket 7) and 95 wouldn't load. I accidentally discovered the cause. I assumed wrongly that running it without the proper heat sink was the problem. That was an issue, but not the first issue I should have encountered. So to be safe, I rejumpered it to 300 Mhz and it worked. Then I bought a proper cooler and still could not run at full speed. So I searched all over for the cause online using a search engine, and guess where it took me? Microsoft. I found there was a MS patch designed for AMD systems running over 300 Mhz. So I installed it, rejumpered it, and booted back up at 500 Mhz. Then when I upgraded to 98, they already included the kernel processor timing fix.

So thank you for getting me to examine the issue more fully and think a little more like a developer. You are right that we should at least consider MS behavior and figure out why they did things as they did before dismissing them. Sure, this is an area where we can never have 100% compatibility, since obviously, we won't call home to Microsoft for updates (and if we could, they would plug that hole quickly), and our exact files and the relationships between them would probably be different (since we will probably never be 100% sure what is inside the MS files as far as how they relate to each other). So the issue is not breaking compatibility, since fundamentally, it is an area where full compatibility is impossible, though we probably could shim it a bit for the few programs which get into the versions and all, though what is the point? I mean, if I ran Belarc Advisor on it, what would it tell me to install? And where would it go for the "missing files"? Microsoft? It might not even run at all, either due to error or realizing it is not truly 2K/XP/etc. If worse comes to worse, we could add that type of stuff to our internal incompatibility list. Or, if we gain traction, we could get some manufacturers to test for our OS (even if just to provide a graceful refusal should we run their code). So how close do we go being that it is not reasonable to attempt full compatibility to WU with RU.

(Sorry if I am babbling....time for bed.)

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Re: ReactOS Update

Post by Haos »

I do find Mark Russinovich advices most accurate. Registry cleanup programs often do more hard than good.

Backup folders as you call it, are left for a reason. Most likely you'd need them for update reverting/uninstall.

One could argue if file checksum would be more efficient than registry. I suppose using registry is a standard practice for MS in such circumstances, perhaps this is also an issue of backward-compatibility. Using WU for live consistency checking is not such a good idea when you consider potential drawbacks and issues it may cause. Live patching of system files is not an uncommon practice, so any unasked attempt at recovery of a failed checksum file could be potentialy a fatal one for system. There are tools dedicated for this purpose, like SFC.

MS with its current Windows userbase cannot let itself proceed with any revolutionary move. This is why backward-compatibility is such a sought value and any changes are in most cases evolutionary.

PurpleGurl
Posts: 1788
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: ReactOS Update

Post by PurpleGurl »

Haos wrote:I do find Mark Russinovich advices most accurate. Registry cleanup programs often do more hard than good.

Backup folders as you call it, are left for a reason. Most likely you'd need them for update reverting/uninstall.

One could argue if file checksum would be more efficient than registry. I suppose using registry is a standard practice for MS in such circumstances, perhaps this is also an issue of backward-compatibility. Using WU for live consistency checking is not such a good idea when you consider potential drawbacks and issues it may cause. Live patching of system files is not an uncommon practice, so any unasked attempt at recovery of a failed checksum file could be potentialy a fatal one for system. There are tools dedicated for this purpose, like SFC.

MS with its current Windows userbase cannot let itself proceed with any revolutionary move. This is why backward-compatibility is such a sought value and any changes are in most cases evolutionary.
In not so many words, I think we are saying the same thing, and I must agree with you. I tried playing out the 2 scenarios in my mind and concluded the same.

I don't think I communicated the checksum file idea right. I was meaning for the Reactos server to have a list of the CRCs for the latest of all the files. The updater would download it and then compare it against the installed files, then ask for the ones not matching. It could even have codes in it or the filename to make sure it is not corrupted (by a connection problem or flaw), though, I see a serious problem even there. Malicious software and deliberate acts of sabotage.

I will continue the other discussion in a more appropriate area.
http://www.reactos.org/forum/viewtopic.php?f=13&t=9387

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: ReactOS Update

Post by naums »

Well... PurpleGurl: I just lost track. I think ReactOS Update would be very nice. I think I would just make an svn or something or have the user download an exe (with the Update Manager) that installes the needed files itself. But the Exe will be very big afterall. The Single-Files thing you said would be working, but you would have to update ALL the files and not just one or two. Because maybe the one DLL needs the second and so an... until a function isn't declared and PANG! system crash. :D

I guess the MS way is failsafe, because MS does it every time so, that the user can't possibly do something wrong. But I would appreciate to make an option either download the "stable releases (0.3.13)" or the current revision. And with the Application Manager it would be possible to update the software installed on the system (at least the free ones) automaticly like the Linux apt-get or rpm or pisi or something. ;) I think that is the worst thing about Windows.

MfG Naums

User avatar
EmuandCo
Developer
Posts: 4439
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: ReactOS Update

Post by EmuandCo »

You just said it yourself. Until so much changes in so many files happen daily, we don't need an updater
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: ReactOS Update

Post by naums »

'Until'... so you will need it anyway some time. Why not writing it now and rewriting it in the future, because that is pretty much what is done here. :)

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: ReactOS Update

Post by Z98 »

As you are not likely the person who would need to commit the time and effort to build a first iteration of an update system, I'm trying to decide whether you're being flippant or outright disrespectful.

naums
Posts: 275
Joined: Sun Feb 21, 2010 9:12 pm
Location: Milkau, Germany
Contact:

Re: ReactOS Update

Post by naums »

I just go on everyones nerves. ;) Well I would not get an working Update Service, but I wanna do the welcome Screen (exe on BootCD). Whether I will do this is out of the question, but I wanna.

Addition: if you don't want me to write Feedback nor suggestions, so don't have this section in your forums.

MfG Naums

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 3 guests