Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2025-08-03 20:45:44 +00:00
Code Issues Projects Releases Packages Wiki Activity

* Create a branch for USB experiments.

Browse source 
svn path=/branches/usb-experiments/; revision=72629
This commit is contained in:
Amine Khaldi 2016-09-09 15:11:19 +00:00
parent 28d8ba0d3e
commit 0ee830d7a4
23049 changed files with 0 additions and 1313991 deletions
Download patch file Download diff file Expand all files Collapse all files

14
media/CMakeLists.txt Normal file
View file

@ -0,0 +1,14 @@
add_subdirectory(fonts)
add_subdirectory(inf)
add_subdirectory(nls)
add_subdirectory(sdb)
add_subdirectory(themes)
add_subdirectory(vgafonts)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/etc/hosts DESTINATION reactos/system32/drivers/etc FOR all)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/etc/KDBinit DESTINATION reactos/system32/drivers/etc FOR all)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/etc/networks DESTINATION reactos/system32/drivers/etc FOR all)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/etc/protocol DESTINATION reactos/system32/drivers/etc FOR all)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/drivers/etc/services DESTINATION reactos/system32/drivers/etc FOR all)
add_cd_file(FILE ${CMAKE_CURRENT_SOURCE_DIR}/sounds/ReactOS_LogOn.wav DESTINATION reactos/media FOR all)

91
media/doc/3rd Party Files.txt Normal file
View file

@ -0,0 +1,91 @@
Files synced with Wine can be found in /media/doc/README.WINE
Other things synced with other projects:
Title: Liberation Fonts
Used Version: 2.00.1
Website: https://fedorahosted.org/liberation-fonts/
Title: DejaVu Fonts
Used Version: 2.37
Website: http://dejavu.sourceforge.net
Title: Ubuntu Fonts
Used Version: 0.83
Website: http://font.ubuntu.com
Title: Open Sans Fonts
Used Version: 1.10
Website: http://www.google.com/fonts/specimen/Open+Sans
Title: DXTN OpenGL Compression Libs
Used Version: 1.1
Website: http://www.geocities.com/dborca/opengl/tc.html
Title: FreeType
Used Version: 2.6.4
Website: http://www.freetype.org
Title: Mesa3D
Used Version: 8.0.4
Website: http://www.mesa3d.org
Title: Mesa3D glu libary
Used Version: 9.0
Website: ftp://ftp.freedesktop.org/pub/mesa/glu/
Title: GNU adns
Used Version: 1.0 REV 5
Website: http://www.gnu.org/software/adns/ | http://adns.jgaa.com
Title: BZip2
Used Version: 1.0.6
Website: http://www.bzip.org
Title: LibXML
Used Version: 2.9.4
Website: http://xmlsoft.org | ftp://xmlsoft.org/libxml2/
Title: Libxslt
Used Version: 1.1.29
Website: http://xmlsoft.org
Title: ZLib
Used Version: 1.2.8
Website: http://www.zlib.net
Title: GNU FreeFont
Used Version: 2012-05-03
Website: http://savannah.gnu.org/projects/freefont/
Title: CardLib
Used Version: 2005-07-14
Website: http://www.catch22.net/tuts/cardlib
Title: libsamplerate
Used Version: 0.1.8
Website: http://www.mega-nerd.com/SRC/download.html
Title: libmpg123 (used by winemp3.acm)
Used Version: 1.22.4
Website: http://www.mpg123.de/
Title: STLport
Used Version: 5.2.1
Website: http://stlport.sourceforge.net/
Title: win-iconv
Used Version: git commit 8765259
Website: https://github.com/win-iconv/win-iconv
Title: libjpeg
Used Version: 9a
Website: http://www.ijg.org/
Title: mbed TLS
Used Version: 2.3.0
Website: https://tls.mbed.org/
Title: libpng
Used Version: 1.6.21
Website: http://libpng.sourceforge.net/

32
media/doc/DdCreateDirectDrawObject.txt Normal file
View file

@ -0,0 +1,32 @@
DdCreateDirectDrawObject
When IN HDC is not NULL
1. we need check the IN HDC is NULL or not
2. if it not null we need create a directdraw handler
and store it to pDirectDrawGlobal->hDD
3. if the directdraw handle is null return false
we did fail to create directdraw HAL
4. if the directdraw handle was not null we return true
we did susses to create directdraw HAL
When IN HDC is NULL
Now we come to if IN HDC is null basic we need create
a hdc and cashe some data
1. if internal cache of directdraw handle is not null (pDirectDrawGlobalInternal->hDD)
we take it and fill to the public directdraw handler (pDirectDrawGlobal->hDD)
and return susses.
2. if no internal cache of directdraw handle is found we need create it
by using CreateDC for tempary HDC that will be cache in the win32k later
3. we need check see if we got a tempary HDC or not, if we fail getting tempary
HDC return FALSE
4. Now we trying create directdraw handler it being cache to (pDirectDrawGlobalInternal->hDD)
and it also set same handler to the public (pDirectDrawGlobal->hDD)
5. if it fails to create directdraw handle return false
we did fail to create directdraw HAL
6. if it susses create directdraw handle return true
we did susses to create directdraw HAL
To create a directdraw handler you need call the NtGdiDdCreateDirectDrawObject with a hdc

16
media/doc/DdDeleteDirectDrawObject.txt Normal file
View file

@ -0,0 +1,16 @@
DdDeleteDirectDrawObject
we need release directdraw handler the cache or not cache handler
1. check see if DirectDrawGlobal->hDD is NULL or not
2. if both cache directdraw handler and public handler is NULL
then we need return false, fail to release it or it was already release
3. if public directdraw handler is not null we need release it
and return if we susses or not.
4. we need check if we need rest the internal cache if public being release
use NtGdiDdDeleteDirectDrawObject((HANDLE)DirectDrawGlobal->hDD);
to release a directdraw handler.

7
media/doc/For_Turkish_Translation.txt Normal file
View file

@ -0,0 +1,7 @@
The ReactOS is translating to pure Turkish with new terminology. For new terminology, see: http://eersoy93.blogspot.com.tr/p/sozluk.html (in Turkish)
For more information on translating to Turkish, see this forum topic and this JIRA issue:
http://www.reactos.org/forum/viewtopic.php?f=45&t=13528 (in Turkish)
https://jira.reactos.org/browse/CORE-9609
Erdem ERSOY (eersoy93) (erdemersoy@live.com)

125
media/doc/HACKING Normal file
View file

