Removed obsolete documentation
authorDavid Welch <welch@cwcom.net>
Sun, 17 Jan 1999 17:18:35 +0000 (17:18 +0000)
committerDavid Welch <welch@cwcom.net>
Sun, 17 Jan 1999 17:18:35 +0000 (17:18 +0000)
svn path=/trunk/; revision=175

13 files changed:
reactos/doc/api.txt [deleted file]
reactos/doc/buglist [deleted file]
reactos/doc/cacheman.txt [deleted file]
reactos/doc/ddkfuncs.txt [deleted file]
reactos/doc/debug.txt [deleted file]
reactos/doc/faq.txt [deleted file]
reactos/doc/internal/mm.txt [deleted file]
reactos/doc/internal/pe.txt [deleted file]
reactos/doc/internal/readme.txt [deleted file]
reactos/doc/irq.txt [deleted file]
reactos/doc/irql.txt [deleted file]
reactos/doc/modules.txt [deleted file]
reactos/doc/wstring.txt [deleted file]

diff --git a/reactos/doc/api.txt b/reactos/doc/api.txt
deleted file mode 100644 (file)
index 4dd8408..0000000
+++ /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 (file)
index 096fb3e..0000000
+++ /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 (file)
index 7b6d79f..0000000
+++ /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 (file)
index c0bcace..0000000
+++ /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 (file)
index 28467c6..0000000
+++ /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 (file)
index 1fe8c22..0000000
+++ /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 (file)
index 880bee0..0000000
+++ /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 (file)
index aeafa65..0000000
+++ /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 (file)
index b0a4593..0000000
+++ /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 (file)
index 1a5a174..0000000
+++ /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 (file)
index de4ce31..0000000
+++ /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 (file)
index c7bcff5..0000000
+++ /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 (file)
index 271adcd..0000000
+++ /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