diff --git a/reactos/DIRS b/reactos/DIRS deleted file mode 100644 index 9accce17b5d..00000000000 --- a/reactos/DIRS +++ /dev/null @@ -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) diff --git a/reactos/NEWS b/reactos/NEWS index fb7fa65bcb1..654b9a26a67 100644 --- a/reactos/NEWS +++ b/reactos/NEWS @@ -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) System calls kernel32 now compiles (only as a static library) diff --git a/reactos/TODO b/reactos/TODO deleted file mode 100644 index bfd76881abf..00000000000 --- a/reactos/TODO +++ /dev/null @@ -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 - diff --git a/reactos/lib/crtdll/crtdll.def b/reactos/lib/crtdll/crtdll.def index 5649b845f6f..c839b50fbc0 100644 --- a/reactos/lib/crtdll/crtdll.def +++ b/reactos/lib/crtdll/crtdll.def @@ -17,9 +17,9 @@ ; DISCLAMED. This includes but is not limited to warrenties of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ; -; $Revision: 1.2 $ +; $Revision: 1.3 $ ; $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 ; probably not going to be able to use them in any case. @@ -713,3 +713,4 @@ wcsxfrm wctomb wprintf wscanf + diff --git a/reactos/lib/kernel32/file/curdir.c b/reactos/lib/kernel32/file/curdir.c index 314bbc6259c..a97a471901e 100644 --- a/reactos/lib/kernel32/file/curdir.c +++ b/reactos/lib/kernel32/file/curdir.c @@ -84,11 +84,7 @@ BOOL STDCALL SetCurrentDirectoryA(LPCSTR lpPathName) } -WINBOOL -STDCALL -SetCurrentDirectoryW( - LPCWSTR lpPathName - ) +WINBOOL STDCALL SetCurrentDirectoryW(LPCWSTR lpPathName) { if ( lpPathName == NULL ) return FALSE; @@ -188,12 +184,8 @@ GetWindowsDirectoryA( return uPathSize; } -UINT -STDCALL -GetSystemDirectoryW( - LPWSTR lpBuffer, - UINT uSize - ) +UINT STDCALL GetSystemDirectoryW(LPWSTR lpBuffer, + UINT uSize) { UINT uPathSize; if ( lpBuffer == NULL ) @@ -206,12 +198,8 @@ GetSystemDirectoryW( return uPathSize; } -UINT -STDCALL -GetWindowsDirectoryW( - LPWSTR lpBuffer, - UINT uSize - ) +UINT STDCALL GetWindowsDirectoryW(LPWSTR lpBuffer, + UINT uSize) { UINT uPathSize; if ( lpBuffer == NULL ) diff --git a/reactos/lib/kernel32/file/dir.c b/reactos/lib/kernel32/file/dir.c index ecd506d78ba..98bfd152163 100644 --- a/reactos/lib/kernel32/file/dir.c +++ b/reactos/lib/kernel32/file/dir.c @@ -8,30 +8,25 @@ * Created 01/11/98 */ +/* INCLUDES ******************************************************************/ + #include #include #include #include #include +/* FUNCTIONS *****************************************************************/ -WINBOOL -STDCALL -CreateDirectoryA( - LPCSTR lpPathName, - LPSECURITY_ATTRIBUTES lpSecurityAttributes - ) +WINBOOL STDCALL CreateDirectoryA(LPCSTR lpPathName, + LPSECURITY_ATTRIBUTES lpSecurityAttributes) { return CreateDirectoryExA(NULL,lpPathName,lpSecurityAttributes); } -WINBOOL -STDCALL -CreateDirectoryExA( - LPCSTR lpTemplateDirectory, - LPCSTR lpNewDirectory, - LPSECURITY_ATTRIBUTES lpSecurityAttributes - ) +WINBOOL STDCALL CreateDirectoryExA(LPCSTR lpTemplateDirectory, + LPCSTR lpNewDirectory, + LPSECURITY_ATTRIBUTES lpSecurityAttributes) { WCHAR TemplateDirectoryW[MAX_PATH]; WCHAR NewDirectoryW[MAX_PATH]; @@ -350,16 +345,45 @@ SearchPathA( return RetValue; } -DWORD -STDCALL -SearchPathW( - LPCWSTR lpPath, - LPCWSTR lpFileName, - LPCWSTR lpExtension, - DWORD nBufferLength, - LPWSTR lpBuffer, - LPWSTR *lpFilePart - ) +DWORD STDCALL SearchPathW(LPCWSTR lpPath, + LPCWSTR lpFileName, + LPCWSTR lpExtension, + DWORD nBufferLength, + LPWSTR lpBuffer, + 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. + */ { diff --git a/reactos/lib/kernel32/misc/console.c b/reactos/lib/kernel32/misc/console.c index 019f765cd22..04f33001e2c 100644 --- a/reactos/lib/kernel32/misc/console.c +++ b/reactos/lib/kernel32/misc/console.c @@ -64,7 +64,7 @@ WINBOOL STDCALL AllocConsole( VOID ) { - StdInput = CreateFile("\\Device\\Keyboard", + StdInput = CreateFile("\\Keyboard", FILE_GENERIC_READ, 0, NULL, @@ -72,7 +72,7 @@ AllocConsole( VOID ) 0, NULL); - StdOutput = CreateFile("\\Device\\BlueScreen", + StdOutput = CreateFile("\\BlueScreen", FILE_GENERIC_WRITE|FILE_GENERIC_READ, 0, NULL, diff --git a/reactos/notes b/reactos/notes deleted file mode 100644 index 25900e924cd..00000000000 --- a/reactos/notes +++ /dev/null @@ -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 -Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode -References: 1, 2 , 3 , 4 - -In article , David C. 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 -To: Jason Filby -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 -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" -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 - 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 -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 ------ - diff --git a/reactos/ntoskrnl/io/create.c b/reactos/ntoskrnl/io/create.c index cb2fb56828d..7b840010ce0 100644 --- a/reactos/ntoskrnl/io/create.c +++ b/reactos/ntoskrnl/io/create.c @@ -17,7 +17,7 @@ #include #include -#define NDEBUG +//#define NDEBUG #include /* FUNCTIONS *************************************************************/ diff --git a/reactos/ntoskrnl/io/rw.c b/reactos/ntoskrnl/io/rw.c index 4b76b12fd65..efd5cba540f 100644 --- a/reactos/ntoskrnl/io/rw.c +++ b/reactos/ntoskrnl/io/rw.c @@ -73,7 +73,7 @@ NTSTATUS ZwReadFile(HANDLE FileHandle, if (Status != STATUS_SUCCESS) { DPRINT("ZwReadFile() ="); - DbgPrintErrorMessage(Status); +// DbgPrintErrorMessage(Status); return(Status); } assert(FileObject != NULL); diff --git a/reactos/ntoskrnl/ke/error.c b/reactos/ntoskrnl/ke/error.c index be48b410dfc..c034a0c76e4 100644 --- a/reactos/ntoskrnl/ke/error.c +++ b/reactos/ntoskrnl/ke/error.c @@ -10,42 +10,10 @@ /* INCLUDE *****************************************************************/ -#include #include -/* GLOBALS *****************************************************************/ - -/* - * Last error code (this should be per process) - */ -DWORD error_code = 0; - /* 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) { } diff --git a/reactos/ntoskrnl/nt/atom.c b/reactos/ntoskrnl/nt/atom.c index cf6da70493a..f8c7b2445af 100644 --- a/reactos/ntoskrnl/nt/atom.c +++ b/reactos/ntoskrnl/nt/atom.c @@ -1,9 +1,9 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected - * PROGRAMMER: David Welch (welch@mcmail.com) + * FILE: ntoskrnl/nt/atom.c + * PURPOSE: Atom managment + * PROGRAMMER: Nobody * UPDATE HISTORY: * Created 22/05/98 */ @@ -19,60 +19,41 @@ NTSTATUS STDCALL NtAddAtom(OUT ATOM *Atom, IN PUNICODE_STRING AtomString) { + return(ZwAddAtom(Atom, AtomString)); } -NTSTATUS -STDCALL -ZwAddAtom( - OUT ATOM *Atom, - IN PUNICODE_STRING AtomString - ) +NTSTATUS STDCALL ZwAddAtom(OUT ATOM *Atom, + IN PUNICODE_STRING AtomString) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtDeleteAtom( - IN ATOM Atom - ) +NTSTATUS STDCALL NtDeleteAtom(IN ATOM Atom) { + return(ZwDeleteAtom(Atom)); } -NTSTATUS -STDCALL -ZwDeleteAtom( - IN ATOM Atom - ) +NTSTATUS STDCALL ZwDeleteAtom(IN ATOM Atom) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtFindAtom( - OUT ATOM *Atom, - IN PUNICODE_STRING AtomString - ) +NTSTATUS STDCALL NtFindAtom(OUT ATOM *Atom, IN PUNICODE_STRING AtomString) { + return(ZwFindAtom(Atom, AtomString)); } -NTSTATUS -STDCALL -ZwFindAtom( - OUT ATOM *Atom, - IN PUNICODE_STRING AtomString - ) +NTSTATUS STDCALL ZwFindAtom(OUT ATOM *Atom, IN PUNICODE_STRING AtomString) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtQueryInformationAtom( - IN HANDLE AtomHandle, - IN CINT AtomInformationClass, - OUT PVOID AtomInformation, - IN ULONG AtomInformationLength, - OUT PULONG ReturnLength - ) +NTSTATUS STDCALL NtQueryInformationAtom(IN HANDLE AtomHandle, + IN CINT AtomInformationClass, + OUT PVOID AtomInformation, + IN ULONG AtomInformationLength, + OUT PULONG ReturnLength) { + UNIMPLEMENTED; } diff --git a/reactos/ntoskrnl/nt/channel.c b/reactos/ntoskrnl/nt/channel.c index 8edf8c75cf4..06d47d21532 100644 --- a/reactos/ntoskrnl/nt/channel.c +++ b/reactos/ntoskrnl/nt/channel.c @@ -8,6 +8,14 @@ * 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 *****************************************************************/ #include diff --git a/reactos/ntoskrnl/nt/evtpair.c b/reactos/ntoskrnl/nt/evtpair.c index 4e434cff19d..baea559c4f0 100644 --- a/reactos/ntoskrnl/nt/evtpair.c +++ b/reactos/ntoskrnl/nt/evtpair.c @@ -1,8 +1,8 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected + * FILE: ntoskrnl/nt/evtpair.c + * PURPOSE: Support for event pairs * PROGRAMMER: David Welch (welch@mcmail.com) * UPDATE HISTORY: * Created 22/05/98 @@ -16,141 +16,96 @@ /* FUNCTIONS *****************************************************************/ -NTSTATUS -STDCALL -NtCreateEventPair( - OUT PHANDLE EventPairHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL NtCreateEventPair(OUT PHANDLE EventPairHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + return(ZwCreateEventPair(EventPairHandle, + DesiredAccess, + ObjectAttributes)); } -NTSTATUS -STDCALL -ZwCreateEventPair( - OUT PHANDLE EventPairHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL ZwCreateEventPair(OUT PHANDLE EventPairHandle, + IN ACCESS_MASK DesiredAccess, + 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 -STDCALL -NtSetHighEventPair( - IN HANDLE EventPairHandle - ) +NTSTATUS STDCALL NtSetLowEventPair(HANDLE EventPairHandle) { + return(ZwSetLowEventPair(EventPairHandle)); } -NTSTATUS -STDCALL -ZwSetHighEventPair( - IN HANDLE EventPairHandle - ) -{ -} - -NTSTATUS -STDCALL -NtSetHighWaitLowEventPair( - IN HANDLE EventPairHandle - ) -{ -} - -NTSTATUS -STDCALL -ZwSetHighWaitLowEventPair( - IN HANDLE EventPairHandle - ) +NTSTATUS STDCALL ZwSetLowEventPair(HANDLE EventPairHandle) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtSetLowEventPair( - HANDLE EventPairHandle - ) +NTSTATUS STDCALL NtSetLowWaitHighEventPair(HANDLE EventPairHandle) { + return(ZwSetLowWaitHighEventPair(EventPairHandle)); } -NTSTATUS -STDCALL -ZwSetLowEventPair( - HANDLE EventPairHandle - ) +NTSTATUS STDCALL ZwSetLowWaitHighEventPair(HANDLE EventPairHandle) { + UNIMPLEMENTED; } - -NTSTATUS -STDCALL -NtSetLowWaitHighEventPair( - HANDLE EventPairHandle - ) +NTSTATUS STDCALL NtWaitLowEventPair(IN HANDLE EventPairHandle) { + return(ZwWaitLowEventPair(EventPairHandle)); } -NTSTATUS -STDCALL -ZwSetLowWaitHighEventPair( - HANDLE EventPairHandle - ) +NTSTATUS STDCALL ZwWaitLowEventPair(IN HANDLE EventPairHandle) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtWaitLowEventPair( - IN HANDLE EventPairHandle - ) +NTSTATUS STDCALL NtOpenEventPair(OUT PHANDLE EventPairHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + return(ZwOpenEventPair(EventPairHandle, + DesiredAccess, + ObjectAttributes)); } -NTSTATUS -STDCALL -ZwWaitLowEventPair( - IN HANDLE EventPairHandle - ) +NTSTATUS STDCALL ZwOpenEventPair(OUT PHANDLE EventPairHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtOpenEventPair( - OUT PHANDLE EventPairHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL NtWaitHighEventPair(IN HANDLE EventPairHandle) { + return(ZwWaitHighEventPair(EventPairHandle)); } -NTSTATUS -STDCALL -ZwOpenEventPair( - OUT PHANDLE EventPairHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL ZwWaitHighEventPair(IN HANDLE EventPairHandle) { + UNIMPLEMENTED; } - -NTSTATUS -STDCALL -NtWaitHighEventPair( - IN HANDLE EventPairHandle - ) -{ -} - -NTSTATUS -STDCALL -ZwWaitHighEventPair( - IN HANDLE EventPairHandle - ) -{ -} \ No newline at end of file diff --git a/reactos/ntoskrnl/nt/mutant.c b/reactos/ntoskrnl/nt/mutant.c index 0b5accf403b..11da167c2fc 100644 --- a/reactos/ntoskrnl/nt/mutant.c +++ b/reactos/ntoskrnl/nt/mutant.c @@ -1,9 +1,9 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected - * PROGRAMMER: David Welch (welch@mcmail.com) + * FILE: ntoskrnl/nt/mutant.c + * PURPOSE: Synchronization primitives + * PROGRAMMER: David Welch (welch@cwcom.net) * UPDATE HISTORY: * Created 22/05/98 */ @@ -16,88 +16,73 @@ /* FUNCTIONS *****************************************************************/ -NTSTATUS -STDCALL -NtCreateMutant( - OUT PHANDLE MutantHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes, - IN BOOLEAN InitialOwner - ) +NTSTATUS STDCALL NtCreateMutant(OUT PHANDLE MutantHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes, + IN BOOLEAN InitialOwner) { + return(ZwCreateMutant(MutantHandle, + DesiredAccess, + ObjectAttributes, + InitialOwner)); } -NTSTATUS -STDCALL -ZwCreateMutant( - OUT PHANDLE MutantHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes, - IN BOOLEAN InitialOwner - ) +NTSTATUS STDCALL ZwCreateMutant(OUT PHANDLE MutantHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes, + IN BOOLEAN InitialOwner) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtOpenMutant( - OUT PHANDLE MutantHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL NtOpenMutant(OUT PHANDLE MutantHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + return(ZwOpenMutant(MutantHandle, + DesiredAccess, + ObjectAttributes)); } -NTSTATUS -STDCALL -ZwOpenMutant( - OUT PHANDLE MutantHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL ZwOpenMutant(OUT PHANDLE MutantHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtQueryMutant( - IN HANDLE MutantHandle, - IN CINT MutantInformationClass, - OUT PVOID MutantInformation, - IN ULONG Length, - OUT PULONG ResultLength - ) +NTSTATUS STDCALL NtQueryMutant(IN HANDLE MutantHandle, + IN CINT MutantInformationClass, + OUT PVOID MutantInformation, + IN ULONG Length, + OUT PULONG ResultLength) { + return(ZwQueryMutant(MutantHandle, + MutantInformationClass, + MutantInformation, + Length, + ResultLength)); } -NTSTATUS -STDCALL -ZwQueryMutant( - IN HANDLE MutantHandle, - IN CINT MutantInformationClass, - OUT PVOID MutantInformation, - IN ULONG Length, - OUT PULONG ResultLength - ) +NTSTATUS STDCALL ZwQueryMutant(IN HANDLE MutantHandle, + IN CINT MutantInformationClass, + OUT PVOID MutantInformation, + IN ULONG Length, + OUT PULONG ResultLength) { + UNIMPLEMENTED; } - -NTSTATUS -STDCALL -NtReleaseMutant( - IN HANDLE MutantHandle, - IN PULONG ReleaseCount OPTIONAL - ) +NTSTATUS STDCALL NtReleaseMutant(IN HANDLE MutantHandle, + IN PULONG ReleaseCount OPTIONAL) { + return(ZwReleaseMutant(MutantHandle, + ReleaseCount)); } -NTSTATUS -STDCALL -ZwReleaseMutant( - IN HANDLE MutantHandle, - IN PULONG ReleaseCount OPTIONAL - ) +NTSTATUS STDCALL ZwReleaseMutant(IN HANDLE MutantHandle, + IN PULONG ReleaseCount OPTIONAL) { + UNIMPLEMENTED; } diff --git a/reactos/ntoskrnl/nt/ntsem.c b/reactos/ntoskrnl/nt/ntsem.c index b2742629383..0f655145653 100644 --- a/reactos/ntoskrnl/nt/ntsem.c +++ b/reactos/ntoskrnl/nt/ntsem.c @@ -1,8 +1,8 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected + * FILE: ntoskrnl/nt/ntsem.c + * PURPOSE: Synchronization primitives * PROGRAMMER: David Welch (welch@mcmail.com) * UPDATE HISTORY: * Created 22/05/98 @@ -16,91 +16,79 @@ /* FUNCTIONS *****************************************************************/ -NTSTATUS -STDCALL -NtCreateSemaphore( - OUT PHANDLE SemaphoreHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, - IN ULONG InitialCount, - IN ULONG MaximumCount - ) +NTSTATUS STDCALL NtCreateSemaphore(OUT PHANDLE SemaphoreHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, + IN ULONG InitialCount, + IN ULONG MaximumCount) { + return(ZwCreateSemaphore(SemaphoreHandle, + DesiredAccess, + ObjectAttributes, + InitialCount, + MaximumCount)); } -NTSTATUS -STDCALL -ZwCreateSemaphore( - OUT PHANDLE SemaphoreHandle, - IN ACCESS_MASK DesiredAccess, - IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, - IN ULONG InitialCount, - IN ULONG MaximumCount - ) +NTSTATUS STDCALL ZwCreateSemaphore(OUT PHANDLE SemaphoreHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, + IN ULONG InitialCount, + IN ULONG MaximumCount) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtOpenSemaphore( - IN HANDLE SemaphoreHandle, - IN ACCESS_MASK DesiredAcces, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL NtOpenSemaphore(IN HANDLE SemaphoreHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + return(ZwOpenSemaphore(SemaphoreHandle, + DesiredAccess, + ObjectAttributes)); } -NTSTATUS -STDCALL -ZwOpenSemaphore( - IN HANDLE SemaphoreHandle, - IN ACCESS_MASK DesiredAcces, - IN POBJECT_ATTRIBUTES ObjectAttributes - ) +NTSTATUS STDCALL ZwOpenSemaphore(IN HANDLE SemaphoreHandle, + IN ACCESS_MASK DesiredAccess, + IN POBJECT_ATTRIBUTES ObjectAttributes) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtQuerySemaphore( - HANDLE SemaphoreHandle, - CINT SemaphoreInformationClass, - OUT PVOID SemaphoreInformation, - ULONG Length, - PULONG ReturnLength - ) +NTSTATUS STDCALL NtQuerySemaphore(HANDLE SemaphoreHandle, + CINT SemaphoreInformationClass, + OUT PVOID SemaphoreInformation, + ULONG Length, + PULONG ReturnLength) { + return(ZwQuerySemaphore(SemaphoreHandle, + SemaphoreInformationClass, + SemaphoreInformation, + Length, + ReturnLength)); } -NTSTATUS -STDCALL -ZwQuerySemaphore( - HANDLE SemaphoreHandle, - CINT SemaphoreInformationClass, - OUT PVOID SemaphoreInformation, - ULONG Length, - PULONG ReturnLength - ) +NTSTATUS STDCALL ZwQuerySemaphore(HANDLE SemaphoreHandle, + CINT SemaphoreInformationClass, + OUT PVOID SemaphoreInformation, + ULONG Length, + PULONG ReturnLength) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtReleaseSemaphore( - IN HANDLE SemaphoreHandle, - IN ULONG ReleaseCount, - IN PULONG PreviousCount - ) +NTSTATUS STDCALL NtReleaseSemaphore(IN HANDLE SemaphoreHandle, + IN ULONG ReleaseCount, + IN PULONG PreviousCount) { + return(ZwReleaseSemaphore(SemaphoreHandle, + ReleaseCount, + PreviousCount)); } -NTSTATUS -STDCALL -ZwReleaseSemaphore( - IN HANDLE SemaphoreHandle, - IN ULONG ReleaseCount, - IN PULONG PreviousCount - ) +NTSTATUS STDCALL ZwReleaseSemaphore(IN HANDLE SemaphoreHandle, + IN ULONG ReleaseCount, + IN PULONG PreviousCount) { + UNIMPLEMENTED; } diff --git a/reactos/ntoskrnl/nt/nttimer.c b/reactos/ntoskrnl/nt/nttimer.c index f535a89aadb..fdda2547560 100644 --- a/reactos/ntoskrnl/nt/nttimer.c +++ b/reactos/ntoskrnl/nt/nttimer.c @@ -1,8 +1,8 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected + * FILE: ntoskrnl/nt/nttimer.c + * PURPOSE: User-mode timers * PROGRAMMER: David Welch (welch@mcmail.com) * UPDATE HISTORY: * Created 22/05/98 diff --git a/reactos/ntoskrnl/nt/plugplay.c b/reactos/ntoskrnl/nt/plugplay.c index 1b2c2798a35..aae5a53ed2d 100644 --- a/reactos/ntoskrnl/nt/plugplay.c +++ b/reactos/ntoskrnl/nt/plugplay.c @@ -1,8 +1,8 @@ /* * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel - * FILE: ntoskrnl/ke/bug.c - * PURPOSE: Graceful system shutdown if a bug is detected + * FILE: ntoskrnl/nt/plugplay.c + * PURPOSE: Mysterious nt4 support for plug-and-play * PROGRAMMER: David Welch (welch@mcmail.com) * UPDATE HISTORY: * Created 22/05/98 @@ -18,8 +18,10 @@ NTSTATUS STDCALL NtGetPlugPlayEvent(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtPlugPlayControl(VOID) { + UNIMPLEMENTED; } diff --git a/reactos/ntoskrnl/nt/port.c b/reactos/ntoskrnl/nt/port.c index 89ff7effd78..16d35a19205 100644 --- a/reactos/ntoskrnl/nt/port.c +++ b/reactos/ntoskrnl/nt/port.c @@ -2,7 +2,7 @@ * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel * 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) * UPDATE HISTORY: * Created 22/05/98 @@ -18,44 +18,55 @@ NTSTATUS STDCALL NtAcceptConnectPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtCompleteConnectPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtConnectPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtCreatePort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtListenPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtReplyPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtReplyWaitReceivePort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtReplyWaitReplyPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtRequestPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtRequestWaitReplyPort(VOID) { + UNIMPLEMENTED; } NTSTATUS STDCALL NtQueryInformationPort(VOID) { + UNIMPLEMENTED; } diff --git a/reactos/ntoskrnl/nt/profile.c b/reactos/ntoskrnl/nt/profile.c index 6c62e332957..b6c31e035a4 100644 --- a/reactos/ntoskrnl/nt/profile.c +++ b/reactos/ntoskrnl/nt/profile.c @@ -2,8 +2,8 @@ * COPYRIGHT: See COPYING in the top level directory * PROJECT: ReactOS kernel * FILE: ntoskrnl/nt/Profile.c - * PURPOSE: - * PROGRAMMER: + * PURPOSE: Support for profiling + * PROGRAMMER: Nobody * UPDATE HISTORY: * */ @@ -16,52 +16,37 @@ /* FUNCTIONS *****************************************************************/ -NTSTATUS -STDCALL -NtCreateProfile( - OUT PHANDLE ProfileHandle, - IN POBJECT_ATTRIBUTES ObjectAttributes, - IN ULONG ImageBase, - IN ULONG ImageSize, - IN ULONG Granularity, - OUT PVOID Buffer, - IN ULONG ProfilingSize, - IN ULONG ClockSource, - IN ULONG ProcessorMask - ) +NTSTATUS STDCALL NtCreateProfile(OUT PHANDLE ProfileHandle, + IN POBJECT_ATTRIBUTES ObjectAttributes, + IN ULONG ImageBase, + IN ULONG ImageSize, + IN ULONG Granularity, + OUT PVOID Buffer, + IN ULONG ProfilingSize, + IN ULONG ClockSource, + IN ULONG ProcessorMask) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtQueryIntervalProfile( - OUT PULONG Interval, - OUT PULONG ClockSource - ) +NTSTATUS STDCALL NtQueryIntervalProfile(OUT PULONG Interval, + OUT PULONG ClockSource) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtSetIntervalProfile( - IN ULONG Interval, - IN ULONG ClockSource - ) +NTSTATUS STDCALL NtSetIntervalProfile(IN ULONG Interval, + IN ULONG ClockSource) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtStartProfile( - IN HANDLE ProfileHandle - ) +NTSTATUS STDCALL NtStartProfile(IN HANDLE ProfileHandle) { + UNIMPLEMENTED; } -NTSTATUS -STDCALL -NtStopProfile( - IN HANDLE ProfileHandle - ) +NTSTATUS STDCALL NtStopProfile(IN HANDLE ProfileHandle) { + UNIMPLEMENTED; } diff --git a/reactos/readme_rex b/reactos/readme_rex index 9accce17b5d..bbcb3b54870 100644 --- a/reactos/readme_rex +++ b/reactos/readme_rex @@ -1,21 +1,58 @@ -DIRECTORIES +* Introduction -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) +These are the sources for the ReactOS kernel, system libraries and +applications. ReactOS is the beginnings of a free clone of Windows NT +(aiming at version 4 right now). ReactOS isn't usuable for anything but +further development, please don't uninstall your existing OSs just yet. + +* Compilation + +ReactOS currently only compiles using the djgpp compiler for DOS (or a djgpp +cross compiler with some fiddling). This will change in the near future to +using the mingw32 compiler. It also needs the NASM assembler installed. +To compile + +1) copy libgcc.a from the djgpp distribution to the ntoskrnl directory +2) make + +* Installation + +By default ReactOS tries to execute 'c:\reactos\system\shell.bin' on +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)