Snail#

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.

I've got a Dell Dimension 4700. It's a 32-bit PC from the mid-2000s, and it's just barely new enough to have a PCI Express slot, which I used to add USB 3 ports, including a type-C, on a front panel (mostly because I thought it was funny).

The only actual work I do on this computer is writing, and the only way I can concentrate on writing is if my computer doesn't let me do anything else, and doesn't show anything else on the screen. That's why I do all my writing in Word 5.5 for DOS. For editing, I usually like to use Word 97 (with doswrd32.cnv), then export to HTML and copy to a thumbdrive.

I'd also like a Debian installation on there, just in case it comes in handy for some random project, but I don't want to commit to not touching it. There's a good chance I'm going to want to overwrite the installation at some point in the not-too-distant future - either by installing over it (maybe with a newer version), or removing it to make more space in my Windows partition for storing some big ol' files - and I don't want that to break my bootloader.

So I need to be able to:

• Boot into FreeDOS
  
• Boot into Windows (this computer's got a Windows 7 license, so that's what I'm using)
  
• Boot into Debian on the rare occasion I need it
• Delete the Debian partition without breaking the ability to boot into the other environments

In a normal triple-boot, you'd probably do something like this:

• Install Windows 7
  
• Install FreeDOS
• Install Debian using the rest of the available space

In this situation, Debian installs GRUB 2, which allows you to boot Windows 7 or FreeDOS instead.

But I don't want to commit to my Debian installation - I'd like to be able to overwrite or remove it, and still boot the other two operating systems on the drive. So what I want is a system that asks if I want Windows 7 or FreeDOS, then gives me a sneaky way to boot to Debian instead if I'd like. Turns out there's a setup that works really well in this very specific situation, and doesn't need any external boot disks. I'll walk through it below.