Hi,
On Tue, Oct 18, 2005 at 08:21:55AM +0200, Eric Pouech wrote:
> Vincent Béron wrote:
> >Changelog:
> >Correctly unicodify winmm/mmio.c.
> don't apply this patch, it's plain wrong.
> the A<->W message mapping isn't implemented yet, and all our internal
> handlers are still ANSI.
I was just thin
Vincent Béron wrote:
Changelog:
Correctly unicodify winmm/mmio.c.
don't apply this patch, it's plain wrong.
the A<->W message mapping isn't implemented yet, and all our internal
handlers are still ANSI.
The steps to go are (in order):
- implement A<->W message mapping for MMIO
- translate our
On 17 Oct 2005 20:02:16 -0400, Vincent Béron
<[EMAIL PROTECTED]> wrote:
> Changelog:
> Unicodify HtmlHelpW in hhctrl.ocx
>
We should leave the message out completely at this point. The
integral components of HTML Help have been implemented, and at least
HH_DISPLAY_TOPIC needs to call doWinMain.
-- Maxime Bellengé <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> You can try this application installer :
> http://jatennis.free.fr/jatinst32.php
>
I've had a look and the installer is failing because of the result returned by :
0009:Call version.VerFindFileA(,0040b4ec "JaTennis32.exe",004
--- Maxime Bellengé <[EMAIL PROTECTED]> wrote:
> For me returning HFILE_ERROR makes one of my application installer
> fails. If the function returns FALSE, it behaves normaly and exactly
> like on windows. The application installer works correctly.
>
Which version of window are you using and do
Ok, Im almost there (or at least alot closer).
After editing a source file and a few Makefiles and manually applying
several diffs from Robert Lunnons patchkit from different Wine versions
(none applicable to 20050830). I got Wine to compile on Solaris 9!
Now when running wine, it sits for
For me returning HFILE_ERROR makes one of my application installer
fails. If the function returns FALSE, it behaves normaly and exactly
like on windows. The application installer works correctly.
Maxime
On Mon, 2005-10-17 at 15:20 +0100, Oliver Stieber wrote:
> --- Dmitry Timoshkov <[EMAIL PROTE
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "Oliver Stieber" <[EMAIL PROTECTED]> wrote:
>
> > > file.c:1413: Test failed: hFile != FALSE : -1
> >
> > -1 is HFILE_ERROR and FALSE is 0 (defined in windef.h), is this running
> > the old or the
> patched
> > one?
>
> It's the result of ru
"Oliver Stieber" <[EMAIL PROTECTED]> wrote:
> > file.c:1413: Test failed: hFile != FALSE : -1
>
> -1 is HFILE_ERROR and FALSE is 0 (defined in windef.h), is this running the
> old or the patched
> one?
It's the result of running existing tests. I just wanted to point out
that the second chunk
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
>
> > >This patch corrects the test for OpenFile with a style of OF_EXIST.
> > > The test should fail
> if the
> > > function returns anything other than HFILE_ERROR as a failure. This is
> > >
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> >This patch corrects the test for OpenFile with a style of OF_EXIST. The
> > test should fail if the
> > function returns anything other than HFILE_ERROR as a failure. This is
> > based on
> > http://msdn.microsoft.com/library/default.asp?url=/
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "Oliver Stieber" <[EMAIL PROTECTED]> wrote:
>
> >This patch corrects the test for OpenFile with a style of OF_EXIST. The
> > test should fail if
> the
> > function returns anything other than HFILE_ERROR as a failure. This is
> > based on
>
Hi, I've been trying to locate an odd bug in the game Perimeter.
The crash happens when execution changes to x41 bytes into the ProcessHeap
structure, so I assume
that there's some stack corruption.
The last bit of the log looks like this: (with relay exclude of
ntdll.*;kernel32.*;gdi32.*)
000
"Oliver Stieber" <[EMAIL PROTECTED]> wrote:
>This patch corrects the test for OpenFile with a style of OF_EXIST. The
> test should fail if the
> function returns anything other than HFILE_ERROR as a failure. This is based
> on
> http://msdn.microsoft.com/library/default.asp?url=/library/en-u
Ray Jones wrote:
This patch:
breaks the MDAC Installation, no matter which version you attempt to install.
The patch changes the way dll overrides work, and is unlikely to be the
direct cause of the regression, you probably only need to adjust your
configuration a little.
If anyone lik
This patch:
___
===
RCS file: /home/wine/wine/dlls/ntdll/loadorder.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -p -r1.16 -r1.17
--- wine/dlls/ntdll/loadorder.c 2005/06/21 09:52:41 1.16
++
"Oliver Stieber" <[EMAIL PROTECTED]> wrote:
> MSDN Notes:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/openfile.asp
> If the function fails, the return value is HFILE_ERROR
>
> There's no reference to returning FALSE is OF_EXIST is passed as a parameter.
dlls/ker
On Mon, 2005-10-17 at 10:33 +0200, [EMAIL PROTECTED] wrote:
> Hi all,
>
> i posted a bug report last friday (10/14) about a nice shoot'em up called
> Warblade, complaining at startup :
>
> "err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable
> to
> dispatch exception."
>
"Vitaliy Margolen" [EMAIL PROTECTED] wrote:
> changelog:
> user/test:
> - Tests for broken behavior of ShowWindow for maximized popup windows.
> + todo_wine ok_sequence(WmCreateInvisibleMaxPopupSeq,
> "CreateWindow(WS_MAXIMIZED):popup", TRUE);
You don't need to use todo_wine for a failing o
James Hawkins <[EMAIL PROTECTED]> writes:
> diff -u -p -r1.35 path.c
> --- dlls/ntdll/path.c 11 Aug 2005 10:41:27 - 1.35
> +++ dlls/ntdll/path.c 15 Oct 2005 16:24:23 -
> @@ -421,6 +421,9 @@ BOOLEAN WINAPI RtlDosPathNameToNtPathNa
> if (!ntpath->Buffer) return FALSE;
>
Mike McCormack <[EMAIL PROTECTED]> writes:
> @@ -1176,18 +1176,7 @@ HRESULT WINAPI IShellLink_Constructor( I
>
> TRACE("(%p)->()\n",sl);
>
> - if (IsEqualIID(riid, &IID_IUnknown) ||
> - IsEqualIID(riid, &IID_IShellLinkA))
> - *ppv = sl;
> - else if (IsEqualIID(rii
Hi all,
i posted a bug report last friday (10/14) about a nice shoot'em up called
Warblade, complaining at startup :
"err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to
dispatch exception."
I searched the lists for other entries about this game, and found another bug
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> Any reason why this patch didn't go in? It does fix the reported bug and tests
> show the correct behavior.
You should only make a copy of the name when really necessary, to
avoid penalizing the common case.
--
Alexandre Julliard
[EMAIL PROTECTED]
23 matches
Mail list logo