Bug Report: Mednaffe Cannot Find Mednafen Config When Using Scoop Package Manager

[harrywenjie]

Bug Report: Mednaffe Cannot Find Mednafen Config When Using Scoop Package Manager

Summary

Mednaffe fails to locate the Mednafen configuration file (mednafen.cfg) when Mednafen is installed via the Scoop package manager on Windows, due to Scoop's shim executable system separating the executable from the actual installation directory.

Environment

• OS: Windows 10/11
• Mednaffe Version: 0.9.3
• Mednafen Version: 1.32.1
• Installation Method: Scoop package manager
• Scoop Version: v0.5.2

Problem Description

When Mednafen is installed via Scoop, the package manager creates a "shim" executable at C:\Users\[username]\scoop\shims\mednafen.exe which acts as a wrapper/proxy to the actual executable located at C:\Users\[username]\scoop\apps\mednafen\current\mednafen.exe. The configuration file mednafen.cfg is located alongside the real executable in the current directory, not in the shims directory.

Mednaffe's current logic assumes the configuration file is in the same directory as the executable it finds via g_find_program_in_path(), causing it to look for the config in the wrong location.

Steps to Reproduce

1. Install Mednafen using Scoop: scoop install mednafen
2. Launch Mednaffe
3. Observe that Mednaffe reports it cannot find the Mednafen configuration

Expected Behavior

Mednaffe should be able to locate and read the Mednafen configuration file regardless of whether Mednafen was installed via Scoop or other package managers that use similar shim/wrapper systems.

Actual Behavior

Mednaffe fails to find mednafen.cfg and reports that it cannot locate the configuration file.

Root Cause Analysis

Looking at medprocess.c, the issue is in the Windows-specific code in med_process_new():

if (self->MedBaseDir == NULL)
{
    gchar* bin = g_find_program_in_path ("mednafen.exe");
    if (bin != NULL)
        self->MedExePath = g_strconcat("\"", bin, "\"", NULL);
    // Problem: MedBaseDir is never set when using g_find_program_in_path
}

Later, in med_process_get_conf_path():

#ifdef G_OS_WIN32
    self->MedConfPath = g_strconcat (self->MedBaseDir, "\\mednafen.cfg", NULL);
#endif

Since MedBaseDir remains NULL when the executable is found via g_find_program_in_path(), the config path construction fails.

Suggested Solutions

Option 1: Extract directory from found executable path

When g_find_program_in_path() finds the executable, extract its directory and set MedBaseDir:

if (self->MedBaseDir == NULL)
{
    gchar* bin = g_find_program_in_path ("mednafen.exe");
    if (bin != NULL)
    {
        self->MedExePath = g_strconcat("\"", bin, "\"", NULL);
        self->MedBaseDir = g_path_get_dirname(bin);  // Extract directory
    }
    g_free (bin);
}

Option 2: Implement MEDNAFEN_HOME support on Windows

Currently, MEDNAFEN_HOME environment variable support is only available on Unix systems. Adding this support to Windows would allow users to explicitly specify the Mednafen directory:

#ifdef G_OS_WIN32
    // Check for MEDNAFEN_HOME first
    gchar* mednafen_home = g_strdup(getenv("MEDNAFEN_HOME"));
    if (mednafen_home != NULL)
    {
        self->MedBaseDir = mednafen_home;
    }
    else
    {
        self->MedBaseDir = path;  // Use provided path or find automatically
    }
#endif

Option 3: Smart config file detection

Implement logic to search for mednafen.cfg in multiple potential locations:

1. Same directory as the executable
2. Parent directory of the executable
3. Common Mednafen installation paths
4. User-specified paths via environment variable

Current Working Workaround

The only current workaround is to manually pass the correct path when creating the MedProcess object, but this requires modifying the application code.

Impact

This affects all Windows users who install Mednafen via Scoop, and potentially other package managers that use similar shim/wrapper systems (like Chocolatey with shims).

Additional Information

• Scoop's shim system is documented at: https://github.com/ScoopInstaller/Scoop/wiki/Shims
• Similar issues may occur with other package managers that separate executables from their installation directories
• The issue does not affect Linux/Unix systems as they already have more flexible path resolution via MEDNAFEN_HOME

Claude wrote most of this. Just so you know.