I actually think that the audit will result in even more spectacular compatability displays. The reason for this, is because it forces developers to look at code that "works", but might not be 'correct', since they HAVE to look at it to have it pass the audit. This means that the end implementation will be "More correct", and less "Hackish".
Without the audit, nobody would look at these areas unless something broke because of it. The Audit is beneficial in more ways than simply legal precident.
As for IE7 working, I am quite impressed. It means that more effort should be employed in looking at why the IE7 installer doesnt work. The next thing that would make me say "wow" is having MS flavor DirectX libraries working, and seeing the DxDiag tests going using those libraries.
(Even more impressive would be ReactOS/Wine 'DirectX' libs, supporting the DxDiag tests!)
<Slightly off topic>
When the time comes though, I would like to see certain features able to be simulated with software on the Direct3D side---- It really pisses me off when a game refuses to run when 99% of the features are supported by my GPU, except one. (Like Per-Pixel shading!) I would like to see an option that can be set in the ROS implementation of DX, to "Lie" about the feature set, and "fake it" with the program. Even if the output "looks bad", it is better than "Not running at all."
</Slightly off topic>
Looks like the next big hurdles are going to be in the "System Services" area-- Taking the win32 SMB-TNG port, and running it as a system service would DRAMATICALLY boost the useability of ReactOS.
IE7 works in SVN_0.3
Moderator: Moderator Team
I think the reason the ie7 install would not work is because it has the genuine (dis)advantage that checks for a genuin windows XP or higher, as far as i know you can't install it on windows 2000 either.
On the graphics thing, I completely agree, you should be able to go to varieng degrees of software rendered mode. It would obvesioly get slower the more parts your hardware didn't support but as you say, at least it would run. I wonder would this be more of a graphics card driver thing though?
On the graphics thing, I completely agree, you should be able to go to varieng degrees of software rendered mode. It would obvesioly get slower the more parts your hardware didn't support but as you say, at least it would run. I wonder would this be more of a graphics card driver thing though?
It is my understanding that the D3D featureset is supposed to be supported by the drivers, and that the driver is supposed to "Report" what features it can handle.
If the DirectX libraries that ReactOS writes is able to interperet this data, it could intercede on the user's behalf, to an extent--- Per-Pixel shading can be accomplished with software, or even just ignored, as long as the program THINKS the shading is happening.... Of course, the output may look rather crappy....
The DX library is then the only one that needs to know what the GPU is REALLY capable of, so it can have it do all the work necessary; It can then give a "Lie" to the D3D application, when the application asks for the featureset.
IIRC, there are some tools that do simmilar intercessions allready available.... at least, I think I remember seeing an application that did this.... (It chain loads the D3D application, and then "lies" to it for you.) But it wasnt able to do any software emulation of the missing features.
Some assembly optimized graphics routines that manipulate texture data could simulate per-pixel shading, with varying degrees of success, for instance--- at a performance hit. (In some cases, a decidedly LARGE performance hit, granted, but again, it is better than the application not running at all!) In the end, all that really matters is that the GPU's Driver, and the D3D application are both satisfied with what they are given. Neighther should really be concerned that there was some intermediate manipulation going on, along with some all out lies. ;P As long as both ends get what they expect to get, it should all be good.
If the DirectX libraries that ReactOS writes is able to interperet this data, it could intercede on the user's behalf, to an extent--- Per-Pixel shading can be accomplished with software, or even just ignored, as long as the program THINKS the shading is happening.... Of course, the output may look rather crappy....
The DX library is then the only one that needs to know what the GPU is REALLY capable of, so it can have it do all the work necessary; It can then give a "Lie" to the D3D application, when the application asks for the featureset.
IIRC, there are some tools that do simmilar intercessions allready available.... at least, I think I remember seeing an application that did this.... (It chain loads the D3D application, and then "lies" to it for you.) But it wasnt able to do any software emulation of the missing features.
Some assembly optimized graphics routines that manipulate texture data could simulate per-pixel shading, with varying degrees of success, for instance--- at a performance hit. (In some cases, a decidedly LARGE performance hit, granted, but again, it is better than the application not running at all!) In the end, all that really matters is that the GPU's Driver, and the D3D application are both satisfied with what they are given. Neighther should really be concerned that there was some intermediate manipulation going on, along with some all out lies. ;P As long as both ends get what they expect to get, it should all be good.
-
cmoibenlepro
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
I disagree. It's not beneficial since it has stoped almost all development in the last month, we don't know when it will start again, and it caused that some important developers left the project...I actually think that the audit will result in even more spectacular compatability displays. The reason for this, is because it forces developers to look at code that "works", but might not be 'correct', since they HAVE to look at it to have it pass the audit. This means that the end implementation will be "More correct", and less "Hackish".
Without the audit, nobody would look at these areas unless something broke because of it. The Audit is beneficial in more ways than simply legal precident.
also don't forget that it will remove only the hacks based on dirty sources since the other clean parts (but possibly "hackish" according to your definition) are fast-tracked...
The audit hasn't stopped development, the fact that developers have stopped developing has stopped development.cmoibenlepro wrote: I disagree. It's not beneficial since it has stoped almost all development in the last month, we don't know when it will start again, and it caused that some important developers left the project...
Developers haven't stopped developing due to the audit. The momentum stopped before the audit was put into place.
-
cmoibenlepro
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
Really? If I remember corretly, there were many posts in the mailing lists every days until Harmut said he remove his name from his code...ged wrote:Developers haven't stopped developing due to the audit. The momentum stopped before the audit was put into place.
Then it stopped, the website closed for a week, then it re-opened with the audit and some developers left...
Surely you're right, but it's not what I saw from the outside...
You said it yourself.
Development stopped because of Harmuts mail, not because of the audit.
The audit is just one of the concequences of Harmuts mail and didn't actually start up until about a month after Harmuts mail.
Developers are free to develop again now, so the audit can't be blamed. With the loss of many key devs, motivation has slumped.
Things are slowly being pieced back together, but it's gonna take a lot of work to rally up the enthusiasm we had before Harmuts mail.
The project will get back on it's feet though, It's not gonna die after 8-9 years of hard work.
Development stopped because of Harmuts mail, not because of the audit.
The audit is just one of the concequences of Harmuts mail and didn't actually start up until about a month after Harmuts mail.
Developers are free to develop again now, so the audit can't be blamed. With the loss of many key devs, motivation has slumped.
Things are slowly being pieced back together, but it's gonna take a lot of work to rally up the enthusiasm we had before Harmuts mail.
The project will get back on it's feet though, It's not gonna die after 8-9 years of hard work.
It is my understanding that most of the "Fast Tracked" parts are external libs, and or-- synched code from Wine and other vendor drops. There are some internals to ROS that got fast tracked (like Fireball's USB code, IIRC)--- but much of ReactOS proper has to pass the audit.
The reason for this is again-- Hartmut's mail... which would have come out regardless. The "Audit" didnt really make people leave--- They left either because of the mail, or for their own reasons.
EG-- Steven resigned from PC because he didnt have the time or resources anymore, etc.
In short, the events that led to Hartmut's mail, people leaving, and the subsiquent audit had been brewing for quite a long time under wraps before anyone even thought about saying the word "audit."
Those preceeding events were bad for ReactOS, the Audit itself is not.
The reason for this is again-- Hartmut's mail... which would have come out regardless. The "Audit" didnt really make people leave--- They left either because of the mail, or for their own reasons.
EG-- Steven resigned from PC because he didnt have the time or resources anymore, etc.
In short, the events that led to Hartmut's mail, people leaving, and the subsiquent audit had been brewing for quite a long time under wraps before anyone even thought about saying the word "audit."
Those preceeding events were bad for ReactOS, the Audit itself is not.
-
cmoibenlepro
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
Yes, Autodesk Inventor
Yes, Autodesk Inventor would be really good, then I can soon throw out WindowsXPMike_PSP wrote:What else does anyone want to see hacked in to ReactOS
Im trying to see if i can trick it in to runing WolfET
http://usa.autodesk.com/adsk/servlet/in ... id=7037114
-
mikedep333
- Posts: 167
- Joined: Sat Oct 01, 2005 1:48 am
- Location: United States
Who is online
Users browsing this forum: DotBot [Crawler] and 29 guests