DLL in Separate Process?

[KK20]

So I was reading this thread that Drago showed us.
http://www.hbgames.org/forums/viewtopic.php?t=71126

And some people mentioned "why not use a DLL instead of an EXE?" From my understanding, this application forces the RMXP game to always be in the foreground (doesn't freeze when the player clicks on something else outside of the game's window). The EXE runs in a separate process and regularly checks if the game window is in focus or not.

My question is how do you even get a DLL to do this? From my understanding, you can't have a DLL run in a separate process. So I have no idea what those people were talking about. Anyone care to enlighten me?

[G_G]

Just throwing this out there, I dunno how this works, but maybe try opening a new thread via your dll and calling the proper user32 and kernel hooks to force the window to keep updating like the script is in the topic. I honestly couldn't figure it out regardless, because in order to call the dll, the window would need to be active to begin with.

Also.... I forgot I still exist there. I still have the fucking Decisive Media shit as my avvie/siggie

[KK20]

in order to call the dll, the window would need to be active to begin with.

Yeah, that's exactly what I was thinking. It seems like an EXE is inevitable. I don't see what's the big deal anyways--just remind your players that it isn't a virus

[Spaceman McConaughey]

Also.... I forgot I still exist there. I still have the fucking Decisive Media shit as my avvie/siggie

trying to say something fucker

[G_G]

I'm just saying, back when we ran the first version of our forums... was forever ago.

[Spaceman McConaughey]

oh das right bb

[Ryex]

have neither of you head of Fork?

No I'm not talking about thread fork I'm talking about hard process fork like the c fork() function that returns the PID of the new process.

Write a DLL that forks just before it starts looping the code that monitors the game window. I know you can do it.

not to be condescending but gogin the root of using an external exe for something like that is a bit amateur.


EDIT:

now obviously the C command fork() is a unix call your gogin to need the windows equavalent http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx

sadly it seems CreateProcess needs the path to an EXE. You can retrieve the path of the current EXE by calling GetModuleFileName with a NULL parameter though... dam it seems you do need an external exe...

but still if you create the process as a child of the game.exe you should be good. perhaps you can even figure out a way to use a thread instead.

[KK20]

Probably because
- I'm still learning what you can do with DLLs
- The professor who taught me this stuff was the type who copied homework questions online from other schools and use them on the tests/quizzes
- I don't know how to do this on Windows, only Linux

[Ryex]

oh wow, so I've actually done some homework on this now and it turns out that windows can't even properly do a process fork. as in it's kernel doesn't even know how! The Fuck Microsoft! fork is fundamental! it's been replicated with a few workarounds (meutex based context switches. stack copies and long jumps in the created child process) but the result is slow as all hell. I guess your stuck using WINAPI CreateProcess() and an external exe...

[KK20]

Well, if I still need another EXE, might as well just recreate the same process OP used. Unless it's slower or something.

[Blizzard]

You should still be able to create a thread within the DLL.

unsigned long WINAPI async_call(void* param)
{
    // your async stuff
    return NULL;
}

void callThisFromRuby()
{
    unsigned int id = CreateThread(0, 0, &async_call, NULL, 0, 0);
    /*
    // uncommenting this code will make the main thread wait until the other thread is done
    if (id != 0)
    {
        WaitForSingleObject(id, INFINITE);
        CloseHandle(id);
    }
    */
}

Look at it like this: On Windows there are equivalents for pthread_create(), pthread_join() and all the other functions. I suggest you take a look at our multi-platform implementation in hltypes.

https://code.google.com/p/libhltypes/source/browse/trunk/src/hthread.cpp

[finalholylight]

Sorry, but anyone have a mirror link of "always on top" demo ?, multiupload server died, I used google to search this demo on other forums but can't find anything.


This has nothing to do with the topic, and should not have been posted here.
Please make a new topic or ask in a pertinent thread in the future.

- ForeverZer0

[KK20]

While taking my shower, I was like "Can't this still be done with threads?" and I come back down to see that you confirmed my suspicion. I will give it a go...right after I finish my other things first. Thanks as always~

[ForeverZer0]

I was curious and just managed to accomplish it with a DLL using Windows hooks. Its only a few kb.
I will post it up sometime later. At work, and I have some things to polish up. I also managed to disallow keyboard input and not make it an always on top window, just keep it activated.