- Ros-dev - ReactOS.org

ReactOS and Viruses
by Rick Langschultz 24 Nov '04

24 Nov '04

Sun will be releasing Solaris 10 shortly as a commercial product available for purchase. There is a new file system that is 128-bit, and is protected by md5 checksums, I think this is a great idea for reactos. I think before a program executes there should be a binary verifier that checks this checksum and then allows the program to run. This would help in deterring Windows viruses from attaching themselves to reactos binaries. Since ReactOS is open source it will be harder to protect a binary if there is an attack and a malicious user replaces a dll or an exe. Perhaps this can be done using a small xml file or a txt file called md5sums or something. Please let me know what you think.

5 6

Idea to protect ReactOS
by Jeff Smith 24 Nov '04

24 Nov '04

With the issue of Ekush talking about sending us patches once they publish thier code and what not I as many of you are worried about being tainted, I have an idea, but I don't know how safe it is from a GPL stand point (I know nothing of the GPL) here's the idea, when we get patches that are questionable from *any* source, we send MS a copy of the suggested patch, and request they compare it with thier code to see if it is differant or the same as thier Windows code, if MS comes back and says it's teh same we delete the patch and move on... I know this idea sounds bad but we need to discuss a plan for any potential tainting and how we'd deal with it, please if you don't like my idea then please by all means suggest something else.

12 16

Windows NT architecture
by Maritn "E.T." Misuth 24 Nov '04

24 Nov '04

Hello people, can you post some sources (links etc.) where I can find some info about internal NT kernel structure/architecture/whatever suitable for lamers and newbs like me?

4 3

Ekush.com up again
by Ibrahim Damlaj 23 Nov '04

23 Nov '04

I don't know if anyone has been to ekush.com recently: > " We are also decided to remove all the non-GPL'd code from our source tree and re-publishing the project based on React OS and Wine. All the Ekush sources will be merged to the React OS tree; sources and binary both will be published accordingly under the GNU GPL and EKUSH.COM will be the official web home for Ekush OS. Hope it will eliminate all the confusion and misunderstanding regarding Ekush Operating System. "

7 8

[Fwd: [ros-cvs] CVS Update: reactos] BUG 446 Fixed - NIC Realtek8139
by Gge 23 Nov '04

23 Nov '04

The bug 446 is fixec and can be closed following this commit The nic driver Realtek8139 loads and start successfully Regards Gerard

1 0

core reorg. request
by Gunnar Dalsnes 23 Nov '04

23 Nov '04

Hi, Does anyone object agains: -moving every NtXxx functions into new files under ntoskrnl\nt? -moveing functions related to ob managed types into new files (thrdobj.c, procobj,c, eventobj.c, fileobj.c etc)? This will make it clearer where the functions are and what they do. Gunnar

4 4

Is ROS-CVS ever going to work?
by Richard Campbell 22 Nov '04

22 Nov '04

Is the ROS cvs list ever going to be functional again? Richard

1 0

RE: [ros-diffs] [CVS reactos] fix kernel queues + misc fixes/cleanups
by Casper Hornstrup 21 Nov '04

21 Nov '04

I really would like to see less "Fixed feature X" commit messages. Sometimes a features is "fixed" more than once in a short period of time. Please specify what was changed in the commit message so others have a better chance of knowing what was actually changed (without looking through the whole patch to figure it out). I'm not saying that simple typos or other trivial changes couldn't have a "Fixed X" commit message, just that the non-trivial ones shouldn't. Casper

1 0

headers suggestion
by Jonathan Wilson 21 Nov '04

21 Nov '04

