Hi All,
Before I reach the point where I am thinking the same way as everyone else,
which will inevitably happen (The Borg - resistance is futile), I wanted to
get some thoughts out:
A question that many have asked is, "Why not port ReactOS to ARM?"
The answer is usually something like,
I suggestasln fileineach directory.Onlyasln fileis too big,very slow to load.
At 2013-01-11 07:01:28,"J. C. Jones" wrote:
Hi All,
I wanted to give an update since it has been a few days.
As you know, Amine was already in the process of generating Visual Studio .sln
and .vcxproj files f
**
On Fri, Jan 11, 2013 at 4:41 AM, J. C. Jones wrote:
> "*Why not port ReactOS to ARM?"*
IIRC a port is ongoing. i dont know too much about its status through
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/r
Hi !
> 4. Developer executes cmake version.
This is just to see that indeed cmake is reachable in your current console
session, and it must display:
cmake version 2.8.10.2-ReactOS
Cheers,
Hermès
-
Op 11-1-2013 11:36, Javier Agustìn Fernàndez Arroyo schreef:
/__/
On Fri, Jan 11, 2013 at 4:41 AM, J. C. Jones mailto:jaibudu...@gmail.com>> wrote:
"/_Why not port ReactOS to ARM?"_/
As was in the news today, start with an already ARM-enabled operating
system (Linux, I'd suppose) and run
If anyone is porting ReactOS to ARM, I would like to know about it, so there
is not any redundancy in effort. J
-John
From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
Behalf Of Javier Agustìn Fernàndez Arroyo
Sent: Friday, January 11, 2013 4:36 AM
To: ReactOS Develo
Why not use NtTerminateProcess() for non-native apps?
Am 10.01.2013 02:45, schrieb hbelu...@svn.reactos.org:
+/*
+ * Declare a target-dependent process termination procedure.
+ */
+#ifndef_NTDDK_ /* User-Mode */
+#ifndef NTOS_MODE_USER /* Should be Win32 */
+#ifndef _W
Am 11.01.2013 06:48, schrieb BinSys:
I suggest a sln file in each directory. Only a sln file is too big,
very slow to load.
I agree, but before changing this, we should measure a possible
performance impact on the configure operation. (We are talking about
generating a few hundred solution fi
This is certainly feasible, but is seriously skirting the issue. And when
you achieve it, it is like a toy. No "average" user will ever use ReactOS in
this way on a regular basis. And even "non-average" users will try it,
experiment with it, and say, "Hmm..That's nice!" Then they will push it
aside
Having a solution for each project is like having a separate build system
for each project.
You could probably break it down to between 5-10 solutions, having one for
each major area of the build but anything more would be detrimental to the
advantages of using VS.
From: Timo Kreuzer
Reply-To:
I would caution everyone to not forget the whole purpose of using Visual
Studio is to make development by Visual Studio users easier, not harder.
Generating .sln files that can be loaded in this way, even if the generation
operation takes less than 1 second, would still result in 800 .sln files.
Th
11 matches
Mail list logo