Ros-dev June 2009

ros-dev@reactos.org

24 participants
36 discussions

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
by Ged 12 Jun '09

12 Jun '09

Ok, I've just read the actual code for NtSetInformationProcess (probably should have done that first) It's right, what threw me was your r41390 commit which contained this : + PriorityClass.PriorityClass = PROCESS_PRIORITY_CLASS_HIGH; + PriorityClass.Foreground = FALSE; + + /* Set priority for process */ + if (!NT_SUCCESS(NtSetInformationProcess(ProcessInfo.ProcessHandle, + ProcessPriorityClass, + &PriorityClass, + sizeof(PROCESS_PRIORITY_CLASS)))) + { + DPRINT1("Unable to set process priority for winlogon.exe\n"); + } I assumed from reading this that our NtSetInformationProcess was setting process priorities via #defines. It turns out that the above is actually wrong. From pstypes.h : #define PROCESS_PRIORITY_CLASS_HIGH 3 You were setting winlogon to have a priority of 3. Clearly not right ... heh. Anyway, I see you've reverted it now. Problem solved. I was just writing this follow up so you didn't start looking into NtSetInformationProcess and scratching your head wondering what my previous mail was about Ged. -----Original Message----- From: Ged [mailto:gedmurphy@gmail.com] Sent: 12 June 2009 18:48 To: 'ros-dev(a)reactos.org' Subject: RE: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Hi This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high. Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes. IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this. Is it our implementation or my memory which is wrong ? Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 12 June 2009 16:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Author: dchapyshev Date: Fri Jun 12 19:41:26 2009 New Revision: 41389 URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev Log: - Start services.exe and lsass.exe with above normal priority class Modified: trunk/reactos/base/system/winlogon/winlogon.c Modified: trunk/reactos/base/system/winlogon/winlogon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo… ============================================================================== --- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original) +++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009 @@ -49,7 +49,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo, @@ -97,7 +97,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo,

1 0

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
by Ged 12 Jun '09

12 Jun '09

Hi This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high. Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes. IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this. Is it our implementation or my memory which is wrong ? Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org Sent: 12 June 2009 16:41 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class Author: dchapyshev Date: Fri Jun 12 19:41:26 2009 New Revision: 41389 URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev Log: - Start services.exe and lsass.exe with above normal priority class Modified: trunk/reactos/base/system/winlogon/winlogon.c Modified: trunk/reactos/base/system/winlogon/winlogon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo… ============================================================================== --- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original) +++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009 @@ -49,7 +49,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo, @@ -97,7 +97,7 @@ NULL, NULL, FALSE, - DETACHED_PROCESS, + DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS, NULL, NULL, &StartupInfo,

1 0

Development plans for May
by Aleksey Bragin 12 Jun '09

12 Jun '09

