readme.htm

crackme 源码系列

          /Df - disable loading XM from file
          /Dr - disable loading XM from resource
          /Dl - disable XM_NOLOOP
          /M  - mark & clear unused chunks of
                data in a masm32/tasm compatible dump

Press any key to continue...</font></table></center><p>As you can see, the last parameter is expected to be a filename, specifying the XM file you plan to use in your application. Additional options:<p><b>/Dm</b> produces a hex dump from the given XM file, suitable for using in MASM32 or TASM. Both MASM32 and TASM examples included in the current uFMOD package use such hex dumps instead of regular resources to save some bytes. <b>/Dd</b> and <b>/Dc</b> produce hex dumps in Pascal (Delphi) or C/C++ format respectively. Specify <b>/Di</b> to disable all the information functions: uFMOD_GetStats, uFMOD_GetTitle and uFMOD_GetTime. Removing them reduces the library size and makes it somewhat faster. <b>/Dp</b> removes uFMOD_Pause and uFMOD_Resume functions. If you don't plan to use pause/resume features, add this option to the command line and save some more bytes. uFMOD_SetVolume not only makes the library bigger, but also eats some additional CPU time. Just use <b>/Dv</b> to turn it off and recover some bytes and ticks ;) Not going to play files and/or resources? - An optimization geek uses plain hex dumps instead of resources anyway! Then, you'll probably like to use <b>/Df</b> and <b>/Dr</b> in order to make the library smaller. <b>/Dl</b> (lower-case letter L) makes the library ignore XM_NOLOOP flag (and makes uFMOD smaller and faster, as expected). Finally, a really insane optimization option is available only for MASM32/TASM coders. There are some byte chunks inside every XM file, which are reserved for future use or just holding metadata (comments, adds and so on). <b>/M</b> marks all such 'holes' in the hex dump and makes them available for something more useful, like storing code and/or data right inside the XM track. masm32\winmm example actually uses this feature.<p>On success, Eff produces a file EFF.INC and a hex dump, if requested. Some examples (all correct):<p><b>eff /Dmpvfrl /M example.xm<br>eff /M /Dm /Dp /Dv /Df /Dr /Dl example.xm<br>eff -M -Dmpvfrl example.xm</b><p>The above example commands produce a MASM32/TASM dump with all the 'holes' properly outlined and cleared by default. The EFF.INC header contains the XM effects actually used in the given XM file and some additional flags to disable pause/resume, volume control, file and resource support and XM_NOLOOP. Copy the new EFF.INC to \ufmodlib and recompile the library. Check the <a href='#5'>FAQ</a> section if not familiar with recompiling. Enjoy your own extremely optimized uFMOD build, but remember that it contains a subset of XM effects. So, it will play normally only the given XM file!<p><a name='22'><b><i>XMStrip</i></b></a>, as the name suggests, expects an XM file on input, repacks the file contents to make it smaller, without losing sound quality. Typing <b>xmstrip /h</b> produces the following output:<p><center><table border='0' cellpadding='8'><tr bgcolor='#000000'><td><pre><font color='#008000'> uFMOD XMSTRIP: removes unused data</font><font color='#FFFFFF'>
 USAGE:  xmstrip file [output]
         file   - input file name
         output - optional output file name
 When [output] is not specified, XMSTRIP
 attempts to overwrite the input. If file
 name contains spaces, enclose it in "".