In light of e.g. http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html I would like to suggest the following header ideas. Currently MingW has: 1.A set of headers that contain a copy of part of the platform SDK 2.Some extra stuff (like that ntdll.h) 3.A set of headers that contain a copy of part of the windows DDK 4.Mabie again some extra stuff MS doesnt have (I dont know) 5.A set of headers that contain a copy of part of the visual C++ runtime library 6.Some extra stuff (mainly bits required to deal with differences between GCC and Visual C I think) WINE has: 1.A set of headers that are supposed to contain a copy of part of the platform SDK (although some things have been claimed to be wrong) 2.A set of headers that are supposed to contain a copy of part of the visual C++ runtime library (although again there may be things that are wrong) and 3.Extra definitions for stuff in both header sets microsoft doesnt define in the platform SDK (e.g. internal bits, functions microsoft doesnt document etc) ReactOS has: w32api (the ROS import of it) include/ddk (the ReactOS version of the windows DDK) include/wine (the WINE windows API headers) include/msvcrt (the MSVCRT headers ROS uses to build and link with msvcrt) include (various misc ReactOS specific headers) What I suggest for ReactOS (and I think some of this is already being done) is as follows: grab any headers from include/* that are public DDK headers (if there are any) and make sure they are all in include/ddk grab everything from the current WINE headers MingW is missing. Check that its all correct and stuff and add it to the ReactOS import of w32api. (if anything is found to be wrong in the wine headers, it should be fixed) grab anything from include itself and add to w32api as needed Get permission to relicence the stuff and contribute back to the main w32api tree. grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE and also mingw-runtime. Create one set of header files from the 3 sets such that it matches the microsoft headers as closely as possible. Merge w32api DDK headers with ROS DDK headers and create one set that, again, matches the MS headers. For w32api/mingw-runtime, the suggestion is that they look at all the "new stuff" generated by the merging of the 3 sets of msvcrt headers plus the ROS/WINE/w32api merger plus the DDK merger and look at acccepting it. For WINE, I suggest they start using the new "merged" headers if at all possible. Basicly, the idea is that mingw-runtime would become the "definitive" set of msvcrt.dll headers out there and that ReactOS, MingW and WINE would start using it for any case where you are talking to msvcrt.dll from the public side. both ROS and WINE would then have their own internal msvcrt headers as necessary to build their msvcrt* builds Then, w32api would become the "definitive" set of win32 api headers and would contain as much of the Microsoft Platform SDK as people have legally cloned. All userland components of ReactOS (as well as kernel-side bits that need the stuff in the userland headers e.g. win32k.sys) would use this. Be nice if WINE were to use this too but because of what WINE is and how it is built/used, there may be reasons for the WINE team not to use w32api as the build headers used to build WINE. And, there would be one "definitive" set of DDK headers which would be good enough for building ReactOS with. And for building any kernel-side stuff WINE decides to add (e.g. that stuff to load the device drivers for vaerious copy protection systems that was being worked on). And for anyone using MingW and MingW GCC to build kernel-mode stuff. Anything private or project specific would go into a set of private headers as needed for the different projects and sub-sections (dlls etc) within them Anything exported by microsoft but undocumented would go into a set of "undocumented" headers (which could then be shared between ReactOS and WINE since I dont think w32api would accept anything not documented in MSDN) Just suggestions btw, if they are good, say so If they are bad, say so (and say why) If there are issues with my idea, say what they are.

4 12

File format and message box icons
by Klemens Friedl 21 Nov '04

21 Nov '04

Hi! I created 13 file format icons (bmp, dll, gif, jpg, mid, mp3, png, psd, rtf, tif, txt, unknown, wav) and 5 message box icons. I hope the icons are useful for ReactOS! License: GNU LESSER GENERAL PUBLIC LICENSE File Format Icons: -> http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic arts&cat=icons&mdnr=58 or -> http://reactos.com/bugzilla/show_bug.cgi?id=449 Message Box Icons: -> http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic arts&cat=icons&mdnr=57 or -> http://reactos.com/bugzilla/show_bug.cgi?id=448 I also built a ReactOS compatibility database (for applications and device drivers) and media files for ROS. Klemens Friedl -- NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl GMX DSL-Netzanschluss + Tarif zum superg�nstigen Komplett-Preis!

2 2

booting ros is broken (was: fix broken work item impl.)
by Hartmut Birr 21 Nov '04

21 Nov '04

Hi, I've added the 'work item fix' to my source tree for testing. I'm not able to boot reactos. Ros hangs somewhere in ndis: ... (ldr/loader.c:319) Could not open module file: \SystemRoot\system32\drivers\DLKRTS.SYS (io/pnpmgr.c:1521) Initialization of service DLKRTS failed (Status c0000001) DriverBase for \SystemRoot\system32\drivers\pci.sys: 9cd89000 Peripheral Component Interconnect Bus Driver (io/create.c:90) Parent is a Directory which is neither a file type nor a device type (io/pnpmgr.c:1521) Initialization of service Ne2000 failed (Status c0000001) DriverBase for scsiport.sys: 9cd93000 DriverBase for atapi.sys: 9cd9f000 DriverBase for aic78u2.sys: 9cdc9000 DriverBase for class2.sys: 9ce6b000 DriverBase for disk.sys: 9ce75000 DriverBase for vfatfs.sys: 9ce7e000 DriverBase for bootvid.sys: 9ce93000 DriverBase for ndis.sys: 9ceb4000 (ndis/main.c:52)(DriverEntry) Called. (ke/main.c:710) CommandLine: multi(0)disk(0)rdisk(0)partition(3)\ReactOS Without the fix, booting continues after that point with: DriverBase for \SystemRoot\system32\drivers\DLKRTS.SYS: 9cf09000 (ndis/miniport.c:1090)(NdisInitializeWrapper) Called. (ndis/miniport.c:1631)(NdisMRegisterMiniport) Called. (ndis/miniport.c:1577)(NdisIAddDevice) LinkageKey: Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0002\Linkage. (ndis/miniport.c:1374)(NdisIStartAdapter) creating device \Device\DLKRTS1 (ndis/miniport.c:1394)(NdisIStartAdapter) opened device reg key (ndis/miniport.c:1396)(NdisIStartAdapter) acquiring miniport block lock ... - Hartmut

4 4

KQUEUE race condition
by Filip Navara 21 Nov '04

21 Nov '04

Hi, I think I found a race condition in KQUEUE code, but I'm not sure my solution is optimal. If no items are queued, KeRemoveQueue calls KeWaitForSingleObject and then after it finishes it acquires dispatcher lock and removes a list item. The problem arises when someone calls KeRemoveQueue just after the KeWaitForSingleObject call finishes and before the dispatcher lock is acquired. In this case he can remove the last item in the list and this will cause the first KeRemoveQueue (the one that waited) to return garbage. Can anybody think of better solution than the attached patch? Regards, Filip Index: ntoskrnl/ke/queue.c =================================================================== RCS file: /CVS/ReactOS/reactos/ntoskrnl/ke/queue.c,v retrieving revision 1.11 diff -u -r1.11 queue.c --- ntoskrnl/ke/queue.c 15 Aug 2004 16:39:05 -0000 1.11 +++ ntoskrnl/ke/queue.c 21 Nov 2004 00:39:52 -0000 @@ -159,27 +159,38 @@ return ListEntry; } - //need to wait for it... - KeReleaseDispatcherDatabaseLock (OldIrql); - - Status = KeWaitForSingleObject(Queue, - WrQueue, - WaitMode, - TRUE,//Alertable, - Timeout); - - if (Status == STATUS_TIMEOUT || Status == STATUS_USER_APC) - { - return (PVOID)Status; - } - else + for (;;) { - OldIrql = KeAcquireDispatcherDatabaseLock (); - ListEntry = RemoveHeadList(&Queue->EntryListHead); + //need to wait for it... KeReleaseDispatcherDatabaseLock (OldIrql); - return ListEntry; - } + Status = KeWaitForSingleObject(Queue, + WrQueue, + WaitMode, + TRUE,//Alertable, + Timeout); + + if (Status == STATUS_TIMEOUT || Status == STATUS_USER_APC) + { + return (PVOID)Status; + } + else + { + OldIrql = KeAcquireDispatcherDatabaseLock (); + + /* + * Prevent a race condition. If someone calls KeRemoveQueue + * just after we end up waiting and before acquiring the spin + * lock he can get the last item in the list... + */ + if (IsListEmpty(&Queue->EntryListHead)) + continue; + + ListEntry = RemoveHeadList(&Queue->EntryListHead); + KeReleaseDispatcherDatabaseLock (OldIrql); + return ListEntry; + } + } }

