Hello! In an effort to put ReactOS development into higher scales, I would like to announce that I am creating a global list of all possible development tasks, broken down into modules/sections/etc. By the time all tasks in this list are fully completed, ReactOS would result in transition to a beta-stage and bumping version number to >= 0.5 (so you understand how big this todolist will be).
This list would be a base to the global ReactOS Roadmap which is going to show a current status of reactos, expected times before future releases, and what future releases will contain exactly.
And the most important: It makes every programmer willing to participate in the project to find a task he feels familiar with, actually do it, and see how it advances the project. All the way before, the only really managed part of development was fixing bugs, because Bugzilla is storing all bugs descriptions/patches/ assignations/etc. Now, similar thing will come in help to the general development.
Creating such a list is quite a hard task, and it can't be done by an individual, so:
Attention all ReactOS Developers, please! Your word is very valuable here! Please, compile a list of tasks you think ReactOS needs and send it here as a reply to this message (I will put a preliminary draft of what I already compiled so far too somewhere in the wiki). Each task should be a clearly outlined work if possible, however all information is important so you can add something like "//TODO: Add more details about this task later" too.
Example of a task considered as "good" to me: - Boot manager -- Make Loader Parameter Block compatible with Windows XP one
Example of a less exact task, but which is still "good" - Boot manager -- Make boot process conforming to NTLDR boot process, so that FreeLdr can boot Windows without NTLDR.
Example of a "bad" task - NTOSKRNL -- Improve kernel
Thank you for the collaboration, I know this maybe a quite hard to do, but it's the first steps of an effort to get development to the speed and quality we never had before. Other things to mention are continuos integration system, regression testing frameworks, etc, etc.
With the best regards, Aleksey Bragin.
Aleksey Bragin wrote:
Attention all ReactOS Developers, please! Your word is very valuable here! Please, compile a list of tasks you think ReactOS needs and send it here as a reply to this message
Here are some tasks which spring to mind for me. Most are very general though and aren’t down to a level you exemplified.
- Network -- Allow setting of address information via ncpa. (This is the only remaining task for the current 0.3.0 roadmap) -- Salvage the sockets library from Alex’s branch and merge to the development branch. -- Build on the existing NDIS model introducing support for IM drivers -- Add a default firewall including GUI for user interaction of the fundamental aspects. -- Add support for packet routing with Network Address Translation. -- Assist and merge with a Win32 port of SMB.
- Security -- Start to build on the current framework providing basic OS security -- Implement logon / logoff facility linking in with our gina library.
- Filesystem -- Replace the primary filesystem in place of a journaling system.
- NT Services -- Add support for starting and stopping services
- Multimedia -- Continue development on DX initially aiming for hardware accelerated playability of key games. -- Improve support for existing sound model.
- Explorer -- Add support for layered windows. -- Add libraries for support of common image formats, including jpeg, gif and png. -- Improve the graphical design of the UI. Enlist help of graphical designers / programmers. -- Add support for theming.
- Drivers -- Continue work on Plug and Play Manager -- Finish off USB support for keyboard and mouse. -- Provide support for drivers written with WDM -- USB support for peripherals such as pendrives and cameras
- Printing -- Introduce a printing framework.
- Power Management -- Add support for ACPI and APM. Battery monitoring, processor throttling, hibernation. -- Introduce shutdown and restart functionality.
- Build System -- Pick up CIS and incorporate into a build farm preferably situated within a university. -- Improve regression testing facilities using Wine where possible. -- Build ReactOS with MSVC and PSDK.
-Networking -- Include ZeroConf networking hosted internally to host uPNP applications to other users on the network.
-Filesystem -- Add support for Networked File Systems to allow Networked resources to act as local folders & drives. -- Automatically defragment files less than 20 megabytes, not read- only, not in use, etc. -- Automatically cache drivers, and executables that a user access frequently to reduce load time.
-Security -- Add support for Access Control Lists embedded in an internal LDAP service to restrict users from accessing others files -- Add Login / Logout / Lock support to explorer, Windows Key + L or like that of Windows 2000 or XP -- Encrypted / Compressed home directories which are actually files that mount on login and unmount on Logout something like FileVault on Mac OS X.
-Explorer -- Revamp explorer to look and feel like Windows explorer -- Remove access to Registry (common users don't use the registry and might not even know it is there) -- Allow indexing and caching of commonly used folders, files, programs -- Support for Windows XP Sidebar features like commonly used files and folders, file properties, etc using standard javascript and html which can be turned on/off.
On Mar 28, 2006, at 3:38 AM, Ged Murphy wrote:
Aleksey Bragin wrote:
Attention all ReactOS Developers, please! Your word is very valuable here! Please, compile a list of tasks you think ReactOS needs and send it here as a reply to this message
Here are some tasks which spring to mind for me. Most are very general though and aren’t down to a level you exemplified.
- Network
-- Allow setting of address information via ncpa. (This is the only remaining task for the current 0.3.0 roadmap) -- Salvage the sockets library from Alex’s branch and merge to the development branch. -- Build on the existing NDIS model introducing support for IM drivers -- Add a default firewall including GUI for user interaction of the fundamental aspects. -- Add support for packet routing with Network Address Translation. -- Assist and merge with a Win32 port of SMB.
- Security
-- Start to build on the current framework providing basic OS security -- Implement logon / logoff facility linking in with our gina library.
- Filesystem
-- Replace the primary filesystem in place of a journaling system.
- NT Services
-- Add support for starting and stopping services
- Multimedia
-- Continue development on DX initially aiming for hardware accelerated playability of key games. -- Improve support for existing sound model.
- Explorer
-- Add support for layered windows. -- Add libraries for support of common image formats, including jpeg, gif and png. -- Improve the graphical design of the UI. Enlist help of graphical designers / programmers. -- Add support for theming.
- Drivers
-- Continue work on Plug and Play Manager -- Finish off USB support for keyboard and mouse. -- Provide support for drivers written with WDM -- USB support for peripherals such as pendrives and cameras
- Printing
-- Introduce a printing framework.
- Power Management
-- Add support for ACPI and APM. Battery monitoring, processor throttling, hibernation. -- Introduce shutdown and restart functionality.
- Build System
-- Pick up CIS and incorporate into a build farm preferably situated within a university. -- Improve regression testing facilities using Wine where possible. -- Build ReactOS with MSVC and PSDK. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
As I posted many weeks ago to the mailinglist and now at the forum (http://www.reactos.org/forum/viewtopic.php?p=15127#15127) we should consider representing ReactOS on Linuxtag 2006. Please watch the forum for further informations.
Best regards, Dominik
Rick Langschultz wrote:
-Networking -- Include ZeroConf networking hosted internally to host uPNP applications to other users on the network.
-Filesystem -- Add support for Networked File Systems to allow Networked resources to act as local folders & drives. -- Automatically defragment files less than 20 megabytes, not read-only, not in use, etc. -- Automatically cache drivers, and executables that a user access frequently to reduce load time.
On Mar 28, 2006, at 3:38 AM, Ged Murphy wrote:
- Filesystem
-- Replace the primary filesystem in place of a journaling system.
Autoimatically defragment files on filesystems that require it. Ext2 and Ext3 not the best idea most cases they defrag themself in general operation most linux/unix/bsd filesystem do. Ntfs and Fat require it.
--Option of background operation filesystem defrager for Ntfs, Fat and any other supported filesystem that requires it a complete defrag of drive only in use files not touch option. --Processor and memory usage limiter on filesystem defrager in background. --Boot Defrag options provided by default no third party tool required to do this. --Filesystem Defrager must have continual operation without restarting no matter what is written to disk its working on. --Registry Hive defraging options for every boot or on X number of reboots.
Filesystem--Security --Documentation on what filesystem flags are required and how they operate locations of sources good idea for developers from other platforms. --Universal posix/xattr/acl translator to and from Ms Windows attributes and secuirty stored on harddrive. The universal will open up options of porting alot more Linux/unix/bsd filesystems. --Support for full unicode filesystems. All applications in Reactos should expect filenames to be unicode.<A audit some time> Ext2/3 Filenames are unicode no codepage required. --Ext2 filesystem driver must be updated to Ext3 support. Having to redo journaling is a pain. The different between Ext2 and Ext3 is journaling.
Peter Dolding
I have thought of a hack that would allow ext2 to store legacy 8.3 file names. If a program requests a 8.3 file name we create it on the fly from the real one. If the program changes the 8.3 file name, we create a sim (or hard) link to the original with the new name. Although this may need to be tweaked, you get the basic idea. ;)
Peter Dolding wrote:
Rick Langschultz wrote:
-Networking -- Include ZeroConf networking hosted internally to host uPNP applications to other users on the network.
-Filesystem -- Add support for Networked File Systems to allow Networked resources to act as local folders & drives. -- Automatically defragment files less than 20 megabytes, not read-only, not in use, etc. -- Automatically cache drivers, and executables that a user access frequently to reduce load time.
On Mar 28, 2006, at 3:38 AM, Ged Murphy wrote:
- Filesystem
-- Replace the primary filesystem in place of a journaling system.
Autoimatically defragment files on filesystems that require it. Ext2 and Ext3 not the best idea most cases they defrag themself in general operation most linux/unix/bsd filesystem do. Ntfs and Fat require it.
--Option of background operation filesystem defrager for Ntfs, Fat and any other supported filesystem that requires it a complete defrag of drive only in use files not touch option. --Processor and memory usage limiter on filesystem defrager in background. --Boot Defrag options provided by default no third party tool required to do this. --Filesystem Defrager must have continual operation without restarting no matter what is written to disk its working on. --Registry Hive defraging options for every boot or on X number of reboots.
Filesystem--Security --Documentation on what filesystem flags are required and how they operate locations of sources good idea for developers from other platforms. --Universal posix/xattr/acl translator to and from Ms Windows attributes and secuirty stored on harddrive. The universal will open up options of porting alot more Linux/unix/bsd filesystems. --Support for full unicode filesystems. All applications in Reactos should expect filenames to be unicode.<A audit some time> Ext2/3 Filenames are unicode no codepage required. --Ext2 filesystem driver must be updated to Ext3 support. Having to redo journaling is a pain. The different between Ext2 and Ext3 is journaling.
Peter Dolding _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Jerry wrote:
I have thought of a hack that would allow ext2 to store legacy 8.3 file names. If a program requests a 8.3 file name we create it on the fly from the real one. If the program changes the 8.3 file name, we create a sim (or hard) link to the original with the new name. Although this may need to be tweaked, you get the basic idea. ;)
Yes know hack been done been delete and droped from Linux apps. You will find this makes the ext2/3 messy and hard to get around from a Linux point of view. Also hardlinks and sim links are not deleted when the file is long filename is. Now xattr the 8.3 filename. NTFS can be created without 8.3 filenames so I don't class it as a big problem. Other way is dosemu way create them on the fly. I know samba 3 using on the fly. I think samba 4 uses xattr to fix.
Security attribute translation is required so we can know how much xattr space is left on the ext2/3 filesystem. Its locked to one block. 1k to 8k depending on the format of the disk. Ext3 update most likely Ext4 will remove the limitation.
http://www.ridgecrop.demon.co.uk/fat32format.htm Waxdragon feel like giving it a test run??.
It a better fat32 format program that what even comes with Windows XP and its GPL. Only fat32 format program if you are nuts can do a single 250G part or bigger.
Reason why I have moved on to defraging. Only reason why we don't have a format tool is that something is missing to stop this working or I am the only person who knew about this. Its the best fat32 format program around so no point redoing it. chkdsk tool does have to be run after it. Ie bad sector detection is not done.
--develop a chkdsk if one is not already. Activate on boot after not shutdown correctly and fixing/marking defects.
Note I forgot It need chkdsk to make safe disks to use. Last format of anything like that 2 years ago memory rusted slightly.
Peter Dolding
Peter Dolding wrote:
Reason why I have moved on to defraging.
We already have a nice NTFS/FAT defrag tool which can easily be merged into the core system if need be (although I think a revamped GUI would be sufficient) I'll drop the code into rosapps so we don't loose it, it's almost impossible to find a copy on the net now.
Ged.
On 3/29/06, Ged Murphy gedmurphy@gmail.com wrote:
We already have a nice NTFS/FAT defrag tool which can easily be merged into the core system if need be (although I think a revamped GUI would be sufficient) I'll drop the code into rosapps so we don't loose it, it's almost impossible to find a copy on the net now.
I also dropped a copy of format/fsck.fat in rosapps a while back. The code is readonly as someone with better programming skills than me needs to check the math to make sure writes are safe but according to our testing it looked good. Its by no means a properly solution as Windows uses some dll for fslib or something that exports a bunch of C++ classes and COM objects to handle filesystem formatting but for limited purposes of fat16/32 support it should work.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
-Filesystem -- Add support for Networked File Systems to allow Networked resources to act as local folders & drives. -- Automatically defragment files less than 20 megabytes, not read-only, not in use, etc. -- Automatically cache drivers, and executables that a user access frequently to reduce load time.
On Mar 28, 2006, at 3:38 AM, Ged Murphy wrote:
- Filesystem
-- Replace the primary filesystem in place of a journaling system.
Autoimatically defragment files on filesystems that require it. Ext2 and Ext3 not the best idea most cases they defrag themself in general operation most linux/unix/bsd filesystem do. Ntfs and Fat require it.
--Option of background operation filesystem defrager for Ntfs, Fat and any other supported filesystem that requires it a complete defrag of drive only in use files not touch option. --Processor and memory usage limiter on filesystem defrager in background. --Boot Defrag options provided by default no third party tool required to do this. --Filesystem Defrager must have continual operation without restarting no matter what is written to disk its working on. --Registry Hive defraging options for every boot or on X number of reboots.
Filesystem--Security --Documentation on what filesystem flags are required and how they operate locations of sources good idea for developers from other platforms. --Universal posix/xattr/acl translator to and from Ms Windows attributes and secuirty stored on harddrive. The universal will open up options of porting alot more Linux/unix/bsd filesystems. --Support for full unicode filesystems. All applications in Reactos should expect filenames to be unicode.<A audit some time> Ext2/3 Filenames are unicode no codepage required. --Ext2 filesystem driver must be updated to Ext3 support. Having to redo journaling is a pain. The different between Ext2 and Ext3 is journaling.
Gee, I'd be happy if I could FORMAT a FAT partition from inside ReactOS.
I agread with Ged here and I will not change my goal getting least dx 2d and 3d to ros and helping with some part of the sound system and other stuff as I usal do.
----- Original Message ----- From: "Ged Murphy" gedmurphy@gmail.com To: "ReactOS Development List" ros-dev@reactos.org Sent: den 28 March 2006 11:38 Subject: Re: [ros-dev] Roadmap / List of tasks / Attn. all developers
Aleksey Bragin wrote:
Attention all ReactOS Developers, please! Your word is very valuable here! Please, compile a list of tasks you think ReactOS needs and send it here as a reply to this message
Here are some tasks which spring to mind for me. Most are very general though and aren’t down to a level you exemplified.
- Network -- Allow setting of address information via ncpa. (This is the only remaining task for the current 0.3.0 roadmap) -- Salvage the sockets library from Alex’s branch and merge to the development branch. -- Build on the existing NDIS model introducing support for IM drivers -- Add a default firewall including GUI for user interaction of the fundamental aspects. -- Add support for packet routing with Network Address Translation. -- Assist and merge with a Win32 port of SMB.
- Security -- Start to build on the current framework providing basic OS security -- Implement logon / logoff facility linking in with our gina library.
- Filesystem -- Replace the primary filesystem in place of a journaling system.
- NT Services -- Add support for starting and stopping services
- Multimedia -- Continue development on DX initially aiming for hardware accelerated playability of key games. -- Improve support for existing sound model.
- Explorer -- Add support for layered windows. -- Add libraries for support of common image formats, including jpeg, gif and png. -- Improve the graphical design of the UI. Enlist help of graphical designers / programmers. -- Add support for theming.
- Drivers -- Continue work on Plug and Play Manager -- Finish off USB support for keyboard and mouse. -- Provide support for drivers written with WDM -- USB support for peripherals such as pendrives and cameras
- Printing -- Introduce a printing framework.
- Power Management -- Add support for ACPI and APM. Battery monitoring, processor throttling, hibernation. -- Introduce shutdown and restart functionality.
- Build System -- Pick up CIS and incorporate into a build farm preferably situated within a university. -- Improve regression testing facilities using Wine where possible. -- Build ReactOS with MSVC and PSDK. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Though I am no dev, this is a very small list of things that seem important to me
- Shell -- Remove the blue line on bottom of the startpanel -- hide expand button in tray if not needed -- add menu latency to startmenu -- make drag-and-drop work in startmenu -- make alphablend for icons work -- add trashcan and implement delete functions -- add posibility to change mouse-cursor speed -- deactivate buttons without function
- Boot manager -- change the current desing to a plain minimalistic black / white design
Here are some tasks which come to my mind:
- System -- Terminal Server alike integration (multiple user on one computer) -- filesystem drivers for ext3 and reiserfs4
- Shell -- a lot of shell32/explorer dialogs (properties, etc.) -- working drop-down menus -- tasks-list or information bar which doesn't rely on a -- Clipboard server: copy&paste feature, ole, etc. -- theme-able GUI -- svg based vector icon support
- Control Panels -- improve several control panels (add more options, add features, etc.)
- Help System -- create a help system for ReactOS -- maybe a html-help or hlp format based one or html/xhtml/xml (gecko engine) -- write help pages
- ReactOS Search -- Front-end Search query and result application -- a system-wide search service (with API for external apps) for indexing and queries -- similar to "spotlight" and various "desktop search" tools -- per volume based metadata and content databases -- slogan: "fast, consistent, innovative and reliable" -- support for all recognized volumes; it does work on all filesystems in contrast to other similar solutions -- integration in the ReactOS shell/explorer -- (for more information: http://www.reactos.org/wiki/index.php/ReactOS_Search)
- Paint clone -- ged (and w3seek) are working on it
- input assistance tools -- virtual keyboard -- screen magnifying glass -- etc.
- winlogon -- logon-screen -- security related code
- Wordpad like app -- vendor import from winehq
- System Tools -- defragmentation app (for fat12/16/32 and ext2) -- ftp tool -- wizards for network configuration (ppoe, modem, wlan, etc.) -- Backup tool (user settings, user data) -- several system tools should accept console flags too (for batch scripts, etc.) -- help/manual pages for several tools (as usual in the multics/unix world) -> see RosApps project (a bit out of date ...) -- special Server Tools to position ReactOS also as a server operating system
- Package Manager -- a simple and working (really need some more feature) is in RosApps -- support for offline (CD) and online (reactos.org website) package database -- install and manage apps -- installation of "RosApps" and some third party tools/apps (mozilla firefox/thunderbird, etc.) while the second step of the ReactOS setup
- RosApps -- IRC client: e.g. BoxedIrc (c source code, gnu gpl, -> soureforge.net) -- simple and tiny webserver: let the users share their data (documents, images) with their own webserver (like MacOS X)
- ReactOS Setup -- combine the LiveCD (only a light version) and the BootCD (this doesn't me the dead for the LiveCD!) -- Copy and setup the settings with the LiveCD version (similar to WinVista), finally reboot into the new installed ReactOS -- by default, only a few really important settings should be required -- extended settings should be hidden by default, so that they cannot confuse normal user -- let more advantaged user to input and adjust more settings while the install process (even more then WinXP) and support for saved settings from a usb-stick, etc. -- let the user specific the settings in the first part of the installation process and then no more user interaction should be requiered; although this shouldn't be such a big problem, because ReactOS won't get such bloated as some other operating systems and distributions (by default). -- keep the current text mode setup (step 1) app for leagancy (only optional), (no high resolution monitor, embed purpose, outdated hardware, etc.) -- let the user to install ReactOS even from Win32 -- support for reiserfs4, ext2/3 while setup (partition and installation) -- simple graphical partition tool which allow you to create, delete, rename and format partitions
- LiveCD -- improve the LiveCD (no reboot required for several settings, etc.) -- RamDrive support -- should be equal to the BootCD (the same apps, almost same settings/registry keys) -- make the LiveCD the "flagship" ("spread" cds around) for events like "linuxtag", "linuxworld", "wineconf", etc. -- reason: everyone want to test a operating system before he change to it finally.
And some links to ReactOS wiki pages which contain some interesting tasks too: * http://www.reactos.org/wiki/index.php/Security * http://www.reactos.org/wiki/index.php/UserSecurity * http://www.reactos.org/wiki/index.php/ShutdownProcess * http://www.reactos.org/wiki/index.php/Firewall * http://www.reactos.org/wiki/index.php/Alex%27s_0.3.0_%27User_Wow_Factor%27_I... * http://www.reactos.org/wiki/index.php/Mf%27s_UIdeas * http://www.reactos.org/wiki/index.php/Ideas
I started a defragmentation app several weeks ago, but unfortunately im stuck. The important API-parts are not implmented yet and I'm lacking of knowledge to implement them on my own. So I tried to directly access the FS, but then again I was stuck in the filesystem-functions.
So, if anyone has some good help for me, documentation, article, etc, feel free to let me know and I'll give it one more try.
Klemens Friedl schrieb:
[..]
- System Tools
-- defragmentation app (for fat12/16/32 and ext2)
For ext3 filesystem drivers, we could use John Newbigin's EXT2 IFS, that is GPLed and can read ext3 too. (Its readonly atm though)
--- Klemens Friedl frik85@gmail.com a écrit :
Here are some tasks which come to my mind:
- System
-- Terminal Server alike integration (multiple user on one computer) -- filesystem drivers for ext3 and reiserfs4
Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org )
Dominik wrote:
- Shell
-- (...)
-- Allow icon moving on a window and on the desktop.
_______________________________________________________ Yahoo! doce lar. Fa�a do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html