February 2009 - Wine-Devel - list.winehq.org

Re: [programs/winetest] Extend PATH if we have dll's that only come with .NET (Try2)

by Nicolas Le Cam

2009/2/25 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Nicolas Le Cam wrote: >>>>> >>>>> + >>>>> + /* We have a dll that cannot be found through >>>>> LoadLibraryExA. >>>>> This >>>>> + * is the case for .NET provided dll's. We will add the >>>>> directory >>>>> + * where the dll resides to the PATH variable when dealing >>>>> with >>>>> + * the tests for this dll. >>>>> + */ >>>>> + GetModuleFileNameA(dll, dllpath, MAX_PATH); >>>>> + *strrchr(dllpath, '\\') = '\0'; >>>>> + wine_tests[nr_of_files].maindllpath = >>>>> xmalloc(strlen(dllpath) + >>>>> 1); >>>>> + strcpy(wine_tests[nr_of_files].maindllpath, dllpath); >>>>> + } >>>> >>>> This won't work if test needs more than one dll found through >>>> LoadLibraryShim >>>> >>> Not sure what you mean as LoadLibraryShim will only return 1 dll. >> >> I mean if the test imports more than one dll that can only be found by >> LoadLibraryShim it will replace the first PATH you retrieved by the >> second one, and a message will be displayed for the first d. In my >> test I did something like that : >> >> else >> { >> char dllpath[MAX_PATH]; >> >> /* We have a dll that cannot be found through LoadLibraryExA. >> This >> * is the case for .NET provided dll's. We will add the >> directory >> * where the dll resides to the PATH variable when dealing with >> * the tests for this dll. >> */ >> GetModuleFileNameA(dll, dllpath, MAX_PATH); >> *strrchr(dllpath, '\\') = '\0'; >> if (!wine_tests[nr_of_files].maindllpath) >> wine_tests[nr_of_files].maindllpath = strmake ( NULL, >> ";%s", dllpath); >> else >> { >> char *newpath = wine_tests[nr_of_files].maindllpath; >> >> wine_tests[nr_of_files].maindllpath = strmake ( NULL, >> "%s;%s", newpath, dllpath); >> free(newpath); >> } >> } >> >> and wine_tests[nr_of_files].maindllpath = NULL; wasn't set in >> extract_test_proc >> > I still don't get it. > > The only dll that we try to load is the main dll. We don't care about all > the other imports. > > -- > Cheers, > > Paul. > Now I get it. I thought we were trying to resolve every imports. Seems that I didn't understand the first part of extract_test_proc as I should. Sorry, I was mistaken. -- Nicolas Le Cam

Feb. 25, 2009

Re: [programs/winetest] Extend PATH if we have dll's that only come with .NET (Try2)

by Paul Vriens

Nicolas Le Cam wrote: >>>> + >>>> + /* We have a dll that cannot be found through >>>> LoadLibraryExA. >>>> This >>>> + * is the case for .NET provided dll's. We will add the >>>> directory >>>> + * where the dll resides to the PATH variable when dealing >>>> with >>>> + * the tests for this dll. >>>> + */ >>>> + GetModuleFileNameA(dll, dllpath, MAX_PATH); >>>> + *strrchr(dllpath, '\\') = '\0'; >>>> + wine_tests[nr_of_files].maindllpath = >>>> xmalloc(strlen(dllpath) + >>>> 1); >>>> + strcpy(wine_tests[nr_of_files].maindllpath, dllpath); >>>> + } >>> This won't work if test needs more than one dll found through >>> LoadLibraryShim >>> >> Not sure what you mean as LoadLibraryShim will only return 1 dll. > > I mean if the test imports more than one dll that can only be found by > LoadLibraryShim it will replace the first PATH you retrieved by the > second one, and a message will be displayed for the first d. In my > test I did something like that : > > else > { > char dllpath[MAX_PATH]; > > /* We have a dll that cannot be found through LoadLibraryExA. This > * is the case for .NET provided dll's. We will add the directory > * where the dll resides to the PATH variable when dealing with > * the tests for this dll. > */ > GetModuleFileNameA(dll, dllpath, MAX_PATH); > *strrchr(dllpath, '\\') = '\0'; > if (!wine_tests[nr_of_files].maindllpath) > wine_tests[nr_of_files].maindllpath = strmake ( NULL, > ";%s", dllpath); > else > { > char *newpath = wine_tests[nr_of_files].maindllpath; > > wine_tests[nr_of_files].maindllpath = strmake ( NULL, > "%s;%s", newpath, dllpath); > free(newpath); > } > } > > and wine_tests[nr_of_files].maindllpath = NULL; wasn't set in extract_test_proc > I still don't get it. The only dll that we try to load is the main dll. We don't care about all the other imports. -- Cheers, Paul.

