Re: [urlmon 1/2] Cast-qual warning fix
--- Paul Vriens [EMAIL PROTECTED] wrote:
Hi,
Fix a warning and remove the now not needed cast.
Changelog
Cast-qual warning fix
Cheers,
Paul.
diff --git a/dlls/urlmon/umon.c
b/dlls/urlmon/umon.c
index 49260ab..d593c81 100644
--- a/dlls/urlmon/umon.c
+++ b/dlls/urlmon/umon.c
@@ -1605,7 +1605,7 @@ HRESULT WINAPI
URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller,
LPCWSTR szURL, LPW
HRESULT hr;
LPWSTR ext;
-static const WCHAR header[] = {
+static WCHAR header[] = {
'H','T','T','P','/','1','.','0','
','2','0','0',' ',
'O','K','\\','r','\\','n','\\','r','\\','n',0
};
@@ -1631,7 +1631,7 @@ HRESULT WINAPI
URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller,
LPCWSTR szURL, LPW
modified.dwLowDateTime = 0;
if (!CommitUrlCacheEntryW(szURL, cache_path,
expire, modified, NORMAL_CACHE_ENTRY,
- (LPWSTR)header,
sizeof(header), NULL, NULL))
+ header,
sizeof(header), NULL, NULL))
return E_FAIL;
if (lstrlenW(cache_path) dwBufLength)
--
If CommitUrlCacheEntryW does not take a constant
pointer, this might be dangerous - if it changes the
string, the next time this code executes the wrong
(modified) string gets used
If this is indeed possible, the static keyword needs
to be dropped too (ensuring the string is
reinitialised with the next call)
If it is only not possible in this particular case,
sorry for complaining; (though it may be possible to
factor out that part of the code that is used, thus
ensuring constness)
If this is not possible in general, the function
CommitUrlCacheEntryW should take a constant pointer
instead
(same for the other patch)
regards,
Joris
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :) From 55b39a67676e2bd8c01c0b17b677298c9d22a46c Mon Sep 17 00:00:00 2001 From: Misha Koshelev [EMAIL PROTECTED] Date: Wed, 7 Feb 2007 08:10:19 -0600 Subject: msi: Make MsiInstallProduct conformance test depend on proper UI level processing. --- dlls/msi/tests/install.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/dlls/msi/tests/install.c b/dlls/msi/tests/install.c index 00b7763..facd280 100644 --- a/dlls/msi/tests/install.c +++ b/dlls/msi/tests/install.c @@ -105,6 +105,12 @@ static const CHAR install_exec_seq_dat[] LaunchConditions\t\t100\n WriteRegistryValues\tSourceDir And SOURCEDIR\t5000; +/* as a proper check for INSTALLUILEVEL flags processing, make sure a UI install fails */ +static const CHAR install_ui_seq_dat[] = Action\tCondition\tSequence\n + s72\tS255\tI2\n + InstallUISequence\tAction\n + AllocateRegistrySpace\tNOT Installed\t1550\n; + static const CHAR media_dat[] = DiskId\tLastSequence\tDiskPrompt\tCabinet\tVolumeLabel\tSource\n i2\ti4\tL64\tS255\tS32\tS72\n Media\tDiskId\n @@ -231,6 +237,7 @@ static const msi_table tables[] = ADD_TABLE(feature_comp), ADD_TABLE(file), ADD_TABLE(install_exec_seq), +ADD_TABLE(install_ui_seq), ADD_TABLE(media), ADD_TABLE(property), ADD_TABLE(registry), @@ -689,6 +696,12 @@ static void test_MsiInstallProduct(void) create_test_files(); create_database(msifile, tables, sizeof(tables) / sizeof(msi_table)); +/* Make sure that the UI level flags are taken into account when determining whether to + * start a graphical UI or execute only mode (bug 6992). If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. */ +MsiSetInternalUI(INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCERESONLY, NULL); + r = MsiInstallProductA(msifile, NULL); ok(r == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %u\n, r); -- 1.4.1
Re: winegcc: sign-compare fixes
I believe this one causes problems -- please do not commit yet
Joris Huizer [EMAIL PROTECTED] wrote:
-
Need Mail bonding?
Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users.From
8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17 00:00:00 2001
From: Joris Huizer
Date: Wed, 7 Feb 2007 15:19:25 +0100
Subject: [PATCH] winegcc sign-compare fixes
To: wine-patches
---
tools/winegcc/utils.c | 13 +++--
tools/winegcc/winegcc.c | 11 ++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c
index 1af91e9..c144077 100644
--- a/tools/winegcc/utils.c
+++ b/tools/winegcc/utils.c
@@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c
void strarray_del(strarray* arr, int i)
{
-if (i 0 || i = arr-size) error(Invalid index i=%d, i);
+if (i 0 || (unsigned int)i = arr-size) error(Invalid index i=%d, i);
memmove(arr-base[i], arr-base[i + 1], (arr-size - i - 1) *
sizeof(arr-base[0]));
arr-size--;
}
void strarray_addall(strarray* arr, const strarray* from)
{
-int i;
+unsigned int i;
for (i = 0; i from-size; i++)
strarray_add(arr, from-base[i]);
@@ -136,7 +136,7 @@ void strarray_addall(strarray* arr, cons
strarray* strarray_dup(const strarray* arr)
{
strarray* dup = strarray_alloc();
-int i;
+unsigned int i;
for (i = 0; i arr-size; i++)
strarray_add(dup, arr-base[i]);
@@ -160,7 +160,7 @@ strarray* strarray_fromstring(const char
char* strarray_tostring(const strarray* arr, const char* sep)
{
char *str, *newstr;
-int i;
+unsigned int i;
str = strmake(%s, arr-base[0]);
for (i = 1; i arr-size; i++)
@@ -277,7 +277,7 @@ static file_type guess_lib_type(const ch
file_type get_lib_type(strarray* path, const char* library, char** file)
{
-int i;
+unsigned int i;
for (i = 0; i path-size; i++)
{
@@ -289,7 +289,8 @@ file_type get_lib_type(strarray* path, c
void spawn(const strarray* prefix, const strarray* args, int ignore_errors)
{
-int i, status;
+unsigned int i;
+int status;
strarray* arr = strarray_dup(args);
const char** argv;
char* prog = 0;
diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c
index f1aa87e..f1a7bb0 100644
--- a/tools/winegcc/winegcc.c
+++ b/tools/winegcc/winegcc.c
@@ -170,7 +170,7 @@ struct options
static void clean_temp_files(void)
{
-int i;
+unsigned int i;
if (keep_generated) return;
@@ -239,7 +239,8 @@ static const strarray* get_translator(en
static void compile(struct options* opts, const char* lang)
{
strarray* comp_args = strarray_alloc();
-int j, gcc_defs = 0;
+unsigned int j;
+int gcc_defs = 0;
switch(opts-processor)
{
@@ -434,7 +435,7 @@ static void build(struct options* opts)
const char *output_name, *spec_file, *lang;
const char* winebuild = getenv(WINEBUILD);
int generate_app_loader = 1;
-int j;
+unsigned int j;
/* NOTE: for the files array we'll use the following convention:
*-axxx: xxx is an archive (.a)
@@ -719,7 +720,7 @@ static int is_linker_arg(const char* arg
-static, -static-libgcc, -shared, -shared-libgcc, -symbolic,
-framework
};
-int j;
+unsigned int j;
switch (arg[1])
{
@@ -769,7 +770,7 @@ static int is_mingw_arg(const char* arg)
{
-mno-cygwin, -mwindows, -mconsole, -mthreads, -municode
};
-int j;
+unsigned int j;
for (j = 0; j sizeof(mingw_switches)/sizeof(mingw_switches[0]); j++)
if (strcmp(mingw_switches[j], arg) == 0) return 1;
--
1.4.4
-
Need a quick answer? Get one in minutes from people who know. Ask your question
on Yahoo! Answers.
Re: winegcc: sign-compare fixes
Joris Huizer [EMAIL PROTECTED] wrote: I believe this one causes problems -- please do not commit yet Sorry for the spamming - the patch should be alright - Everyone is raving about the all-new Yahoo! Mail beta.
Re: winedump: sign-compare fixes
Joris Huizer [EMAIL PROTECTED] wrote: -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) Please keep white space unchanged. -while (ptr - (const unsigned char*)table len) +while ((unsigned long)(ptr - (const unsigned char*)table) len) -int i, length; +unsigned long int i, length; -while (file - (const char*)symbols sizeof(PDB_SYMBOLS) + symbols-module_size) +while ((unsigned long int)(file - (const char*)symbols) sizeof(PDB_SYMBOLS) + symbols-module_size) Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? -- Dmitry.
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 08:33 -0600, Misha Koshelev wrote: Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :) Alright, got the crosstest to work, no new errors with and without my patch on Windows XP. Misha
Re: advapi32: sign-compare fixes
Joris Huizer wrote:
- int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName,
+ unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName,
This isn't right. WideCharToMultiByte returns INT, which is signed.
@@ -1995,11 +1995,11 @@ LookupAccountSidW(
if (dm) {
BOOL status = TRUE;
-if (*accountSize lstrlenW(ac)) {
+if (*accountSize (unsigned)lstrlenW(ac)) {
if (account)
lstrcpyW(account, ac);
}
-if (*domainSize lstrlenW(dm)) {
+if (*domainSize (unsigned)lstrlenW(dm)) {
if (domain)
lstrcpyW(domain, dm);
}
This isn't correct either. lstrlenW() also returns INT and you
can't just cast it to (unsigned). Unsigned what? int/long/dword?
Vitaliy.
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. -- James Hawkins
Re: advapi32: sign-compare fixes
Vitaliy Margolen [EMAIL PROTECTED] wrote: Joris Huizer wrote:
- int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName,
+ unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName,
This isn't right. WideCharToMultiByte returns INT, which is signed.
@@ -1995,11 +1995,11 @@ LookupAccountSidW(
if (dm) {
BOOL status = TRUE;
-if (*accountSize lstrlenW(ac)) {
+if (*accountSize (unsigned)lstrlenW(ac)) {
if (account)
lstrcpyW(account, ac);
}
-if (*domainSize lstrlenW(dm)) {
+if (*domainSize (unsigned)lstrlenW(dm)) {
if (domain)
lstrcpyW(domain, dm);
}
This isn't correct either. lstrlenW() also returns INT and you
can't just cast it to (unsigned). Unsigned what? int/long/dword?
Vitaliy.
Sorry I'll fix it; Will try and check in future
Joris
-
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa Weird, because it does indeed fail when running in full UI mode. Do you know a better (more proper) way to do this then? I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? Thanks Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa Weird, because it does indeed fail when running in full UI mode. It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. Do you know a better (more proper) way to do this then? Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. Why do you want the install to fail? The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests Correct. No user intervention. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? I don't know why you want the install to fail, so I don't have any suggestions. -- James Hawkins
Re: msi: Register the typelib
Mike McCormack [EMAIL PROTECTED] writes:
+ITypeLib *get_msi_typelib( LPWSTR *path )
+{
+static CRITICAL_SECTION cs = { NULL, -1, 0, 0, 0, 0 };
Please use the standard pattern for static critical sections. Setting
the debug info to NULL is reserved for global sections.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH 3/6] oleaut32: Comment out dual attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.
Robert Shearman [EMAIL PROTECTED] writes: This fixes a bunch of tmarshal tests. It doesn't seem to make any difference for me: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c touch tmarshal.ok tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 make: *** [tmarshal.ok] Error 7 -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 3/6] oleaut32: Comment out dual attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.
Alexandre Julliard wrote: Robert Shearman [EMAIL PROTECTED] writes: This fixes a bunch of tmarshal tests. It doesn't seem to make any difference for me: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c touch tmarshal.ok tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 tmarshal.c:765: Test failed: CoUnmarshalInterface failed with error 0x80040155 tmarshal.c:784: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:803: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:915: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:942: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x7bc7a2c8 tmarshal.c:977: Test failed: EXCEPINFO differs from expected: wCode = 0x2, scode = 0x80004001 make: *** [tmarshal.ok] Error 7 Did you remove ~/.wine? It only registers the typelib if the typelib hasn't already been registered (perhaps this should be changed.) -- Rob Shearman
Re: [PATCH 3/6] oleaut32: Comment out dual attribute of IKindaEnumWidget in tmarshal test to cause the interface to be marshaled correctly.
Robert Shearman [EMAIL PROTECTED] writes: Did you remove ~/.wine? It only registers the typelib if the typelib hasn't already been registered (perhaps this should be changed.) Ah sorry, I missed that part. Yes, I think that needs to be changed, we can't ask people to rm -rf their .wine dir all the time. At the very least there needs to be an easy way to force the re-registration. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Undoc. comctl32 mem management functions
Felix Nawothnig wrote: Hi. comctl32 exports (undocumented) Alloc() and friends which call LocalAlloc = GlobalAlloc = HeapAlloc since it's doesn't use any fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() directly? If Global/Local* behave different than Heap* on Windows - wouldn't it then be desirable to replace the Alloc()/etc. calls in our comctl32 (we use it all over the place) by Heap*? There are probably quite a few locations where it doesn't make a difference, but there are also probably a few locations where it does. Since it is easier to use the Alloc/ReAlloc/Free functions, why bother changing them to the longer Heap* variants? Reason I'm asking: Since it's not documented the Free(NULL) semantics are not clear (although it's safe in our implementation) - and I'm wondering if we really want to internally use undocumented functions with unclear semantics when there is an easy (documented) way. Well, I think it needs to be tested on Windows if Free(NULL) is valid before changing the calls in comctl32. -- Rob Shearman
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa Weird, because it does indeed fail when running in full UI mode. It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. Do you know a better (more proper) way to do this then? Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. Why do you want the install to fail? The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests Correct. No user intervention. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? I don't know why you want the install to fail, so I don't have any suggestions. Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the child MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account. This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed.
Helping a user migrate an odbc app to Wine
Can somebody help this (german-speaking) fellow: http://www.unixboard.de/vb3/showthread.php?t=26943 He says his company's internal application requires you to input a DSN when installing it, and he doesn't know how to come up with a DSN under Wine. Presumably he doesn't want to mess with Unixodbc, he just wants to keep using the Microsoft drivers...? - Dan
Re: winegcc: sign-compare fixes
On 2/7/07, Joris Huizer [EMAIL PROTECTED] wrote:
I believe this one causes problems -- please do not commit yet
Joris Huizer [EMAIL PROTECTED] wrote:
Need Mail bonding?
Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users.From
8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17
00:00:00 2001
From: Joris Huizer
Date: Wed, 7 Feb 2007 15:19:25 +0100
Subject: [PATCH] winegcc sign-compare fixes
To: wine-patches
---
tools/winegcc/utils.c | 13 +++--
tools/winegcc/winegcc.c | 11 ++-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c
index 1af91e9..c144077 100644
--- a/tools/winegcc/utils.c
+++ b/tools/winegcc/utils.c
@@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c
void strarray_del(strarray* arr, int i)
{
- if (i 0 || i = arr-size) error(Invalid index i=%d, i);
+ if (i 0 || (unsigned int)i = arr-size) error(Invalid index i=%d, i);
The unsigned int comparison here makes the negative check superfluous.
Perhaps the argument should even be changed to unsigned as well, to
match the range of arr-size (if the element is one byte).
memmove(arr-base[i], arr-base[i + 1], (arr-size - i - 1) *
sizeof(arr-base[0]));
arr-size--;
}
If the element size could be greater than one byte, the multiplication
here should be checked for overflow (actually, this is more necessary
when the array is created or expanded).
Re: winedump: sign-compare fixes
On 2/7/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Joris Huizer [EMAIL PROTECTED] wrote: -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) Please keep white space unchanged. -while (ptr - (const unsigned char*)table len) +while ((unsigned long)(ptr - (const unsigned char*)table) len) -int i, length; +unsigned long int i, length; -while (file - (const char*)symbols sizeof(PDB_SYMBOLS) + symbols-module_size) +while ((unsigned long int)(file - (const char*)symbols) sizeof(PDB_SYMBOLS) + symbols-module_size) Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? Seeing int extended to unsigned long like this makes me question whether the correct type wouldn't be size_t especially as it is compared to sizeof(...) -- Dmitry.
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa Weird, because it does indeed fail when running in full UI mode. It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. Do you know a better (more proper) way to do this then? Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. Why do you want the install to fail? The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests Correct. No user intervention. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? I don't know why you want the install to fail, so I don't have any suggestions. Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the child MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account. This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install.
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. Changelog: * msi: Make MsiInstallProduct conformance test depend on proper UI level processing. You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. If the full UI is started (incorrectly) + * the InstallUISequence table will be used, and the install will fail. If the full UI is + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa Weird, because it does indeed fail when running in full UI mode. It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer. Do you know a better (more proper) way to do this then? Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch. I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. Why do you want the install to fail? The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests Correct. No user intervention. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? I don't know why you want the install to fail, so I don't have any suggestions. Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the child MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account. This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table? http://msdn2.microsoft.com/en-us/library/aa370912.aspx First of all, I added the Property to the Property table, which is, what I understand from that link (paragraph three I think) all that it takes to make it public (in fact, what happens when you go from UI to Execute is that the value of the property seems to be reset back to the value from the Properties table). Two things: 1) I am testing the behavior in UI mode to make sure the test works, but the actual test is to test the mode NONE | otherflags, which, before the bug fix, would result in a UI install, whereas in Windows (all versions) it would result in an execute-only install. This test breaks on wine without the patch to fix it, whereas it would execute on all Windows version without error, thus in this sense it conforms to Windows. The question is whether we are able to detect a failure to conform. 2) I tried on Win98 and in Win98 it works the same way it does on Wine. I will play with it some more, but because of these points it seems to me that it is still a reasonable test (it will succeed on all version of Windows, on Wine that properly detects UI flags, but fail on wine that does not detect UI flags; however, in the future, if wine MSI is made more like Win XP MSI, it would be possible that we will not be able to detect failure anymore). Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table? http://msdn2.microsoft.com/en-us/library/aa370912.aspx Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Misha
Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
On Wed, 2007-02-07 at 23:46 -0600, James Hawkins wrote: On 2/7/07, Misha Koshelev [EMAIL PROTECTED] wrote: Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table? http://msdn2.microsoft.com/en-us/library/aa370912.aspx Aha, google search figured it out: * Property name ALL CAPS - passed from UI to execute. * otherwise not. Too bad it's not documented on msdn (you think they would...) Properties with names containing no lowercase letters are public properties... http://msdn2.microsoft.com/en-us/library/aa370905.aspx Too bad I don't read things carefully enough :) Anyway, I am sending the patch to wine-patches now. It is able to determine UI level properly (UI vs execute-only) on Win98, WinXP, and wine. Phew, time to go to bed. Misha
Re: Helping a user migrate an odbc app to Wine
On Thursday 08 February 2007 01:42, Dan Kegel wrote: Can somebody help this (german-speaking) fellow: http://www.unixboard.de/vb3/showthread.php?t=26943 He says his company's internal application requires you to input a DSN when installing it, and he doesn't know how to come up with a DSN under Wine. The german speaking part is not a problem, I just don't know my way around that odbc stuff, not even on win32 native. Presumably he doesn't want to mess with Unixodbc, he just wants to keep using the Microsoft drivers...? I figure using the appropriate native dlls would work? I vaguely remember Windows had a tool to set up odbc drivers, what was the exe called? Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgprUtInjcZhQ.pgp Description: PGP signature
Re: ole32: Remove casts
Mike McCormack wrote: --- This is the way ref counting is done everywhere else in Wine. Ref counts can be assumed to be between 0 and MAXLONG, so the fact that LONG is signed isn't important. NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, therefore the ref counts can be assumed to be up to MAXULONG. Therefore, this change is incorrect and it would lead to subtle signedness errors. Casting ULONG* to LONG* to solve the above problem is unnecessary. -- Rob Shearman
