>
>This patch fixes Bug 14784.
>
>As requested by Dmitry Timoshkov, I have created a standalone test case
>for DLL injection via SetWindowHookEx. It has been attached in Bug 14784
>with MSVC source code and compiled exe and dll.
>
>With LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH)
> What do I have to do to get this patch accepted ?
Write a regression test that shows the problem, marked with todo_wine.
--Juan
Rolf Kalbermatter wrote:
> I do not think that the solution is to "correct" LoadLibrary to actually do
> a search for linked libraries in the parent library's directory too.
>
> However I fear the proper fix might go deep into Wine server and probably is
> above most people's head except for Alex
On Sat, Aug 2, 2008 at 2:10 AM, Steven Edwards <[EMAIL PROTECTED]> wrote:
> Its also documented in Inside Windows by Jeffery Richter if you happen
> to have a copy of that laying around.
Sorry make that Advanced Windows. I gave my copy to a friend so I
don't recall much about the chapter, except t
On Fri, Aug 1, 2008 at 6:25 PM, Rolf Kalbermatter
<[EMAIL PROTECTED]> wrote:
> Ok I think I understand. You are using a technique I have once read about in
> Microsoft System Journal back in about 1994. And this is certainly tricky.
Its also documented in Inside Windows by Jeffery Richter if you h
Hongbo Ni wrote:
> Back to DLL injecting, It works since Windows 95. My program
> has been working for many years, but not on Wine.
>
> Here is how to inject a DLL into another process:
> .
Ok I think I understand. You are using a technique I have once read about in
Microsoft System Journ
Rolf Kalbermatter wrote:
> My guess is that it will however fail on most Windows versions except maybe
> Vista which would still be a reason to try to implement that behaviour in
> Wine
> too. However you will likely have to do quite
> a bit more tests to then figure out the exact conditions un
tra here, for
instance to support
new Vista behaviour which seems to have complicated the whole DLL loading
procedure a bit.
>I have produced a patch to load the imported dll from same directory
>as the referring DLL when import_dll() fail to load from standard
>locations (curren
> Rolf Kalbermatter wrote:> > Not sure about what you mean with injecting here
> but in normal application operation> when loading a DLL explicitedly from a
> specific directory (which is not the current> directory nor the application
> directory or one of the standard search paths),
> Windows
Hongbo Ni wrote:
>I think when processing the imports for C:\DirA\B.dll to load C.dll, it
should
>try C:\DirA\C.dll first, then form the standard load locations.
>
>I think it should call load_library( "C:\DirA\C.dll ",
LOAD_WITH_ALTERED_SEARCH_PATH)
>so C.dll can be loaded into C:\DirX\X.exe pro
Hongbo Ni <[EMAIL PROTECTED]> writes:
> I think it should call load_library( "C:\DirA\C.dll ",
> LOAD_WITH_ALTERED_SEARCH_PATH)
> so C.dll can be loaded into C:\DirX\X.exe process.
>
> Alexandre, can you please comment ?
You should write test cases.
--
Alexandre Julliard
[EMAIL PROTECTED]
Hi,
I have observed a DLL loading prolem when injecting into another process.
For example,
In folder C:\DirA\, I have A.exe which is linked to B.dll, and B.dll is linked
to C.dll.
B.dll and C.dll are in same folder as A.exe.
If I run A.exe, B.dll and C.dll will be loaded without problem
Stefan Dösinger <[EMAIL PROTECTED]> wrote:Many applications behave that way,
and we create fake .DLL files in system32.
They are real PE files from their file header, but they do not contain the
implementation. When an app tries to LoadLibrary this DLL we load the builtin
one instead
So we j
Am Mittwoch, 16. April 2008 16:43:13 schrieb Rhys McGuckin:
> There are two possible ways currently that I can think of, which would
> potentially solve this problem: 1. Have symbolic links within the system
> directory (I find this to be bad method, for multiple reasons) 2. Have some
> interceptio
In reference to bug #11973, I've the following observation.
Using the native .NET 2.0 installed via winetricks, I located what is
potentially a problem with the method that .NET is using to locate the DLLs
that it wishes to load.
The problem seems to be that .NET is attempting to locate the var
Bojan "ÿ8aernek" <[EMAIL PROTECTED]> writes:
> I'd like to load a DLL from a memory buffer. The
> regular Win32 API function to load DLLs, however,
> takes a path name. So, I'm looking for resources about
> this kind of thing, but it has to work both under
> win32 and unix+wine. There used to
hello,
I'd like to load a DLL from a memory buffer. The
regular Win32 API function to load DLLs, however,
takes a path name. So, I'm looking for resources about
this kind of thing, but it has to work both under
win32 and unix+wine. There used to be a web page about
just this thing, but I lost the
All,
Seems that a regression in DLL loading crept in lately (a game that worked
somewhat with my old CVS tree does not start anymore with the current CVS).
It must have been broken for some time now as Mike 'TD' had the issue for a
long time (with a 4 hours Wine compile time, I do n
18 matches
Mail list logo
