Since this is true and the ros-amd64-bringup tree is up to date with the region and WND code I committed without the assumed fixes to the region leaks in my working tree,,,,,,,,,,, Also to note I was looking for a ghost,,,,, wasting my TIME!,,,,
Is it possible to build ros-amd64-bringup in 32 bit mode?
So,,,,, I can continue my work and commit my updates to head knowing I'm not the FFFf ff uf problem!
FYFI: I just finished a point to point compare and the only differences are kernel changes! Thanks, James
1. Since when ros-amd64-bringup boots to the desktop and works like a charm? It's a major achievement. 2. ros-amd64-bringup tree is merged till r45185, while you made 12 commits to win32k after this, 4 to user32 and 3 to gdi32 (saying "adding experimental code for regions").
WBR, Aleksey.
On Feb 5, 2010, at 10:59 AM, James Tabor wrote:
Since this is true and the ros-amd64-bringup tree is up to date with the region and WND code I committed without the assumed fixes to the region leaks in my working tree,,,,,,,,,,, Also to note I was looking for a ghost,,,,, wasting my TIME!,,,,
Is it possible to build ros-amd64-bringup in 32 bit mode?
So,,,,, I can continue my work and commit my updates to head knowing I'm not the FFFf ff uf problem!
FYFI: I just finished a point to point compare and the only differences are kernel changes! Thanks, James
Timo told me. So it must build in 32 bit mode and boot.
On Fri, Feb 5, 2010 at 3:51 AM, Aleksey Bragin aleksey@reactos.org wrote:
- Since when ros-amd64-bringup boots to the desktop and works like a charm?
It's a major achievement. 2. ros-amd64-bringup tree is merged till r45185, while you made 12 commits to win32k after this, 4 to user32 and 3 to gdi32 (saying "adding experimental code for regions").
WBR, Aleksey.
James Tabor schrieb:
Timo told me. So it must build in 32 bit mode and boot.
Oops my fault, I guess :)
I thought you were joking when talking about the branch. That's why I said it doesn't have the kernel problems of trunk and there is no region leak. Because the 64 bit code it is neither subject to trap handling rewrite and of cause does not boot anywhere near that. I didn't take it as you wanted to use the 32bit compiled version.
It should boot when compiled for 32 bit, but I don't actually know whether the leak is there or not, I didn't check yet.
Timo
You maybe right.
We are still looking into the logs here. The last thing I did and looks like the only commit was late November working on getting Classes fixed. Bug 4980 was filed on the 2nd of December. So this means the leak has been around for a while. FF 3.5 and SM 2.0 comes out about this time too. Remembering back from the Testers paste posts about GDI object crashes during web surfing. At the time, I was busy working on Classes and user32. There was a bug filed about AbiWord with a funny combo box issue when selecting the font type, then isolated it to an ARM3 kernel commit. Remembering again, that was about in June/July when I noticed it after upping and thinking I had done it. After reverting, I knew I was not the one and moved on. I did look to see if one of the wine sync mergers created the leak and I followed the flow and the regions had been deleted. Just glancing through the files......
All: So~ That leak must have been around for a while. We had two releases so my guess is to have the testers have a crack at it and see. But,!!, FF 3.5 and SM 2.0 will not run in those releases....... Best test I have to check, run GDIviewer with wordpad. Running wordpad, select one of the menus and run the mouse over to the next menu and observe the Region count in GDIviewer. GDIviewer can auto refresh so play with it.
Why FF 3.5 and SM 2.0? These are the worse case tests, giving the time to fill up the processes object counts, very fast!
Happy Hunting, James
On Fri, Feb 5, 2010 at 5:46 AM, Timo Kreuzer timo.kreuzer@web.de wrote:
James Tabor schrieb:
Timo told me. So it must build in 32 bit mode and boot.
Oops my fault, I guess :)
I thought you were joking when talking about the branch. That's why I said it doesn't have the kernel problems of trunk and there is no region leak. Because the 64 bit code it is neither subject to trap handling rewrite and of cause does not boot anywhere near that. I didn't take it as you wanted to use the 32bit compiled version.
It should boot when compiled for 32 bit, but I don't actually know whether the leak is there or not, I didn't check yet.
Timo
Besides,,, the leak was in before that so,,,,,, look at bug 4980.
On Fri, Feb 5, 2010 at 3:51 AM, Aleksey Bragin aleksey@reactos.org wrote:
- Since when ros-amd64-bringup boots to the desktop and works like a charm?
It's a major achievement. 2. ros-amd64-bringup tree is merged till r45185, while you made 12 commits to win32k after this, 4 to user32 and 3 to gdi32 (saying "adding experimental code for regions").
WBR, Aleksey.
On Feb 5, 2010, at 10:59 AM, James Tabor wrote:
Since this is true and the ros-amd64-bringup tree is up to date with the region and WND code I committed without the assumed fixes to the region leaks in my working tree,,,,,,,,,,, Also to note I was looking for a ghost,,,,, wasting my TIME!,,,,
Is it possible to build ros-amd64-bringup in 32 bit mode?
So,,,,, I can continue my work and commit my updates to head knowing I'm not the FFFf ff uf problem!
FYFI: I just finished a point to point compare and the only differences are kernel changes! Thanks, James
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
James Tabor -
Timo Kreuzer