Ros-dev

ros-dev@reactos.org

5788 discussions

by Hartmut Birr

Hi, since some time, I'm not able to install ReactOS on real hardware. Freeldr fails at the first boot after the second stage setup. The error message is 'Couldn't open CodePage registry key'. I've add some debug messages to freeldr. Freeldr isn't able to open the key '\Registry\Machine\SYSTEM\CurrentControlSet'. If I rename umpnpmgr.exe between usetup and the second stage setup, ReactOS boots without any problems. If I rename umpnpmgr.exe back, ReactOS fails on the second boot with umpnpmgr.exe. - Hartmut

19 years, 2 months

Where to commit?

by Brandon Turner

I have interesting in working on the following programs: C:\WINDOWS\system32\tree.exe C:\WINDOWS\system32\gettype.exe(win2k3) C:\WINDOWS\system32\findstr.exe C:\WINDOWS\system32\w32tm.exe and if I'm feeling extra fiesty maybe C:\WINDOWS\system32\osk.exe Now my question is where i should put these, rospapps or maybe reactos\subsys\system\ ? Brandon

19 years, 2 months

[ros-dev] RE:[blight] 19008: Implement (Int)EngAlphaBlend and 8, 16, 24 and 32 bpp DIB AlphaBlend functions. AlphaBlend()should work now.

by Ge van Geldorp

> From: blight(a)svn.reactos.com > > Implement (Int)EngAlphaBlend and 8, 16, 24 and 32 bpp DIB > AlphaBlend functions. AlphaBlend() should work now. Great work. Not sure if you realized it, but this helps Firefox a lot. Screenshot with these changes applied: http://www.reactos.nl/pics/ff2.png (the "before" screenshot is at http://www.reactos.nl/pics/ff1.png see the difference in the toolbars) Thanks again, Gé.

19 years, 2 months

NPFS problems

by Ge van Geldorp

After changes r18883/r18912 umpnpmgr.exe (and eventlog.exe) don't start anymore. The problem is that they try to connect to the service control manager using a named pipe (advapi32/service/sctrl.c function ScConnectControlPipe). Before opening the pipe, a call is made to WaitNamedPipe() to see if the pipe exists. This call currently fails, resulting in failure of ScConnectControlPipe(), resulting in failure of umpnpmgr.exe, resulting in network drivers not being installed, resulting in no network connectivity. WaitNamedPipe() NtOpenFile()s the pipe and then issues a FSCTL_PIPE_WAIT ioctl. The problem is that this end of the pipe is now connected to the server end (which is already listening) during the call to NtOpenFile() (in function NpfsCreate(), setting the PipeStatus to FILE_PIPE_CONNECTED_STATE. NpfsWaitPipe first checks the PipeStatus and bails out if it's not 0 (passive waiting state). So, in our case NpfsWaitPipe fails, 'cause the pipe is already connected. The patch below just makes NpfsWaitPipe return success in case it's already connected, which solves the umpnpmgr problem. However, I don't think it's the correct solution, after the FSCTL_PIPE_WAIT ioctl returns WaitNamedPipe() will close its end, so the server end sees an unexpected close. I have no clue how to proceed, and to be honest I'm not interested in solving it myself. I'd rather see the author of the original patch take his responsibility and fix the regression he introduced. GvG.

19 years, 2 months

Re: [ros-svn] [blight] 18997: Import Mesa-6.4 release. (Thanks GvG :-)

by Jirka Doubek

Sorry, I was too fast with my question... Jirka

19 years, 2 months

Re: [ros-svn] [blight] 18984: Import Mesa-6.2 sources.

by Jirka Doubek

Hi! Blight: I have a little question: why are you importing Mesa3d 6.2 sources, when there is a new stable version 6.4 out there? Maybe I something misunderstood (I know almost nothing about OpenGL sources and implementation in ReactOS), so there is a reason - in that case can you explain it, please? Thank you very much. Best regards, Jirka

19 years, 2 months

RE: NPFS problems

by Ge van Geldorp

