"Bugs? There's no bugs in GCC. GCC is perfect."
"I've never encountered a bug in GCC that would have real-life effects,
except a small one a long time ago"
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi,
> Subject: [ros-diffs] [ekohl] 23521:
> - Implement ScmStartServiceA and revert the last modification of
StartServiceA.
> - Fix EnumServicesStatusExW.
We now have an exact code duplication between StartServiceA/StartServiceW
(except strlen/wcslen and strcpy/wcscpy) and
ScmrStartServiceA/ScmrStartServiceW.
I don't think it's a good thing because we will have some problems to keep
the code in sync.
I did r23519 to prevent this code duplication and because
ScmrStartServiceA() was not called except in StartServiceA.
By the way, I also implemented argument conversion between ANSI and Unicode
in StartServiceA before calling StartServiceW, which meant that arguments
were ignored only in ScmrStartServiceW. Now, you have 2 places to take care
of them (ScmrStartServiceA/W)...
That was just to say my feeling...
Hervé
> Commit by *fireball* :: r*23508* *reactos*/ntoskrnl/ (cm/regobj.c
> ob/obhandle.c):
>
> Goodbye REGISTRY_ERROR bsod!
>
> * Change UserMode -> KernelMode in ObReferenceObject*() calls,
> because that calls failed
> * Remove Cm-specific hack from Ob "advapi32_winetest.exe registry"
> shows 0 failures on the first run and 2 failures on further
> runs. I suppose there might be a leakage in the CM. To be
> investigated further (or wait till complete Cm rewrite in October).
>
Still regedit crashes when trying to open a key that contains one or
more values.
From http://reactos.dyndns.org:8010/
[CC] drivers\network\ndis\ndis\control.c
drivers\network\ndis\ndis\control.c: In function `NdisAcquireReadWriteLock':
drivers\network\ndis\ndis\control.c:63: warning: assignment makes integer from pointer without a cast
make: *** [obj-i386\drivers\network\ndis\ndis\control.o] Error 1
program finished with exit code 2
From Linux,
[CC] drivers/network/ndis/ndis/control.c
drivers/network/ndis/ndis/control.c: In function `NdisAcquireReadWriteLock':
drivers/network/ndis/ndis/control.c:63: warning: assignment makes integer from pointer without a cast
make[1]: *** [obj-i386/drivers/network/ndis/ndis/control.o] Error 1
make: *** [ndis] Error 2
8^)
James
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sun Aug 6 01:39:29 2006
> New Revision: 23491
>
> URL: http://svn.reactos.org/svn/reactos?rev=23491&view=rev
> Log:
> [AUDIT]
> Configuration Manager
>
> After going through the code, it doesn't have any signs of questionable origin.
If it did, where are all those REGISTRY_ERROR bugchecks I should be
getting in Windows NT? :P
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sun Aug 6 00:57:36 2006
> New Revision: 23489
>
> URL: http://svn.reactos.org/svn/reactos?rev=23489&view=rev
> Log:
> Fix DbgPrint / DbgPrintEx definitions to use PCCHAR instead of PCCH (recent WDK uses PCCHAR).
> This change fixes compiling.
>
Um, no, this is the latest definition:
ULONG
__cdecl
DbgPrint (
__in PCCH Format,
...
);
Why do you think I had changed it in the first place?!
A PCCHAR is *NOT* a const char, it's just typedef char*.
So my change correctly changed the definition to use const char (Because
dbgprint fails if you're not sending a const char), and also allowed
building with the fixed WDKs, and you just reverted that... when you
asked on Google Talk if you could fix it, I assumed you know what you
were doing :)
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hi,
I'm really excited by all the recent WinLogon work! Congratulations to
Hervé for working on this.
Some questions:
Will the GINA be 100% compatible with NT WinLogon? I hope so. Also,
there is a fully FOSS GINA project out there, I'm sure it can be useful.
MSDN also has a lot of information, and I can help with some Winlogon
internals, by email only please, I'm not and won't be on IRC for a while.
Are we also going to support GUI-on-demand? That was largely the big
problem with Winlogon, and both Thomas and I (And others) think GUI On
Demand is a big hack that currently screws up more stuff then it
helps... If yes, then how's winlogon going to work? As a text-mode login
problem as well? Hopefully that won't hack GINA compatibility.
Since this was supposed to be an SoC program, I propose that we setup a
personal fund (and advertise) on the website for Hervé to get paid. I'll
also try talking to Google (since our SoC GINA guy failed) to see if
they'd be willing to set up an exchange. Unless Hervé disagrees, of course.
Good luck to all.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
