Ros-dev January 2013

ros-dev@reactos.org

17 participants
23 discussions

ReactOS On ARM/Raspberry Pi
by J. C. Jones 20 Jan '13

20 Jan '13

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

7 11

ReactOS: Execute Natively or Virtually?
by J. C. Jones 19 Jan '13

19 Jan '13

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.

2 1

Re: [ros-dev] Ros-dev Digest, Vol 101, Issue 30
by HeChi-Lau 19 Jan '13

19 Jan '13

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

1 0

Status of ARM Development
by J. C. Jones 19 Jan '13

19 Jan '13

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.

5 6

Notice Of Intent - Visual Studio Build of ReactOS - Take III
by J. C. Jones 13 Jan '13

13 Jan '13

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

2 2

Notice Of Intent - Visual Studio Build of ReactOS
by J. C. Jones 13 Jan '13

13 Jan '13

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

8 33

Notice Of Intent - Visual Studio Build of ReactOS - Take II
by J. C. Jones 12 Jan '13

12 Jan '13

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

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 58154: [REACTOS] Fix the debugging macros introduced in r58132 (for the _FATAL case): do not use exceptions but instead a breakpoint followed by a process termination procedure (or a bug...
by Timo Kreuzer 12 Jan '13

12 Jan '13

Why not use NtTerminateProcess() for non-native apps? Am 10.01.2013 02:45, schrieb hbelusca(a)svn.reactos.org: > +/* > + * Declare a target-dependent process termination procedure. > + */ > +#ifndef_NTDDK_ /* User-Mode */ > + #ifndef NTOS_MODE_USER /* Should be Win32 */ > + #ifndef _WIN32 > + #error "Unsupported target." > + #else > + #define TerminateCurrentProcess(Status) TerminateProcess(GetCurrentProcess(), (Status)) > + #endif > + #else /* Native */ > + #ifndef _PSFUNCS_H > + NTSYSCALLAPI > + NTSTATUS > + NTAPI > + NtTerminateProcess( > + IN HANDLE ProcessHandle, > + IN NTSTATUS ExitStatus > + ); > + #endif > + #ifndef NtCurrentProcess > + #define NtCurrentProcess() ((HANDLE)(LONG_PTR)-1) > + #endif > + #define TerminateCurrentProcess(Status) NtTerminateProcess(NtCurrentProcess(), (Status)) > + #endif > +#else /* Kernel-Mode */ > + #include <bugcodes.h> > + #define TerminateCurrentProcess(Status) KeBugCheckEx(CRITICAL_SERVICE_FAILED, (Status), 0, 0, 0) > +#endif > +

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 58135: [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...
by Timo Kreuzer 08 Jan '13

08 Jan '13

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)) > > >

2 4

Re: [ros-dev] [ros-diffs] [hbelusca] 58110: while (TRUE); (when something is unimplemented) ---> ASSERT(FALSE); // while (TRUE); (unless we deal with a 'noreturn' function), and in some cases, return an adequate value. Part...
by Aleksey Bragin 05 Jan '13

05 Jan '13

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

5 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2013