Ros-dev September 2005

ros-dev@reactos.org

67 participants
129 discussions

Anyone looking for a nice, uncomplicated bug to fix?
by Ge van Geldorp 16 Sep '05

16 Sep '05

Bug 775 (http://www.reactos.com/bugzilla/show_bug.cgi?id=775) seems to be a simple application bug. I expect no kernel involvement at all. So, if you were always wanting to fix something in ReactOS but were afraid it might be too complicated, this bug is for you. It should give you experience in building and debugging ReactOS so maybe next time you can attack something a little bit more complicated. Gé van Geldorp.

1 0

Re: [ros-diffs] [hbirr] 17863: Fixed the MP build.
by Alex Ionescu 16 Sep '05

16 Sep '05

hbirr(a)svn.reactos.com wrote: >Fixed the MP build. > Hi Hartmut, I'm really sorry, I forgot to test MP=1 :( We really need a way to ensure that KDBG/MP code always gets built... it would cause less problems... Best regards, Alex Ionescu

1 0

Re: [ros-diffs] [ion] 17860: Return valid status
by Hartmut Birr 15 Sep '05

15 Sep '05

ion(a)svn.reactos.com wrote: >Return valid status > >Modified: trunk/reactos/lib/rtl/exception.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/rtl/exception.c* > >--- trunk/reactos/lib/rtl/exception.c 2005-09-15 13:25:32 UTC (rev 17859) >+++ trunk/reactos/lib/rtl/exception.c 2005-09-15 14:07:37 UTC (rev 17860) >@@ -39,10 +39,10 @@ > > Context.ContextFlags = CONTEXT_FULL; > > /* Check if we're being debugged (user-mode only) */ > > >- if (!RtlpCheckForActiveDebugger()) > > >+ if (!RtlpCheckForActiveDebugger(TRUE)) > > RtlpCheckForActiveDebugger is defined as BOOLEAN NTAPI RtlpCheckForActiveDebugger(VOID); - Hartmut

1 0

I/O subsystem question
by Ge van Geldorp 15 Sep '05

15 Sep '05

I'm working on bug 713 (http://www.reactos.com/bugzilla/show_bug.cgi?id=713 for the click-happy). What I have found is this: - Telnet opens a socket - Sending and receiving are handled by different threads, let's call them S and R - Thread R starts a recv() operation, which is translated to an ioctl on the socket - No data is available, so thread R blocks, waiting for FileObject->Event - I type something, which is handled by thread S. Thread S starts a send() operation. - Again translated to an ioctl on the socket. Since this is the same socket as used by S, the FileObject will be the same - The send can complete immediately, IoCompleteRequest is called which sets the FileObject->Event. - Thread R is unblocked, the event it was waiting for was set by thread S. However, the irp of thread R was never completed. The recv() call returns with bogus info. - Thread R starts another recv(). When some data arrives from the server, two irps are waiting for it. This eventually leads to the crash. The fundamental problem seems to be multiple overlapping I/O operations which all use FileObject->Event to signal their completion. I have no idea how to fix that... Gé van Geldorp.

5 8

Non-working uxtheme.dll
by Mike Swanson 14 Sep '05

14 Sep '05

I'm sorry if this would a wrong place to post this, but since I'm trying the ReactOS uxtheme.dll, I figured this would be fine. I've compiled today's SVN, and I noticed that ReactOS had a uxtheme.dll (didn't know that before :P). Well, as a try, I went and put it on a Windows XP Professional machine (no service pack, and the Microsoft uxtheme.dll is un-patched). When I rebooted with the ReactOS DLL, Windows XP freezes at the welcome screen, the start up sound doesn't even play. So I'm wondering if uxtheme.dll isn't complete yet or if it's already known to have problems. -- Mike

6 7

freeldr questions
by vit-ros＠att.net 14 Sep '05

14 Sep '05

Few questions about freeldr - Is there a compelling reason to have pointer members of LOADER_PARAMETER_BLOCK such as ModsAddr as ULONGs ? (include/ndk/haltypes.h) - Why the kernel module (ntoskrnl.exe) in not treated as such in the loader (there is a special case to create the corresponding module object in the kernel) ? - Why MachGetMemoryMap() is called twice: in freeldr/mm/meminit.c and in freeldr/reactos/reactos.c ? - wouldn't it be nicer to fix these ?

1 0

WaitNamedPipe bug? can anyone confirm?
by Luke Kenneth Casson Leighton 14 Sep '05

14 Sep '05

is WaitNamedPipe working, or have i got something wrong in my code? this is 0.2.7. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

msafd headers
by Mikhail Y. Zvyozdochkin 14 Sep '05

14 Sep '05

Hi All! Files on reactos/lib/msafd/misc/ uses header "msafd.h" from reactos/lib/msafd/. On my system, MinGW/linux successfully compiled these files ONLY after I manually corrected include directive: #include <../msafd.h> instead #include <msafd.h> in all 5 *.c files in reactos/lib/msafd/misc/. Maybe we must make this replacement in svn tree? Or it was my misconfiguration? ;) WBR, DarkHobbit

3 3

Testing ROS on VMWare With 32MB... Interesting Results
by TwoTailedFox 14 Sep '05

14 Sep '05

Been having a poke around, it seems neither LiveCD nor BootCD will boot into GUI (Using latest HEAD SVN), on 32MB. BootCD will complete first stage installer, but won't boot into GUI to load the second stage setup. LiveCD immediately hangs. Now, on VMWare, I use Other/Other as the OS Category, and I've been hearing some (like WaxDragon), using Windows XP Professional as the OS Category. I obtained a BootCD of 17751 rev, and tried it on the WinXP setting, using 32MB. First time I tried it, it hung at copying ole32.dll (34%). Second time, I got a STOP error during the file transfer. Third time, however, it completed the first stage fine. The only difference between the Other and WinXP Pro settings is the inclusion of a USB Controller. I added one to my "Other" setup, and ROS, again, installed fine first time around on 32MB. Now, for the interesting bit. The error is a pretty constant one, and it complains of No Memory Pages Available. It seems just common to the GUI, seeing as ROS won't boot on 32MB even once Setup is completed. This is the case for both SVN Live and BootCD's. Something in the GUI is causing a leak -- "I had a handle on life, but then it broke"

5 6

NamedPipes - cause massive reliability problems with services. what to _do_?
by Luke Kenneth Casson Leighton 14 Sep '05

14 Sep '05

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/m… please note the comments "it is possible for a client to connect in between the CreateNamedPipe and ConnectPipe". in other words, NamedPipes don't have any equivalent of "listen()". this is a massive _massive_ problem, evidence of which i first encountered with "rpctorture --processes=100 --repeat-operation=100", back in 1998. out of 10,000 operations performed across 100 processes, about TWENTY of those operations would succeed. that's a success rate of 0.2%. (anyone who runs a lab where 400 students sit down at the beginning of a session and all log in to the same NT PDC will tell you _exactly_ what they bloody think of windows and it's the same issue) the reason why there is such an abysmal failure rate was not clear to me until today. it's due - quite simply - to this delay. if the server is particularly overloaded (due to having to deal with, oh i dunno, say, a large influx of incoming Named Pipe client requests) then the time delay between CreateNamedPipe and ConnectPipe is increased; if some idiot decides that the number of pipe connections is to be limited; if someone decides that the number of threads is to be limited, then the server quickly goes into meltdown. if there is protocol proxying or authentication going on (as is the case of SMB IPC$ providing MSRPC named pipes - ncacn_np for those people who know what that is) then you _really_ are in trouble. the question is: having access to the source code - in reactos - what can be _done_ about this? would it be reasonable to write - and use - a named pipes equivalent of "listen()"? alternatively, how in hell's name do you _deal_ with this sort of thing? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev September 2005