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, "We cannot afford the resources to
port to ARM."
I think on the contrary, the opposite might be true:
1. There is a hoard of developers over on the Raspberry Pi site right
now who would enjoy seeing ReactOS on the RaspPi.
2. There are device manufacturers who would like to free themselves
from the Apple/Google/Microsoft triumvirate and iOS/Android/Windows Phone 8
lock-in. Samsung recently announced its intent to explore other operating
systems.
http://news.cnet.com/8301-1035_3-57455054-94/would-samsung-ever-leave-androi
d-new-ceo-drops-hints/
3. The operating systems are not exactly easy to develop for. I have
read credible articles that Android is a mess from a development
perspective. ReactOS would be the operating system of choice for
straightforward development.
4. There are embedded systems companies who struggled in vain to get
Windows CE to behave like "Big Windows", but were unsuccessful because
restrictions in the Windows CE kernel. Many of them switch to Linux, but
quite a few still use some form of embedded Windows, and would welcome an
open-source Windows-like OS.
5. The United States Military has very large base of software that
they would like to put on lower-power systems (ARM) that is written for
Windows/i386. They are currently trying to port this software to Linux, with
varying degrees of success, not because they like Linux, but because they
need as much of the software to be open as possible. They would be
particularly attracted by the open-source nature of ReactOS, because the USA
national security vetting process requires that certain classes of software
be reviewed, line by line, by a certain US security agency. The singular,
totally exposed nature of ReactOS makes it attractive in this regard.
6. ReactOS.ORG would likely receive real money from device
manufacturers. Even a few dollars per-device would add-up very quickly.
7. There is NO mobile platform right now, among the Big Three, that
allows true, native, C/C++ development. Each of these platform plays a game
where the native code is invoked by some shell, even in the case of Windows
Phone 8, despite Microsoft's claim that Windows Phone 8 supports native
development. [It depends on what your interpretation of native development
is.]
ARM device manufacturers are all stuck in the same boat. Most of these
companies are actually not very good at OS design. Think about it: Nokia was
a multi-billion-$US company that was using an operating system (Symbian)
that was so broken and toxic to innovation that it almost drowned their
company. What did they do to fix this problem? They adopted a closed OS from
Microsoft. Manufacturers, actually, do not like having closed software. It
eliminates their opportunity for differentiation. If ReactOS were made to
run on a single manufacturer's device, the other manufacturers would become
nervous, and insist on having the same access as does their competitor.
There is nothing wrong with making these manufacturers pay a small fee to
support the ReactOS Foundation, and they would gladly pay it, if we
developed killer applications for their devices.
Of course, because most of ReactOS, in theory, should be portable, software
working on ARM is software working on x86_32/x86_64. I would also like to
mention here that there are a lot of developers who would much rather have a
stable kernel, and a paucity of user-mode applications, versus an unstable
kernel, and a plethora of user-mode applications. User mode applications
will be created by the hoard, *if* the kernel is stable. If the kernel is
not stable, the incentive to do anything else is greatly reduced.
This is the opportunity I see. My biological clock is telling me that 2013
is the year to pursue this effort. The market is waiting. But an effort like
porting to ARM should not be done haphazardly or opportunistically. It
should be done with deliberation and intent.
Just my opinion.
-John
Hi,
I had forgotten all about BOCHS. It is amazing how many emulators there are on the market these days.
I think that, for mass appeal, we should try to get ReactOS to run natively. The problem is that there are basically two types of users of ReactOS:
1. Those who enjoy OS development.
2. Those who do not enjoy OS development. :)
#1 is the type that might run ReactOS inside an emulator.
#2 is the type that would probably never run ReactOS inside an emulator, even if ReactOS were stable.
Unfortunately, for all the people who might run ReactOS someday [millions and millions of people] the ratio #1/#2 is probably less than 1/100, conservatively speaking.
Therefore, it makes sense to get ReactOS to run on as many of the devices that users of type #2 would use. That leads to the following reasoning:
There are several popular CPU's on the market. X86_32/x86_64 rules the desktop. ARM is 90% of mobile devices. And there is the "other" category, which is less than 10% of all new devices, including mobile.
Since it is not (yet) likely that a user of type #2 will remove Microsoft Windows from an existing device and replace it with ReactOS, even if ReactOS were stable, one must conclude that the best way to get ReactOS onto as many devices as possible is to make ReactOS the first OS on the device before any other OS has a chance to be on the device. That means new devices.
New devices come with Microsoft Windows, iOS, or Android. Getting HP, Dell, ASUS, Acer, etc..to start using ReactOS instead of Microsoft Windows on their hardware is an up-hill battle and not likely to succeed. Apple hardware, of course, is out of the question. That leaves Android hardware, which is more vulnerable, IMO, than people might think. Google does not own these devices. As Timo showed, there are manufacturers in China/Taiwan/Korea, etc. that make Android hardware very cheaply. Those manufacturers choose Android, but they could choose whatever they desire.
So I think that getting ReactOS to run on just one, commonly-available, mobile device, like an ARM-based SmartPhone, that is made by a hardware manufacturer who is not committed to Android or any other OS, would open the flood-gates.
I would not worry about the number of available "apps" on ReactOS on ARM, because there are many, many developers who know how to write applications for Microsoft Windows on x86_32/x86_64, and therefore, for ReactOS on ARM, and they will be immediately attracted by the open nature of ReactOS. Also, I suspect that the following technique for converting Windows-on-x86_32 applications to ReactOS-on-ARM will work:
http://www.reactos.org/forum/viewtopic.php?f=9&t=12262
Cheers!
-John
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of HeChi-Lau
Sent: Saturday, January 19, 2013 10:20 AM
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Ros-dev Digest, Vol 101, Issue 30
Hey，Do you know the BOCHS？An x86 emulator.Its android version works fine through the JNI library.Reactos also runs okay.But I configured the net card in conf file,nothing effected.
In my opinion if anyone could develop a similar,but advanced software:it included full hardward support and released with reactos.Or just add the x86 vm or in reactos's kernel,and then reactos can work with arm cpus.After one of I said above done,I believe more people will know reactos and use it.
reactos has some advantages that other os can't compared with.such as free,fully opensource,pe compatible,low memory usage and fast boot and shutdown.If application experience be better，it will be finer.
Hey，Do you know the BOCHS？An x86 emulator.Its android version works fine through the JNI library.Reactos also runs okay.But I configured the net card in conf file,nothing effected.
In my opinion if anyone could develop a similar,but advanced software:it included full hardward support and released with reactos.Or just add the x86 vm or in reactos's kernel,and then reactos can work with arm cpus.After one of I said above done,I believe more people will know reactos and use it.
reactos has some advantages that other os can't compared with.such as free,fully opensource,pe compatible,low memory usage and fast boot and shutdown.If application experience be better，it will be finer.
ros-dev-request(a)reactos.org wrote:
Send Ros-dev mailing list submissions to
ros-dev(a)reactos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
ros-dev-request(a)reactos.org
You can reach the person managing the list at
ros-dev-owner(a)reactos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."
Today's Topics:
1. Re: Status of ARM Development (J. C. Jones)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Jan 2013 19:23:50 -0600
From: "J. C. Jones" <jaibuduvin(a)gmail.com>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Status of ARM Development
Message-ID: <00af01cdf5e3$a37f1b50$ea7d51f0$(a)gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi RMS,
What happen to your port?
-John
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of rms(a)velocitylimitless.org
Sent: Wednesday, December 26, 2012 6:04 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Status of ARM Development
I actually did get a simple port of freeloader and reactos working on my iPod touch a while ago. :P
On Dec 25, 2012, at 4:55 AM, Herm?s B?LUSCA - MA?TO <hermes.belusca(a)sfr.fr> wrote:
Well, I fear Igor is right.
Herm?s.
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la part de Igor Paliychuk
Envoy? : mardi 25 d?cembre 2012 07:16
? : ReactOS Development List
Objet : Re: [ros-dev] Status of ARM Development
If you want to help, go ahead. If you are just asking, the answer is: "There is no work on ARM port going on because there are no human resources for doing that". Well, at least afaik.
2012/12/25 J. C. Jones <jaibuduvin(a)gmail.com>
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM port. It seems that, with the current lock-down of all three major mobile platforms (iOS/Android/Windows Phone 8), as well as the impending surge in 2013 of ultra-cheap mobile devices like tablets based on ARM, and of course, the loveable Raspberry Pi, a truly open Windows-oriented platform is more needed than ever.
J.C.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5987 - Release Date: 12/25/12
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM
port. It seems that, with the current lock-down of all three major mobile
platforms (iOS/Android/Windows Phone 8), as well as the impending surge in
2013 of ultra-cheap mobile devices like tablets based on ARM, and of course,
the loveable Raspberry Pi, a truly open Windows-oriented platform is more
needed than ever.
J.C.
Hi All,
I had quick chat with Amine and others, and for the time being, I will pick
up where I let off in creating a Visual Studio ReactOS.sln with the
following features:
1. A single ReactOS.sln file that is interchangeable between Visual
Studio 2010 and Visual Studio 2012.
2. A single ReactOS.sln file that incorporates all 800+ .vcxproj files
and allows all 800+ project to be viewable within a single session of Visual
Studio.
3. No (serious) performance problems with load of the ReactOS.sln file
or .vcxproj files.
4. An arrangement in the Solution Workspace that mirrors the structure
of the ReactOS repository on disk.
5. The ability to build all applications or drivers by right-clicking,
within Solution Workspace, on the folder named applications or drivers and
doing clicking Build.
6. Visibility of the lang directories in the Solution Workspace.
7. Visibility of all SVN files in the Solution Workspace, including
CMakeLists.txt files.
8. Support for Debug and Release project configurations.
9. Support for x86_32, x86_64, ARM platform configurations.
10. Self-relative paths for all .h's and .libs's so that solution can be
moved by the developer on his/her local hard disk without consequence.
11. No need to download any extraneous tools. User should be able to type
in SVN URL, either from within Visual Studio, or with Windows Explorer, pull
ReactOS repository, load ReactOS.sln, and start editing/compiling/linking,
debugging.
With the CMakeLists.txt files, the information needed is already present.
With Amine's latest work of actually generating the .vcxproj files, things
become even easier. However, as I have two other moderate projects going
concurrently, one of which I just started, this will take some time. I will
provide updates as I go along.
Cheers,
-John
Hi All,
Some of you might have seen my recent on the post regarding the build
process:
http://www.reactos.org/forum/viewtopic.php?f=9&t=12240&start=15
As I mentioned, it would help greatly to lower the barrier-to-entry to
less-experienced developers, as well as more experienced developers who
might have limited time budgets [Who among us does not have a limited time
budget?].
I wanted to send out this message to let everyone know that I intend to use
what bit of time that I available right now, at the beginning of January, to
tackle this issue head-on. Again, my purpose here is not to step on anyone's
toes, but make certain that we never turn away a potentially-valuable
contributor simply because they are unnecessarily removed from their
development comfort zone. I do realize that there is already on-going work
on the build process, and I have no intention of interfering with that.
I will wait 24-hours for any objections/reservations from now before making
a hard commitment, but frankly, we really to get this done, like right now.
Happy New Year. :)
-JC
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