3 3

Keyboard layout DLLs
by Casper Hornstrup 20 Nov '04

20 Nov '04

These are a big mystery to me. I'd like to document how to create them, but I need to know how to create them first. Please send me any information you have on them. Casper

4 3

A call for help getting putty working
by art yerkes 20 Nov '04

20 Nov '04

I'm hoping to get putty working to use as another test case for the network code. I'm running into problems right now, however and could really use a hand. There are two versions of putty in here, built with symbols as well as a diff against the original sources and a mingw-able makefile named makefile.mgw I haven't tried the mingw makefile on windows but it shouldn't take too much effort. putty-noshow differs from the release putty only in that it contains debug messages and symbols. The putty dialog is created and the caret timer even fires, but the window is never shown. w3seek thinks that the dialog functions in user32 and win32k are correct, but the dialog shows on windows and wine so something is wrong. If I add a ShowWindow as in putty-show, the dialog shows, so the problem is clearly in reactos. I'm seeing some random crashes as well accessing the registry that will be the subject of another mail. my putty musings: http://64.81.145.152/~arty/putty.zip Putty page: http://www.chiark.greenend.org.uk/~sgtatham/putty/ -- Here's a simple experiment. Stand on a train track between two locomotives which are pushing on you with equal force in opposite directions. You will exhibit no net motion. None the less, you may soon begin to notice that something important is happening. -- Robert Stirniman