@ -0,0 +1,125 @@
* Introduction
Having successfully built ReactOS and been amazed by what it does, you're
now desperate to fill in some of the omissions, this document shows you how.
* Prerequisites
A working knowledge of NT driver development is useful for understanding the
kernel and some of its abstractions. The NT4 ddk is available for free
download from http://www.microsoft.com/hwdev/. The Windows 98 and Windows
2000 DDKs are also available but the NT4 one is the most useful. See
Legal Stuff below however.
There are a number of books on NT driver development, I would recommend
'Windows NT Device Driver Development' (http://www.osr.com/book/) since OSR
seem to know their stuff. There is only one book on NT filesystem
development 'Windows NT File System Internals'. Please don't buy any of
these books unless you need to, and can afford it.
These mailing lists and newsgroups are useful for NT internals related
questions,
ntfsd@atria.com, ntdev@atria.com
(subscribe by email to majordomo@atria.com)
comp.os.????
microsoft.public.????
* Style
There is a coding style used for ReactOS, it's described in a ReactOS's Wiki
page called Coding Style: http://www.reactos.org/wiki/index.php/Coding_Style
However, not all codebase complies with the rules outlined in that page, so
if you need to hack some code which has not been yet formatted, it's wise
to keep the kind of formatting it already has, to make it looking good until
it receives a formatting patch.
* Debugging
Debugging kernel-mode code is tricky, these are some snippets
DbgPrint writes a message to the console using a printf style format
string. The DPRINT macro (defined in internal/debug.h) expands to
DbgPrint unless NDEBUG is defined, this is useful for having copious
output from a module only when a problem is being debugging. DPRINT
also prefixes the message with the file and line number to make it
easier to see where output is coming from. DbgPrint can be used at any
point including in interrupt handlers.
There are options in ntoskrnl/kd/kdebug.c for copying DbgPrint output
to a serial device or bochs logging port (parallel support should also
be added). This can be useful if a lot of output is being generated.
It should be possible to include support for debugging the kernel with
gdb over a serial line. Bochs (a shareware CPU emulator) is also useful
for debugging the kernel, I wrote some patches to allow capture of console
output from within bochs to file and for debugging a kernel running
under bochs with gdb. Contact me (welch@cwcom.net) if you're are
interested.
If CPU reports an exception not handled by the kernel (any page fault
not part of virtual memory support or any other exception) the kernel
will display output like this and halt
General Protection Fault Exception: 13(0)
CS:EIP xxxxxxxx:xxxxxxx
DS xxxx ES xxxx FS xxxx GS xxxxx
EAX: xxxx EBX: xxxx
....
EDI: xxxx EFLAGS: xxxx ESP: xxxx
cr2: xxxx
Stack: xxxx xxxx xxxx ...
....
Frames: xxxx xxxx xxxx ...
....
The fault type will usually be either 'General Protection' or
'Page Fault', see your Intel manual for the more exotic types. The
'EIP' number is the address of the faulting instruction. If the 'CS'
number is 0x20 then the exception occured in kernel mode, if it is 0x11
then the exception occurred in user mode. 'cr2' is the address that the
faulting instruction was trying to access, if the exception was a page
fault. The number printed after 'Frames' are any addresses on the stack
that look like function addresses.
If the kernel detects a serious problem that it will bug check, displaying
output like this
Bug detected (code x, param x x x x)
Frames: xxx xxxx xxxx
....
Again the numbers printed after 'Frames' are any addresses on the stack
that look like function addresss. Usually the kernel will also print a
message describing the problem in more detail, the bug check code isn't
very useful at the moment.
* Contacts
There is a mailing list for kernel development,
ros-dev@reactos.org
The main developers use a svn account to coordinate changes, ask
Aleksey (aleksey@reactos.org) for an account if you are going to be
adding a lot of code. Smaller patches can go to the mailing list or to the
relevant developer (usually the comment at the top of a module will have
an email address). Regular snapshots are made available for download,
see the mailing list for announcements.
* Legal stuff
The ReactOS project is GPL'ed, please make sure any code submitted is
compatible with this.
The NT4 ddk license agreement allows its usage for developing nt drivers
only. Legally therefore it can not be used to develop ReactOS, neither the
documentation or the sample code. I'm not a lawyer, but I doubt the
effiacy of 'shrinkwrap licenses' particularly on freely downloadable
software. The only precendent I know of, in a Scottish court, didn't
upload this type of license.
Also the 'fair use' section of copyright law allows the 'quoting' of small
sections from copyrighted documents, e.g. Windows API or DDK documentation

6
media/doc/INDEX Normal file
View file

@ -0,0 +1,6 @@
HACKING: Some notes for adding code to ReactOS
DIRS: Explanation of directory layout
INTERNALS: Some notes on kernel internals
TODO: Bugs and omissions, big and little things that need to be done
NOTES: Unsorted material, some of it is redundant
BUGLIST: Known bugs, please update when you find one

43
media/doc/INTERNALS Normal file
View file

@ -0,0 +1,43 @@
A collection of articles on kernel internals, please add to this
------------------------------------------------------------------------------
IRQ level
------------------------------------------------------------------------------
IRQ level (IRQL) is a per-processor state in ReactOS used to coordinate
execution between ISRs and between threads. There are several levels
PASSIVE_LEVEL, APC_LEVEL: The normal level for user mode and most
kernel mode code. At the moment APC_LEVEL is unused.
DISPATCH_LEVEL: At this level all irqs are still allowed but thread
rescheduling on the current processor is disabled. This is used by
the spinlock synchronization primitive to implement its uniprocessor
semantics (multiprocessor is more complex). It is also used for some
other forms of synchronization, DPCs for example. Many APIs are
unavailable at this IRQL, usually those that might have to wait. It
is recommended that you don't spend too much time at this IRQL
otherwise system responsiveness will be reduced.
> DISPATCH_LEVEL: Each irq is assigned a priority (which will be
greater than DISPATCH_LEVEL). At an irq's priority level that irq,
lower priority irqs and thread rescheduling are disabled. Higher
priority irqs can still run. Very few APIs are available at IRQLs
greater than DISPATCH_LEVEL.
HIGH_LEVEL: All irqs are disabled.
-------------------------------------------------------------------------------
DPCs
-------------------------------------------------------------------------------
It is a design goal not to spend too much time in ISRs, for this reason
ISRs should postpone most processing till it can run at a lower IRQL. The
mechanism for this is a Deferred Procedure Call (DPC). When a DPC object is
created, it is associated with a function. The DPC object can then be inserted
in the DPC queue from an ISR. If the IRQL on return from the ISR is less than
DISPATCH_LEVEL the DPC queue will be drained, otherwise this will happen when
the IRQL level drops below DISPATCH_LEVEL or the processor becomes idle. When
the DPC queue is drained each DPC object is removed and the associated
function is called at DISPATCH_LEVEL. A DPC object can only be inserted once,
further insertions before it is removed will have no effect.

53
media/doc/LPC.txt Normal file
View file

@ -0,0 +1,53 @@
==============================================================
= =
= NOTES FROM THE UNDERGROUND =
= =
==============================================================
Below are some of Alex's notes on the mysterious LPC Subsystem
=========================
1. Sizes, sizes, sizes...
=========================
There are four imporant LPC Sizes to keep in mind. Try to understand them:
/*
* This determines the absolute maximum message size (0x100 bytes). For
* larger values, use a section-backed message.
*/
#define PORT_MAXIMUM_MESSAGE_LENGTH 256
/*
* This determines the maximum length of an LPC request. It is the largest
* amount of bytes that an LPC request can take. To calculate this, assume
* that this is a CONNECTION_REQUEST message, which includes the additionnal
* LPCP_CONNECTION_MESSAGE structure as well. Therefore, we add the kernel LPC,
* header, the maximum port size and the size of the connection request
* structure. This gives a value of 0x15C. However, one must note that NT
* allocates the Lookaside List using a 16-byte aligned value, making this
* number 0x160.
*/
#define LPCP_MAX_MESSAGE_SIZE ROUND_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \
sizeof(LPCP_MESSAGE) + \
sizeof(LPCP_CONNECTION_MESSAGE), 16)
/*
* Now, for an actual LPC Request size, we remove the kernel LPC header, which
* yields the size of the actual LPC Data that follows the Header, making this
* number 0x148.
*/
#define LPC_MAX_MESSAGE_LENGTH (LPCP_MAX_MESSAGE_SIZE - \
FIELD_OFFSET(LPCP_MESSAGE, Request))
/*
* Finally, we'll calculate the maximum size of the Connection Info, giving us
* 0x104
*/
#define LPC_MAX_DATA_LENGTH (LPC_MAX_MESSAGE_LENGTH - \
sizeof(PORT_MESSAGE) - \
sizeof(LPCP_CONNECTION_MESSAGE))
==========================
2. Structures
==========================
SOON. TODO.

15
media/doc/README.FSD Normal file
View file

@ -0,0 +1,15 @@
# ReactOS FSD porting/syncing reference file
# Update this file when you port/sync a FSD from an external source.
The following FSD are shared with: https://github.com/maharmstone/btrfs.
reactos/drivers/filesystems/btrfs # Synced to 0.6
The following FSD are shared with: http://www.ext2fsd.com/
reactos/drivers/filesystems/ext2 # Synced to 0.68
The following FSD are shared with: http://www.acc.umu.se/~bosse/
reactos/drivers/filesystems/ffs # Synced to 0.5.2
reactos/drivers/filesystems/reiserfs # Synced to 0.26

353
media/doc/README.WINE Normal file
View file

