![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Take a look at this folder:
This is an application for Wii Virtual Console ROM injection from 2008, but that's not really important. What I want to talk about is the DLLs in this folder - in particular, which executables need which DLLs - and how, when I wanted to use wadpacker myself, I took a different approach, just so I didn't have to learn how linking works.
Auto Injectuwad Injector v3.exe is the main GUI, which calls injectuwad.exe. There's also sha1.exe and the WAD tools (wadpacker, wadunpacker, imet_signer, and wadsigncheck). The dependency tree looks like this:
- Auto Injectuwad Injector v3
- MBVBM60.DLL (Visual Basic 6)
- injectuwad
- zlib1.dll
- kernel32.dll (Windows API)
- MSVCP80.dll (Visual C++ 8.0)
- MSVCR80.dll (Visual C++ 8.0)
- sha1
- kernel32.dll (Windows API)
- MSVCRT.dll (Visual C++ 6.0)
- wadpacker / wadunpacker / imet_signer / wadsigncheck
- cygcrypto-0.9.8.dll
- cygwin1.dll
- kernel32.dll (Windows API)
The Visual Basic 6 runtime is included with Windows. So is the "old" Windows C runtime in MSVCRT.dll, which MinGW uses as well. Later Visual C++ versions split their standard libraries from the OS - you can download them here, but they're so commonly used that you probably have some of them installed already.
The other libraries are included with the application. zlib1 implements the compression algorithm used in ZIP, gzip, and PNG, among others; it's only about 60 KB. The other two are much larger though, at about 3 MB combined: cygwin1 provides a POSIX API, and cygcrypto provides encryption and hashing functions from OpenSSL. Both come from the Cygwin project, which implements a Unix environment on top of Windows (as opposed to something like WSL, which runs alongside Windows in a hypervisor; Cygwin compiles apps to Windows binaries, albeit ones that reference its own runtime libraries).
Is this a problem? Not really. Besides, since their site calls out cygwin1.dll by the name right at the top, I think including it with an application is accepted practice. But it did cause a couple of issues for me when I wanted to tweak wadpacker by adding a couple of parameters. First, I like it when I'm able to have a bunch of EXEs in one folder, without worrying about conflicting DLLs, or trying to figure out which version of a library is newer. But also, I just think it's more elegant to take advantage of Microsoft's libraries when you can. If wadpacker were compiled for Linux, it would use the C and OpenSSL libraries from the distro's repository, and I wanted my Windows apps to do the same kind of thing.
( Read more... )