From 7b23bdc4acfa148feed6ce99ed3073ad2e2af582 Mon Sep 17 00:00:00 2001 From: Eric Kohl Date: Tue, 24 Jul 2001 20:49:57 +0000 Subject: [PATCH] Documentation update. Added preliminary road-map. svn path=/trunk/; revision=2095 --- reactos/doc/notes | 128 +------------------------------------------- reactos/doc/roadmap | 26 +++++++++ reactos/doc/todo | 15 +----- 3 files changed, 28 insertions(+), 141 deletions(-) create mode 100644 reactos/doc/roadmap diff --git a/reactos/doc/notes b/reactos/doc/notes index 74b3f2766c2..eaa392ea794 100644 --- 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 -Reply-To: -To: ReactOS Kernel Forum - -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 -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" @@ -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 index 00000000000..a52e9b86a5e --- /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 eb14026ec0d..7678acbc475 100644 --- 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