> From: Ge van Geldorp > > The patch below just makes NpfsWaitPipe > return success in case it's already connected, which solves > the umpnpmgr problem. Forgot the patch: Index: fsctrl.c =================================================================== --- fsctrl.c (revision 18977) +++ fsctrl.c (working copy) @@ -278,8 +278,13 @@ WaitPipe = (PFILE_PIPE_WAIT_FOR_BUFFER)Irp->AssociatedIrp.SystemBuffer; Pipe = Fcb->Pipe; - if (Fcb->PipeState != 0) + if (FILE_PIPE_CONNECTED_STATE == Fcb->PipeState) { + DPRINT("Pipe is already connected\n"); + return STATUS_SUCCESS; + } + else if (Fcb->PipeState != 0) + { DPRINT("Pipe is not in passive (waiting) state!\n"); return STATUS_UNSUCCESSFUL; }

19 years, 2 months

patch for test/review

by Hartmut Birr

Hi, I've changed rbuild a little bit, that it can run on msys (on windows). The major changes are: - The separator (slash or back slash), exepostfix and exeprefix are initialized from environment variables. - The separators in the path for the system command are always converted for the host system. - Our own build utilities must convert paths itself (bin2res). It exist some problems with absolute paths on msys, because msys uses '/c/foo/bar' and windows 'c:\foo\bar' or 'c:/foo/bar'. I've tested the patch on msys and on windows. I cannot test the patch on linux. Currently, msys is the only way to use all cpus or cores for the build process on windows. - Hartmut

19 years, 2 months

auto vs manual vc6 project files naming conflict

by Royce Mitchell III

our "make -vs6 msvc" command generates dsp files automatically for all project in the tree. At the moment, this is overwriting the following files: subsys/system/explorer/notifyhook/notifyhook.dsp subsys/system/ibrowser/ibrowser/ibrowser.dsp lib/opengl32/opengl32.dsp lib/cpl/ncpa/ncpa.dsp lib/cpl/control/control.dsp lib/cpl/appwiz/appwiz.dsp Would anybody have a problem with it if I renamed all these dsp files out of the way, or would it be better if the auto-generated dsp files were named something like notifyhook_auto.dsp? Thanks

19 years, 2 months

RE: [ros-bugs] [Bug 948] New: ReactOS Hangs After Changing ISO Images

by Casper Hornstrup

Why don't 0.2.8 display filenames and line numbers in stack traces? Casper > -----Original Message----- > From: ros-bugs-bounces(a)reactos.org [mailto:ros-bugs-bounces@reactos.org] On Behalf Of > ReactOS.Bugzilla(a)reactos.org > Sent: 2. november 2005 10:49 > To: ros-bugs(a)reactos.com > Subject: [ros-bugs] [Bug 948] New: ReactOS Hangs After Changing ISO Images > > http://www.reactos.org/bugzilla/show_bug.cgi?id=948 > > Summary: ReactOS Hangs After Changing ISO Images > Product: ReactOS > Version: 0.2.8 > Platform: VMWare 5 > OS/Version: Microsoft Windows NT 4.0 > Status: NEW > Severity: major > Priority: P3 > Component: Kernel > AssignedTo: ros-bugs(a)reactos.com > ReportedBy: the80sphreak(a)yahoo.co.uk > QAContact: ros-bugs(a)reactos.com > > > Hi there, > > I am using ReactOS inside vmware 5.0 on a Pentium 4 (2GHZ) laptop with 768MB > Ram, 20GB Hard disk and windows XP Home + SP2. During my testing of ReactOS > 0.2.8, I unmounted one CD image, and mounted another. This caused ReactOS to > hang and VMWare to report the processor being halted by the guest OS. I tried > a reboot, but this did not help, and now any time I try and access CDs > (physical or ISO,) ReactOS hangs with a BSOD. > > I have posted 2 screenshots on my website at: > > http://www.geocities.com/the80sphreak/reactos.jpg > http://www.geocities.com/the80sphreak/reactos2.jpg > > If you require any more information, please send me an email at: > > the80sphreak(a)yahoo.co.uk > > Thanks, > > R. McLay > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > You are the QA contact for the bug, or are watching the QA contact. > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs

19 years, 2 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