ion(a)svn.reactos.com wrote:
> Dmitry Philippov <shedon(a)mail.ru>:
>
> - Implemented FindFirstFileExW() and have removed InternalFindFirstFile() in /lib/kernel32/file/find.c, now FindFirstFileA (), FindFirstFileExA () and FindFirstFileW called FindFirstFileExW ()
>
>NOTE: Filip has asked revision "16661" (the next one) to be done by him... sorry if this sounds silly, but please respect his wish :)
>
>
>Updated files:
>trunk/reactos/lib/kernel32/file/find.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
The implemention of FindFirstFileExW is very buggy. On errors, the
allocated buffers are not cleanup correctly. The fourth parameter is
wrong in the call to RtlDosPathNameToNtPathName_U. It isn't possible to
cast a unicode string to a directory structure. The using of the results
from the call to RtlDosPathNameToNtPathName_U is wrong. The buffer from
the returned directory structure isn't always null terminated.
- Hartmut
Robert k. <rob(a)koepferl.de> wrote:
> Hi,
>
> since there was just one change to the branch 0.2.7 I did not yet
> publish the RC2 version. I decided to wait until monday to publishing
> RC2.
>
It seems RC1 is being forgotten about.
I know this has been discussed a few times before, but can we not look into
the possibility of branching off for releases in a different way.
Although it means changing SVN URL for HEAD, is it not better to follow the
path of branching a new HEAD and freezing the current address for the next
release. This may help people to remember to concentrate more on bugfixes
for the upcoming release and not on implementing new features to HEAD.
I'd hate to see another buggy release like 0.2.6, which was possibly a
regression on 0.2.5
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hehe... Bug 666 in 16661... OK, I get the Joke ;)
On 7/20/05, navaraf(a)svn.reactos.com <navaraf(a)svn.reactos.com> wrote:
> Get rid of windows.h include in win32k. Fixes bug #666.
>
>
> Updated files:
> trunk/reactos/include/ndk/extypes.h
> trunk/reactos/include/ndk/i386/ketypes.h
> trunk/reactos/include/subsys/csrss/csrss.h
> trunk/reactos/subsys/win32k/eng/xlate.c
> trunk/reactos/subsys/win32k/ntuser/misc.c
> trunk/reactos/subsys/win32k/ntuser/scrollbar.c
> trunk/reactos/subsys/win32k/objects/text.c
> trunk/reactos/subsys/win32k/w32k.h
> trunk/reactos/w32api/include/basetyps.h
> trunk/reactos/w32api/include/ddk/ddrawi.h
> trunk/reactos/w32api/include/ddk/ddrawint.h
> trunk/reactos/w32api/include/ddraw.h
> trunk/reactos/w32api/include/oleacc.h
> trunk/reactos/w32api/include/winuser.h
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
Hi!
ion(a)svn.reactos.com wrote:
> - Update ASM header file with more offsets.
>
>
> Updated files:
> trunk/reactos/ntoskrnl/include/internal/asm.h
>
[PCH] obj-i386/ntoskrnl/include/ntoskrnl.h.gch
In file included from ntoskrnl/include/internal/ntoskrnl.h:14,
from ntoskrnl/include/ntoskrnl.h:43:
ntoskrnl/include/internal/asm.h:132:1: "CONTEXT_FULL" redefined
In file included from w32api/include/windef.h:249,
from w32api/include/ddk/ntddk.h:35,
from ntoskrnl/include/ntoskrnl.h:18:
w32api/include/winnt.h:1482:1: this is the location of the previous definition
In file included from ntoskrnl/include/internal/ntoskrnl.h:14,
from ntoskrnl/include/ntoskrnl.h:43:
ntoskrnl/include/internal/asm.h:133:1: "CONTEXT_FLOATING_POINT" redefined
In file included from w32api/include/windef.h:249,
from w32api/include/ddk/ntddk.h:35,
from ntoskrnl/include/ntoskrnl.h:18:
w32api/include/winnt.h:1479:1: this is the location of the previous definition
make: *** [obj-i386/ntoskrnl/include/ntoskrnl.h.gch] Error 1
Did I miss a memo or should I delete something to make this work?
Thanks,
James
8^>
greatlrd(a)svn.reactos.com wrote:
>Change some error msg from ConErr to ConOut for they are being pipe so the behover are equal with ms windows cmd
>
>
>
>Updated files:
>trunk/reactos/subsys/system/cmd/error.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
Hi,
I think this change is wrong (also some parts from 16579). The error
messages have always to go to the error output (STD_ERROR_HANDLE).
- Hartmut
ion(a)svn.reactos.com wrote:
> - Fix nasty APC delivery bug (in case a Kernel-Mode Special APC still returned with a Normal Routine, the Normal Routine was called with incorrect values (Special Routines take PVOID* arguments, while Normal Routines do not!))
> - Remove APC from list before setting it to non-inserted.
> - Do proper thread termination piggybacking; terminate threads in user-mode as Hartmut correctly fixed.
>
>
>Updated files:
>trunk/reactos/ntoskrnl/ke/apc.c
>trunk/reactos/ntoskrnl/ps/kill.c
>
>
>
Hi,
I do not agree to this changes. For a non system thread, we use a kernel
mode apc first, which uses a second user mode apc. This overhead isn't
necessary. For system threads it isn't possible to use a kernel mode apc
which calls PspExitThread. A system thread must terminate it self. It is
only possible to help by marking a flag, setting an event or unwait the
thread.
- Hartmut
Hi,
Sorry but I accidentally lost 60 emails including the one I'm supposed
to reply to.
Hartmut, you have done a recent change in kill.c in which you change the
APC inside PspTerminateThreadByPointer to a user-mode APC. This is
incorrect and I don't understand why it was done... furthermore, I've
even documented a source of information which proves my code was correct
(on top of the function header), so why did you change it?
Best regards,
Alex Ionescu