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

Re: rpcrt4: Check for null endpoint in RpcServerUseProtseqEpExW

by David Gerard

2009/2/22 Luke Kenneth Casson Leighton <lkcl(a)lkcl.net>: > come on folks, pick up the ball. acknowledge that you're aware that > there is an authoritative source of information on this > horrendously-complex topic, in the form of nothing less than a fully > functioning reference implementation. I don't think anyone questions this. But (speaking as an observer, not someone with any particular power to garner interest for this), I suspect that your best bet for getting traction on this in Wine is: * some apps that use this and work in Windows, but won't work on Wine without the admittedly bletcherous interface being implemented - that is, a good reason to implement this particular interface (remembering that there are large chunks of win32 that Wine doesn't bother implementing because it turns out they're all but unused by actual app developers) * then a conformance test or several that works in Windows but not in Wine. That is, the first thing is a real-life use case or several. - d.

Feb. 24, 2009

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

by Paul Vriens

Nicolas Le Cam wrote: > 2009/2/24 Paul Vriens <paul.vriens.wine(a)gmail.com>: >> Hi, >> >> This makes sure that if we have a dll that's only provided via .NET it can >> still >> be found. Now both our extraction (and the generation of the subtest list) >> and >> the real test will find the dll. >> >> The downside (and hence this is a bit hackish) is that we extend the PATH >> for >> every test. For now it's only gdiplus that needs this btw as that dll can >> also >> exist without .NET (if I'm correct) and these tests directly import gdiplus. >> >> Changelog >> Extend PATH if we have dll's that only come with .NET >> >> -- >> Cheers, >> >> Paul. >> >> >> >From 3cf6c1e876ac032aab988efa0751b26b9643cf93 Mon Sep 17 00:00:00 2001 >> From: Paul Vriens <Paul.Vriens.Wine(a)gmail.com> >> Date: Tue, 24 Feb 2009 14:05:26 +0100 >> Subject: [PATCH] Extend PATH if we have dll's that only come with .NET >> >> --- >> programs/winetest/main.c | 28 +++++++++++++++++++++++++++- >> 1 files changed, 27 insertions(+), 1 deletions(-) >> >> diff --git a/programs/winetest/main.c b/programs/winetest/main.c >> index 74a4307..ee390ec 100644 >> --- a/programs/winetest/main.c >> +++ b/programs/winetest/main.c >> @@ -542,7 +542,33 @@ extract_test_proc (HMODULE hModule, LPCTSTR lpszType, >> 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 *newpath; >> + char dllpath[MAX_PATH]; >> + DWORD needed, pathlen = 0; >> + >> + /* Extend the path so get_subtests() and the test itself can >> find >> + * the dll (gdiplus for example). >> + */ >> + GetModuleFileNameA(dll, dllpath, MAX_PATH); >> + *strrchr(dllpath, '\\') = '\0'; >> + >> + needed = GetEnvironmentVariableA("PATH", NULL, 0); >> + >> + /* current path + ';' + dllpath + '\0' */ >> + pathlen = needed + 1 + strlen(dllpath) + 1; >> + newpath = xmalloc(pathlen); >> + GetEnvironmentVariable("PATH", newpath, pathlen); >> + >> + strcat(newpath, ";"); >> + strcat(newpath, dllpath); >> + SetEnvironmentVariableA("PATH", newpath); >> + >> + free(newpath); >> + } >> } >> if (!dll) { >> xprintf (" %s=dll is missing\n", dllname); >> -- >> 1.6.0.6 >> >> >> >> >> >> > > What about extending wine_test struct with a path variable that will > be set and restored around the CreateProcess call in run_ex if not > null ? > That will provide us at least with a per-test PATH change if needed. Let me think about that one a bit more (maybe AJ already has another/better idea, how to solve this) as that requires some bigger changes. -- Cheers, Paul.

Feb. 24, 2009

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

by Nicolas Le Cam

2009/2/24 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > This makes sure that if we have a dll that's only provided via .NET it can > still > be found. Now both our extraction (and the generation of the subtest list) > and > the real test will find the dll. > > The downside (and hence this is a bit hackish) is that we extend the PATH > for > every test. For now it's only gdiplus that needs this btw as that dll can > also > exist without .NET (if I'm correct) and these tests directly import gdiplus. > > Changelog > Extend PATH if we have dll's that only come with .NET > > -- > Cheers, > > Paul. > > > >From 3cf6c1e876ac032aab988efa0751b26b9643cf93 Mon Sep 17 00:00:00 2001 > From: Paul Vriens <Paul.Vriens.Wine(a)gmail.com> > Date: Tue, 24 Feb 2009 14:05:26 +0100 > Subject: [PATCH] Extend PATH if we have dll's that only come with .NET > > --- > programs/winetest/main.c | 28 +++++++++++++++++++++++++++- > 1 files changed, 27 insertions(+), 1 deletions(-) > > diff --git a/programs/winetest/main.c b/programs/winetest/main.c > index 74a4307..ee390ec 100644 > --- a/programs/winetest/main.c > +++ b/programs/winetest/main.c > @@ -542,7 +542,33 @@ extract_test_proc (HMODULE hModule, LPCTSTR lpszType, > 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 *newpath; > + char dllpath[MAX_PATH]; > + DWORD needed, pathlen = 0; > + > + /* Extend the path so get_subtests() and the test itself can > find > + * the dll (gdiplus for example). > + */ > + GetModuleFileNameA(dll, dllpath, MAX_PATH); > + *strrchr(dllpath, '\\') = '\0'; > + > + needed = GetEnvironmentVariableA("PATH", NULL, 0); > + > + /* current path + ';' + dllpath + '\0' */ > + pathlen = needed + 1 + strlen(dllpath) + 1; > + newpath = xmalloc(pathlen); > + GetEnvironmentVariable("PATH", newpath, pathlen); > + > + strcat(newpath, ";"); > + strcat(newpath, dllpath); > + SetEnvironmentVariableA("PATH", newpath); > + > + free(newpath); > + } > } > if (!dll) { > xprintf (" %s=dll is missing\n", dllname); > -- > 1.6.0.6 > > > > > > What about extending wine_test struct with a path variable that will be set and restored around the CreateProcess call in run_ex if not null ? -- Nicolas Le Cam

Feb. 24, 2009

Re: Simple but awesome demos of Wine?

by David Gerard

2009/2/24 Ben Klein <shacklein(a)gmail.com>: > 2009/2/24 Vit Hrachovy <vit.hrachovy(a)sandbox.cz>: >> Mmmm. According to AppDB Runescape is said to work well in Wine ;) >> That's another layer-within-layer - Runespace is an MMORPG written in >> JAVA/OpenGL as browser-embedded application. > Sounds like something that could work equally well natively ... It does. Also on Macs. - d.

Feb. 24, 2009

Re: Simple but awesome demos of Wine?

by Vit Hrachovy

Ben Klein wrote: > 2009/2/24 Vit Hrachovy <vit.hrachovy(a)sandbox.cz>: >> Mmmm. According to AppDB Runescape is said to work well in Wine ;) >> That's another layer-within-layer - Runespace is an MMORPG written in >> JAVA/OpenGL as browser-embedded application. > > Sounds like something that could work equally well natively ... Hi Ben, surely it works natively well. Tested on people! The $subj tells about simple and awesome demos ... 'of complexity Wine can handle'. One sample of complexity is gaming GUI automation mentioned in the previous posts. Another sample of elegance could be JAVA and DotNet apps embedded in browser. Imagine if Wine could handle MS SharePoint 3.0 installation... Hark