Press any key to continue...</font></table></center><p>Keep in mind, that other XM players whould probably reject a 'stripped' XM file.<p>Usually, using Eff along with XMStrip produces very significant size and speed gain. Just take a look at masm32\minimal.exe file size, which is not even packed or compressed.<p>&nbsp;<br><a name='3'><b>Examples</b></a><p>Compiler-specific usage examples are provided in separate folders. Every example folder contains both WINMM and DirectX projects. Most representative examples contain prebuild executables to show the smallest image size achieved so far. Prebuilt binaries are neither compressed, nor packed.<p><table border='0' cellpadding='4' cellspacing='2' style='font-size:10pt;font-family:Arial,Aerial'><tr bgcolor='#708090' style='color:#E7E7E7;font-weight:bold'><td>Dir<td width='160'>Compiler<td>Contributed by<td>Notes<tr><td>BCB<td>Borland C++ Builder<td><a href='mailto:[e-mail]'>dododo</a><td><tr bgcolor='#E7E7E7' valign='top'><td>Delphi<td>Borland Delphi<td>*<td>Delphi 5 - 7 users should compile the examples via the batch files in order to make the executables a bit smaller. Delphi 9 or later users should build both projects from the IDE only, because some compiler internals used in the BATs changed in later versions.<tr valign='top'><td>Fasm<td>Flat Assembler<td>bogrus, *<td>Pure FASM (no linker) and FASM plus MS Linker or Polink examples provided just to show both ways to build an executable using FASM.<tr bgcolor='#E7E7E7' valign='top'><td>Masm32<td>MASM32<td>*<td>The most complex uFMOD usage samples. The main idea is to place the executable code and data inside (!) the XM stream to reduce the executable image size. Only for real optimization freaks!<tr><td>Nasm<td>Netwide Assembler<td>*<td><tr bgcolor='#E7E7E7'><td>Tasm<td>Borland Turbo Assembler<td>*<td><tr valign='top'><td>PureBasic<td>PureBasic<td><a href='http://flaith.free.fr/'>flaith</a>, chris_b<td>PureBasic version 3.50 or later required. Copy the given PureLibraries to [PureBasic]\PureLibraries\UserLibraries before compiling the projects. An online help for PureBasic uFMOD API is available in the HELP subfolder. Copy the given CHM to [PureBasic]\HELP if you wish to use it from the IDE.<tr bgcolor='#E7E7E7'><td>VisualBasic<td>Visual Basic 6<td>*<td>Read the <a href='..\VisualBasic\Readme\en.txt'>readme file</a> before compiling!<tr valign='top'><td>VisualC<td>Visual C/C++<td>*<td>Minimalistic XM players written in plain C. Load / stop, pause / resume, muting, volume control, playback progress, VU meter and even some DX effects in less than 17Kb!<tr bgcolor='#E7E7E7'><td>BlitzMax<td>BlitzMax<td>*, <a href='http://flaith.free.fr/'>flaith</a><td>Complete documentation <a href='..\BlitzMax\mod\pub.mod\ufmod.mod\doc\commands.html'>provided</a>.<tr valign='top'><td>FreeBASIC<td>FreeBASIC<td>voodooattack, antarman<td>Using a visualization based on Torus by rel.</table><span style='font-size:8pt'>* Quantum, Asterix</span><p>&nbsp;<br><a name='4'><b>Making your exe smaller</b></a><p>Use <a href='#21'>Eff</a> to optimize the library and make it smaller.<p>When embedding the XM track directly into the executable or attaching it as a raw binary resource, it's sometimes worth it trying to optimize the XM itself. There's a freeware opensource set of utilities <a href='http://www.modplug.com/'>Open Modplug Tracker</a> available for authoring, modifying and cleaning up tracker music files. Modplug Player features ADPCM compression, which makes the XM somewhat smaller, but it's a lossy compression! Use <a href='#22'>XMStrip</a> for lossless (in terms of sound quality) size optimization.<p>Try using the undocumented directive <code>/opt:nowin98</code> while linking a Visual C++ or MASM32 project to minimize section alignment. The .rdata section (read-only data, where the IAT and some other constants reside) and .text section (usually contains executable code) could be safely combined together into a single section. Try adding the following directives to MS LINK.EXE or POLINK.EXE command line: <code>/MERGE:.rdata=.text</code><p>There's another MS linker-specific known issue. link.exe attaches some <i>unnecessary</i> data between DOS stub and the beginning of PE header. It's easy to spot the dead weight in a Hex editor - it begins with a magic word 'Rich'. The encoded machine <i>compid</i> follows the magic word. If you don't want your executables being <i>signed</i> this way or just don't like to spend some extra bytes (actually, it's half a Kb!) on the signature, there's a couple of workarounds available. First, you can switch to another linker. Or you can search the web to find an article on patching link.exe. Psst! It's written in russian and available somewhere at wasm.ru.<p>Delphi likes to include a Relocation Table (.reloc section) inside every single executable. That's not required for a typical exe to run (but not a DLL!) and you may safely remove that section. Try using <a href='http://www.jrsoftware.org/striprlc.php'>StripReloc</a> by Jordan Russel, <a href='http://www.uinc.ru/files/index_eng.shtml'>PE Optimizer</a> by Dr. Golova or a similar tool in case you don't know how to remove relocations by hand.<p>Visual Basic and Delphi like to create a Resources section (.rsrc) even if it doesn't contain any useful resources. So, it's usually safe to remove the whole resources section if it doesn't contain forms, XMs or anything your program might really need. The same applies to .flat sections inside PureBasic executables. Be careful while performing this kind of operation on your exe!<p>Packers and exe compressors, such as <a href='http://www.xtreeme.prv.pl/'>FSG</a> and <a href='http://upx.sf.net/'>UPX</a>, make executables smaller. Anyway, to make things fair, the sample executables are not compressed at all!<p>&nbsp;<br><a name='5'><b>FAQ</b></a><p><span style='color:#008080'><b>Q:</b> Is uFMOD free for any type of use? Even commercial?</span><br><b>A:</b> Sure, current version is completely free of charge. Because of that, no warranty could be offered for both commercial and non-profit development. uFMOD is provided AS IS. You don't have to credit uFMOD developers in your application's <i>about</i> box, documentation or anywhere else, if you don't want to.<p><span style='color:#008080'><b>Q:</b> Where can I get XM files from?</span><br><b>A:</b> Try visiting <a href='http://www.modarchive.com/'>The Mod Archive</a>. They have a huge archive of free tracker music in XM, IT, S3M and MOD format. You can use <a href='http://www.modplug.com/'>Open Modplug Tracker</a> to convert IT, S3M and MOD tracks to XM format without degradation. There are many talented composers out there in the web sharing their music at no cost. Just don't forget the copyright!<p><span style='color:#008080'><b>Q:</b> Is uFMOD related in some way to Firelight Technologies&#174; FMOD and miniFMOD sound libraries?</span><br><b>A:</b> Some earlier uFMOD releases were based on the latest miniFMOD public source code release. Since then, library sources had been completely rewritten, many bugs fixed and new features added. So, uFMOD is in no way representative of FMOD and miniFMOD sources.<p><span style='color:#008080'><b>Q:</b> Some XM player libraries claim to add only N kilobytes to the executable file. How many Kb does uFMOD add exactly to the executable's size?</span><br><b>A:</b> It is impossible to tell an exact value, because it depends on library features used (especially, when using the EFF utility), test program code layout, XM file size (when embedding the XM into the EXE). It also depends on the linker options. The MASM32\minimal.exe example is 6.144 bytes. That's currently the smallest uncompressed uFMOD usage example.<p><span style='color:#008080'><b>Q:</b> How to recompile uFMOD (i.e. after using EFF)?</span><br><b>A:</b> To build uFMOD for a particular compiler, open the corresponding batch file in a plain text editor, setup the available options (compiler, target subsystem, mixing rate, Unicode support and so on) and make sure all paths are correct. Run the batch file to build the library.<p><table border='0' cellpadding='4' cellspacing='2' style='font-size:10pt;font-family:Arial,Aerial'><tr bgcolor='#708090' style='color:#E7E7E7;font-weight:bold'><td>BAT<td>Target compiler(s)<td>Notes<tr valign='top'><td>makecoff<td>Visual C/C++, FASM, NASM, MASM32, FreeBASIC<td>FreeBASIC users should rename the output file from *.obj to *.o.<tr bgcolor='#E7E7E7' valign='top'><td>makeomf<td>Borland Delphi, Borland C++ Builder, TASM<td>Borland C++ Builder users should set UFMOD_FMT option to LIB. Delphi and TASM users should set it to OBJ instead.<tr><td>makevb6<td>Visual Basic 6<td><tr bgcolor='#E7E7E7'><td>makepb<td>PureBasic<td><tr><td>makebmod<td>BlitzMax<td></table><p><span style='color:#008080'><b>Q:</b> Compiling the COFF library with MASM32 takes a lot of time. Is that normal?</span><br><b>A:</b> Yes, for some reason MASM32 takes for ages to produce a COFF object when using large sections. That's not a bug anyway. Use FASM or NASM to speed up the compilation process.<p><span style='color:#008080'><b>Q:</b> When will uFMOD support ARM/JVM/SPARC/PowerPC/IA64/x86-64?</span><br><b>A:</b> Actually, there're no plans to support PowerPC and SPARC processors. JVM (Java Virtual Machine) won't become a supported target either. There're not many demos/intros targeting a SPARC or PowerPC based machines. Java intros ain't numerous either ;). An x86-64 port will probably become available someday. An IA64 and ARM whould be less likely to appear, but also possible. By the way, the uFMOD development team encourages porting uFMOD sources to any other platform, operating system or compiler, as long as you release it on an open source basis.<p>&nbsp;<br><a name='6'><b>Thanks go out to</b></a><p>antarman, Barracuda, bogrus, chris_b, cresta, dododo, flaith, Four-F, GL#0M, q_q, SofT MANiAC, S_T_A_S_ and voodooattack.<p><a href='http://wasm.ru'>[WASM.RU]</a> and <a href='http://sf.net'>SourceForge.net</a> for support and hosting.<p>&nbsp;<br><a name='7'><b>Copyright</b></a><p>All trademarks used are properties of their respective owners.<br>uFMOD sources, binaries and utility programs &#169; 2005 - 2006 Asterix and Quantum.<br>The sample tune, Minimal III &#169; 2006 SofT MANiAC (CoolPHat).<br>All rights reserved.<p>Found a bug? Got a question or a suggestion? Starting to develop a cool application using uFMOD? Please, let us know: <a href='mailto:[e-mail]'>[e-mail]</a></div></body></html>