The Portable Freeware Collection Forums

IMPORTANT NOTE:
The last change log bullet is VERY important if you wish to use any of these
dlls with any configs that make use of the [HookExclude], [HookInclude],
[HookInitExclude], or [HookInitInclude] sections.

- Quick Use Notes -
o these are the latest jauntePE runtime dll 0.5.0 development builds
o they each go into their same-named subdirectory in JauntePE\Runtime\jauntePE
o once you move them there, rename each to jauntePE.dll
o they should be usable as-is except as noted above

- Change Log -
o to fix some of the issues when running on Vista or newer platforms
o the open and create registry key api hooks now return system registry
handles to the caller, whenever an equivalent system registry key exists
o 6 ntdll.dll registry api function hooks were added, that convert JPE open
registry key handles to system registry handles, whenever one exists
o the above 2 changes fix the "cannot use the File->Open dialog box on Vista
or newer" issue, but does not fix any other known file system related issue
o the above 2 changes probably also fix any other non-known issues that are
caused by creating and opening registry keys via win32 calls followed by
use of those open key handles in calls directly to the native (ntdll.dll)
api registry functions - this coding approach was seen in the Vista system
shell and ole runtimes, but may also exist in other system runtimes as well
as within application specific executables, or anywhere else for that matter
o the underlying causes for the file system related issues have been located
within the Vista shell and ole system runtimes, but the changes made in them
are significant enough that no reasonable workaround has been found yet

o the technique used to store JPE open registry key handles was changed to
boost performance and to prepare for future multi-process use, at the cost of
slightly higher memory use and a very slight chance that the maximum supported
number of simultaneously open registry keys will be exceeded, causing any
further requests to fail until previously open registry keys are closed

o the latest (and possibly last 2.x version) 2.x version of MadCodeHook was
used for the builds - this version supposedly allows for proper injection of
the 32 bit JPE runtime into a 32 bit process while running on a 64 bit
platform, but no testing was done to verify that claim

o support was added for a new high-level registry key introduced with Vista,
HKEY_CURRENT_USER_LOCAL_SETTINGS

o the fake drive plugin was enhanced and several bugs were fixed, mainly in the
virtual drive functionality (virt drive contents are not backward compatible)

o a temporary workaround was put into place to fix a bug that creates one empty
and non-named section header in a portable registry that was used in-memory

o the basic log output now includes additional info regarding timing per hooked
api function call and # of calls redirected per hooked api function - there's
also info indicating the # of successfully hooked api functions versus the
# of requested api functions to be hooked - an unsuccessful hooks list is
also output as needed

o a bug was fixed that could cause the logging version's ms (millisecond) output
numbers to not be shown with their actual ms values, depending on the system's
performance counter frequency value

o _lopen, CreateFileA/W, and OpenFileA/W hooks now all process their requests
the same way

o the extra code specific to 9x platforms support was removed

o support for plugin-specific api hooked function names was added - current
supported prefixes are drv (for fake drive), prc (for process redirection),
reg (for registry redirection), and wfs (for file system redirection), e.g.,
drvCreateFileW, prcCreateProcessW, regRegCloseKey, and wfsCreateFileW - the
non-prefixed names are no longer supported so any affected configs will need
to be modified accordingly

Andrew Lee wrote:I am normally not into profanity, but this is f**king fabulous news!!!

WHAT?

Hoorayyyyyy!!

joby_toss wrote: Yupiiiiiiiiiiiiiiiiii !!!!!!!!!!!!!!!!
Best news in a loooooong time for me !!!!!!!!!!!!

Thank you Redllar!!!!!!!!!
Thank you Crownixx!!!!!!!!!

Onesimus Prime wrote:Wow!!!

Many thanks to Redllar for this amazing news!

And thanks also to crownixx, Napiophelios, et al who did so much work with JPE in the meantime! Perhaps it's people like you whose efforts helped restore Redllar's faith in the portable freeware community? Who knows.

usdcs wrote:Welcome back!

redllar over at sourceforge wrote:As you can see, JPE is now an open source project. That means a move away from the previous versions use of the MadCodeHook hooking library, to new dll injection and api hooking methods that are now part of JPE proper.