Feb. 25, 2009

Re: [programs/winetest] Extend PATH if we have dll's that only come with .NET (Try2)

by Nicolas Le Cam

>>> + >>> + /* We have a dll that cannot be found through >>> LoadLibraryExA. >>> This >>> + * is the case for .NET provided dll's. We will add the >>> directory >>> + * where the dll resides to the PATH variable when dealing >>> with >>> + * the tests for this dll. >>> + */ >>> + GetModuleFileNameA(dll, dllpath, MAX_PATH); >>> + *strrchr(dllpath, '\\') = '\0'; >>> + wine_tests[nr_of_files].maindllpath = >>> xmalloc(strlen(dllpath) + >>> 1); >>> + strcpy(wine_tests[nr_of_files].maindllpath, dllpath); >>> + } >> >> This won't work if test needs more than one dll found through >> LoadLibraryShim >> > > Not sure what you mean as LoadLibraryShim will only return 1 dll. I mean if the test imports more than one dll that can only be found by LoadLibraryShim it will replace the first PATH you retrieved by the second one, and a message will be displayed for the first d. In my test I did something like that : else { char dllpath[MAX_PATH]; /* We have a dll that cannot be found through LoadLibraryExA. This * is the case for .NET provided dll's. We will add the directory * where the dll resides to the PATH variable when dealing with * the tests for this dll. */ GetModuleFileNameA(dll, dllpath, MAX_PATH); *strrchr(dllpath, '\\') = '\0'; if (!wine_tests[nr_of_files].maindllpath) wine_tests[nr_of_files].maindllpath = strmake ( NULL, ";%s", dllpath); else { char *newpath = wine_tests[nr_of_files].maindllpath; wine_tests[nr_of_files].maindllpath = strmake ( NULL, "%s;%s", newpath, dllpath); free(newpath); } } and wine_tests[nr_of_files].maindllpath = NULL; wasn't set in extract_test_proc

Feb. 25, 2009

Re: [1/3] wordpad: Added missing string values for some languages.

by Michael Stefaniuc

Hello Dylan, please do not add the English strings for stringtable resources that aren't broken (here the Hungarian translation). It makes it hard to automatically detect (http://www.mikolaj.zalewski.pl/wine-transl/) if the resource is translated or not. Also you have fixed only the traditional Chinese stringtable but not the simplified Chinese one in the same Zh.rc file. The best way to check for translation errors is to pass --verify-translation to the wrc command invoked from the Makefile and look for ERR and DIFF lines. Dylan Smith wrote: > There were some string that were only available in for certain > languages, so I copied the english version of these values. > --- > programs/wordpad/Da.rc | 5 +++++ > programs/wordpad/Hu.rc | 18 ++++++++++++++++++ > programs/wordpad/Ja.rc | 1 + > programs/wordpad/No.rc | 1 + > programs/wordpad/Pl.rc | 5 +++++ > programs/wordpad/Ru.rc | 6 +++++- > programs/wordpad/Tr.rc | 5 +++++ > programs/wordpad/Zh.rc | 1 + > 8 files changed, 41 insertions(+), 1 deletions(-) > bye michael

Feb. 25, 2009

Re: [programs/winetest] Extend PATH if we have dll's that only come with .NET (Try2)

by Paul Vriens

