It might be safer to add E:\Program files\Winford to the DLL search path (which is probably what the installer will have done)
You are out of luck if it saves anything in the registry but I'd guess that ancient GPIB programs are unlikely to bother.
There is a serious risk of getting into DLL hell with ancient code being spliced into a modern OS where DLLs with the same name but different entry points and call parameters are present.
More likely it is the Uninstall log.
Adding ;.;
ie. Look into the current directory to the library and command paths ought to be reasonably helpful in getting it to see its own code.
However, it is quite likely to find itself running on a Windows environment it neither understands nor can operate correctly. My guess is the next thing it does after starting to execute will be a msgbox saying Win XX.YY not recognised or a blue screen.
If the executable was invoked from E:\Program Files\Winford, Windows will hunt for the DLL there (unless some *other* instance of that DLL is already loaded by *another* application -- unlikely in this case!)
[Remember, OP isn't terribly comfortable "playing" in this sandbox]
OTOH, there may be some configuration parameters (or implicit dependencies) that point to C:\Program Files\Winford -- where the program was initially installed. Hence it's probably safer to "put things where they were" than to try to update pointers to where they *are* (cuz you don't know which pointers may exist)
Remember, this is W95 technology (even if updated in the W2k era) so not unheard of for an application to *expect* to be in a particular place in the filesystem, etc. The fact that the DLL was found in E:\Program Files\Winford instead of E:\Program\Winford is a small encouragement! :>
What I'd be more worried about is any *other* envars that are now "invisible" without the *original* OS actually "running" in its native environment.
W95/98/2k era software probably expects a ".INI" file -- under C:\WINDOWS (which is now "invisible" as E:\WINDOWS).
It depends on how much his apps draw on from the system. Old DLLs tended to have different names than "current" DLLs (e.g., Borland DLLs). I'd more expect them to just not be present (because they were installed under E:\WINDOWS in its original role as C:\WINDOWS) unless found in the "Winford" folder (hence the reason to copy the entire folder/subfolders over to C:)
It encodes the actions taken during installation so the uninstaller can "undo" them -- i.e., the program hasn't been uninstalled yet so no "record" of the uninstaller's actions exists.
I'm not sure it looks in the current directory! I know it looks in the directory in which the executable is found. But, not sure that it tries "." (this should be easy enough to verify empirically)
I'm not so pessimistic. I have lots of binaries that I've just been dragging along over the years from one Windows release to the next. The biggest uncertainty (for the OP) is the interface to the GPIB card. MS used to play fast and loose about what you could do from userland. But, has become increasingly more "prudent" in tying the applications' hands in that regard.
This is why I suggested trying to get the "user interfaces" up, first.
However, from the OP's comments since then, it appears the user interfaces are "hardware interactive". I.e., they don't just manipulate/display previously acquired data but, instead, *talk* to the GPIB devices while the user is twiddling knobs in the application. So, unlikely that anything is going to happen because the hardware interface won't be accessible.
We still have no idea which drivers may be hiding under E:\WINDOWS that are required to even *talk* to the card...
Hopefully the OP will be able to fix the old machine and move the disk back to its original home and home environment! This would also handle any other hardware dependencies from that era (sound, video, etc.) that haven't *yet* bitten him.
Have you tried installing WinXP, going to the NI website and downloading the older NI device driver CD and running the installer for NI-488.2 and NI-VISA. Make sure GPIB is up and running through Measurement and Automation Explorer, copy your custom software over and give it a go?
You might need to gleen some more info from the old computer about run-times you may need to download from the NI website. CVI or LabView runtime versions, and etc.
You may also visit the Agilent/Keysight website and find the correct VXIpnp versions of intrument drivers you may need.
If attempts to resuscitate the old 98 box fail, I suspect the shortest/simplest way home on this may be to set up a dual boot configuration on the XP box, with the original 98 disk untouched.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.