@ -0,0 +1,353 @@
# ReactOS WINE porting/syncing reference file
# Update this file when you port/sync a dll/program from WINE.
The ReactOS Project shares quite a bit of code with the WINE project.
This document should provide a complete reference for all of the
locations in the ReactOS source tree where code is shared between the
two projects. If you find something is missing from this documentation
please add it.
If you find that a function in ReactOS that is not implemented properly
and is based on WINE sources, check the latest Winehq CVS and see if
it has been fixed there. If so, please submit a patch to
ros-dev@reactos.org. Otherwise please send a patch to both
wine-patches@winehq.com and ros-dev@reactos.org
The following build tools are shared with Wine.
reactos/sdk/tools/unicode # Synced to WineStaging-1.9.16
reactos/sdk/tools/widl # Synced to WineStaging-1.9.16
reactos/sdk/tools/wpp # Synced to WineStaging-1.9.11
The following libraries are shared with Wine.
reactos/dll/directx/wine/amstream # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/d3d8 # Synced to WineStaging-1.9.4
reactos/dll/directx/wine/d3d9 # Synced to WineStaging-1.9.4
reactos/dll/directx/wine/d3dcompiler_43 # Synced to WineStaging-1.9.4
reactos/dll/directx/wine/d3drm # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/d3dx9_24 => 43 # Synced to WineStaging-1.9.4
reactos/dll/directx/wine/d3dxof # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/ddraw # Synced to WineStaging-1.9.4
reactos/dll/directx/wine/devenum # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/dinput # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/dinput8 # Synced to WineStaging-1.9.11
reactos/dll/directx/wine/dmusic # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/dplay # Synced to WineStaging-1.9.11
reactos/dll/directx/wine/dplayx # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/dsound # Synced to Wine-1.3.29
reactos/dll/directx/wine/dxdiagn # Synced to WineStaging-1.9.11
reactos/dll/directx/wine/msdmo # Synced to WineStaging-1.9.11
reactos/dll/directx/wine/qedit # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/quartz # Synced to WineStaging-1.9.16
reactos/dll/directx/wine/wined3d # Synced to WineStaging-1.9.4
reactos/dll/win32/activeds # Synced to WineStaging-1.9.11
reactos/dll/win32/actxprxy # Synced to WineStaging-1.9.11
reactos/dll/win32/advpack # Synced to WineStaging-1.9.11
reactos/dll/win32/atl # Synced to WineStaging-1.9.16
reactos/dll/win32/atl80 # Synced to WineStaging-1.9.11
reactos/dll/win32/atl100 # Synced to WineStaging-1.9.11
reactos/dll/win32/avifil32 # Synced to WineStaging-1.9.16
reactos/dll/win32/bcrypt # Synced to WineStaging-1.9.4
reactos/dll/win32/browseui # Out of sync
reactos/dll/win32/cabinet # Synced to WineStaging-1.9.16
reactos/dll/win32/clusapi # Synced to WineStaging-1.9.11
reactos/dll/win32/comcat # Synced to WineStaging-1.9.11
reactos/dll/win32/comctl32 # Synced to WineStaging-1.9.16
reactos/dll/win32/comdlg32 # Synced to WineStaging-1.9.16
reactos/dll/win32/compstui # Synced to WineStaging-1.9.11
reactos/dll/win32/credui # Synced to WineStaging-1.9.16
reactos/dll/win32/crypt32 # Synced to WineStaging-1.9.16
reactos/dll/win32/cryptdlg # Synced to WineStaging-1.9.11
reactos/dll/win32/cryptdll # Synced to WineStaging-1.9.11
reactos/dll/win32/cryptnet # Synced to WineStaging-1.9.11
reactos/dll/win32/cryptui # Synced to WineStaging-1.9.16
reactos/dll/win32/dbghelp # Synced to WineStaging-1.9.16
reactos/dll/win32/dciman32 # Synced to WineStaging-1.9.11
reactos/dll/win32/faultrep # Synced to WineStaging-1.9.11
reactos/dll/win32/fontsub # Synced to WineStaging-1.9.13
reactos/dll/win32/fusion # Synced to WineStaging-1.9.11
reactos/dll/win32/gdiplus # Synced to WineStaging-1.9.16
reactos/dll/win32/hhctrl.ocx # Synced to WineStaging-1.9.16
reactos/dll/win32/hlink # Synced to WineStaging-1.9.16
reactos/dll/win32/hnetcfg # Synced to WineStaging-1.9.16
reactos/dll/win32/httpapi # Synced to WineStaging-1.9.11
reactos/dll/win32/iccvid # Synced to WineStaging-1.9.11
reactos/dll/win32/ieframe # Synced to WineStaging-1.9.16
reactos/dll/win32/imaadp32.acm # Synced to WineStaging-1.9.11
reactos/dll/win32/imagehlp # Synced to WineStaging-1.9.11
reactos/dll/win32/imm32 # Synced to Wine-1.7.27
reactos/dll/win32/inetcomm # Synced to WineStaging-1.9.16
reactos/dll/win32/inetmib1 # Synced to WineStaging-1.9.11
reactos/dll/win32/initpki # Synced to WineStaging-1.9.11
reactos/dll/win32/inseng # Synced to WineStaging-1.9.11
reactos/dll/win32/iphlpapi # Out of sync
reactos/dll/win32/itircl # Synced to WineStaging-1.9.11
reactos/dll/win32/itss # Synced to WineStaging-1.9.11
reactos/dll/win32/jscript # Synced to WineStaging-1.9.16
reactos/dll/win32/jsproxy # Synced to WineStaging-1.9.11
reactos/dll/win32/loadperf # Synced to WineStaging-1.9.11
reactos/dll/win32/localspl # Synced to WineStaging-1.9.11
reactos/dll/win32/localui # Synced to WineStaging-1.9.11
reactos/dll/win32/lz32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mapi32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mciavi32 # Synced to WineStaging-1.9.16
reactos/dll/win32/mcicda # Synced to WineStaging-1.9.16
reactos/dll/win32/mciqtz32 # Synced to WineStaging-1.9.16
reactos/dll/win32/mciseq # Synced to WineStaging-1.9.11
reactos/dll/win32/mciwave # Synced to WineStaging-1.9.11
reactos/dll/win32/mgmtapi # Synced to WineStaging-1.9.11
reactos/dll/win32/mlang # Synced to WineStaging-1.9.16
reactos/dll/win32/mmdevapi # Synced to WineStaging-1.9.16
reactos/dll/win32/mpr # Synced to WineStaging-1.9.11
reactos/dll/win32/mprapi # Synced to WineStaging-1.9.11
reactos/dll/win32/msacm32 # Synced to WineStaging-1.9.11
reactos/dll/win32/msacm32.drv # Synced to WineStaging-1.9.11
reactos/dll/win32/msadp32.acm # Synced to WineStaging-1.9.11
reactos/dll/win32/mscat32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mscms # Synced to WineStaging-1.9.11
reactos/dll/win32/mscoree # Synced to Wine-1.5.4
reactos/dll/win32/msctf # Synced to WineStaging-1.9.16
reactos/dll/win32/msftedit # Synced to WineStaging-1.9.11
reactos/dll/win32/msg711.acm # Synced to WineStaging-1.9.11
reactos/dll/win32/msgsm32.acm # Synced to WineStaging-1.9.11
reactos/dll/win32/mshtml # Synced to WineStaging-1.7.55
reactos/dll/win32/mshtml.tlb # Synced to WineStaging-1.7.55
reactos/dll/win32/msi # Synced to WineStaging-1.9.16
reactos/dll/win32/msimg32 # Synced to WineStaging-1.9.11
reactos/dll/win32/msimtf # Synced to WineStaging-1.9.16
reactos/dll/win32/msisip # Synced to WineStaging-1.9.11
reactos/dll/win32/msisys.ocx # Synced to WineStaging-1.9.11
reactos/dll/win32/msnet32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mspatcha # Synced to WineStaging-1.9.11
reactos/dll/win32/msrle32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mssign32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mssip32 # Synced to WineStaging-1.9.11
reactos/dll/win32/mstask # Synced to WineStaging-1.9.11
reactos/dll/win32/msvcrt20 # Out of sync
reactos/dll/win32/msvcrt40 # Out of sync
reactos/dll/win32/msvfw32 # Synced to WineStaging-1.9.16
reactos/dll/win32/msvidc32 # Synced to WineStaging-1.9.11
reactos/dll/win32/msxml # Synced to WineStaging-1.9.11
reactos/dll/win32/msxml2 # Synced to WineStaging-1.9.11
reactos/dll/win32/msxml3 # Synced to WineStaging-1.9.16
reactos/dll/win32/msxml4 # Synced to WineStaging-1.9.11
reactos/dll/win32/msxml6 # Synced to WineStaging-1.9.11
reactos/dll/win32/nddeapi # Synced to WineStaging-1.9.11
reactos/dll/win32/netapi32 # Forked at Wine-1.3.34
reactos/dll/win32/npptools # Synced to WineStaging-1.9.11
reactos/dll/win32/ntdsapi # Synced to WineStaging-1.9.11
reactos/dll/win32/ntprint # Synced to WineStaging-1.9.11
reactos/dll/win32/objsel # Synced to WineStaging-1.9.11
reactos/dll/win32/odbc32 # Synced to WineStaging-1.9.11. Depends on port of Linux ODBC.
reactos/dll/win32/odbccp32 # Synced to WineStaging-1.9.11
reactos/dll/win32/ole32 # Synced to WineStaging-1.9.16
reactos/dll/win32/oleacc # Synced to WineStaging-1.9.11
reactos/dll/win32/oleaut32 # Synced to WineStaging-1.9.16
reactos/dll/win32/olecli32 # Synced to WineStaging-1.9.11
reactos/dll/win32/oledlg # Synced to WineStaging-1.9.11
reactos/dll/win32/olepro32 # Synced to WineStaging-1.9.11
reactos/dll/win32/olesvr32 # Synced to WineStaging-1.9.11
reactos/dll/win32/olethk32 # Synced to WineStaging-1.9.11
reactos/dll/win32/pdh # Synced to WineStaging-1.9.11
reactos/dll/win32/pidgen # Synced to WineStaging-1.9.11
reactos/dll/win32/powrprof # Forked at Wine-1.0rc5
reactos/dll/win32/printui # Synced to WineStaging-1.9.11
reactos/dll/win32/propsys # Synced to WineStaging-1.9.16
reactos/dll/win32/pstorec # Synced to WineStaging-1.9.16
reactos/dll/win32/qmgr # Synced to WineStaging-1.9.11
reactos/dll/win32/qmgrprxy # Synced to WineStaging-1.9.11
reactos/dll/win32/query # Synced to WineStaging-1.9.11
reactos/dll/win32/rasapi32 # Synced to WineStaging-1.9.11
reactos/dll/win32/resutils # Synced to WineStaging-1.9.11
reactos/dll/win32/riched20 # Synced to WineStaging-1.9.16
reactos/dll/win32/riched32 # Synced to WineStaging-1.9.11
reactos/dll/win32/rpcrt4 # Synced to WineStaging-1.9.16
reactos/dll/win32/rsabase # Synced to WineStaging-1.9.11
reactos/dll/win32/rsaenh # Synced to WineStaging-1.9.11
reactos/dll/win32/sccbase # Synced to WineStaging-1.9.11
reactos/dll/win32/schannel # Synced to WineStaging-1.9.11
reactos/dll/win32/scrrun # Synced to WineStaging-1.9.11
reactos/dll/win32/secur32 # Forked
reactos/dll/win32/security # Forked (different .spec)
reactos/dll/win32/sensapi # Synced to WineStaging-1.9.11
reactos/dll/win32/setupapi # Forked at Wine-20050524
reactos/dll/win32/shdoclc # Synced to WineStaging-1.9.11
reactos/dll/win32/shdocvw # Synced to WineStaging-1.9.11
reactos/dll/win32/shell32 # Forked at Wine-20071011
reactos/dll/win32/shfolder # Synced to WineStaging-1.9.11
reactos/dll/win32/shlwapi # Synced to WineStaging-1.9.16
reactos/dll/win32/slbcsp # Synced to WineStaging-1.9.11
reactos/dll/win32/snmpapi # Synced to WineStaging-1.9.11
reactos/dll/win32/softpub # Synced to WineStaging-1.9.11
reactos/dll/win32/spoolss # Synced to WineStaging-1.9.11
reactos/dll/win32/stdole2.tlb # Synced to WineStaging-1.9.11
reactos/dll/win32/stdole32.tlb # Synced to WineStaging-1.9.11
reactos/dll/win32/sti # Synced to WineStaging-1.9.11
reactos/dll/win32/sxs # Synced to WineStaging-1.9.11
reactos/dll/win32/t2embed # Synced to WineStaging-1.9.11
reactos/dll/win32/tapi32 # Synced to WineStaging-1.9.11
reactos/dll/win32/traffic # Synced to WineStaging-1.9.11
reactos/dll/win32/twain_32 # Synced to WineStaging-1.9.11
reactos/dll/win32/updspapi # Synced to WineStaging-1.9.11
reactos/dll/win32/url # Synced to WineStaging-1.9.11
reactos/dll/win32/urlmon # Synced to WineStaging-1.9.16
reactos/dll/win32/usp10 # Synced to WineStaging-1.9.16
reactos/dll/win32/uxtheme # Forked
reactos/dll/win32/vbscript # Synced to WineStaging-1.9.11
reactos/dll/win32/version # Synced to WineStaging-1.9.11
reactos/dll/win32/vssapi # Synced to WineStaging-1.9.11
reactos/dll/win32/wbemdisp # Synced to WineStaging-1.9.16
reactos/dll/win32/wbemprox # Synced to WineStaging-1.9.11
reactos/dll/win32/windowscodecs # Synced to WineStaging-1.9.16
reactos/dll/win32/windowscodecsext # Synced to WineStaging-1.9.11
reactos/dll/win32/winemp3.acm # Synced to WineStaging-1.9.11
reactos/dll/win32/wing32 # Synced to WineStaging-1.9.11
reactos/dll/win32/winhttp # Synced to WineStaging-1.9.16
reactos/dll/win32/wininet # Synced to WineStaging-1.9.16
reactos/dll/win32/winmm # Forked at Wine-20050628
reactos/dll/win32/winmm/midimap # Forked at Wine-20050628
reactos/dll/win32/winmm/wavemap # Forked at Wine-20050628
reactos/dll/win32/winscard # Synced to WineStaging-1.9.11
reactos/dll/win32/wintrust # Synced to WineStaging-1.9.11
reactos/dll/win32/wldap32 # Synced to WineStaging-1.9.11
reactos/dll/win32/wmi # Synced to WineStaging-1.9.11
reactos/dll/win32/wmiutils # Synced to WineStaging-1.9.11
reactos/dll/win32/wmvcore # Synced to WineStaging-1.9.11
reactos/dll/win32/wshom.ocx # Synced to WineStaging-1.9.11
reactos/dll/win32/wtsapi32 # Synced to WineStaging-1.9.11
reactos/dll/win32/wuapi # Synced to WineStaging-1.9.11
reactos/dll/win32/xinput1_1 # Synced to WineStaging-1.9.11
reactos/dll/win32/xinput1_2 # Synced to WineStaging-1.9.11
reactos/dll/win32/xinput1_3 # Synced to WineStaging-1.9.16
reactos/dll/win32/xinput9_1_0 # Synced to WineStaging-1.9.11
reactos/dll/win32/xmllite # Synced to WineStaging-1.9.16
reactos/dll/cpl/inetcpl # Synced to WineStaging-1.9.11
ReactOS shares the following programs with Winehq.
reactos/base/applications/cmdutils/cscript # Synced to WineStaging-1.9.11
reactos/base/applications/cmdutils/reg # Synced to WineStaging-1.9.16
reactos/base/applications/cmdutils/schtasks # Synced to WineStaging-1.9.14
reactos/base/applications/cmdutils/taskkill # Synced to WineStaging-1.9.11
reactos/base/applications/cmdutils/wmic # Synced to WineStaging-1.9.11
reactos/base/applications/cmdutils/wscript # Synced to WineStaging-1.9.16
reactos/base/applications/cmdutils/xcopy # Synced to WineStaging-1.9.11
reactos/base/applications/games/winmine # Synced to WineStaging-1.9.16 with our own resources.
reactos/base/applications/extrac32 # Synced to WineStaging-1.9.11
reactos/base/applications/iexplore # Synced to WineStaging-1.9.11
reactos/base/applications/notepad # Forked at Wine-20041201
reactos/base/applications/regedit # Out of sync
reactos/base/applications/winhlp32 # Synced to WineStaging-1.9.16
reactos/base/applications/wordpad # Synced to WineStaging-1.9.16
reactos/base/applications/write # Synced to WineStaging-1.9.16
reactos/base/services/rpcss # Synced to WineStaging-1.9.16
reactos/base/system/expand # Synced to WineStaging-1.9.11
reactos/base/system/msiexec # Synced to WineStaging-1.9.11
reactos/modules/rosapps/winfile # Autosync
In addition the following libs, dlls and source files are mostly based on code ported
from Winehq CVS. If you are looking to update something in these files
check Wine current sources first as it may already be fixed.
reactos/sdk/lib/3rdparty/strmbase # Synced to WineStaging-1.9.16
reactos/sdk/lib/rtl/actctx.c # Partly synced with WineStaging-1.9.16
reactos/sdk/lib/rtl/timerqueue.c # Partly synced with WineStaging-1.7.55
reactos/sdk/lib/rtl/wait.c # Partly synced with WineStaging-1.7.55
advapi32 -
reactos/dll/win32/advapi32/wine/cred.c # Synced to WineStaging-1.7.55
reactos/dll/win32/advapi32/wine/crypt.c # Synced to WineStaging-1.7.55
reactos/dll/win32/advapi32/wine/crypt_des.c # Synced to WineStaging-1.7.55
reactos/dll/win32/advapi32/wine/crypt_lmhash.c # Synced to WineStaging-1.7.55
reactos/dll/win32/advapi32/wine/security.c # Out of Sync
gdi32 -
reactos/dll/win32/gdi32/objects/linedda.c # Synced at 20090410
iphlpapi -
reactos/dll/win32/iphlpapi/icmp.c # Partially synced to WineStaging-1.7.55
kernel32 -
reactos/dll/win32/kernel32/wine/actctx.c # Partly synced with Wine 1.7.55
reactos/dll/win32/kernel32/wine/comm.c # Synced in r52754
reactos/dll/win32/kernel32/wine/lzexpand.c # Synced in r52754
reactos/dll/win32/kernel32/wine/profile.c # Partially synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/wine/res.c # Partially synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/winnls/string/casemap.c # Synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/winnls/string/chartype.c # Synced in r52754
reactos/dll/win32/kernel32/winnls/string/collation.c # Synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/winnls/string/format_msg.c # Synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/winnls/string/lang.c # Synced in r52754
reactos/dll/win32/kernel32/winnls/string/lcformat.c # Synced to WineStaging-1.7.55
reactos/dll/win32/kernel32/winnls/string/nls.c # Synced in r52754
reactos/dll/win32/kernel32/winnls/string/sortkey.c # Synced to WineStaging-1.9.16
msvcrt -
reactos/sdk/lib/crt/conio/cputs.c # Synced to WineStaging-1.9.16
reactos/sdk/lib/crt/except/cpp.c # Synced at 20080528
reactos/sdk/lib/crt/except/cppexcept.c # Synced at 20071111
reactos/sdk/lib/crt/process/_cwait.c # Synced to WineStaging-1.7.37
reactos/sdk/lib/crt/signal/xcptinfo.c # Synced to WineStaging-1.7.37
reactos/sdk/lib/crt/string/scanf.c/h # Synced to Wine-1.7.17
reactos/sdk/lib/crt/string/strtoi64.c # Synced to WineStaging-1.9.9
reactos/sdk/lib/crt/string/strtok.c # Synced to WineStaging-1.9.16
reactos/sdk/lib/crt/string/strtok_s.c # Synced to WineStaging-1.9.16
reactos/sdk/lib/crt/string/strtoul.c # Synced to WineStaging-1.9.9
reactos/sdk/lib/crt/string/wcs.c # Synced at 20080611
reactos/sdk/lib/crt/string/wctype.c # Synced at WineStaging-1.9.16
reactos/sdk/lib/crt/wine/heap.c # Synced at 20080529
reactos/sdk/lib/crt/wine/undname.c # Synced to WineStaging-1.9.16
reactos/sdk/lib/crt/process/thread.c # Synced to WineStaging-1.7.55
User32 -
reactos/win32ss/user/user32/controls/button.c # Synced to WineStaging-1.7.37
reactos/win32ss/user/user32/controls/combo.c # Synced to WineStaging-1.7.37
reactos/win32ss/user/user32/controls/edit.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/controls/icontitle.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/controls/listbox.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/controls/scrollbar.c # Forked
reactos/win32ss/user/user32/controls/static.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/include/dde_private.h # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/misc/dde.c # Synced to WineStaging-1.7.55 (dde_misc.c)
reactos/win32ss/user/user32/misc/ddeclient.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/misc/ddeserver.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/misc/exticon.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/misc/resources.c # Partially synced to WineStaging-1.7.55
reactos/win32ss/user/user32/misc/winhelp.c # Last sync date unknown
reactos/win32ss/user/user32/windows/cursoricon # Forked from Wine-1.2-rc7
reactos/win32ss/user/user32/windows/defwnd.c # Forked
reactos/win32ss/user/user32/windows/draw.c # Forked at Wine-20020904 (uitools.c)
reactos/win32ss/user/user32/windows/mdi.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/windows/menu.c # Forked
reactos/win32ss/user/user32/windows/messagebox.c # Forked
reactos/win32ss/user/user32/windows/rect.c # Forked (uitools.c)
reactos/win32ss/user/user32/windows/spy.c # Synced to WineStaging-1.7.55
reactos/win32ss/user/user32/windows/text.c # Forked (lstr.c)
reactos/win32ss/user/user32/windows/winpos.c # Forked
schannel.c
reactos/dll/win32/schannel/schannel_wine.c # synced to wine-1.7.17 (secur32/schannel.c)
reactos/dll/win32/schannel/secur32_wine.c # partial sync to wine-1.7.17 (secur32/secur32.c)
secur32 -
reactos/dll/win32/secur32/sspi.c # Partially synced to WineStaging-1.7.55 (secur32.c)
reactos/dll/win32/secur32/thunks.c # Synced to WineStaging-1.9.4
reactos/dll/win32/secur32/wrapper.c # Synced to WineStaging-1.9.4
setupapi -
reactos/dll/win32/setupapi/dialog.c # Synced to WineStaging-1.9.15
reactos/dll/win32/setupapi/query.c # Partially synced to WineStaging-1.9.4
reactos/dll/win32/setupapi/setupcab.c # Synced to WineStaging-1.9.4
win32k -
win32ss/gdi/ntgdi/bezier.c # Synced to WineStaging-1.9.4 (gdi32/painting.c)
ws2_32 -
reactos/dll/win32/ws2_32/wine/async.c # Synced to WineStaging-1.9.4