Nicolas Le Cam wrote: > Hi Paul, minor comments : > >> +static void append_path( const char *path) >> +{ >> + char *newpath; >> + >> + newpath = xmalloc(strlen(curpath) + 1 + strlen(path) + 1); >> + strcpy(newpath, curpath); >> + strcat(newpath, ";"); >> + strcat(newpath, path); >> + SetEnvironmentVariableA("PATH", newpath); >> + >> + free(newpath); >> +} > Perhaps use newpath = strmake( NULL, "%s;%s", curpath, path); I don't > know. (I used it in a similar patch that I was making yesterday) > Just a matter of preference I guess. >> if (!dll && pLoadLibraryShim) >> { >> MultiByteToWideChar(CP_ACP, 0, dllname, -1, dllnameW, MAX_PATH); >> - if (FAILED( pLoadLibraryShim(dllnameW, NULL, NULL, &dll) )) dll = >> 0; >> + if (FAILED( pLoadLibraryShim(dllnameW, NULL, NULL, &dll) )) >> + dll = 0; >> + else >> + { >> + char dllpath[MAX_PATH]; > dllpath should be declared at start of the function IMHO. > It's only needed in the else branch. >> + >> + /* We have a dll that cannot be found through LoadLibraryExA. >> This >> + * is the case for .NET provided dll's. We will add the >> directory >> + * where the dll resides to the PATH variable when dealing with >> + * the tests for this dll. >> + */ >> + GetModuleFileNameA(dll, dllpath, MAX_PATH); >> + *strrchr(dllpath, '\\') = '\0'; >> + wine_tests[nr_of_files].maindllpath = xmalloc(strlen(dllpath) + >> 1); >> + strcpy(wine_tests[nr_of_files].maindllpath, dllpath); >> + } > This won't work if test needs more than one dll found through LoadLibraryShim > Not sure what you mean as LoadLibraryShim will only return 1 dll. >> } >> if (!dll) { >> xprintf (" %s=dll is missing\n", dllname); >> @@ -578,6 +619,12 @@ run_tests (char *logname) >> DWORD strsize; >> SECURITY_ATTRIBUTES sa; >> char tmppath[MAX_PATH], tempdir[MAX_PATH+4]; >> + DWORD needed; >> + >> + /* Get the current PATH only once */ >> + needed = GetEnvironmentVariableA("PATH", NULL, 0); >> + curpath = xmalloc(needed); >> + GetEnvironmentVariable("PATH", curpath, needed); > This should be GetEnvironmentVariableA. > Well it would work anyway but for consistency sake I will change that. -- Cheers, Paul.

Feb. 25, 2009

Re: [programs/winetest] Extend PATH if we have dll's that only come with .NET (Try2)

by Nicolas Le Cam

