mirror of
https://github.com/reactos/reactos.git
synced 2024-12-27 01:24:38 +00:00
Documentation update.
Added preliminary road-map. svn path=/trunk/; revision=2095
This commit is contained in:
Eric Kohl
parent
6c6bb5f62e
commit
7b23bdc4ac
3 changed files with 28 additions and 141 deletions
|
|
@ -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.
|
||||
|
|
|
|||
26
reactos/doc/roadmap
Normal file
26
reactos/doc/roadmap
Normal file
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue