Documentation update.

Added preliminary road-map.

svn path=/trunk/; revision=2095

diff --git a/reactos/doc/notes b/reactos/doc/notes
index 74b3f27..eaa392e 100644 (file)
--- a/reactos/doc/notes
+++ b/reactos/doc/notes
@@ -102,108 +102,6 @@ it to ya.
 
 Rex.
 -----
-Subject: [ros-kernel] Pet peeve of the week
-Resent-Date: Sun, 25 Oct 1998 11:57:40 -0600
-Resent-From: ros-kernel@sid-dis.com
-Date: Sun, 25 Oct 1998 09:53:48 -0800
-From: rex <rex@lvcablemodem.com>
-Reply-To: <ros-kernel@sid-dis.com>
-To: ReactOS Kernel Forum <ros-kernel@sid-dis.com>
-
-Hi all,
-
-I guess it's about time to start another mailstorm
-on the list. :)
-
-I have a suggestion for a change to the kernel.
-It not a very big change, and I hope everyone
-will agree that it makes sense.
-
-There is a structure used in many places in the
-kernel called LARGE_INTEGER.  the is also
-a version called ULARGE_INTEGER, but it
-is not used at all as far as I can tell.  this structure
-is equivalent to a long long int.  You can literally
-cast a pointer to a LARGE_INTEGER to a
-long long int and all manipulation will work
-seemlessly. My suggestion is that we replace the
-use of this structure with long long ints.  Even
-microsoft, in their infinite wisdom, has made this
-suggestion in the DDK documentation.  If you're
-wondering where, look at the RTL functions
-that manipulate LARGE_INTEGER structs.
-
-Replacing LI's with long long ints will work
-because they are binary compatable.  All software
-compiled to use LI's will manipulate long long ints
-correctly and vice versa. There is one problem
-with this suggestion: the LARGE_INTEGER type
-is a structure containing 2 members.  Any code
-that accesses the structure by members will break.
-I think the kernel side impact is minimal, and is
-worth the change.  However, the structure is used
-in several of the Win32 API functions, and needs
-to remain there.  I think we build a conditionally
-compiled version of the LARGE_INTEGER type.
-In kernel mode code (the kernel proper and drivers)
-the LARGE INTEGER will be the following:
-
-typedef long long int LARGE_INTEGER,
-    *PLARGE_INTEGER;
-typedef unsigned long long int ULARGE_INTEGER,
-    *PULARGE_INTEGER;
-
-and in user mode code it will expand out to the
-current definition (which by the way, is not
-strictly correct, but can't be because it uses a
-MS compiler extension).
-
-Brian, I would be willing to make the conversion
-to those kernel modules that needed it, and of
-course to the IDE driver if we want to go forward
-with the change.
-
-Lastly, I'll mention what made me consider this.
-I was fixing the timer routines, and two of the
-three problems turned out to be related to LI
-conversion problems.
-
-Rex.
------
-Subject:  Re: [ros-kernel] Pet peeve of the week
-Date: Thu, 29 Oct 1998 19:10:37 +0100
-From: Boudewijn <ariadne@xs4all.nl>
-To: rex@lvcablemodem.com
-References: 1
-
-Hai Rex
-
-    I think it is a good idea to wrap a makro around the member access
-to large integers.
-I haven't tested this, but do you think this is a good sugestion ?
-
-#ifdef COMPILER_LARGE_INTEGERS
-#define GET_LARGE_INTEGER_HIGH_PART(LargeInteger) ( ( LargeInteger >>
-32) )
-#define GET_LARGE_INTEGER_LOW_PART(LargeInteger) ( (LargeInteger &
-0xFFFFFFFF) )
-#define SET_LARGE_INTEGER_HIGH_PART(LargeInteger,Signed_Long) (
-LargeInteger |= ( ((LARGE_INTEGER)Signed_Long) << 32 ) )
-#define SET_LARGE_INTEGER_LOW_PART(LargeInteger,Unsigned_Long) (
-LargeInteger |= Unsigned_Long  )
-#else
-#define GET_LARGE_INTEGER_HIGH_PART(LargeInteger) (  (
-LargeInteger.HighPart) )
-#define GET_LARGE_INTEGER_LOW_PART(LargeInteger) (
-(LargeInteger.LowPart) )
-#define SET_LARGE_INTEGER_HIGH_PART(LargeInteger,Signed_Long) (
-LargeInteger.HighPart=  Signed_Long  )
-#define SET_LARGE_INTEGER_LOW_PART(LargeInteger,Unsigned_Long) (
-LargeInteger.LowPart = Unsigned_Long  )
-#endif
-
-Boudewijn
------
 Subject: Re: Question on "Sending buffers on the stack to asynchronous DeviceIoControl with buffered I/O"
 Date: Mon, 16 Nov 1998 11:24:57 -0800
 From: "-Paul" <paulsan@microsoftSPAM.com>
