Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [cgutman] 41399: - Implement NdisGeneratePartialCancelId

by Aleksey Bragin

On Jun 13, 2009, at 9:25 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sat Jun 13 09:25:54 2009 > New Revision: 41399 > +UCHAR > +EXPORT > +NdisGeneratePartialCancelId(VOID) > +{ > + static UCHAR CancelId = 0; > + > + CancelId++; I don't think using static var for this purpose is a great idea. WBR, Aleksey Bragin.

16 years, 3 months

Re: [ros-dev] Development plans for May

by tamlin＠algonet.se

aicommander wrote: [...] >The main problem with NDIS 5.1 drivers is the lack of S/G support in HAL > (PRO/100 and PRO/1000 XP drivers are affected by this). Could the follwing info from public MSDN help? If so, it seems to be a rather minor hack to make it work: Scatter/gather DMA Scatter/gather DMA is a shortcut method that sets up several packet DMA transfers at once. If you are transferring a packet over the network, for example, each part of the network stack adds its own header (TCP, IP, Ethernet, and so forth). These headers are all allocated from different places in memory. In this case, the scatter/gather DMA saves time by issuing a batch request to the HAL to map each header plus the data segment for access by the hardware. Instead of having to call the packet DMA routines on each part of the packet, this method calls each routine once, and lets the HAL be responsible for mapping each one individually. Note Scatter/gather capability does not mean that the device can use the scatter/gather routines. Scatter/gather capability refers to a flag in the device description that indicates that the device is able to read or write from any area in memory, instead of just a certain range. -------- What I found to be the interesting (and easily hackable) part was "and lets the HAL be responsible for mapping each one individually". -- Mike

16 years, 3 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class

by Ged

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,

16 years, 3 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class

by Ged

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,

16 years, 3 months

Development plans for May

by Aleksey Bragin

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.

16 years, 3 months

Re: [ros-dev] Development plans for May

by Olaf Siejka

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.

16 years, 3 months

Help me test Visual C++ support

by KJK::Hyperion

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!

16 years, 3 months

Help me test Visual C++ support

by KJK::Hyperion

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

16 years, 3 months

Help me test Visual C++ support

by victor martinez

> * 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

16 years, 3 months

Re: [ros-dev] [ros-diffs] [hyperion] 41344: Fix no-op code for UNIX hosts

by Steven Edwards

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

16 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev