Hello, this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even more, for our developers to understand it. The key idea is that our work on the project now MUST be aimed at bugfixing, not at adding even more nice features. There are already quite enough of them (features)!
As I said 1000 times, our general "users" don't care about ability to insert 3 graphic cards into their PC, and get ReactOS using them! They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
Moreover, I don't understand why noone ever bothered to work through the winetests for reactos-specific parts of the system, like GDI, user32/win32k testing, kernel32 testing. There are lots of failures, and wine test results show APIs which are used for REAL, and by REAL applications, not some historic APIs implemented by Magnus (no offence, I'm just using him as an example, please excuse me if I sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in ReactOS way of development of its Win32 subsystem. There were a lot of positive events happening (win32k native tests library, great work by Timo at fixing various small issues, handles, memory leaks, etc). But it must be continued!
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better. The same applies to everywhere, there is no need to have some special skills to improve ReactOS. You know, there are not that many people who *really* worked on win32k in Microsoft, and they obviously can't code for us anyway, so everyone had to learn how to develop one or another part of the system. Look at Stefan Ginsberg - a guy who didn't know anything about C development 3 months ago, but learnt just by reading ros-diffs (well, and constant private messaging me in IRC asking questions, but that doesn't count), and yesterday spotted a couple of important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as strict NT-alike as legally possible, so it takes time to read all available literature), but for Win32-subsystem, just maintaining its code would result in a hundred less crashes now! I don't even say about rewriting bad written parts. Or just simply, very-very simply, syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to concentrate more on bugfixes. We could easily release in the beginning of may, there are enough of good changes for a usual reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate on a boring work first, believe me, there will be lots more fun when amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards, Aleksey Bragin.
Aleksey Bragin schrieb:
Hello, this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even more, for our developers to understand it. The key idea is that our work on the project now MUST be aimed at bugfixing, not at adding even more nice features. There are already quite enough of them (features)!
As I said 1000 times, our general "users" don't care about ability to insert 3 graphic cards into their PC, and get ReactOS using them! They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
Moreover, I don't understand why noone ever bothered to work through the winetests for reactos-specific parts of the system, like GDI, user32/win32k testing, kernel32 testing. There are lots of failures, and wine test results show APIs which are used for REAL, and by REAL applications, not some historic APIs implemented by Magnus (no offence, I'm just using him as an example, please excuse me if I sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in ReactOS way of development of its Win32 subsystem. There were a lot of positive events happening (win32k native tests library, great work by Timo at fixing various small issues, handles, memory leaks, etc). But it must be continued!
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better. The same applies to everywhere, there is no need to have some special skills to improve ReactOS. You know, there are not that many people who *really* worked on win32k in Microsoft, and they obviously can't code for us anyway, so everyone had to learn how to develop one or another part of the system. Look at Stefan Ginsberg - a guy who didn't know anything about C development 3 months ago, but learnt just by reading ros-diffs (well, and constant private messaging me in IRC asking questions, but that doesn't count), and yesterday spotted a couple of important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as strict NT-alike as legally possible, so it takes time to read all available literature), but for Win32-subsystem, just maintaining its code would result in a hundred less crashes now! I don't even say about rewriting bad written parts. Or just simply, very-very simply, syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to concentrate more on bugfixes. We could easily release in the beginning of may, there are enough of good changes for a usual reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate on a boring work first, believe me, there will be lots more fun when amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I think concentrating to new Features is a good idea, but as long as ReactOS hangs on 2/3 of tries to install it, these should go into some branches. As long as ROS is unstable the main concentration should be in fixing the bugs which cause the instability. I more than second Aleksey's Mail. I got a mail from a guy some minutes ago which clearly shows, what ppl want and expect:
Are you a programmer on the ReactOS team? If yes, can you explain why Reactos can not be run or installed? I keep reading use Vbox, also, is Reactos dos? The most important question I have is, is the base stable and it's more about getting the apps made for windows working on ReactOS?
I answered him with the same nice argument we all use all the time: Its Alpha etcetc blablabla.
Aleksey Bragin wrote:
I especially delay the 0.3.5 release, because I want people to concentrate more on bugfixes
And if no beta this year, I'm sorry to say, but it may be too late.
I couldn't agree more.
The development process of ReactOS has always been 'work on whatever you want', however I don't think this is a viable method any longer. This method leads people to work on pretty useless stuff, and only partially finish other stuff.
At this stage, the important stuff is bug fixing important core components. There's little point in having 5% of directx running if 95% of Windows applications don't run. It's the core components which 3rd party software heavily relies on to run. Ignoring these components is damaging to ReactOS as it will hugely prolong the time span to Beta, and possibly lead to eventual failure to ever become stable and mainstream,. As Aleksey said, if people focused in bugfixing and other important stuff, we could hit beta this year ... I just don't see that happening with the current development model.
I therefore propose that a tighter leash needs to be kept on development, and how this should work needs careful consideration. This doesn't and shouldn't move towards some sort of commercial dictatorship, but I do think a small amount of fun needs to be traded in for some proper organization. If the project wants to start becoming serious, it needs to start acting a little more serious in its development cycle.
One idea I had was to have focus days, whereby a component is chosen, lets say user32, and everyone spends time bugfixing that. Brownie points are handed out to the person with the most, or best fix. Another idea to try to keep the fun is to everyone to pick an application from a list and see who can get it running first.
However, these are just some fun and game ideas, not to be confused with the fact that ReactOS needs to start getting tougher and what people should and shouldn't be working on. When ReactOS works, the world will adopt it, avenues of work and money will flow!!
Regards, Ged.
Hi,
I mostly agree with the ideas developed in that mail. I've just a problem with one of them. Make bugfixing a priority before implementing new features is a great idea; it could avoid some really bad releases such as ReactOS 0.3.4. BUT asking people to learn how some Windows parts works in order to fix bugs is a bad idea. In my opinion, fixing bug is easier when the dev know code on which he is working especially when it looks like Win32k subsystem. Other way, it's easier to implement bug than fixing them...
So, we should focus our work on fixing bugs in branches of the OS we're working on usually and not trying to learn how something works to fix bug whereas there's a hundred times more skilled developer working on. We should keep the "you work on what you like" motto. I'd like also add something that always made uneasy. I don't know how you, others devs, are working, but I really don't understand why build can be broken after a patch. It should be tested (so build!) before being committed. Committing a patch that broke build shows a lack of tests and potentials bugs.
About "And if no beta this year, I'm sorry to say, but it may be too late.", I'm afraid to say I agree. But we aim to make a WinXP OS like or WinXP is about to be retired by Microsoft to leave Vista taking his place. And in my opinion, copying dead OS have no sense. So, indeed, we should hurry, and that leads to the last point I wanted to speak about. We don't have enough devs. Getting new and skilled ones should be really great for us... That's really hard to find!
Anyway, until 0.3.5 comes out, I'll try (as far as I can code) to fix bugs I'll find.
Aleksey, do not give up!
Best regards, P. Schweitzer.
-------------------------------------------------- From: "Aleksey Bragin" aleksey@reactos.org Sent: Thursday, May 08, 2008 3:46 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: [ros-dev] Time has come, a call to developers
Hello, this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even more, for our developers to understand it. The key idea is that our work on the project now MUST be aimed at bugfixing, not at adding even more nice features. There are already quite enough of them (features)!
As I said 1000 times, our general "users" don't care about ability to insert 3 graphic cards into their PC, and get ReactOS using them! They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
Moreover, I don't understand why noone ever bothered to work through the winetests for reactos-specific parts of the system, like GDI, user32/win32k testing, kernel32 testing. There are lots of failures, and wine test results show APIs which are used for REAL, and by REAL applications, not some historic APIs implemented by Magnus (no offence, I'm just using him as an example, please excuse me if I sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in ReactOS way of development of its Win32 subsystem. There were a lot of positive events happening (win32k native tests library, great work by Timo at fixing various small issues, handles, memory leaks, etc). But it must be continued!
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better. The same applies to everywhere, there is no need to have some special skills to improve ReactOS. You know, there are not that many people who *really* worked on win32k in Microsoft, and they obviously can't code for us anyway, so everyone had to learn how to develop one or another part of the system. Look at Stefan Ginsberg - a guy who didn't know anything about C development 3 months ago, but learnt just by reading ros-diffs (well, and constant private messaging me in IRC asking questions, but that doesn't count), and yesterday spotted a couple of important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as strict NT-alike as legally possible, so it takes time to read all available literature), but for Win32-subsystem, just maintaining its code would result in a hundred less crashes now! I don't even say about rewriting bad written parts. Or just simply, very-very simply, syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to concentrate more on bugfixes. We could easily release in the beginning of may, there are enough of good changes for a usual reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate on a boring work first, believe me, there will be lots more fun when amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I don't mean to sound harsh, but any dev should be able to fix bugs in most parts of the OS without knowing how it works. This is especially true in usermode, if a dev can't fix usermode bugs, then they shouldn't have commit access in the first place.
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Heis Spiter Sent: 08 May 2008 20:43 To: ReactOS Development List Subject: Re: [ros-dev] Time has come, a call to developers
Hi,
I mostly agree with the ideas developed in that mail. I've just a problem with one of them. Make bugfixing a priority before implementing new features
is a great idea; it could avoid some really bad releases such as ReactOS 0.3.4. BUT asking people to learn how some Windows parts works in order to fix bugs is a bad idea. In my opinion, fixing bug is easier when the dev know code on which he is working especially when it looks like Win32k subsystem. Other way, it's easier to implement bug than fixing them...
So, we should focus our work on fixing bugs in branches of the OS we're working on usually and not trying to learn how something works to fix bug whereas there's a hundred times more skilled developer working on. We should
keep the "you work on what you like" motto. I'd like also add something that always made uneasy. I don't know how you, others devs, are working, but I really don't understand why build can be broken after a patch. It should be tested (so build!) before being committed. Committing a patch that broke build shows a lack of tests and potentials bugs.
About "And if no beta this year, I'm sorry to say, but it may be too late.",
I'm afraid to say I agree. But we aim to make a WinXP OS like or WinXP is about to be retired by Microsoft to leave Vista taking his place. And in my opinion, copying dead OS have no sense. So, indeed, we should hurry, and that leads to the last point I wanted to speak about. We don't have enough devs. Getting new and skilled ones should be really great for us... That's really hard to find!
Anyway, until 0.3.5 comes out, I'll try (as far as I can code) to fix bugs I'll find.
Aleksey, do not give up!
Best regards, P. Schweitzer.
-------------------------------------------------- From: "Aleksey Bragin" aleksey@reactos.org Sent: Thursday, May 08, 2008 3:46 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: [ros-dev] Time has come, a call to developers
Hello, this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even more, for our developers to understand it. The key idea is that our work on the project now MUST be aimed at bugfixing, not at adding even more nice features. There are already quite enough of them (features)!
As I said 1000 times, our general "users" don't care about ability to insert 3 graphic cards into their PC, and get ReactOS using them! They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
Moreover, I don't understand why noone ever bothered to work through the winetests for reactos-specific parts of the system, like GDI, user32/win32k testing, kernel32 testing. There are lots of failures, and wine test results show APIs which are used for REAL, and by REAL applications, not some historic APIs implemented by Magnus (no offence, I'm just using him as an example, please excuse me if I sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in ReactOS way of development of its Win32 subsystem. There were a lot of positive events happening (win32k native tests library, great work by Timo at fixing various small issues, handles, memory leaks, etc). But it must be continued!
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better. The same applies to everywhere, there is no need to have some special skills to improve ReactOS. You know, there are not that many people who *really* worked on win32k in Microsoft, and they obviously can't code for us anyway, so everyone had to learn how to develop one or another part of the system. Look at Stefan Ginsberg - a guy who didn't know anything about C development 3 months ago, but learnt just by reading ros-diffs (well, and constant private messaging me in IRC asking questions, but that doesn't count), and yesterday spotted a couple of important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as strict NT-alike as legally possible, so it takes time to read all available literature), but for Win32-subsystem, just maintaining its code would result in a hundred less crashes now! I don't even say about rewriting bad written parts. Or just simply, very-very simply, syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to concentrate more on bugfixes. We could easily release in the beginning of may, there are enough of good changes for a usual reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate on a boring work first, believe me, there will be lots more fun when amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Actually I didn't tell that any housewife could become a president (or however the saying tells). I told that in order to try to find and fix bugs, nothing extraordinary is needed, except brain and C syntax knowledge. Everything else in source code, in open form. The committer (who already has experience with reactos, by definition) reviews such a patch, and notices problems if it improper fix.
What Ged said also underlines the idea.
Every part of the OS may have its own complex points, but one must not miss the most important thing: you have access to everything. ReactOS is made from whatever you checkout as trunk/reactos, and there are no hidden, closed parts.
Another example is that many things could have been done and tested in Windows when ReactOS was not ready enough yet, but that's another story, about the history. But let's talk about the future. The future we can change. The history is the history.
WBR, Aleksey Bragin.
On May 8, 2008, at 11:52 PM, gedmurphy wrote:
I don't mean to sound harsh, but any dev should be able to fix bugs in most parts of the OS without knowing how it works. This is especially true in usermode, if a dev can't fix usermode bugs, then they shouldn't have commit access in the first place.
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev- bounces@reactos.org] On Behalf Of Heis Spiter Sent: 08 May 2008 20:43 To: ReactOS Development List Subject: Re: [ros-dev] Time has come, a call to developers
Hi,
I mostly agree with the ideas developed in that mail. I've just a problem with one of them. Make bugfixing a priority before implementing new features
is a great idea; it could avoid some really bad releases such as ReactOS 0.3.4. BUT asking people to learn how some Windows parts works in order to fix bugs is a bad idea. In my opinion, fixing bug is easier when the dev know code on which he is working especially when it looks like Win32k subsystem. Other way, it's easier to implement bug than fixing them...
So, we should focus our work on fixing bugs in branches of the OS we're working on usually and not trying to learn how something works to fix bug whereas there's a hundred times more skilled developer working on. We should
keep the "you work on what you like" motto. I'd like also add something that always made uneasy. I don't know how you, others devs, are working, but I really don't understand why build can be broken after a patch. It should be tested (so build!) before being committed. Committing a patch that broke build shows a lack of tests and potentials bugs.
About "And if no beta this year, I'm sorry to say, but it may be too late.",
I'm afraid to say I agree. But we aim to make a WinXP OS like or WinXP is about to be retired by Microsoft to leave Vista taking his place. And in my opinion, copying dead OS have no sense. So, indeed, we should hurry, and that leads to the last point I wanted to speak about. We don't have enough devs. Getting new and skilled ones should be really great for us... That's really hard to find!
Anyway, until 0.3.5 comes out, I'll try (as far as I can code) to fix bugs I'll find.
Aleksey, do not give up!
Best regards, P. Schweitzer.
Hi!
On Thu, May 8, 2008 at 8:46 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Its was a fix idea that would include the addition of support for more than one display device. Why stop at a NEAR DO WELL fix when it would fix the rest of the install display device issues. Just one days work, it would have taken~ Lack of power has issued a HALT instruction waiting for power on interrupt..
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better.
Okay,,,,, Hax (wine) aside,,, Can we do this in small testing steps? I just thought of it, can we download the viewers for Office 2003: Word, Excel and Office 2007 Powerpoint and test them? I have Office 2003 and do not have time to fuction with CD issues but instead copy the viewer Exe install files to the ros install cd. This would manage the testing better, if anyone is reading this. After this, we can test the big one after cleaning up the small ones. I have ID'ed one hax by m$ and it lite my fuse! That noone has brought this up with the USDOJ TC. If you dont know, Dont ask.
With the best regards, Aleksey Bragin.
Thanks, James
My two cents:
You guys shouldn't even release 0.3.5 until *all* Winetests give the same results as testing on WinXP/2003.
I've never understood why such critical/useful tests have always been ignored -- I remember fixing a lot of the ntdll regressions (thousands of them) and it took me less than a week. Mostly looking at Wine code and looking for bugs in functions that were being tested.
On Fri, May 9, 2008 at 5:44 AM, James Tabor jimtabor.rosdev@gmail.com wrote:
Hi!
On Thu, May 8, 2008 at 8:46 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,this message is inspired by a lot of thinking, and yesterdays talk in #reactos, when Magnus Olsen's proposition to add support for more than one graphic adapter was a last drop into my cup of tolerancy.
Its was a fix idea that would include the addition of support for more than one display device. Why stop at a NEAR DO WELL fix when it would fix the rest of the install display device issues. Just one days work, it would have taken~ Lack of power has issued a HALT instruction waiting for power on interrupt..
Ged Murphy said very right about the problem: small problems prevent big apps from working. Wine already supports Office 2003 for years, and noone except me was trying to make support it better.
Okay,,,,, Hax (wine) aside,,, Can we do this in small testing steps? I just thought of it, can we download the viewers for Office 2003: Word, Excel and Office 2007 Powerpoint and test them? I have Office 2003 and do not have time to fuction with CD issues but instead copy the viewer Exe install files to the ros install cd. This would manage the testing better, if anyone is reading this. After this, we can test the big one after cleaning up the small ones. I have ID'ed one hax by m$ and it lite my fuse! That noone has brought this up with the USDOJ TC. If you dont know, Dont ask.
With the best regards, Aleksey Bragin.
Thanks, James _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi! Good advice worth more than a few cents!
Wow! I'm still using wine tests for this rewrite. It's hard work and going over my notes I see the use one test for over a year. Yes that DCE thing! The way we use it hasn't changed and we still do not pass all the tests. I haven't over looked anything. I'm still working on gdi handle management and this will fix the issue but adds more questions. What is published is not correct based on what is evident points of discovery.
Thanks, James
Ref: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/win32k/ntgd...
On Fri, May 9, 2008 at 6:59 PM, Alex Ionescu ionucu@videotron.ca wrote:
My two cents:
You guys shouldn't even release 0.3.5 until *all* Winetests give the same results as testing on WinXP/2003.
I've never understood why such critical/useful tests have always been ignored -- I remember fixing a lot of the ntdll regressions (thousands of them) and it took me less than a week. Mostly looking at Wine code and looking for bugs in functions that were being tested.
Hi CreateBitmap inside gdi32.dll should not leak any handle now when you trying create a bitmap with CreateBitmap(0,0,x,x,x); it is a GetStockObject(21) we getting back with this call and that mean we do not need delete it etiher, this should take care of few gdi handle leaks we have with some program I did implemeted it in win32k now this object it is 1x1 1bpp Bitmap you getting back. we still have bug on the syscall part for NtGdiCreateBitmap if I fix thuse bugs we breaking downtotop bitmap support, it seam something miss use CreateBitmap or or NtGdiCreateBitmap or IntGdiCreateBitmap in reactos I was force remove the correct bugfix for IntGdiCreateBitmap until we figout who does send down negtive with or height that is forbien todo that in NtGdiCreateBitmap and CreateBitmap and IntGdiCreateBitmap.
----- Original Message ----- From: "James Tabor" jimtabor.rosdev@gmail.com To: "ReactOS Development List" ros-dev@reactos.org Sent: Saturday, May 10, 2008 9:13 PM Subject: Re: [ros-dev] Time has come, a call to developers
Hi! Good advice worth more than a few cents!
Wow! I'm still using wine tests for this rewrite. It's hard work and going over my notes I see the use one test for over a year. Yes that DCE thing! The way we use it hasn't changed and we still do not pass all the tests. I haven't over looked anything. I'm still working on gdi handle management and this will fix the issue but adds more questions. What is published is not correct based on what is evident points of discovery.
Thanks, James
Ref: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/win32k/ntgd...
On Fri, May 9, 2008 at 6:59 PM, Alex Ionescu ionucu@videotron.ca wrote:
My two cents:
You guys shouldn't even release 0.3.5 until *all* Winetests give the same results as testing on WinXP/2003.
I've never understood why such critical/useful tests have always been ignored -- I remember fixing a lot of the ntdll regressions (thousands of them) and it took me less than a week. Mostly looking at Wine code and looking for bugs in functions that were being tested.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Fri, May 9, 2008 at 7:59 PM, Alex Ionescu ionucu@videotron.ca wrote:
You guys shouldn't even release 0.3.5 until *all* Winetests give the same results as testing on WinXP/2003.
Also the Wine developer who works on MSI, James Hawkins has been busting his chops to make sure all of the Wine tests past on WinXP/2003. The test suite is getting pretty close, I think the failure rate is around 10%. If you guys manage to get networking working on ReactOS for the tests and not have the system crash then you can even use the latest mingw build of the framework from here
http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe
And have it report to http://test.winehq.org. The Wine team has not raised an objection to having ReactOS report there as long as your reports are clearly marked so they don't get confused with other platforms.
Hi!
On Thu, May 8, 2008 at 8:46 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
I've tried to install wdviewer.exe (Word viewer for Office 2003), here are results.
err:(dll/win32/advapi32/service/sctrl.c:243) CreateFileW() failed (Error 231) fixme:(dll/win32/comdlg32/filedlg.c:256) Flags 0x00800000 not yet implemented (subsystems/win32/win32k/ntuser/message.c:1207) Attempted to post message to window 0x30104 that is being destroyed! fixme:(dll/win32/imm32/imm.c:802) (-1): stub fixme:(dll/win32/msxml3/domdoc.c:67) interface {6d5140c1-7436-11ce-8034-00aa006009fa} not implemented (subsystems/win32/win32k/ntuser/window.c:1538) FIXME - Parent is HWND_MESSAGE fixme:(dll/win32/msxml3/domdoc.c:67) interface {79eac9e4-baf9-11ce-8c82-00aa004ba90b} not implemented fixme:(dll/win32/rpcrt4/ndr_marshall.c:6456) (301C9A08, 301C9608, 1024, 0x0): stub err:(dll/win32/advapi32/service/scm.c:1427) ROpenServiceW() failed (Error 1060) fixme:(dll/win32/rpcrt4/ndr_marshall.c:6456) (301C9A08, 301C9608, 1024, 0x0): stub
pause
fixme:(dll/win32/msxml3/main.c:39) err:(dll/win32/msi/package.c:830) (subsystems/win32/win32k/objects/gdiobj.c:721) Attempted to free global gdi handle 0xb70801d9, caller needs to get ownership first!!! (subsystems/win32/win32k/objects/gdiobj.c:722) Type = 0xb808, KernelData = 0x000001CD, ProcessId = 0x00000000 failed to copy package L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\WORDVIEW.MSI" fixme:(dll/win32/msi/database.c:146) open failed r = 80030003 for L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\WORDVIEW.MSI"
Hum? It looks to me that wine does not work,,, well look where it crashed! Are you sure you are talking about cross over and not wine?
On Sun, May 11, 2008 at 12:22 AM, James Tabor jimtabor.rosdev@gmail.com wrote:
Hum? It looks to me that wine does not work,,, well look where it crashed! Are you sure you are talking about cross over and not wine?
I think it should work, I know several of the viewers can be installed under stock Wine, there is a tool called winetricks Dan Kegel publishes to make installing extra Microsoft packages like the viewers less of a pain, so you might want to check that script and see which versions work.
Really it seems to have some error inside RPC (openservice, 1060 error, etc). Similar to a full MS Office 2003 installation package, it behaves similar way. Then after pause (when it tries to do an RPC connect, but fails at last),
(subsystems/win32/win32k/objects/gdiobj.c:722) Type = 0xb808, KernelData = 0x000001CD, ProcessId = 0x00000000
our favorite one, with messed up KernelData pointer (which gets filled by something incorrectly, or is not initialized, or whatever).
fixme:(dll/win32/msi/database.c:146) open failed r = 80030003 for L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\ \WORDVIEW.MSI"
this one, 80030003 is STG_E_PATHNOTFOUND, so it couldn't open this file for some reason.
Hum? It looks to me that wine does not work,,, well look where it crashed! Are you sure you are talking about cross over and not wine?
It looks to me that ReactOS doesn't work :-)
WBR, Aleksey Bragin.
On May 11, 2008, at 8:22 AM, James Tabor wrote:
Hi!
On Thu, May 8, 2008 at 8:46 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,They care about ReactOS crashing after closing regedit. Or during Office 2003 installation. And if it continues to crash this way, I'm sorry, but noone could feel the pleasure of multiple graphic cards support, or any other feature which is useless for 99% of potential users.
I've tried to install wdviewer.exe (Word viewer for Office 2003), here are results.
err:(dll/win32/advapi32/service/sctrl.c:243) CreateFileW() failed (Error 231) fixme:(dll/win32/comdlg32/filedlg.c:256) Flags 0x00800000 not yet implemented (subsystems/win32/win32k/ntuser/message.c:1207) Attempted to post message to window 0x30104 that is being destroyed! fixme:(dll/win32/imm32/imm.c:802) (-1): stub fixme:(dll/win32/msxml3/domdoc.c:67) interface {6d5140c1-7436-11ce-8034-00aa006009fa} not implemented (subsystems/win32/win32k/ntuser/window.c:1538) FIXME - Parent is HWND_MESSAGE fixme:(dll/win32/msxml3/domdoc.c:67) interface {79eac9e4-baf9-11ce-8c82-00aa004ba90b} not implemented fixme:(dll/win32/rpcrt4/ndr_marshall.c:6456) (301C9A08, 301C9608, 1024, 0x0): stub err:(dll/win32/advapi32/service/scm.c:1427) ROpenServiceW() failed (Error 1060) fixme:(dll/win32/rpcrt4/ndr_marshall.c:6456) (301C9A08, 301C9608, 1024, 0x0): stub
pause
fixme:(dll/win32/msxml3/main.c:39) err:(dll/win32/msi/package.c:830) (subsystems/win32/win32k/objects/gdiobj.c:721) Attempted to free global gdi handle 0xb70801d9, caller needs to get ownership first!!! (subsystems/win32/win32k/objects/gdiobj.c:722) Type = 0xb808, KernelData = 0x000001CD, ProcessId = 0x00000000 failed to copy package L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\ \WORDVIEW.MSI" fixme:(dll/win32/msi/database.c:146) open failed r = 80030003 for L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\ \WORDVIEW.MSI"
Hum? It looks to me that wine does not work,,, well look where it crashed! Are you sure you are talking about cross over and not wine? _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
On Sun, May 11, 2008 at 5:22 AM, Aleksey Bragin aleksey@reactos.org wrote:
Really it seems to have some error inside RPC (openservice, 1060 error, etc). Similar to a full MS Office 2003 installation package, it behaves similar way. Then after pause (when it tries to do an RPC connect, but fails at last),
(subsystems/win32/win32k/objects/gdiobj.c:722) Type = 0xb808, KernelData = 0x000001CD, ProcessId = 0x00000000
our favorite one, with messed up KernelData pointer (which gets filled by something incorrectly, or is not initialized, or whatever).
RPC that's wine right? GDI? Yes, as it seems to be one of the things I'm working on ATM.
fixme:(dll/win32/msi/database.c:146) open failed r = 80030003 for L"C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\IXP001.TMP\ \WORDVIEW.MSI"
this one, 80030003 is STG_E_PATHNOTFOUND, so it couldn't open this file for some reason.
Hum? It looks to me that wine does not work,,, well look where it crashed! Are you sure you are talking about cross over and not wine?
It looks to me that ReactOS doesn't work :-)
WBR, Aleksey Bragin.
Still looks like wine problems, MSI? RPC? Are those both from wine?
Look~! I'm working on this for free and I can think of a nice Alex'ism but no lets not go there.
8^)
-
Aleksey Bragin -
Alex Ionescu -
Daniel Reimer -
gedmurphy -
Heis Spiter -
James Tabor -
Magnus Olsen -
Steven Edwards