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>
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.
* 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