Hi all,
Bored again, decided to build ros on ros.
Getting this,
(subsys/csrss/api/handle.c:75) CsrGetObject returning invalid handle
(KERNEL32:lib/kernel32/mem/global.c:412) Memory Load: 11
(KERNEL32:lib/kernel32/mem/global.c:412) Memory Load: 11
(subsys/csrss/api/handle.c:75) CsrGetObject returning invalid handle
(subsys/csrss/api/handle.c:75) CsrGetObject returning invalid handle
Things I noticed may have been fixed,
Multi cmd problem, handle count going throw the roof and hangs.
Thanks,
James
Hi!
When compiling ros on ros this happens. The build process, well nothing has changed
for more than a year, except cmd and the dlls.
make[2]: Entering directory `C:/ros/reactos/apps/utils/rundl32'
windres --include-dir ../../../include --include-dir ../../../w32api/include ru
ndll32.rc -o rundll32.coff
gcc -DUNICODE -Wall -Werror -D__USE_W32API -I. -I../../../include -I../../../w32
api/include -pipe -march=i386 -D_M_IX86 -c rundll32.c -o rundll32.o
make[2]: *** No rule to make target `../../../dk/w32/lib/user32.a', needed by `r
undll32.nostrip.exe'. Stop.
I use a old build to test ros with. It gives ros hell and it is small too. Doesnt
use much disk space.
Thanks,
James
Hi
a new branch ros-branch-0_2_7 * r16538 exists, now.
Please be cautious in terms of to which branch you commit and that this
branch remains buildable.
The next days there will be a binary distribution as RC1 whilst RC2 or
final will follow.
It seems like there is some uncertainty between this
code and RtlQueryEnvironmentVariable_U about who is
going to ensure that the string returned from
GetEnvironmentVariable() is nul terminated...
If I read the code in RtlQueryEnvironmentVariable_U
correctly (and I don't swear I have), it is possible
for it to return STATUS_SUCCESS and not copy a
NUL terminator. This happens if the buffer is large
enough to contain the value but not the NUL terminator.
This is probably correct for this function since
UNICODE_STRINGs (and the Rtl* library) generally have
no requirement of a NUL terminator.
But then, if I read the code in GetEnvironmentVariable()
correctly, I don't believe it takes this situation into
account.
Probably, it would be best if RtlQueryEnvironmentVariable_U
_never_ copied the NUL terminator, and the caller was
always responsible for adding NUL termination, if needed.
Thanks,
Joseph
PS. MSDN is slightly unclear (to me) on how it should behave
in this case, but it seems unlikely that the real
GetEnvironmentVariable() returns success and a non-nul-terminated
string. But I haven't written a test program to prove it.
weiden(a)svn.reactos.com wrote:
> return the length of the string excluding the null-termination character on success in GetEnvironmentVariable(). Thanks to Hartmut.
>
> Modified: trunk/reactos/lib/kernel32/misc/env.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/lib/kernel32/misc/env.c*
>
> --- trunk/reactos/lib/kernel32/misc/env.c 2005-07-11 18:22:53 UTC (rev 16535)
> +++ trunk/reactos/lib/kernel32/misc/env.c 2005-07-11 20:30:33 UTC (rev 16536)
> @@ -91,7 +91,7 @@
>
> /* free unicode variable name string */
> RtlFreeUnicodeString (&VarNameU);
>
>
> - return (VarValueU.Length / sizeof(WCHAR) + 1);
>
> + return (VarValueU.Length / sizeof(WCHAR));
>
> }
>
>
> @@ -133,7 +133,7 @@
>
> }
> }
>
>
> - return (VarValue.Length / sizeof(WCHAR) + 1);
>
> + return (VarValue.Length / sizeof(WCHAR));
>
> }
>
>
>
On Fri, Jul 08, 2005 at 08:38:38AM +0200, Rafal Kupiec
wrote:
> I think I shoudn't write here this.
> Person finds free time to do it and you're doing
> problems. I think i'll never more write information
> about bugs in your system.
I shall refrain from commenting.
> BTW. Please download HostiliX Sources from SVN (rev
> 42). Make CD Image and boot it in VmWare or on real
> hardware. This problems don't occure in HostiliX!
Ummm... and please sign up for the bugzilla system
to submit your bugs?
You, as a full-time employee, can't be bothered to
sign up for bugzilla, but you expect all of us to
go download the entire HostiliX repo (some on dialup),
compile it, and boot it... just to prove/disprove
that the bug does or doesn't exist in code that's not
even ours?
Methinks you're holding a double-standard -- a very
self-centered one at that. Your time is -so- precious
that you can't be bothered to go through, at most, a
30-minute, one-time process in order to properly
report a bug, yet you think our time is soooo
expendable that we should go through a process that
could easily take some of us over an hour to do. Not
only that, but the process you want -us- to go through
doesn't even result in work getting done -- it would
succeed only in stroking your ego. Look! ReactOS has a
bug that HostiliX doesn't! Whoop-de-doo! Now what? We
can't re-use your code, since it's considered
"tainted," so we don't gain anything by verifying that
the HostiliX code does/doesn't work.
For the record: How many people on this list have
full-time jobs not related to ReactOS?
When I joined the ReactOS Bugzilla, I was a full-time
college student (15 credits, 22 hours of class/travel
a week, another 20+ hours in homework easily).
-- Travis
__________________________________
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html