55
media/doc/Romanian translation notes.txt Normal file
View file

@ -0,0 +1,55 @@
The following material is addressed (in Romanian) to Romanian translators.
------------------------------------------------------------------------------
* Notă introductivă
Resursele în română din ReactOS au suferit în timp o serie de modificări - de la „plombarea” (inițial rudimentară) cu resurse românești a primelor aplicații care au apărut între resursele (deja traduse) moștenite din Wine până la sistematizarea și consecventizarea traducerilor acestor resurse în întreg volumul de surse al sistemului de operare. Prezenta notă explicitează normele adoptate pentru această sistematizare/consecventizare.
* Convenții adoptate
Normele de traducere curente conțin în mare parte normele de traducere adoptate și în alte traduceri și localizări de logică computațională. Cele mai importante în această privință se regăsesc la i18n.ro și anume în „ghidul traducătorului” [1]:
Astfel:
1. Se folosesc diacriticele corecte ale limbii române.
2. Traducerile trebuiesc adaptate respectând topica limbii române.
3. În relația utilizator - calculator se adoptă o atitudine informal-autoritară (cu verbe la modul imperativ singular).
4. În relația utilizator - calculator, în cazul etapelor intermediare (având texte delimitate de puncte de suspensie), (în cazul verbelor) se folosește modul infinitiv lung.
5. În relația calculator - utilizator se adoptă o atitudine formal-politicoasă (cu verbe la modul indicativ/conjunctiv, persoana a 2-a, plural).
6. În relația calculator - utilizator, la raportarea de informații se folosesc verbe la diateza pasivă sau reflexivă/impersonală.
7. Se evită politețea excesivă prin omiterea expresiilor de politețe explicite.
8. Este recomandată o formulare independentă de gen (gramatical).
9. Se evită utilizarea diacriticelor ca taste active (acceleratori sau taste de acces).
10. Pentru tastele de acces (care răspund la combinația de taste «Alt» + «tastă», evidențiate prin sublinierea tastei respective):
- Se folosesc doar litere sau cifre (recomandare de la Microsoft [2]: „Access keys are alphanumeric keys”). Sunt deci de evitat alte simboluri sau semne de punctuație.
- Sunt de evitat (tot conform aceiași recomandări [2]) literele sau cifrele care fac reperarea lor un exercițiu dificil, cum e grupul „l”, „1”, „i” și „I” (din cauza lățimii lor reduse), sau „g”, „j”, „p”, „q” și „y” (care intersectează marcajul de evidențiere).
11. Ghilimelele folosite în limba română sunt perechea ghilimelele-deschise (99 jos) cu ghilimele-închise (99 sus), și ghilimelele unghiulare.
La acestea se adaugă și câteva norme (deduse) din „greșeli frecvente” raportate tot la i18n.ro [3].
12. Se evită articularea inutilă, însă adaptarea mesajelor traduse trebuie totuși să primeaze.
13. Nu se traduc numele proprii, însă numele traductibile ale componentelor/subcomponentelor unui program sau pachet de programe pot fi traduse.
14. Nu se capitalizează decât prima literă dintr-un text.
* Particularizări locale
În resursele românești din ReactOS există și o serie de particularizări care fie nu se regăsesc în alte traduceri fie din cauza diferențelor de natură ale proiectelor, fie e vorba de termeni încă disputați sau neadoptați în localizările altor proiecte din diverse motive. Multe dintre acestea au fost menționate/discutate în grupul „Diacritice” [4]. Câteva dintre cele mai relevante:
15. În glosar sunt preferate:
- „logică computațională” vs. „software”
- „configurare”/„particularizare” vs. „Setare”
- „modul pilot” (sau doar „pilot”) vs. „driver”
- „păstrează” vs. „salvează”
- „Confirmă”/„Anulează” vs. „OK”/„Renunță”
16. Acceleratorii (combinațiile de taste de gen „«Ctrl» + «tastă»”) rămân aceiași ca în limba engleză.
17. Tastele de acces (combinațiile de taste de gen „«Alt» + «tastă»”) nu rămân neapărat la fel ca în limba engleză. În mulțimea de taste cu această utilizare:
- Se recomandă a evita utilizarea literelor „s” și „t” pe post de taste de acces pentru a preveni confuzia între acestea și diacriticele „ș” și „ț”.
- „f” și „n” sunt rezervate pentru „Confirmă” și respectiv „Anulează”; „a” pentru „Aplică” (dacă există în aceiași fereastră). În cazul ferestrelor de tip asistent, „a”, „o”, „f” și „n” sunt rezervate respectiv pentru „Înainte”, „Înapoi”, „Sfârșit” și „Anulează”. [NOTĂ]
- În cazul interfețelor grafice opțiunilor „Da” și „Nu” le corespund tastele de acces „a” și „u”. (În cazul interfețelor linie-de-comandă, corespunzătoare opțiunilor „Da|Nu”, care NU sunt taste de acces, rămân „d” și „n”.)
18. Din considerente de lizibilitate, în cazul programelor executate în linie-de-comandă se folosesc doar ghilimele unghiulare. Tot ghilimelele unghiulare sunt preferate și pentru citarea tastelor fizice în mesajele elementelor GUI.
19. Enunțul de la convenția 2 se poate extinde la „traducerile trebuiesc adaptate respectând (și beneficiind de) particularitățile limbii române”, iar următoarele zece coonvenții ce urmează după el (3-13) definesc de fapt reguli implicite aplicabile în lipsa unui context bine definit în toate aspectele sale. Unde este posibil, o adaptare la context este dezirabilă:
- În cazul opțiunilor despre care există suficiente informații de context, este recomandată flexionarea. De exemplu, opțiunea nulă pentru lista de animații pentru ecran inactiv se poate flexiona în siguranță specificându-i-se genul gramatical feminin - „(nespecificată)”.
- În cazul unor subiecte unice (dintr-un context local sau global), se folosește forma articulată. Exemple: „Calculatorul meu” (numai unul, conținut concret), „Sistemul de operare” (unic în cadrul său), „Documentele mele” (conținut concret) vs. „Locații în rețea” (nedefinit), „Linie de comandă” (cu multiple posibile instanțe distincte/independente), etc.
[1] http://i18n.ro/Ghidul_traducătorului_de_software
[2] https://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_selecting_access_keys
[3] http://i18n.ro/Greșeli_frecvente
[4] http://groups.google.com/group/diacritice
___________________________
[NOTĂ] Această convenție deviază de la recomandarea Microsoft [2] de a nu aloca taste de acces pentru controalele cărora le corespund efectele implicite ale tastelor «Enter» și «Esc», sau care ar putea interfera cu alte grupuri de formulare-client ce utilizează șabloanele „Confirmă”-„Anulează”-„Aplică” și „Înapoi”-„Înainte”/„Sfârșit”-„Anulează”. Totuși, alocarea de taste de acces nu intră în conflict cu efectul acționării tastelor fizice (dimpotrivă, navigând utilizând tasta «Tab» într-o fereastră de dialog poate schimba efectul implicit al tastei «Enter» pe o altceva decât butonul-control de confirmare a întregii ferestre de dialog). Evitarea suprapunerii cu alte combinații de acces din formularele-client este și ea realizabilă (și recomandată prin urmare în lista de convenții).