Hi, as we earlier discussed, there is an idea to make 0.3.10 a "hardware- compatibility" release. There is a full list of 0.3.10 milestones bugs linked from our roadmap page, but here are some possible directions for work: - USB support for keyboard and mouse devices. Right now, it needs fixing the rare crash during booting (bug is bugzilled, comment explaining how to solve the problem is attached, some investigation remains), and more testing on real hardware. - Uniata support: it solves many problems at once, such as a stupid 8Gb limit which is a nonsense for a 2009-year operating system, and Serial ATA support, which greatly enhances possible ReactOS usability (along with the first item of this list). I use it in my builds everyday for more than a month, it works very good. Problems: VirtualBox CDROM support (it doesn't recognize it), on my realhardware it also experiences similar problems. Bug is also bugzilled, a lot of debug logs attached, so everyone can participate. - Common NICs support: Cameron is doing great work, testers too. There are some outstanding problems, which you can see from http:// www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards - Sound support: Johannes knows best, but getting any progress with sound by 0.3.10 release date is greatly appreciated. - Videocards support: Olaf performs some tesitng and bugreporting. Third party drivers support is rather weak, http://www.reactos.org/ wiki/index.php/Supported_Hardware/Video_cards , and usually is limited by VMWare's video driver which is being one of the most supported through the ReactOS development history. Besides of that, Olaf is organizing the Golden Apps testing, so that we won't discover regressions occasionally or by the time the release is branched and everyone is awaiting, but instead that's going to happen on a periodical basis, and he's going to manage this process with help of our fellow testers. Target 0.3.10 release date is month from now on - that means, somewhere in the end of May. Certainly, if our goals aren't met, the release is going to be rescheduled and that's it, but, I'd like to ask to concentrate on the above problems first. They are hard to solve when every problem is being approached by one person, but with a common effort they aren't going to be a problem. Any new developers - welcome! There are very definite goals, enough of information, so please feel free to join and help. With the best regards, Aleksey Bragin.

5 5

Re: [ros-dev] Development plans for May
by Olaf Siejka 11 Jun '09

11 Jun '09

As for Videocards, it seems that our situation is not as bad as it was perceived before. Its not perfect, of course. - currently i can name at least 3 cards working on my ReactOS PC with native XP drivers: ATI Rage II+, Matrox G100 and Matrox G400. With considerable cerainty i can say that all Matrox models inbetween or bit newer than afforementioned model range will also be working, as they are using same driver package; - all vesa 2.0 videocards i tested are working correctly with our VESA driver. Only single cases have issues here; We still have a number of bugs in this area, for your consideration: - lack of VESA 1.2 support: this locks up older PCI cards, like whole S3 family (up to savage) to VGA driver. Only workaround is to use native XP drivers. It succeeded with S3 Trio 64, but uncovered another bug listed belo; (bug no.4447) - if XP video driver is installed (by slipstreaming into bootcd) on installation with VGA driver selected in 1st stage, even though XP driver is loaded, the system will be locked to VGA mode (640x480x4bpp unchangeable). This one is not yet submitted as it needs to be confirmed by other tester first; - VGA driver, if picked in 1st stage, jumps back to VESA on 3rd stage boot. This can be rigged away by replacing VESA driver with vga driver files, leaving the filenames of the former (bug no. - Some Windows VGA drivers will cause ASSERT in Videoprt. In many cases this ASSERT may be cont-ed without any visible side-effect, yet it requires more attention (bug no.4354); - our opengl setup requires only specific opengl setup (bug no. 4574); - Matrox G400 opengl ICD is not cooperating well with our opengl32.dll (fails when DrvDescribePixelFormat is called from the icd), requires more attention and a way to instert breakpoint within ReactOS to an dll that has not been loaded yet, namely a working debugger like Olly); I am also preparing to create a support page for I/O controllers, as soon as i get some components for a few entries.

1 0

Help me test Visual C++ support
by KJK::Hyperion 10 Jun '09

10 Jun '09

As of r41374, Visual C++ suppport in rbuild is almost fully functional (PCH and full dependencies - i.e. rbuild -df - won't work yet. Also, the Microsoft linker is not supported yet). All I need now is people working to make sources compile with it. How to: add option -Mcmsc to variable ROS_RBUILDFLAGS: set ROS_RBUILDFLAGS=%ROS_RBUILDFLAGS% -Mcmsc and build modules! make --keep-going will be very useful for the time being. Now start fixing shit, for the love of god! go go go!

1 0

Help me test Visual C++ support
by KJK::Hyperion 08 Jun '09

08 Jun '09

So you want to make Visual C++ building support a reality. Good. Do you have Visual Studio, Visual C++ Express or any flavor of the DDK? Do you have trunk checked out and updated? Even better. Do the following from a RosBE prompt: * del makefile.auto * set ROS_RBUILDFLAGS=-Mmicrosoft * make rbuild and reply to this message with: * what version of Visual Studio, Visual C++ Express or the DDK you installed * the output of the "[RBUILD] makefile.auto" phase To clean up and resume building as usual: * del makefile.auto * set ROS_RBUILDFLAGS= Thank you

7 6

Help me test Visual C++ support
by victor martinez 08 Jun '09

08 Jun '09

> * what version of Visual Studio, Visual C++ Express or the DDK you > installed Microsoft Visual Studio 2005 Version 8.0.50727.867 (vsvista.050727-8600) > * the output of the "[RBUILD] makefile.auto" phase [RBUILD] makefile.auto Reading build files...done Detecting compiler...detected (cl 14.0.50727.762) Detecting binutils...detected (link 8.0.50727.762) Detecting netwide assembler...detected (nasm 2.05.01) Detecting compiler pre-compiled header support...disabled Processing modules...done Creating directories...done Generating test support code...done Generating compilation unit support code...done Generating syssetup.inf...done Generating proxy makefiles...done Checking automatic dependencies...done Regards, Victor. _________________________________________________________________ Descubre todas las formas en que puedes estar en contacto con amigos y familiares. http://www.microsoft.com/windows/windowslive/default.aspx

1 0

Re: [ros-dev] [ros-diffs] [hyperion] 41344: Fix no-op code for UNIX hosts
by Steven Edwards 08 Jun '09

08 Jun '09

On Sun, Jun 7, 2009 at 7:39 PM, <hyperion(a)svn.reactos.org> wrote: > +#include "../../pch.h" This is really minor but can you fix it by changing the -I path? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

Re: [ros-dev] [ros-diffs] [hyperion] 41343: modified tools/rbuild/backend/mingw/mingw.cpp modified tools/rbuild/backend/mingw/mingw.h From now on, the MinGW back-end will also support the Microsoft command line C/C++ compiler (cl) and incremental linker (link)
by Steven Edwards 08 Jun '09

08 Jun '09

On Sun, Jun 7, 2009 at 7:33 PM, <hyperion(a)svn.reactos.org> wrote: > +#include "../../pch.h" Ditto for here. > + > +// TODO? attempt to support Microsoft tools on non-Windows? > +#if !defined(WIN32) > + > +bool > +MingwBackend::DetectMicrosoftCompiler ( std::string& ) > +{ > + return false; > +} There are some crazy people that run cl under Wine. I know older versions such as the vctoolkit worked. I'm not sure about more recent revs. I'm happy to try to make time to look in to this at some point. It would be nice for us Linux and OS X users to be able to verify things from time to time with msvc without needing a fullblown vm. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Old Code in User32
by James Tabor 05 Jun '09

05 Jun '09

Hi all! I noticed we still have drawing issues even after fixing some gdi code. Well, I guess we need to look at the main windowing side of the house now. I guess, based on a stable release we can sync up wine and patch by hand the forked code too. I know of some Delphi issues that could use a good non static update. Bulk of our user code is from wine and that includes the window positioning bug everyone has had a crack at as well. I notices that most of the syncs in comdlg/controls depend on user code updates. If Richedit breaks windowing, it could be related to user32/win32k code not updated or based on behavior that is wrong. Syncing and updating forked code is not fun, with both, one needs to take into account local fixes. When you find them, mark them like "REACTOS HACK" or "REACTOS ONLY" or "REACTOS ????" what ever. Reading the change logs for each file should help with determining local patches that have been applied and need to be taken into account as well. If you have a bug report, please mark it as WINE SYNC or WINE UPDATE, something to let us know, it's a wine sync of some kind. We have a file in our media doc directory that holds the sync/fork information, please include it with your updates. Thanks, James Ref: README.WINE: User32 - reactos/dll/win32/user32/controls/button.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/combo.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/edit.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/icontitle.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/listbox.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/controls/scrollbar.c # Forked reactos/dll/win32/user32/controls/static.c # Synced at 20071024 reactos/dll/win32/user32/misc/dde.c # Synced to wine 1.1.17 (dde_misc.c) reactos/dll/win32/user32/misc/ddeclient.c # Synced to wine 1.1.17 reactos/dll/win32/user32/misc/ddeserver.c # Synced to wine 1.1.17 reactos/dll/win32/user32/misc/exticon.c # Last sync date unknown reactos/dll/win32/user32/misc/resources.c # Forked? reactos/dll/win32/user32/misc/winhelp.c # Last sync date unknown reactos/dll/win32/user32/misc/wsprintf.c # Synced to Wine-1_1_13 reactos/dll/win32/user32/windows/defwnd.c # Forked reactos/dll/win32/user32/windows/draw.c # Forked at Wine-20020904 (uitools.c) reactos/dll/win32/user32/windows/mdi.c # Synced at 20060703 reactos/dll/win32/user32/windows/menu.c # Forked reactos/dll/win32/user32/windows/messagebox.c # Forked reactos/dll/win32/user32/windows/rect.c # Forked (uitools.c) reactos/dll/win32/user32/windows/text.c # Forked (lstr.c) reactos/dll/win32/user32/windows/winpos.c # Forked

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev June 2009