Freeworld wrote:
> What do you think of releasing it
> concurrent to ReactOS 0.3?
Do you mean 0.2.7 ?
0.3 could be another year away !
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
Hey Robert,
How are things looking for 0.2.7? Should be expecting it soon?
http://www.reactos.com/wiki/index.php/ChangeLog-0.2.7 is still looking
kinda bare, we might want to make sure that gives a better
repersentation of 0.2.7 when it comes out.
Brandon
> From: ion(a)svn.reactos.com
>
> Remove all non-official LPC structures/defines/hardcoded
> hacks, and use actual correct sizes and structures.
This breaks a simple boot.
ntoskrnl/include/internal/port.h previously defined QUEUEDMESSAGE as:
typedef struct _QUEUEDMESSAGE
{
PEPORT Sender;
LIST_ENTRY QueueListEntry;
PORT_MESSAGE Message;
UCHAR MessageData [MAX_MESSAGE_DATA];
} QUEUEDMESSAGE, *PQUEUEDMESSAGE;
r17417 removed the MessageData member.
Now in ntoskrnl/lpc/reply.c function EiReplyOrRequestPort() line 52:
memcpy(&MessageReply->Message, LpcReply, LpcReply->u1.s1.TotalLength);
writes outside allocated memory (MessageReply is a PQUEUEDMESSAGE,
LpcReply->u1.s1.TotalLength is 292). This causes a subsequent ExFreePool to
generate a page fault.
Gé van Geldorp.
It's becoming impossible for me to keep some components synced with Wine.
For some components, we have too many changes in our tree which were not
submitted to Wine. I've tried to submit some of "our" changes, but was
unable to answer questions asked by the Wine people, since I simply do not
have enough knowledge of those particular DLLs. The original (ReactOS)
authors of the changes are not interested or currently unable to answer
either.
So, the following components are now effectively forked:
- tools/widl
- lib/dinput
- lib/setupapi
- lib/winmm
Gé van Geldorp.
I was poking around in gdbstub.c, trying to get it to work a bit
better. I managed to drastically reduce the time it takes GDB to
attach, among other things, by not trying to send a stop reply packet
(and so not responding to GDB's queries). The only reason it worked
before is that, after all the other replies had timed out a few times
each, it issued a `?' query, and finally interpreted the stop reply
packet as the answer to that... there are some other changes,
hopefully for the better.
Can't we use "optional" here instead of "o"? I know it will require
two more seconds to write, but it is much more self-documenting than "o".
Casper
________________________________________
From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of ea(a)svn.reactos.com
Sent: 15. august 2005 19:31
To: ros-diffs(a)reactos.com
Subject: [ros-diffs] [ea] 17400: Add winemine.
Add winemine.
Modified: trunk/reactos/bootdata/packages/reactos.dff
________________________________________
Modified: trunk/reactos/bootdata/packages/reactos.dff
--- trunk/reactos/bootdata/packages/reactos.dff 2005-08-15 17:04:34 UTC (rev 17399)
+++ trunk/reactos/bootdata/packages/reactos.dff 2005-08-15 17:30:20 UTC (rev 17400)
@@ -299,6 +299,7 @@
modules\rosapps\cmdutils\mode\mode.exe 1 o
modules\rosapps\cmdutils\touch\touch.exe 1 o
modules\rosapps\games\solitaire\sol.exe 1 o
+modules\rosapps\games\winemine\winemine.exe 1 o
modules\rosapps\mc\mc.exe 1 o
modules\rosapps\net\ncftp\ncftp.exe 1 o
modules\rosapps\net\niclist\niclist.exe 1 o
greatlrd(a)svn.reactos.com wrote:
> change CMDLINE_LENGTH to 8192 to keep rbuild happy until dymatic alloc are in place
>
>
> Updated files:
> trunk/reactos/subsys/system/cmd/cmd.h
>
Hi!
My problem with building is fix with this patch. I would make sure this setting
is the, no other, only minimum setting. Due to speed of allocating memory every
time cmd is running.
Thanks,
James
It seems you missed a test into your dfp.cxx change.
The change of the series of if() else if() into a switch(){} is ok,
except now it always returns CAB_STATUS_SUCCESS.
+ case CAB_STATUS_NOMEMORY:
+ printf("Insufficient memory to add file: %s.\n", SrcName);
+ break;
+ default:
+ printf("Cannot add file: %s (%lu).\n", SrcName, Status);
+ break;
}
-
return CAB_STATUS_SUCCESS;
}
To restore the correct behaviour, you have to
return Status;
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
I'm curious why we are making this string nul terminated?
IoCreateSymbolicLink() should not care (I'm virtually
certain it doesn't under windows.) And I'm pretty
sure that IoRegisterDeviceInterface isn't expected
to return a nul terminated string either. And I'm also
pretty sure our implementation doesn't actually return
it NUL terminated because the length doesn't include
the NUL termination (rightly so or the symbolic link
would actually have a NUL character as part of it's
name) and the RtlMoveMemory() at the end of the function
is based of off Length().
I'm pretty sure that virtually no windows kernel mode function
taking a UNICODE_STRING structure (or a STRING structure)
expects nul termination...
Thanks,
Joseph
hbirr(a)svn.reactos.com wrote:
> Fixed a terminating NULL in IoRegisterDeviceInterface.
>
> Modified: trunk/reactos/ntoskrnl/io/deviface.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/io/deviface.c*
>
> --- trunk/reactos/ntoskrnl/io/deviface.c 2005-08-15 16:41:43 UTC (rev 17396)
> +++ trunk/reactos/ntoskrnl/io/deviface.c 2005-08-15 16:47:15 UTC (rev 17397)
> @@ -815,7 +815,7 @@
>
> RtlAppendUnicodeToString(SymbolicLinkName, L"\\");
> RtlAppendUnicodeStringToString(SymbolicLinkName, ReferenceString);
> }
>
> - SymbolicLinkName->Buffer[SymbolicLinkName->Length] = '\0';
>
> + SymbolicLinkName->Buffer[SymbolicLinkName->Length/sizeof(WCHAR)] = L'\0';
>
>
> /* Create symbolic link */
> DPRINT("IoRegisterDeviceInterface(): creating symbolic link %wZ -> %wZ\n", SymbolicLinkName, &PdoNameInfo->Name);
>