36
media/doc/apc Normal file
View file

@ -0,0 +1,36 @@
APC
Asynchronous procedure call
An APC is a Kernel-defined control object representing a procedure
that is called asynchronously. APCs are thread-context dependent; that
is, they are queued to a particular thread for execution.
There are three different kinds of APCs in NT:
User APCs are used by certain asynchronous NT system services to allow
user-mode applications or protected subsystems to synchronize the
execution of a thread with the completion of an operation or the
occurrence of an event such as a timers expiration. User APCs are, by
default, disabled. That is, they are queued to the user-mode thread,
but they are not executed except at well-defined points in the
program. Specifically, they can only be executed when an application
or protected subsystem has called a wait service and has enabled
alerts to occur, or if it has called the test-alert service.
Kernel APCs are normal kernel-mode APCs. They are much like a normal
user APC except that they are executable by default. That is, they are
enabled except when the thread is already executing a Kernel APC.
(Note that a special Kernel APC always preempts these.)
Special Kernel APCs cannot be blocked except by running at a raised
IRQL. They are executed at APC_LEVEL IRQL (see IDT), in kernel mode.
These types of APCs are used by the system to force a thread to
execute a procedure in the threads context. An example of this is I/O
completion: the I/O Manager needs to get back into the context of the
original requestor of the I/O operation so that it can copy buffers,
and so forth. In order to do this, the I/O Manager must be able to
access the virtual address space of the thread/process, and the most
efficient way to complete the operation is to be in the calling
threads context.

18
media/doc/books.txt Normal file
View file

