September 2010 - Wine-devel

Re: Wine Introduction Page
by James Mckenzie 07 Sep '10

07 Sep '10

Ken Thomases <ken(a)codeweavers.com> wrote: >Sent: Sep 7, 2010 9:17 AM >To: James McKenzie <jjmckenzie51(a)earthlink.net> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Wine Introduction Page > >On Sep 4, 2010, at 2:20 PM, James McKenzie wrote: > >> I know it is in git. I don't want to give out bogus information, that's why the question. I don't have an Intel system >>here with MacOSX 10.4 installed anymore, all of mine are at 10.6.4 >> >> Same thing with XCode. I know that the 2.x is at 2.5 but can Wine still be built with 2.4? I don't have the resources >>available to test. > >It still builds on Tiger, although maintaining that may become problematic over time. > >I don't know about Xcode 2.4, but I'm not aware of any breaking changes between 2.4 and 2.5. I expect it still builds >with 2.4 if that's what a user has. > Thank you. No update necessary for this information then. James McKenzie

1 0

[Fwd: Re: Wine Introduction Page]
by James McKenzie 07 Sep '10

07 Sep '10

To the list as well. Can we fix this so that replies go to the list rather than the sender? James McKenzie -------- Original Message -------- Subject: Re: Wine Introduction Page Date: Sat, 04 Sep 2010 12:18:42 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Roderick Colenbrander <thunderbird2k(a)gmail.com> References: <4C8286F5.7090207(a)earthlink.net> <AANLkTikVVEyKVSMb17NePtBvW+pHC3tsmvuYYvF_HVWr(a)mail.gmail.com> Roderick Colenbrander wrote: > On Sat, Sep 4, 2010 at 7:50 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: > >> I was just going over this page and found a few things that I don't know >> about but have questions on for building Wine on the Mac: >> >> The lowest MacOSX version that Wine will build on from the native package is >> stated to be 10.4 (Tiger). Is this still true? >> >> The lowest XCode required is 2.4. Apple stopped supporting this a long time >> ago. I had XCode 2.5 for Tiger. >> >> Can anyone update these? >> >> James McKenzie >> >> >> >> >> > > The website is in git, so feel free to submit patches ;) > I know it is in git. I don't want to give out bogus information, that's why the question. I don't have an Intel system here with MacOSX 10.4 installed anymore, all of mine are at 10.6.4 Same thing with XCode. I know that the 2.x is at 2.5 but can Wine still be built with 2.4? I don't have the resources available to test. James McKenzie

2 1

Re: ntdll: Don't cancel loading on IMAGE_FILE_RELOCS_STRIPPED
by Marcus Meissner 07 Sep '10

07 Sep '10

On Tue, Sep 07, 2010 at 04:37:49PM +0200, André Hentschel wrote: > give the file a try when it only links to ordinals instead of just stopping execution here. > --- > dlls/ntdll/virtual.c | 4 ---- > 1 files changed, 0 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index a42ed5f..0bd3023 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1232,12 +1232,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > const IMAGE_DATA_DIRECTORY *relocs; > > if (nt->FileHeader.Characteristics & IMAGE_FILE_RELOCS_STRIPPED) > - { > WARN_(module)( "Need to relocate module from %p to %p, but there are no relocation records\n", > base, ptr ); > - status = STATUS_CONFLICTING_ADDRESSES; > - goto error; > - } > > TRACE_(module)( "relocating from %p-%p to %p-%p\n", > base, base + total_size, ptr, ptr + total_size ); Have you seen a program needing this? Which? "links to ordinals" is also a wrong comment, as RELOCS are used for relocation addresses within the binary itself (not imports). Ciao, Marcus

3 2

Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
by misha680 07 Sep '10

07 Sep '10

