Building with _WINKD_ = 1 is broken
[COPY] output-i386\bootcd\reactos\ntfs.sys
[AS] ntoskrnl\ke\i386\boot.S
[CC] ntoskrnl\ke\i386\abios.c
In file included from ntoskrnl/include/internal/ntoskrnl.h:83,
from ntoskrnl/include/precomp.h:64,
from ntoskrnl/include/ntoskrnl.h:1,
from ntoskrnl\ke\i386\abios.c:11:
ntoskrnl/include/../kdbg/kdb.h:228: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'KdbEnterDebuggerException'
mingw32-make: *** [obj-i386\ntoskrnl\ke\i386\abios_ntkrnlmp.o] Error 1
I've gone down the path of virtually rewriting the msvc backend for rbuild.
Our current implementation had completely outgrown its original design and
was becoming very difficult to manage, as highlighted when I was adding
support for VS 2010.
Anyway, whilst I'm doing this I think it's a good time assess what we want
to support. We currently support Visual Studio 6, Visual Studio .NET 2002
and Visual Studio.NET 2003. This is a waste of time IMO and only adds to the
complexity of the module
I'm proposing to remove support for these 3 products unless anyone has any
reasons against.
Ged.
cfinck(a)svn.reactos.org schrieb:
> Author: cfinck
> Date: Wed Dec 2 21:32:16 2009
> New Revision: 44368
>
> URL: http://svn.reactos.org/svn/reactos?rev=44368&view=rev
> Log:
> [General]
> - Remove the "kernel32" library reference in all .rbuild files of user-mode modules, because this one is already added by "mingw_common". Also fix the indentation in some files.
>
Hi,
doesnt that break a few modules which used to build with msvc?
kind regards
Johannes
This is stupid!!! We had this discussion countless times!
It's not a bug to get back access denied! In many situations this is
normal, and the application will try again! (Ie: Writing to a
read-only file)
Best regards,
Alex Ionescu
On Tue, Dec 1, 2009 at 10:26 PM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Tue Dec 1 22:26:40 2009
> New Revision: 44348
>
> URL: http://svn.reactos.org/svn/reactos?rev=44348&view=rev
> Log:
> [ntoskrnl/se]
> - Add a hack which prints an annoying message and grants access when it should not be. Callers/bugs should be fixed and this commit reverted after that.
> See issue #4169 for more details.
>
> Modified:
> trunk/reactos/ntoskrnl/se/semgr.c
>
> Modified: trunk/reactos/ntoskrnl/se/semgr.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=44…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Tue Dec 1 22:26:40 2009
> @@ -608,10 +608,12 @@
> }
> else
> {
> - DPRINT1("Denying access for caller: granted 0x%lx, desired 0x%lx (generic mapping %p)\n",
> + DPRINT1("HACK: Should deny access for caller: granted 0x%lx, desired 0x%lx (generic mapping %p).\n",
> *GrantedAccess, DesiredAccess, GenericMapping);
> - *AccessStatus = STATUS_ACCESS_DENIED;
> - return FALSE;
> + //*AccessStatus = STATUS_ACCESS_DENIED;
> + //return FALSE;
> + *AccessStatus = STATUS_SUCCESS;
> + return TRUE;
> }
> }
>
>
>
>
Hello,
the trunk of our SVN server has been locked to prevent even more
regression from entering the tree.
So far, after more than 3 weeks after I filed the bug report and not
including all previous time when people were complaining about rapps
which can't download anything at all - either hangs or crashes, I see
that now even PCNet network card is being recognized in my VMWare
Workstation 6.5.
Trunk is writable right now by members of the bugfix team only,
that's so far Cameron (because he is the one supposed to fix
networking) and me. If someone volunteers to fix any of the existing
regressions, please let me know on irc/email, I'll include you into
the bugfix team.
Thanks for understanding, and patience. My patience is over.
WBR,
Aleksey Bragin.
Hi everybody,
The "clean" command in RosBE has often been criticized for not cleaning what
the user expected.
While in the past, it had just issued commands to delete the four
files/folders "makefile.auto", "obj-i386", "output-i386" and "reactos" in
the current directory, it's general behaviour has been changed significantly
over time, in particular by these two commits:
- 38756
If you set a different object or output directory for the built files
through RosBE Options, these directories are always cleaned instead of
"obj-i386" or "output-i386" in the current directory.
- 39138
If no dedicated object or output directory is set through RosBE Options,
we always clean the one set after RosBE has been started or which has been
set by "chdefdir". We even do so if this directory is not the current
working directory.
Especially the latter commit seems to have caused problems for many people
as you could easily clean the wrong tree now.
Therefore I made some efforts to rework this command a bit and published by
current script at http://reactos.colinfinck.de.
This script now first checks whether "makefile.auto", "obj-i386",
"output-i386" and "reactos" exist in the current directory. If all of them
exist, they are cleaned.
If not, it checks whether different object and output directories were set
using RosBE Options and checks for them instead of "obj-i386" and
"output-i386". If they exist together with "makefile.auto" and "reactos" in
the current working directory, all of them are cleaned.
Of course, this also works for every other architecture we support, i386 was
just taken as the most popular example here.
I'm posting this here now, because I don't want to upset other people now
that the script logic is changed again. If you rather like the current
"clean" logic instead of my proposal, please tell me.
I leave this discussion opened for several weeks as I currently don't have
much time anyway. If there are no negative comments, the new script will be
committed afterwards.
Best regards,
Colin
cgutman(a)svn.reactos.org wrote:
> - ULONG SocketError;
> + ULONG SocketError = 0;
FYI, I've already reported this bug some days ago at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145.
As it only occurs in GCC >= 4.3 and the necessary code changes for compiling
ReactOS with GCC 4.4.x are currently collected in a big separate patch (see
http://www.reactos.org/bugzilla/show_bug.cgi?id=4810), no hack from my side
has been committed so far.
If this hack is going to stay, please mark it as such and add a reference to
the GCC bug report.
Hopefully, it's properly resolved someday... :-)
Best regards,
Colin