Reckless wrote:Hi again... […]
Show full quote
Hi again...
In answer to your question:
But how would I get of this mess if I want to put the DLLs into a system wide search path?
Do it the ATI way, and add my install dir to the path? I'd rather not, if I don't absolutely need to ...
The answer is you shouldn't!
Now that's just grand. I'm not exactly offering an application here, I'm offering an API to any program that might want to use it. Real Glide drivers for real Voodoos install into a swsp. That's okay, because they expose an API that's useful to more than one application. I do that for exactly the same reason.
That's just like asking that MSVCRT.DLL should never be put into a system wide search path!
To continue on this tangent, I have a handful of older games that come with their own copy of MSVCRT.DLL, and they don't work on modern systems because of that.
Reckless wrote: It would be much better if you provided a configuration utility which managed the DLL placement into a set of user controlled directories. I can't remember what used to do this but something I had many moons ago (I think it was an OpenGL driver for a Matrox card I had...) used to do something very similar.
I have no reservations against the idea of "into/out of system" functionality in the config app. I also already thought out loud about "implant" functionality.
But I want swsp as the "normal" mode of operation. Everything beyond that is sugar, not even necessary except for conflicts with other DLLs of the same name.
As this one particular conflict (with dege) seems to be resolved, I'd like to hear some good reasons why you think that I absolutely should not, never, install into $WINDIR (to use NSIS parlance for a change).
That special Matrox OpenGL driver probably was just another version that was broken, like all Matrox OpenGL drivers, but in another way, so that different applications could be run with it. I've had that, too. Anyone remember the "alternative" version? I'm glad that's over.
Reckless wrote:The utilitiy could perform a filescan looking for 'known applications' and have checkboxes next to the located games (when found) to enable/disable the driver for that entry. A user could also Browse... to a game that wasn't known about as well so all bases would be covered.
I guess the above is all very well but would take some development effort. I could probably do something for you but being honest I'd not be interested if it wasn't in C# (as that would cut the required development effort by some margin as well as reduce the installation issues!) but that would obviously mean .NET Framework being a pre-requisite in order to run it. Let me knoiw...
I'd go for a pure "by browsable directory" design. "Known apps" is covered by the profile mechanism and these get created automatically anyway. Static assumptions just won't cut it. I have, at one time, thought there might be app specific driver optimizations breaking my rendering, so I renamed "Tribes.exe" to "Troybs.exe" ... not to mention that I have never installed any game in the suggested default directory.
I will never force a full hard drive scan just to locate a handful of EXEs. I'd find that intrusive and insulting if an application would do this to me, so I'm not going to write code that does.
And I will never require installation of the .NET runtime (to a swsp, I suppose?). Besides other more debatable reasons, there's Win9x support to consider.
Reckless wrote:Changing the install location to %systemroot% (from %systemroot%\system32) doesn't gain you anything apart from potentially not overwriting an existing file.
So I figured, thanks to the info you posted.
I really do believe that your stance is correct for application software. But IMO not for APIs and libraries, or in general terms, software that enhances the capabilites of the base system (.NET, Java, graphics drivers, sound drivers, ... Glide ...). I think these two categories have very different requirements, with the overall goal being "annoy as few users as possible".
For the "application" part of the wrapper, I follow the rules closely. For the "core" part, well, I think different rules apply, and I follow these as well as I can.