Changeset 252

Show
Ignore:
Timestamp:
04/02/07 11:03:29 (1 year ago)
Author:
aldacron
Message:

[Docs]
* tweaked the style sheet to make code snippets easier on the eyes
* updated/clarified/corrected/cleaned up the the following documentation files:
credit.html
index_a.html
loading.html
selective.html
terms.html

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • trunk/docs/credit.html

    r209 r252  
    1313<h3>Credit Where Credit is Due</h3> 
    1414<blockquote> 
    15 When I first started Derelict, I did it because it was something I needed. I  
    16 decided to make it available to the D community at large in case other D  
    17 programmers found a need for it also. I never really expected that anyone would.  
    18 Thus, it was surprising to learn that not only were people using it, but they  
    19 were willing to contribute to it!  
     15When I first started Derelict, I did it because it was something I needed. I 
     16decided to make it available to the D community at large in case other D 
     17programmers found a need for it also. I never really expected that anyone would. 
     18Thus, it was surprising to learn that not only were people using it, but they 
     19were willing to contribute to it! 
    2020<p> 
    2121Contributions have come in various forms: bug reports, bug fixes, new ports, 
    2222and advice. For the first year of Derelict's existence, I did not maintain a 
    2323list of contributors. But, most everyone is on record in the forums (or my email 
    24 box). Names in parentheses are the handles on either the Derelict forums or the  
     24box). Names in parentheses are the handles on either the Derelict forums or the 
    2525D newsgroups (D NGs). If I missed anyone, forgive me! 
    2626</blockquote> 
     
    3737</ul> 
    3838</p><p> 
    39 <b>Package Creators</b> - people who have created the initial versions of current Derelict packages<br> 
     39<b>Package Creators</b> - people who have created the initial versions of past 
     40and current Derelict packages<br> 
    4041<ul> 
    41 <li>Michael Parker (Aldacron) - DerelictGL, DerelictGLU, DerelictSDL, DerelictAL,  
     42<li>Michael Parker (Aldacron) - DerelictGL, DerelictGLU, DerelictSDL, DerelictAL, 
    4243DerelictSDLImage, DerelictSDLNet</li> 
    4344<li>John Reimer (JJR) - DerelictGLFW, DerelictFT</li> 
     
    4950</ul> 
    5051</p><p> 
    51 <b>Bug Reporters/Bug Fixers</b> - people (other than the maintainers), who have  
    52 submitted bug reports and/or fixes (in no particular order)<br> 
     52<b>Contributers</b> - people (other than the maintainers), who have submitted 
     53bug reports, fixes, and enhancements in order to make Derelict what it has 
     54become (in no particular order)<br> 
    5355<ul> 
    54 <li>Clay Smith (clayasaurus) - has caught numerous bugs and made several fixes;  
    55 did a lot of work getting Derelict on Linux before John came in</li> 
    56 <li>Justin Calvarese (jcc7) - took some of my crashing Derelict code and narrowed it down to 
    57 the minimal case so that we could report a DMD bug to Walter</li> 
    58 <li>Miguel Ferreira Simões - caught and fixed a major DerelictGL bug</li> 
    59 <li>Sebastian Beschke (randomZ) - reported an access violation in DerelictGL;  
    60 submitted some DerelictSDLttf fixes.</li> 
    61 <li>??? (xicesky) - submitted a fix for a bug in DerelictSDLMixer</li> 
    62 <li>Trevor Parscal - reported conflicts between DerelictGL and external Win32 GDI bindings</li> 
    63 <li>Eric Poggel (JoeCoder) - fixed a bug with buildme.d on Linux; reported some DerelictGL bugs</li> 
    64 <li>??? (silvestre) - fixed a bug with OpenGL version handling</li> 
    65 <li>??? (lindquist) - added some missing OpenGL 1.4 declarations</li> 
    66 <li>??? (odeamus) - reported missing declarations in DerelictFT; reported typo in DerelictGL</li> 
     56<li>Clay Smith (clayasaurus)</li> 
     57<li>Justin Calvarese (jcc7)</li> 
     58<li>Miguel Ferreira Simões</li> 
     59<li>Sebastian Beschke (randomZ)</li> 
     60<li>??? (xicesky)</li> 
     61<li>Trevor Parscal</li> 
     62<li>Eric Poggel (JoeCoder)</li> 
     63<li>??? (silvestre)</li> 
     64<li>??? (lindquist)</li> 
     65<li>??? (odeamus)</li> 
     66<li>Lucas Goss (lgoss007)</li> 
     67<li>Matti Niemenmaa (Deewiant)</li> 
     68<li>Anders F Björklund (afb)</li> 
     69<li>James Pelcis (jpelcis</li> 
     70<li>Eric Poggel (JoeCoder)</li> 
     71<li>William R. DeVore (quartz)</li> 
     72<li>??? (volcore)</li> 
     73<li>Paolo Invernizzi</li> 
     74<li>??? (demise)</li> 
     75<li>??? (wct)</li> 
    6776</ul> 
    6877</p><p> 
    69 <b>Other Contributors</b> - people who contributed enhancements/improvements that 
    70 weren't bug fixes. 
    71 <ul> 
    72 <li>Lucas Goss (lgoss007) - implemented and submitted build scripts for Linux (which 
    73 have been superseded by the new build system - but thanks anyway!)</li> 
    74 <li>Matti Niemenmaa (Deewiant) - updated DerelictGLFW to work with GLFW 2.5</li> 
    75 <li>Anders F Björklund (afb) - submitted a patch to derelict.util.loader to make it work with GDC.</li> 
    76 <li>James Pelcis (jpelcis) - submitted up to date versions of DerelictSDLImage, DerelictSDLMixer,  
    77 DerelictSDLNet, and DerelictSDLttf. 
    78 <li>Eric Poggel (JoeCoder) - knocked up the initial version of the documentaion style sheet.</li> 
    79 <li>??? (lindquist) - added support for some OpenGL extensions</li> 
    80 <li>William R. DeVore (quartz) - added support for GL_ATI extensions</li> 
    81 </ul> 
     78If your handle is listed next to a '???', please let me know your name and I'll 
     79fill it in. 
    8280</p><p> 
    83 <b>Derelict's Little Helpers</b> - people (other than the maintainers) who have 
    84 been extremely helpful to new Derelict users on the forums and the D NGs<br> 
    85 <ul> 
    86 <li>Clay Smith (clayasaurus)</li> 
    87 </ul> 
    88 </p><p> 
    89 <b>Misc.</b> - people who have influenced the development of Derelict in a  
     81<b>Misc.</b> - people who have influenced the development of Derelict in a 
    9082profound way.<br> 
    9183<ul> 
  • trunk/docs/index_a.html

    r219 r252  
    1313Derelict is a collection of D bindings to C shared (dynamic) libraries which are 
    1414useful for multimedia applications, with a heavy bias toward libraries commonly 
    15 used in game development. Derelict currently includes bindings for the following  
     15used in game development. Derelict currently includes bindings for the following 
    1616libraries: 
    1717 
     
    3232<p> 
    3333 
    34 Over the past few years, D bindings for some of the above libraries have been created  
     34Over the past few years, D bindings for some of the above libraries have been created 
    3535as part of other projects. One thing all of the existing bindings had in common 
    3636was that they required users to statically link to import libraries. None of the 
    3737bindings were designed to allow a user to manually load libraries via an operating 
    3838system API (such as LoadLibrary/GetProcAddress on Windows, or libdl on Linux and 
    39 Mac). Linking to a shared library's static import library is not a bad thing,  
     39Mac). Linking to a shared library's static import library is not a bad thing, 
    4040but having the option to load a shared library manually allows the developer a 
    4141great deal more flexibility - particularly when things go wrong. 
     
    4747you wish to link with, then you need to go through the step of converting the 
    4848library to the proper format, or, if the library's source is available, compile 
    49 the library with a compiler that outputs the proper object format (currently,  
     49the library with a compiler that outputs the proper object format (currently, 
    5050this is only an issue on Windows when using the DMD tools). This is only a minor 
    5151annoyance that can usually be handled once and forgotten about until you upgrade 
    52 to a new version of a library. But, there is a more serious issue with static  
     52to a new version of a library. But, there is a more serious issue with static 
    5353import libraries in that they lack flexibility and robustness. 
    5454</p><p> 
     
    5858fail to load and the operating system will display an error message to the user. 
    5959This could also occur if the only version of a shared library available on the 
    60 user's system is older than the version of the static import library. The  
     60user's system is older than the version of the static import library. The 
    6161error message displayed may not be very user-friendly. Some users who do not 
    6262understand the concepts behind the error message could become frustrated with 
    63 you, the developer, and may even view you as unprofessional. When it comes to  
     63you, the developer, and may even view you as unprofessional. When it comes to 
    6464software, there is no such thing as one-size-fits-all. A large company like Adobe, 
    6565or someone making free software, may not find such errors a concern. A solo 
     
    8888<h4>Special Features</h4> 
    8989Derelict goes one step further and allows selective loading of shared library 
    90 symbols. This gives you the freedom to do things like falling back to older  
     90symbols. This gives you the freedom to do things like falling back to older 
    9191versions of a shared library when a current version is not available. For example, 
    9292if a particular Derelict package is setup to load version 2 of a shared library, 
    9393but your application does not use any exported functions or variables that are 
    94 specific to version 2, then you can use selective symbol loading to allow  
     94specific to version 2, then you can use selective symbol loading to allow 
    9595version 1 of the shared library to be loaded if version 2 fails to load. 
    9696</p><p> 
     
    9898of manually loading libraries, other features (such as <a href="selective.html"> 
    9999selective symbol exceptions</a>) are provided through the DerelictUtil package. 
    100 As a side effect, all Derelict packages have an implicit dependency upon DerelictUtil.  
     100As a side effect, all Derelict packages have an implicit dependency upon DerelictUtil. 
    101101This means that when compiling any individual packages, DerelictUtil <b>must</b> 
    102 be available on the import path, and when linking, DerelictUtil <b>must be</b>  
     102be available on the import path, and when linking, DerelictUtil <b>must be</b> 
    103103linked into the application. See the <a href="util.html">DerelictUtil documentation</a> 
    104104for more details. 
     
    106106<h4>The Future</h4> 
    107107Derelict has grown quite a bit since its humble beginnnings as OpenGL and SDL 
    108 bindings created by one guy as a hobby project. Users have contributed a number  
    109 of packages, bugfixes and improvements over the project's lifetime. The build  
     108bindings created by one guy as a hobby project. Users have contributed a number 
     109of packages, bugfixes and improvements over the project's lifetime. The build 
    110110system has been overhauled twice. The internal loading system has been rewritten 
    111 twice. Other packages are waiting in the wings to be added somewhere down the  
     111twice. Other packages are waiting in the wings to be added somewhere down the 
    112112road. Most importantly, the user community has continued to grow. 
    113113<p> 
    114 Because of Derelict's success, it must continue to evolve and grow. As the number 
    115 of Derelict users increases, so does the variety of project requirements. Derelict 
    116 was started because other bindings forced users to statically link to an import  
    117 library. To date, Derelict has forced users to load import libraries manually. 
    118 The reality is that such an approach goes against the idea of flexibility that 
    119 Derelict was built on in the first place. In order to really satisfy as many  
    120 users as possible, all Derelict packages will ultimately be configurable to  
    121 allow static import library linkage (though not static library linkage -  
    122 see <a href="terms.hmtl">this page</a> for clarification of the terminology).  
    123 This feature is experimentally implemented in <a href="al.html">DerelictAL</a>. 
    124 </p><p> 
    125114More users also means more demand for new Derelict packages. Rather than adding 
    126115just any old binding to Derelict, there must be some guidelines in place to 
    127116keep things under control. The following (loose) criteria are used to determine 
    128 the fitness of bindings to any given library for inclusion in the Derelict trunk. 
     117the fitness of bindings to any given library for inclusion in the Derelict trunk: 
    129118 
    130 <h4 id="criteria">Criteria for Adding a Package to Derelict</h4> 
    131119<ul> 
    132120<li>is the library useful for games or other multimedia applications?</li> 
     
    142130its chances for inclusion into Derelict are high. While the given criteria are 
    143131not etched in stone and anything is possible, you can be certain that no library 
    144 licensed under the <a href="http://www.gnu.org/copyleft/gpl.html">GPL</a> will  
    145 ever make it into Derelict. 
     132licensed under the <a href="http://www.gnu.org/copyleft/gpl.html">GPL</a> will 
     133ever make it into Derelict. Keeping Derelict free of viral licenses like the GPL 
     134allows users to make their own decision about whether or not to open their source, 
     135rather than requiring them to do so. 
    146136</p><p> 
    147137If a particular library you want to use is not currently in Derelict, you can 
     
    150140forums</a> that it be included. Even if your work is not officially added 
    151141to the trunk, you are still free to use it yourself or even distribute it as 
    152 a separate package from your own website. Read <a href="derelictify.html">Aldacron's  
    153 Guide to Derelictification</a> for instructions on how to create your own  
     142a separate package from your own website. Read <a href="derelictify.html">Aldacron's 
     143Guide to Derelictification</a> for instructions on how to create your own 
    154144Derelict packages. 
    155145</p> 
    156146<h4>The Docs</h4> 
    157 The documents linked in the first section below give a general overview of  
     147The documents linked in the first section below give a general overview of 
    158148Derelict, explaining functionality common to all Derelict packages. The 
    159 documents linked in the second section give specific details on building and using 
     149documents linked in the second section give details on building and using 
    160150specific packages. 
    161151</p> 
  • trunk/docs/loading.html

    r195 r252  
    1111<hr> 
    1212<h3>Introduction</h3> 
    13 All Derelict packages are interface to C shared libraries. No package in Derelict 
    14 is designed to work with static C libraries. By default, Derelict packages are 
    15 designed to load shared libraries manually. If you use the manual loading system, 
    16 which is the most flexible way to use Derelict, then the instructions on this 
    17 page apply to you. The interface is the same for all packages in Derelict, so these 
    18 instructions apply to each package. Any exceptions will be noted in the package 
    19 documentation. 
     13All Derelict packages are bindings to C shared libraries. No package in Derelict 
     14is designed to work with static C libraries. The interface for loading and 
     15unloading shared libraries is the same for all packages in Derelict, so the 
     16instructions on this page apply to each package. However, some libraries may have 
     17special features that require more than the common loader interface. Any such 
     18exceptions will be noted in the documentation for those packages. 
    2019 
    2120<h3>Derelict's Common Loader Interface</h3> 
    22 Shared libraries are loaded in Derelict through a common interface. You are 
    23 probably already aware of Derelict's package naming convention. Each package nam
    24 is a combination of Derelict with some form of the name of the library the  
    25 package binds with. No matter what form of the library name is used, the Derelict 
    26 package name is the same throughout all documentation and code related to that 
    27 package. DerelictGL is always referred to as DerelictGL. If you aren't sure about 
    28 a package name, look at the documentation list at the bottom of the 
    29 <a href="index_a.html">front page</a>. All of the package document titles in  
     21You are probably already aware of Derelict's package naming convention. Each 
     22package name is a combination of 'Derelict' with some form of the name of th
     23library the package binds with. No matter what form of the library name is used, 
     24the Derelict package name is the same throughout all documentation and code 
     25related to that package. For example, DerelictGL is always referred to as 
     26'DerelictGL'. If you aren't sure about a package name, look at the documentation 
     27list at the bottom of the 
     28<a href="index_a.html">front page</a>. All of the package document titles in 
    3029that list correlate to Derelict package names. 
    3130</p><p> 
     
    3736</p> 
    3837<h4>Loading</h4> 
    39 The important thing to remember about loading is that  
     38The important thing to remember about loading is that 
    4039<span class="important">a package's load method must be called before any functions 
    41 from the bound library can be used</span>. If you tried to use an OpenGL function 
    42 without first calling DerelictGL.load(), you would find yourself with an access 
    43 violation. When manually loading shared libraries, the library interface consists of function 
    44 pointers. The load method pulls the shared library in to memory and points all 
    45 of the function pointers to the proper memory location. Until then, the function 
     40from the bound library can be used</span>. If you tried to use a library function 
     41without first calling the load method for that package, you would find yourself 
     42with an access violation. The library interface consists of function pointers. 
     43The load method pulls the shared library in to memory and points each function 
     44pointer to the address of the appropriate function. Until that time, the function 
    4645pointers are all null. 
    4746<p> 
    48 As an example, if you were using DerelictGL, you would use the following 
    49 syntax to load the OpenGL shared library: 
     47As an example, if you were using DerelictSDL, you would use the following 
     48syntax to load the SDL shared library: 
    5049 
    5150<pre> 
    52 DerelictGL.load(); 
     51DerelictSDL.load(); 
    5352</pre> 
    5453 
    55 From that point onward you would be able to use all OpenGL functions normally. 
     54From that point onward you would be able to use all SDL functions normally. 
    5655</p><p> 
    5756The load method accepts an optional shared library name string parameter that will 
     
    6059a hardware accelerated version of OpenAL, some do not. You may want to ship the 
    6160OpenAL dll with your app, but renamed to something like "myopenal.dll", or perhaps 
    62 with the same name but in a subdirectory of the application directory ("al/openal32.dll").  
    63 If the <tt>DerelictAL.load()</tt> fails, then you can call  
     61with the same name but in a subdirectory of the application directory ("al/openal32.dll"). 
     62If the <tt>DerelictAL.load()</tt> fails, then you can call 
    6463<tt>DerelictAL.load("myopenal.dll")</tt> instead. This is important because 
    6564Windows (and other OSes) will look in the application's directory for a given 
    6665shared library before looking in system directories. If you were to drop openal32.dll 
    67 in your application's directory, it would be loaded every time. This technique 
    68 can be used for every Derelict package, not just DerelictAL. 
     66in your application's directory, that version would be loaded every time and any 
     67hardware accelerated version in the system directories would be ignored. This 
     68technique can be used for every Derelict package, not just DerelictAL. 
    6969</p><p> 
    7070Sometimes, loads fail. There are several root causes for this, the end result 
    71 being either that the system couldn't find the shared library or one of the  
     71being either that the system couldn't find the shared library or that one of the 
    7272functions Derelict expected to find in the library wasn't there. In either 
    7373case, the load method will throw an exception. You can read more about Derelict 
     
    7878 
    7979<h4>Unloading</h4> 
    80 Unloading a shared library uses the same syntax, but you call the unload method 
    81 instead: 
     80Unloading a shared library uses the same syntax as when loading, but you call 
     81the <tt>unload</tt> method instead: 
    8282 
    8383<pre> 
    84 DerelictGL.unload(); 
     84DerelictSDL.unload(); 
    8585</pre> 
    8686 
    8787In normal usage of Derelict, <span class="important">you do not need to unload 
    8888any of the shared libraries</span>. Derelict will do this for you automatically. 
    89 The unload method is provided as a convenience for those who want to implement  
    90 hot swapping or want to free up memory if a library is no longer needed during  
     89The <tt>unload</tt> method is provided as a convenience for those who want to implement 
     90hot swapping or want to free up memory if a library is no longer needed during 
    9191execution. 
    9292</p> 
     93 
     94<h4>Note For Linux/Mac Users</h4> 
     95On Linux and Mac, there is one additional dependency that must be linked into 
     96your executable: libdl. On Windows, the functions used to load shared libraries 
     97are part of the core libraries linked automatically during compilation. On other 
     98platforms, this is not the case. So any time you compile a Derelict application 
     99on Linux or Mac, regardless of whether you are using DMD or GDC, you must link 
     100to libdl. Otherwise, compilation will fail with symbol errors. 
    93101 
    94102 
  • trunk/docs/selective.html

    r197 r252  
    2929 
    3030<p> 
    31 When a symbol fails to load, Derelict first checks if a MissingProcCallback has 
    32 been set. If it has, then the callback is called with the name of the library 
     31When a symbol fails to load, Derelict first checks if a <tt>MissingProcCallback</tt> 
     32has been set. If it has, then the callback is called with the name of the library 
    3333and the name of the missing symbol as arguments. If a callback has not been set, 
    3434then a <tt>SharedLibProcLoadException</tt> is thrown instead. Callbacks can be 
     
    3737<p> 
    3838Following is a complete example of using this feature. Older versions of SDL 
    39 did not include functions to test for CPU capabilities.  
     39did not include functions to test for CPU capabilities. 
    4040<a href="sdl.html">DerelictSDL</a> always attempts to load those functions since 
    4141they are present in the latest versions. It is possible to load older versions 
     
    5252bool myMissingProcCallback(char[] libName, char[] procName) 
    5353{ 
    54     // there are 8 functions as part of SDL's CPU interface - test for them all. 
     54    // there are 8 functions in SDL's CPU interface - test for them all. 
    5555    // If the procName matches any one of them, return true to ignore the missing 
    5656    // function. 
     
    6464        procName.cmp("SDL_HasAltiVec") == 0) 
    6565            return true;        // ignore the error and throw no exception 
    66              
     66 
    6767    // a function other than one of those above failed to load - return false 
    6868    // to indicate that an exception should be thrown. 
    69     return false;   
     69    return false; 
    7070} 
    7171 
     
    7575   Derelict_SetMissingProcCallback(&myMissingProcCallback); 
    7676   DerelictSDL.load(); 
    77 }  
     77} 
    7878</pre> 
    7979 
     
    8989</p> 
    9090<p> 
    91 <span class="important">This is an optional feature and is not required to use  
    92 Derelict</span>. It is provided to give an even greater degree of flexibility  
    93 and control to those who need it.  
     91<span class="important">This is an optional feature and is not required to use 
     92Derelict</span>. It is provided to give an even greater degree of flexibility 
     93and control to those who need it. 
    9494</p> 
    9595 
  • trunk/docs/styles.css

    r158 r252  
    1111 
    1212/* no margins at the edge of the page */ 
    13 body{   
     13body{ 
    1414    font-family     : Verdana, Helvetica, sans-serif; 
    1515    font-size       : 11pt; 
     
    2121/* Decrease border above and below list */ 
    2222ul { 
    23     margin-top      : 0.25em;   
     23    margin-top      : 0.25em; 
    2424} 
    2525 
     
    2727pre { 
    2828    color           : #000080; 
    29     background-color: #F8F8FF
     29    background-color: #BBB
    3030    font-weight     : bold; 
    3131} 
     
    3838 
    3939/* headers */ 
    40 h2 {    
     40h2 { 
    4141    font-family     : Verdana, Helvetica, sans-serif; 
    4242    font-size       : 20pt; 
     
    6060 
    6161ul { 
    62     background-color: #EEEEEE;  
     62    background-color: #EEEEEE; 
    6363} 
    6464 
    6565blockquote { 
    66     font-style: italic;     
     66    font-style: italic; 
    6767} 
    6868 
  • trunk/docs/terms.html

    r195 r252  
    1212 
    1313<h3>Introduction</h3> 
    14 When discussing Derelict in the  
     14When discussing Derelict in the 
    1515<a href="http://www.dsource.org/forums/viewforum.php?f=19&sid=d6f86cfb804d7c8727af1f58cd327d2c">project forums</a> 
    16 or elsewhere, it is important to understand the terminology that often surfaces  
     16or elsewhere, it is important to understand the terminology that often surfaces 
    1717in such discussions. This will also be helpful in better understanding the Derelict 
    18 documentation. Following is a list of terms which could potentially be misunderstood  
     18documentation. Following is a list of terms which could potentially be misunderstood 
    1919and their meaning when used in relation to Derelict. 
    2020 
     
    2323loaded at run time and can be used simultaneously by multiple programs. On Windows, 
    2424such libraries are referred to as "Dynamic Link Libraries", or "DLLs", and have 
    25 the .dll file extension. On Linux, such libraries are referred to as "Shared 
    26 Object Libraries" or "Shared Objects" and have the file extension of .so. 
     25the .dll file extension. On Linux and other Unix-like platforms, such libraries 
     26are referred to as "Shared Object Libraries" or "Shared Objects" and have the 
     27file extension of .so. This also includes the "Frameworks" found on Mac. 
    2728 
    2829<p> 
     
    3536Static libraries are the traditional form of distribution for archived object 
    3637files. On Windows, such libraries are called "Libraries" and have the extension 
    37 .lib. On Linux, such libraries are called "object archives", "archives",  
    38 "libraries", and several other terms, all of which have the file extension 
    39 .a and usually have the prefix "lib" prepended to the file name. 
     38.lib. On Linux and other Unix-like platforms, such libraries are called "object 
     39archives", "archives", "libraries", and several other terms, all of which have 
     40the file extension .a and usually have the prefix "lib" prepended to the file 
     41name. 
    4042 
    4143<p> 
     
    4648 
    4749<h4>Import Libraries, or Static Import Libraries</h4> 
    48 An import library is a library which automates the process of loading a shared  
    49 library. On Windows, when you create a DLL the compiler also creates a static  
    50 library by the same name. This library is the DLL's import library. By compiling  
    51 this library into your executable, the application will be bound to the DLL and  
    52 the DLL will be loaded at run time by the OS.  
     50An import library is a library which automates the process of loading a shared 
     51library. On Windows, when you create a DLL most compilers also create a static 
     52library by the same name. This library is the DLL's import library. By compiling 
     53this library into your executable, the application will be bound to the DLL and 
     54the DLL will be loaded at run time by the OS. 
    5355<p> 
    54 Linux has the same concept, but handles it differently. Rather than link to a separate, 
    55 static import library, you link to the .so itself. In otherwords, the .so doubles 
    56 as a shared library and as an import library. Even though you are linking to the 
    57 .so at compile time, the library itself is still loaded at run time. 
     56Linux and other Unix-like platforms handle this differently. Rather than link 
     57to a separate, static import library, you link to the .so itself. In otherwords, 
     58the .so doubles as a shared library and as an import library. Even though you 
     59are linking to the .so at compile time, the library itself is still loaded at 
     60run time. 
    5861</p> 
    5962 
     
    7982method of loading a shared library at run time: you do not link with an import 
    8083library and, instead, load the shared library programmatically through 
    81 operating system API calls. This is Derelict's default mode of operation and 
    82 is the reason why you must call methods like Derelict*.load(). 
     84operating system API calls. This is Derelict's mode of operation and is the 
     85reason why you must call methods like Derelict*.load(). 
    8386</body> 
    8487</html>