Re: msi: Write-strings warnings fix
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
Andrew Talbot wrote:
MSI{Get|Set}FeatureState(), MSI{Get|Set}ComponentState() and
MSI{Get|Set}Property() have appropriate const string arguments in the SDK.
Which version of the Windows SDK is that?
-UINT WINAPI MsiGetFeatureStateA(MSIHANDLE hInstall, LPSTR szFeature,
+UINT WINAPI MsiGetFeatureStateA(MSIHANDLE hInstall, LPCSTR szFeature,
INSTALLSTATE *piInstalled, INSTALLSTATE *piAction)
According to my version of the Windows SDK, these changes are wrong.
My copy of Windows Server 2003 SP1 SDK confirms Andrew's findings.
--
Dmitry.
Re: msi: Write-strings warnings fix
Andrew Talbot wrote:
MSI{Get|Set}FeatureState(), MSI{Get|Set}ComponentState() and
MSI{Get|Set}Property() have appropriate const string arguments in the SDK.
Which version of the Windows SDK is that?
-UINT WINAPI MsiGetFeatureStateA(MSIHANDLE hInstall, LPSTR szFeature,
+UINT WINAPI MsiGetFeatureStateA(MSIHANDLE hInstall, LPCSTR szFeature,
INSTALLSTATE *piInstalled, INSTALLSTATE *piAction)
According to my version of the Windows SDK, these changes are wrong.
Mike
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
On 8/4/06, Thomas Kho <[EMAIL PROTECTED]> wrote: > > Tommy's APC version of his > > VirtualAllocEx / CreateRemoteThread patch > > seems to be safe (since APCs only run a points where threads > > in well-written programs are not holding locks), > > Unfortunately there's no such guarantee, kernel APCs will run on every > wait. I'm not too clear why this is a problem. The closest Alexandre has come to answering this is http://www.mail-archive.com/wine-devel@winehq.org/msg29265.html but with APCs we at least handle one of his two objections (an APC definitely doesn't interrupt any critical section initialization). leaving "One problem is that many locks have to be acquired in a specific order to avoid deadlocks, and since you don't know which locks the thread is already holding you can't guarantee the order" So all you have to do is identify all the locks that your APCs might need to acquire, and verify that they are always acquired in the same order by all possible code paths. (Or did I miss something, Alexandre?) A torture test program running on a multi-CPU box might give some warm fuzzies, too, especially if you artificially increase the duration that locks are held by inserting busywaits. (That will increase the chance of threads colliding.) - Dan
Re: wine.inf: Windows 9x and Windows NT store the time zone data in different places.
Friday, August 4, 2006, 9:47:38 AM, Francois Gouget wrote: > So duplicate it so programs find it no matter where they look. > Note: > Another option would be to have a [Timezones9x] section that would set > this data in the alternate location. But we would still need to > duplicate all the data in the inf file anyway. This would also make > checking the inf file consistency harder too. And finally, it would make > it impossible to change the Windows version of a Wine environment after > the fact. So I chose to just duplicate it all. You missed one more option - use registry symlinks. The only problem is - win2k and winXP doesn't have those registry keys in win9x place. Vitaliy Margolen
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
On 8/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: "Dan Kegel" <[EMAIL PROTECTED]> writes: > Tommy's APC version of his > VirtualAllocEx / CreateRemoteThread patch > seems to be safe (since APCs only run a points where threads > in well-written programs are not holding locks), Unfortunately there's no such guarantee, kernel APCs will run on every wait. I'm not too clear why this is a problem. I thought that kernel APCs run on just interruptible waits, which excludes the wait on suspend and perhaps others. Also, I was under the impression that only locks taken in the code path of the VM and thread creation functions had to be respected. If necessary, non-interruptible waits could/should be done while holding these locks (although I looked through the code and it doesn't look like any applicable code does a wait while holding a lock). As a side note, there was a bug in my APC implementation--the process APC queue was flushed on every thread cleanup. Tommy
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
On 8/4/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Tommy's APC version of his > VirtualAllocEx / CreateRemoteThread patch > seems to be safe (since APCs only run a points where threads > in well-written programs are not holding locks), Unfortunately there's no such guarantee, kernel APCs will run on every wait. Unless you meant user APCs which only run on alertable waits, Whoops. I meant user APCs, and I thought Tommy was using user APCs, but I see now he's using system APCs. Drats. but this means they would essentially never run. If it's true that no windows app enters an alertable wait condition normally, then I guess APCs (without a service thread) are out. How about a custom windows message? ALL gui programs have a message pump, so that has a better chance of actually getting through. - Dan
Re: Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
"Dan Kegel" <[EMAIL PROTECTED]> writes: > Tommy's APC version of his > VirtualAllocEx / CreateRemoteThread patch > seems to be safe (since APCs only run a points where threads > in well-written programs are not holding locks), Unfortunately there's no such guarantee, kernel APCs will run on every wait. Unless you meant user APCs which only run on alertable waits, but this means they would essentially never run. Like so much of the Windows API, APCs are a feature that could have been useful if it had been properly thought out... -- Alexandre Julliard [EMAIL PROTECTED]
Time to commit remote ops for VirtualAllocEx, CreateRemoteThread
Tommy's APC version of his VirtualAllocEx / CreateRemoteThread patch seems to be safe (since APCs only run a points where threads in well-written programs are not holding locks), is complete enough to make many apps happy, and is probably the best that can be done without a service thread or a real kernel change. I've encouraged him to submit it for real. Let's get this puppy committed!
[PATCH] Re: tools/winemaker prints unexpected output
Hi,
it seems like the open function failed, but the error code wasn't
checked, resulting in a wrong filehandle. I think I would correct it
this way (see attached patch).
Regards,
Colin Pitrat (Bull Services Telco)
Bull, Architect of an Open World (TM)
Tél : +33 (0) 1 30 80 72 93
www.bull.com
Saulius Krasuckas wrote:
Now I am running it on a latest GIT tree this way:
$ tools/winapi/msvcmaker --no-wine
.: searching for /^Makefile.in$/
And after a while it appends this string to the end of last line:
readline() on closed filehandle IN at tools/winapi/msvcmaker line 134.
Maybe it doesn't indicate any harm, but in ideal world this should be
fixed. I don't know perl, unfortunately.
--- msvcmaker.old 2006-08-04 17:07:28.0 +0200
+++ msvcmaker 2006-08-04 17:07:06.0 +0200
@@ -45,7 +45,7 @@
my $type = "win32";
-open(IN, "< $wine_dir/$spec_file");
+open(IN, "< $wine_dir/$spec_file") || die "Error : Can't open
$wine_dir/$spec_file : $!\n";
my $header = 1;
my $lookahead = 0;
@@ -115,7 +115,7 @@
my %wine_test_dsp_files;
MAKEFILE_IN: foreach my $makefile_in_file (@makefile_in_files) {
-open(IN, "< $wine_dir/$makefile_in_file");
+open(IN, "< $wine_dir/$makefile_in_file") || die "Error : Can't open
$wine_dir/$makefile_in_file : $!\n";
my $topobjdir;
my $module;
[ws2_32] connect doesn't generate FD_CONNECT event in non-blocking mode
dlls/ws2_32/tests/sock.c:event_client:597: /* Prepare event notification for connect, makes socket nonblocking */ event = WSACreateEvent (); WSAEventSelect ( mem->s, event, FD_CONNECT ); tmp = connect ( mem->s, (struct sockaddr*) &mem->addr, sizeof ( mem->addr ) ); if ( tmp != 0 && ( err = WSAGetLastError () ) != WSAEWOULDBLOCK ) ok ( 0, "event_client (%x): connect error: %d\n", id, err ); tmp = WaitForSingleObject ( event, INFINITE ); When dlls/ws2_32/socket.c:WS_connect returns 0 (because unix connect returns 0) no FD_CONNECT event is ever generated and the call on the last line above never returns. So who's wrong, the test case or WS_connect?
tools/winemaker prints unexpected output
Now I am running it on a latest GIT tree this way: $ tools/winapi/msvcmaker --no-wine .: searching for /^Makefile.in$/ And after a while it appends this string to the end of last line: readline() on closed filehandle IN at tools/winapi/msvcmaker line 134. Maybe it doesn't indicate any harm, but in ideal world this should be fixed. I don't know perl, unfortunately.
Re: VNC and worms
* On Thu, 3 Aug 2006, Krzysztof Foltman wrote: > Can anyone figure out how to fix this display artifact that's very > frequent when using Wine through VNC servers ... > http://foltman.com/worms.png I guess this can be related to 2 bugreports: [2] http://bugs.winehq.org/show_bug.cgi?id=3571 [3] http://bugs.winehq.org/show_bug.cgi?id=5248
Re: advapi32: Add more SID tests
Robert Reif wrote:
Adds more SID tests.
Fixes some Windows failures by checking version first.
Add some more info on failed tests.
Removes Windows version check.
diff -p -u -r1.34 security.c
--- dlls/advapi32/tests/security.c 31 Jul 2006 09:33:04 - 1.34
+++ dlls/advapi32/tests/security.c 4 Aug 2006 12:14:56 -
@@ -18,15 +18,21 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
+#include
#include
-#include "wine/test.h"
+#include "ntstatus.h"
+#define WIN32_NO_STATUS
#include "windef.h"
#include "winbase.h"
#include "winerror.h"
#include "aclapi.h"
#include "winnt.h"
+#include "winternl.h"
#include "sddl.h"
+#include "ntsecapi.h"
+
+#include "wine/test.h"
typedef VOID (WINAPI *fnBuildTrusteeWithSidA)( PTRUSTEEA pTrustee, PSID pSid );
typedef VOID (WINAPI *fnBuildTrusteeWithNameA)( PTRUSTEEA pTrustee, LPSTR
pName );
@@ -49,6 +55,11 @@ typedef BOOL (WINAPI *fnGetFileSecurityA
typedef DWORD (WINAPI *fnRtlAdjustPrivilege)(ULONG,BOOLEAN,BOOLEAN,PBOOLEAN);
typedef BOOL (WINAPI
*fnCreateWellKnownSid)(WELL_KNOWN_SID_TYPE,PSID,PSID,DWORD*);
+typedef NTSTATUS (WINAPI
*fnLsaQueryInformationPolicy)(LSA_HANDLE,POLICY_INFORMATION_CLASS,PVOID*);
+typedef NTSTATUS (WINAPI *fnLsaClose)(LSA_HANDLE);
+typedef NTSTATUS (WINAPI *fnLsaFreeMemory)(PVOID);
+typedef NTSTATUS (WINAPI
*fnLsaOpenPolicy)(PLSA_UNICODE_STRING,PLSA_OBJECT_ATTRIBUTES,ACCESS_MASK,PLSA_HANDLE);
+
static HMODULE hmod;
fnBuildTrusteeWithSidA pBuildTrusteeWithSidA;
@@ -61,6 +72,10 @@ fnConvertStringSidToSidA pConvertStringS
fnGetFileSecurityA pGetFileSecurityA;
fnRtlAdjustPrivilege pRtlAdjustPrivilege;
fnCreateWellKnownSid pCreateWellKnownSid;
+fnLsaQueryInformationPolicy pLsaQueryInformationPolicy;
+fnLsaClose pLsaClose;
+fnLsaFreeMemory pLsaFreeMemory;
+fnLsaOpenPolicy pLsaOpenPolicy;
struct sidRef
{
@@ -87,7 +102,7 @@ static void test_str_sid(char *str_sid)
}
}
else
-trace("%s couldn't be converted\n", str_sid);
+trace("%s couldn't be converted, returned %ld\n", str_sid,
GetLastError());
}
static void test_sid(void)
@@ -180,7 +195,6 @@ static void test_sid(void)
LocalFree( psid );
}
-trace("String SIDs:\n");
test_str_sid("AO");
test_str_sid("RU");
test_str_sid("AN");
@@ -799,6 +813,7 @@ static void test_token_attr(void)
trace("\t%s, %s\\%s use: %d attr: 0x%08lx\n", SidString, Domain, Name,
SidNameUse, Groups->Groups[i].Attributes);
LocalFree(SidString);
}
+HeapFree(GetProcessHeap(), 0, Groups);
/* user */
ret = GetTokenInformation(Token, TokenUser, NULL, 0, &Size);
@@ -852,19 +867,19 @@ static void test_LookupAccountSid(void)
ret = AllocateAndInitializeSid(&SIDAuthNT, 2, SECURITY_BUILTIN_DOMAIN_RID,
DOMAIN_ALIAS_RID_USERS, 0, 0, 0, 0, 0, 0, &pUsersSid);
-ok(ret, "AllocateAndInitializeSid failed with error %ld\n",
GetLastError());
+ok(ret, "AllocateAndInitializeSid failed with error %ld\n",
GetLastError());
/* try NULL account */
acc_size = MAX_PATH;
dom_size = MAX_PATH;
ret = LookupAccountSid(NULL, pUsersSid, NULL, &acc_size, domain,
&dom_size, &use);
-ok(ret, "Expected TRUE, got FALSE\n");
+ok(ret, "LookupAccountSid() Expected TRUE, got FALSE\n");
/* try NULL domain */
acc_size = MAX_PATH;
dom_size = MAX_PATH;
ret = LookupAccountSid(NULL, pUsersSid, account, &acc_size, NULL,
&dom_size, &use);
-ok(ret, "Expected TRUE, got FALSE\n");
+ok(ret, "LookupAccountSid() Expected TRUE, got FALSE\n");
pCreateWellKnownSid = (fnCreateWellKnownSid)GetProcAddress( hmod,
"CreateWellKnownSid" );
@@ -882,11 +897,114 @@ static void test_LookupAccountSid(void)
dom_size = MAX_PATH;
if (LookupAccountSid(NULL, &max_sid.sid, account,
&acc_size, domain, &dom_size, &use))
trace(" %d: %s %s\\%s %d\n", i, str_sid, domain,
account, use);
-LocalFree(str_sid);
+LocalFree(str_sid);
}
}
else
-trace(" CreateWellKnownSid(%d) failed: %ld\n", i,
GetLastError());
+trace(" CreateWellKnownSid(%d) failed: %ld\n", i,
GetLastError());
+}
+
+pLsaQueryInformationPolicy =
(fnLsaQueryInformationPolicy)GetProcAddress( hmod, "LsaQueryInformationPolicy");
+pLsaOpenPolicy = (fnLsaOpenPolicy)GetProcAddress( hmod,
"LsaOpenPolicy");
+pLsaFreeMemory = (fnLsaFreeMemory)GetProcAddress( hmod,
"LsaFreeMemory");
+pLsaClose = (fnLsaClose)GetProcAddress( hmod, "LsaClose");
+
+if (pLsaQueryInformationPolicy && pLsaOpenPolicy && pLsaFreeMemory &&
pLsaClose)
+{
+NTSTATUS status;
+LSA_HANDLE handle;
+LSA_OBJECT_ATTRIBUTES object_attributes;
+
+ZeroMemory(&object_attributes, sizeof(object_attributes));
+
+
Re: advapi32: Add more SID tests
Robert Reif <[EMAIL PROTECTED]> writes: > ConvertStringSidToSid is supported on NT and later but the particular > type of two character sid that I am testing is only avaliable on XP > and later. Yes, but the right way is to call it and check if it works. On Wine the Windows version can report anything but the function will still work, and should be tested. -- Alexandre Julliard [EMAIL PROTECTED]
Re: user [1/2]: Add a test for CreateWindowEx
Dan Hipschman <[EMAIL PROTECTED]> writes: > @@ -137,8 +137,10 @@ static void test_parent_owner(void) > trace( "main window %p main2 %p desktop %p child %p\n", hwndMain, > hwndMain2, desktop, child ); > > /* child without parent, should fail */ > +SetLastError(ERROR_SUCCESS); > test = CreateWindowExA(0, "ToolWindowClass", "Tool window 1", > WS_CHILD, 0, 0, 100, 100, 0, 0, 0, NULL ); > +todo_wine ok( GetLastError() != ERROR_SUCCESS, "CreateWindowExA should > call SetLastError\n" ); 0xdeadbeef is usually a better choice than ERROR_SUCCESS for that sort of thing. Also you might as well check for the expected value instead of only checking that it has been modified. -- Alexandre Julliard [EMAIL PROTECTED]
Re: advapi32: Add more SID tests
Alexandre Julliard wrote: Robert Reif <[EMAIL PROTECTED]> writes: Adds more SID tests. Fixes some Windows failures by checking version first. You shouldn't check the Windows version, you should check the features themselves. ConvertStringSidToSid is supported on NT and later but the particular type of two character sid that I am testing is only avaliable on XP and later. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/convertstringsidtosid.asp
Re: advapi32: Add more SID tests
Robert Reif <[EMAIL PROTECTED]> writes: > Adds more SID tests. > Fixes some Windows failures by checking version first. You shouldn't check the Windows version, you should check the features themselves. -- Alexandre Julliard [EMAIL PROTECTED]
Re: urlmon: Delay-load cabinet.dll as native urlmon doesn't import it.
Robert Shearman <[EMAIL PROTECTED]> writes: > +if (!hCabinet) return HRESULT_FROM_WIN32(GetLastError()); > +pExtract = GetProcAddress(hCabinet, "Extract"); > +if (!pExtract) return HRESULT_FROM_WIN32(GetLastError()); > + > +hr = pExtract(dest, szCabName); > +FreeLibrary(hCabinet); > +return hr; > +} Unless the app depends on it, it's usually better to not free the library on each call, otherwise repeated calls to the function will be very expensive. You can free the library in PROCESS_DETACH. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msi: The input buffer length is the number of characters excluding the NULL terminator, so fix an off by one error [RESEND]
"James Hawkins" <[EMAIL PROTECTED]> writes: > Is there anything wrong with this patch? Yes, the length does include the terminating null. That's what the rest of the function expects, and AFAICT it's what the callers expect too (and it's the standard behavior of API functions that take a buffer length). -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine's fullscreen code has no effect on metacity
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: "Havoc Pennington" <[EMAIL PROTECTED]> wrote: You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927 They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity. I've added a patch there which fixes the problem for me. I've attached a couple of patches based on Havoc's suggestions to the bug above. The patches fix Thief game and IE's fullscreen mode for me. Vincent, could you try them and report if any of the patches fixes Firefox for you? -- Dmitry.
