RE: ADVAPI32: Start test for service tests
James Hawkins [mailto:[EMAIL PROTECTED] wrote: +ok(size = 1, size should be = 1 was %d!, size); This is a bad test. According to msdn, GetServiceDisplayName does not modify lpcchBuffer on error, so size should be exactly 0. MSDN says a lot of things. On my XP SP2 it returns 1 as size when passed an empty service name. Also failing here is a bit ambigeuos since the dunction also fails when a NULL pointer is passed or the buffer is to small, but it does change the size into what it expects in these two cases. +static BOOL test_service_info(SC_HANDLE hscm) test functions are void, not BOOL. You're never going to do anything but return, and there's no value to check by the caller. I took this more or less directly from registry.c in the same directory. +ok(size, size should be returned!); And what is the size? Tests are supposed to be exact. If our implementation is incorrect, and we return size as 39491, that's certainly not correct, but this test won't fail when it should. This won't work for localized Windows versions. The display name is possibly translated. Also, on XP SP2 the A function returns the size in ASCI chars that the W function will need in bytes. Not a behaviour I feel Wine should imitate without an app that would need that behaviour. I'll be gone for two weeks for vacation. If anyone wants to continue on that please feel free. Otherwise I'll be picking this up afterwards. Rolf Kalbermatter
Re: shlwapi: stub implementation for SHSetTimerQueueTimer (try 2)
Nigel Liang [EMAIL PROTECTED] wrote:
+HANDLE WINAPI SHSetTimerQueueTimer(HANDLE hQueue,
+WAITORTIMERCALLBACK pfnCallback, LPVOID pContext, DWORD dwDueTime,
+DWORD dwPeriod, LPCSTR lpszLibrary, DWORD dwFlags)
+{
...
+return CreateTimerQueueTimer(hNewTimer, hQueue, pfnCallback, pContext,
+dwDueTime, dwPeriod, dwFlags)?hNewTimer:NULL;
This can't work: CreateTimerQueueTimer and SHSetTimerQueueTimer
return different things.
--
Dmitry.
Re: localui/tests: Add tests for ConfigurePortUI
Detlef Riekenberg [EMAIL PROTECTED] writes: diff --git a/dlls/localui/tests/Makefile.in b/dlls/localui/tests/Makefile.in index 191a312..634060b 100644 --- a/dlls/localui/tests/Makefile.in +++ b/dlls/localui/tests/Makefile.in @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. SRCDIR= @srcdir@ VPATH = @srcdir@ TESTDLL = localui.dll -IMPORTS = kernel32 +IMPORTS = kernel32 msvcrt winspool You can't import msvcrt without using the headers and the appropriate compiler flags. It would be much better to avoid it though. -- Alexandre Julliard [EMAIL PROTECTED]
Re: review: add Video Memory text input to winecfg Graphics/Direct3D tab
On Wed, May 16, 2007 at 06:41:33PM +0200, Frank Richter wrote: just add all preset memory sizes, and WM_SETTEXT the value read from the registry. Might be code-wise a bit simpler than your GETCURSEL approach, but otherswise not much different I think. -f.r. Hi Frank, I've simplified the code according Your review, see the attached patch. Thanks for help. Vit diff --git a/programs/winecfg/Bg.rc b/programs/winecfg/Bg.rc index 302bec5..a2580a3 100644 --- a/programs/winecfg/Bg.rc +++ b/programs/winecfg/Bg.rc @@ -90,6 +90,8 @@ BEGIN COMBOBOX IDC_D3D_VSHADER_MODE,115,218,125,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Đŕçđĺřč Pixel Shader (ŕęî ńĺ ďîääúđćŕ îň őŕđäóĺđŕ),IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,237,230,10 +LTEXT Video Memory Size (in megabytes):,IDC_STATIC,15,232,120,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE END IDD_DLLCFG DIALOG DISCARDABLE 0, 0, 260, 250 diff --git a/programs/winecfg/Cs.rc b/programs/winecfg/Cs.rc index 5bba698..07ba100 100644 --- a/programs/winecfg/Cs.rc +++ b/programs/winecfg/Cs.rc @@ -88,6 +88,8 @@ BEGIN COMBOBOX IDC_D3D_VSHADER_MODE,105,197,140,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Povolit stínování pixelů (spoléhá se na hardware podporu),IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,216,230,10 +LTEXT Velikost videopaměti (v megabytech):,IDC_STATIC,15,232,140,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,145,232,40,112,CBS_DROPDOWN | WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE END IDD_DLLCFG DIALOG DISCARDABLE 0, 0, 260, 250 @@ -244,8 +246,8 @@ END STRINGTABLE DISCARDABLE BEGIN -IDS_SHADER_MODE_HARDWAREHardwarový -IDS_SHADER_MODE_NONEádný +IDS_SHADER_MODE_HARDWAREPodporováno zařízením +IDS_SHADER_MODE_NONEádná END STRINGTABLE DISCARDABLE diff --git a/programs/winecfg/De.rc b/programs/winecfg/De.rc index 8c77b2b..9741a48 100644 --- a/programs/winecfg/De.rc +++ b/programs/winecfg/De.rc @@ -84,6 +84,8 @@ BEGIN COMBOBOXIDC_D3D_VSHADER_MODE,140,197,105,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Pixel Shader aktivieren (wenn von Hardware unterstützt), IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,212,230,10 +LTEXT Größe des Grafikspeichers(in Megabytes),IDC_STATIC,15,232,140,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,150,232,40,112,CBS_DROPDOWN | WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE END IDD_DLLCFG DIALOG DISCARDABLE 0, 0, 260, 250 diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc index 02d4850..218150a 100644 --- a/programs/winecfg/En.rc +++ b/programs/winecfg/En.rc @@ -79,12 +79,14 @@ BEGIN EDITTEXTIDC_DESKTOP_WIDTH,64,167,40,12,ES_AUTOHSCROLL | ES_NUMBER | WS_DISABLED EDITTEXTIDC_DESKTOP_HEIGHT,117,167,40,12,ES_AUTOHSCROLL | ES_NUMBER | WS_DISABLED -GROUPBOX Direct3D ,IDC_STATIC,8,189,244,50 +GROUPBOX Direct3D ,IDC_STATIC,8,189,244,60 LTEXT Vertex Shader Support: ,IDC_STATIC,15,199,80,30 COMBOBOX IDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Allow Pixel Shader (if supported by hardware),IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,216,230,10 +LTEXT Video Memory Size (in megabytes):,IDC_STATIC,15,232,120,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE END IDD_DLLCFG DIALOG DISCARDABLE 0, 0, 260, 250 diff --git a/programs/winecfg/Es.rc b/programs/winecfg/Es.rc index 2430b02..d7dea8b 100644 --- a/programs/winecfg/Es.rc +++ b/programs/winecfg/Es.rc @@ -83,6 +83,8 @@ BEGIN COMBOBOXIDC_D3D_VSHADER_MODE,100,197,145,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Permitir Pixel Shader (si hay soporte por hardware),IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,216,230,10 +LTEXT Video Memory Size (in megabytes):,IDC_STATIC,15,232,120,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | WS_VSCROLL | WS_TABSTOP | CBS_LOWERCASE END IDD_DLLCFG DIALOG DISCARDABLE 0, 0, 260, 250 diff --git a/programs/winecfg/Fi.rc b/programs/winecfg/Fi.rc index 16da0ca..f8f8180 100644 --- a/programs/winecfg/Fi.rc +++ b/programs/winecfg/Fi.rc @@ -84,6 +84,8 @@ BEGIN COMBOBOX IDC_D3D_VSHADER_MODE,100,218,150,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Salli Pixel Shader:n käyttö laitteiston tukiessa,IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,237,230,10 +LTEXT Video Memory Size (in megabytes):,IDC_STATIC,15,232,120,12 +COMBOBOXIDC_VIDEOMEMORY_SIZE_COMBO,130,232,40,112,CBS_DROPDOWN | WS_VSCROLL
Re: hnetcfg: [resend 2] 3/6 add local header file
Jeff Latimer wrote: --- dlls/hnetcfg/hnetcfg_dll.h | 70 1 files changed, 70 insertions(+), 0 deletions(-) create mode 100644 dlls/hnetcfg/hnetcfg_dll.h diff --git a/dlls/hnetcfg/hnetcfg_dll.h b/dlls/hnetcfg/hnetcfg_dll.h new file mode 100644 index 000..64b1f0c --- /dev/null +++ b/dlls/hnetcfg/hnetcfg_dll.h @@ -0,0 +1,70 @@ +/* + * Copyright (C) 2007 Jeff Latimer + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#ifndef __WINE_HNETCFG_DLL_H +#define __WINE_HNETCFG_DLL_H + +#include windef.h +#include wine/debug.h +#include winbase.h +#include winnt.h + + +/* __stdcall HNETCFG_HNetDeleteRasConnection(); */ It's only the comments but why don't you use WINAPI instead of __stdcall? bye michael +/* __stdcall HNETCFG_HNetFreeSharingServicesPage(); */ +/* __stdcall HNETCFG_HNetGetSharingServicesPage(); */ +/* __stdcall HNETCFG_WinBomConfigureWindowsFirewall(); */ +/* __stdcall HNETCFG_HNetFreeFirewallLoggingSettings(); */ +/* __stdcall HNETCFG_HNetGetFirewallSettingsPage(); */ +/* __stdcall HNETCFG_HNetGetShareAndBridgeSettings(); */ +/* __stdcall HNETCFG_HNetSetShareAndBridgeSettings(); */ +/* __stdcall HNETCFG_HNetSharedAccessSettingsDlg(); */ +/* __stdcall HNETCFG_HNetSharingAndFirewallSettingsDlg(); */ +/* __stdcall HNETCFG_IcfChangeNotificationCreate(); */ +/* __stdcall HNETCFG_IcfChangeNotificationDestroy(); */ +/* __stdcall HNETCFG_IcfCheckAppAuthorization(); */ +/* __stdcall HNETCFG_IcfCloseDynamicFwPort(); */ +/* __stdcall HNETCFG_IcfConnect(); */ +/* __stdcall HNETCFG_IcfDisconnect(); */ +/* __stdcall HNETCFG_IcfFreeAdapters(); */ +/* __stdcall HNETCFG_IcfFreeDynamicFwPorts(); */ +/* __stdcall HNETCFG_IcfFreeProfile(); */ +/* __stdcall HNETCFG_IcfFreeString(); */ +/* __stdcall HNETCFG_IcfFreeTickets(); */ +/* __stdcall HNETCFG_IcfGetAdapters(); */ +/* __stdcall HNETCFG_IcfGetCurrentProfileType(); */ +/* __stdcall HNETCFG_IcfGetDynamicFwPorts(); */ +/* __stdcall HNETCFG_IcfGetOperationalMode(); */ +/* __stdcall HNETCFG_IcfGetProfile(); */ +/* __stdcall HNETCFG_IcfGetTickets(); */ +/* __stdcall HNETCFG_IcfIsIcmpTypeAllowed(); */ +/* __stdcall HNETCFG_IcfIsPortAllowed(); */ +/* __stdcall HNETCFG_IcfOpenDynamicFwPort(); */ +/* __stdcall HNETCFG_IcfOpenDynamicFwPortWithoutSocket(); */ +/* __stdcall HNETCFG_IcfOpenFileSharingPorts(); */ +/* __stdcall HNETCFG_IcfRefreshPolicy(); */ +/* __stdcall HNETCFG_IcfRemoveDisabledAuthorizedApp(); */ +/* __stdcall HNETCFG_IcfSetServicePermission(); */ +/* __stdcall HNETCFG_IcfSubNetsGetScope(); */ +/* __stdcall HNETCFG_IcfSubNetsIsStringValid(); */ +/* __stdcall HNETCFG_IcfSubNetsToString(); */ + +HRESULT NetFwMgr_create(IUnknown *, LPVOID *); + + +#endif /* __WINE_HNETCFG_DLL_H */ -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: hnetcfg: [resend 2] 1/6 uuids for INetFwMgr interface
Jeff Latimer wrote: diff --git a/include/uuids.h b/include/uuids.h index e3fb41b..cf99672 100644 --- a/include/uuids.h +++ b/include/uuids.h @@ -271,5 +271,7 @@ OUR_GUID_ENTRY(CLSID_VideoProcAmpPropertyPage, 0x71f96464, 0x78f3, 0x11d0, OUR_GUID_ENTRY(CLSID_CameraControlPropertyPage, 0x71f96465, 0x78f3, 0x11d0, 0xa1, 0x8c, 0x00, 0xa0, 0xc9, 0x11, 0x89, 0x56) OUR_GUID_ENTRY(CLSID_AnalogVideoDecoderPropertyPage, 0x71f96466, 0x78f3, 0x11d0, 0xa1, 0x8c, 0x00, 0xa0, 0xc9, 0x11, 0x89, 0x56) OUR_GUID_ENTRY(CLSID_VideoStreamConfigPropertyPage, 0x71f96467, 0x78f3, 0x11d0, 0xa1, 0x8c, 0x00, 0xa0, 0xc9, 0x11, 0x89, 0x56) +OUR_GUID_ENTRY(IID_INetFwMgr,0xf7898af5, 0xcac4, 0x4632, 0xa2, 0xec, 0xda ,0x06, 0xe5, 0x11, 0x1a, 0xf2) +OUR_GUID_ENTRY(CLSID_NetFwMgr, 0x304ce942, 0x6e39, 0x40d8, 0x94, 0x3a, 0xb9, 0x13, 0xc4, 0x0c, 0x9c, 0xd4) #undef OUR_GUID_ENTRY This isn't in the PSDK version of uuids.h and also uuid.lib from the PSDK doesn't contain these symbols either (although there are a bunch of IID_INetFwV6... symbols that might be related). -- Rob Shearman
re: msi ole automation: where to next?
Misha wrote: [I have the scripting required by the Vector NTI and the iTunes 7 installers working. What should I do next?] First off, congratulations! If you're interested in continuing to work on MSI, I'd suggest asking James Hawkins for suggestions. If you're more interested in adding COM interfaces to things, perhaps implementing the iTextServices api to riched20 would be useful. Maarten got started on that, but I think it's not complete enough for say, Google Talk to function. Most useful of all might be for you to look at improving our COM implementation itself. Rob Shearman could give you suggestions on where to start there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: [PATCH 2/2] wininet: Implement basic non-proxy authentiction.
On Mo, 2007-05-21 at 14:28 +0100, Robert Shearman wrote: +int userlen = WideCharToMultiByte(CP_UTF8, 0, domain_and_username, lstrlenW(domain_and_username), NULL, 0, NULL, NULL); +int passlen = WideCharToMultiByte(CP_UTF8, 0, password, lstrlenW(password), NULL, 0, NULL, NULL); What is the advantage to use lstrlenW() here over -1, as used below? + +WideCharToMultiByte(CP_UTF8, 0, domain_and_username, -1, auth_data, userlen, NULL, NULL); +auth_data[userlen] = ':'; +WideCharToMultiByte(CP_UTF8, 0, password, -1, auth_data[userlen+1], passlen, NULL, NULL); Using -1 has the advantage to reduce the code-size. Thanks. -- By by ... Detlef
localui/tests: Add tests for ConfigurePortUI (try 2)
Changelog:
localui/tests: Add tests for ConfigurePortUI
Removed the implicit import of msvcrt, as suggested by Alexandre
(Replaced swprintf by sprintf with MultiByteToWideChar as
Alexandre did in serialui/tests)
--
By by ... Detlef
From 3ec5c52ce8f27f41543e54ab5771f5e5faca3deb Mon Sep 17 00:00:00 2001
From: Detlef Riekenberg [EMAIL PROTECTED]
Date: Mon, 21 May 2007 17:50:29 +0200
Subject: [PATCH] localui/tests: Add tests for ConfigurePortUI
---
dlls/localui/tests/Makefile.in |2
dlls/localui/tests/localui.c | 175
2 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/dlls/localui/tests/Makefile.in b/dlls/localui/tests/Makefile.in
index 191a312..8532af8 100644
--- a/dlls/localui/tests/Makefile.in
+++ b/dlls/localui/tests/Makefile.in
@@ -3,7 +3,7 @@ TOPOBJDIR = ../../..
SRCDIR= @srcdir@
VPATH = @srcdir@
TESTDLL = localui.dll
-IMPORTS = kernel32
+IMPORTS = kernel32 winspool
CTESTS = \
localui.c
diff --git a/dlls/localui/tests/localui.c b/dlls/localui/tests/localui.c
index e3a1813..4c5e769 100644
--- a/dlls/localui/tests/localui.c
+++ b/dlls/localui/tests/localui.c
@@ -20,11 +20,13 @@
*/
#include stdarg.h
+#include stdio.h
#include windef.h
#include winbase.h
#include winerror.h
#include wingdi.h
+#include winnls.h
#include winreg.h
#include winspool.h
@@ -42,6 +44,51 @@ static BOOL (WINAPI *pAddPortUI)(PCWSTR
static BOOL (WINAPI *pConfigurePortUI)(PCWSTR, HWND, PCWSTR);
static BOOL (WINAPI *pDeletePortUI)(PCWSTR, HWND, PCWSTR);
+static WCHAR does_not_existW[] =
{'d','o','e','s','_','n','o','t','_','e','x','i','s','t',0};
+static WCHAR emptyW[] = {0};
+static CHAR fmt_comA[] = {'C','O','M','%','u',':',0};
+static CHAR fmt_lptA[] = {'L','P','T','%','u',':',0};
+static WCHAR portname_fileW[] = {'F','I','L','E',':',0};
+
+static LPBYTE pi_buffer;
+static DWORD pi_numports;
+static DWORD pi_needed;
+
+static PORT_INFO_2W * lpt_present;
+static PORT_INFO_2W * com_present;
+static PORT_INFO_2W * file_present;
+
+static LPWSTR lpt_absent;
+static LPWSTR com_absent;
+
+/* ### */
+
+static PORT_INFO_2W * find_portinfo2(LPWSTR pPort)
+{
+PORT_INFO_2W * pi;
+DWORD res;
+
+if (!pi_buffer) {
+res = EnumPortsW(NULL, 2, NULL, 0, pi_needed, pi_numports);
+pi_buffer = HeapAlloc(GetProcessHeap(), 0, pi_needed);
+SetLastError(0xdeadbeef);
+res = EnumPortsW(NULL, 2, pi_buffer, pi_needed, pi_needed,
pi_numports);
+}
+if (pi_buffer) {
+pi = (PORT_INFO_2W *) pi_buffer;
+res = 0;
+while (pi_numports res) {
+if (lstrcmpiW(pi-pPortName, pPort) == 0) {
+return pi;
+}
+pi++;
+res++;
+}
+}
+return NULL;
+}
+
+
/* ### */
static LPCSTR load_functions(void)
@@ -59,6 +106,96 @@ static LPCSTR load_functions(void)
return NULL;
}
+/* ###
+ * strdupW [internal]
+ */
+
+static LPWSTR strdupW(LPCWSTR strW)
+{
+LPWSTR ptr;
+
+ptr = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(strW) + 1) * sizeof(WCHAR));
+if (ptr) {
+lstrcpyW(ptr, strW);
+}
+return ptr;
+}
+
+/* ### */
+
+static void test_ConfigurePortUI(void)
+{
+DWORD res;
+
+/* not present before w2k */
+if (!pConfigurePortUI) {
+skip(ConfigurePortUI not found\n);
+return;
+}
+
+SetLastError(0xdeadbeef);
+res = pConfigurePortUI(NULL, NULL, NULL);
+ok( !res (GetLastError() == ERROR_UNKNOWN_PORT),
+got %d with %u (expected '0' with ERROR_UNKNOWN_PORT)\n,
+res, GetLastError());
+
+
+SetLastError(0xdeadbeef);
+res = pConfigurePortUI(NULL, NULL, emptyW);
+ok( !res (GetLastError() == ERROR_UNKNOWN_PORT),
+got %d with %u (expected '0' with ERROR_UNKNOWN_PORT)\n,
+res, GetLastError());
+
+
+SetLastError(0xdeadbeef);
+res = pConfigurePortUI(NULL, NULL, does_not_existW);
+ok( !res (GetLastError() == ERROR_UNKNOWN_PORT),
+got %d with %u (expected '0' with ERROR_UNKNOWN_PORT)\n,
+res, GetLastError());
+
+
+if (winetest_interactive lpt_present) {
+SetLastError(0xdeadbeef);
+res = pConfigurePortUI(NULL, NULL, lpt_present-pPortName);
+ok( res ||
+(GetLastError() == ERROR_CANCELLED) || (GetLastError() ==
ERROR_ACCESS_DENIED),
+got %d with %u (expected '!= 0' or '0' with: ERROR_CANCELLED or
+ERROR_ACCESS_DENIED)\n, res, GetLastError());
+}
+
+if (lpt_absent) {
+SetLastError(0xdeadbeef);
+res = pConfigurePortUI(NULL, NULL, lpt_absent);
+ok( !res (GetLastError() == ERROR_UNKNOWN_PORT),
+got %d with %u (expected '0' with ERROR_UNKNOWN_PORT)\n,
+res, GetLastError());
+}
+
+if (winetest_interactive com_present)
re: msi ole automation: where to next?
On Mon, 2007-05-21 at 08:23 -0700, Dan Kegel wrote: Misha wrote: [I have the scripting required by the Vector NTI and the iTunes 7 installers working. What should I do next?] First off, congratulations! If you're interested in continuing to work on MSI, I'd suggest asking James Hawkins for suggestions. If you're more interested in adding COM interfaces to things, perhaps implementing the iTextServices api to riched20 would be useful. Maarten got started on that, but I think it's not complete enough for say, Google Talk to function. Most useful of all might be for you to look at improving our COM implementation itself. Rob Shearman could give you suggestions on where to start there. - Dan Thanks Dan for your thoughtful descriptions, I will have to mull over where to head next. I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff: The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it. Now I really don't understand this or whether this is still the plan for custom actions (James?) or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else... Thanks Misha
Re: msi ole automation: where to next?
On 5/21/07, Misha Koshelev [EMAIL PROTECTED] wrote: I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff: The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it. Now I really don't understand this or whether this is still the plan for custom actions (James?) It's still the plan, and James is going to be working on it. or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else... I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.) - Dan
Re: shlwapi: stub implementation for SHSetTimerQueueTimer (try 2)
Hi,
I am not quite sure I understand what you mean? CreateTimerQueueTimer
should return a Boolean indicating whether the operation has
succeeded. Checking the return value in a ternary operation should
return the correct handle if CreateTimerQueueTimer succeeds and NULL
otherwise. Unless I have misunderstood the msdn documentation?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_new/shlwapi_wrappers.asp
-Nigel
On 5/21/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Nigel Liang [EMAIL PROTECTED] wrote:
+HANDLE WINAPI SHSetTimerQueueTimer(HANDLE hQueue,
+WAITORTIMERCALLBACK pfnCallback, LPVOID pContext, DWORD dwDueTime,
+DWORD dwPeriod, LPCSTR lpszLibrary, DWORD dwFlags)
+{
...
+return CreateTimerQueueTimer(hNewTimer, hQueue, pfnCallback, pContext,
+dwDueTime, dwPeriod, dwFlags)?hNewTimer:NULL;
This can't work: CreateTimerQueueTimer and SHSetTimerQueueTimer
return different things.
--
Dmitry.
Re: msi ole automation: where to next?
On Mon, 2007-05-21 at 10:05 -0700, Dan Kegel wrote: On 5/21/07, Misha Koshelev [EMAIL PROTECTED] wrote: I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff: The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it. Now I really don't understand this or whether this is still the plan for custom actions (James?) It's still the plan, and James is going to be working on it. or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else... I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.) - Dan I guess I would definitely like to learn more about this, then, as it seems like this, per Mike's comment, would require all the automation functions to be implemented, and I wouldn't mind to keep working on this as I've already got a good tempo going with it and it is kind of nice to make/design a whole part together like this. Plus I feel like I'm catching a fair number of msi bugs in other areas (mostly registry.c) through my conformance tests for automation. But I would definitely like to know more about it, as right now I don't really see how this separate custom action queue would be calling automation objects or why... Misha
Re: msi ole automation: where to next?
On Mon, 2007-05-21 at 10:05 -0700, Dan Kegel wrote: On 5/21/07, Misha Koshelev [EMAIL PROTECTED] wrote: I guess what I am still concerned about is this blurb from an email Mike McCormack had sent me when I started working on the scripting/automation stuff: The work that I was doing is aimed at running custom action threads in a separate process. It will require the OLE interfaces (Session/Installer) to be working before the custom actions can run out of process. The custom action queue needs to be exposed by another OLE interface so that msiexec can query it. Now I really don't understand this or whether this is still the plan for custom actions (James?) It's still the plan, and James is going to be working on it. or why having custom action threads in a separate process would require Session and Installer to be working at all, since they are mostly just wrappers around the C functions, which seem to be much easier to call from another C program like msiexec than the automation functions. However, I want to make sure that the full Installer/Session functionality is not required by something like this that could potentially improve more than just scripting support before I completely move on to something else... I'm sure James can fill you in. (FWIW, James, my druthers would be that you have a good look at the Autocad 2000/2002/2004 installer problems before diving in on the msi comification task. I'll bring the discs in tomorrow.) - Dan I guess the bottom line is I don't mind eventually implementing _all_ the automation functions as long as I know that I'm not just wasting my time (i.e., if these actions are only required by installer scripts, and I bet most installer scripts do not even use most of the functions). Misha
Re: msi ole automation: where to next?
On 5/21/07, Misha Koshelev [EMAIL PROTECTED] wrote: I guess the bottom line is I don't mind eventually implementing _all_ the automation functions as long as I know that I'm not just wasting my time ... I doubt anyone knows the complete set of those functions that actually get used by real-world installers. I think your choice is either a) keep plugging along on msi automation on the theory that it's good for msi in general and might help a few as yet unknown apps, or b) put this on the back burner and go work on something known to be blocking some app you care about. - Dan
Re: ADVAPI32: Start test for service tests
On 5/21/07, Rolf Kalbermatter [EMAIL PROTECTED] wrote: James Hawkins [mailto:[EMAIL PROTECTED] wrote: +ok(size = 1, size should be = 1 was %d!, size); This is a bad test. According to msdn, GetServiceDisplayName does not modify lpcchBuffer on error, so size should be exactly 0. MSDN says a lot of things. On my XP SP2 it returns 1 as size when passed an empty service name. Also failing here is a bit ambigeuos since the dunction also fails when a NULL pointer is passed or the buffer is to small, but it does change the size into what it expects in these two cases. ...and msdn is wrong a lot, but that doesn't mean the check is right. If the value you get is 1, then check exactly for 1. +static BOOL test_service_info(SC_HANDLE hscm) test functions are void, not BOOL. You're never going to do anything but return, and there's no value to check by the caller. I took this more or less directly from registry.c in the same directory. No test function in registry.c returns BOOL, and to save you some time replying, set_privileges is not a test function. It's a helper function. +ok(size, size should be returned!); And what is the size? Tests are supposed to be exact. If our implementation is incorrect, and we return size as 39491, that's certainly not correct, but this test won't fail when it should. This won't work for localized Windows versions. The display name is possibly translated. Also, on XP SP2 the A function returns the size in ASCI chars that the W function will need in bytes. Not a behaviour I feel Wine should imitate without an app that would need that behaviour. Huh? The function, A or W, returns the number of TCHARS. What behavior should wine not imitate? We don't ignore expected behavior just because we doubt an app will depend on it, especiallly a behavior that is so common. I'll be gone for two weeks for vacation. If anyone wants to continue on that please feel free. Otherwise I'll be picking this up afterwards. Rolf Kalbermatter -- James Hawkins
Re: shlwapi: stub implementation for SHSetTimerQueueTimer (try 2)
On 5/21/07, Nigel Liang (梁乃強) [EMAIL PROTECTED] wrote:
Hi,
I am not quite sure I understand what you mean? CreateTimerQueueTimer
should return a Boolean indicating whether the operation has
succeeded. Checking the return value in a ternary operation should
return the correct handle if CreateTimerQueueTimer succeeds and NULL
otherwise. Unless I have misunderstood the msdn documentation?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_new/shlwapi_wrappers.asp
+return CreateTimerQueueTimer(hNewTimer, hQueue, pfnCallback, pContext,
+dwDueTime, dwPeriod, dwFlags)?hNewTimer:NULL;
I'm pretty sure Dmitry did what I did. That last little blurb at the
end (?hNewTimer:NULL;) is not very noticeable, and looks like the end
of the function arguments at first glance. You really should get rid
of the ternary condition and split it out for code readability.
Also, please bottom-post on this list.
On 5/21/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Nigel Liang [EMAIL PROTECTED] wrote:
+HANDLE WINAPI SHSetTimerQueueTimer(HANDLE hQueue,
+WAITORTIMERCALLBACK pfnCallback, LPVOID pContext, DWORD dwDueTime,
+DWORD dwPeriod, LPCSTR lpszLibrary, DWORD dwFlags)
+{
...
+return CreateTimerQueueTimer(hNewTimer, hQueue, pfnCallback, pContext,
+dwDueTime, dwPeriod, dwFlags)?hNewTimer:NULL;
This can't work: CreateTimerQueueTimer and SHSetTimerQueueTimer
return different things.
--
Dmitry.
--
James Hawkins
FPS tool for wine
The largest gaming site in Norway recently did an extensive review of gaming on Linux, but Wine was left out of the benchmark because no FPS tool exists for Wine. Surely this can't be true?
Re: FPS tool for wine
Tirsdag 22 mai 2007 00:13, skrev [EMAIL PROTECTED]: The largest gaming site in Norway recently did an extensive review of gaming on Linux, but Wine was left out of the benchmark because no FPS tool exists for Wine. Surely this can't be true? Isn't the point rather to test how actual games run in Wine? Then you can use a game or a benchmarking tool like 3DMark. Regards, Alexander N. Sørnes
RE: FPS tool for wine
does fraps not work in wine? From: [EMAIL PROTECTED] To: wine-devel@winehq.org Subject: FPS tool for wine Date: Tue, 22 May 2007 00:13:22 +0200 The largest gaming site in Norway recently did an extensive review of gaming on Linux, but Wine was left out of the benchmark because no FPS tool exists for Wine. Surely this can't be true? _ Catch suspicious messages before you open themwith Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_protection_0507
Re: FPS tool for wine
Am Dienstag 22 Mai 2007 00:13 schrieb [EMAIL PROTECTED]: The largest gaming site in Norway recently did an extensive review of gaming on Linux, but Wine was left out of the benchmark because no FPS tool exists for Wine. Surely this can't be true? What exactly do they mean with FPS tools? After working with all this 3D business since almost 2 years I do not know what this term would precicely mean :-o If they mean built-in benchmark tools, then we have something like that, the fps debug channel which shows the ddraw / d3d / opengl buffer flips per secound. But why would they prefer external stuff over the games' built-in benchmark features?
Re: FPS tool for wine
Right, for instance Tom Wickline ran 3dmark2000 and posted the results here: http://wiki.winehq.org/BenchMark-0.9.33 On 5/21/07, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Tirsdag 22 mai 2007 00:13, skrev [EMAIL PROTECTED]: The largest gaming site in Norway recently did an extensive review of gaming on Linux, but Wine was left out of the benchmark because no FPS tool exists for Wine. Surely this can't be true? Isn't the point rather to test how actual games run in Wine? Then you can use a game or a benchmarking tool like 3DMark. Regards, Alexander N. Sørnes
