Hi,
Here is a current update on the 0.2.7 blockers...if you can help, please DO!
BUG: - Green icon in run dialog
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD.
CAUSE: Incorrect icon was added to resource file.
FIXED: Yes. Fix needs to be merged into 0.2.7 branch.
-------------------
BUG: - Common Dialog Control Broken for File/Save.
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669.
CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed.
----------------------
BUG: - If you use the arrow keys in the explorer start menu to expand an entry, you cannot use them anymore to go up and down.
No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code?
---------------------
BUG: - If you right-click on the desktop to show the context menu, then right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore.
No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides.
-------------------
BUG: - Several applications have regressed due to "memory corruption" and a bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
--------------------
BUG: - AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Best Regards, Alex Ionescu
Thanks, I just wanted to look for he status of bhe blockers.
Hmmm, I'll wait anoher days for RC2... There was again just one file changed. Neither did I somehong...so :-/
Alex Ionescu wrote:
Hi,
Here is a current update on the 0.2.7 blockers...if you can help, please DO!
BUG:
- Green icon in run dialog
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD.
CAUSE: Incorrect icon was added to resource file.
FIXED: Yes. Fix needs to be merged into 0.2.7 branch.
BUG:
- Common Dialog Control Broken for File/Save.
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669.
CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed.
BUG:
- If you use the arrow keys in the explorer start menu to expand an
entry, you cannot use them anymore to go up and down.
No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code?
BUG:
- If you right-click on the desktop to show the context menu, then
right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore.
No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides.
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Best Regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
BUG: - If you right-click on the desktop to show the context menu, then right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore.
More information: MOUSE_RIGHT_BUTTON_DOWN/MOUSE_RIGHT_BUTTON_UP events are correctly sent from i8042prt driver to mouclass driver, which sends them correctly to win32k. So the problem is in win32k or above
Here is a patch to see mouse buttons events received by win32k: Index: subsys/win32k/ntuser/input.c =================================================================== --- subsys/win32k/ntuser/input.c (revision 16704) +++ subsys/win32k/ntuser/input.c (working copy) @@ -77,6 +77,19 @@ for(i = 0; i < InputCount; i++) { mid = (Data + i); + if (mid->ButtonFlags & (MOUSE_LEFT_BUTTON_DOWN | MOUSE_LEFT_BUTTON_UP | MOUSE_RIGHT_BUTTON_DOWN | MOUSE_RIGHT_BUTTON_UP)) + { + DPRINT1("{ "); + if (mid->ButtonFlags & MOUSE_LEFT_BUTTON_DOWN) + DbgPrint("MOUSE_LEFT_BUTTON_DOWN "); + if (mid->ButtonFlags & MOUSE_LEFT_BUTTON_UP) + DbgPrint("MOUSE_LEFT_BUTTON_UP "); + if (mid->ButtonFlags & MOUSE_RIGHT_BUTTON_DOWN) + DbgPrint("MOUSE_RIGHT_BUTTON_DOWN "); + if (mid->ButtonFlags & MOUSE_RIGHT_BUTTON_UP) + DbgPrint("MOUSE_RIGHT_BUTTON_UP "); + DbgPrint("}\n"); + } mi.dx += mid->LastX; mi.dy += mid->LastY;
Hervé
2005/7/23, Alex Ionescu ionucu@videotron.ca:
BUG:
- If you use the arrow keys in the explorer start menu to expand an
entry, you cannot use them anymore to go up and down.
No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code?
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Regards,
Martin
Hi Martin,
--- Martin Fuchs fuchs.martin@gmail.com wrote:
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Right. We should have thought of this. In the future we can save time tracking down bugs in explorer and isolating them by testing on Windows and comparing the results to ros.
Thanks Steven
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Martin Fuchs wrote:
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Regards,
Martin
You're right, it works fine on Windows. But I'm not going to let you go so easily ;). Here's something which is in explorer, has been there since 0.2.0 and really bugs me, it's on Windows too... you create the buttons on the task bar too low... they aren't centered, so they are much lower then they should be...and it looks really bad, especially on ReactOS (but on Windows too).
Can you fix that please ? :)
Best regards, Alex Ionescu
Alex Ionescu wrote:
Martin Fuchs wrote:
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Regards,
Martin
You're right, it works fine on Windows. But I'm not going to let you go so easily ;). Here's something which is in explorer, has been there since 0.2.0 and really bugs me, it's on Windows too... you create the buttons on the task bar too low... they aren't centered, so they are much lower then they should be...and it looks really bad, especially on ReactOS (but on Windows too).
Can you fix that please ? :)
Best regards, Alex Ionescu
I'm going to piggyback this with another request :)
When browsing through the start menu and pointing at an item which has further sub-items, it is expanded straight away. This makes the start menu expand everything as the mouse quickly moves across it. It would be nicer to have it as it is in Windows or KDE, etc, whereby the pointer needs to hover over a particular item for around 0.5-1.0 secs before it expands.
Hope that makes sense.
Ged.
Gedi wrote:
Alex Ionescu wrote:
Martin Fuchs wrote:
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Regards,
Martin
You're right, it works fine on Windows. But I'm not going to let you go so easily ;). Here's something which is in explorer, has been there since 0.2.0 and really bugs me, it's on Windows too... you create the buttons on the task bar too low... they aren't centered, so they are much lower then they should be...and it looks really bad, especially on ReactOS (but on Windows too).
Can you fix that please ? :)
Best regards, Alex Ionescu
I'm going to piggyback this with another request :)
When browsing through the start menu and pointing at an item which has further sub-items, it is expanded straight away. This makes the start menu expand everything as the mouse quickly moves across it. It would be nicer to have it as it is in Windows or KDE, etc, whereby the pointer needs to hover over a particular item for around 0.5-1.0 secs before it expands.
Hope that makes sense.
I prefer the instant reaction. If we're going to change it, can we make it configurable, please?
Royce Mitchell III wrote:
I prefer the instant reaction. If we're going to change it, can we make it configurable, please?
The menu behavior (delay of popup menus) can be configured in windows and even disabled, so explorer should use these settings imo. Use SystemParametersInfo with SPI_GETMENUSHOWDELAY to determine the behavior. There are more menu settings you can and should query using the same method.
Best Regards, Thomas
I though ReactOS was supposed to be a Windows-like environment; having said that I think that there should be an option obviously a home user would like those flashy things included, whether they choose to turn them on or off is their choice. Now a developer's machine is about the programming aspects, and cpu cycles would be better spent on code, services, and performance. The way I see it is Windows XP implemented a great feature in letting the user choose using the Advanced Performance Options. Also, let me say, that if a developer chooses to use a lot of services, such as high-end databases used on an e-commerce site the process host should be allocated more memory than say the GUI. Optimization of services is an important factor in choosing a server environment.
I think BeOS also touched on a key feature in isolating each background service. If ReactOS has a bug or a server or service crashed the system should not BSOD instead there should be an auto-restart option that will effect/affect only that process or service. This will allow little downtime especially in a mission critical environment.
Hi guys,
Whats up with all our websites, they all seem to be down? :-/
Grtz, Nick
Yeah, it was hacked, you missed it :)
GvG is on holiday, he'll be back in about a week to fix it
On 27/07/05, Nick Journals nick_journals@hotmail.com wrote:
Hi guys,
Whats up with all our websites, they all seem to be down? :-/
Grtz, Nick
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
--- Royce Mitchell III royce3@ev1.net wrote:
When browsing through the start menu and pointing at an item which has further sub-items, it is expanded straight away. This makes the start menu expand everything as the mouse quickly moves across it. It would be nicer to have it as it is in Windows or KDE, etc, whereby the pointer needs to hover over a particular item for around 0.5-1.0 secs before it expands.
Hope that makes sense.
I prefer the instant reaction. If we're going to change it, can we make it configurable, please?
Yes I prefer instant reaction as well. Microsoft added that stupid fade effect for no other reason than to eat CPU cycles and look flashy. If you don't want the menu to expand.....don't move the mouse there =P.
Or at the very least make it a configurable option so I don't have to waste 0.5-1.0 secs of my life everytime I use the menu. You know those secs from all this eye candy add up over the years.....
Thanks Steven
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Steven Edwards wrote:
Hi,
--- Royce Mitchell III royce3@ev1.net wrote:
When browsing through the start menu and pointing at an item which has further sub-items, it is expanded straight away. This makes the start menu expand everything as the mouse quickly moves across it. It would be nicer to have it as it is in Windows or KDE, etc, whereby the pointer needs to hover over a particular item for around 0.5-1.0 secs before it expands.
Hope that makes sense.
I prefer the instant reaction. If we're going to change it, can we make it configurable, please?
Yes I prefer instant reaction as well. Microsoft added that stupid fade effect for no other reason than to eat CPU cycles and look flashy. If you don't want the menu to expand.....don't move the mouse there =P.
Or at the very least make it a configurable option so I don't have to waste 0.5-1.0 secs of my life everytime I use the menu. You know those secs from all this eye candy add up over the years.....
Thanks Steven
I'm not into all the eye candy stuff either. I'm not sure if we're taking about the same thing here. What I meant was, when you move your mouse up the start menu quickly, everything tries to expand immedietly. This turns the menu into a mad flashing strobe like something out of a prodigy video. Also, when wanting to follow an expanded item, if you drift off with the cursor there is no leeway and you have to start over again. It's sorta like that game at the fair where you have to move the loop around without touching the wire, else you have to start over.
Ged.
FYI the Windows version of explorer uses a button bar, MF's explorer doesn't. Using a button bar would fix a couple of annoyances as far as the taskbar goes.
Alex Ionescu wrote:
Martin Fuchs wrote:
Sorry, I can't reproduce this problem on (MS) Windows. As I currently don't have a working ROS installation - and don't know how to debug such in reasonable time, I don't think I can help you here very much. However I can say, the Explorer start menu and the context menus are not related in any way. I guess this might be a focus handling problem somewhere in the USER32 code handling window creation/keyboard message processing.
Regards,
Martin
You're right, it works fine on Windows. But I'm not going to let you go so easily ;). Here's something which is in explorer, has been there since 0.2.0 and really bugs me, it's on Windows too... you create the buttons on the task bar too low... they aren't centered, so they are much lower then they should be...and it looks really bad, especially on ReactOS (but on Windows too).
Can you fix that please ? :)
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Alex Ionescu wrote:
BUG:
- Common Dialog Control Broken for File/Save.
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669.
CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed.
UPDATE: FIXED. Resolution found by Filip Navara. Awaiting patch.
Best Regards, Alex Ionescu
On 7/23/05, Alex Ionescu ionucu@videotron.ca wrote:
Hi,
Here is a current update on the 0.2.7 blockers...if you can help, please DO!
The keyboard input bug was a blocker too. Luckly i had the email from bugzilla. ----- http://reactos.com/bugzilla/show_bug.cgi?id=657
Summary: Shift sticks when selecting text with the arrow keys. Product: ReactOS Version: 0.3.0-SVN Platform: VMWare 4 OS/Version: ReactOS Status: NEW Severity: major Priority: P3 Component: Drivers AssignedTo: ros-bugs@reactos.com ReportedBy: waxdragon@ameritech.net
VMWare 4.5.2 ReactOS r16251 (this is not a recent bug, I think 15xxx has it)
1. Boot ROS 2. Open notepad 3. Type "This sucks" 4. Press and hold Shift and use the arrow keys to select the previous text (not the numberic keypad*) 5. Type "This sucks" again, notice it is in UPPERCASE and backspace no longer works
* Numlock seems to affect this. I boot vmware with numlock off, and this bug occurs. If turn num lock on before typing, imput works as expected. It's Shift that gets stuck because capslock Shifts them back to lowercase, but the numbers come out as ! @ # $ still. The capslock - arrow keys interaction is also discussed in bug 617 -----
There were some other comments on this bug, basically keycode dumps showing how the arrow keys are emulated my qemu and vmware.
Has anyone seen tinus?
WD
Hi,
--- WaxDragon waxdragon@gmail.com wrote:
The keyboard input bug was a blocker too. Luckly i had the email from bugzilla.
This is a good time to mention this. I would like to propose that we have a regression or (QA) coordinator position in the Constitution. This position is designed with WaxDragon in mind. For those of you that don't know he hangs out on IRC all the time and has been doing a incredible job tracking down regressions and which revisions caused them using ISOs from each build.
The position would entail certain rights and responsibilities:
Finial Authority on blocker bugs for a release (Could be overridden by a vote) Maintains the documentation on testing, hunting regressions, etc Would be the person in charge of directing any testing team that develops. Maintain bugzilla Anything else that we would need a QA person for.
Thoughts?
Thanks Steven
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Steven Edwards wrote:
Hi,
--- WaxDragon waxdragon@gmail.com wrote:
The keyboard input bug was a blocker too. Luckly i had the email from bugzilla.
This is a good time to mention this. I would like to propose that we have a regression or (QA) coordinator position in the Constitution. This position is designed with WaxDragon in mind. For those of you that don't know he hangs out on IRC all the time and has been doing a incredible job tracking down regressions and which revisions caused them using ISOs from each build.
The position would entail certain rights and responsibilities:
Finial Authority on blocker bugs for a release (Could be overridden by a vote) Maintains the documentation on testing, hunting regressions, etc Would be the person in charge of directing any testing team that develops. Maintain bugzilla Anything else that we would need a QA person for.
Thoughts?
Thanks Steven
WaxDragon, Has my vote for Top Test and Release Coordinator. Very Good! James
Same here,
Go Wax
Andrew
On 7/24/05, James Tabor jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net wrote:
Steven Edwards wrote:
Hi,
--- WaxDragon waxdragon@gmail.com wrote:
The keyboard input bug was a blocker too. Luckly i had the email from
bugzilla.
This is a good time to mention this. I would like to propose that we
have a regression or (QA)
coordinator position in the Constitution. This position is designed with
WaxDragon in mind. For
those of you that don't know he hangs out on IRC all the time and has
been doing a incredible job
tracking down regressions and which revisions caused them using ISOs
from each build.
The position would entail certain rights and responsibilities:
Finial Authority on blocker bugs for a release (Could be overridden by a
vote)
Maintains the documentation on testing, hunting regressions, etc Would be the person in charge of directing any testing team that
develops.
Maintain bugzilla Anything else that we would need a QA person for.
Thoughts?
Thanks Steven
WaxDragon, Has my vote for Top Test and Release Coordinator. Very Good! James _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Steven Edwards Sent: 24. juli 2005 17:50 To: WaxDragon; ReactOS Development List Subject: Re: [ros-dev] Blockers...
Hi,
--- WaxDragon waxdragon@gmail.com wrote:
The keyboard input bug was a blocker too. Luckly i had the email from bugzilla.
This is a good time to mention this. I would like to propose that we have a regression or (QA) coordinator position in the Constitution. This position is designed with WaxDragon in mind. For those of you that don't know he hangs out on IRC all the time and has been doing a incredible job tracking down regressions and which revisions caused them using ISOs from each build.
The position would entail certain rights and responsibilities:
Finial Authority on blocker bugs for a release (Could be overridden by a vote) Maintains the documentation on testing, hunting regressions, etc Would be the person in charge of directing any testing team that develops. Maintain bugzilla Anything else that we would need a QA person for.
Thoughts?
Thanks Steven
The constitution is not about team coordinator roles. It's about the decision making process of the project. A description of the organizational structure of ReactOS belong in a separate document that is easier to change.
Casper
Hi Casper,
--- Casper Hornstrup ch@csh-consult.dk wrote:
The constitution is not about team coordinator roles. It's about the decision making process of the project. A description of the organizational structure of ReactOS belong in a separate document that is easier to change.
Works for me. How about WaxDragon in such a role?
Thanks Steven
____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
WaxDragon wrote:
On 7/23/05, Alex Ionescu ionucu@videotron.ca wrote:
Hi,
Here is a current update on the 0.2.7 blockers...if you can help, please DO!
The keyboard input bug was a blocker too. Luckly i had the email from bugzilla.
http://reactos.com/bugzilla/show_bug.cgi?id=657
Summary: Shift sticks when selecting text with the arrow keys. Product: ReactOS Version: 0.3.0-SVN Platform: VMWare 4 OS/Version: ReactOS Status: NEW Severity: major Priority: P3 Component: Drivers AssignedTo: ros-bugs@reactos.com ReportedBy: waxdragon@ameritech.netVMWare 4.5.2 ReactOS r16251 (this is not a recent bug, I think 15xxx has it)
- Boot ROS
- Open notepad
- Type "This sucks"
- Press and hold Shift and use the arrow keys to select the previous text (not
the numberic keypad*) 5. Type "This sucks" again, notice it is in UPPERCASE and backspace no longer works
- Numlock seems to affect this. I boot vmware with numlock off, and this bug
occurs. If turn num lock on before typing, imput works as expected. It's Shift that gets stuck because capslock Shifts them back to lowercase, but the numbers come out as ! @ # $ still. The capslock - arrow keys interaction is also discussed in bug 617
There were some other comments on this bug, basically keycode dumps showing how the arrow keys are emulated my qemu and vmware.
Has anyone seen tinus?
WD
After looking into this I found in win32k/ntuser/keyboard.c. All controls keys in wParam return left key as in VK_LCONTROL, VK_LMENU and VK_LSHIFT. I can not down menu with VK_MENU because wParam is VK_LMENU.
The numlock keys are also translated into, static WORD NumpadConversion[][2] = { { VK_DELETE, VK_DECIMAL }, { VK_INSERT, VK_NUMPAD0 }, { VK_END, VK_NUMPAD1 }, { VK_DOWN, VK_NUMPAD2 }, { VK_NEXT, VK_NUMPAD3 }, { VK_LEFT, VK_NUMPAD4 }, { VK_CLEAR, VK_NUMPAD5 }, { VK_RIGHT, VK_NUMPAD6 }, { VK_HOME, VK_NUMPAD7 }, { VK_UP, VK_NUMPAD8 }, { VK_PRIOR, VK_NUMPAD9 }, this is in W32kKeyProcessMessage. Maybe the bug is in keyboard.c or input.c. Thanks, James
Hi,
the mailing list might not be the best place for this, but blight was so nice to provide his wiki.
http://blight.eu.org/reactos/wiki/index.php/0.2.7
Maarten Bosma
I wanted to add details about te memory corrution bug, but I can't register, the "Create an account"-fields are missing
Hi,
the mailing list might not be the best place for this, but blight was so nice to provide his wiki.
http://blight.eu.org/reactos/wiki/index.php/0.2.7
Maarten Bosma _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Sorry for the delay, i will narrow it down father, which of the 3 rev it is, later today once i get back home from my small vacation.
Brandon
Alex Ionescu writes:
Hi,
Here is a current update on the 0.2.7 blockers...if you can help, please DO!
BUG:
- Green icon in run dialog
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD.
CAUSE: Incorrect icon was added to resource file.
FIXED: Yes. Fix needs to be merged into 0.2.7 branch.
BUG:
- Common Dialog Control Broken for File/Save.
REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669.
CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed.
BUG:
- If you use the arrow keys in the explorer start menu to expand an entry,
you cannot use them anymore to go up and down.
No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code?
BUG:
- If you right-click on the desktop to show the context menu, then
right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore.
No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides.
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Best Regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Alex Ionescu wrote:
As I don't have the wiki password yet, I'm updating this here:
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
Possible patch posted by Hartmut on the ML. Does anyone remember which apps were broken? I'd like to test it.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
Best regards, Alex Ionescu
Alex Ionescu wrote:
Alex Ionescu wrote:
As I don't have the wiki password yet, I'm updating this here:
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
Possible patch posted by Hartmut on the ML. Does anyone remember which apps were broken? I'd like to test it.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
Best regards, Alex Ionescu
Hi! Do you mean NtGdiResizePalette? I do not have a listing in Undoc W2k of a NtGdiRealizePallette. Thanks, James
BTW NtGdiUnrealizeObject is finished, it does nothing more than what I committed to the patch.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/colors_...
James Tabor wrote:
James Tabor wrote:
Hi! Do you mean NtGdiResizePalette? I do not have a listing in Undoc W2k of a NtGdiRealizePallette. Thanks, James
BTW NtGdiUnrealizeObject is finished, it does nothing more than what I committed to the patch.
UserRealizePalette ping! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hi! Richard wrote:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/colors_...
Thanks, I know. 8^D
James Tabor wrote:
James Tabor wrote:
Hi! Do you mean NtGdiResizePalette? I do not have a listing in Undoc W2k of a NtGdiRealizePallette. Thanks, James
BTW NtGdiUnrealizeObject is finished, it does nothing more than what I committed to the patch.
UserRealizePalette ping!
I was in my little way maken a joke. 8^P James
Hi Winrar is one of two apps that have memory corruption bugs that I know of
Quoting Alex Ionescu ionucu@videotron.ca:
Alex Ionescu wrote:
As I don't have the wiki password yet, I'm updating this here:
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
Possible patch posted by Hartmut on the ML. Does anyone remember which apps were broken? I'd like to test it.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Other examples are Dr. Hardware and Total Commander (not always!)
Hi Winrar is one of two apps that have memory corruption bugs that I know of
Quoting Alex Ionescu ionucu@videotron.ca:
Alex Ionescu wrote:
As I don't have the wiki password yet, I'm updating this here:
BUG:
- Several applications have regressed due to "memory corruption" and a
bugcheck related to NtGdiRealizePallette.
More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps.
Possible patch posted by Hartmut on the ML. Does anyone remember which apps were broken? I'd like to test it.
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Alex Ionescu wrote:
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
If the 1st-stage setup is the console setup which copies the files from the cd, it isn't possible that my patch has any effect for this bug. Usetup.exe does only use ntdll.dll. Kernel32.dll isn't loaded at that time.
- Hartmut
I am almost certain i made a mistake when doing the reg testing. I have talked with alex, but i think it was after he sent this out. I dont think it broke on this patch. I think it a few after it. I will get the exact one a little later. Sorry for the confusion and the delay.
Brandon
Hartmut Birr wrote:
Alex Ionescu wrote:
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
If the 1st-stage setup is the console setup which copies the files from the cd, it isn't possible that my patch has any effect for this bug. Usetup.exe does only use ntdll.dll. Kernel32.dll isn't loaded at that time.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Hartmut Birr wrote:
Alex Ionescu wrote:
BUG:
- AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe
others).
REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression.
Regression found by BrandonTurner. Caused by commit 14906: Author: hbirr Fixed the calculation of timeout values.
However, I believe that Hartmut's patch is correct...
If the 1st-stage setup is the console setup which copies the files from the cd, it isn't possible that my patch has any effect for this bug. Usetup.exe does only use ntdll.dll. Kernel32.dll isn't loaded at that time.
- Hartmut
Hi Hartmut,
This confirms what I thought, and also your patch is correct. Brandon told me that he made some mistakes in regression testing, but it was after I posted the email. Sorry.
Best regards, Alex Ionescu