ep_extra: Implemented an `ep_extra`-based loader
ExplorerPatcher includes a mechanism which allows the user to load
a single DLL, named `ep_extra.dll` and placed in `C:\Windows` when
`explorer.exe` loads. This was long requested by some users who wanted
to perform their own code/initializations/hooks when `explorer` started.
In the mean time, I thought `ep_extra.dll` would work nicely as a
loader for any number of modules. I could've included this functionality
in the main ExplorerPatcher code, but I decided to take it up as a
challenge instead and offer a robust implementation without changing
ExplorerPatcher's main code.
Thus, when using this as `ep_extra.dll`, it will also load DLLs that
match the `ep_extra_*.dll` pattern. These DLLs must export a function
called `setup` which the loader will execute on the thread that is
loading the DLLs. Although not currently checked, return 0 from this
function if your initialization succeeded, or some error code when it
fails.
What's up with the assembly and shell codes and weird threads that I
create? Well, I realized I kind of did a mistake when coding
ExplorerPatcher, in that I should have loaded and executed `ep_extra`
on a seprate thread, not in `explorer`'s main thread. But since I said
I'd do this challenge without changing EP, this was my solution
towards having this `ep_extra` loader do its work, load the other DLLs,
if any, and then unload itself from memory safely and (almost) cleanly
without disturbing the main application right after it does its job.
This way, you can update it seamlessly when `explorer` is running,
which is much more convenient than having to kill `explorer`, replace
the DLL, and then manually reload `explorer`. I don't know if this is
the best way, but it is the way I thought about when realizing that I
cannot call `FreeLibrary` simply, since the "next line" (which would
have been a "return") is well outside of valid memory at that point.
`FreeLibraryAndExitThread` also can't be used since I do not want to
exit `explorer`'s main thread which the loader's function is called on.
2023-03-01 19:27:44 +01:00
|
|
|
// Microsoft Visual C++ generated resource script.
|
|
|
|
|
//
|
|
|
|
|
#include "resource.h"
|
|
|
|
|
|
|
|
|
|
#define APSTUDIO_READONLY_SYMBOLS
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
//
|
|
|
|
|
// Generated from the TEXTINCLUDE 2 resource.
|
|
|
|
|
//
|
|
|
|
|
#include "winres.h"
|
|
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
#undef APSTUDIO_READONLY_SYMBOLS
|
|
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// English (United States) resources
|
|
|
|
|
|
|
|
|
|
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
|
|
|
|
|
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
|
|
|
|
|
#pragma code_page(1252)
|
|
|
|
|
|
|
|
|
|
#ifdef APSTUDIO_INVOKED
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
//
|
|
|
|
|
// TEXTINCLUDE
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
1 TEXTINCLUDE
|
|
|
|
|
BEGIN
|
|
|
|
|
"resource.h\0"
|
|
|
|
|
END
|
|
|
|
|
|
|
|
|
|
2 TEXTINCLUDE
|
|
|
|
|
BEGIN
|
|
|
|
|
"#include ""winres.h""\r\n"
|
|
|
|
|
"\0"
|
|
|
|
|
END
|
|
|
|
|
|
|
|
|
|
3 TEXTINCLUDE
|
|
|
|
|
BEGIN
|
|
|
|
|
"\r\n"
|
|
|
|
|
"\0"
|
|
|
|
|
END
|
|
|
|
|
|
|
|
|
|
#endif // APSTUDIO_INVOKED
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
//
|
|
|
|
|
// Version
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
VS_VERSION_INFO VERSIONINFO
|
|
|
|
|
FILEVERSION 1,0,0,1
|
|
|
|
|
PRODUCTVERSION 1,0,0,1
|
|
|
|
|
FILEFLAGSMASK 0x3fL
|
|
|
|
|
#ifdef _DEBUG
|
|
|
|
|
FILEFLAGS 0x1L
|
|
|
|
|
#else
|
|
|
|
|
FILEFLAGS 0x0L
|
|
|
|
|
#endif
|
|
|
|
|
FILEOS 0x40004L
|
|
|
|
|
FILETYPE 0x2L
|
|
|
|
|
FILESUBTYPE 0x0L
|
|
|
|
|
BEGIN
|
|
|
|
|
BLOCK "StringFileInfo"
|
|
|
|
|
BEGIN
|
|
|
|
|
BLOCK "040904b0"
|
|
|
|
|
BEGIN
|
|
|
|
|
VALUE "CompanyName", "VALINET Solutions SRL"
|
|
|
|
|
VALUE "FileDescription", "ExplorerPatcher Custom Libraries Chainloader"
|
|
|
|
|
VALUE "FileVersion", "1.0.0.0"
|
|
|
|
|
VALUE "InternalName", "ep_extra.dll"
|
2023-03-19 04:27:08 +01:00
|
|
|
VALUE "LegalCopyright", "Copyright (C) 2006-2023 VALINET Solutions SRL. All rights reserved."
|
ep_extra: Implemented an `ep_extra`-based loader
ExplorerPatcher includes a mechanism which allows the user to load
a single DLL, named `ep_extra.dll` and placed in `C:\Windows` when
`explorer.exe` loads. This was long requested by some users who wanted
to perform their own code/initializations/hooks when `explorer` started.
In the mean time, I thought `ep_extra.dll` would work nicely as a
loader for any number of modules. I could've included this functionality
in the main ExplorerPatcher code, but I decided to take it up as a
challenge instead and offer a robust implementation without changing
ExplorerPatcher's main code.
Thus, when using this as `ep_extra.dll`, it will also load DLLs that
match the `ep_extra_*.dll` pattern. These DLLs must export a function
called `setup` which the loader will execute on the thread that is
loading the DLLs. Although not currently checked, return 0 from this
function if your initialization succeeded, or some error code when it
fails.
What's up with the assembly and shell codes and weird threads that I
create? Well, I realized I kind of did a mistake when coding
ExplorerPatcher, in that I should have loaded and executed `ep_extra`
on a seprate thread, not in `explorer`'s main thread. But since I said
I'd do this challenge without changing EP, this was my solution
towards having this `ep_extra` loader do its work, load the other DLLs,
if any, and then unload itself from memory safely and (almost) cleanly
without disturbing the main application right after it does its job.
This way, you can update it seamlessly when `explorer` is running,
which is much more convenient than having to kill `explorer`, replace
the DLL, and then manually reload `explorer`. I don't know if this is
the best way, but it is the way I thought about when realizing that I
cannot call `FreeLibrary` simply, since the "next line" (which would
have been a "return") is well outside of valid memory at that point.
`FreeLibraryAndExitThread` also can't be used since I do not want to
exit `explorer`'s main thread which the loader's function is called on.
2023-03-01 19:27:44 +01:00
|
|
|
VALUE "OriginalFilename", "ep_extra.dll"
|
|
|
|
|
VALUE "ProductName", "ExplorerPatcher"
|
|
|
|
|
VALUE "ProductVersion", "1.0.0.0"
|
|
|
|
|
END
|
|
|
|
|
END
|
|
|
|
|
BLOCK "VarFileInfo"
|
|
|
|
|
BEGIN
|
|
|
|
|
VALUE "Translation", 0x409, 1200
|
|
|
|
|
END
|
|
|
|
|
END
|
|
|
|
|
|
|
|
|
|
#endif // English (United States) resources
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#ifndef APSTUDIO_INVOKED
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
//
|
|
|
|
|
// Generated from the TEXTINCLUDE 3 resource.
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
#endif // not APSTUDIO_INVOKED
|
|
|
|
|
|