Hi Paul, minor comments : > programs/winetest/main.c | 60 > +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 59 insertions(+), 1 deletions(-) > > diff --git a/programs/winetest/main.c b/programs/winetest/main.c > index 74a4307..58e520b 100644 > --- a/programs/winetest/main.c > +++ b/programs/winetest/main.c > @@ -44,6 +44,7 @@ struct wine_test > int subtest_count; > char **subtests; > char *exename; > + char *maindllpath; > }; > > char *tag = NULL; > @@ -61,6 +62,9 @@ static unsigned int nb_filters = 0; > static HMODULE hmscoree; > static HRESULT (WINAPI *pLoadLibraryShim)(LPCWSTR, LPCWSTR, LPVOID, HMODULE > *); > > +/* To store the current PATH setting (related to .NET only provided dlls) > */ > +static char *curpath; > + > /* check if test is being filtered out */ > static BOOL test_filtered_out( LPCSTR module, LPCSTR testname ) > { > @@ -341,6 +345,19 @@ static DWORD wait_process( HANDLE process, DWORD > timeout ) > return WAIT_TIMEOUT; > } > > +static void append_path( const char *path) > +{ > + char *newpath; > + > + newpath = xmalloc(strlen(curpath) + 1 + strlen(path) + 1); > + strcpy(newpath, curpath); > + strcat(newpath, ";"); > + strcat(newpath, path); > + SetEnvironmentVariableA("PATH", newpath); > + > + free(newpath); > +} Perhaps use newpath = strmake( NULL, "%s;%s", curpath, path); I don't know. (I used it in a similar patch that I was making yesterday) > + > /* Run a command for MS milliseconds. If OUT != NULL, also redirect > stdout to there. > > @@ -446,8 +463,16 @@ get_subtests (const char *tempdir, struct wine_test > *test, LPTSTR res_name) > > extract_test (test, tempdir, res_name); > cmd = strmake (NULL, "%s --list", test->exename); > + if (test->maindllpath) { > + /* We need to add the path (to the main dll) to PATH */ > + append_path(test->maindllpath); > + } > status = run_ex (cmd, subfile, tempdir, 5000); > err = GetLastError(); > + if (test->maindllpath) { > + /* Restore PATH again */ > + SetEnvironmentVariableA("PATH", curpath); > + } > free (cmd); > > if (status == -2) > @@ -538,11 +563,27 @@ extract_test_proc (HMODULE hModule, LPCTSTR lpszType, > strcpy(dllname, lpszName); > *strstr(dllname, testexe) = 0; > > + wine_tests[nr_of_files].maindllpath = NULL; > dll = LoadLibraryExA(dllname, NULL, LOAD_LIBRARY_AS_DATAFILE); > if (!dll && pLoadLibraryShim) > { > MultiByteToWideChar(CP_ACP, 0, dllname, -1, dllnameW, MAX_PATH); > - if (FAILED( pLoadLibraryShim(dllnameW, NULL, NULL, &dll) )) dll = > 0; > + if (FAILED( pLoadLibraryShim(dllnameW, NULL, NULL, &dll) )) > + dll = 0; > + else > + { > + char dllpath[MAX_PATH]; dllpath should be declared at start of the function IMHO. > + > + /* We have a dll that cannot be found through LoadLibraryExA. > This > + * is the case for .NET provided dll's. We will add the > directory > + * where the dll resides to the PATH variable when dealing with > + * the tests for this dll. > + */ > + GetModuleFileNameA(dll, dllpath, MAX_PATH); > + *strrchr(dllpath, '\\') = '\0'; > + wine_tests[nr_of_files].maindllpath = xmalloc(strlen(dllpath) + > 1); > + strcpy(wine_tests[nr_of_files].maindllpath, dllpath); > + } This won't work if test needs more than one dll found through LoadLibraryShim > } > if (!dll) { > xprintf (" %s=dll is missing\n", dllname); > @@ -578,6 +619,12 @@ run_tests (char *logname) > DWORD strsize; > SECURITY_ATTRIBUTES sa; > char tmppath[MAX_PATH], tempdir[MAX_PATH+4]; > + DWORD needed; > + > + /* Get the current PATH only once */ > + needed = GetEnvironmentVariableA("PATH", NULL, 0); > + curpath = xmalloc(needed); > + GetEnvironmentVariable("PATH", curpath, needed); This should be GetEnvironmentVariableA. > > SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); > > @@ -684,11 +731,21 @@ run_tests (char *logname) > struct wine_test *test = wine_tests + i; > int j; > > + if (test->maindllpath) { > + /* We need to add the path (to the main dll) to PATH */ > + append_path(test->maindllpath); > + } > + > for (j = 0; j < test->subtest_count; j++) { > report (R_STEP, "Running: %s:%s", test->name, > test->subtests[j]); > run_test (test, test->subtests[j], logfile, tempdir); > } > + > + if (test->maindllpath) { > + /* Restore PATH again */ > + SetEnvironmentVariableA("PATH", curpath); > + } > } > report (R_DELTA, 0, "Running: Done"); > > @@ -697,6 +754,7 @@ run_tests (char *logname) > logfile = 0; > remove_dir (tempdir); > free (wine_tests); > + free (curpath); > > return logname; > } I did a similar patch yesterday but forget to set PATH around run_ex in get_subtests so it didn't work when I tested on my W2K Pro test platform. Thanks for your work -- Nicolas Le Cam

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

On Tuesday 24 February 2009 8:57:23 pm Scott Ritchie wrote: > It would also make it completely unusable. Remember, all downloaded > executables (even intentionally downloaded ones) will be -x by default. > Do you really expect users to go right > click->properties->permissions->allow execution? Or will they just > conclude that it doesn't work. I would expect them to mark it executable. That's how most Unix systems work. A Linux-native executable/script would need to be set as executable by the user all the same. > Worse, you could actively irritate them - suppose they do double click > and you DONT offer the ability to open it, but instead instruct them to > go through that annoying procedure. It's hardly annoying as it takes all of two seconds (or less). It's part of normal system operation that the user will already have to deal with outside of Wine. And at least they'll know that it's something that is going to be executing, instead of simply opened/read. Trading safety for user convenience like that is a bad habit to pick up. > > Not necessarily. Along with the .desktop trojan, the blog I read also > > showed how to override system menu entries (by placing a replacement in > > the local folder which will override the system one). So the link you > > clicked on may not be what you intended.. > > But in order to do that a malicious script has to already be running! > Such a system is already owned. True enough, I suppose. It just seems unnecessary to me to special-case it since a program installed via Wine (that would have created such a menu entry) is already marked as +x. What kind of scenario would there be for a user to have a menu entry and the program its pointing to to unknowingly be -x?