Feb. 24, 2009

Re: Simple but awesome demos of Wine?

by Ben Klein

2009/2/24 Vit Hrachovy <vit.hrachovy(a)sandbox.cz>: > Mmmm. According to AppDB Runescape is said to work well in Wine ;) > That's another layer-within-layer - Runespace is an MMORPG written in > JAVA/OpenGL as browser-embedded application. Sounds like something that could work equally well natively ...

Feb. 24, 2009

Re: Simple but awesome demos of Wine?

by Vit Hrachovy

ACK, I like it too :) VirtualDesktop is one workaround, second is using 'xrandr -s 0' past wine exit. As I have each game installed into individual WINEPREFIX, I've got game start scripts in ~/bin that handle WINEDEBUG=-all before start and 'xrandr -s 0' after exit. Although, on Linux I usually play with Wine Virtual desktop (to be able to listen on ICQ and for easier app switching). Mmmm. According to AppDB Runescape is said to work well in Wine ;) That's another layer-within-layer - Runespace is an MMORPG written in JAVA/OpenGL as browser-embedded application. Cheers Hark Tom Wickline wrote: > Hello Dan, > Maybe run the game in a Virtual Desktop? > Tom > > On Tue, Feb 24, 2009 at 1:57 PM, Dan Kegel <dank(a)kegel.com > <mailto:dank(a)kegel.com>> wrote: > > > Wow. I just tried LOTRBFME2 :-) and it's impressive. > Only problem so far is that it doesn't restore video resolution on exit. > Otherwise it's the coolest game of the sort I've ever seen. > (I don't get out much :-) > - Dan

Feb. 24, 2009

Re: [try2] gdiplus/tests: Dynamically load gdiplus.dll.

by Paul Vriens

Vincent Povirk wrote: > On Mon, Feb 23, 2009 at 6:15 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> The reason you see this is because next to a normal LoadLibrary we also use the >> .NET variant. On some boxes gdiplus.dll cannot be found through LoadLibrary but >> will trough LoadLibraryShim. As winetest now thinks the library is there it will >> try to launch "gdiplus_test.exe --list" and that of course fails. >> >> Not sure how to approach this. > > Silly question: > > Could we, if LoadLibraryShim returns a library that isn't in the PATH, > add it to the PATH in the environment used to call the test exe? Then > we would be able to run tests on some "new" versions of dll's we can't > cover currently. > I've been thinking along those same lines. I don't have much time this week but I'll see what I can do. If somebody wants to beat me to it, be my guest ;) -- Cheers, Paul.

