Hi,
I've been trying to tackle some of the issues we have when trying to run
some process tests (through winetest.exe, see also
http://test.winehq.org/data):
process.c:775: Test failed: CreateProcess (./kernel32_test.exe
tests/process.c C:\TEMP\wt44.tmp "a\"b\\" c\" d) failed : 2
process.c:777: Test failed: Child process termination
process.c:781: Test failed: Arguments:argvA0 expected './kernel32_test.exe', got '(null)'
process.c:790: Test failed: CreateProcess (.\kernel32_test.exe tests/process.c C:\TEMP\wt45.tmp "a\"b\\" c\" d) failed : 2
process.c:792: Test failed: Child process termination
process.c:796: Test failed: Arguments:argvA0 expected '.\kernel32_test.exe', got '(null)'
process.c:810: Test failed: CreateProcess (..\wct12/kernel32_test.exe tests/process.c C:\TEMP\wt46.tmp "a\"b\\" c\" d) failed : 2
process.c:812: Test failed: Child process termination
process.c:816: Test failed: Arguments:argvA0 expected '..\wct12/kernel32_test.exe', got '(null)'
The reason for this particular one is that I'm running winetest.exe
started from a command-file on my desktop. This means that the current
directory is the desktop directory. The winetest gui shows that the
working directory is (in this case) c:\temp\wct12. This value is however
not passed to the tests when CreateProcess is run:
main.c:
291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0,
292 NULL, NULL, &si, &pi)) {
The above means that the kernel32_test.exe has a working directory that
is not c:\temp\wct12 (in this case again) and thus cannot find the
executable when referenced relatively.
All the test-results that are shown on http://test.winehq.org show
more-or-less the same behavior.
How can I retrieve the correct working directory (as shown in the
winetest gui) and pass that to the single tests? (I think that would
solve these particular issues).
Cheers and thanks for any pointers,
Paul.
The topic of getting OpenGL to show and use more visuals/pixel formats than
just the one the main window uses came up on IRC, and I was told to make a
post here. One of the ideas was to create a child window of the main X window
(which can be given a different visual) and have OpenGL use that for drawing.
A simple test program I wrote (using X) seems to behave well. The child window
stays relative to the parent, it remains fully connected (even with the
wobbly effects of compositors like Beryl), and it can use a different visual.
Since wgl is now a part of x11drv, it should be possible to make an X11 child
window. Are there any problems with using this approach in Wine?
"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote:
> As Dmitry Timoshkov (thanks for that) the SetLastError was not necessary.
> Here's updated patch.
Probably the problem is that you need also handle both FindResourceW and
LoadResource failures the same way by returning -1, and change 'return -1;'
later to 'return 0;' (for invalid parent) as MSDN suggests. All that needs
to be tested as well. Also DialogBoxParamW needs to be fixed as well.
Probably other dialaog APIs (like DialogBoxIndirectParamAorW) need a review
regarding that.
--
Dmitry.
Hi,
On Sun, Dec 31, 2006 at 05:28:23PM +0800, Dmitry Timoshkov wrote:
> Hello,
>
> Running RedAlert demo spits a lot of FIXMEs about converting errno 29
> (ESPIPE) to STATUS_UNSUCCESSFUL. In Linux /usr/include/asm/errno.h has
> a comment /* Illegal seek */ for ESPIPE, so STATUS_ILLEGAL_FUNCTION seems
> to be the best choice.
>
> Changelog:
> ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION.
The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't
indicate at all that it's supposed to be pipe-related
(however it's within the numeric range of many other pipe status codes!).
So, given that this is mainly a pipe status code after all I'd say that's
the best we can achieve right now.
Of course, what really matters is what the receiving Win32 side *usually*
expects after we encountered ESPIPE, and this might turn out to differ
from your conversion ;).
(is there any indication that RedAlert checks for a specific status code??)
Andreas Mohr
"Roderick Colenbrander" <thunderbird2k(a)gmx.net> wrote:
> This patch removes the DesktopDoubleBuffered option.
Support for this option should be removed from winecfg simultaneously
with this change.
--
Dmitry.
for almost a week now, wine has been acting weird. I compile wine and
using it from the wine source tree, everything works perfectly. But
if I make install it, then try to use it, all I get is a black screen
that I have to alt-tab to get out of. On a note, it works fine if I
run as root. I have blown away my .wine directory, it doesn't help.
I compile from git.
Corey McClymonds
On 12/28/06, Colin Pitrat <colin.pitrat(a)bull.net> wrote:
> Hi,
>
> here is a patch I sent a few weeks ago implementing two functions in
> msxml.dll, and the corresponding test.
>
I suggest sending the tests in one patch first, then send each
function in a separate patch afterwards.
--
James Hawkins
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: c5b8df481f2bb0362b57188a8c7df423030ba8b0
> URL: http://source.winehq.org/git/wine.git/?a=commit;h=c5b8df481f2bb0362b57188a8…
>
> Author: Vijay Kiran Kamuju <infyquest(a)gmail.com>
> Date: Sun Dec 24 13:31:56 2006 +0530
>
> comctl32: MonthCalendar - Fix highlighting of current date.
That does highlight the current date on startup. But I notice that when
I click another date, the current date doesn't get unhighlighted.
On 12/30/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote:
>
> This patch blocks riched20 from recursivly sending an EN_CHANGE
> notification.
> Fixes bug 6985.
>
> Thanks,
> Clinton Stimpson
>
> ChangeLog
> Block recursive EN_CHANGE notifications.
If you're adding a new variable to the ME_TextEditor structure then
you should probably also initialize it in ME_MakeEditor.
Naming the variable "notify" is somewhat ambiguous, and there seems to
be an established convention of naming int's with the 'n' prefix, like
nNotifiy. You should probably comment to explain what the variable is
for or attempt to name it something more self evident. Maybe a BOOL
would be more appropriate, unless you're intending to extend this to
other notify calls as well.
Lastly, I don't see why this patch is needed - it only prevents the
ME_SendOldNotify (which just calls SendMessageA) from triggering
another call of that same EN_CHANGE notification. I don't see why
calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe
the application you're working with, in processing the EN_CHANGE
message, is sending another message to which we wrongly are sending an
EN_CHANGE notification - so thus we should fix our message handling of
that.
A quick look at MSDN shows that "The EN_CHANGE notification message is
sent when the user has taken an action that may have altered text in
an edit control." - it seems that we may be sending them whenever any
action (user or not) has altered text in the control. We really could
use some tests to see what should generate EN_CHANGE messages.
Another possibility is that we don't handle the case where (again,
from MSDN) "The EN_CHANGE notification is not sent when the
ES_MULTILINE style is used and the text is sent through WM_SETTEXT." -
perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in
response to the EN_CHANGE notification?
Thanks for your help with richedit,
--Matt Finnicum
On Sat, Dec 30, 2006 at 04:49:27AM +0100, Bernard Ladenthin wrote:
> Hello,
> in the attachment is a small patch for the OleIconToCursor function.
> The function works with this. I hope i can help with this and get a
> response mail that this mail have received. I haven't any experiences
> with git so it's a simply patch.
>
> I have tested it with the "Lexware Buchhalter 2005".
> You can download it from http://server.ladenthin.net/bh2005.zip to see
> that it works. Start with wine the "LxStart.exe" and turn over the
> Text and Icon with the mouse, the icon is now the cursor.
>
> Best regards from Germany,
> Bernard Ramon Ladenthin
In general you do no need to edit Changelog yourself. Just add a note
above the patch.
Otherwise it looks fine to my eyes (and perhaps Alexandres too), thanks!
Ciao, Marcus
> diff --git a/ChangeLog b/ChangeLog
> index 3b536b5..9723401 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2006-12-30 Bernard Ramon Ladenthin <bernard(a)ladenthin.net>
> +
> + * dlls/oleaut32/oleaut.c, dlls/oleaut32/stubs.c:
> + oleaut32: Implement the function OleIconToCursor and remove the stub.
> +
> 2006-12-22 Dmitry Timoshkov <dmitry(a)codeweavers.com>
>
> * dlls/user32/tests/msg.c, dlls/winex11.drv/winpos.c:
> diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c
> index d6a08a9..65a4174 100644
> --- a/dlls/oleaut32/oleaut.c
> +++ b/dlls/oleaut32/oleaut.c
> @@ -837,3 +837,19 @@ BOOL WINAPI DllMain(HINSTANCE hInstDll,
>
> return TRUE;
> }
> +
> +/***********************************************************************
> + * OleIconToCursor (OLEAUT32.415)
> + */
> +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon)
> +{
> + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon);
> + if (hIcon)
> + return CopyCursor(hIcon);
> + else
> + return NULL;
> +
> + /* FIXME
> + make a extended conversation from HICON to HCURSOR
> + */
> +}
> diff --git a/dlls/oleaut32/stubs.c b/dlls/oleaut32/stubs.c
> index ac2d494..d87e76e 100644
> --- a/dlls/oleaut32/stubs.c
> +++ b/dlls/oleaut32/stubs.c
> @@ -33,15 +33,6 @@
> WINE_DEFAULT_DEBUG_CHANNEL(ole);
>
> /***********************************************************************
> - * OleIconToCursor (OLEAUT32.415)
> - */
> -HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hicon)
> -{
> - FIXME("(%p,%p), not implemented (olepro32.dll)\n",hinstExe,hicon);
> - return S_OK;
> -}
> -
> -/***********************************************************************
> * OleCreatePropertyFrameIndirect (OLEAUT32.416)
> */
> HRESULT WINAPI OleCreatePropertyFrameIndirect( LPOCPFIPARAMS lpParams)
>