Feb. 25, 2009

Re: [2/2] WineD3D: Create a common sampling function in GLSL

by Henri Verbeet

2009/2/24 Stefan Dösinger <stefan(a)codeweavers.com>: > > +static void shader_glsl_gen_sample_code(const SHADER_OPCODE_ARG *arg, DWORD sampler, const char *coord_reg, > + const glsl_sample_function_t *sample_function, const char *dst_swizzle, > + const char *bias) { You need to pass dst_swizzle as a swizzle + write mask instead of a string. As an API it's nicer than passing in random strings, but you will also need this when you're going to integrate the fixup code. I think it's a bit silly to pass sample_function to this function, the caller will only call shader_glsl_get_sample_function() to pass it to this function, so you might as well call it yourself. > + shader_glsl_append_dst(arg->buffer, arg); I'm not sure about this one. It's not strictly necessary to do this in the caller, but it would be more consistent between different instruction handlers to do it there, and have shader_glsl_gen_sample_code() only generate the second part of the line. I think it would be nicer to avoid the stack buffers foor coord_reg, either by splitting shader_glsl_gen_sample_code() in two functions to generate the start and end, or by passing it a format string for coord_reg. > + sprintf(instr, "%sLod", sample_function.name); > + sample_function.name = instr; > + shader_glsl_gen_sample_code(arg, sampler_idx, coord_param.param_str, > + &sample_function, dst_swizzle, > + lod_param.param_str); This is just ugly.

Feb. 25, 2009

aquamark 3 crashing on startup?

by Dan Kegel

I was hoping to demo aquamark 3, but it now crashes for me on startup. Did I forget the magic incantation to run it successfully? http://appdb.winehq.org/objectManager.php?sClass=version&iId=6616

Feb. 25, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/25 Scott Ritchie <scott(a)open-vote.org>: > Chris Robinson wrote: >> On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote: >>> When I brought this up at the Ubuntu Developer Summit a while back, the >>> security conscious there wanted to check an executable for the execute >>> bit before launching it with Wine. Then, the user would be prompted if >>> they wanted to run it, and if yes the execute bit would be set and the >>> program launched. >> >> Seems a bit too easy to me for this to be ineffective. It's been repeated >> often around here how people, especially Windows users, are conditioned to >> click "Yes" and not actually see or comprehend what they're clicking yes too >> ("I thought it was going to open it in notepad, not run it!"). IMHO, it would >> be better if they had to take the initiative to mark it +x, then run it again. >> That would prevent these kinds of surprises. >> > > It would also make it completely unusable. Remember, all downloaded > executables (even intentionally downloaded ones) will be -x by default. > Do you really expect users to go right > click->properties->permissions->allow execution? Or will they just > conclude that it doesn't work. > > Worse, you could actively irritate them - suppose they do double click > and you DONT offer the ability to open it, but instead instruct them to > go through that annoying procedure. And what happens if they intentionally download a Linux-native executable or script? It won't run unless it's marked +x or passed as an argument to the appropriate interpreter. Wine/Windows apps shouldn't be different. It's admirable to think of new users and say "how much will they get?", but you're holding them back if you don't educate them with things like this. If it's the *correct* way to do it, which I believe it is, it's *incorrect* to assume that new users are incapable of learning how to +x their apps when they're downloaded. >>> This check would be skipped if you clicked a link on the start menu >>> (since you obviously meant to launch a program then). >> >> Not necessarily. Along with the .desktop trojan, the blog I read also showed >> how to override system menu entries (by placing a replacement in the local >> folder which will override the system one). So the link you clicked on may not >> be what you intended.. > > But in order to do that a malicious script has to already be running! > Such a system is already owned. What he's talking about here, if I understand correctly, is a .desktop file that can be clicked on in a web browser, and executed by the system without warning. It's an entry-point for malware.

Feb. 25, 2009