Congratulations for 0.3.12!
Moderator: Moderator Team
Congratulations for 0.3.12!
Bravo, people! This is going to be a fascinating Thursday...
Re: Congratulations for 0.3.12!
I second that, and would like to thank Alex Bragin for taking time to post a detailed, but still layman understandable description.
Re: Congratulations for 0.3.12!
well done, but at the frontpage is still shown that the next rls will be the 0.3.12 (at least at the german page)
- EmuandCo
- Developer
- Posts: 4723
- Joined: Sun Nov 28, 2004 7:52 pm
- Location: Germany, Bavaria, Steinfeld
- Contact:
Re: Congratulations for 0.3.12!
Because I did not edit it yet.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
If my post/reply offends or insults you, be sure that you know what sarcasm is...
-
- Posts: 234
- Joined: Sun Sep 17, 2006 3:08 am
- Location: Northeast Ohio, USA
Re: Congratulations for 0.3.12!
So 0.3.12 actually exists? Imagine that.
This means that people have actually played fricken Duke Nukem Forever before this release! XD
This means that people have actually played fricken Duke Nukem Forever before this release! XD
Last edited by Nintendo Maniac 64 on Fri Oct 22, 2010 5:16 am, edited 1 time in total.
Re: Congratulations for 0.3.12!
Congrats!
-
- Posts: 291
- Joined: Wed Jul 25, 2007 10:31 am
Re: Congratulations for 0.3.12!
Great!
I can install it tonight on my laptop in a live version. Next week I am back at home and check it out on my ROS designed PC!
I can install it tonight on my laptop in a live version. Next week I am back at home and check it out on my ROS designed PC!
Re: Congratulations for 0.3.12!
That's excellent news.
Congratulations!
I will test it starting this evening.
Congratulations!
I will test it starting this evening.
Re: Congratulations for 0.3.12!
i wasnt very impressed with 0.3.12 and now i know why,i just discovered a weird vmware bug,if you try to create a video of ReactOS while its running then the download manager locks up and ReactOS becomes very slow and unuseable.
*i am using vmware workstation 6.0.0.45731
*i am using vmware workstation 6.0.0.45731
-
- Posts: 5
- Joined: Tue Nov 20, 2007 11:47 am
Re: Congratulations for 0.3.12!
Well the time is already arrived ReactOS 0.3.12 has been released ...
Congrats ReactOS Team, Keep up the good work
Congrats ReactOS Team, Keep up the good work
Re: Congratulations for 0.3.12!
I haven't tested it yet, but read that ROS now has SXS. I kind of makes me
SXS was introduced as a urgent measure to improve "servicing" (MS Word for bug-fixing).
I can understand that you need Installer to support installation of applications, but why would you need SXS?
If you also implement "servicing", Autoupdates, "Trusted Installers", and limit Administrator's rights, it would be not many reasons left to prefer ROS over XP (unless you are really concerned with DRM).
The answer (if any) would probably be "You are free to make you own fork without SXS".
So, I'm asking ROS developers - please, don't make it too hard to make such fork, and in general, can you encapsulate most of the "modern innovations" and make it easy to exclude them at ROS install?
As an example to clarify what I mean: Virtual PS has plain and simple file structure (you can esily handle it the way you want). Not the same with Hyper-V, where all stuff is shadowed with GUIDs and you are kind of loosing control...
SXS was introduced as a urgent measure to improve "servicing" (MS Word for bug-fixing).
I can understand that you need Installer to support installation of applications, but why would you need SXS?
If you also implement "servicing", Autoupdates, "Trusted Installers", and limit Administrator's rights, it would be not many reasons left to prefer ROS over XP (unless you are really concerned with DRM).
The answer (if any) would probably be "You are free to make you own fork without SXS".
So, I'm asking ROS developers - please, don't make it too hard to make such fork, and in general, can you encapsulate most of the "modern innovations" and make it easy to exclude them at ROS install?
As an example to clarify what I mean: Virtual PS has plain and simple file structure (you can esily handle it the way you want). Not the same with Hyper-V, where all stuff is shadowed with GUIDs and you are kind of loosing control...
Re: Congratulations for 0.3.12!
alexei SXS doesn't sound like a bad thing.
That is if you mean Side-by-side assembly. What this does is help fix the problem of dependency hell.
If you have one application which uses foo.dll version 1 and another that uses foo.dll version 2 which has removed the method void bar() and added void wow(). Only one of these applications could work previously before SXS because they only reference foo.dll not the version. Well SXS fixed this. I want this for the applications that need this. Unless i'm completely wrong.
That is if you mean Side-by-side assembly. What this does is help fix the problem of dependency hell.
If you have one application which uses foo.dll version 1 and another that uses foo.dll version 2 which has removed the method void bar() and added void wow(). Only one of these applications could work previously before SXS because they only reference foo.dll not the version. Well SXS fixed this. I want this for the applications that need this. Unless i'm completely wrong.
Re: Congratulations for 0.3.12!
I think you may be confusing SXS (side by side assemblies) with something else.alexei wrote:I haven't tested it yet, but read that ROS now has SXS. I kind of makes me
SXS was introduced as a urgent measure to improve "servicing" (MS Word for bug-fixing).
I can understand that you need Installer to support installation of applications, but why would you need SXS?
If you also implement "servicing", Autoupdates, "Trusted Installers", and limit Administrator's rights, it would be not many reasons left to prefer ROS over XP (unless you are really concerned with DRM).
The answer (if any) would probably be "You are free to make you own fork without SXS".
So, I'm asking ROS developers - please, don't make it too hard to make such fork, and in general, can you encapsulate most of the "modern innovations" and make it easy to exclude them at ROS install?
As an example to clarify what I mean: Virtual PS has plain and simple file structure (you can esily handle it the way you want). Not the same with Hyper-V, where all stuff is shadowed with GUIDs and you are kind of loosing control...
This must be supported as applications may not work correctly with out it.
Mjmartin
- EmuandCo
- Developer
- Posts: 4723
- Joined: Sun Nov 28, 2004 7:52 pm
- Location: Germany, Bavaria, Steinfeld
- Contact:
Re: Congratulations for 0.3.12!
I dont get your problem too, explain plz.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
If my post/reply offends or insults you, be sure that you know what sarcasm is...
Re: Congratulations for 0.3.12!
Moderators, this discussion is getting off the topic. Please move it to an appropriated forum/thread.
Of course, SXS helps to solve the problem with dependency hell, known as "DLL Hell", but in a way to simplify and automate MS "servicing".
Let's start from the beginning. At first MS recommended to have the latest version of each DLL in System32 making it available for programs system-wide. In theory that was the best approach, but unfortunately MS was unable to keep DLLs backward compatible (though app developers also did "bad" things relying on a specifics they should not). That resulted in application crashes after DLL updates called "DLL Hell". As a kind of workaround MS set a new policy - keep DLLs along with their respective applications. Obviously, that completely fixed the problem (and I think that's the way it should stay).
However, having numerous copies of system DLLs (initially planned to be shared by applications) in numerous application directories created new problem with fixing security holes in them. How would MS updates know what and where to fix?
At some point this problem created significant stress on MS (I remember SQL server security was mentioned). MS had to take an urgent measures to fix it and they decided to use some technology they already had handy. That's how SXS was born.
I believe, it could be solved in a much simpler and backward compatible way and MS just lost common sense in system design there.
In SXS copies of DLLs are stored under wierd names and it becomes really hard to see what's where. Hard links are heavily involved. There is a need for additional files to control DLL loading, etc. This is heavy, bulky, and genarally not very reliable technic created just to simplify MS "servicing". Though with proper manifest files you can still keep "right" DLLs along with their respective application, that's a new hassle from MS you have to deal with.
BTW, it's interesting to note that for sometime already MS steers to unix rules. I mean switching from "encapsulated" applications (where everything the app needs is located in the app directory) to integration of applications into the system (where application's data of different kind is placed to the designated system location). That's the worse thing MS could do to Windows, though they started kind of steer back with virtual registry, etc. Please note, many application developes proudly make their applications portable resisting "unixification".
I understand that ROS developers want all Windows applications run on ROS, but they may want to think about making ROS better then MS produts at least in some respects. Otherwise why would people prefer ROS over MS creations? "GPL" is not not a real reason, unless you have a time and desire to read the sources, make your changes, and keep them up to date". Please remember that decision-makers would hear about ROS from those who tried and liked it, and that would not be a regular PC users, but Windows enthisiasts who (say it softly) dislike "unixification".
Of course, SXS helps to solve the problem with dependency hell, known as "DLL Hell", but in a way to simplify and automate MS "servicing".
Let's start from the beginning. At first MS recommended to have the latest version of each DLL in System32 making it available for programs system-wide. In theory that was the best approach, but unfortunately MS was unable to keep DLLs backward compatible (though app developers also did "bad" things relying on a specifics they should not). That resulted in application crashes after DLL updates called "DLL Hell". As a kind of workaround MS set a new policy - keep DLLs along with their respective applications. Obviously, that completely fixed the problem (and I think that's the way it should stay).
However, having numerous copies of system DLLs (initially planned to be shared by applications) in numerous application directories created new problem with fixing security holes in them. How would MS updates know what and where to fix?
At some point this problem created significant stress on MS (I remember SQL server security was mentioned). MS had to take an urgent measures to fix it and they decided to use some technology they already had handy. That's how SXS was born.
I believe, it could be solved in a much simpler and backward compatible way and MS just lost common sense in system design there.
In SXS copies of DLLs are stored under wierd names and it becomes really hard to see what's where. Hard links are heavily involved. There is a need for additional files to control DLL loading, etc. This is heavy, bulky, and genarally not very reliable technic created just to simplify MS "servicing". Though with proper manifest files you can still keep "right" DLLs along with their respective application, that's a new hassle from MS you have to deal with.
BTW, it's interesting to note that for sometime already MS steers to unix rules. I mean switching from "encapsulated" applications (where everything the app needs is located in the app directory) to integration of applications into the system (where application's data of different kind is placed to the designated system location). That's the worse thing MS could do to Windows, though they started kind of steer back with virtual registry, etc. Please note, many application developes proudly make their applications portable resisting "unixification".
I understand that ROS developers want all Windows applications run on ROS, but they may want to think about making ROS better then MS produts at least in some respects. Otherwise why would people prefer ROS over MS creations? "GPL" is not not a real reason, unless you have a time and desire to read the sources, make your changes, and keep them up to date". Please remember that decision-makers would hear about ROS from those who tried and liked it, and that would not be a regular PC users, but Windows enthisiasts who (say it softly) dislike "unixification".
Who is online
Users browsing this forum: No registered users and 45 guests