Re: Patchwatcher online
On Sat, Aug 9, 2008 at 9:01 PM, Dan Kegel <[EMAIL PROTECTED]> wrote: > For the moment, the results only go to a web page, > http://kegel.com/wine/patchwatcher/results/ > Most of the results there right now are just test messages > so you can see how it will look when real patches > with various problems are received. > > The scripts are a bit ugly, so expect problems to linger > for the next week or so while I work out the kinks. I just noticed Ambroz actually came through with the chroot: http://article.gmane.org/gmane.comp.emulators.wine.devel/62314 I had already moved to using a separate userid, and switched to a very low-privilege way of uploading results, so my security story is probably ok for a little while, but I'll try to integrate the chroot one of these days soon for even more protection.
Patchwatcher online
For the moment, the results only go to a web page, http://kegel.com/wine/patchwatcher/results/ Most of the results there right now are just test messages so you can see how it will look when real patches with various problems are received. The scripts are a bit ugly, so expect problems to linger for the next week or so while I work out the kinks.
Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
> Then I should end up with errors on my WindowsXP system that match yours. I
> don't have time tonight to do so, but my find time tomorrow to run them.
Oops, I realized I should have been more clear. I mean the tests in
general fail on my XP system. I just ran the riched20 tests, though,
so you can compare:
editor.c:367: Test failed: 120 != 121
editor.c:1272:EM_STREAMOUT produced:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0
System;}}
\viewkind4\uc1\pard\b\f0\fs19 TestSomeText\par
}
editor.c:1528:EM_STREAMOUT produced:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fprq2\fcharset0
System;}}
\viewkind4\uc1\pard\b\f0\fs19 TestSomeText\par
}
editor.c:2813:EM_SETTEXTEX is supported on this platform
editor.c:2088:Testing EM_REPLACESEL behavior with redraw=1
editor.c:2088:Testing EM_REPLACESEL behavior with redraw=0
editor: 825 tests executed (0 marked as todo, 1 failure), 0 skipped.
--Juan
Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
Juan Lang <[EMAIL PROTECTED]> on Aug 9, 2008 8:27 PM (PNT) wrote additionally in reply to Question: Why are EM_FORMATRANGE Tests 'To Do' > >> Thank you for the clarification. Thus, I can run the pre-built executable >> on WindowsXP and there should be no richedit errors, correct? > >That's the theory :) The test don't run without error on my XP system, so >YMMV. Then I should end up with errors on my WindowsXP system that match yours. I don't have time tonight to do so, but my find time tomorrow to run them. James McKenzie
Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
> Thank you for the clarification. Thus, I can run the pre-built executable on > WindowsXP and there should be no richedit errors, correct? That's the theory :) The test don't run without error on my XP system, so YMMV. --Juan
Re: rpcrt4: [1/2] Improve stub for I_RpcBindingInqTransportType, with test
Detlef Riekenberg <[EMAIL PROTECTED]> wrote:
> @@ -848,6 +848,10 @@ RPC_STATUS WINAPI I_RpcBindingInqTransportType(
> RPC_BINDING_HANDLE Binding, unsi
> {
>
>FIXME( "(%p,%p): stub\n", Binding, Type);
> +
> + /* NT: RPC_S_NO_CONTEXT_AVAILABLE, 9x: RPC_S_NO_CALL_ACTIVE */
> + if (!Binding) return RPC_S_NO_CONTEXT_AVAILABLE;
According to your test this should be
if (!Binding || !Type) return RPC_S_NO_CONTEXT_AVAILABLE;
Also the comment doesn't belong here, it's ok to have in the test though.
--
Dmitry.
Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
Juan Lang <[EMAIL PROTECTED]> on Aug 9, 2008 6:41 PM wrote about Question: Why are EM_FORMATRANGE Tests 'To Do' in reply to James McKenzie's question on this subject. > >Hi James, > >> Title states it all. I would like to compile tests to run against WindowsXP >> to see if the test will function. Could I un'to-do' this test and compile >> it with MinGW? > >todo_wine tests are always run, whether or not the todo_wine flag is >there. The only difference is how the results are interpreted: if >running on Wine (which the standalone tests assume they are not), the >test is assumed to fail, and an error reported if the test does not >fail as expected on Wine. If not running on Wine, they run as normal. Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? James McKenzie
Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
Hi James, > Title states it all. I would like to compile tests to run against WindowsXP > to see if the test will function. Could I un'to-do' this test and compile it > with MinGW? todo_wine tests are always run, whether or not the todo_wine flag is there. The only difference is how the results are interpreted: if running on Wine (which the standalone tests assume they are not), the test is assumed to fail, and an error reported if the test does not fail as expected on Wine. If not running on Wine, they run as normal. --Juan
Question: Why are EM_FORMATRANGE Tests 'To Do'
Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? Thank you. James McKenzie
Re: DIB engine status
On Fr, 2008-08-01 at 12:56 +0100, Huw Davies wrote: > Hi folks, > > Here's an update on the DIB engine that I've been working on for the > last few months. This work has been made possible by the generosity > of Google - so thanks go to them and of course to Dan. > > You can find the code at http://repo.or.cz/w/wine/dibeng-hd.git Thanks for picking up the dib-engine issue. > What needs to be done > = > - Lots more... The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers) IMHO, every other attemp to implement a DIB-Engine is a waste of time. Marcel did some work last Year during SoC with the correct API (Eng* and friends) but also in the wrong location (he used wineddi.drv) -- By by ... Detlef
Re: debugging applications Re: Networking problems with IDU Verwaltung software
On Fr, 2008-08-08 at 16:51 +0200, Werner LEMBERG wrote: > > Investigate the RelayInclude and RelayExclude string values in > [HKCU\Software\Wine\Debug] if you're being overwhelmed by certain > functions. [...] > > I suppose this is a registry entry, right? Yes. HKCU (or HCU) is: HKEY_CURRENT_USER > Perhaps one or two sentences can be added to mention this, > together with an explanation > which program should be used to change those settings. You change the registry with: regedit (wine provide an own implementation) Patches are welcome. The source of the website is managed with git: http://source.winehq.org/git/website.git (templates/en/*) Thanks for helping Wine -- By by ... Detlef
Re: Make RegisterDeviceNotificationW behave likeRegisterDeviceNotificationA
> So is there anything I should do now? Or just wait to see what happens? Wait, as Alexandre's on vacation until the 18th. He'll probably commit this after he gets back, but if you notice a bunch of things getting committed and yours did not and did not get any feedback from him, you can ask again. --Juan
Re: [1/11] ole32 : basic inprocess handler implentation
On Do, 2008-08-07 at 15:45 +0200, [EMAIL PROTECTED] wrote: > This patch modifies the Makefile.in file to include some new file to be > compile - You must use your real name - Wine must compile after every Patch. You need to add the changes for Makefile.in, when you add a file - Why do you need to use sed for winuser.h? When the input for widl is correct and the output of widl is wrong, then widl must be fixed instead. - You forgot the License-Header in the new files. Wine is LGPL. -- quote -- 2.1 of the License, or (at your option) any later version. -- quote -- - The subject is not very precise. You should use the description, that is already in your Mail. Example for [4/11]: "Main core file for inprocess handler implementation" - Some Patches are large, please try to split it. - Some lines in your Patches are very long, please try to split them. - Do not use C++ style comments - Wine is using 4 Space for indention. The only exception is to stay with the indention of File, when you touch that File - No Idea, if the change in 8/11 is acceptable, but you should a comment in the code, when you make such a change. - A Hack, to workaround a bug in widl will not be accepted. Widl must be fixed instead. - Unrelated to the fact, that the Hack in 10/11 will not be accepted, you must make sure, not add spaces at the end of a Line. - When you change the imlementation, that fix a test, then both changes must be in the same Patch Thanks for helping Wine -- By by ... Detlef
Re: Make RegisterDeviceNotificationW behave likeRegisterDeviceNotificationA
Dmitry Timoshkov wrote: >"Zachary Goldberg" wrote: > >> Your patch is more likely to be accepted if it comes with a test which >> works on windows, didnt pass in wine before but passes now and >> demonstrates why the new behavior is correct. > > There is no need for a test since that's not really an implementation > but just a better stub which follows existing code. So is there anything I should do now? Or just wait to see what happens? As for writing a test, I don't think that's possible. The affected apps don't crash inside that function but shortly afterwards. It's just that the crash is affected by the result of RegisterDeviceNotificationW. Wouldn't it also be more consistent, if *A and *W did the same thing? Martin -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
Re: taskmgr [try 4]: Converted some functions and variables to Unicode [1/7]
Vladimir Pankratov wrote:
> static void TaskManager_OnMenuSelect(HWND hWnd, UINT nItemID, UINT nFlags,
> HMENU hSysMenu)
> {
> -TCHAR str[100];
> +WCHAR wstr[256];
> +WCHAR wszEmptyStr[] = {' ',0};
>
> -_tcscpy(str, TEXT(""));
> -if (LoadString(hInst, nItemID, str, 100)) {
> -/* load appropriate string */
> -LPTSTR lpsz = str;
> -/* first newline terminates actual string */
> -lpsz = _tcschr(lpsz, '\n');
> -if (lpsz != NULL)
> -*lpsz = '\0';
> -}
> -SendMessage(hStatusWnd, SB_SETTEXT, 0, (LPARAM)str);
> +strcpyW(wstr, wszEmptyStr);
> +LoadStringW(hInst, nItemID, wstr, sizeof(wstr)/sizeof(WCHAR));
> +SendMessageW(hStatusWnd, SB_SETTEXTW, 0, (LPARAM)wstr);
> }
>
> static void TaskManager_OnViewUpdateSpeedHigh(void)
You really need a single space string passed as message parameter?
If not - WCHAR wszEmptyStr[] = {0} - should be enough. And maybe it's
better to initialize wstr to empty instead of using another variable.
