Please run
  gswin32c -h
and tell me what is set in the Search path.  On my system this is:
Search path:
   . ; C:\Program Files\gs\gs8.54\lib ; C:\Program Files\gs\fonts ;
   C:\Program Files\gs\gs8.54\Resource ; C:/WINDOWS/fonts ;
   c:/gs/gs8.54/lib ; c:/gs/gs8.54/Resource ; c:/gs/fonts

If you install to G:, then the first 3 or 4 will 
have G: not C:.  Ghostscript should be able to work
like this, but I'm not sure if it will ever access the last 
3 or 4 paths, and which one of these is causing problems.

Created attachment 5164 [details]
Suggested patch.

I suggest here a patch for getting rid of the hard-coded value for 
GS_LIB_DEFAULT on the Windows platform, where the value currently 
in the makefiles in unsuitable. There is the necessary framework 
to implement the same functionality for the other platforms, but 
I don’t know how to actually implement it for these platforms.

Problems were reported multiple times, but the general advice was 
to rebuild from source with a suitable GS_LIB_DEFAULT, or use -I:

    Bug 688083 - Build - Default search paths
    Bug 688296 - Default paths hard-coded
    Bug 688506 - Install and run ghostscript off of USB drive
    Bug 688832 - wrong GS_LIB_DEFAULT location (32bit Windows)
    Bug 689040 - Installation on other harddrive than default (disk c)

Partially related is a mention in

    Bug 690146 - GS_LIB registry setting entry with gs863w32.exe

(bug 690146 comment 1) about simplifying the ‘c:/gs’ part of the path.


This patch :

- Removes the hard-coded reference to a drive that might not even 
  exist on the user’s computer (and to directories that never exist).
- Allows GS to run without any environment variables or Registry 
  entries set. This is true even with COMPILE_INITS=0.
- As a consequence, allows ‘xcopy deployment’, run from USB memory 
  sticks or CDs - drive letters for these change when moved from 
  computer to computer.
- Allows easy ‘side-by-side’ install of multiple revisions, not only 
  versions (for this to fully work, don’s set GS_LIB).

-----

Patch details

base\gp.h :
    Provide a prototype for a platform-specific function that 
    computes, at run-time, a value for GS_LIB_DEFAULT.

    Function input:
	‘str’, *‘sizestr’
	    Buffer to hold the computed path, and its size.
	    ‘size’ == 0 allowed, and useful to get the needed buffer 
	    size; in this case ‘str’ can be NULL.
	‘have_rom_device’
	    Indicates the presence of a %rom% file system.
	    If set, some directories will be omitted from the 
	    returned path.
	    Details:
	    With COMPILE_INITS=1, ‘Resource/*’ are not installed but 
	    are included in %rom%, and files within will be found 
	    in %rom% before even looking into a ‘$(GSROOT)\Resource\*’ 
	    directory on disk.
	    To get the old behavior, where all directories are 
	    included regardless of COMPILE_INITS, pass ‘false’ here.

    Function output:
	*‘sizestr’
	    Set to the number of bytes stored in the buffer, or the 
	    size needed by such a buffer. *‘sizestr’ is set even if
	    an error occurs.
	Returns 0 if all OK, or -1 if error or not implemented.

psi\imain.c :
    If, at build time, GS_LIB_DEFAULT was set to ‘<>’ then get a 
    suitable value for it by calling the new ‘gp_getenv_gslibrtdef()’.
    No change relative to the previous functionality if 
    GS_LIB_DEFAULT set to anything else (including the empty string).

base/gp_dvx.c, base/gp_mac.c,  base/gp_msdos.c,
base/gp_os2.c, base/gp_unix.c, base/gp_vms.c :
    Provide stub implementations for all platforms except Windows.
    I don’t know how to implement the function on these platforms.
    I believe an OS/2 implementation may be similar to the Windows one.
    For Mac, I found some already existing code that looks like trying 
    to get some value for GS_LIB, maybe that’s the way to go (but I may 
    be absolutely wrong here). For *nix, I’m not even sure the 
    conventions for the directory tree are stable enough for this 
    functionality to be useful.

base/gp_mswin.c, base/gp_win32.c, base/winplat.mak :
    Implement ‘gp_getenv_gslibrtdef()’ for the Windows platform.
    The directories returned are based on Ghostscrip’s EXE/DLL 
    location, and are similar to on the ones in the previous 
    definition of GS_LIB_DEFAULT in the makefiles.

    Note about EXE vs. DLL (and about ‘phInstance’) :

    I moved ‘phInstance’ to be available for the monolithic EXE too, 
    not only for the DLL. The ‘big’ EXE does not assign any value to 
    it, so it remains NULL, which ‘GetModuleFileName()’ considers as 
    ‘the current running process’, that is the EXE.
    The DLL assigns it, and ‘GetModuleFileName()’ will return the 
    name of the DLL, not of whatever EXE is making use of the 
    Ghostscript DLL. So the path returned will always be based on 
    the location of the Ghostscript component in use - either the 
    monolithic EXE or the DLL.

psi/msvc32.mak,   base/bcwin32.mak, base/watcw32.mak,
base/msvclib.mak, base/watclib.mak :
    Switch the Windows makefiles to use the new mechanism, instead of 
    the previously hard-coded value of GS_LIB_DEFAULT.

    [BTW: why are ‘bcwin32.mak’ and ‘watcw32.mak’ in ‘base\’, while 
    ‘msvc32.mak’ is in ‘psi\’?]

Reassigning for patch review. Making P2 since I want to review and/or improve
this before the next release Aug 1.

Building with GS_LIB_DEFAULT= (and the default COMPILE_INIT=1) results in the
search paths shown from:
   gswin32c -h
showing:
    Search path:
      . ; %rom%Resource/Init/ ; %rom%lib/ ; %rom%Resource
    Initialization files are compiled into the executable.

Based on this, there will be no attempts to open "C:" or any other hard drive.

Anyone that has this problem can rebuild (using, for example the free Visual
Studio Express C++) to avoid the problem. The free, pre-built binaries for
Windows are for example only.

Closing as "FIXED" since COMPILE_INITS=1 and GS_LIB_DEFAULT=  as build macros
prevents the problem.