mirror of
https://github.com/reactos/reactos.git
synced 2025-08-05 21:23:05 +00:00
Bug fixes
svn path=/trunk/; revision=176
This commit is contained in:
David Welch
parent
8551dc320b
commit
12ea84e3c9
21 changed files with 350 additions and 1134 deletions
21
reactos/DIRS
21
reactos/DIRS
|
|
@ -1,21 +0,0 @@
|
||||||
DIRECTORIES
|
|
||||||
|
|
||||||
system : compiled versions of the various system components and
|
|
||||||
libraries
|
|
||||||
ntoskrnl : microkernel source
|
|
||||||
ntoskrnl/hal : hardware abstraction layer source
|
|
||||||
ntoskrnl/mm : memory managment subsystem source
|
|
||||||
ntoskrnl/io : IO manager subsystem source
|
|
||||||
include : win32 headers
|
|
||||||
include/internal : kernel private header files
|
|
||||||
include/ntdll : system library private header files
|
|
||||||
include/kernel32 : system library private header files
|
|
||||||
include/user32 : user interface private header files
|
|
||||||
include/gdi32 : graphics interface private header files
|
|
||||||
include/ddk : header files for modules
|
|
||||||
lib/ntdll : NT dll source
|
|
||||||
lib/kernel32 : kernel32 source
|
|
||||||
doc : documentation
|
|
||||||
loaders/dos : DOS based loader
|
|
||||||
loaders/boot : boot loader
|
|
||||||
services : various services (device drivers, filesystems etc)
|
|
||||||
|
|
@ -1,3 +1,7 @@
|
||||||
|
0.0.14 (so far):
|
||||||
|
|
||||||
|
0.0.13: Mostly bugfixes (I think)
|
||||||
|
|
||||||
0.0.12: Added support for multiple processes (not really tested)
|
0.0.12: Added support for multiple processes (not really tested)
|
||||||
System calls
|
System calls
|
||||||
kernel32 now compiles (only as a static library)
|
kernel32 now compiles (only as a static library)
|
||||||
|
|
|
||||||
13
reactos/TODO
13
reactos/TODO
|
|
@ -1,13 +0,0 @@
|
||||||
Hardware resource management
|
|
||||||
Deleting namespace objects
|
|
||||||
Directory functions
|
|
||||||
File sharing
|
|
||||||
Event pairs
|
|
||||||
Io completion ports
|
|
||||||
Cancel io support
|
|
||||||
DMA support
|
|
||||||
Registry support
|
|
||||||
Cache read ahead
|
|
||||||
Caching file mapping
|
|
||||||
Driver unloading
|
|
||||||
|
|
||||||
|
|
@ -17,9 +17,9 @@
|
||||||
; DISCLAMED. This includes but is not limited to warrenties of
|
; DISCLAMED. This includes but is not limited to warrenties of
|
||||||
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||||
;
|
;
|
||||||
; $Revision: 1.2 $
|
; $Revision: 1.3 $
|
||||||
; $Author: dwelch $
|
; $Author: dwelch $
|
||||||
; $Date: 1999/01/16 21:02:58 $
|
; $Date: 1999/01/17 17:27:24 $
|
||||||
;
|
;
|
||||||
; These three functions appear to be name mangled in some way, so GCC is
|
; These three functions appear to be name mangled in some way, so GCC is
|
||||||
; probably not going to be able to use them in any case.
|
; probably not going to be able to use them in any case.
|
||||||
|
|
@ -713,3 +713,4 @@ wcsxfrm
|
||||||
wctomb
|
wctomb
|
||||||
wprintf
|
wprintf
|
||||||
wscanf
|
wscanf
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -84,11 +84,7 @@ BOOL STDCALL SetCurrentDirectoryA(LPCSTR lpPathName)
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
WINBOOL
|
WINBOOL STDCALL SetCurrentDirectoryW(LPCWSTR lpPathName)
|
||||||
STDCALL
|
|
||||||
SetCurrentDirectoryW(
|
|
||||||
LPCWSTR lpPathName
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
if ( lpPathName == NULL )
|
if ( lpPathName == NULL )
|
||||||
return FALSE;
|
return FALSE;
|
||||||
|
|
@ -188,12 +184,8 @@ GetWindowsDirectoryA(
|
||||||
return uPathSize;
|
return uPathSize;
|
||||||
}
|
}
|
||||||
|
|
||||||
UINT
|
UINT STDCALL GetSystemDirectoryW(LPWSTR lpBuffer,
|
||||||
STDCALL
|
UINT uSize)
|
||||||
GetSystemDirectoryW(
|
|
||||||
LPWSTR lpBuffer,
|
|
||||||
UINT uSize
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
UINT uPathSize;
|
UINT uPathSize;
|
||||||
if ( lpBuffer == NULL )
|
if ( lpBuffer == NULL )
|
||||||
|
|
@ -206,12 +198,8 @@ GetSystemDirectoryW(
|
||||||
return uPathSize;
|
return uPathSize;
|
||||||
}
|
}
|
||||||
|
|
||||||
UINT
|
UINT STDCALL GetWindowsDirectoryW(LPWSTR lpBuffer,
|
||||||
STDCALL
|
UINT uSize)
|
||||||
GetWindowsDirectoryW(
|
|
||||||
LPWSTR lpBuffer,
|
|
||||||
UINT uSize
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
UINT uPathSize;
|
UINT uPathSize;
|
||||||
if ( lpBuffer == NULL )
|
if ( lpBuffer == NULL )
|
||||||
|
|
|
||||||
|
|
@ -8,30 +8,25 @@
|
||||||
* Created 01/11/98
|
* Created 01/11/98
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
/* INCLUDES ******************************************************************/
|
||||||
|
|
||||||
#include <windows.h>
|
#include <windows.h>
|
||||||
#include <ddk/ntddk.h>
|
#include <ddk/ntddk.h>
|
||||||
#include <string.h>
|
#include <string.h>
|
||||||
#include <wstring.h>
|
#include <wstring.h>
|
||||||
#include <ddk/rtl.h>
|
#include <ddk/rtl.h>
|
||||||
|
|
||||||
|
/* FUNCTIONS *****************************************************************/
|
||||||
|
|
||||||
WINBOOL
|
WINBOOL STDCALL CreateDirectoryA(LPCSTR lpPathName,
|
||||||
STDCALL
|
LPSECURITY_ATTRIBUTES lpSecurityAttributes)
|
||||||
CreateDirectoryA(
|
|
||||||
LPCSTR lpPathName,
|
|
||||||
LPSECURITY_ATTRIBUTES lpSecurityAttributes
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
return CreateDirectoryExA(NULL,lpPathName,lpSecurityAttributes);
|
return CreateDirectoryExA(NULL,lpPathName,lpSecurityAttributes);
|
||||||
}
|
}
|
||||||
|
|
||||||
WINBOOL
|
WINBOOL STDCALL CreateDirectoryExA(LPCSTR lpTemplateDirectory,
|
||||||
STDCALL
|
|
||||||
CreateDirectoryExA(
|
|
||||||
LPCSTR lpTemplateDirectory,
|
|
||||||
LPCSTR lpNewDirectory,
|
LPCSTR lpNewDirectory,
|
||||||
LPSECURITY_ATTRIBUTES lpSecurityAttributes
|
LPSECURITY_ATTRIBUTES lpSecurityAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
WCHAR TemplateDirectoryW[MAX_PATH];
|
WCHAR TemplateDirectoryW[MAX_PATH];
|
||||||
WCHAR NewDirectoryW[MAX_PATH];
|
WCHAR NewDirectoryW[MAX_PATH];
|
||||||
|
|
@ -350,16 +345,45 @@ SearchPathA(
|
||||||
return RetValue;
|
return RetValue;
|
||||||
}
|
}
|
||||||
|
|
||||||
DWORD
|
DWORD STDCALL SearchPathW(LPCWSTR lpPath,
|
||||||
STDCALL
|
|
||||||
SearchPathW(
|
|
||||||
LPCWSTR lpPath,
|
|
||||||
LPCWSTR lpFileName,
|
LPCWSTR lpFileName,
|
||||||
LPCWSTR lpExtension,
|
LPCWSTR lpExtension,
|
||||||
DWORD nBufferLength,
|
DWORD nBufferLength,
|
||||||
LPWSTR lpBuffer,
|
LPWSTR lpBuffer,
|
||||||
LPWSTR *lpFilePart
|
LPWSTR *lpFilePart)
|
||||||
)
|
/*
|
||||||
|
* FUNCTION: Searches for the specified file
|
||||||
|
* ARGUMENTS:
|
||||||
|
* lpPath = Points to a null-terminated string that specified the
|
||||||
|
* path to be searched. If this parameters is NULL then
|
||||||
|
* the following directories are searched
|
||||||
|
* The directory from which the application loaded
|
||||||
|
* The current directory
|
||||||
|
* The system directory
|
||||||
|
* The 16-bit system directory
|
||||||
|
* The windows directory
|
||||||
|
* The directories listed in the PATH environment
|
||||||
|
* variable
|
||||||
|
* lpFileName = Specifies the filename to search for
|
||||||
|
* lpExtension = Points to the null-terminated string that specifies
|
||||||
|
* an extension to be added to the filename when
|
||||||
|
* searching for the file. The first character of the
|
||||||
|
* filename extension must be a period (.). The
|
||||||
|
* extension is only added if the specified filename
|
||||||
|
* doesn't end with an extension
|
||||||
|
*
|
||||||
|
* If the filename extension is not required or if the
|
||||||
|
* filename contains an extension, this parameters can be
|
||||||
|
* NULL
|
||||||
|
* nBufferLength = The length in characters of the buffer for output
|
||||||
|
* lpBuffer = Points to the buffer for the valid path and filename of
|
||||||
|
* file found
|
||||||
|
* lpFilePart = Points to the last component of the valid path and
|
||||||
|
* filename
|
||||||
|
* RETURNS: On success, the length, in characters, of the string copied to the
|
||||||
|
* buffer
|
||||||
|
* On failure, zero.
|
||||||
|
*/
|
||||||
{
|
{
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -64,7 +64,7 @@ WINBOOL
|
||||||
STDCALL
|
STDCALL
|
||||||
AllocConsole( VOID )
|
AllocConsole( VOID )
|
||||||
{
|
{
|
||||||
StdInput = CreateFile("\\Device\\Keyboard",
|
StdInput = CreateFile("\\Keyboard",
|
||||||
FILE_GENERIC_READ,
|
FILE_GENERIC_READ,
|
||||||
0,
|
0,
|
||||||
NULL,
|
NULL,
|
||||||
|
|
@ -72,7 +72,7 @@ AllocConsole( VOID )
|
||||||
0,
|
0,
|
||||||
NULL);
|
NULL);
|
||||||
|
|
||||||
StdOutput = CreateFile("\\Device\\BlueScreen",
|
StdOutput = CreateFile("\\BlueScreen",
|
||||||
FILE_GENERIC_WRITE|FILE_GENERIC_READ,
|
FILE_GENERIC_WRITE|FILE_GENERIC_READ,
|
||||||
0,
|
0,
|
||||||
NULL,
|
NULL,
|
||||||
|
|
|
||||||
687
reactos/notes
687
reactos/notes
|
|
@ -1,687 +0,0 @@
|
||||||
*** This file contains messages I've culled off the net as well
|
|
||||||
as previous discussions all of which have useful info on fixes
|
|
||||||
that need to be added to ReactOS. messages are between five
|
|
||||||
dashes on a line by themselves. If you implement the fix
|
|
||||||
reffered to in a message, feel free to delete it from the file.
|
|
||||||
Rex ***
|
|
||||||
-----
|
|
||||||
Yes with DPCs, KeDrainDpcQueue should go to HIGH_LEVEL because
|
|
||||||
it needs to synchronize with KeInsertDpcQueue. Also the idle thread
|
|
||||||
should run at DISPATCH_LEVEL and regularly drain the dpc queue, that
|
|
||||||
way if an irq happens and the dpc can't be executed immediately it
|
|
||||||
will be executed as soon as the processor is idle rather than
|
|
||||||
waiting for the next timer tick
|
|
||||||
-----
|
|
||||||
About the console driver, I think it might be quite useful to have a simple
|
|
||||||
way for apps to print to the screen for debugging. But when the kernel is more
|
|
||||||
stable, console handling should be moved to user level because console printing
|
|
||||||
needs to know about windows and so on which can only be done at user level.
|
|
||||||
-----
|
|
||||||
Subject: Re: IMSAMP-how to avoid rebooting?
|
|
||||||
Date: 9 Nov 1998 00:40:32 -0000
|
|
||||||
From: Charles Bryant <n51190709.ch@chch.demon.co.uk>
|
|
||||||
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
|
|
||||||
References: 1, 2 , 3 , 4
|
|
||||||
|
|
||||||
In article <un264wzle.fsf@xxx.yyy.zzz>, David C. <qqqq@xxx.yyy.zzz> wrote:
|
|
||||||
>The reason it won't unload when something is bound to it is the same
|
|
||||||
>reason you can't unload any other driver that has an open client. If
|
|
||||||
>you install any driver, and have a user program (or another driver) open
|
|
||||||
>a handle to it, and then give the "net stop" command to unload it,
|
|
||||||
>you'll find that the unload will be delayed until the user program
|
|
||||||
>closes its handle.
|
|
||||||
|
|
||||||
When developing a driver I found this to be a considerable nuisance.
|
|
||||||
Frequently a bug would leave an IRP stuck in the driver and I
|
|
||||||
couldn't unload and reload a fixed version. While reading NTDDK.H I
|
|
||||||
found a suspicious constant and discovered that the Flags field in
|
|
||||||
the device (the one which you OR in DO_BUFFERED_IO or DO_DIRECT_IO)
|
|
||||||
has a bit called DO_UNLOAD_PENDING. By experiment I confirmed that
|
|
||||||
this bit is set when you do 'net stop', so a driver can check it
|
|
||||||
periodically (e.g. from a timer DPC every ten seconds) and cancel all
|
|
||||||
queued IRPs if it is found to be set.
|
|
||||||
|
|
||||||
Since this is not documented anywhere that I can find, it might be
|
|
||||||
unwise to rely on it for production code, but it is very useful for
|
|
||||||
debugging. Maybe someone with internals knowledge can comment on the
|
|
||||||
reliability of it.
|
|
||||||
-----
|
|
||||||
Subject: Re: Kernel bugs
|
|
||||||
Date: Fri, 23 Oct 1998 12:08:36 -0700
|
|
||||||
From: rex <rex@lvcablemodem.com>
|
|
||||||
To: Jason Filby <jasonfilby@yahoo.com>
|
|
||||||
References: 1
|
|
||||||
|
|
||||||
Jason Filby wrote:
|
|
||||||
|
|
||||||
> Hi,
|
|
||||||
>
|
|
||||||
> Ok -- here's most of what I get when I press a key:
|
|
||||||
>
|
|
||||||
> Page fault detected at address 1fd4 with eip c042f794
|
|
||||||
> Recursive page fault detected
|
|
||||||
> Exception 14(2)
|
|
||||||
> CS:EIP 20:c042f794
|
|
||||||
>
|
|
||||||
> Rex -- do you know of anyway to find out which function in what file
|
|
||||||
> is causing the exception? I know that for problems in the kernel, you
|
|
||||||
> just look in the ntoskrnl\kernel.sym file and find the EIP value which
|
|
||||||
> matches the one given in the exception debug text. But what about
|
|
||||||
> modules? How can we track exceptions that occur in functions in modules?
|
|
||||||
>
|
|
||||||
|
|
||||||
I know this is a little belated, but I thought I'd take astab at answering
|
|
||||||
this anyway. add an option to the
|
|
||||||
makefile for the module to generate a listing file with
|
|
||||||
symbol information. Then, on a boot test, note the
|
|
||||||
address that the module is loaded at, and subtract
|
|
||||||
this from the EIP value. add any offset used in the
|
|
||||||
module link specification (I dont think there currently
|
|
||||||
is one), and look for the last symbol with a lower
|
|
||||||
address offset.
|
|
||||||
|
|
||||||
Brian, I have an idea on how to make this exception
|
|
||||||
dump information a little more useful. We should
|
|
||||||
have the load information for the load modules
|
|
||||||
in memory somewhere. Perhaps the exception
|
|
||||||
dump could check offending addresses to see if
|
|
||||||
they lie in the kernel or in a module, and if they
|
|
||||||
lie in a module the proper offset could be subtracted
|
|
||||||
and this number could be displayed seperately. If
|
|
||||||
I get a chance today, I'll make this change and send
|
|
||||||
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>
|
|
||||||
Organization: Microsoft Corp.
|
|
||||||
Newsgroups: microsoft.public.win32.programmer.kernel, comp.os.ms-windows.programmer.nt.kernel-mode
|
|
||||||
References: 1
|
|
||||||
|
|
||||||
Radu, I post the following information occassionally for questions such as
|
|
||||||
yours. I hope it helps.
|
|
||||||
|
|
||||||
-Paul
|
|
||||||
|
|
||||||
Here is an explanation of buffers and DeviceIoControl.
|
|
||||||
|
|
||||||
First, here are the parameters,
|
|
||||||
|
|
||||||
BOOL DeviceIoControl(
|
|
||||||
HANDLE hDevice, // handle to device of interest
|
|
||||||
DWORD dwIoControlCode, // control code of operation to perform
|
|
||||||
LPVOID lpInBuffer, // pointer to buffer to supply input data
|
|
||||||
DWORD nInBufferSize, // size of input buffer
|
|
||||||
LPVOID lpOutBuffer, // pointer to buffer to receive output data
|
|
||||||
DWORD nOutBufferSize, // size of output buffer
|
|
||||||
LPDWORD lpBytesReturned, // pointer to variable to receive output byte
|
|
||||||
count
|
|
||||||
LPOVERLAPPED lpOverlapped // pointer to overlapped structure for
|
|
||||||
asynchronous operation
|
|
||||||
);
|
|
||||||
|
|
||||||
METHOD_BUFFERED
|
|
||||||
|
|
||||||
user-mode perspective
|
|
||||||
|
|
||||||
lpInBuffer - optional, contains data that is written to the driver
|
|
||||||
lpOutBuffer - optional, contains data that is read from the driver after
|
|
||||||
the call has completed
|
|
||||||
|
|
||||||
lpInBuffer and lpOutBuffer can be two buffers or a single shared buffer.
|
|
||||||
If a shared buffer, lpInBuffer is overwritten by lpOutBuffer.
|
|
||||||
|
|
||||||
|
|
||||||
I/O Manager perspective
|
|
||||||
|
|
||||||
examines nInBufferSize and nOutBufferSize. Allocates memory from non-paged
|
|
||||||
pool and puts the address of this pool in Irp->AssociatedIrp.SystemBuffer.
|
|
||||||
The size of this buffer is equal to the size of the larger of the two
|
|
||||||
bufferes. This buffer is accessible at any IRQL.
|
|
||||||
|
|
||||||
copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
|
|
||||||
copies nOutBufferSize to
|
|
||||||
irpSp->Parameters.DeviceIoControl.OutputBufferLength
|
|
||||||
copies contents of lpInBuffer to SystemBuffer allocated above
|
|
||||||
calls your driver
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Device Driver perspective
|
|
||||||
|
|
||||||
you have one buffer, Irp->AssociatedIrp.SystemBuffer. You read input data
|
|
||||||
from this buffer and you write output data to the same buffer, overwriting
|
|
||||||
the input data.
|
|
||||||
|
|
||||||
Before calling IoCompleteRequest, you must
|
|
||||||
- set IoStatus.Status to an approriate NtStatus
|
|
||||||
- if IoStatus.Status == STATUS_SUCCESS
|
|
||||||
set IoStatus.Information to the
|
|
||||||
number of bytes you want copied
|
|
||||||
from the SystemBuffer back into
|
|
||||||
lpOutBuffer.
|
|
||||||
|
|
||||||
|
|
||||||
I/O Manager Completion Routine perspective
|
|
||||||
|
|
||||||
looks at IoStatus block, if IoStatus.Status = STATUS_SUCCESS, copies the
|
|
||||||
number of bytes specified by IoStatus.Information from
|
|
||||||
Irp->AssociatedIrp.SystemBuffer into lpOutBuffer
|
|
||||||
completes the request
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
METHOD_IN_DIRECT
|
|
||||||
|
|
||||||
user-mode perspective
|
|
||||||
|
|
||||||
lpInBuffer - optional, contains data that is written to the driver. This
|
|
||||||
buffer is used in the exact same fashion as METHOD_BUFFERED. To avoid
|
|
||||||
confusion, mentally rename this buffer to lpControlBuffer. This is
|
|
||||||
typically a small, optional buffer that might contain a control structure
|
|
||||||
with useful information for the device driver. This buffer is smal and is
|
|
||||||
double buffered.
|
|
||||||
|
|
||||||
lpOutBuffer - NOT OPTIONAL, This LARGE buffer contains data that is read by
|
|
||||||
the driver. To avoid confusion, mentally rename this buffer to
|
|
||||||
lpDataTransferBuffer. This is physically the same buffer that the device
|
|
||||||
driver will read from. There is no double buffering. Technically, this
|
|
||||||
buffer is still optional, but since you are using this buffering method,
|
|
||||||
what would be the point???
|
|
||||||
|
|
||||||
I/O Manager perspective
|
|
||||||
|
|
||||||
If lpInBuffer exists, allocates memory from non-paged pool and puts the
|
|
||||||
address of this pool in Irp->AssociatedIrp.SystemBuffer. This buffer is
|
|
||||||
accessible at any IRQL.
|
|
||||||
|
|
||||||
copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
|
|
||||||
copies nOutBufferSize to
|
|
||||||
irpSp->Parameters.DeviceIoControl.OutputBufferLength
|
|
||||||
copies contents of lpInBuffer to SystemBuffer allocated above
|
|
||||||
So far this is completely identical to METHOD_BUFFERED. Most likely
|
|
||||||
lpInBuffer (mentally renamed to lpControlBuffer) is very small in size.
|
|
||||||
|
|
||||||
For lpOutBuffer (mentally renamed to lpDataTransferBuffer), an MDL is
|
|
||||||
allocated. lpOutBuffer is probed and locked into memory. Then, the user
|
|
||||||
buffer virtual addresses are checked to be sure they are readable in the
|
|
||||||
caller's access mode.
|
|
||||||
|
|
||||||
The MDL is address is stored in Irp->MdlAddress.
|
|
||||||
Your driver is called.
|
|
||||||
|
|
||||||
|
|
||||||
Device Driver perspective
|
|
||||||
|
|
||||||
The device driver can read the copy of lpOutBuffer via
|
|
||||||
Irp->AssociatedIrp.SystemBuffer. Anything written by the device driver to
|
|
||||||
this buffer is lost. The I/O Manager does not copy any data back to the
|
|
||||||
user-mode buffers as it did in the completion routine for METHOD_BUFFERED.
|
|
||||||
Art Baker's book is wrong in this respect (page 168, "data going from the
|
|
||||||
driver back to the caller is passed through an intermediate system-space
|
|
||||||
buffer" and page 177, "When the IOCTL IRP is completed, the contents of the
|
|
||||||
system buffer will be copied back into the callers original output buffer".
|
|
||||||
|
|
||||||
The device driver accesses the Win32 buffer directly via Irp->MdlAddress.
|
|
||||||
The driver uses whatever Mdl API's to read the buffer. Usually, this
|
|
||||||
buffer is to be written to some mass storage media or some similar
|
|
||||||
operation. Since this is a large data transfer, assume a completion
|
|
||||||
routine is required.
|
|
||||||
|
|
||||||
mark the Irp pending
|
|
||||||
queue it
|
|
||||||
return status pending
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Device Driver Completion Routine perspective
|
|
||||||
|
|
||||||
standard completion routine operations
|
|
||||||
set IoStatus.Status to an approriate NtStatus
|
|
||||||
IoStatus.Information is not needed
|
|
||||||
completete the request
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
I/O Manager Completion Routine perspective
|
|
||||||
|
|
||||||
standard I/O Manager completion routine operations
|
|
||||||
unmap the pages
|
|
||||||
deallocate the Mdl
|
|
||||||
complete the request
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
METHOD_OUT_DIRECT
|
|
||||||
|
|
||||||
user-mode perspective
|
|
||||||
|
|
||||||
lpInBuffer - optional, contains data that is written to the driver. This
|
|
||||||
buffer is used in the exact same fashion as METHOD_BUFFERED. To avoid
|
|
||||||
confusion, mentally rename this buffer to lpControlBuffer. This is
|
|
||||||
typically a small, optional buffer that might contain a control structure
|
|
||||||
with useful information for the device driver. This buffer is smal and is
|
|
||||||
double buffered.
|
|
||||||
|
|
||||||
lpOutBuffer - NOT OPTIONAL, This LARGE buffer contains data that is written
|
|
||||||
by the driver and read by the wer-mode application when the request is
|
|
||||||
completed. To avoid confusion, mentally rename this buffer to
|
|
||||||
lpDataTransferBuffer. This is physically the same buffer that the device
|
|
||||||
driver will write to. There is no double buffering. Technically, this
|
|
||||||
buffer is still optional, but since you are using this buffering method,
|
|
||||||
what would be the point???
|
|
||||||
|
|
||||||
I/O Manager perspective
|
|
||||||
|
|
||||||
If lpInBuffer exists, allocates memory from non-paged pool and puts the
|
|
||||||
address of this pool in Irp->AssociatedIrp.SystemBuffer. This buffer is
|
|
||||||
accessible at any IRQL.
|
|
||||||
|
|
||||||
copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
|
|
||||||
copies nOutBufferSize to
|
|
||||||
irpSp->Parameters.DeviceIoControl.OutputBufferLength
|
|
||||||
copies contents of lpInBuffer to SystemBuffer allocated above
|
|
||||||
So far this is completely identical to METHOD_BUFFERED. Most likely
|
|
||||||
lpInBuffer (mentally renamed to lpControlBuffer) is very small in size.
|
|
||||||
|
|
||||||
For lpOutBuffer (mentally renamed to lpDataTransferBuffer), an MDL is
|
|
||||||
allocated. lpOutBuffer is probed and locked into memory. Then the user
|
|
||||||
buffer's addresses are checked to make sure the caller could write to them
|
|
||||||
in the caller's access mode.
|
|
||||||
|
|
||||||
The MDL is address is stored in Irp->MdlAddress.
|
|
||||||
Your driver is called.
|
|
||||||
|
|
||||||
|
|
||||||
Device Driver perspective
|
|
||||||
|
|
||||||
The device driver can read the copy of lpOutBuffer via
|
|
||||||
Irp->AssociatedIrp.SystemBuffer. Anything written by the device driver to
|
|
||||||
this buffer is lost.
|
|
||||||
|
|
||||||
The device driver accesses the Win32 buffer directly via Irp->MdlAddress.
|
|
||||||
The driver uses whatever Mdl API's to write data to the buffer. Usually,
|
|
||||||
this buffer is to be read from some mass storage media or some similar
|
|
||||||
operation. Since this is a large data transfer, assume a completion
|
|
||||||
routine is required.
|
|
||||||
|
|
||||||
mark the Irp pending
|
|
||||||
queue it
|
|
||||||
return status pending
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Device Driver Completion Routine perspective
|
|
||||||
|
|
||||||
standard completion routine operations
|
|
||||||
set IoStatus.Status to an approriate NtStatus
|
|
||||||
IoStatus.Information is not needed
|
|
||||||
completete the request
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
I/O Manager Completion Routine perspective
|
|
||||||
|
|
||||||
standard I/O Manager completion routine operations
|
|
||||||
unmap the pages
|
|
||||||
deallocate the Mdl
|
|
||||||
complete the request
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
METHOD_NEITHER
|
|
||||||
|
|
||||||
I/O Manager perspective
|
|
||||||
|
|
||||||
Irp->UserBuffer = lpOutputBuffer;
|
|
||||||
IrpSp->Parameters.DeviceIoControl.Type3InputBuffer = lpInputBuffer;
|
|
||||||
|
|
||||||
No comments here. Don't use METHOD_DIRECT unless you know what you are
|
|
||||||
doing. Simple rule.
|
|
||||||
|
|
||||||
If your IOCtl involves no data transfer buffers, then METHOD_NEITHER is the
|
|
||||||
fastest path through the I/O Manager that involves an Irp.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Final Comment
|
|
||||||
|
|
||||||
Don't touch Irp->UserBuffer. This is a bookmark for the I/O Manager. Two
|
|
||||||
major problems can occur. 1 - page fault at high IRQL, or 2 - you write
|
|
||||||
something to Irp->UserBuffer and the I/O Manager overwrites you in its
|
|
||||||
completion routine. File systems access Irp->UserBuffer, but FSD writers
|
|
||||||
know all of the above and know when it is safe to touch Irp->UserBuffer.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Radu Woinaroski wrote in message <364F8F6E.2434B010@scitec.com.au>...
|
|
||||||
>Hello,
|
|
||||||
>
|
|
||||||
>I have a kernel-mode device driver that accepts a number of IoControl
|
|
||||||
>commands that use buffered data transfer (METHOD_BUFFERED).
|
|
||||||
>
|
|
||||||
>A user mode API provides a higher level access then the DeviceIoControl
|
|
||||||
>function.
|
|
||||||
>
|
|
||||||
>The function is implemented like that
|
|
||||||
>
|
|
||||||
>BOOL
|
|
||||||
Something(
|
|
||||||
> HANDLE hDevice ,
|
|
||||||
> int param1,
|
|
||||||
> int param2,
|
|
||||||
> DWORD * pReturn,
|
|
||||||
> LPOVERLAPPED pOverlapped)
|
|
||||||
>{
|
|
||||||
> // here a data buffer on the stack sent to asynchronous DeviceIoControl
|
|
||||||
>call
|
|
||||||
> int aDataIn[2];
|
|
||||||
> aDataIn[0] = param1;
|
|
||||||
> aDataIn[1] = param2;
|
|
||||||
>
|
|
||||||
> return DeviceIoControl(
|
|
||||||
> hDevice,
|
|
||||||
> DO_SOMETHING_IO,
|
|
||||||
> aDataIn,
|
|
||||||
> sizeof(int)*2,
|
|
||||||
> pReturn,
|
|
||||||
> sizeof(DWORD),
|
|
||||||
> pOverlapped);
|
|
||||||
>}
|
|
||||||
>
|
|
||||||
>The aDataIn buffer will not exist after DeviceIoControl returns (and
|
|
||||||
>when the I/O operation terminates). I know that for buffered IO the
|
|
||||||
>input data buffer is copyed by de IOManager to a nonpaged-pool area
|
|
||||||
>before passing the request to driver dispatch routine (DeviceControl).
|
|
||||||
>At the point of calling the dispatch routine (DeviceControl) the driver
|
|
||||||
>runs in the context of the calling thread so DeviceIoControl hasn't
|
|
||||||
>returned yet (?? or so I think) so aDataI
|
|
||||||
n will still be valid at the
|
|
||||||
>time IOManager copyes it to its buffer. So, this apears to work ok (at
|
|
||||||
>least in my opinion).
|
|
||||||
>
|
|
||||||
>Does I/O Manager use the Input buffer from the call to the Win32
|
|
||||||
>DeviceIoControl any where else after the first copy ?
|
|
||||||
>
|
|
||||||
>Is there any reason why this approach (passing a buffer on the stack to
|
|
||||||
>a asynchronous DeviceIoControl that uses buffered I/O) wouldn't work ?
|
|
||||||
>
|
|
||||||
>Allocating buffers from heap and deleting them on IO completion while
|
|
||||||
>managing asynchronous IO seems too much work ;-) .
|
|
||||||
>
|
|
||||||
>Thanks in advance for your opinions
|
|
||||||
>Radu W.
|
|
||||||
>
|
|
||||||
>--
|
|
||||||
>Radu Woinaroski
|
|
||||||
>Scitec
|
|
||||||
>Sydney, Australia
|
|
||||||
>Radu.Woinaroski@scitec.com.au
|
|
||||||
-----
|
|
||||||
Subject: Re: PCI ISR problem
|
|
||||||
Date: Fri, 20 Nov 1998 18:04:48 GMT
|
|
||||||
From: jeh@cmkrnl.com (Jamie Hanrahan)
|
|
||||||
Organization: Kernel Mode Systems, San Diego, CA
|
|
||||||
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
|
|
||||||
References: 1
|
|
||||||
|
|
||||||
On Thu, 19 Nov 1998 15:46:13 -0600, Eric Gardiner
|
|
||||||
<eric.gardiner@natinst.com> wrote:
|
|
||||||
|
|
||||||
>I'm having problems with NT4 not hooking the interrupt line indicated by
|
|
||||||
>a PCI device. Here's what I'm doing:
|
|
||||||
>
|
|
||||||
>1) Enumerating the PCI buses on the system (using HalGetBusData) until
|
|
||||||
>I find my device.
|
|
||||||
>2) Once my device is found, I read the "Interrupt Line Register" in the
|
|
||||||
>device's PCI config space to determine what interrupt level to pass to
|
|
||||||
>HalGetInterruptVector.
|
|
||||||
|
|
||||||
Whups! No. Call HalAssignSlotResources and look at the returned
|
|
||||||
CM_RESOURCE_LIST to find the vector, level, port addresses, etc., for
|
|
||||||
your device. (Then pass the returned CM_RESOURCE_LIST to ExFreePool.)
|
|
||||||
|
|
||||||
|
|
||||||
See Knowledge Base article Q152044.
|
|
||||||
|
|
||||||
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (jeh@cmkrnl.com)
|
|
||||||
Drivers, internals, networks, applications, and training for VMS and Windows NT
|
|
||||||
NT kernel driver FAQ, links, and other information: http://www.cmkrnl.com/
|
|
||||||
|
|
||||||
Please post replies, followups, questions, etc., in news, not via e-mail.
|
|
||||||
-----
|
|
||||||
Subject: Re: IRP canceling
|
|
||||||
Date: Mon, 23 Nov 1998 09:05:47 -0500
|
|
||||||
From: Walter Oney <waltoney@oneysoft.com>
|
|
||||||
Organization: Walter Oney Software
|
|
||||||
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
|
|
||||||
References: 1
|
|
||||||
|
|
||||||
Seol,Keun Seok wrote:
|
|
||||||
> But, if the IRP was the CurrentIrp of the Device Object,
|
|
||||||
> the Driver's Start I/O routine will try to process the IRP.
|
|
||||||
> In the DDK help, the Start I/O routine MUST check the current IRP's
|
|
||||||
> Cancel bit.
|
|
||||||
> If set, Start I/O routine must just return.
|
|
||||||
>
|
|
||||||
> But I think that the IRP already completed should not be accessed.
|
|
||||||
|
|
||||||
You're absolutely right. I recommend the following code in a standard
|
|
||||||
StartIo routine to avoid the problem you point out:
|
|
||||||
|
|
||||||
VOID StartIo(PDEVICE_OBJECT DeviceObject, PIRP Irp)
|
|
||||||
{
|
|
||||||
KIRQL oldirql;
|
|
||||||
IoAcquireCancelSpinLock(&oldirql);
|
|
||||||
if (Irp != DeviceObject->CurrentIrp || Irp->Cancel)
|
|
||||||
{
|
|
||||||
IoReleaseCancelSpinLock(oldirql);
|
|
||||||
return;
|
|
||||||
}
|
|
||||||
else
|
|
||||||
{
|
|
||||||
IoSetCancelRoutine(Irp, NULL);
|
|
||||||
IoReleaseCancelSpinLock(oldirql);
|
|
||||||
}
|
|
||||||
. . .
|
|
||||||
}
|
|
||||||
|
|
||||||
This dovetails with a standard cancel routine:
|
|
||||||
|
|
||||||
VOID CancelRoutine(PDEVICE_OBJECT DeviceObject, PIRP Irp)
|
|
||||||
{
|
|
||||||
if (DeviceObject->CurrentIrp == Irp)
|
|
||||||
{
|
|
||||||
IoReleaseCancelSpinLock(Irp->CancelIrql);
|
|
||||||
IoStartNextPacket(DeviceObject, TRUE);
|
|
||||||
}
|
|
||||||
else
|
|
||||||
{
|
|
||||||
KeRemoveEntryDeviceQueue(&DeviceObject->DeviceQueue,
|
|
||||||
&Irp->Tail.Overlay.DeviceQueueEntry);
|
|
||||||
IoReleaseCancelSpinLock(Irp->CancelIrql);
|
|
||||||
}
|
|
||||||
Irp->IoStatus.Status = STATUS_CANCELLED;
|
|
||||||
Irp->IoStatus.Information = 0;
|
|
||||||
IoCompleteRequest(Irp, IO_NO_INCREMENT);
|
|
||||||
}
|
|
||||||
|
|
||||||
You need to remember that the C language specification requires that
|
|
||||||
evaluation of boolean operators short circuit when the result is known.
|
|
||||||
So, if StartIo discovers that the Irp it got as an argument is not the
|
|
||||||
same as CurrentIrp, it will not attempt to evaulate Irp->Cancel.
|
|
||||||
|
|
||||||
Now, as to why this works: StartIo gets called either by IoStartPacket
|
|
||||||
or IoStartNextPacket. Each of them will grab the cancel spin lock and
|
|
||||||
set CurrentIrp, then release the spin lock and call StartIo. If someone
|
|
||||||
should sneak in on another CPU and cancel this very same IRP, your
|
|
||||||
cancel routine will immediately release the spin lock and call
|
|
||||||
IoStartNextPacket. One of two things will then happen. IoStartNextPacket
|
|
||||||
may succeed in getting the cancel spin lock, whereupon it will nullify
|
|
||||||
the CurrentIrp pointer. If another IRP is on the queue, it will remove
|
|
||||||
it from the queue, set CurrentIrp to point to this *new* IRP, release
|
|
||||||
the spin lock, and call StartIo. [You now have two instances of StartIo
|
|
||||||
running on two different CPUs for two different IRPs, but it's not a
|
|
||||||
problem because they won't be able to interfere with each other.]
|
|
||||||
Meanwhile, your original instance of StartIo gets the cancel spin lock
|
|
||||||
and sees that CurrentIrp is not equal to the IRP pointer it got as an
|
|
||||||
argument, so it gives up.
|
|
||||||
|
|
||||||
The second way this could play out is that StartIo gets the cancel lock
|
|
||||||
before IoStartNextPacket does. In this case, CurrentIrp is still
|
|
||||||
pointing to the IRP that's in the process of being cancelled and that
|
|
||||||
StartIo got as an argument. But this IRP hasn't been completed yet (the
|
|
||||||
CPU that's running your cancel routine is spinning inside
|
|
||||||
IoStartNextPacket and therefore hasn't gotten to calling
|
|
||||||
IoCompleteRequest yet), so no-one will have been able to call IoFreeIrp
|
|
||||||
to make your pointer invalid.
|
|
||||||
|
|
||||||
People may tell you that you should be using your own queues for IRPs so
|
|
||||||
you can avoid bottlenecking the system on the global cancel spin lock.
|
|
||||||
That's true enough, but doing it correctly with Plug and Play and Power
|
|
||||||
management things in the way is gigantically complicated. There's a
|
|
||||||
sample in the NT 5 beta-2 DDK called CANCEL that shows how to manage
|
|
||||||
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
|
|
||||||
-----
|
|
||||||
|
|
||||||
|
|
@ -17,7 +17,7 @@
|
||||||
#include <internal/string.h>
|
#include <internal/string.h>
|
||||||
#include <wstring.h>
|
#include <wstring.h>
|
||||||
|
|
||||||
#define NDEBUG
|
//#define NDEBUG
|
||||||
#include <internal/debug.h>
|
#include <internal/debug.h>
|
||||||
|
|
||||||
/* FUNCTIONS *************************************************************/
|
/* FUNCTIONS *************************************************************/
|
||||||
|
|
|
||||||
|
|
@ -73,7 +73,7 @@ NTSTATUS ZwReadFile(HANDLE FileHandle,
|
||||||
if (Status != STATUS_SUCCESS)
|
if (Status != STATUS_SUCCESS)
|
||||||
{
|
{
|
||||||
DPRINT("ZwReadFile() =");
|
DPRINT("ZwReadFile() =");
|
||||||
DbgPrintErrorMessage(Status);
|
// DbgPrintErrorMessage(Status);
|
||||||
return(Status);
|
return(Status);
|
||||||
}
|
}
|
||||||
assert(FileObject != NULL);
|
assert(FileObject != NULL);
|
||||||
|
|
|
||||||
|
|
@ -10,42 +10,10 @@
|
||||||
|
|
||||||
/* INCLUDE *****************************************************************/
|
/* INCLUDE *****************************************************************/
|
||||||
|
|
||||||
#include <windows.h>
|
|
||||||
#include <ddk/ntddk.h>
|
#include <ddk/ntddk.h>
|
||||||
|
|
||||||
/* GLOBALS *****************************************************************/
|
|
||||||
|
|
||||||
/*
|
|
||||||
* Last error code (this should be per process)
|
|
||||||
*/
|
|
||||||
DWORD error_code = 0;
|
|
||||||
|
|
||||||
/* FUNCTIONS ***************************************************************/
|
/* FUNCTIONS ***************************************************************/
|
||||||
|
|
||||||
DWORD STDCALL GetLastError(VOID)
|
|
||||||
/*
|
|
||||||
* FUNCTION: Get the detailed error (if any) from the last function
|
|
||||||
* RECEIVES: Nothing
|
|
||||||
* RETURNS:
|
|
||||||
* The error code
|
|
||||||
*/
|
|
||||||
{
|
|
||||||
return(error_code);
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
VOID STDCALL SetLastError(DWORD dwErrCode)
|
|
||||||
/*
|
|
||||||
* FUNCTION: Set the last error code
|
|
||||||
* RECEIVES:
|
|
||||||
* dwErrCode = the error code to set
|
|
||||||
* RETURNS: Nothing
|
|
||||||
*/
|
|
||||||
{
|
|
||||||
error_code=dwErrCode;
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS STDCALL NtRaiseHardError(VOID)
|
NTSTATUS STDCALL NtRaiseHardError(VOID)
|
||||||
{
|
{
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,9 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/atom.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Atom managment
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: Nobody
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
*/
|
*/
|
||||||
|
|
@ -19,60 +19,41 @@
|
||||||
NTSTATUS STDCALL NtAddAtom(OUT ATOM *Atom,
|
NTSTATUS STDCALL NtAddAtom(OUT ATOM *Atom,
|
||||||
IN PUNICODE_STRING AtomString)
|
IN PUNICODE_STRING AtomString)
|
||||||
{
|
{
|
||||||
|
return(ZwAddAtom(Atom, AtomString));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwAddAtom(OUT ATOM *Atom,
|
||||||
STDCALL
|
IN PUNICODE_STRING AtomString)
|
||||||
ZwAddAtom(
|
|
||||||
OUT ATOM *Atom,
|
|
||||||
IN PUNICODE_STRING AtomString
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtDeleteAtom(IN ATOM Atom)
|
||||||
STDCALL
|
|
||||||
NtDeleteAtom(
|
|
||||||
IN ATOM Atom
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwDeleteAtom(Atom));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwDeleteAtom(IN ATOM Atom)
|
||||||
STDCALL
|
|
||||||
ZwDeleteAtom(
|
|
||||||
IN ATOM Atom
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtFindAtom(OUT ATOM *Atom, IN PUNICODE_STRING AtomString)
|
||||||
STDCALL
|
|
||||||
NtFindAtom(
|
|
||||||
OUT ATOM *Atom,
|
|
||||||
IN PUNICODE_STRING AtomString
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwFindAtom(Atom, AtomString));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwFindAtom(OUT ATOM *Atom, IN PUNICODE_STRING AtomString)
|
||||||
STDCALL
|
|
||||||
ZwFindAtom(
|
|
||||||
OUT ATOM *Atom,
|
|
||||||
IN PUNICODE_STRING AtomString
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtQueryInformationAtom(IN HANDLE AtomHandle,
|
||||||
STDCALL
|
|
||||||
NtQueryInformationAtom(
|
|
||||||
IN HANDLE AtomHandle,
|
|
||||||
IN CINT AtomInformationClass,
|
IN CINT AtomInformationClass,
|
||||||
OUT PVOID AtomInformation,
|
OUT PVOID AtomInformation,
|
||||||
IN ULONG AtomInformationLength,
|
IN ULONG AtomInformationLength,
|
||||||
OUT PULONG ReturnLength
|
OUT PULONG ReturnLength)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -8,6 +8,14 @@
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
/*
|
||||||
|
* NOTES:
|
||||||
|
*
|
||||||
|
* An article on System Internals (http://www.sysinternals.com) reports
|
||||||
|
* that these functions are unimplemented on nt version 3-5.
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
|
||||||
/* INCLUDES *****************************************************************/
|
/* INCLUDES *****************************************************************/
|
||||||
|
|
||||||
#include <ddk/ntddk.h>
|
#include <ddk/ntddk.h>
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/evtpair.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Support for event pairs
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@mcmail.com)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
|
|
@ -16,141 +16,96 @@
|
||||||
|
|
||||||
/* FUNCTIONS *****************************************************************/
|
/* FUNCTIONS *****************************************************************/
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtCreateEventPair(OUT PHANDLE EventPairHandle,
|
||||||
STDCALL
|
|
||||||
NtCreateEventPair(
|
|
||||||
OUT PHANDLE EventPairHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwCreateEventPair(EventPairHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwCreateEventPair(OUT PHANDLE EventPairHandle,
|
||||||
STDCALL
|
|
||||||
ZwCreateEventPair(
|
|
||||||
OUT PHANDLE EventPairHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL NtSetHighEventPair(IN HANDLE EventPairHandle)
|
||||||
|
{
|
||||||
|
return(ZwSetHighEventPair(EventPairHandle));
|
||||||
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL ZwSetHighEventPair(IN HANDLE EventPairHandle)
|
||||||
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL NtSetHighWaitLowEventPair(IN HANDLE EventPairHandle)
|
||||||
|
{
|
||||||
|
return(ZwSetHighWaitLowEventPair(EventPairHandle));
|
||||||
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL ZwSetHighWaitLowEventPair(IN HANDLE EventPairHandle)
|
||||||
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtSetLowEventPair(HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
NtSetHighEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwSetLowEventPair(EventPairHandle));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwSetLowEventPair(HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
ZwSetHighEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
|
||||||
}
|
|
||||||
|
|
||||||
NTSTATUS
|
|
||||||
STDCALL
|
|
||||||
NtSetHighWaitLowEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
|
||||||
}
|
|
||||||
|
|
||||||
NTSTATUS
|
|
||||||
STDCALL
|
|
||||||
ZwSetHighWaitLowEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtSetLowWaitHighEventPair(HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
NtSetLowEventPair(
|
|
||||||
HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwSetLowWaitHighEventPair(EventPairHandle));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwSetLowWaitHighEventPair(HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
ZwSetLowEventPair(
|
|
||||||
HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL NtWaitLowEventPair(IN HANDLE EventPairHandle)
|
||||||
NTSTATUS
|
|
||||||
STDCALL
|
|
||||||
NtSetLowWaitHighEventPair(
|
|
||||||
HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwWaitLowEventPair(EventPairHandle));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwWaitLowEventPair(IN HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
ZwSetLowWaitHighEventPair(
|
|
||||||
HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtOpenEventPair(OUT PHANDLE EventPairHandle,
|
||||||
STDCALL
|
|
||||||
NtWaitLowEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
|
||||||
}
|
|
||||||
|
|
||||||
NTSTATUS
|
|
||||||
STDCALL
|
|
||||||
ZwWaitLowEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
|
||||||
}
|
|
||||||
|
|
||||||
NTSTATUS
|
|
||||||
STDCALL
|
|
||||||
NtOpenEventPair(
|
|
||||||
OUT PHANDLE EventPairHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwOpenEventPair(EventPairHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwOpenEventPair(OUT PHANDLE EventPairHandle,
|
||||||
STDCALL
|
|
||||||
ZwOpenEventPair(
|
|
||||||
OUT PHANDLE EventPairHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtWaitHighEventPair(IN HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
NtWaitHighEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwWaitHighEventPair(EventPairHandle));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwWaitHighEventPair(IN HANDLE EventPairHandle)
|
||||||
STDCALL
|
|
||||||
ZwWaitHighEventPair(
|
|
||||||
IN HANDLE EventPairHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
@ -1,9 +1,9 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/mutant.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Synchronization primitives
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@cwcom.net)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
*/
|
*/
|
||||||
|
|
@ -16,88 +16,73 @@
|
||||||
|
|
||||||
/* FUNCTIONS *****************************************************************/
|
/* FUNCTIONS *****************************************************************/
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtCreateMutant(OUT PHANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
NtCreateMutant(
|
|
||||||
OUT PHANDLE MutantHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
||||||
IN BOOLEAN InitialOwner
|
IN BOOLEAN InitialOwner)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwCreateMutant(MutantHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes,
|
||||||
|
InitialOwner));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwCreateMutant(OUT PHANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
ZwCreateMutant(
|
|
||||||
OUT PHANDLE MutantHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
||||||
IN BOOLEAN InitialOwner
|
IN BOOLEAN InitialOwner)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtOpenMutant(OUT PHANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
NtOpenMutant(
|
|
||||||
OUT PHANDLE MutantHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwOpenMutant(MutantHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwOpenMutant(OUT PHANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
ZwOpenMutant(
|
|
||||||
OUT PHANDLE MutantHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtQueryMutant(IN HANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
NtQueryMutant(
|
|
||||||
IN HANDLE MutantHandle,
|
|
||||||
IN CINT MutantInformationClass,
|
IN CINT MutantInformationClass,
|
||||||
OUT PVOID MutantInformation,
|
OUT PVOID MutantInformation,
|
||||||
IN ULONG Length,
|
IN ULONG Length,
|
||||||
OUT PULONG ResultLength
|
OUT PULONG ResultLength)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwQueryMutant(MutantHandle,
|
||||||
|
MutantInformationClass,
|
||||||
|
MutantInformation,
|
||||||
|
Length,
|
||||||
|
ResultLength));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwQueryMutant(IN HANDLE MutantHandle,
|
||||||
STDCALL
|
|
||||||
ZwQueryMutant(
|
|
||||||
IN HANDLE MutantHandle,
|
|
||||||
IN CINT MutantInformationClass,
|
IN CINT MutantInformationClass,
|
||||||
OUT PVOID MutantInformation,
|
OUT PVOID MutantInformation,
|
||||||
IN ULONG Length,
|
IN ULONG Length,
|
||||||
OUT PULONG ResultLength
|
OUT PULONG ResultLength)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
NTSTATUS STDCALL NtReleaseMutant(IN HANDLE MutantHandle,
|
||||||
NTSTATUS
|
IN PULONG ReleaseCount OPTIONAL)
|
||||||
STDCALL
|
|
||||||
NtReleaseMutant(
|
|
||||||
IN HANDLE MutantHandle,
|
|
||||||
IN PULONG ReleaseCount OPTIONAL
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwReleaseMutant(MutantHandle,
|
||||||
|
ReleaseCount));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwReleaseMutant(IN HANDLE MutantHandle,
|
||||||
STDCALL
|
IN PULONG ReleaseCount OPTIONAL)
|
||||||
ZwReleaseMutant(
|
|
||||||
IN HANDLE MutantHandle,
|
|
||||||
IN PULONG ReleaseCount OPTIONAL
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/ntsem.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Synchronization primitives
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@mcmail.com)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
|
|
@ -16,91 +16,79 @@
|
||||||
|
|
||||||
/* FUNCTIONS *****************************************************************/
|
/* FUNCTIONS *****************************************************************/
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtCreateSemaphore(OUT PHANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
NtCreateSemaphore(
|
|
||||||
OUT PHANDLE SemaphoreHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
|
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
|
||||||
IN ULONG InitialCount,
|
IN ULONG InitialCount,
|
||||||
IN ULONG MaximumCount
|
IN ULONG MaximumCount)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwCreateSemaphore(SemaphoreHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes,
|
||||||
|
InitialCount,
|
||||||
|
MaximumCount));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwCreateSemaphore(OUT PHANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
ZwCreateSemaphore(
|
|
||||||
OUT PHANDLE SemaphoreHandle,
|
|
||||||
IN ACCESS_MASK DesiredAccess,
|
IN ACCESS_MASK DesiredAccess,
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
|
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
|
||||||
IN ULONG InitialCount,
|
IN ULONG InitialCount,
|
||||||
IN ULONG MaximumCount
|
IN ULONG MaximumCount)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtOpenSemaphore(IN HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
IN ACCESS_MASK DesiredAccess,
|
||||||
NtOpenSemaphore(
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
IN HANDLE SemaphoreHandle,
|
|
||||||
IN ACCESS_MASK DesiredAcces,
|
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwOpenSemaphore(SemaphoreHandle,
|
||||||
|
DesiredAccess,
|
||||||
|
ObjectAttributes));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwOpenSemaphore(IN HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
IN ACCESS_MASK DesiredAccess,
|
||||||
ZwOpenSemaphore(
|
IN POBJECT_ATTRIBUTES ObjectAttributes)
|
||||||
IN HANDLE SemaphoreHandle,
|
|
||||||
IN ACCESS_MASK DesiredAcces,
|
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtQuerySemaphore(HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
NtQuerySemaphore(
|
|
||||||
HANDLE SemaphoreHandle,
|
|
||||||
CINT SemaphoreInformationClass,
|
CINT SemaphoreInformationClass,
|
||||||
OUT PVOID SemaphoreInformation,
|
OUT PVOID SemaphoreInformation,
|
||||||
ULONG Length,
|
ULONG Length,
|
||||||
PULONG ReturnLength
|
PULONG ReturnLength)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwQuerySemaphore(SemaphoreHandle,
|
||||||
|
SemaphoreInformationClass,
|
||||||
|
SemaphoreInformation,
|
||||||
|
Length,
|
||||||
|
ReturnLength));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwQuerySemaphore(HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
ZwQuerySemaphore(
|
|
||||||
HANDLE SemaphoreHandle,
|
|
||||||
CINT SemaphoreInformationClass,
|
CINT SemaphoreInformationClass,
|
||||||
OUT PVOID SemaphoreInformation,
|
OUT PVOID SemaphoreInformation,
|
||||||
ULONG Length,
|
ULONG Length,
|
||||||
PULONG ReturnLength
|
PULONG ReturnLength)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtReleaseSemaphore(IN HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
NtReleaseSemaphore(
|
|
||||||
IN HANDLE SemaphoreHandle,
|
|
||||||
IN ULONG ReleaseCount,
|
IN ULONG ReleaseCount,
|
||||||
IN PULONG PreviousCount
|
IN PULONG PreviousCount)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
return(ZwReleaseSemaphore(SemaphoreHandle,
|
||||||
|
ReleaseCount,
|
||||||
|
PreviousCount));
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL ZwReleaseSemaphore(IN HANDLE SemaphoreHandle,
|
||||||
STDCALL
|
|
||||||
ZwReleaseSemaphore(
|
|
||||||
IN HANDLE SemaphoreHandle,
|
|
||||||
IN ULONG ReleaseCount,
|
IN ULONG ReleaseCount,
|
||||||
IN PULONG PreviousCount
|
IN PULONG PreviousCount)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/nttimer.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: User-mode timers
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@mcmail.com)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
/*
|
/*
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/ke/bug.c
|
* FILE: ntoskrnl/nt/plugplay.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Mysterious nt4 support for plug-and-play
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@mcmail.com)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
|
|
@ -18,8 +18,10 @@
|
||||||
|
|
||||||
NTSTATUS STDCALL NtGetPlugPlayEvent(VOID)
|
NTSTATUS STDCALL NtGetPlugPlayEvent(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtPlugPlayControl(VOID)
|
NTSTATUS STDCALL NtPlugPlayControl(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/nt/port.c
|
* FILE: ntoskrnl/nt/port.c
|
||||||
* PURPOSE: Graceful system shutdown if a bug is detected
|
* PURPOSE: Communication mechanism (like Mach?)
|
||||||
* PROGRAMMER: David Welch (welch@mcmail.com)
|
* PROGRAMMER: David Welch (welch@mcmail.com)
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
* Created 22/05/98
|
* Created 22/05/98
|
||||||
|
|
@ -18,44 +18,55 @@
|
||||||
|
|
||||||
NTSTATUS STDCALL NtAcceptConnectPort(VOID)
|
NTSTATUS STDCALL NtAcceptConnectPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtCompleteConnectPort(VOID)
|
NTSTATUS STDCALL NtCompleteConnectPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtConnectPort(VOID)
|
NTSTATUS STDCALL NtConnectPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtCreatePort(VOID)
|
NTSTATUS STDCALL NtCreatePort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtListenPort(VOID)
|
NTSTATUS STDCALL NtListenPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtReplyPort(VOID)
|
NTSTATUS STDCALL NtReplyPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtReplyWaitReceivePort(VOID)
|
NTSTATUS STDCALL NtReplyWaitReceivePort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtReplyWaitReplyPort(VOID)
|
NTSTATUS STDCALL NtReplyWaitReplyPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtRequestPort(VOID)
|
NTSTATUS STDCALL NtRequestPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtRequestWaitReplyPort(VOID)
|
NTSTATUS STDCALL NtRequestWaitReplyPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS STDCALL NtQueryInformationPort(VOID)
|
NTSTATUS STDCALL NtQueryInformationPort(VOID)
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -2,8 +2,8 @@
|
||||||
* COPYRIGHT: See COPYING in the top level directory
|
* COPYRIGHT: See COPYING in the top level directory
|
||||||
* PROJECT: ReactOS kernel
|
* PROJECT: ReactOS kernel
|
||||||
* FILE: ntoskrnl/nt/Profile.c
|
* FILE: ntoskrnl/nt/Profile.c
|
||||||
* PURPOSE:
|
* PURPOSE: Support for profiling
|
||||||
* PROGRAMMER:
|
* PROGRAMMER: Nobody
|
||||||
* UPDATE HISTORY:
|
* UPDATE HISTORY:
|
||||||
*
|
*
|
||||||
*/
|
*/
|
||||||
|
|
@ -16,10 +16,7 @@
|
||||||
|
|
||||||
/* FUNCTIONS *****************************************************************/
|
/* FUNCTIONS *****************************************************************/
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtCreateProfile(OUT PHANDLE ProfileHandle,
|
||||||
STDCALL
|
|
||||||
NtCreateProfile(
|
|
||||||
OUT PHANDLE ProfileHandle,
|
|
||||||
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
IN POBJECT_ATTRIBUTES ObjectAttributes,
|
||||||
IN ULONG ImageBase,
|
IN ULONG ImageBase,
|
||||||
IN ULONG ImageSize,
|
IN ULONG ImageSize,
|
||||||
|
|
@ -27,41 +24,29 @@ NtCreateProfile(
|
||||||
OUT PVOID Buffer,
|
OUT PVOID Buffer,
|
||||||
IN ULONG ProfilingSize,
|
IN ULONG ProfilingSize,
|
||||||
IN ULONG ClockSource,
|
IN ULONG ClockSource,
|
||||||
IN ULONG ProcessorMask
|
IN ULONG ProcessorMask)
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtQueryIntervalProfile(OUT PULONG Interval,
|
||||||
STDCALL
|
OUT PULONG ClockSource)
|
||||||
NtQueryIntervalProfile(
|
|
||||||
OUT PULONG Interval,
|
|
||||||
OUT PULONG ClockSource
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtSetIntervalProfile(IN ULONG Interval,
|
||||||
STDCALL
|
IN ULONG ClockSource)
|
||||||
NtSetIntervalProfile(
|
|
||||||
IN ULONG Interval,
|
|
||||||
IN ULONG ClockSource
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtStartProfile(IN HANDLE ProfileHandle)
|
||||||
STDCALL
|
|
||||||
NtStartProfile(
|
|
||||||
IN HANDLE ProfileHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
||||||
NTSTATUS
|
NTSTATUS STDCALL NtStopProfile(IN HANDLE ProfileHandle)
|
||||||
STDCALL
|
|
||||||
NtStopProfile(
|
|
||||||
IN HANDLE ProfileHandle
|
|
||||||
)
|
|
||||||
{
|
{
|
||||||
|
UNIMPLEMENTED;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,21 +1,58 @@
|
||||||
DIRECTORIES
|
* Introduction
|
||||||
|
|
||||||
system : compiled versions of the various system components and
|
These are the sources for the ReactOS kernel, system libraries and
|
||||||
libraries
|
applications. ReactOS is the beginnings of a free clone of Windows NT
|
||||||
ntoskrnl : microkernel source
|
(aiming at version 4 right now). ReactOS isn't usuable for anything but
|
||||||
ntoskrnl/hal : hardware abstraction layer source
|
further development, please don't uninstall your existing OSs just yet.
|
||||||
ntoskrnl/mm : memory managment subsystem source
|
|
||||||
ntoskrnl/io : IO manager subsystem source
|
* Compilation
|
||||||
include : win32 headers
|
|
||||||
include/internal : kernel private header files
|
ReactOS currently only compiles using the djgpp compiler for DOS (or a djgpp
|
||||||
include/ntdll : system library private header files
|
cross compiler with some fiddling). This will change in the near future to
|
||||||
include/kernel32 : system library private header files
|
using the mingw32 compiler. It also needs the NASM assembler installed.
|
||||||
include/user32 : user interface private header files
|
To compile
|
||||||
include/gdi32 : graphics interface private header files
|
|
||||||
include/ddk : header files for modules
|
1) copy libgcc.a from the djgpp distribution to the ntoskrnl directory
|
||||||
lib/ntdll : NT dll source
|
2) make
|
||||||
lib/kernel32 : kernel32 source
|
|
||||||
doc : documentation
|
* Installation
|
||||||
loaders/dos : DOS based loader
|
|
||||||
loaders/boot : boot loader
|
By default ReactOS tries to execute 'c:\reactos\system\shell.bin' on
|
||||||
services : various services (device drivers, filesystems etc)
|
startup, if you want to see a user program running, copy either
|
||||||
|
'apps\hello\hello.bin' or 'apps\shell\shell.bin' to
|
||||||
|
'c:\reactos\system\shell.bin'. 'hello.bin' will write 'hello world' to the
|
||||||
|
console, 'shell.bin' will allow you to enter simple commands including
|
||||||
|
'dir', 'cd' and to execute additional processes e.g. 'hello.bin'.
|
||||||
|
|
||||||
|
* Running
|
||||||
|
|
||||||
|
Type 'boot.bat' from this directory. ReactOS won't start if a DPMI or VCPI
|
||||||
|
program is running e.g. Windows or EMM386.
|
||||||
|
|
||||||
|
* Further information
|
||||||
|
|
||||||
|
See the doc subdirectory, and these websites
|
||||||
|
|
||||||
|
http://www.sid-dis.com/reactos (main project website)
|
||||||
|
http://mok.lvcm.com/ (some more information including web based access
|
||||||
|
to the cvs server)
|
||||||
|
|
||||||
|
And also
|
||||||
|
|
||||||
|
http://www.delorie.com/djgpp/ (for DJGPP)
|
||||||
|
http://?? (for NASM)
|
||||||
|
http://www.microsoft.com/hwdev/ (Information on NT driver development)
|
||||||
|
http://www.sysinternals.com/ (NT internals)
|
||||||
|
http://www.osr.com/ (Information on NT internals, also get an NT
|
||||||
|
insider subscription)
|
||||||
|
http://www.internals.com/ (Some information)
|
||||||
|
http://www.winehq.com/ (Windows emulators for Unix)
|
||||||
|
|
||||||
|
Competitors
|
||||||
|
|
||||||
|
http://www.freedows.org/ (Aiming at an OS able to emulate various
|
||||||
|
systems including windows, vapourware so far)
|
||||||
|
http://www.solarmoon.org/ (Makers of a FreeBSD based NT clone, site now
|
||||||
|
blank)
|
||||||
|
http://www.genericwindows.com/ (Aiming to make a Windows 3.1 clone
|
||||||
|
based on FreeBSD and Wine)
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue