From 8551dc320b5d9e396aa5a49fde2abc23b0e42457 Mon Sep 17 00:00:00 2001 From: David Welch Date: Sun, 17 Jan 1999 17:18:35 +0000 Subject: [PATCH] Removed obsolete documentation svn path=/trunk/; revision=175 --- reactos/doc/api.txt | 140 ---- reactos/doc/buglist | 2 - reactos/doc/cacheman.txt | 32 - reactos/doc/ddkfuncs.txt | 24 - reactos/doc/debug.txt | 19 - reactos/doc/faq.txt | 114 --- reactos/doc/internal/mm.txt | 10 - reactos/doc/internal/pe.txt | 1253 ------------------------------- reactos/doc/internal/readme.txt | 2 - reactos/doc/irq.txt | 135 ---- reactos/doc/irql.txt | 21 - reactos/doc/modules.txt | 33 - reactos/doc/wstring.txt | 16 - 13 files changed, 1801 deletions(-) delete mode 100644 reactos/doc/api.txt delete mode 100644 reactos/doc/buglist delete mode 100644 reactos/doc/cacheman.txt delete mode 100644 reactos/doc/ddkfuncs.txt delete mode 100644 reactos/doc/debug.txt delete mode 100644 reactos/doc/faq.txt delete mode 100644 reactos/doc/internal/mm.txt delete mode 100644 reactos/doc/internal/pe.txt delete mode 100644 reactos/doc/internal/readme.txt delete mode 100644 reactos/doc/irq.txt delete mode 100644 reactos/doc/irql.txt delete mode 100644 reactos/doc/modules.txt delete mode 100644 reactos/doc/wstring.txt diff --git a/reactos/doc/api.txt b/reactos/doc/api.txt deleted file mode 100644 index 4dd8408e5b9..00000000000 --- a/reactos/doc/api.txt +++ /dev/null @@ -1,140 +0,0 @@ -This file attempts to document the functions made publically available by -the various subsystems. - -* Formatted I/O operations * - -NAME: int vsprintf(char *buf, const char *fmt, va_list args) -NAME: int sprintf(char* buf, const char* fmt, ...) -WHERE: internal/kernel.h -FUNCTION: The same as the standard c library versions - -* PIO operations * - -NAME: in[b/w/l](port) -WHERE: internal/io.h -FUNCTION: Read an IO port of the specified size (byte/word or long) -RETURNS: The value read - -NAME: out[b/w/l](port,val) -WHERE: internal/io.h -FUNCTION: Write an IO port of the specified size (byte/word or long) - -NAME: in_p[b/w/l](port) -WHERE: internal/io.h -FUNCTION: Read an IO port of the specified size (byte/word or long) with - a pause -RETURNS: The value read - -NAME: out_p[b/w/l](port,val) -WHERE: internal/io.h -FUNCTION: Write an IO port of the specified size (byte/word or long) with - a pause - -* Bit operations * - -NAME: int set_bit(int nr, void* addr) -NAME: int clear_bit(int nr, void* addr) -NAME: int change_bit(int nr, void* addr) -WHERE: internal/bitops.h> -FUNCTION: Operate on a bit in the word pointed to by addr -RETURN: 0 if the bit was cleared before the operations - non-zero otherwise - -* Debugging functions * - -NAME: DPRINT(fmt,....) -WHERE: internal/debug.h -FUNCTION: Outputs a string to the console if NDEBUG isn't defined before -including internal/debug.h, a NOP otherwise -ARGUMENTS: The same as printf - -NAME: printk -WHERE: internal/kernel.h -FUNCTION: Outputs a string to the console -ARGUMENTS: The same as printf - -* Memory managment functions * - -NAME: unsigned int physical_to_linear(unsigned int paddr) -WHERE: hal/page.h -FUNCTION: Converts a physical address to a linear one -RECEIVES: - paddr = the physical address to convert -RETURNS: A virtual address where the memory at that physical address can be -accessed - -NAME: void* ExAllocatePool(unsigned int size, unsigned int type = 0); -WHERE: internal/pool.h -FUNCTION: Allocates a block of memory -RECEIVES: - size = the size of the block to allocate - type = will be whether to allocate pagable memory -RETURNS: The address of the block -NOTE: This isn't interrupt safe - -NAME: void ExFreePool(void* block) -WHERE: internal/pool.h -FUNCTION: Frees a block of memory - -NAME: void free_page(unsigned int physical_base, unsigned int nr = 1) -WHERE: internal/mm.h -FUNCTION: Adds a continuous range of physical memory to the free list - -NAME: unsigned int get_free_page(void) -WHERE: internal/mm.h -FUNCTION: Gets a free page -RETURNS: Its physical address - -NAME: unsigned int get_page_physical_address(unsigned int vaddr) -WHERE: internal/mm.h -FUNCTION: Gets the physical address of a page - -NAME: void mark_page_not_writable(unsigned int vaddr) -WHERE: internal/mm.h -FUNCTION: Prevent writing the page - -* DMA functions * - -NAME: unsigned int get_dma_page(unsigned int max_address) -WHERE: internal/mm.h -FUNCTION: Gets a page with a restricted physical address i.e. suitable for - dma -RETURNS: The physical address of the page - -NAME: void disable_dma(unsigned int dmanr) -WHERE: internal/dma.h -FUNCTION: Disables the specified dma channel - -NAME: void enable_dma(unsigned int dmanr) -WHERE: internal/dma.h -FUNCTION: Enables the specified dma channel - -NAME: void clear_dma_ff(unsigned int dmanr) -WHERE: internal/dma.h -FUNCTION: Clear the dma flip-flop - -NAME: void set_dma_mode(unsigned int dmanr, char mode) -WHERE: internal/dma.h -FUNCTION: Sets the type of dma transfer - -NAME: void set_dma_page(unsigned int dmanr, char pagenr) -WHERE: internal/dma.h -FUNCTION: Set only the page register bits of the transfer address - -NAME: void set_dma_addr(unsigned int dmanr, unsigned int a) -WHERE: internal/dma.h -FUNCTION: Set the transfer address for dma -NOTE: Assumes flip-flop is clear - -NAME: void set_dma_count(unsigned int dmanr, unsigned int count) -WHERE: internal/dma.h -FUNCTION: Sets the size of the transfer -ARGUMENTS: - count = the number of bytes to transfer -NOTE: Count must be even for channels 5-7 - -NAME: int get_dma_residue(unsigned int dmanr) -WHERE: internal/dma.h -FUNCTION: Gets the residue remaining after a dma transfer on the channel - - diff --git a/reactos/doc/buglist b/reactos/doc/buglist deleted file mode 100644 index 096fb3e8cf1..00000000000 --- a/reactos/doc/buglist +++ /dev/null @@ -1,2 +0,0 @@ -* Kernel bugs not fixed - diff --git a/reactos/doc/cacheman.txt b/reactos/doc/cacheman.txt deleted file mode 100644 index 7b6d79f6a44..00000000000 --- a/reactos/doc/cacheman.txt +++ /dev/null @@ -1,32 +0,0 @@ -- Cache Manager - -This document describes the current implementation of the cache manager. - -- Description - -In its current state the CM (cache manager) only includes primitives to -cache disk blocks, this is useful for filesystem metadata but it requires an -additional copy operation when reading files from cache. This will be fixed. - -Each disk drive with data in the cache has an associated DCCB (Device Cache -Control Block) which details all the blocks from the device in memory. If a -filesystem requires cache services for a device it must call CbInitDccb to -initialize this structure. - -Each block with data from a device has an associated CCB (Cache Control -Block) with a pointer to the physical memory used to hold the block, and -various state and locking information. When a filesystem requires a block -from the device it calls CbAcquireForRead or CbAcquireForWrite which ensure -the data for the block is uptodate (loading it from disk if necessary) and -return a pointer to the associated CCB. When a filesystem has finished with -a block it calls CbReleaseFromRead or CbReleaseFromWrite, it is important to -call these functions because the CM can only release blocks from the cache -if they have no active readers or writers. The CM also enforces cache -consistency by ensuring that while multiple threads can be reading a block -simultaneously, there is only ever one active writers. - -The CM provides no support for deadlock prevention/detection as it has no -knowledge of the layout of a a filesystem (nor should it have). - -- TODO - diff --git a/reactos/doc/ddkfuncs.txt b/reactos/doc/ddkfuncs.txt deleted file mode 100644 index c0bcacea251..00000000000 --- a/reactos/doc/ddkfuncs.txt +++ /dev/null @@ -1,24 +0,0 @@ -This is a list of the functions documented in the ddk that have been -implemented - -IoAllocateController -IoFreeController -IoCreateController -IoDeleteController -IoStartNextPacket -IoStartNextPacketByKey -IoStartPacket -IoSizeOfIrp -IoMarkIrpPending -IoFreeIrp -IoConnectInterrupt -IoDisconnectInterrupt -IoGetCurrentIrpStackLocation -IoGetNextIrpStackLocation -IoRequestDpc -IoInitializeDpc -IoInitializeTimer -IoStartTimer -IoStopTimer -IoCreateDevice -IoCallDriver diff --git a/reactos/doc/debug.txt b/reactos/doc/debug.txt deleted file mode 100644 index 28467c6d883..00000000000 --- a/reactos/doc/debug.txt +++ /dev/null @@ -1,19 +0,0 @@ -Some notes on debugging the ReactOS kernel ------------------------------------------- - -* Interpreting crashes - -If the kernel causes a fatal cpu fault then it will print out a message and -halt. This message contains important information for debugging the problem, -look for these lines - -Exception: xx(yy) -CS:EIP 20:zzzzzzzzzzzz - -Here xx is the type of error, usually either 14 or 13 and yy is the error -code. Generally error codes 13 and 14 both mean the kernel tried to access -some memory in an invalid way. zzzzzzzzz is the address of the erronous -instruction. - -* Debugging with bochs - diff --git a/reactos/doc/faq.txt b/reactos/doc/faq.txt deleted file mode 100644 index 1fe8c22e27f..00000000000 --- a/reactos/doc/faq.txt +++ /dev/null @@ -1,114 +0,0 @@ -Kernel Development FAQ (for v0.0.7) - -This attempts to answer some of the common questions people developing for -the kernel might want to ask (or at least what I think they should ask). -Obviously I can only detail those parts which I have written so other -developers please fill in the gaps. - -Q: What is this, what are you people, what's going on -A: This is the ReactOS, an operating system intended as a clone of windows -NT. See the project website (http://www.sid-dis.com/reactos/) for more details. - -Q: Why ReactOS -A: To condemn Bill Gates to penury. - -Q: What do I need to compile the kernel -A: DJGPP, get it from http://www.delorie.com/djgpp - -Q: How do I compile the kernel -A: Unpack the zip. It is important not to install the kernel in the same -directory as a previous version, this has caused a bit of confusion in the -past. Edit the makefile in the top level directory, in particular select the -correct host to build from. Then run make in the top directory - -Q: What files are created when I make the kernel -A: The following files are created in the kernel directory - kimage = the kernel as a coff executable - kimage.bin = the kernel as a raw binary image - kernel.sym = a list of the kernel symbols - -Q: How do I load the kernel -A: Run the boot.bat batch file. - -Q: Does it boot from disk -A: Not at the moment. - -Q: When I run the kernel it crashes -A: The kernel (at the moment) can only be loaded from a clean system. That -is one without EMM386 or any version of windows loaded. A quick way to -ensure this (if you have windows 95) is to set the program to run in msdos -mode and specify an empty config.sys and autoexec.bat. See the windows help -for more information. - -If you do that and the problem persists then contact the kernel team -(ros-kernel@sid-dis.com) as it is probably a bug in the kernel - -Q6: How do I load a module with the kernel -A: Add the names of any modules to be loaded to the command line of boot.bat. - -Q7: I want to add code to the kernel, how do I get it to be compiled -A: You will need to edit the Makefile in kernel directory. There should be -a statement like this - - OBJECTS = hal/head.o hal/exp.o kernel/vsprintf.o \ - .... - kernel/irqhand.o hal/page.o mm/virtual.o kernel/error.o \ - kernel/exports.o kernel/module.o - -Add the name of the object file (the file produced when your code is -compiled) to the end of the statement (in this case after kernel/module.o). -If you need to go onto a new line then add a slash to the end of the -previous line. It is also very important to use an editor which preserves -tabs. - -Q8: I want to add code to the kernel, how do I make it official -A: Contact the kernel mailing list ros-kernel@sid-dis.com or our coordinator -dwinkley@whitworth.edu. If it is for a specific section then the kernel -website (http://www.geocities.com/SiliconValley/Peaks/1957) has a list of -those working on individual areas, you might what to contact one of them -instead. - -Q9: What header files should I use -A: Don't include the usual DJGPP headers like stdio.h unless you are using -something compiler based like stdargs.h. To use the DJGPP headers requires -linking with libc which is useless in kernel mode. - -All the header files are in the top-level include directory which is laid -out like this - include = general win32 api declarations - include/internal = private kernel headers - include/internal/hal = HAL headers - include/ddk = header files with declarations for modules - -There should be a file called api.txt which documents all of the functions -(and which header files they need). - -Q11: I want to export my function for modules to use, how do I do that -A: Add the function to the list in kernel/exports.lst, then remake the -kernel. Note the function must be declared as extern "C". - -Q12: I want to make my functions part of the kernel interface to user mode, -A: That section isn't finished yet, though it will probably mean adding a -pointer to the function and the size of its parameters to a internal table -somewhere. - -Q14: I want to write a module, what are the guidelines -A: See modules.txt in this directory - -Q15: I want to write an ISR (interrupt service routine) -A: See irq.txt in this directory - -Q16: I want to use DMA -A: Firstly this answer covers only DMA via the dma chips *not* -busmaster DMA. - -To program the dma chip use the functions in internal/dma.h (look in api.txt -for details). PC DMA can only go to memory with a physical address below -1mb (or 16mb on some systems), use the get_dma_page to allocate this kind -of memory. - -Q17: You haven't answered my question -A: Send your questions to ros-kernel@sid-dis.com - - -- David Welch (welch@mcmail.com) diff --git a/reactos/doc/internal/mm.txt b/reactos/doc/internal/mm.txt deleted file mode 100644 index 880bee07976..00000000000 --- a/reactos/doc/internal/mm.txt +++ /dev/null @@ -1,10 +0,0 @@ -This document describes the implementation of the memory managment - - -* ReactOS memory map - -0x00000000 - 0xc0000000 = User memory -0xc0000000 - 0xd0000000 = Kernel memory -0xd0000000 - 0xffffffff = Identify map of physical memory - -* diff --git a/reactos/doc/internal/pe.txt b/reactos/doc/internal/pe.txt deleted file mode 100644 index aeafa654276..00000000000 --- a/reactos/doc/internal/pe.txt +++ /dev/null @@ -1,1253 +0,0 @@ - - PORTABLE EXECUTABLE FORMAT - - Author: Micheal J. O'Leary - - - Preface - - This document was edited and released by Microsoft Developer - Support. It describes the binary portable executable format for NT. - The information is provided at this point because we feel it will - make the work of application development easier. Unfortunately, the - information in this document may change before the final release of - Windows NT. Microsoft is NOT committing to stay with these formats - by releasing this document. Questions or follow-ups for any of the - information presented here should be posted to CompuServe MSWIN32 - forum, section 6. - --Steve Firebaugh - Microsoft Developer Support - - - -Contents - - 1. Overview - - 2. PE Header - - 3. Object Table - - 4. Image Pages - - 5. Exports - 5.1 Export Directory Table - 5.2 Export Address Table - 5.3 Export Name Table Pointers - 5.4 Export Ordinal Table - 5.5 Export Name Table - - 6. Imports - 6.1 Import Directory Table - 6.2 Import Lookup Table - 6.3 Hint-Name Table - 6.4 Import Address Table - - 7. Thread Local Storage - 7.1 Thread Local Storage Directory Table - 7.2 Thread Local Storage CallBack Table - - 8. Resources - 8.1 Resource Directory Table - 8.2 Resource Example - - 9. Fixup Table - 9.1 Fixup Block - - 10. Debug Information - 10.1 Debug Directory - - - -1. Overview - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ <ÄÄ¿ <ÄÄÄÄÄ Base of Image Header - ³ DOS 2 Compatible ³ ³ - ³ EXE Header ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ - ³ unused ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ - ³ OEM Identifier ³ ³ - ³ OEM Info ³ ³ - ³ ³ ³ DOS 2.0 Section - ³ Offset to ³ ³ (for DOS compatibility only) - ³ PE Header ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ - ³ DOS 2.0 Stub ³ ³ - ³ Program & ³ ³ - ³ Reloc. Table ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÙ - ³ unused ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ <ÄÄÄÄÄÄÄÄÄ Aligned on 8 byte boundary - ³ PE Header ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ Object Table ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ Image Pages ³ - ³ import info ³ - ³ export info ³ - ³ fixup info ³ - ³ resource info³ - ³ debug info ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 1. A typical 32-bit Portable EXE File Layout - - - -2. PE Header - - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ SIGNATURE BYTES ³ CPU TYPE ³ # OBJECTS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TIME/DATE STAMP ³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ NT HDR SIZE³ FLAGS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÂÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³LMAJOR³LMINOR³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ENTRYPOINT RVA ³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ IMAGE BASE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ OBJECT ALIGN ³ FILE ALIGN ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ OS MAJOR ³ OS MINOR ³USER MAJOR ³USER MINOR ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ SUBSYS MAJOR³ SUBSYS MINOR³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ IMAGE SIZE ³ HEADER SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ FILE CHECKSUM ³ SUBSYSTEM ³ DLL FLAGS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ STACK RESERVE SIZE ³ STACK COMMIT SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ HEAP RESERVE SIZE ³ HEAP COMMIT SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ # INTERESTING RVA/SIZES ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ EXPORT TABLE RVA ³ TOTAL EXPORT DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ IMPORT TABLE RVA ³ TOTAL IMPORT DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESOURCE TABLE RVA ³ TOTAL RESOURCE DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ EXCEPTION TABLE RVA ³ TOTAL EXCEPTION DATA SIZE³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ SECURITY TABLE RVA ³ TOTAL SECURITY DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ FIXUP TABLE RVA ³ TOTAL FIXUP DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ DEBUG TABLE RVA ³ TOTAL DEBUG DIRECTORIES ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ IMAGE DESCRIPTION RVA ³ TOTAL DESCRIPTION SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ MACHINE SPECIFIC RVA ³ MACHINE SPECIFIC SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ THREAD LOCAL STORAGE RVA ³ TOTAL TLS SIZE ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 2. PE Header - -Notes: - - o A VA is a virtual address that is already biased by the Image - Base found in the PE Header. A RVA is a virtual address that is - relative to the Image Base. - - o An RVA in the PE Header which has a value of zero indicates the - field isn't used. - - o Image pages are aligned and zero padded to a File Align - boundary. The bases of all other tables and structures must be - aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's - must be on a 32 bit boundary. All table and structure fields - must be aligned on their "natural" boundaries, with the possible - exception of the Debug Info. - -SIGNATURE BYTES = DB * 4. -Current value is "PE/0/0". Thats PE followed by two zeros (nulls). - -CPU TYPE = DW CPU Type. -This field specifies the type of CPU compatibility required by this -image to run. The values are: - - o 0000h __unknown - - o 014Ch __80386 - - o 014Dh __80486 - - o 014Eh __80586 - - o 0162h __MIPS Mark I (R2000, R3000) - - o 0163h __MIPS Mark II (R6000) - - o 0166h __MIPS Mark III (R4000) - -# OBJECTS = DW Number of object entries. -This field specifies the number of entries in the Object Table. - -TIME/DATE STAMP = DD Used to store the time and date the file was -created or modified by the linker. - -NT HDR SIZE = DW This is the number of remaining bytes in the NT -header that follow the FLAGS field. - -FLAGS = DW Flag bits for the image. -The flag bits have the following definitons: - - o 0000h __Program image. - - o 0002h __Image is executable. - If this bit isn't set, then it indicates that either errors - where detected at link time or that the image is being - incrementally linked and therefore can't be loaded. - - o 0200h __Fixed. - Indicates that if the image can't be loaded at the Image Base, - then don't load it. - - o 2000h __Library image. - -LMAJOR/LMINOR = DB Linker major/minor version number. - -ENTRYPOINT RVA = DD Entrypoint relative virtual address. -The address is relative to the Image Base. The address is the -starting address for program images and the library initialization -and library termination address for library images. - -IMAGE BASE = DD The virtual base of the image. -This will be the virtual address of the first byte of the file (Dos -Header). This must be a multiple of 64K. - -OBJECT ALIGN = DD The alignment of the objects. This must be a power -of 2 between 512 and 256M inclusive. The default is 64K. - -FILE ALIGN = DD Alignment factor used to align image pages. The -alignment factor (in bytes) used to align the base of the image pages -and to determine the granularity of per-object trailing zero pad. -Larger alignment factors will cost more file space; smaller alignment -factors will impact demand load performance, perhaps significantly. -Of the two, wasting file space is preferable. This value should be a -power of 2 between 512 and 64K inclusive. - -OS MAJOR/MINOR = DW OS version number required to run this image. - -USER MAJOR/MINOR # = DW User major/minor version number. -This is useful for differentiating between revisions of -images/dynamic linked libraries. The values are specified at link -time by the user. - -SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number. - -IMAGE SIZE = DD The virtual size (in bytes) of the image. -This includes all headers. The total image size must be a multiple -of Object Align. - -HEADER SIZE = DD Total header size. -The combined size of the Dos Header, PE Header and Object Table. - -FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker. - -SUBSYSTEM = DW NT Subsystem required to run this image. -The values are: - - o 0000h __Unknown - - o 0001h __Native - - o 0002h __Windows GUI - - o 0003h __Windows Character - - o 0005h __OS/2 Character - - o 0007h __Posix Character - -DLL FLAGS = DW Indicates special loader requirements. -This flag has the following bit values: - - o 0001h __Per-Process Library Initialization. - - o 0002h __Per-Process Library Termination. - - o 0004h __Per-Thread Library Initialization. - - o 0008h __Per-Thread Library Termination. - -All other bits are reserved for future use and should be set to zero. - -STACK RESERVE SIZE = DD Stack size needed for image. -The memory is reserved, but only the STACK COMMIT SIZE is committed. -The next page of the stack is a 'guarded page'. When the application -hits the guarded page, the guarded page becomes valid, and the next -page becomes the guarded page. This continues until the RESERVE SIZE -is reached. - -STACK COMMIT SIZE = DD Stack commit size. - -HEAP RESERVE SIZE = DD Size of local heap to reserve. - -HEAP COMMIT SIZE = DD Amount to commit in local heap. - -# INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array -that follows. - -EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table. -This address is relative to the Image Base. - -IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table. -This address is relative to the Image Base. - -RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource -Table. This address is relative to the Image Base. - -EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception -Table. This address is relative to the Image Base. - -SECURITY TABLE RVA = DD Relative Virtual Address of the Security -Table. This address is relative to the Image Base. - -FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table. -This address is relative to the Image Base. - -DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table. -This address is relative to the Image Base. - -IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the -description string specified in the module definiton file. - -MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine -specific value. This address is relative to the Image Base. - -TOTAL EXPORT DATA SIZE = DD Total size of the export data. - -TOTAL IMPORT DATA SIZE = DD Total size of the import data. - -TOTAL RESOURCE DATA SIZE = DD Total size of the resource data. - -TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data. - -TOTAL SECURITY DATA SIZE = DD Total size of the security data. - -TOTAL FIXUP DATA SIZE = DD Total size of the fixup data. - -TOTAL DEBUG DIRECTORIES = DD Total number of debug directories. - -TOTAL DESCRIPTION SIZE = DD Total size of the description data. - -MACHINE SPECIFIC SIZE = DD A machine specific value. - - - -3. Object Table - -The number of entries in the Object Table is given by the # Objects -field in the PE Header. Entries in the Object Table are numbered -starting from one. The object table immediately follows the PE -Header. The code and data memory object entries are in the order -chosen by the linker. The virtual addresses for objects must be -assigned by the linker such that they are in ascending order and -adjacent, and must be a multiple of Object Align in the PE header. - -Each Object Table entry has the following format: - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ OBJECT NAME ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ VIRTUAL SIZE ³ RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ PHYSICAL SIZE ³ PHYSICAL OFFSET ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ RESERVED ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ OBJECT FLAGS ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 3. Object Table - -OBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded -ASCII string representing the object name. - -VIRTUAL SIZE = DD Virtual memory size. The size of the object that -will be allocated when the object is loaded. Any difference between -PHYSICAL SIZE and VIRTUAL SIZE is zero filled. - -RVA = DD Relative Virtual Address. The virtual address the object is -currently relocated to, relative to the Image Base. Each Object's -virtual address space consumes a multiple of Object Align (power of 2 -between 512 and 256M inclusive. Default is 64K), and immediately -follows the previous Object in the virtual address space (the virtual -address space for a image must be dense). - -PHYSICAL SIZE = DD Physical file size of initialized data. The size -of the initialized data in the file for the object. The physical -size must be a multiple of the File Align field in the PE Header, and -must be less than or equal to the Virtual Size. - -PHYSICAL OFFSET = DD Physical offset for object's first page. This -offset is relative to beginning of the EXE file, and is aligned on a -multiple of the File Align field in the PE Header. The offset is -used as a seek value. - -OBJECT FLAGS = DD Flag bits for the object. The object flag bits -have the following definitions: - - o 000000020h __Code object. - - o 000000040h __Initialized data object. - - o 000000080h __Uninitialized data object. - - o 040000000h __Object must not be cached. - - o 080000000h __Object is not pageable. - - o 100000000h __Object is shared. - - o 200000000h __Executable object. - - o 400000000h __Readable object. - - o 800000000h __Writeable object. - -All other bits are reserved for future use and should be set to zero. - -4. Image Pages - -The Image Pages section contains all initialized data for all -objects. The seek offset for the first page in each object is -specified in the object table and is aligned on a File Align -boundary. The objects are ordered by the RVA. Every object begins -on a multiple of Object Align. - - - -5. Exports - -A typical file layout for the export information follows: - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DIRECTORY TABLE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ADDRESS TABLE ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NAME PTR TABLE ³ - ³ ³ - ³ ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ORDINAL TABLE ³ - ³ ³ - ³ ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NAME STRINGS ³ - ³ ³ - ³ ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 4. Export File Layout - -5.1 Export Directory Table - -The export information begins with the Export Directory Table which -describes the remainder of the export information. The Export -Directory Table contains address information that is used to resolve -fixup references to the entry points within this image. - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ EXPORT FLAGS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TIME/DATE STAMP ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ MAJOR VERSION ³ MINOR VERSION ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NAME RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ORDINAL BASE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ # EAT ENTRIES ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ # NAME PTRS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ADDRESS TABLE RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NAME PTR TABLE RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ORDINAL TABLE RVA ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 5. Export Directory Table Entry - -EXPORT FLAGS = DD Currently set to zero. - -TIME/DATE STAMP = DD Time/Date the export data was created. - -MAJOR/MINOR VERSION = DW A user settable major/minor version number. - -NAME RVA = DD Relative Virtual Address of the Dll asciiz Name. -This is the address relative to the Image Base. - -ORDINAL BASE = DD First valid exported ordinal. -This field specifies the starting ordinal number for the export -address table for this image. Normally set to 1. - -# EAT ENTRIES = DD Indicates number of entries in the Export Address -Table. - -# NAME PTRS = DD This indicates the number of entries in the Name Ptr -Table (and parallel Ordinal Table). - -ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address -Table. -This address is relative to the Image Base. - -NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table -Pointers. -This address is relative to the beginning of the Image Base. This -table is an array of RVA's with # NAMES entries. - -ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals -Table Entry. -This address is relative to the beginning of the Image Base. - -5.2 Export Address Table - -The Export Address Table contains the address of exported entrypoints -and exported data and absolutes. An ordinal number is used to index -the Export Address Table. The ORDINAL BASE must be subracted from the -ordinal number before indexing into this table. - -Export Address Table entry formats are described below: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ EXPORTED RVA ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 6. Export Address Table Entry - -EXPORTED RVA = DD Export address. -This field contains the relative virtual address of the exported -entry (relative to the Image Base). - -5.3 Export Name Table Pointers - -The export name table pointers array contains address into the Export -Name Table. The pointers are 32-bits each, and are relative to the -Image Base. The pointers are ordered lexically to allow binary -searches. - -5.4 Export Ordinal Table - -The Export Name Table Pointers and the Export Ordinal Table form two -parallel arrays, separated to allow natural field alignment. The -export ordinal table array contains the Export Address Table ordinal -numbers associated with the named export referenced by corresponding -Export Name Table Pointers. - -The ordinals are 16-bits each, and already include the Ordinal Base -stored in the Export Directory Table. - -5.5 Export Name Table - -The export name table contains optional ASCII names for exported -entries in the image. These tables are used with the array of Export -Name Table Pointers and the array of Export Ordinals to translate a -procedure name string into an ordinal number by searching for a -matching name string. The ordinal number is used to locate the entry -point information in the export address table. - -Import references by name require the Export Name Table Pointers -table to be binary searched to find the matching name, then the -corresponding Export Ordinal Table is known to contain the entry -point ordinal number. Import references by ordinal number provide -the fastest lookup since searching the name table is not required. - -Each name table entry has the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ ASCII STRING ::: :::::::: '\0' ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 7. Export Name Table Entry - -ASCII STRING = DB ASCII String. -The string is case sensitive and is terminated by a null byte. - - - -6. Imports - -A typical file layout for the import information follows: - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DIRECTORY TABLE ³ - ³ ³ - ³ ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL DIR ENTRY ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DLL1 LOOKUP TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DLL2 LOOKUP TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ Dll3 LOOKUP TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ HINT-NAME TABLE ³ - ³ ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DLL1 ADDRESS TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DLL2 ADDRESS TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DLL3 ADDRESS TABLE ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 8. Import File Layout - -6.1 Import Directory Table - -The import information begins with the Import Directory Table which -describes the remainder of the import information. The Import -Directory Table contains address information that is used to resolve -fixup references to the entry points within a DLL image. The import -directory table consists of an array of Import Directory Entries, one -entry for each DLL this image references. The last directory entry is -empty (NULL) which indicates the end of the directory table. - -An Import Directory Entry has the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ IMPORT FLAGS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TIME/DATE STAMP ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ MAJOR VERSION ³ MINOR VERSION ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NAME RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ IMPORT LOOKUP TABLE RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ IMPORT ADDRESS TABLE RVA ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 9. Import Directory Entry - -IMPORT FLAGS = DD Currently set to zero. - -TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or -zero if not pre-snapped. - -MAJOR/MINOR VERSION = DW The major/minor version number of the dll -being referenced. - -NAME RVA = DD Relative Virtual Address of the Dll asciiz Name. -This is the address relative to the Image Base. - -IMPORT LOOKUP TABLE RVA = DD This field contains the address of the -start of the import lookup table for this image. The address is -relative to the beginning of the Image Base. - -IMPORT ADDRESS TABLE RVA = DD This field contains the address of the -start of the import addresses for this image. The address is -relative to the beginning of the Image Base. - -6.2 Import Lookup Table - -The Import Lookup Table is an array of ordinal or hint/name RVA's for -each DLL. The last entry is empty (NULL) which indicates the end of -the table. - -The last element is empty. - - 3 0 - 1 - ÚÄÒÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³0º ORDINAL#/HINT-NAME TABLE RVA ³ - ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 10. Import Address Table Format - -ORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal -Number or Name Table RVA. -If the import is by ordinal, this field contains a 31 bit ordinal -number. If the import is by name, this field contains a 31 bit -address relative to the Image Base to the Hint-Name Table. - -O = 1-bit (mask = 80000000h) Import by ordinal flag. - - o 00000000h __Import by name. - - o 80000000h __Import by ordinal. - -6.3 Hint-Name Table - -The Hint-Name Table format follows: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ HINT ³ ASCII STRING |||³ - ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´ - ³|||||||||||||||||³ '\0' PAD ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - - - The PAD field is optional. - -Figure 11. Import Hint-Name Table - -HINT = DW Hint into Export Name Table Pointers. -The hint value is used to index the Export Name Table Pointers array, -allowing faster by-name imports. If the hint is incorrect, then a -binary search is performed on the Export Name Ptr Table. - -ASCII STRING = DB ASCII String. -The string is case sensitive and is terminated by a null byte. - -PAD = DB Zero pad byte. -A trailing zero pad byte appears after the trailing null byte if -necessary to align the next entry on an even boundary. - -The loader overwrites the import address table when loading the image -with the 32-bit address of the import. - - - -6.4 Import Address Table - -The Import Address Table is an array of addresses of the imported -routines for each DLL. The last entry is empty (NULL) which indicates -the end of the table. - -7. Thread Local Storage - -Thread local storage is a special contiguous block of data. Each -thread will gets its own block upon creation of the thread. - -The file layout for thread local storage follows: - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ DIRECTORY TABLE ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ TLS DATA ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ INDEX VARIABLE ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ CALLBACK ADDRESSES ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 12. Thread Local Storage Layout - -7.1 Thread Local Storage Directory Table - -The Thread Local Storage Directory Table contains address information -that is used to describe the rest of TLS. - -The Thread Local Storage Directory Table has the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ START DATA BLOCK VA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ END DATA BLOCK VA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ INDEX VA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ CALLBACK TABLE VA ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 13. Thread Local Storage Directory Table - -START DATA BLOCK VA = DD Virtual Address of the start of the thread -local storage data block. - -END DATA BLOCK VA = DD Virtual Address of the end of the thread local -storage data block. - -INDEX VA = DD Virtual Address of the index variable used to access -the thread local storage data block. - -CALLBACK TABLE VA = DD Virtual Address of the callback table. - -7.2 Thread Local Storage CallBack Table - -The Thread Local Storage Callbacks is an array of Virtual Address of -functions to be called by the loader after thread creation and thread -termination. The last entry is empty (NULL) which indicates the end -of the table. - -The Thread Local Storage CallBack Table has the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ FUNCTION1 VA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ FUNCTION2 VA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ NULL ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 14. Thread Local Storage CallBack Table - -8. Resources - -Resources are indexed by a multiple level binary-sorted tree -structure. The overall design can incorporate 2**31 levels, however, -NT uses only three: the highest is TYPE, then NAME, then LANGUAGE. - -A typical file layout for the resource information follows: - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ RESOURCE DIRECTORY ³ - ³ ³ - ³ ³ - ³ ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESOURCE DATA ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ³ ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 15. Resource File Layout - - -The Resource directory is made up of the following tables: - - - -8.1 Resource Directory Table -ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ -³ RESOURCE FLAGS ³ -ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ -³ TIME/DATE STAMP ³ -ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ -³ MAJOR VERSION ³ MINOR VERSION ³ -ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ -³ # NAME ENTRY ³ # ID ENTRY ³ -ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ -³ RESOURCE DIR ENTRIES ³ -ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 16. Resource Table Entry - - -RESOURCE FLAGS = DD Currently set to zero. - -TIME/DATE STAMP = DD Time/Date the resource data was created by the -resource compiler. - -MAJOR/MINOR VERSION = DW A user settable major/minor version number. - -# NAME ENTRY = DW The number of name entries. -This field contains the number of entries at the beginning of the -array of directory entries which have actual string names associated -with them. - -# ID ENTRY = DW The number of ID integer entries. -This field contains the number of 32-bit integer IDs as their names -in the array of directory entries. - -The resource directory is followed by a variable length array of -directory entries. # NAME ENTRY is the number of entries at the -beginning of the array that have actual names associated with each -entry. The entires are in ascending order, case insensitive strings. -# ID ENTRY identifies the number of entries that have 32-bit integer -IDs as their name. These entries are also sorted in ascending order. - -This structure allows fast lookup by either name or number, but for -any given resource entry only one form of lookup is supported, not -both. This is consistent with the syntax of the .RC file and the .RES -file. - - - -The array of directory entries have the following format: - 3 0 - 1 -ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ -³ NAME RVA/INTEGER ID ³ -ÃÄÒÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ -³Eº DATA ENTRY RVA/SUBDIR RVA ³ -ÀÄÐÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 17. Resource Directory Entry - - -INTERGER ID = DD ID. -This field contains a integer ID field to identify a resource. - -NAME RVA = DD Name RVA address. -This field contains a 31-bit address relative to the beginning of the -Image Base to a Resource Directory String Entry. - -E = 1-bit (mask 80000000h) Unescape bit. -This bit is zero for unescaped Resource Data Entries. - -DATA RVA = 31-bits (mask 7fffffffh) Data entry address. -This field contains a 31-bit address relative to the beginning of the -Image Base to a Resource Data Entry. - -E = 1-bit (mask 80000000h) Escape bit. -This bit is 1 for escaped Subdirectory Entry. - -DATA RVA = 31-bits (mask 7fffffffh) Directory entries. -This field contains a 31-bit address relative to the beginning of the -Image Base to Subdirectory Entry. - - - -Each resource directory string entry has the following format: -ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ -³ LENGTH ³ UNICODE STRING ³ -ÃÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄ´ -³ ³ -ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 18. Resource Directory String Entry - - -LENGTH = DW Length of string. - -UNICODE STRING = DW UNICODE String. - -All of these string objects are stored together after the last -resource directory entry and before the first resource data object. -This minimizes the impact of these variable length objects on the -alignment of the fixed size directory entry objects. The length needs -to be word aligned. - - - -Each Resource Data Entry has the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ DATA RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ CODEPAGE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ RESERVED ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 19. Resource Data Entry - - - -DATA RVA = DD Address of Resource Data. -This field contains 32-bit virtaul address of the resource data -(relative to the Image Base). - -SIZE = DD Size of Resource Data. -This field contains the size of the resource data for this resource. - -CODEPAGE = DD Codepage. - -RESERVED = DD Reserved - must be zero. - -Each resource data entry describes a leaf node in the resource -directory tree. It contains an address which is relative to the -beginning of Image Base, a size field that gives the number of bytes -of data at that address, a CodePage that should be used when decoding -code point values within the resource data. Typically for new -applications the code page would be the unicode code page. - - - -8.2 Resource Example - -The following is an example for an app. which wants to use the following data -as resources: - - TypeId# NameId# Language ID Resource Data - 00000001 00000001 0 00010001 - 00000001 00000001 1 10010001 - 00000001 00000002 0 00010002 - 00000001 00000003 0 00010003 - 00000002 00000001 0 00020001 - 00000002 00000002 0 00020002 - 00000002 00000003 0 00020003 - 00000002 00000004 0 00020004 - 00000009 00000001 0 00090001 - 00000009 00000009 0 00090009 - 00000009 00000009 1 10090009 - 00000009 00000009 2 20090009 - -Then the Resource Directory in the Portable format looks like: -Offset Data -0000: 00000000 00000000 00000000 00030000 (3 entries in this directory) -0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28) -0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50) -0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80) -0028: 00000000 00000000 00000000 00030000 (3 entries in this directory) -0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0) -0040: 00000002 00000108 (NameId #2, data desc at offset 0x108) -0048: 00000003 00000118 (NameId #3, data desc at offset 0x118) -0050: 00000000 00000000 00000000 00040000 (4 entries in this directory) -0060: 00000001 00000128 (NameId #1, data desc at offset 0x128) -0068: 00000002 00000138 (NameId #2, data desc at offset 0x138) -0070: 00000003 00000148 (NameId #3, data desc at offset 0x148) -0078: 00000004 00000158 (NameId #4, data desc at offset 0x158) -0080: 00000000 00000000 00000000 00020000 (2 entries in this directory) -0090: 00000001 00000168 (NameId #1, data desc at offset 0x168) -0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0) -00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory) -00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8 -00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8 -00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory) -00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178 -00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188 -00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x198 - -00E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0 - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1 - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1, - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0 - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1 - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) -0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2 - 00000004 (4 bytes of data) - 00000000 (codepage) - 00000000 (reserved) - -And the data for the resources will look like: -01A8: 00010001 -01AC: 10010001 -01B0: 00010002 -01B4: 00010003 -01B8: 00020001 -01BC: 00020002 -01C0: 00020003 -01C4: 00020004 -01C8: 00090001 -01CC: 00090009 -01D0: 10090009 -01D4: 20090009 - - -9. Fixup Table - -The Fixup Table contains entries for all fixups in the image. The -Total Fixup Data Size in the PE Header is the number of bytes in the -fixup table. The fixup table is broken into blocks of fixups. Each -block represents the fixups for a 4K page. - -Fixups that are resolved by the linker do not need to be processed by -the loader, unless the load image can't be loaded at the Image Base -specified in the PE Header. - -9.1 Fixup Block - -Fixup blocks have the following format: - - ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³ PAGE RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ BLOCK SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TYPE/OFFSET ³ TYPE/OFFSET ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TYPE/OFFSET ³ ... ³ - ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ - -Figure 20. Fixup Block Format - -To apply a fixup, a delta needs to be calculated. The 32-bit delta -is the difference between the preferred base, and the base where the -image is actually loaded. If the image is loaded at its preferred -base, the delta would be zero, and thus the fixups would not have to -be applied. Each block must start on a DWORD boundary. The ABSOLUTE -fixup type can be used to pad a block. - -PAGE RVA = DD Page RVA. The image base plus the page rva is added to -each offset to create the virtual address of where the fixup needs to -be applied. - -BLOCK SIZE = DD Number of bytes in the fixup block. This includes the -PAGE RVA and SIZE fields. - -TYPE/OFFSET is defined as: - - 1 1 0 - 5 1 - ÚÄÄÄÄÒÄÄÄÄÄÄÄÄÄÄÄÄ¿ - ³TYPEº OFFSET ³ - ÀÄÄÄÄÐÄÄÄÄÄÄÄÄÄÄÄÄÙ -Figure 21. Fixup Record Format - -TYPE = 4-bit fixup type. This value has the following definitions: - - o 0h __ABSOLUTE. This is a NOP. The fixup is skipped. - - o 1h __HIGH. Add the high 16-bits of the delta to the 16-bit field - at Offset. The 16-bit field represents the high value of a 32- - bit word. - - o 2h __LOW. Add the low 16-bits of the delta to the 16-bit field - at Offset. The 16-bit field represents the low half value of a - 32-bit word. This fixup will only be emitted for a RISC machine - when the image Object Align isn't the default of 64K. - - o 3h __HIGHLOW. Apply the 32-bit delta to the 32-bit field at - Offset. - - o 4h __HIGHADJUST. This fixup requires a full 32-bit value. The - high 16-bits is located at Offset, and the low 16-bits is - located in the next Offset array element (this array element is - included in the SIZE field). The two need to be combined into a - signed variable. Add the 32-bit delta. Then add 0x8000 and - store the high 16-bits of the signed variable to the 16-bit - field at Offset. - - o 5h __MIPSJMPADDR. - -All other values are reserved. - - - -10. Debug Information - -The debug information is defined by the debugger and is not -controlled by the portable EXE format or linker. The only data -defined by the portable EXE format is the Debug Directory Table. - -10.1 Debug Directory - -The debug directory table consists of one or more entries that have -the following format: - - ÚÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ - ³ DEBUG FLAGS ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ TIME/DATE STAMP ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ MAJOR VERSION ³ MINOR VERSION ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ DEBUG TYPE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ DATA SIZE ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ DATA RVA ³ - ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ - ³ DATA SEEK ³ - ÀÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÙ - -Figure 22. Debug Directory Entry - -DEBUG FLAGS = DD Set to zero for now. - -TIME/DATE STAMP = DD Time/Date the debug data was created. - -MAJOR/MINOR VERSION = DW Version stamp. -This stamp can be used to determine the version of the debug data. - -DEBUG TYPE = DD Format type. -To support multiple debuggers, this field determines the format of -the debug information. This value has the following definitions: - - o 0001h __Image contains COFF symbolics. - - o 0001h __Image contains CodeView symbolics. - - o 0001h __Image contains FPO symbolics. - -DATA SIZE = DD The number of bytes in the debug data. This is the -size of the actual debug data and does not include the debug -directory. - -DATA RVA = DD The relative virtual address of the debug data. This -address is relative to the beginning of the Image Base. - -DATA SEEK = DD The seek value from the beginning of the file to the -debug data. - -If the image contains more than one type of debug information, then -the next debug directory will immediately follow the first debug -directory. diff --git a/reactos/doc/internal/readme.txt b/reactos/doc/internal/readme.txt deleted file mode 100644 index b0a4593f171..00000000000 --- a/reactos/doc/internal/readme.txt +++ /dev/null @@ -1,2 +0,0 @@ -This contains documentation describing the internals of the various kernel -subsystems and a few other useful bits of information. diff --git a/reactos/doc/irq.txt b/reactos/doc/irq.txt deleted file mode 100644 index 1a5a17405ed..00000000000 --- a/reactos/doc/irq.txt +++ /dev/null @@ -1,135 +0,0 @@ -** Introduction - -This attempts to document the ReactOS irq handling. As of v0.0.8 this has -changed to be more nt like, I will attempt to summarize the new -implementation for those unavailable with nt device driver writing. Note, -ReactOS doesn't have an exact implementation but the omissions are, except -where noted, not user visible. - -** Steps in grabbing an irq vector - -* Call HalConnectInterrupt - -PROTOTYPE: - -ULONG HalGetInterruptVector(INTERFACE_TYPE InterfaceType, - ULONG BusNumber, - ULONG BusInterruptLevel, - ULONG BusInterruptVector, - OUT PKIRQL Irql, - OUT PKAFFINITY Affinity) - -PURPOSE: - -Translates a bus dependant interrupt vector to a system vector - -ARGUMENTS: - - InterfaceType = Type of bus to which the device to receive interrupts - from is connected to. Currently only 'Internal' is - recognized - BusNumber = Number of the bus the device is connected to - (currently ignored) - BusInterruptLevel = Bus specific interrupt level (currently ignored) - BusInterruptVector = Bus specific vector. Currently this is the same - as the normal vector (09 is the keyboard vector - for example) - Irql = On return contains the DIRQL for the vector - Affinity = On return contains the affinity mask for the vector - (currently unimplemented) - -RETURNS: - The system mapped vector - -* Call IoConnectInterrupt - -PROTOTYPE: - -NTSTATUS IoConnectInterrupt(OUT PKINTERRUPT* InterruptObject, - PKSERVICE_ROUTINE ServiceRoutine, - PVOID ServiceContext, - PKSPIN_LOCK SpinLock, - ULONG Vector, - KIRQL Irql, - KIRQL SynchronizeIrql, - KINTERRUPT_MODE InterruptMode, - BOOLEAN ShareVector, - KAFFINITY ProcessorEnableMask, - BOOLEAN FloatingSave) - -PURPOSE: - -Connect a service routine to an interrupt vector - -ARGUMENTS: - - InterruptObject = Points to an object describes the interrupt on - return - ServiceRoutine = Function to be called when the device interrupts - ServiceContext = Parameters to be passed to the service routine - SpinLock = Should be NULL - Vector = System mapped vector returned from HalGetInterruptVector - Irql = DIRQL returned from HalGetInterruptVector - SynchronizeIrql = Should be the same as Irql - InterruptMode = Device interrupt type (currently ignored) - ShareVector = True if the interrupt vector can shared - ProcessorEnableMask = Currently ignored - FloatingSave = Should be false - -RETURNS: Status - -* Sample code for snarfing an interrupt vector - - - void grab_my_irq() - { - ULONG MappedIrq; - KIRQL Dirql; - KAFFINITY Affinity; - PKINTERRUPT IrqObject; - - MappedIrq = HalGetInterruptVector(Internal, - 0, - 0, - MY_VECTOR, - &Dirql, - &Affinity); - IoConnectInterrupt(&IrqObject, - my_irq_service_routine, - my_context, - NULL, - MappedIrq, - Dirql, - Dirql, - 0, - FALSE, // Not sharable - Affinity, - FALSE); - } - -** Designing an interrupt service routine - -An interrupt service routine should have the following prototype - - BOOLEAN my_irq_service_routine(PKINTERRUPT Interrupt, - PVOID ServiceContext); - -ARGUMENTS: - - Interrupt = The same as the object returned from the - IoConnectInterrupt - ServiceContext = A user defined parameters - (passed to IoConnectInterrupt) - -RETURNS: - - True if it handled the interrupt, false if it should be passed onto - other devices sharing the same vector - -NOTES: - - While an isr is executing all devices of a lower or equal priority - can't interrupt. For this reason it is important that an isr - should complete in a short an interval as possible. The set of - routines an isr can call is also restricted. - diff --git a/reactos/doc/irql.txt b/reactos/doc/irql.txt deleted file mode 100644 index de4ce316a66..00000000000 --- a/reactos/doc/irql.txt +++ /dev/null @@ -1,21 +0,0 @@ -This document describes the state of a uniprocessor PC at each of the IRQ -levels supported by the ReactOS kernel - -PASSIVE_LEVEL: IF bit clear in the processor flags - All irqs umasked at the PIC - -APC_LEVEL: Unknown -WAKE_LEVEL: Unknown - -DISPATCH_LEVEL: IF bit clear in the processor flags - All irqs umasked at the PIC - Thread dispatching disabled - -DIRQL (Device specific IRQ level): - IF bit clear in the processor flags - Device's irq and all lower priority irqs masked at the PIC - Thread dispatching disabled - -HIGH_LEVEL: IF bit set in the processor flags - All irqs masked at the PIC - Thread dispatching disabled diff --git a/reactos/doc/modules.txt b/reactos/doc/modules.txt deleted file mode 100644 index c7bcff51976..00000000000 --- a/reactos/doc/modules.txt +++ /dev/null @@ -1,33 +0,0 @@ -** Introduction - -This is (an incomplete) guide to writing device drivers (and other kernel -extensions) for ReactOS. - -** Setting up the build environment - -Create a new subdirectory in the modules directory and copy one of the -existing module makefiles into it. Customize the makefile to compile the -source files for the module. Note: generally it is not necessary to specify -the compiler or compiler flags to use. - -** Initializing a module - -On loading the kernel will call the module function - -PROTOTYPE: - - NTSTATUS ModuleEntry(PDRIVER_OBJECT DriverObject, - PUNICODE_STRING RegistryPath) - -PURPOSE: - - Initializing the module - -ARGUMENTS: - - DriverObject = Pointer to an object describing the driver - RegistryPath = Currently NULL - -RETURNS: - - STATUS_SUCCESS = If the module initialized successfully diff --git a/reactos/doc/wstring.txt b/reactos/doc/wstring.txt deleted file mode 100644 index 271adcd56dd..00000000000 --- a/reactos/doc/wstring.txt +++ /dev/null @@ -1,16 +0,0 @@ -subject wstring.zip -author Boudewijn Dekker -date 06-06-98 - - -I wrote some inline wide character string functions. It are modified version -of the ones in string.h. I added four more function nl stricmp, strnicmp, -wcsicmp, and wcsnicmp. These are the case insensitive variants of -strcmp, strncmp and wcscmp, wcsncmp. I tested all the functions but I -would urge anyone to tested again. I removed an extern specifier -__wcstok and strtok cause I it caused an compilation error when -using strtok or wcstok. Please could someone see if this correct. -I also used these string functions in lstring api functions. - - -Boudewijn Dekker \ No newline at end of file -- 2.17.1