4 7

headers in reactos/w32api/include and reactos/include/wine
by Steven Edwards 20 Nov '04

20 Nov '04

Does anyone care if I merge the duplicate headers from reactos/include/wine in to the headers in the reactos/w32api/include folder? There are a few headers we will want to keep in reactos/include/wine but now that we have our own copy of the w32api we dont need most of these headers that do the #include_next thing. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

7 10

Request for use of Logo on items at CafePress
by Wierd Wierd 19 Nov '04

19 Nov '04

I have set up an account at CafePress, and would like to make some ReactOS merchanise, for advertisment purposes. I do not intend on adding a retail markup to the base price of the items in question- the prices will be solely the price mandated by CafePress for fabrication and shipment. (this means I make nothing) Some of the items that can be made, include Mugs, buttons, mousepads, T-shirts, hoodies... ...Thongs... and other misc. items. I think it could have utility for us as a project, on occasions where we are promoting our project-- Things like "ReactOS Developer" buttons for our booth sitters, etc... I would like a "Yeah"/"Nay" vote, and then I may require a written letter of permission allowing me to use the logo. (The letter is required by the CafePress legal terms of service contract) Please let me know what you think of the idea. __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

5 4

RE: [ros-dev] question about some old changes (hartmut)
by Hartmut Birr 19 Nov '04

19 Nov '04

Hi, >What was the reason for these changes? It looks like a workaround for some other bug. it is a nice question after more than one year. >http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/ntoskrnl/ke/wait.c.diff?r 1=1.51&r2=1.52 KeRemoveAllWaitsThread was called in two situations. One was a real unblocking of the thread, if the thread was waiting on a waitable object which was signaled. The other was the terminating of the thread by an other thread. In this case KeRemoveAllWaitsThread has worked if the thread was waiting on a waitable object. If the thread was simply suspended, RemoveEntryList has bug checked because Waiter->WaitListEntry wasn't in any list. The reason for these changes was the implementation of the CTRL-C handlers in csrss. - Hartmut

2 2

fix for regedit
by Christian Koinig 19 Nov '04

19 Nov '04