@@ -669,28 +567,4 @@ your own queue if you don't worry about PNP and POWER. I hear tell of an
 upcoming MSJ article by a Microsoft developer that may solve the
 complete problem.
 -----
-Subject: ANNOUNCE: ALINK v1.5
-Date: 16 Nov 1998 16:36:05 GMT
-From: anthony_w@my-dejanews.com
-Organization: Deja News - The Leader in Internet Discussion
-Newsgroups: comp.os.ms-windows.programmer.win32, comp.lang.asm.x86, comp.os.msdos.programmer
-
-ALINK is a freeware linker, creating MSDOS COM and EXE files and Win32 PE EXE
-and DLL files from OMF format OBJ and LIB files, win32-COFF format OBJ files,
-and win32 RES files.
-
-NEW for version 1.5:
-
-Win32 COFF object file support.
-
-Download it now from my home page.
-
-Anthony
---
-anthony_w@geocities.com
-http://www.geocities.com/SiliconValley/Network/4311/index.html
-
------------== Posted via Deja News, The Discussion Network ==----------
-http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
------
-
+The END.

diff --git a/reactos/doc/roadmap b/reactos/doc/roadmap
new file mode 100644 (file)
index 0000000..a52e9b8
--- /dev/null
+++ b/reactos/doc/roadmap
@@ -0,0 +1,26 @@
+
+ ReactOS RoadMap
+=================
+
+This file should give developers and users some hints about where
+the project development is heading to. This list is intended to be
+a base for discussions and can be changed to reflect the results of
+these discussions. Every developer is encouraged to add his/her own
+ideas to this list.
+
+
+Version 0.0.19:
+ - FreeLoader can boot ReactOS from hard-disk
+ - Registry support for FreeLoader
+ - ATAPI storage driver stack
+
+Version 0.0.20:
+ - CDROM class driver
+ - CDFS file system driver (iso9660,...)
+
+Version 0.0.21:
+ - ReactOS can boot from CDROM
+
+
+List includes personal 'to-do' topics by:
+  Eric Kohl

diff --git a/reactos/doc/todo b/reactos/doc/todo
index eb14026..7678acb 100644 (file)
--- a/reactos/doc/todo
+++ b/reactos/doc/todo
@@ -10,32 +10,19 @@
 * Function groups totally or partially unimplemented
 
        Dma functions (see hal/x86/dma.c)
-       PCI interface functions (see hal/x86/bios32.c, hal/x86/pci.c)
-       HalExamineMbr
-       Locale support (see ex/locale.c)
        Shutdown support (see ex/power.c)
        Zw(Set/Get)SystemInformation (see ex/sysinfo.c)
-       Adapter functions (see io/adapter.c)
        Io cancelation support (see io/cancel, et al)
        Directory change notification (see io/dir.c)
        Error logging (see io/errlog.c)
-       Buffer flushing (see io/flush.c)
        Io completion ports (see io/iocomp.c)
        File locking (see io/lock.c)
-       Mailslots (see io/mailslot.c)
-       Named pipes (see io/npipe.c)
        Hardware resource management (see io/resource.c)
-       File access checking (see io/share.c)
        Exception support (see ke/catch.c)
-       Mutex support (see ke/mutex.c)
-       Semaphore support (see ke/sem.c)
-       Timer support (see ke/timer.c)
-       Single linked lists (see rtl/slist.c)
-       Sequenced lists (see rtl/seqlist.c)
+       Mutex support (see nt/mutex.c)
        
 * Verify implementation
 
-       Fast mutexes (see ex/fmutex.c)
        
 * Major areas