Sorry for reposting - apparently my original nabble link did not work :( --- Dear All: Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I encountered a very strange error. Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter to D3DXCreateMesh, a) in Windows - one can create static const D3DVERTEXELEMENT9 decl1[3] = { {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, {0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, D3DDECL_END(), }; and pass (LPD3DVERTEXELEMENT9 *)&decl1 directly. b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call HeapAlloc, and finally copy my original decl1 and pass &decl (pointer to newly allocated structure) for it to work. Any ideas? Here is my git diff http://wine.1045685.n5.nabble.com/file/n2805603/patch patch Thx Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-… Sent from the Wine - Devel mailing list archive at Nabble.com.

4 4

Re: msi/tests: Fix compilation on systems that don't support nameless unions or structs.
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5078 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 2/6] gameux: initial implementation of IGameExplorer::AddGame
by Nikolay Sivov 07 Sep '10

07 Sep '10

On 9/3/2010 13:25, Mariusz Pluciński wrote: > --- > dlls/gameux/Makefile.in | 2 +- > dlls/gameux/gameexplorer.c | 254 > +++++++++++++++++++++++++++++++++++++- > dlls/gameux/gameux_private.h | 63 ++++++++++ > dlls/gameux/tests/gameexplorer.c | 18 ++-- > 4 files changed, 322 insertions(+), 15 deletions(-) > +/******************************************************************************* > + * _initGameData > + * > + * Internal helper function. Description available in gameux_private.h file > + */ > +void _initGameData(struct GAME_DATA *GameData) > +{ > + GameData->sGDFBinaryPath = NULL; > + GameData->sGameInstallDirectory = NULL; > +} Do you really need another helper for that? Please use better naming like GAMEUX_* for example. > +void _uninitGameData(struct GAME_DATA *GameData) > +{ > + CoTaskMemFree(GameData->sGDFBinaryPath); > + CoTaskMemFree(GameData->sGameInstallDirectory); > +} Any specific reason you need CoTaskMem* here and not a process heap? > + WCHAR sInstanceId[40]; > + WCHAR sRegistryPath[8192]; Where does this come from? Sizes I mean.

2 2

Re: kernel32: forward GetThreadUILanguage() to GetUserDefaultUILanguage() (try 2)
by Alexandre Julliard 07 Sep '10

07 Sep '10

Austin English <austinenglish(a)gmail.com> writes: > @@ -658,6 +658,7 @@ > @ stdcall GetTimeFormatA(long long ptr str ptr long) > @ stdcall GetTimeFormatW(long long ptr wstr ptr long) > @ stdcall GetTimeZoneInformation(ptr) > +@ stdcall GetThreadUILanguage() GetUserDefaultUILanguage You can't do that, the functions are not identical. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] gameux: add support of loading Application Id into registry
by Nikolay Sivov 07 Sep '10

07 Sep '10

On 9/3/2010 13:25, Mariusz Pluciński wrote: > +static HRESULT _ParseGameDefinition( > + IXMLDOMElement *lpXMLGameDefinitionElement, > + struct GAME_DATA *GameData) > +{ > + static const WCHAR sGameId[] = {'g','a','m','e','I','D',0}; > + > + HRESULT hr = S_OK; > + BSTR bstrAttribute = NULL; > + VARIANT variant; No need for initializers here. > + hr = IXMLDOMElement_getAttribute(lpXMLGameDefinitionElement, bstrAttribute,&variant); > + if(hr != S_OK || V_VT(&variant) != VT_BSTR) hr = E_FAIL; No need to test for hr != S_OK and alter failure code after that I guess. > + /* load MSXML parser */ > + hr = CoCreateInstance(&CLSID_DOMDocument30, NULL, CLSCTX_INPROC_SERVER, > +&IID_IXMLDOMDocument, (LPVOID*)&lpXMLDocument); Use neutral CLSID_DOMDocument. Minor things - useless comment, and LPVOID* -> void**. > + IXMLDOMDocument *lpXMLDocument = NULL; > + IXMLDOMNode *lpXMLGameDefinitionNode = NULL; > + IXMLDOMElement *lpXMLRootElement = NULL, *lpXMLGameDefinitionElement = NULL; Same here, you don't need to initialize that. Please use shorter names, like 'root', 'document' or something. > + hr = IXMLDOMDocument_get_documentElement(lpXMLDocument,&lpXMLRootElement); > + if(hr == S_FALSE) > + hr = E_FAIL; hr != S_OK works. P.S. it makes sense to test xml parsing part with native msxml first. This will hopefully show some problems with builtin msxml.

2 1

Typo in : wined3d: Translate before scaling for rhw as well in transform_projection().
by Joris Huizer 07 Sep '10

07 Sep '10

While skimming through recently committed patches, I noticed this piece: + /* Window Coord 0 is the middle of the first pixel, so translate by 1/2 pixels */ + glTranslatef(63.0f / 128.0f, 63.0f / 128.0f, 0.0f); + checkGLcall("glTranslatef(63.0f / 128.0f, -63.0f / 128.0f, 0.0f)"); In the checkGLcall you changed the sign of the second parameter, but you didn't do this in the glTranslatef call. This seemed a bit strange (and I don't know which one would be right). HTH, Joris

2 1

Using the eventlog API for Wine errors
by Paul Vriens 07 Sep '10

07 Sep '10

Hi, I was just reading the emails about the winediag stuff and more particularly AJ's remark about the 'hypothetical GUI'. Would it make sense to really start fleshing out the eventlog API so we can/could log errors (or whatever) in that way? The GUI (or commandline app) could then 'easily' connect to the appropriate eventlog(s). The benefit is that it will make sure the eventlog API is actually implemented and the GUI could tap into historical (until .wine is cleaned) information as well. -- Cheers, Paul.

1 0