Hi All,
I wanted to start fresh since there are several emails/chats going around
regarding Visual Studio builds of ReactOS.
First, I would like to state something clearly, since there seems to be
implicit thoughts to the contrary:
Visual Studio is capable of handling a project the size of ReactOS in its
entirety in one .sln without any major performance problems, if it is
configured correctly.
The key phrase is "if it is configured correctly".
For example:
1. The performance problem during loading occurs because IntelliSense
is being unnecessarily taxed (quite heavily in fact). This is fixed by
adding #define WIN32_LEAN_AND_MEAN as appropriate to the IDE settings.
2. The lack of x86_64 and ARM support is occurring because there is a
lack of x86_64 and ARM support. :D
3. Some people might look at the Solution Workspace window, see 800
projects, and think, "Wow. That's a lot of projects. I will be scrolling all
day long." There is a solution (no pun intended) for that: Don't put 800
projects linearly in the Solution Workspace. Put them in a hierarchy that
matches, exactly, the hierarchy of the ReactOS project.
4. That build paths will be broken if the user decides to move his/her
ReactOS hierarchy to a different directory after the .sln and .vcxproj files
have been generated by cmake, is easily fixed: Use relative paths in the IDE
project settings instead.
5. The fact that it is not possible to build, say, just applications,
or just drivers, without hunting-and-pecking projects in the Solution
Workspace, is related to problem #3: The projects are not yet placed into a
hierarchy that mirrors the ReactOS repository. If the projects were placed
into a hierarchy that mirrors the ReactOS repository, it would be possible
to select, say, drivers, right-click, select Build, and all the drivers will
be built depends on what was done in the code, as well as setting proper
paths in the IDE. The use would be able to toggle between Debug/Release,
x86_32/ARM, and perform the same operation, with expected results.
I could go on, but you get the point. It is trivial to set up Visual Studio
so that it "behaves properly". I started this effort, and was 10% into the
800 projects, at least setting up the structure, for x86_32, x86_64, and
ARM; but I throttled-back because I do not like redundancy of effort, and
Amine was already well on his way doing something that was essentially
similar. I am confident that, over time, he will solve these problems.
In the meantime, I would hope that we keep in mind that the problem is not
the tool. The problem is that the tool has not been given a chance to be
configured properly.
If we configure it properly, these problems go away, and most importantly,
when a new developer comes and sees ReactOS in Visual Studio for the first
time, what they see makes sense. Let me repeat that: The measure of success
here, is not whether it is possible to get Visual Studio to compile ReactOS,
although I read some writings about how some wanted the Microsoft compiler
over GCC. The measure of success is whether a heavily experience user of
Visual Studio sees the IDE for the first time with ReactOS in it, and not
start mumbling things like.."Ok.uh... why did they do that.???"
By contrast we want them to say:
"Wow.800-project solution. Let's see, x86_32, x86_64, ARM support..nice.both
Debug and Release present.good good.looks like Solution Workspace mirrors
what is on disk..cool.#include paths in IDE project settings are relative to
root of solution so I can move solution to another disk if I like.appreciate
that.IntelliSense seems to be working correctly.and this livecd thing.I
guess right-clicking on that and doing Build does minimum operations
necessary to generate a live CD. I wonder what happens when I try to execute
the livecd project after built. Wow.that is too awesome!!! Ok. Everything
makes sense. I can handle myself from here. Thanks."
IMO, we should give Amine time to get the ReactOS repository into this
state.. I am re-attaching an image I sent last week about what I would have
done for the structure of the Solution Workspace. As you can see from this
structure, there is nothing intimidating or inefficient about this
structure, and it mirrors what ReactOS veterans see on disk every day.
Cheers.
-John
cid:image001.png@01CDEA11.FFD64AF0
I see a problem with this change.
A debug breakpoint will always break into the debugger exactly where it
is. Like an ASSERT does.
But an exception will usually end up in the installed exception handler.
This does not really help with figuring out what went wrong.
Am 07.01.2013 00:29, schrieb hbelusca(a)svn.reactos.org:
> Author: hbelusca
> Date: Sun Jan 6 23:29:05 2013
> New Revision: 58135
>
> URL: http://svn.reactos.org/svn/reactos?rev=58135&view=rev
> Log:
> [REACTOS]
> - Fix the debugging macros I've introduced in r58132; in particular do not use while(true); for forbidding the user to continue execution, but instead raise an exception with EXCEPTION_NONCONTINUABLE flag (included when called RtlRaiseStatus).
> - Adjust the definition of RtlRaiseStatus (in kernel-mode it is ExRaiseStatus which is used).
>
> Modified:
> trunk/reactos/include/reactos/debug.h
>
> Modified: trunk/reactos/include/reactos/debug.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/debug.h?re…
> ==============================================================================
> --- trunk/reactos/include/reactos/debug.h [iso-8859-1] (original)
> +++ trunk/reactos/include/reactos/debug.h [iso-8859-1] Sun Jan 6 23:29:05 2013
> @@ -15,7 +15,7 @@
> #ifndef __INTERNAL_DEBUG
> #define __INTERNAL_DEBUG
>
> -/* Define DbgPrint/DbgPrintEx/RtlAssert unless the NDK is used */
> +/* Define DbgPrint/DbgPrintEx/RtlAssert/RtlRaiseStatus unless the NDK is used */
> #if !defined(_RTLFUNCS_H) && !defined(_NTDDK_)
>
> /* Make sure we have basic types (some people include us *before* SDK)... */
> @@ -51,7 +51,27 @@
> PCHAR Message
> );
>
> +#ifndef _NTDEF_ /* Guard against redefinition from ntdef.h */
> + typedef _Return_type_success_(return >= 0) LONG NTSTATUS;
> +#endif
> +__analysis_noreturn
> +NTSYSAPI
> +VOID
> +NTAPI
> +RtlRaiseStatus(
> + _In_ NTSTATUS Status
> +);
> +
> #endif /* !defined(_RTLFUNCS_H) && !defined(_NTDDK_) */
> +
> +
> +/* Fix usage of RtlRaiseStatus */
> +#if !defined(_RTLFUNCS_H) && defined(_NTDDK_)
> + #define RaiseStatus ExRaiseStatus
> +#else
> + #define RaiseStatus RtlRaiseStatus
> +#endif /* !defined(_RTLFUNCS_H) && defined(_NTDDK_) */
> +
>
> #ifndef assert
> #ifndef NASSERT
> @@ -136,11 +156,7 @@
>
> #endif /* not DBG */
>
> -/*
> - * These macros are designed to display an optional printf-like
> - * user-defined message and to break into the debugger.
> - * After that they allow to continue the program execution.
> - */
> +/******************************************************************************/
> /* For internal purposes only */
> #define __ERROR_DBGBREAK(...) \
> do { \
> @@ -148,6 +164,18 @@
> DbgBreakPoint(); \
> } while (0)
>
> +/* For internal purposes only */
> +#define __ERROR_FATAL(Status, ...) \
> +do { \
> + DbgPrint("" __VA_ARGS__); \
> + RaiseStatus((Status)); \
> +} while (0)
> +
> +/*
> + * These macros are designed to display an optional printf-like
> + * user-defined message and to break into the debugger.
> + * After that they allow to continue the program execution.
> + */
> #define ERROR_DBGBREAK(...) \
> do { \
> __NOTICE(ERROR, "\n"); \
> @@ -165,19 +193,18 @@
> * user-defined message and to break into the debugger.
> * After that they halt the execution of the current thread.
> */
> -#define ERROR_FATAL(...) \
> -do { \
> - __NOTICE(UNRECOVERABLE ERROR, "\n"); \
> - __ERROR_DBGBREAK(__VA_ARGS__); \
> - while (TRUE); \
> +#define ERROR_FATAL(...) \
> +do { \
> + __NOTICE(UNRECOVERABLE ERROR, "\n"); \
> + __ERROR_FATAL(STATUS_ASSERTION_FAILURE, __VA_ARGS__); \
> } while (0)
>
> #define UNIMPLEMENTED_FATAL(...) \
> do { \
> __NOTICE(UNRECOVERABLE ERROR, "is UNIMPLEMENTED!\n"); \
> - __ERROR_DBGBREAK(__VA_ARGS__); \
> - while (TRUE); \
> -} while (0)
> + __ERROR_FATAL(STATUS_NOT_IMPLEMENTED, __VA_ARGS__); \
> +} while (0)
> +/******************************************************************************/
>
> #define ASSERT_IRQL_LESS_OR_EQUAL(x) ASSERT(KeGetCurrentIrql()<=(x))
> #define ASSERT_IRQL_EQUAL(x) ASSERT(KeGetCurrentIrql()==(x))
>
>
>
With all respect, I don't understand many of these changes. Answering
between the lines.
On 04.01.2013 15:47, hbelusca(a)svn.reactos.org wrote:
> NTSTATUS
> @@ -643,7 +643,8 @@
> /* FIXME: TODO */
> DPRINT1("You have implemented the KD routines for searching PCI debugger"
> "devices, but you have forgotten to implement this routine\n");
> - while (TRUE);
> + UNIMPLEMENTED;
> + ASSERT(FALSE); // while (TRUE);
> }
It already prints a mandatory log message that this part is
unimplemented. And execution is supposed to stop after printing this
message, because it's meaningless to continue (that's why while(TRUE);
was put there in the first place).
>
> static ULONG NTAPI
> @@ -678,7 +679,7 @@
> {
> /* /PCILOCK is not yet supported */
> UNIMPLEMENTED;
> - while (TRUE);
> + ASSERT(FALSE); // while (TRUE);
> }
> #endif
> /* Now create the correct resource list based on the supported bus ranges */
It already has UNIMPLEMENTED; and now you added an ASSERT(FALSE); which
essentially is the same thing. And if continuation is possible, then
just UNIMPLEMENTED would be enough.
I'd like some general solution to this. Like, UNIMPLEMENTED_FATAL() or
something like that.
Any thoughts?
Regards,
Aleksey Bragin
Hello!
Due to Christmas and New Year holidays this month's status meeting makes
little sense. Preliminary it's rescheduled to January, exact dates will
be proposed after speaking to our team members.
Thank you all for your work in 2012, and bright future awaits us in
2013, I'm sure.
Best regards,
Aleksey Bragin
Hi,
due to a server move, one IPv6 link is currently down waiting for its replacing link (and for DNS update). Affected services are mainly Jira, Fisheye & Drupal website.
We are working on it. Sorry for the inconvenience.
IPv4 is all fine on those servers.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
I think that in the spec files semantics, destination strings are just
buffers and should be considered as pointers.
hbelusca(a)svn.reactos.org a écrit :
> Author: hbelusca
> Date: Wed Dec 26 19:26:08 2012
> New Revision: 58016
>
> URL: http://svn.reactos.org/svn/reactos?rev=58016&view=rev
> Log:
> [MSVCRT]
> Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are :
>
> int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src,
> int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag)
>
> and
>
> int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src,
> int srclen, char* dst, int dstlen, unsigned int codepage, int xflag)
>
> Needed by SVN.
>
> Modified:
> trunk/reactos/dll/win32/msvcrt/msvcrt.spec
>
> Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.sp…
> ==============================================================================
> --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 19:26:08 2012
> @@ -143,8 +143,8 @@
> @ cdecl __crtCompareStringW(long long wstr long wstr long) kernel32.CompareStringW
> @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW
> @ cdecl __crtGetStringTypeW(long long wstr long ptr)
> -@ cdecl __crtLCMapStringA(long long str long ptr long long long)
> -# stub __crtLCMapStringW
> +@ cdecl __crtLCMapStringA(long long str long str long long long)
> +@ cdecl __crtLCMapStringW(long long wstr long wstr long long long)
> @ cdecl __daylight() __p__daylight
> @ cdecl __dllonexit(ptr ptr ptr)
> @ cdecl __doserrno()
>
>
Hello,
starting now a new debug testbot slave is available. It is running VMware Player 5.0.1 under Linux x64.
It will run all the ISOs built by the Linux builder.
Its results are available at the usual place: http://www.reactos.org/testman with the name: CMake_x86_GCCLin (VMPlayer).
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hello and Merry Christmas!
I know there are people from various technical universities around the
world subscribed to this list.
If you work there, please reply to me, as I'm looking for some
collaboration related to Operating Systems theory course and ReactOS.
Thank you,
Aleksey Bragin
P.S. Crossposting to both ros-dev and ros-general is a bad idea, but I'm
doing this to reach out all our subscribers. Sorry for inconvinience.