@ -0,0 +1,18 @@
References (Rex's at least)
Baker, Art. The Windows NT Device Driver Book. Prentice Hall, 1997.
Borate, Dabak & Phadke. Undocumented Windows NT. M&T Books, 1999.
Brain, Marshall. Win32 System Services. Prentice Hall, 1996.
Cant, Chris. Writing Windows WDM Device Drivers. R&D Books, 1999.
Canton & Sanchez. IBM Microcomputers: A Programmer's Handbook. McGraw Hill, 1990.
Davis & Wallace. Windows Undocumented File Formats. R&D Books, 1997.
Mason & Viscarola. Windows NT Device Driver Development. Macmillan, 1999.
Mitchell, Stan. Inside the Windows 95 File System. O'Reilly, 1997.
Murray, James D. Windows NT Event Logging. O'Reilly, 1998.
Nagar, Rajeev. Windows NT File System Internals. O'Reilly, 1997.
Osbourne, Sandra. Windows NT Registry: A Settings Reference. New Riders, 1998.
Pietrek, Matt. Windows 95 System Programming Secrets. IDG, 1995.
Richter, Jeffery. Advanced Windows, 3rd ed. Microsoft, 1997.
Simon, Richard J. Windows NT Win32 API Superbible. Waite Group, 1996.
Solomon, David A. Inside Windows NT, 2nd Ed. Microsoft, 1998.
"The NT Insider." Open Systems Resources, 1999-2000.

103
media/doc/irp cancel boilerplate.c Normal file
View file

@ -0,0 +1,103 @@
/*
Boiler plate for irp cancelation, for irp queues you manage yourself
-Gunnar
*/
CancelRoutine(
DEV_OBJ Dev,
Irp
)
{
//don't need this since we have our own sync. protecting irp cancellation
IoReleaseCancelSpinLock(Irp->CancelIrql);
theLock = Irp->Tail.Overlay.DriverContext[3];
Lock(theLock);
RemoveEntryList(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}
QUEUE_BOLIERPLATE
{
Lock(theLock);
Irp->Tail.Overlay.DriverContext[3] = &theLock;
IoSetCancelRoutine(Irp, CancelRoutine);
if (Irp->Cancel && IoSetCancelRoutine(Irp, NULL))
{
/*
Irp has already been cancelled (before we got to queue it),
and we got to remove the cancel routine before the canceler could,
so we cancel/complete the irp ourself.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_CANCELLED;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return FALSE;
}
//else were ok
Irp->IoStatus.Status = STATUS_PENDING;
IoMarkIrpPending(Irp);
InsertTailList(Queue);
Unlock(theLock);
}
DEQUEUE_BOILERPLATE
{
Lock(theLock);
Irp = RemoveHeadList(Queue);
if (!IoSetCancelRoutine(Irp, NULL))
{
/*
Cancel routine WILL be called after we release the spinlock. It will try to remove
the irp from the list and cancel/complete this irp. Since we allready removed it,
make its ListEntry point to itself.
*/
InitializeListHead(&Irp->Tail.Overlay.ListEntry);
Unlock(theLock);
return;
}
/*
Cancel routine will NOT be called, canceled or not.
The Irp might have been canceled (Irp->Cancel flag set) but we don't care,
since we are to complete this Irp now anyways.
*/
Unlock(theLock);
Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}

39
media/doc/locks.txt Normal file
View file

@ -0,0 +1,39 @@
Next-Gen (NT 5.2) Executive Locks in NTOSKRNL.
------------------------------
1a. Rundown Protection
USED IN: Thread/Process Ps* Code.
EXAMPLES: NtSetInformationProcess/Thread, PspCreateThread/Process, PspSuspend/ResumeThread...
REPLACES: Unlocked access and/or PsLock/UnlockProcess.
ROS STATUS: Implemented. Code needs cleanup. Not yet tested. Not yet used.
1b. Cache-Aware Rundown Protection
USED IN: Unknown. Functions exported for drivers.
EXAMPLES: None.
REPLACES: Nothing.
ROS STATUS: Unimplemented.
2. Guarded Mutex
USED IN: Configuration Manager, MCB Functions (FsRtl), Binary Hive Module (Hv), PnP (Notifications), LPC, Jobs (Ps), Device Map (Ob), and Memory Management (Address Space/Virtual Memory).
EXAMPLES: Too many.
REPLACES: Anything that used FAST_MUTEX.
ROS STATUS: Implemented, slightly tested; appears to still contain a bug.
3. Fast Referencing
USED IN: Tokens.
EXAMPLES: R: PsReferencePrimary/EffectiveToken. D: Failure code of anything that calls those two functions.
REPLACES: Normal referencing.
ROS STATUS: Hackplemented stubs.
4a. Pushlocks
USED IN: Configuration Manager (Cm), Handle Table (Ex), Binary Hive Module (Hv), Memory Management (Address Space/Virtual Memory), Object Namespace (Directories/Names) (Ob), Impersonation (Ps).
EXAMPLES: Too many.
REPLACES: Anything that used ERESOURCE.
ROS STATUS: Implemented (missing Block/([Timed]Wait)Unblock) and slightly tested.
4b. Cache-Aware Pushlocks
USED IN: AWE (Mm).
EXAMPLES: None.
REPLACES: Executive Resources.
ROS STATUS: Unimplemented.
TODO: Kernel Locks (Queued and In-Stack Spinlocks)

142
media/doc/news1 Normal file
View file

@ -0,0 +1,142 @@
Correction / addition to Prasad's "Undocumented NT"
From: dan_ps@my-deja.com
Reply to: dan_ps@my-deja.com
Date: Sun, 23 Apr 2000 10:03:30 GMT
Organization: Deja.com - Before you buy.
Newsgroups:
comp.os.ms-windows.programmer.nt.kernel-mode
Followup to: newsgroup
Recently , I had a chanche to borrow "Undocumented NT" by Mr Prasad
Dabak from one of my friends and read it. While reading the chapters
regarding builidng your own interrupt handlers or callgates under NT ,
I found that the book glosses over very important topics such as IDT
in SMP enviroments , and a complete wrong presentation of what structure
a interrupt handler is supposed to build on the stack to ensure shamless
OS functionality. Mr's Prasad choice is a straigtforward pushad ,
folowed by setting the FS segment to the ring0 PCR selector. This way
to build a trap frame for a interrupt is still used in Windows 95 ,
but in Windows NT , the layout of a correct Trap Frame is a little bit
more complex.
The correct layout for a Trap Frame is the folowing: (note that
it consitis from two parts , a stack frame wich is built by the CPU
according to mode in wich was the CPU when the exception or software
interrupt was generated , and a Context Capure frame who has to be built
by the exception handler itself )
struc KeTrapFrame
.DebugEBP resd 1 ; 00
.DebugEIP resd 1 ; 04
.DebugArgMark resd 1 ; 08
.DebugPointer resd 1 ; 0C
.TempCS resd 1 ; 10
.TempEsp resd 1 ; 14
.DR0 resd 1 ; 18
.DR1 resd 1 ; 1C
.DR2 resd 1 ; 20
.DR3 resd 1 ; 24
.DR6 resd 1 ; 28
.DR7 resd 1 ; 2C
.GS resw 1 ; 30
resw 1 ; 32
.ES resw 1 ; 34
resw 1 ; 36
.DS resw 1 ; 38
resw 1 ; 3A
.EDX resd 1 ; 3C
.ECX resd 1 ; 40
.EAX resd 1 ; 44
.PreviousMode resd 1 ; 48
.ExceptionList resd 1 ; 4C
.FS resw 1 ; 50
resw 1 ; 52
.EDI resd 1 ; 54
.ESI resd 1 ; 58
.EBX resd 1 ; 5C
.EBP resd 1 ; 60
.Error resd 1 ; 64
.EIP resd 1 ; 68
.CS resw 1 ; 6C
resw 1 ; 6E
.EFLAGS resd 1 ; 70
.ESP resd 1 ; 74
.SS resw 1 ; 78
resw 1 ; 7A
.ES_V86 resw 1 ; 7C
resw 1 ; 7E
.DS_V86 resw 1 ; 80
resw 1 ; 82
.FS_V86 resw 1 ; 84
resw 1 ; 86
.GS_V86 resw 1 ; 88
endstruc
Note that this is the complete layout of a TrapFrame structure.
Depending in what mode the CPU was when the exception occured , it may
break earlier than .GS_V86. Also , it seems that fields above .DR0 are
required only to debug builds. The declaration is for NASM , a free X86
assembler , but this shouldnt have any kind of importance.
Now why one should build the correct layout for this stack
frame ? The answer is that for shamlees operation of OS , a interrupt
handler HAS to poke into interrupted thread's KTHREAD strucure a
pointer to current TrapFrame existing on stack. This pointer will be
later used by several ntoskrnl API's to gain access to interrupted
thread;s acccess registers , or to gain information about the
interrupted thread's ring3 stack location , or simply to capture all
this information and package it into the form of a CONTEXT structure.
Since ntoskrnl assumes the above layout for a stack frame , using any
other structure size or layout can lead to unforeseen consequences.
Other things wich one may want to do when building a stack
frame are : (assumes that the handler already set the FS register to
kernel PCR selector )
1. Save old Exception List head , and patch -1 to FS:0 ( thus
overriding any potentialy pre-existing SEH handlers.
2. Determine whatever the interrupted thread was runing in
ring0 or in ring3 and save this information in PreviousMode field of
The Trap frame. This is also important , since many internal API's will
check the Provious mode , acting differently in each case. (check CS
image on stack for this )
3. Get a pointer to the top of KeTrapFrame , and patch it into
KTHREAD structure, at KTHREAD->TrapFrame. if ya want the layout of
TrapFrame , there are multiple places where one can get it , but Im
willing to post it here on request.
4. In the case that the hardware stack built by CPU does not
contain an error code , fake one ( generaly , aborts always push an
error code on stack , some exceptions do , and traps never push an
error code by deafult. Suplimentary information can be found in intel
arch. reference manual .
5. Optionaly enable the interrupts trough a STI . NT uses
usualy interrupt gates , so the CPU will clear IF upon entering an
exception handler. Note that in the case handling the interrupt or
exception trough a trap gate , IF will not be automaticly cleared.
If you are interesting in the code wich can actualy build such
a structure on the stack , use a kernel debugger and Break on Int
0x2E , and single step the code .
As last words , I want to ensure Mr Prasad of my respect , and
the thing that the only reason for this posting is my feeling that all
holes must be covered , for the sake of all NT driver writing comunity.
Later , Dan
Sent via Deja.com http://www.deja.com/
Before you buy.

52
media/doc/news2 Normal file
View file

@ -0,0 +1,52 @@
Re: alternative to SeCaptureSubjectContext for Win2000 sought
From: "dave porter" <porter@zultranet.com>
Reply to: "dave porter"
Date: Mon, 26 Jun 2000 10:57:18 -0400
Newsgroups:
comp.os.ms-windows.programmer.nt.kernel-mode
Followup to: newsgroup
References:
<39520e7f$0$15896@wodc7nh1.news.uu.net>
<sl5ulbjfe7f47@corp.supernews.com>
<39575985$0$24336@wodc7nh0.news.uu.net>
> Under advise, I have tried ZwOpenProcessToken(), but to little avail.
> ZwQueryInformationToken( ..TokenUser ...) doesn't seem to want to do its
job
> either under NT4.
I could be jumping in the middle here, but in what way doesn't it work?
This code works for me:
int bufLen = 256; // we suppose this is enough
void* sidBuf = new char[bufLen];
int sidLen = 0;
void* pToken = PsReferencePrimaryToken(PsGetCurrentProcess());
if (!pToken) ... error ...
NTSTATUS ntstatus = ObOpenObjectByPointer(pToken, 0, 0, TOKEN_QUERY,
0, KernelMode, &handle);
if (!NT_SUCCESS(ntstatus)) ... error ...
TOKEN_USER* user = static_cast<TOKEN_USER*>(sidBuf);
ULONG tokenInfoLen;
ntstatus = ZwQueryInformationToken(handle, TokenUser, user, bufLen,
&tokenInfoLen);
if (!NT_SUCCESS(ntstatus)) ... error ...
assert(tokenInfoLen <= bufLen); // else we would have got an error,
right?
assert(user->User.Sid == user+1); // SID is in buffer just past
TOKEN_USER structure
sidLen = tokenInfoLen - sizeof (TOKEN_USER);
memmove(sidBuf, user->User.Sid, sidLen); // shuffle down the buffer
Naturally, this returns the id of the thread that's running it.
If you execute this in DriverEntry, you're running in some
thread in the system process, which is not related to
the thread which executed the Win32 StartService call.

570
media/doc/notes Normal file
View file

@ -0,0 +1,570 @@
*** 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 ***
-----
Subject: [ros-kernel] Inside the Boot Process
Date: Mon, 22 Mar 1999 22:05:47 +0100
From: Emanuele Aliberti <ea@iol.it>
For those working on the boot loader: in WinNt Magazine november 1998
issue (http://www.winntmag.com/) there is a detailed description, by
Mark Russinovich, of the rôle the MBR, NTLDR, boot.ini, ntdetect.com...
play in the boot process ("Inside the Boot Process, Part 1").
-----
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: 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.
-----
The END.

37
media/doc/todo Normal file
View file

@ -0,0 +1,37 @@
* Critical path tasks
Test and debug Registry routines
Implement file cache
Implement paging
* These tasks would be nice
Separate HAL into KM DLL
* Function groups totally or partially unimplemented
Dma functions (see hal/x86/dma.c)
Shutdown support (see ex/power.c)
Zw(Set/Get)SystemInformation (see ex/sysinfo.c)
Io cancelation support (see io/cancel, et al)
Directory change notification (see io/dir.c)
Error logging (see io/errlog.c)
Io completion ports (see io/iocomp.c)
File locking (see io/lock.c)
Hardware resource management (see io/resource.c)
Exception support (see ke/catch.c)
Mutex support (see nt/mutex.c)
* Verify implementation
* Major areas
Security support (see se/*.c)
SCSI miniport driver
* Drivers
NTFS, EXT2 filesystems
Many others (use oem's where possible)
* For the future
DOS, Win16, POSIX subsystems

79
media/doc/win32k_refs.txt Normal file
View file

@ -0,0 +1,79 @@
References:
-----------
window -> desktop
window -> class
thread_input -> thread
thread -> process
process -> winsta
thread -> desktop
desktop -> winsta
winsta -> session
NOTE: Message queue has 1:1 relationship with (w32)thread and need no ref. count.
-If the (w32)thread is destroyed, so is the message queue.
-If the (w32)thread exist, so does the message queue.
So if you want the queue to hang around, you reference the thread instead.
^ This is wrong, one can attach message queue to different thread using
AttachThreadInput. The number of threads sharing a queue is stored in the
message queue structure and can be considered a reference count. Also on
Windows systems there is maintained a global list of thread attachments.
Above references create following dependencies:
-----------------------------------------------
window -> desktop -> winsta -> session
window -> class
thread -> process -> winsta -> session
thread -> desktop -> winsta -> session
process -> winsta -> session
NtUser/NtGdi/win32k syscalls
----------------------------
A process and/or thread automatically gets converted to a GUI thread /
process when the first syscall from the shadow service table is called (ie.
any NtUser* or NtGdi* call). GUI threads have bigger kernel stack (FIXME:
not the case on ReactOS yet) and have associated storage for the Win32
structures. The conversion itself happens in the syscall handler and the
win32k callbacks (registered with PsEstablishWin32Callouts) are called
accordingly.
A process automatically establishes a connection to a window station on the
GUI thread conversion. The Win32 process initialization callback routine
also creates and initializes the W32PROCESS structure and associates it with
the process.
Similary for thread the callback routine automatically assigns a desktop
when the thread is converted to GUI thread. The thread also gets a W32THREAD
structure, a message queue and a thread input structures.
Beware that there is an exception to these rules and that's WinLogon. Since
at the time the process starts no window stations or desktops exist, none
are assigned to the the initial thread / process. The first Win32k calls
the thread does are to create the window station and desktop and to associate
them with itself.
FIXME: At the time of this writing there's a second exception, a "primitive
message queue" thread in CSRSS that is created before any window stations
exist and is used to capture keyboard input in console mode. Eventually we
should get rid of it and replace is with hidden window w/ focus or something
similar.
Generally this means that when you are in a Win32k syscall function (other
than the window station or desktop functions) you can be 100% sure that the
following exists:
- Process window station
- Win32 process structure
- Win32 thread structure
- Thread message queue
- Thread input
- Thread desktop
There is no need to validate any of these values, because they MUST EXIST!

156
media/doc/winsta and desktops.txt Normal file
View file

@ -0,0 +1,156 @@
SAWinSta
--------
I write a GUI appication, and the user may run it in task schedule. Since
windows 2000/XP treat schedule task as a service, the schedule service can
not be associated with interactive desktop object in the in 2 states
1) No user log on
2) Log on with another account.
I write a test program, and find when the schedule service starts, the
station/desktop will be "SAWinSta\Desktop" in both cases
Is there any way to let schedule service associated with interactive desktop
in these 2 cases?
thanks
-------------------------------------------
Service-0x0-3e7$
----------------
By default Win32 services associated with non-visible windows station (for
services which run in the local system account it is Service-0x0-3e7$) and they
can't (without using special flag MB_SERVICE_NOTIFICATION or
MB_DEFAULT_DESKTOP_ONLY in the MessageBox function) interact with user.
However, you may configure a service to have GUI capabilities. Just set Type
field of the registry service entry equal SERVICE_INTERACTIVE_PROCESS. When
this key is specified SCM will connect the service with WinSta0 instead
Service-0x0-3e7$ and it will alow to display windows and dialog boxes.
-------------------------------------------------
WinSta0
-------
-The one-and-only interactive WinSta.
-No other winsta can be visible/active.
-Only WinSta0 can receive input.
-All other WinSta's are invisible/non-interactive WinStas.
What good is a invisible WinSta? Its used for running services in thus services cant
interact with the user.
There are limits to what u can do in a invisible WinSta.
-Bitblt wont work for instance, since nothing is really displayed in a invisible WinSta (to save resources).
No point in using GDI resources for stuff noone can see.
-SendInput wont work
---------------------------------------------------
MORE INFORMATION
A Window station can either be interactive or noninteractive. (At the moment on Windows NT 3.51 and 4.0, only "Winsta0" can be an interactive Window station.) Any Desktops created on the interactive Window station will have the ability to become active. An active Desktop encompasses the ability for user objects (such as windows and dialog boxes) created on the Desktop to be visible to the interactively logged-on user (that is, the user who logs on the system via CTRL-ALT-DELETE) and receive user input.
When the interactively logged-on user launches any processes, these processes are associated with the "default" Desktop in the "Winsta0" Window station. The "default" Desktop is considered the active Desktop. A process on the active Desktop could switch Desktops such that another Desktop becomes the active Desktop such as the "Winlogon" Desktop. Only one Desktop can be the active Desktop at any one time.
Desktops associated with a noninteractive Window station can create user objects. These objects will never be visible to the interactively logged-on user and will never receive any user input. If you have a noninteractive Service running in the LocalSystem account, any user objects created by the service will not be visible to the interactively logged-on user. In addition, any processes launched by the service will also not be visible.
If our desktop has the same name as the active one, we are running on the
active (input) desktop. This is true because desktops have exactly one
name each, and within a window station, desktop names must be unique
----------------------------------------------------------------
Process closing window station with CloseWindowStation can't be assigned to the window station
it is closing.
The reason is that each session has its own CSRSS, as well as instanced
win32k.sys data. So in each session, you basically have a complete copy of
Windows that doesn't know about the existance of any other copy. You're not
just on a different desktop/windowstation when you're in a different
session.
Lawrence, you are wrong. HWNDs are valid throughout the whole
windowstation, not only the creating process. That's because they
are pointers, but not in your address space...
The CreateDesktop function creates a new desktop on the window station associated with the calling process.
PROCESS:
-every w32 process is associated with a WindowStation
-can move between window stations (well, with strict limitations i would guess eg. what if
windows have been created and is using the winsta heap? or can multiple winsta heaps be mapped into
one process?? )
THREADS:
-can only enumerate windows on its desktop (but u can easely switch to a different desk)
-every w32 thread is associated with a Desktop
-Threads can switch between desktops, and windows are created on the thread's current desktop
(a thread can have windows on multiple desktops? IS THIS REALLY TRUE?)
DESKTOP:
-owns windows
-Only one desktop at a time can interact with the user, and that desktop must necessarily
be associated with Winsta0
-Only one desktop is visible to the user and only one can receives input at any time
-contain a logical display surface
-contin windows (or a pointer to the desktop window)
-contain menus
-contain hooks
-holds UI objects, such as windows, menus, and hooks
-Once a window is created it cannot move between desktops
SESSION:
-session = win32k instance
-Every session contains one or more windows stations
-A given login session has only one window station with access to user interactions
(term server has multiple login sessions)
-each logon session is associated with a window station
WINDOW STATION:
-only Winsta0 has access to the display
-Only one window station, called Winsta0, can interact with the user display, keyboard, mouse
-is a secure object
-Only the interactive window station WinSta0, can display
output or receive input. Other window stations are used by "services"
(but cant u switch winsta?? so a noninteractive winsta becomes active?)
-contains a set of global atoms
-contains a clipboard
-contains a set of desktop objects
-contains handle table(s) (handles are valid throughout the whole windowstation, not only the creating process)
-contain heaps (pointer(s) to the section heap(s) shared between user32/gdi32/win32k)
-A Windows 2000 session will have several windows stations, one assigned to the logon session
of the interactive user, and others assigned to the Winlogon process, the secure screen saver
process, and any service that runs in a security context other than that of the interactive user.
The interactive window station assigned to the logon session of the interactive user also contains
the keyboard, mouse, and display device. The interactive window station is visible to the user and
can receive input from the user. All other window stations are noninteractive, which means that
they cannot be made visible to the user, and cannot receive user input.
WINDOWS
-is owned by a desktop
-windows are tied to the window station where they started
-u cant move windows between desktops either
The system associates a desktop with a thread when that thread is created
The desktop associated with a thread must be on the window station associated with the thread's process.
A thread can use the SetThreadDesktop function to change its desktop.
The GetThreadDesktop function retrieves a handle to the desktop associated with a specified thread.
The calling process must have an associated window station, either assigned by the system at process creation time or set by SetProcessWindowStation. A desktop is a secure object contained within a window station object.
There can be several window stations in the system but only one of them can
be the interactive window station. That is the only windowstation whose
processes can communicate with the user (it has a visible desktop and can
receive mouse and keyboard input). A desktop lives inside a windowstation
and provides a display to the user. Only one desktop can be the active
desktop for a particular windowstation at any time. Furthermore only a
desktop that lives inside the interactive windowstation and is the currently
active desktop for that windowstation is visible to the user. On your
average Windows NT system there are at least 3 desktops inside the
interactive windowstation: the 'shell', winlogon and the screensaver. Each
process that runs on your system (and hence services as well) run inside a
windowstation and each thread in that process runs in the same windowstation
but can run in a different desktop.

13
media/drivers/etc/KDBinit Normal file
View file

@ -0,0 +1,13 @@
# Example KDB.init file
#
# Set the disassembly flavor to "intel" (default is "at&t")
set syntax intel
# Change the condition to enter KDB on INT3 to "always" (default is "kmode")
#set condition INT3 first always
# This is a special command available only in the KDBinit file - it breaks into
# KDB when it is interpreting the init file at startup.
#break

3
media/drivers/etc/hosts Normal file
View file

@ -0,0 +1,3 @@
# ReactOS hosts file
127.0.0.1 localhost

16
media/drivers/etc/networks Normal file
View file

@ -0,0 +1,16 @@
# The ReactOS networks file
#
# This file contains network name/network number mappings for
# local networks. Network numbers are recognized in dotted decimal form.
#
# Format:
#
# <network name> <network number> [aliases...] [#<comment>]
#
# For example:
#
# loopback 127
# campus 284.122.107
# london 284.122.108
loopback 127

155
media/drivers/etc/protocol Normal file
View file

@ -0,0 +1,155 @@
# The ReactOS protocols file
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
# Last IANA update included dated 2009-06-18
#
# See also http://www.iana.org/assignments/protocol-numbers
ip 0 IP # internet protocol, pseudo protocol number
hopopt 0 HOPOPT # hop-by-hop options for ipv6
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group management protocol
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
cbt 7 CBT # CBT, Tony Ballardie <A.Ballardie@cs.ucl.ac.uk>
egp 8 EGP # exterior gateway protocol
igp 9 IGP # any private interior gateway (Cisco: for IGRP)
bbn-rcc 10 BBN-RCC-MON # BBN RCC Monitoring
nvp 11 NVP-II # Network Voice Protocol
pup 12 PUP # PARC universal packet protocol
argus 13 ARGUS # ARGUS
emcon 14 EMCON # EMCON
xnet 15 XNET # Cross Net Debugger
chaos 16 CHAOS # Chaos
udp 17 UDP # user datagram protocol
mux 18 MUX # Multiplexing protocol
dcn 19 DCN-MEAS # DCN Measurement Subsystems
hmp 20 HMP # host monitoring protocol
prm 21 PRM # packet radio measurement protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
trunk-1 23 TRUNK-1 # Trunk-1
trunk-2 24 TRUNK-2 # Trunk-2
leaf-1 25 LEAF-1 # Leaf-1
leaf-2 26 LEAF-2 # Leaf-2
rdp 27 RDP # "reliable datagram" protocol
irtp 28 IRTP # Internet Reliable Transaction Protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol Class 4
netblt 30 NETBLT # Bulk Data Transfer Protocol
mfe-nsp 31 MFE-NSP # MFE Network Services Protocol
merit-inp 32 MERIT-INP # MERIT Internodal Protocol
dccp 33 DCCP # Datagram Congestion Control Protocol
3pc 34 3PC # Third Party Connect Protocol
idpr 35 IDPR # Inter-Domain Policy Routing Protocol
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 38 IDPR-CMTP # IDPR Control Message Transport Proto
tp++ 39 TP++ # TP++ Transport Protocol
il 40 IL # IL Transport Protocol
ipv6 41 IPv6 # IPv6
sdrp 42 SDRP # Source Demand Routing Protocol
ipv6-route 43 IPv6-Route # Routing Header for IPv6
ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6
idrp 45 IDRP # Inter-Domain Routing Protocol
rsvp 46 RSVP # Resource ReSerVation Protocol
gre 47 GRE # Generic Routing Encapsulation
dsr 48 DSR # Dynamic Source Routing Protocol
bna 49 BNA # BNA
esp 50 ESP # Encap Security Payload
ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 (not in official list)
ah 51 AH # Authentication Header
ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 (not in official list)
i-nlsp 52 I-NLSP # Integrated Net Layer Security TUBA
swipe 53 SWIPE # IP with Encryption
narp 54 NARP # NBMA Address Resolution Protocol
mobile 55 MOBILE # IP Mobility
tlsp 56 TLSP # Transport Layer Security Protocol
skip 57 SKIP # SKIP
ipv6-icmp 58 IPv6-ICMP # ICMP for IPv6
ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6
ipv6-opts 60 IPv6-Opts # Destination Options for IPv6
# 61 # any host internal protocol
cftp 62 CFTP # CFTP
# 63 # any local network
sat-expak 64 SAT-EXPAK # SATNET and Backroom EXPAK
kryptolan 65 KRYPTOLAN # Kryptolan
rvd 66 RVD # MIT Remote Virtual Disk Protocol
ippc 67 IPPC # Internet Pluribus Packet Core
# 68 # any distributed file system
sat-mon 69 SAT-MON # SATNET Monitoring
visa 70 VISA # VISA Protocol
ipcv 71 IPCV # Internet Packet Core Utility
cpnx 72 CPNX # Computer Protocol Network Executive
cphb 73 CPHB # Computer Protocol Heart Beat
wsn 74 WSN # Wang Span Network
pvp 75 PVP # Packet Video Protocol
br-sat-mon 76 BR-SAT-MON # Backroom SATNET Monitoring
sun-nd 77 SUN-ND # SUN ND PROTOCOL-Temporary
wb-mon 78 WB-MON # WIDEBAND Monitoring
wb-expak 79 WB-EXPAK # WIDEBAND EXPAK
iso-ip 80 ISO-IP # ISO Internet Protocol
vmtp 81 VMTP # Versatile Message Transport
secure-vmtp 82 SECURE-VMTP # SECURE-VMTP
vines 83 VINES # VINES
ttp 84 TTP # TTP
nsfnet-igp 85 NSFNET-IGP # NSFNET-IGP
dgp 86 DGP # Dissimilar Gateway Protocol
tcf 87 TCF # TCF
eigrp 88 EIGRP # Enhanced Interior Routing Protocol (Cisco)
ospf 89 OSPFIGP # Open Shortest Path First IGP
sprite-rpc 90 Sprite-RPC # Sprite RPC Protocol
larp 91 LARP # Locus Address Resolution Protocol
mtp 92 MTP # Multicast Transport Protocol
ax.25 93 AX.25 # AX.25 Frames
ipip 94 IPIP # Yet Another IP encapsulation
micp 95 MICP # Mobile Internetworking Control Pro.
scc-sp 96 SCC-SP # Semaphore Communications Sec. Pro.
etherip 97 ETHERIP # Ethernet-within-IP Encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
# 99 # any private encryption scheme
gmtp 100 GMTP # GMTP
ifmp 101 IFMP # Ipsilon Flow Management Protocol
pnni 102 PNNI # PNNI over IP
pim 103 PIM # Protocol Independent Multicast
aris 104 ARIS # ARIS
scps 105 SCPS # SCPS
qnx 106 QNX # QNX
a/n 107 A/N # Active Networks
ipcomp 108 IPComp # IP Payload Compression Protocol
snp 109 SNP # Sitara Networks Protocol
compaq-peer 110 Compaq-Peer # Compaq Peer Protocol
ipx-in-ip 111 IPX-in-IP # IPX in IP
vrrp 112 VRRP # Virtual Router Redundancy Protocol
pgm 113 PGM # PGM Reliable Transport Protocol
# 114 # any 0-hop protocol
l2tp 115 L2TP # Layer Two Tunneling Protocol
ddx 116 DDX # D-II Data Exchange
iatp 117 IATP # Interactive Agent Transfer Protocol
stp 118 STP # Schedule Transfer
srp 119 SRP # SpectraLink Radio Protocol
uti 120 UTI # UTI
smp 121 SMP # Simple Message Protocol
sm 122 SM # SM
ptp 123 PTP # Performance Transparency Protocol
isis 124 ISIS # ISIS over IPv4
fire 125 FIRE
crtp 126 CRTP # Combat Radio Transport Protocol
crdup 127 CRUDP # Combat Radio User Datagram
sscopmce 128 SSCOPMCE
iplt 129 IPLT
sps 130 SPS # Secure Packet Shield
pipe 131 PIPE # Private IP Encapsulation within IP
sctp 132 SCTP # Stream Control Transmission Protocol
fc 133 FC # Fibre Channel
rsvp-e2e-ignore 134 RSVP-E2E-IGNORE
# 135 # Mobility Header
udplite 136 UDPLite
mpls-in-ip 137 MPLS-in-IP
manet 138 manet # MANET Protocols [RFC5498]
hip 139 HIP # Host Identity Protocol
shim6 140 Shim6 #Shim6 Protocol [RFC5533]
# 141-252 Unassigned [IANA]
# 253 Use for experimentation and testing [RFC3692]
# 254 Use for experimentation and testing [RFC3692]
# 255 Reserved [IANA]

8236
media/drivers/etc/services Normal file
View file

File diff suppressed because it is too large Load diff

89
media/fonts/CMakeLists.txt Normal file
View file

@ -0,0 +1,89 @@
list(APPEND FONT_FILES
DejaVuMathTeXGyre.ttf
DejaVuSans-Bold.ttf
DejaVuSans-BoldOblique.ttf
DejaVuSans-ExtraLight.ttf
DejaVuSans-Oblique.ttf
DejaVuSans.ttf
DejaVuSansCondensed-Bold.ttf
DejaVuSansCondensed-BoldOblique.ttf
DejaVuSansCondensed-Oblique.ttf
DejaVuSansCondensed.ttf
DejaVuSansMono-Bold.ttf
DejaVuSansMono-BoldOblique.ttf
DejaVuSansMono-Oblique.ttf
DejaVuSansMono.ttf
DejaVuSerif-Bold.ttf
DejaVuSerif-BoldItalic.ttf
DejaVuSerif-Italic.ttf
DejaVuSerif.ttf
DejaVuSerifCondensed-Bold.ttf
DejaVuSerifCondensed-BoldItalic.ttf
DejaVuSerifCondensed-Italic.ttf
DejaVuSerifCondensed.ttf
FreeMono.ttf
FreeMonoBold.ttf
FreeMonoBoldOblique.ttf
FreeMonoOblique.ttf
FreeSans.ttf
FreeSansBold.ttf
FreeSansBoldOblique.ttf
FreeSansOblique.ttf
FreeSerif.ttf
FreeSerifBold.ttf
FreeSerifBoldItalic.ttf
FreeSerifItalic.ttf
FSEX301.ttf
FSEX301-L2.ttf
LiberationMono-Bold.ttf
LiberationMono-BoldItalic.ttf
LiberationMono-Italic.ttf
LiberationMono-Regular.ttf
LiberationSans-Bold.ttf
LiberationSans-BoldItalic.ttf
LiberationSans-Italic.ttf
LiberationSans-Regular.ttf
LiberationSansNarrow-Bold.ttf
LiberationSansNarrow-BoldItalic.ttf
LiberationSansNarrow-Italic.ttf
LiberationSansNarrow-Regular.ttf
LiberationSerif-Bold.ttf
LiberationSerif-BoldItalic.ttf
LiberationSerif-Italic.ttf
LiberationSerif-Regular.ttf
Marlett.ttf
OpenSans-Bold.ttf
OpenSans-BoldItalic.ttf
OpenSans-CondBold.ttf
OpenSans-CondLight.ttf
OpenSans-CondLightItalic.ttf
OpenSans-ExtraBold.ttf
OpenSans-ExtraBoldItalic.ttf
OpenSans-Italic.ttf
OpenSans-Light.ttf
OpenSans-LightItalic.ttf
OpenSans-Regular.ttf
OpenSans-Semibold.ttf
OpenSans-SemiboldItalic.ttf
symbol.ttf
tahoma.ttf
tahomabd.ttf
Ubuntu-B.ttf
Ubuntu-BI.ttf
Ubuntu-C.ttf
Ubuntu-L.ttf
Ubuntu-LI.ttf
Ubuntu-M.ttf
Ubuntu-MI.ttf
UbuntuMono-B.ttf
UbuntuMono-BI.ttf
UbuntuMono-R.ttf
UbuntuMono-RI.ttf
Ubuntu-R.ttf
Ubuntu-RI.ttf
UniVGA16.ttf)
foreach(item ${FONT_FILES})
add_cd_file(FILE "${CMAKE_CURRENT_SOURCE_DIR}/${item}" DESTINATION reactos/Fonts FOR all)
endforeach(item)

BIN
media/fonts/DejaVuMathTeXGyre.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSans-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSans-BoldOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSans-ExtraLight.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSans-Oblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSans.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansCondensed-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansCondensed-BoldOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansCondensed-Oblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansCondensed.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansMono-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansMono-BoldOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansMono-Oblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSansMono.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerif-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerif-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerif-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerif.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerifCondensed-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerifCondensed-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerifCondensed-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/DejaVuSerifCondensed.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FSEX301-L2.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FSEX301.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeMono.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeMonoBold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeMonoBoldOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeMonoOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSans.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSansBold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSansBoldOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSansOblique.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSerif.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSerifBold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSerifBoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/FreeSerifItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationMono-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationMono-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationMono-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationMono-Regular.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSans-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSans-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSans-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSans-Regular.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSansNarrow-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSansNarrow-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSansNarrow-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSansNarrow-Regular.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSerif-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSerif-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSerif-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/LiberationSerif-Regular.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Marlett.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-Bold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-BoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-CondBold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-CondLight.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-CondLightItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-ExtraBold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-ExtraBoldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-Italic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-Light.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-LightItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-Regular.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-Semibold.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/OpenSans-SemiboldItalic.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-B.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-BI.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-C.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-L.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-LI.ttf Normal file
View file

Binary file not shown.

BIN
media/fonts/Ubuntu-M.ttf Normal file
View file

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show more