MacroQuest64

whenever I try and recompile, I always have to restart explorer because eqlib.dll is still open, even though MQ has been closed. anyone know if this is normal, or if there's a way to fix it?

i just quickly rename it... no need to restart explorer, but yeah it is anoying and I think I know why its doing that, I will look at it.

The reason is because it attaches to all processes and has to remove itself from them. I usually open up windows task manager (ctrl+alt+del in xp) and it removes itself at that point.

As Lax said, the dll attaches to every process (though it only takes action in the eqgame process) so when you unload it all you have to give each processes the chance to handle the dll unload.

Processes wont always get the unload message when they are minimized but if you just click each application window into foreground once that usually does the trick for me. Also, it is common is for eq to leave zombie processes around as well, so you shoudl bring up task manager and make sure there are no hung eq processes. Whenever I am unable to overwrite the dll like you mentioned, I just do those two things and it always clears up.

I gather from what you said about EQLib attaching to every process that you are using windows message hooks to inject yourself into any process with a windows hook. You're already using Detours, and it has a couple ways of injecting a DLL into a running process, why not just use that method? That way you don't have to load into every process' address space.

Madar

Can you elaborate on the way detours can do dll injection?

I did some research on this a long time ago... Theres 2 ways of doing the injection. One is the way MQ does it through global windows hooks, the other is to load the process yourself and create a remote thread. The remote thread way requires Windows 2000 or later, and also requires loading the process yourself (ie no EQW support). It's probably workable using remote threads and getting the process ID of each eqgame.exe through snapshot/etc but the MQ injector would have to continually scan for new eqgame.exe processes... and even then, requires Win2k or later.

I'd just keep it how it is really

Ahh didn't realise you were supporting Win9x, that makes sense. As for Win2k/xp/2k3, there're actually a couple ways to do it. One is as you mentioned, which is to patch CreateProcess in the lobby proc, and substitute a call to DetourCreateProcessWithDll. What this does is creates the EQ process in the suspended state (the main thread is suspended), injects some code into its address space with WriteProcessMemory, then calls CreateRemoteThread to execute that code. All that code does is calls LoadLibrary on the DLL of your choice.

You still have to get into the lobby proc's address space, but there are some big advantages to this method. The biggest is that your injection is done BEFORE any code in the game executes. With the alternate detours injection you're injecting at some time shortly after the process starts, and with a windows hook you're injecting as soon as EQ pumps its first windows message. This loses you the ability to patch alot of initialization code that EQ does - don't know if this is a problem. (I'm just returning to EQ hacking after a 6 or 7 month hiatus, so bear with me )

The other method with Detours is to open the process handle for EQ and then use DetourContinueProcessWithDll. This does the second have of what the first call I listed does - it writes some code into EQ's address space with WriteProcessMemory, and then uses CreateRemoteThread to execute it, and the code just calls LoadLibrary on your DLL. A bit more surgical than a windows hook, but has the disadvantage of not knowing what state the process is in when you inject. (If you don't care though, you can inject at any time).

There is a workaround for this not working on Win9x, but Detours doesn't have that method implemented since it only supports 2000/xp/2k3 etc.. It involves hijacking a thread's context rather than using CreateRemoteThread (CreateRemoteThread is what's missing on 9x). The concept is to suspend all the threads in the target process (or start it suspended as above), then save off the thread context of the main thread. Write your LoadLibrary code into the address space, same as before. Modify the EIP register in that thread to point to your code using SetThreadContext, and then resume that thread. Once your code has executed (and hence loaded your DLL), suspend the thread again, restore its thread state, and let it resume right where it left off. Alot more of a pain than using Detours, but I know I've seen a couple libraries out there to do it.

Either way, MacroQuest looks pretty impressive - good work guys.

Madar

Well, there's a very simple way to do it by modifying the .exe -- pick an import with few API calls, replace the name in the import table with your own DLL, and have the DLL support the real one's API... requires no injector after modifying the exe, doesn't stick in memory, and works like a champ The only problems with this are that EQ would patch the exe whenever you run the patcher, if the modification changed the file time it would confuse MQ, and if EQ checks the file itself for CRC it would fail.

I may do some testing on this and if it works I'll offer an alternative to the global method.

Win9x is still supported in MQ, for a very simple reason. Stability issues aside, from everything I read the fastest OS for gaming is still Win98. A lot of folks still use it on their gaming machines.

Add to that the fact that a lot of people can't afford Win2k/XP, and not everyone is willing to "acquire" a copy of it.

Mckorr wrote:Win9x is still supported in MQ, for a very simple reason. Stability issues aside, from everything I read the fastest OS for gaming is still Win98. A lot of folks still use it on their gaming machines.

That is a myth, and Win98 will probably no longer be supported by Microsoft in 2004. It's got one foot in the grave and there is no reason to support it.

Make a poll, find out how many MQ users use Win98, and I bet the number will be very very low.

MQ should ditch Win9x support sooner or later, although I think the injection mode currently used is fine since its already implemented and working, theres no compelling reason to change it.

Well, MS supports the OS for a number of years, 95 recently went out of the support cycle and 98 is pending when the time runs out :)

There's no really good argument for changing the injection method, because the current method is supported across the board and works fine, other than minor annoyances when updating...

However, I'll pursue what I talked about (simulating an existing DLL) as an alternative..

That is a myth, and Win98 will probably no longer be supported by Microsoft in 2004. It's got one foot in the grave and there is no reason to support it.

Unfortunatly that is not true. Microsoft is bound to support all of there programs as long as somebody is using it, even if this meens only 1 person. If you go on microsoft's web site you'll see that there is still an active support page for win95. Of course there's not much recent updates on the page because as we all know microsoft's programs are all bug free (HAHAHAHA.. erm.. sorry) but still they do offer support, even by phone.

For win98, it still does the work. I run both win98 and XP on a P2 266mhz 192MB SDRam and EQ run on win98 (very slow) but not on XP, screen flashes continuously with XP.

Clone39

Theyre not bound to support it, they will have a support page sure. There might even be patches for it. However, they will not go out of their way to make sure that new versions of API support it. I would expect when Longhorn comes out, new versions of DirectX might not support Windows 98 at all.

Not sure how this turned into that. :) However, it's true that Microsoft will drop support for 98 / 98se very soon. http://www.microsoft.com/windows/lifecycle.mspx describes their product life cycle - in 2004 98/se are in the unsupported phase, meaning no hotfixes, security or otherwise. I wouldn't want to be running an unsupported OS. In 2005 their lifecycle ends which seems to mean all the windows update stuff for them and support information is removed.

Do people really prefer 98se to XP for gaming these days? I thought those days were long gone - XP rocks.

Madar