This fixes the problem with regedit (regedit freezes after opening a child window). Regards Christian ------------------------------------------------------ Index: framewnd.c =================================================================== RCS file: /CVS/ReactOS/reactos/subsys/system/regedit/framewnd.c,v retrieving revision 1.11 diff -u -p -r1.11 framewnd.c --- framewnd.c 11 Oct 2004 21:08:05 -0000 1.11 +++ framewnd.c 18 Nov 2004 21:56:01 -0000 @@ -670,8 +670,10 @@ FrameWndProc(HWND hWnd, UINT message, WP OnMenuSelect(hWnd, LOWORD(wParam), HIWORD(wParam), (HMENU)lParam); break; case WM_ACTIVATE: - if (LOWORD(hWnd)) - SetFocus(g_pChildWnd->hWnd); + // I don't know what this is supposed to do (except for creating an infinite "setfocus loop"). + // If someone ever figures it out put it back in plz. + //if (LOWORD(hWnd)) + // SetFocus(g_pChildWnd->hWnd); break; case WM_DESTROY: WinHelp(hWnd, _T("regedit"), HELP_QUIT, 0); ------------------------------------------------------

5 4

Greenville: The story of Freetype VS the windows rasterizer---
by Wierd Wierd 19 Nov '04

19 Nov '04

Hey everybody- I seem to be consistantly running into troubles with Freetype and Greenville. I suspect the problem stems from Freetype trying to render the glyph with too many shades of grey, and I *SERIOUSLY NEED* somebody to fix it. Here is a more technical view of the situation, and the problem: The TrueType hinting system allows each pixel to be subdivided into sub-units. There are 81 subunits per pixel, in a 9x9 grid, with the center being the origin point. So, it looks something like this: 87654321012345678 7XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 0XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 7XXXXXXXXXXXXXXXX 8XXXXXXXXXXXXXXXX That represents the total number of subunits, and their coordinate placements within 1 pixel. The windows rasterizer determines the 'shade' the pixel will get, based on % of coverage this pixel gets from the outline, as does freetype. The problem shows up, because The windows type rasterizer only renders 16 shades, including Black and White, while the Freetype one renders 256 shades. There are only 81 units, however. What does this mean? It means that under freetype as it currently stands, if even *ONE* pixel subunit is covered by an outline, it will render as a shade of grey--- While the exact same pixel, with the windows rasterizer, will render as 'white' instead. This is because "white" is 1/256th coverage, and there are only 81 subunits-- Essentially meaning that in order to get 'white' out of freetype, the pixel cannot be touched *AT ALL* by the glyph outline. On the windows rasterizer, there are only 16 shades of grey, so up to 1/16th of the area can be covered, and still rendered as 'white'-- or 5 subunits covered. This is why the windows rasterizer produces crisper images than Freetype. I don't know how to fix this behavior in Freetype, and *SERIOUSLY* need said behavior changed, As soon as possible. Thank you. __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

4 3

RE: [ros-dev] ReactOS Versions
by Waldo Alvarez Cañizares 18 Nov '04

18 Nov '04

Hi Rick: I think you mean something like the make xconfig or make gconfig you can do when building the Linux kernel. Hmm I think if that´s what you mean ROS could have a little GUI application to configure the system. I mean to make life easier to non-programmers that wish to build a custom system. That's one of the things Linux users enjoy very much and I think that would be good for ROS too and won't take very long to do. Also if it is done general enough won't have to be maintained in the future. Well at least not that much. Regards Waldo ________________________________ De: ros-dev-bounces(a)reactos.com en nombre de Rick Langschultz Enviado el: Jue 11/11/2004 6:53 p.m. Para: ros-dev(a)reactos.com Asunto: [ros-dev] ReactOS Versions When ReactOS is built and runs windows executables stabily I think we should have a program for windows that will let you customize the platform like windows ce and compile it with all the features you want. I think that it would be a great idea because of different types of systems such as PBX/VOIP servers, application servers, and domain name servers. This would allow security to be integrated into ReactOS by limiting programs allowing open ports, and Denial of service attacks. Maybe even support for multiple architectures like SH, ARM, X86, AMD64, PPC??? With FAT, FAT32, NTFS, XFS, EXT3, EXT2, and many others. Maybe even a rom based os... Please tell me what you all think.

2 1

"no current process" problem
by Gunnar Dalsnes 18 Nov '04

18 Nov '04

Hi. I'm was fixing some code, se\semgr.c->SeLockSubjectContext/SeUnlockSubjectContext, where apc's were not disabled before/after ExAcquireResourceExclusiveLite/ExReleaseResourceLite using KeEnterCriticalRegion/KeLeaveCriticalRegion. KeEnterCriticalRegion/KeLeaveCriticalRegion access current thread and this triggers bsod->"no current process". call chain: CmInitializeRegistry->ObCreateObject->SeCaptureSubjectContext->SeLockSubject Context CmInitializeRegistry is called in ke\main.c before the initial process is created. What should i do? Add checks for if the current process/thread exist or not in KeEnterCriticalRegion/KeLeaveCriticalRegion or is there some other way to fix this? Gunnar

1 0

Hmm, another petition:
by Lucio Diaz 18 Nov '04

18 Nov '04

As someone have stated in the forum, the Roadmap is YEARS old, could you send me the projects you are working in, and the expected (realist ones) dates of conclusion. That way i could make a new roadmap. Thankyou again, Lucio Diaz. ______________________________________________ Renovamos el Correo Yahoo!: ¡100 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es

6 5

Loading ReactOS from Floopy
by Lucio Diaz 18 Nov '04

18 Nov '04

I am working in a Howto for installing ReactOS, so i tried the diferent ways for instalating it, but in recent builds there was no option to install the Freeloader in a diskete (XP machine here) in the Real Hardware instalation. I tried downloading the binaries and copying them to C:\ReactOS , download the Freeloader image and RAWwrite it in a diskete, but i could not get the configuration screen (it worked for me, but maybe not for others without configuration options) Is there any way i could install the Freeloader image and still have a "normal" configuration phase of ReactOS.? This will help convince people to install reactOS, not having to touch the Boot sector for a ReactOS insatllation regardless the OS you have installed would be great. I imagine something like this: -------------------------------------- 1) Download the ReactOS binaries (8 Megs) from sourceforge 2) Use Winzip to extract them to C:\ that way a Folder called C:\ReactOS will be created with all the reactos files(It must be a FAT32 partition). 3) Download the Program Rawwrite for windows and extract it to any folder you wish. 4) Download the Freeloader Floopy Disk image and extract it to any folder you wish. 5) Insert a new formated Floopy Disk and Execute Rawwrite: 6) Select the image file from the folder you extracted the Freeloader: 7) Press write, and wait till the program ends writing the image to the Floopy. 8) Restart the computer booting from the Floopy Disk: ---------------------------------------- This is the option i would like as user. Copy the program to a folder, and the use a Diskete to load it. Usefull both in 95/98/NT/XP and Linux, with minimal risks for people who fears burning their HD. But the question, Can this be done?. I have downloaded the source code but i am lost. Can someone help me with this? Thanks in advance, Lucio Diaz. ______________________________________________ Renovamos el Correo Yahoo!: ¡100 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es

5 7

NDIS suggestion
by eric.kohl＠t-online.de 18 Nov '04

18 Nov '04

Hi! Isn't it possible to call NdisIStartAdaper (in ndis/miniport.c) when the miniport driver recieves an IRP_MJ_PNP/IRP_MN_START_DEVICE request? Right now it is called from NdisIAddDevice. This means the miniport device is started before resource lists are assigned to the NICs device node. NdisMQueryAdaperResources and NdisMPciAssignResources cannot be implemented oe won't work because of this. Regards, Eric

2 2

Important software
by Casper Hornstrup 18 Nov '04

18 Nov '04

I intend to move the following important software from rosapps to reactos/subsys/system: calc regedt32 regsvr32 sysutils/ctm and the following to reactos/apps/utils/net: net/ping net/arp net/finger net/ipconfig net/netstat net/telnet net/whois Actually there are two telnet applications. Which is better? If I've left out something important, please speak up. Casper

5 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev