Documentation update.
[reactos.git] / reactos / doc / notes
index 74b3f27..eaa392e 100644 (file)
@@ -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.