Why not just remove the code in #if 0/#endif? It serves no purpose.
________________________________________
From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of ea(a)svn.reactos.com
Sent: 29. juli 2005 12:05
To: ros-diffs(a)reactos.com
Subject: [ros-diffs] [ea] 16854: Various fixex to make HEAD compile.
Various fixex to make HEAD compile.
I hope I did break nothing.
Modified: trunk/reactos/hal/halx86/generic/processor.c
Modified: trunk/reactos/lib/advapi32/sec/trustee.c
Modified: trunk/reactos/lib/advapi32/service/scm.c
Modified: trunk/reactos/subsys/csrss/win32csr/desktopbg.c
Modified: trunk/reactos/subsys/ntvdm/ntvdm.c
Modified: trunk/reactos/subsys/smss/client.c
Modified: trunk/reactos/subsys/system/setup/setup.c
Modified: trunk/reactos/subsys/system/winlogon/setup.c
Modified: trunk/reactos/subsys/win32k/ntuser/keyboard.c
________________________________________
Modified: trunk/reactos/hal/halx86/generic/processor.c
--- trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 09:51:08 UTC (rev 16853)
+++ trunk/reactos/hal/halx86/generic/processor.c 2005-07-29 10:04:38 UTC (rev 16854)
@@ -39,7 +39,9 @@
HalStartNextProcessor(ULONG Unknown1,
ULONG ProcessorStack)
{
+#if 0
DPRINT("HalStartNextProcessor(%x %x)\n", ProcessorNumber, ProcessorStack);
+#endif
return TRUE;
}
Wouldn't it be good to forward web-users to http://reactosde.re.funpic.de ?
or at least put a link for those wanting to go on with something?
Yours sincerely,
Jaix Bly
Hi.
I'm upgrading Subversion on svn.reactos.com to version 1.2.1
to correct some memory leaks in svnserve. Subversion 1.2.x
also brings us:
Faster access to old revisions. svn blame, svn checkout,
svn update, svn diff, svn merge will be faster.
Locking. If you have an 1.2.x client you can lock files and
directories. This is mostly useful for binaries so it's
possibly not something we will use much.
For faster access to old revisions, a "dump and load" of the
repository is needed so the repository will be unavailable
for a few hours today.
Casper
Hi,
It seems that the problem regarding Ged's RTL network card is related to
patch 15402:
http://svn.reactos.com/viewcvs?view=rev&rev=15402.
Is it possible that the card is incorrectly (or not in the same way we
are expecting) telling us its resource data? Or that somethign has been
overlooked? Ged has done a terrible deal of network testing for us but
he's been unable to work since his network card couldn't even ping
anymore. I've helped him find the regression and I hope someone more
experienced in PnP can help him out... at least we know what patch did it.
Best regards,
Alex Ionescu
ion(a)svn.reactos.com wrote:
>- Final ROSRTL removal patch. The next patch will remove the actual library and code.
>- Changes:
> - CreateProcess
> * Cleanup creation of the initial thread using new utility functions and remove rosrtl
> * Almost entirely rewrote the function to support features such as:
> - SxS (locally only, patch will follow),
> - SFP (SAFER) (locally only, patch will follow),
> - DllPaths (locally only, patch will follow),
> - Proper process environment/paramter block creation
> - Proper console handle management (needs more work in kernel32/csr),
> - Tokens/CreateProcessAsUser (locally only, patch will follow),
> - Simpler code for path lookup, and more robust.
> - Support for "auto-correction" (see Raymond Chen's blog)
> - 16-bit/NE detection
> - A variety of creation flags are now properly supported
> - Added support for an undocumented-yet-known (see comment) shell flag
> - Alert for flags we don't support yet
> - Catch invalid flag combinations and other caller errors
> - Improve and correct path searcing to use documented behaviours
> - Created a multitude of helper functions to make the code easier to read
> and allow them to be used for other apis as time goes on.
>
> - BaseProcessStartup
> * Call NtSetThreadInformation to let the Kernel know of the Thread's Start Address.
> * Correct prototype of Thread Startup function for this case.
>
>This fixes MANY things, some of which may not be evident, and possibly creates regressions which I have not yet seen but will try to correct. Some of these may be caused by the fact that I've seen code send CreateProcessW incorrect flags. Some things of note: DO NOT send partial names as "lpApplicationName". It's not supposed to work unless you're in the same current directory. Also, do NOT send CREATE_UNICODE_ENVIRONMENT if you don't have a unicode environement, and vice-versa. I've seen lots of code doing mistakes related to this. I hope you appreciate this patch and won't all jump on me for possbile regressions :(.
>
>Modified: trunk/reactos/lib/kernel32/process/create.c
>Modified: trunk/reactos/lib/kernel32/thread/i386/thread.S
>Modified: trunk/reactos/lib/kernel32/thread/thread.c
>Modified: trunk/reactos/ntoskrnl/mm/process.c
>
>
> ------------------------------------------------------------------------
Hi,
your rewrite of CreateProcess is broken. Before you can inform csrss
about the process creation, you have to gather all informations about
handles and creation options. After your commit, each console
application creates its own console window and the redirection of
standard handles is broken. It seems also that the inheritance of msvcrt
file id's is broken. This stops compiling ros on ros.
- Hartmut