Without any reason, my cable ISP has been filtering a couple of domains for nearly two months, including Vogons. Sorry for the extended absence. I've just updated my above post with the latest releases of GlideWrapper and dgVoodoo.
0.80 is out at the usual address. The changelog is much too long to post 😦
edit:
Direct link to changelog
Kaminari,
That updated Tomb Raider screenshot of yours ... a Geforce card, right? Should be fixed now, or at least I hope so. That's the "lose hardware palette during close/reopen sequence" issue I think.
Wow, you've been busy!!
I noticed that the textures are still too low resolution in Boss Rally (dgVoodoo draws them full resolution but shows black screen when you switch to the view with a rear-view mirror!).
There is one BIG problem with this wrapper though. It prevents dgVoodoo working in DOS games! For games that I wish to run dgVoodoo in rather than Zeckensack's wrapper (Boss Rally & NFS2SE etc) then I just put glide2x.dll and dgVoodooSetup.exe in the game's folder and only that game will use the wrapper...
...however for DOS games this approach doesn't work, so Screamer Rally can only run in Glide with dgVoodoo if I uninstall Zeckensack's wrapper first.
Any ideas?!
Ice
wrote:I noticed that the textures are still too low resolution in Boss Rally (dgVoodoo draws them full resolution but shows black screen when you switch to the view with a rear-view mirror!).
Whoops. If only there was a demo of the game 😖
wrote:There is one BIG problem with this wrapper though. It prevents dgVoodoo working in DOS games! For games that I wish to run dgVoo […]
There is one BIG problem with this wrapper though. It prevents dgVoodoo working in DOS games! For games that I wish to run dgVoodoo in rather than Zeckensack's wrapper (Boss Rally & NFS2SE etc) then I just put glide2x.dll and dgVoodooSetup.exe in the game's folder and only that game will use the wrapper...
...however for DOS games this approach doesn't work, so Screamer Rally can only run in Glide with dgVoodoo if I uninstall Zeckensack's wrapper first.
Any ideas?!
Ice
Hmmm ... yes, ideas, no real good ones though.
1)Uninstall mine, use his, reinstall mine. No, really, it's fast, doesn't require a reboot or anything. There's a creatively named ini in the wrapper's directory (C:\Program Files\GlideWrapper\ by default), which you can save somewhere and restore.
Okay, more serious now
2)How'd you like a pair of buttons in the already overloaded config thingy, that can get the two DLLs out of the system, and back in ...?
Another way would be an "implant" option that puts the DLLs in a selectable game directory. Would by messy to get the whole thing uninstalled again, but that can certainly be done.
What do you think? How should this be working?
I think the fundamental problem with any approach is that can't have dege's system wide and mine system wide. Even if I let you move the DLLs in and out of the system folder, dege's would need to have such an option too. Does he?
There can only be one glide2x.dll in the system directory, you see? 😖
A couple of notes:
1. dgVoodoo you put all the relevant files in C:\WINDOWS not windows\system32 so they won't actually overwrite yours. I'm not sure which wrapper gets preference then when a Glide game triggers though...
2. dgVoodoo CAN be installed per game. In fact for games such as NFS2SE I simply put his glide2x.dll and dgVoodooSetup.exe in the NFS2SE folder and then the game uses that wrapper instead of yours. The problem only arises on DOS games where doing the same (putting all the files in say the Screamer Rally folder) says some message about unable to find device. This is odd as a DOS game shouldn't be looking for Glide in a Windows folder. Maybe your wrapper is collecting the game call or something. I can't figure it out but as soon as I uninstall yours the dgVoodoo window appears and the game works.
Basically I'm not looking to run both system-wide (I prefer your wrapper at present as it's more compatible currently) - it's just the DOS Glide games that won't work in dgVoodoo with your wrapper installed at the same time.
Ice
wrote:A couple of notes:
1. dgVoodoo you put all the relevant files in C:\WINDOWS not windows\system32 so they won't actually overwrite yours. I'm not sure which wrapper gets preference then when a Glide game triggers though...
2. dgVoodoo CAN be installed per game. In fact for games such as NFS2SE I simply put his glide2x.dll and dgVoodooSetup.exe in the NFS2SE folder and then the game uses that wrapper instead of yours. The problem only arises on DOS games where doing the same (putting all the files in say the Screamer Rally folder) says some message about unable to find device. This is odd as a DOS game shouldn't be looking for Glide in a Windows folder. Maybe your wrapper is collecting the game call or something. I can't figure it out but as soon as I uninstall yours the dgVoodoo window appears and the game works.
I think part of the problem is that Windows makes that choice of priority. A DLL that's being loaded can't say "no, I don't want to be first choice, go look somewhere else".
And at this point it doesn't matter much whether it's in \WinNT, in \WinNT\system or \WinNT\system32 ... any of these are system wide search paths. You'll get wrong choices eventually, and there's nothing a DLL can do about that. And as you've seen, the priority of multiple DLLs of the same name isn't even deterministic, it depends on circumstances.
This looks to me like whenever dege's glide2x.ovl looks for glide2x.dll, it gets "mine" somewhere out of \WinNT, even though his glide2x.dll is right in place.
And there is no "collecting calls", I don't even know if this is possible. My DLLs are never "registered" with the system, if that matters, it's just plain file copies.
Really, the only way around this is to get the glide2x.dll out of anywhere near \WinNT. This way you force the system to load the DLL out of the game directory, everything else is just unreliable (even depends on OS version).
Note that you can move around my two DLLs as freely as dege's, they can work from any place (including all the config stuff).
wrote:Basically I'm not looking to run both system-wide (I prefer your wrapper at present as it's more compatible currently) - it's just the DOS Glide games that won't work in dgVoodoo with your wrapper installed at the same time.
Ice
Okay, I want you to try something out for me. What happens if you move my two DLLs from \WinNT\system32 to just \WinNT? Does it start working then?
If that doesn't help, would you be satisfied with "move in"/"move out" functionality? Or would you like me to add "implant" functionality ... or perhaps both?
What would be more convenient to use for you?
In the meantime I'll ask dege if he can influence which DLL gets loaded from his OVL.
Windows has always had a strict search path.
If the path isn't hardcoded (which it should never be), LoadLibrary will always search:
For 32-bit apps, Windows NT searches for implicitly loaded DLLs at: […]
For 32-bit apps, Windows NT searches for implicitly loaded DLLs at:
The .exe file directory.
The current directory.
The %SystemRoot%\SYSTEM32 directory.
The %SystemRoot% directory.
The directories in your Path.If the DLL is listed as a KnownDLLs at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager as a type REG_SZ entry with a Value Name of the DLL without the extension and a data value of the DLL with the .DLL extension, then the search is:
The %SystemRoot%\SYSTEM32 directory.
The .exe file directory.
The current directory.
The %SystemRoot% directory.
The directories in your Path.The KnownDLLs are mapped at boot time. Rernaming or moving during a session has no effect.
You can alter this behavior by including the 8.3 DLL name in the ExcludeFromKnownDlls entry, a type REG_MULTI_SZ value, one per line. This will make NT believe that the DLL is not listed in KnownDLLs.
For 16-bit apps, Windows NT uses KnownDLLs for both implicitly and explicitly load DLLs. The value is at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WOW. At this key, KnownDLLs is a type REG_SZ value which lists the 8.3 DLL names, separated by spaces. Wihout a KnownDLLs entry, WOW searches:
The current directory.
The %SystemRoot% directory.
The %SystemRoot%\SYSTEM directory.
The %SystemRoot%\SYSTEM32 directory.
The .exe file directory.
The directories in your Path.With the KnownDLLs entry, WOW only searches the %SystemRoot%\SYSTEM32 directory.
Just place a copy of the driver Glide2x.dll (or Glide3x.dll and/or any support files, etc.) in the game directory and all should be well. It is (and always was) a very bad idea to place DLLs in to the System[32] directory...
Hope that clears that up 😀
Having just looked at Mobygames..... Boss Rally supports D3D, what's wrong with using it? A Glide wrapper is great for games that now wouldn't otherwise have 3D acceleration (Red Baron 3D for example!)...
Boss Rally supports D3D but it doesn't work with my ATI Radeon 9800XT! That's why Glide is my only option!
Ice
Eh? The 9800XT is a fully compliant (and very capable) D3D card.... What issues are you getting with D3D on it?
Boss Rally itself has the problem. It only recognises certain old graphics card in it's graphics card setup utility. If you choose any Direct3D setting the game says "Unable to initialize Direct3D" or something similar when starting the game. Thus Glide emulation is the only option!
Ice
Thanks Reckless. 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 ...
wrote:Windows has always had a strict search path. […]
Windows has always had a strict search path.
If the path isn't hardcoded (which it should never be), LoadLibrary will always search:
For 32-bit apps, Windows NT searches for implicitly loaded DLLs at:
The .exe file directory.
The current directory.
The %SystemRoot%\SYSTEM32 directory.
The %SystemRoot% directory.
The directories in your Path.If the DLL is listed as a KnownDLLs <snip>
It isn't, so I snipped that part.
wrote:For 16-bit apps <snip> Wihout a KnownDLLs entry, WOW searches: […]
For 16-bit apps <snip>
Wihout a KnownDLLs entry, WOW searches:The current directory.
The %SystemRoot% directory.
The %SystemRoot%\SYSTEM directory.
The %SystemRoot%\SYSTEM32 directory.
The .exe file directory.
The directories in your Path.
And that's the whole problem I suppose!
If the current dir really goes first for WoW, there should be absolutely no problem. But there is a problem, so either your info isn't correct (which I doubt), or the current dir isn't the same as the exe dir.
wrote:Just place a copy of the driver Glide2x.dll (or Glide3x.dll and/or any support files, etc.) in the game directory and all should be well. It is (and always was) a very bad idea to place DLLs in to the System[32] directory...
Hope that clears that up 😀
Well, yes, it's very useful info, thanks. But I'm still confused about what would be the proper way to do.
I find it quite nice to be able to plug a DLL somewhere (not necessarily system32, mind) and have it instantly work for any number of applications.
I just reworked my installer script to put the DLLs into \WinNT, and wrote a small "crapkiller" that will automatically run on installation to get any leftovers out of system32. I somehow had in mind that this might work, but according to your list it should make absolutely no difference, neither for Win32 games, nor for DOS games.
Maybe that's even worse than before. If dege installs to \WinNT, too, that is. So ... what to do?
VirtuaIceMan, if I may insist ...
wrote:Okay, I want you to try something out for me. What happens if you move my two DLLs from \WinNT\system32 to just \WinNT? Does it start working then?
wrote:VirtuaIceMan, if I may insist ...
wrote:Okay, I want you to try something out for me. What happens if you move my two DLLs from \WinNT\system32 to just \WinNT? Does it start working then?
Two things:
Firstly, Dege's wrapper doesn't install anywhere - you have to put it manually in the C:\WINDOWS folder (that's what the readme says!).
Secondly I'm not sure why I need to test your wrapper in another folder? My PC is WindowsXP so I have C:\WINDOWS not C:\WINNT anyway. I run Dege's wrapper only in the game folder of games that need it, so it doesn't conflict either. And since Dege fixed the reading order of the glide2x.ovl so it checks the game's folder first it's all fine (well for me anyway!).
Still, let me know if you still want me to try anything in particular.
Ice
No, after dege's changes that's not necessary anymore 😀
0.80b
As the name implies, this is a small incremental update. Fixes the most ovbious bugs that were in 0.80. Changelog.
I've also changed the DLL install target to \WinNT or \Windows on Win9x. Leftovers from previous versions of my wrapper will be deleted during the installation. Not sure if that's any use now. I originally thought it might help with dege's wrapper (didn't have the info posted by Reckless then).
Well ...
The next one's going to be big and seriously multithreaded. Two months from now is the approximate target for that.
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! 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.
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...
Changing the install location to %systemroot% (from %systemroot%\system32) doesn't gain you anything apart from potentially not overwriting an existing file.
wrote:Hi again... […]
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.
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.
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.
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.
Don't take posting as what you must do, I'm merely offering some guidance... feel free to toss it if you want!
In fact, you should note that Microsoft now no longer consider %systemroot%\system32 to be a suitable home for MSVCRT.DLL. It and all the other C runtime libraries should all be located in the application directory.
What you've done is follow what was considered the done thing as of a few years back. A low level API provider is installed in a common location so that a number of applications may make use of it. That's cool. However things move on and Microsoft and developers now realise this can lead to a different set of issues - Microsoft gave it the name of DLL hell.
To prevent this, Microsoft came up with a few solutions. a) Side-by-side execution (SxS) which is basically a set of hidden directories per component version. b) Requiring certain files to be installed in the application folder instead of one of the common ones. c) .NET with its version managed GAC (global assembly cache). With all three options in place, it's almost impossible to run into trouble with DLLs 😀
I remembered tonight what the Matrox driver was and it was the TurboGL driver that was shipped with the G200 (some years back now!!). It had special execution code for a variety of games which made it run a lot faster (hence its name!) than the standard GL driver located in %systemroot%\system32.
As for you disdain for .NET, then that's your choice 😀 Personally, I don't really care for any system running anything less than Windows 2000 these days. .NET is a completely different environment and will support co-location of multiple versions.
Anyways, my ideas are only ideas. Nothing more, nothing less.
0.80c is a very small change over 0.80b, but ...
0.80 completely broke usability on Geforce <=4 cards. It automatically assumed EXT_blend_func_separate functionality to be available on GL versions >=1.4. This is technically correct (it's a core feature in GL1.4), but the OpenGL driver then enters a software rendering path on these "lesser" cards.
That's what's fixed in 0.80c. Mea culpa.
Reckless,
you seem to know a lot on the subject, and I'm glad you're sharing. For a moment I feared I just might have p**sed you off too much ...
This is an integral design decision, and I want it to be right, so maybe you can see why I get so defensive about it. Sorry.
I was hoping that maybe you had an idea for a swsp that was "ok" to use, or perhaps less bad than %systemroot%.
If I reread your priority list, the KnownDLLs mechanism can only function if the DLL itself is in %systemroot%\system32? Or can it somehow be made to work with DLLs in arbitrary directories? If yes, that would be a good replacement, wouldn't it?
"Implant" just for the sake of not touching %systemroot% does not appear to make much sense atm. There's so little benefit and so many new problems. I'm only trying to support 5+ year old software, that's all 😀
Hopefully this is the last hotfix for now. The 0.80 series was a nightmare so far 😖
