WINEDUMP(1)

✨ WINEDUMP(1) ✨

okay bestie, gather round, because this is the Wine Developers Manual entry for winedump and it's literally the Swiss Army knife of Wine DLL tooling πŸ’…


🌸 NAME 🌸

winedump β€” the Wine DLL tool. that's it, that's the name, short and iconic πŸ‘‘


πŸŽ€ SYNOPSIS πŸŽ€

winedump [-h | sym sym | spec dll | dump file ] [mode_options]

one line, four vibes. pick your mode, live your truth ✨


πŸ’– DESCRIPTION πŸ’–

so winedump is a Wine tool and it's here to help you with two big quests:

  • A: reimplementing a Win32 DLL so it works inside Wine, or
  • B: compiling a Win32 application with Winelib that uses x86 DLLs

for both of those missions, you need a little something called glue code so you can actually link to the Win functions. and this "glue" arrives in the form of a .spec file 🫢 that .spec file, plus some dummy code, gets used to create a Wine .so that corresponds to the Windows DLL. then the winebuild program can resolve calls made to DLL functions. no cap.

making a .spec file is a labour intensive task, and it is so easy to make a mistake while you're doing it (😭 we've all been there). the whole idea of winedump is to automate that task and generate the majority of the support code your DLL needs. plus β€” bonus β€” you can have winedump create code that helps you re-implement a DLL, by giving you tracing of calls to the DLL, and (in some cases) automatically figuring out the parameters, calling conventions and return values of the DLL functions. it's giving genius behavior, fr fr.

another use for this tool: displaying (dumping) information about a 32bit DLL or PE format image file. when you use it like that, winedump functions similarly to tools such as pedump provided by many Win32 compiler vendors. same energy, different girl πŸ’…

and finally β€” yes there's more β€” winedump can also be used to demangle C++ symbols. multitasking queen. πŸ‘‘


🌈 MODES 🌈

winedump can be used in several different modes, and the first argument to the program is what decides which mode you're in. choose wisely, bestie ✨

  • -h β€” Help mode. basic usage help gets printed.
  • dump β€” to dump the contents of a file.
  • spec β€” for generating .spec files and stub DLLs.
  • sym β€” Symbol mode. used to demangle C++ symbols.

πŸ‘‘ OPTIONS πŸ‘‘

the mode options depend on the mode you gave as the first argument. iykyk.

πŸ¦‹ Help mode

no options are used here. the program prints the help info and then exits. short and sweet, we love a low-maintenance icon πŸŽ€

πŸ“ Dump mode

  • file β€” dumps the contents of file. various file formats are supported: PE, NE, LE, Minidumps, .lnk.
  • -C β€” turns on symbol demangling.
  • -f β€” dumps file header information. this option dumps only the standard PE header structures, along with the COFF sections available in the file.
  • -j dir_name β€” dumps only the content of directory dir_name, for files whose header points to directories. for PE files, the import, export, debug, resource, tls, loadcfg, clr, reloc and except directories, as well as the apiset section, are implemented. for NE files, the export and resource directories are implemented.
  • -x β€” dumps everything. this command prints all available information (including all available directories β€” see the -j option) about the file. you may wish to pipe the output through more/less or into a file, since a lot of output will be produced 🫠 like, a lot lot.
  • -G β€” dumps contents of debug section if any (for now, only stabs information is supported).