Feb. 24, 2009

Re: advapi32: Stubs for GetNamedSecurityInfoEx (attempt 4)

by Austin English

On Tue, Feb 24, 2009 at 1:59 AM, Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> wrote: > Reference bug 14334 (WordPerfect Office 2002: Unable to Install) > > Use of breakpoints in a debugger under WindowsTM has shown that > GetNamedSecurityInfoExA is called during a normal installation. From > this we infer that some kind of implementation of this routine is > necessary if the app in question is ever to install. It has been > determined empirically that a empty sub is sufficient. > > This attempt has been written without reference to the previous attempts > or to the piclist web site. It takes on board feedback received and has > done after study of carefully distilled precedent exposed at: > > http://wiki.jswindle.com/index.php/Stubs_Partially_Explained#Brief_Stub_Cod… > > http://wiki.jswindle.com/index.php/Coding_Hints:Patches#Copyright > > The patch provides a stub pair for the A and W forms of > GetNamedSecurityInfoEx. Prototypes in include/aclapi.h, implementations > in advapi32/security.c and the whats-it-called in advapi32/advapi32.spec. > > No reference to GetNamedSecurityInfoEx is to be found on the MSDN > web-site: the signature of these stubs is derived by splicing to > together GetNamedSecurityInfo and GetSecurityInfoEx (as found in > aclapi.h etc). You forgot the patch :-). -- -Austin

Feb. 24, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/24 Damjan Jovanovic <damjan.jov(a)gmail.com>: > It generates an association from a file extension, to open with the > handler for its ProgID currently in the registry. > > So it allows .txt to open with Notepad and .dev to open with Dev-C++. > It does not make Wine open a new .exe by default - at least, that was > not the intention. This reminds me of something. On some (all? at least, all with registry?) versions of Windows, when the user double-clicks a .exe, .com, .bat etc, Windows looks up the handler for that filetype in the registry. Some malware (and potentially some virus scanners too) replace the .exe, .dll, .com etc handlers with a rundll32 call that pre-processes the executable. Now, I'm pretty sure Wine doesn't do this. Someone correct me if I'm wrong. In terms of bug-for-bug compatibility, it should, but I think in this case it would be safe to diverge from bug-for-bug :)

Feb. 24, 2009