Idea for ReactOS about WinRot
Moderator: Moderator Team
Idea for ReactOS about WinRot
Hi,
I'm a new user about ReactOS. I really think this project has chance to become someting great, it could be a chance for entreprises.
Personally, I'm waiting for NTFS support to use it permanently.
May I just suggest an idea ?
The very big problem in Windows is the WinRot :
Every program installed is allowed to copy DLL and registry keys where it wants :
And when it's uninstalled, these keys and DLLs are not always uninstalled.
And after a time, the OS becomes slow, and you need to format and reinstall.
As a programer, I really think that an OS should install each components of programs in separated folders : One program entierly in one folder.
Registry keys should be copied in a file, DLL needed should be copied too...
I think this choice have been made because of the limit of the HDD size, but today this problem does'nt exist anymore.
No external program should be allowed to add files in the system folders.
And in order to uninstall a program, you only need to delete the folder and everything is cleaned.
It could allow to run many versions of a program, in order to compare them, and even many installations of a same version program.
And it could help the system to remain stable.
Microsoft seems to made this choice with Windows 8 and it's API "WinRT", where everything is correctly compartmentalized.
I think it could be a very good point for ReactOS to offer that with the API "Win32".
But It could take time to load the registry if there are files to search in the folder "Program Files"...
I don't know the code of ReactOS, so I don't know if it is possible...
That's just an idea ^^
PS : Sorry for grammar, english is not my mother tongue...
I'm a new user about ReactOS. I really think this project has chance to become someting great, it could be a chance for entreprises.
Personally, I'm waiting for NTFS support to use it permanently.
May I just suggest an idea ?
The very big problem in Windows is the WinRot :
Every program installed is allowed to copy DLL and registry keys where it wants :
And when it's uninstalled, these keys and DLLs are not always uninstalled.
And after a time, the OS becomes slow, and you need to format and reinstall.
As a programer, I really think that an OS should install each components of programs in separated folders : One program entierly in one folder.
Registry keys should be copied in a file, DLL needed should be copied too...
I think this choice have been made because of the limit of the HDD size, but today this problem does'nt exist anymore.
No external program should be allowed to add files in the system folders.
And in order to uninstall a program, you only need to delete the folder and everything is cleaned.
It could allow to run many versions of a program, in order to compare them, and even many installations of a same version program.
And it could help the system to remain stable.
Microsoft seems to made this choice with Windows 8 and it's API "WinRT", where everything is correctly compartmentalized.
I think it could be a very good point for ReactOS to offer that with the API "Win32".
But It could take time to load the registry if there are files to search in the folder "Program Files"...
I don't know the code of ReactOS, so I don't know if it is possible...
That's just an idea ^^
PS : Sorry for grammar, english is not my mother tongue...
Re: Idea for ReactOS about WinRot
Registry is still central with Windows Run Time. It is possible to make it track-and-undo semantics, but I cannot guarantee the lack of suspect on having spies on OS if "magic OS undo", that is, OS tracking installer's actions and creating undo points, happened.Microsoft seems to made this choice with Windows 8 and it's API "WinRT", where everything is correctly compartmentalized.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
Re: Idea for ReactOS about WinRot
WinRT doesn't break with the registry ? Sorry, I ignored, I don't know WinRT API yet.erkinalp wrote:Registry is still central with Windows Run Time. It is possible to make it track-and-undo semantics, but I cannot guarantee the lack of suspect on having spies on OS if "magic OS undo", that is, OS tracking installer's actions and creating undo points, happened.Microsoft seems to made this choice with Windows 8 and it's API "WinRT", where everything is correctly compartmentalized.
A track-and-undo semantics is precisely what I think that could be avoided.
Because of the problem of suspicion, and because of the it's not a good hierarchy for files.
There are already programs like that on Windows, installers that keep a log of installed components, but they all have the same weakness : files and registry keys created after installation are not logged.
We should have :
Program Files\[My_program_name]\Registry.txt => Containing registry keys for this program, and only this program.
Program Files\[My_program_name]\Program Files\[Files of the program]
Program Files\[My_program_name]\Common Files\[Files for the common if there are]
Program Files\[My_program_name]\Windows\[Files for the folder "windows" if there are]
Program Files\[My_program_name]\Windows\System32\[Files for the folder "system32" if there are]
Program Files\[My_program_name]\Windows\Temp\[Temporary files that the program will create]
etc.
And if there are another installation of [My_program_name], we let the user choosing another name or we add a number...
An arborescence for each program, each program would believe it's the one to be installed (except if we notify the opposite, like for antivirus or other programs that needs to read/write on others).
And we could copy each DLL necessary, allowing to create an almost "autonomous pack" [My_program_name] runable from anywhere in the hard drive disk.
The idea is to destroy the very process of an installation / uninstallation, making it useless.
Each old game could integrate old DLLs it needs, no library conflict anymore, no problems of dependancies, etc.
Each program would only needs basic DLL of the OS, drivers and kernel ideally.
But it implies to create a program that load every "Registry.txt" at the start, managing collisions, etc.
I don't know if it's possible, but after a long though, I think it could be the very best FHS to keep the cleanest system.
Re: Idea for ReactOS about WinRot
Side by side assembly. In ReactOS, you'll notice a winsxs folder inside the reactos folder. This is there to prevent dll hell.
In NT6+ this is owned by trusted installer, so even the admin can not by default delete it (at least accidentally).
In NT6+ this is owned by trusted installer, so even the admin can not by default delete it (at least accidentally).
Re: Idea for ReactOS about WinRot
Yes I know, but this is only to prevent DLL hell, not to prevent Winrot.Frontier wrote:Side by side assembly. In ReactOS, you'll notice a winsxs folder inside the reactos folder. This is there to prevent dll hell.
In NT6+ this is owned by trusted installer, so even the admin can not by default delete it (at least accidentally).
I saw a post like mine here :
http://www.reactos.com/forum/viewtopic.php?p=31707
Someone talk about GoboLinux, a Linux distrib that seems to applied my idea. Interesting...
Re: Idea for ReactOS about WinRot
Most registry/file pollution is not created at install time, but at run time of an application. The uninstaller is unaware of what the application has done on the system in its lifetime.
Re: Idea for ReactOS about WinRot
That's what I said.rembrandt wrote:Most registry/file pollution is not created at install time, but at run time of an application. The uninstaller is unaware of what the application has done on the system in its lifetime.
The idea I talk about would solve this problem.
Re: Idea for ReactOS about WinRot
I disagree that would solve it as a clear-cut solution. You'd basically sandbox the application, and as you probably know many applications depend on each other; in my corporate network we use dozens of applications that depend on other components/layers, such as Excel or Outlook, ODBC, Java etc. You'd have to have all the inter-dependent components in the same sandbox, and if you run all those sandboxes on the same system you again have a lot of overhead (multiple instances of Office etc.), and you'd need additional measures such as file deduplication to keep your system lean.Celes wrote:That's what I said.rembrandt wrote:Most registry/file pollution is not created at install time, but at run time of an application. The uninstaller is unaware of what the application has done on the system in its lifetime.
The idea I talk about would solve this problem.
Re: Idea for ReactOS about WinRot
There are 2 types of applications : those which depend on others, and those which don't.rembrandt wrote:I disagree that would solve it as a clear-cut solution. You'd basically sandbox the application, and as you probably know many applications depend on each other; in my corporate network we use dozens of applications that depend on other components/layers, such as Excel or Outlook, ODBC, Java etc. You'd have to have all the inter-dependent components in the same sandbox, and if you run all those sandboxes on the same system you again have a lot of overhead (multiple instances of Office etc.), and you'd need additional measures such as file deduplication to keep your system lean.Celes wrote:That's what I said.rembrandt wrote:Most registry/file pollution is not created at install time, but at run time of an application. The uninstaller is unaware of what the application has done on the system in its lifetime.
The idea I talk about would solve this problem.
Yes, the idea is to sandbox, but to let the choice:
- 1 : To allow communication between applications by settings (right click on application folder and dialog box when search to go out of its sandbox).
- 2 : On the installation, you could choose betwwen a "normal" installation and a "sandbox" installation, this system must be implemented with the previous windows FHS, and must not replace it, for retrocompatibility. It's for programs which doesn't need interactions.
But it's someting complicated, I know. Just an idea in fact, perhaps it's too much to create.
I'm just trying to imagine what the best FHS should be.
Re: Idea for ReactOS about WinRot
IMO to design/implement something would be far more complicated than the reward. And overly confusing for the users. The way we use Windows in the enterprise now is to sandbox application landscapes in virtual environments, and ReactOS would be very suited for that as well. When the lifetime of applications expires, you just destroy the VM's. It's been ages since I last uninstalled an application.Celes wrote: There are 2 types of applications : those which depend on others, and those which don't.
Yes, the idea is to sandbox, but to let the choice:
- 1 : To allow communication between applications by settings (right click on application folder and dialog box when search to go out of its sandbox).
- 2 : On the installation, you could choose betwwen a "normal" installation and a "sandbox" installation, this system must be implemented with the previous windows FHS, and must not replace it, for retrocompatibility. It's for programs which doesn't need interactions.
But it's someting complicated, I know. Just an idea in fact, perhaps it's too much to create.
I'm just trying to imagine what the best FHS should be.
Re: Idea for ReactOS about WinRot
Maybe it's the less worst solution...rembrandt wrote:IMO to design/implement something would be far more complicated than the reward. And overly confusing for the users. The way we use Windows in the enterprise now is to sandbox application landscapes in virtual environments, and ReactOS would be very suited for that as well. When the lifetime of applications expires, you just destroy the VM's. It's been ages since I last uninstalled an application.Celes wrote: There are 2 types of applications : those which depend on others, and those which don't.
Yes, the idea is to sandbox, but to let the choice:
- 1 : To allow communication between applications by settings (right click on application folder and dialog box when search to go out of its sandbox).
- 2 : On the installation, you could choose betwwen a "normal" installation and a "sandbox" installation, this system must be implemented with the previous windows FHS, and must not replace it, for retrocompatibility. It's for programs which doesn't need interactions.
But it's someting complicated, I know. Just an idea in fact, perhaps it's too much to create.
I'm just trying to imagine what the best FHS should be.
Maybe we've to create our own preinstalled packs to prevent Winrot...
Re: Idea for ReactOS about WinRot
btrfs has deduplication, but it degrades performance with automatic deduplication turned on. It makes a 50x performance difference whether you turned on or off.rembrandt wrote:I disagree that would solve it as a clear-cut solution. You'd basically sandbox the application, and as you probably know many applications depend on each other; in my corporate network we use dozens of applications that depend on other components/layers, such as Excel or Outlook, ODBC, Java etc. You'd have to have all the inter-dependent components in the same sandbox, and if you run all those sandboxes on the same system you again have a lot of overhead (multiple instances of Office etc.), and you'd need additional measures such as file deduplication to keep your system lean.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
Re: Idea for ReactOS about WinRot
A long time ago, I was using W98, and I had a program called Arachnophilia by Paul Lutus, a web page development workshop. And Paul had a few gripes, one of which was DLL Hell: at http://www.arachnoid.com/lutusp/dll_article.html.Frontier wrote:Side by side assembly. In ReactOS, you'll notice a winsxs folder inside the reactos folder. This is there to prevent dll hell.
And Paul was preaching almost everything Celes is saying. I know it saved me many hours of sleep when a new install screwed the system: all I had to do was find newest DLL in the \Windows\dll\ list, move it to the new install folder and replace it with with the proper Windows DLL. We have lift-off once more!
But I shouldn't have had to do that... Certainly it would be wonderful if ReactOS could intercept all DLL installs and reroute them back to their proper place!
Gordon.
Re: Idea for ReactOS about WinRot
Ah, someone used and remembers that, still! Ah, Arachnophilia; the nostalgia!gordon451 wrote:A long time ago, I was using W98, and I had a program called Arachnophilia by Paul Lutus, a web page development workshop. And Paul had a few gripes, one of which was DLL Hell: at http://www.arachnoid.com/lutusp/dll_article.html.Frontier wrote:Side by side assembly. In ReactOS, you'll notice a winsxs folder inside the reactos folder. This is there to prevent dll hell.
And Paul was preaching almost everything Celes is saying. I know it saved me many hours of sleep when a new install screwed the system: all I had to do was find newest DLL in the \Windows\dll\ list, move it to the new install folder and replace it with with the proper Windows DLL. We have lift-off once more!
But I shouldn't have had to do that... Certainly it would be wonderful if ReactOS could intercept all DLL installs and reroute them back to their proper place!
Gordon.
Come to think of it, I still have it installed on my PC. The old version (I didn't like his java-version much).
Never had any problems with it, though.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Idea for ReactOS about WinRot
Interestingly, Win 3.x avoided this by having .ini files all over the place. While that didn't have the size overhead of a b-tree database, it did have the overhead of slack space (no file can take up less size than the cluster size). You would still have the remnant problem, but you'd only have it with folders/files and not with the registry. However, the purpose of the registry was to provide a faster way to access the settings and take advantage of caching.
Who is online
Users browsing this forum: No registered users and 1 guest