πŸ’œ Spec mode

  • dll β€” use dll for input file and generate implementation code.
  • -I dir β€” look for prototypes in dir (implies -c). in the case of Windows DLLs, this could be either the standard include directory from your compiler, or a SDK include directory. if you have a text document with prototypes (such as documentation) that can be used also, however you may need to delete some non-code lines to ensure that prototypes are parsed correctly. the dir argument can also be a file specification (e.g. include/*). if it contains wildcards you must quote it to prevent the shell from expanding it. if you have no prototypes, specify /dev/null as dir. winedump may still be able to generate some working stub code for you.
  • -c β€” generate skeleton code (requires -I). this option tells winedump to create function stubs for each function in the DLL. as winedump reads each exported symbol from the source DLL, it first tries to demangle the name. if the name is a C++ symbol, the arguments, class and return value are all encoded into the symbol name. winedump converts this information into a C function prototype. if this fails, the file(s) specified in the -I argument are scanned for a function prototype. if one is found it is used for the next step of the process, code generation. slay πŸ’…
  • -t β€” TRACE arguments (implies -c). this option produces the same code as -c, except that arguments are printed out when the function is called. structs that are passed by value are printed as "struct", and functions that take variable argument lists print "...".
  • -f dll β€” forward calls to dll (implies -t). this is the most complicated level of code generation. the same code is generated as -t, however support is added for forwarding calls to another DLL. the DLL to forward to is given as dll.
  • -D β€” generate documentation. by default, winedump generates a standard comment at the header of each function it generates. passing this option makes winedump output a full header template for standard Wine documentation, listing the parameters and return value of the function.
  • -o name β€” set the output dll name (default: dll). by default, if winedump is run on DLL foo, it creates files foo.spec, foo_main.c etc, and prefixes any functions generated with FOO_. if -o bar is given, these will become bar.spec, bar_main.c and BAR_ respectively. this option is mostly useful when generating a forwarding DLL.
  • -C β€” assume __cdecl calls (default: __stdcall). if winebuild cannot determine the calling convention, __stdcall is used by default, unless this option has been given. unless -q is given, a warning will be printed for every function that winedump determines the calling convention for and which does not match the assumed calling convention.
  • -s num β€” start prototype search after symbol num.
  • -e num β€” end prototype search after symbol num. by passing the -s or -e options you can have winedump try to generate code for only some functions in your DLL. this may be used to generate a single function, for example, if you wanted to add functionality to an existing DLL.
  • -S symfile β€” search only prototype names found in symfile. if you want to only generate code for a subset of exported functions from your source DLL, you can use this option to provide a text file containing the names of the symbols to extract, one per line. only the symbols present in this file will be used in your output DLL.
  • -q β€” don't show progress (quiet). no output is printed unless a fatal error is encountered.
  • -v β€” show lots of detail while working (verbose). there are 3 levels of output while winedump is running. the default level, when neither -q or -v are given, prints the number of exported functions found in the dll, followed by the name of each function as it is processed, and a status indication of whether it was processed OK. with -v given, a lot of information is dumped while winedump works: this is intended to help debug any problems.

🧚 Sym mode

  • sym β€” demangles C++ symbol sym and then exits. in and out, no small talk ✨

🌸 FILES 🌸

  • function_grep.pl β€” Perl script used to retrieve a function prototype.

files output in spec mode for foo.dll:

  • foo.spec β€” this is the .spec file.
  • foo_dll.h, foo_main.c β€” these are the source code files containing the minimum set of code to build a stub DLL. the C file contains one function, FOO_Init, which does nothing (but must be present). she's useless but she's essential πŸ’…
  • Makefile.in β€” this is a template for configure to produce a makefile. it is designed for a DLL that will be inserted into the Wine source tree.

😭 BUGS 😭

C++ name demangling is not fully in sync with the implementation in msvcrt. it might be useful to submit your C++ name to the testsuite for msvcrt.

bugs can be reported on the Wine bug tracker.

not me being honest about my flaws... growth is beautiful, bestie 🫢

🫢 AUTHORS 🫢

  • Jon P. Griffiths <jon_p_griffiths at yahoo dot com>
  • Michael Stefaniuc <mstefani at redhat dot com>

πŸ’« AVAILABILITY πŸ’«

winedump is part of the Wine distribution, which is available through WineHQ, the Wine development headquarters. go get her πŸ‘‘


⭐ SEE ALSO ⭐

  • wine(1)
  • Wine documentation and support.

and that's the whole page, bestie!! this was Wine 11.20, dated October 2005 β€” vintage but still eating, periodt πŸ’…βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from