May 2005 - Wine-Devel - list.winehq.org

Half Life 2 error -- err:mmio:MMIO_ParseExtA

by J. Grant

Hello, I am getting this error when trying to run Half Life2 in err:mmio:MMIO_ParseExtA. Could someone tell me if this is a problem in in WINE, or a problem in my setup? Or not an error at all..? Also if there is already a document on setting up Half Life2 could someone direct me to it please, I could not find one already. $ wcmd Invoking /usr/lib/wine/wine.bin wcmd.exe ... WCMD Version 0.17 Z:\home\now3d>cd C:\opt\games\steam\ C:\opt\games\steam>C:\opt\games\steam\Steam.exe -applaunch 220 C:\opt\games\steam>err:dc:CreateDCW no driver found for L"WINEPS" fixme:winspool:AddPrinterW DocumentPropertiesW on printer 'L"deskjet930c"' fails err:dc:CreateDCW no driver found for L"WINEPS" err:dc:CreateDCW no driver found for L"WINEPS" fixme:winspool:AddPrinterW DocumentPropertiesW on printer 'L"hp930c"' fails err:dc:CreateDCW no driver found for L"WINEPS" err:mmio:MMIO_ParseExtA No . in szFileName: "" err:mmio:MMIO_ParseExtA No . in szFileName: "C:\\opt\\games\\steam\\" You need to install the Mozilla ActiveX control to use Wine's builtin CLSID_WebBrowser from SHDOCVW.DLL fixme:ole:CoCreateInstance no instance created for interface {00000000-0000-0000-c000-000000000046} of class {8856f961-340a-11d0-a96b-00c04fd705a2},hres is 0x80040111 fixme:debug_buffer:RtlCreateQueryDebugBuffer (0, 0): stub fixme:debug_buffer:RtlCreateQueryDebugBuffer (96, 0): returning 0x40473b08 fixme:debug_buffer:RtlQueryProcessDebugInformation (11, 80000001, 0x40473b08): stub fixme:debug_buffer:RtlDestroyQueryDebugBuffer (0x40473b08): stub C:\opt\games\steam> C:\opt\games\steam> C:\opt\games\steam>Shutting down. . . 30client callback thread error C:\opt\games\steam>STEAM.exe "steam://open/registerproduct/220" C:\opt\games\steam>err:mmio:MMIO_ParseExtA No . in szFileName: "" err:mmio:MMIO_ParseExtA No . in szFileName: "C:\\opt\\games\\steam\\" fixme:sync:CreateIoCompletionPort (0xffffffff, (nil), 00000000, 00000000): stub. fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x4046b9a0): not verifying image Shutting down. . . 1completionportmanager.cpp (28) : Assertion Failed: m_hIOCP C:\opt\games\steam>exit -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

May 29, 2005

Re: [ddraw] Mipmap creation with DDSCAPS_COMPLEX, DDSCAPS_MIPMAP, and no mipmap count

by Antoine Chavasse

Mike Hearn <mh(a)codeweavers.com> wrote: > I can't comment on the DirectX side of things, but this looks like a > textbook case of how to do a patch correct. Thanks :) On 5/29/05, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > > The only (minor) gripe I would have with this patch is the use of the 'log() > / log()' to compute the mipmap count (I usually dislike floating point match > - it's maybe my background in embedded programming where FPU are inexistant > :-) )... I would have found it simpler to just have a 'while (min > 0) { min > >>= 1; count += 1 }'. > Alright. I'll resend the patch with this change.

May 29, 2005

Re: Make more of the OLE interface vtables const

by Dimi Paun

On Sun, 2005-05-29 at 20:49 +0200, Andreas Mohr wrote: > So, does anybody know what seems to be wrong with winegcc or why it > chose to do that? winegcc is just a wrapper around gcc, it just passes stuff on to the native compiler. I doubt it's because of that (unless some of the additional options we pass have such an effect). -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

May 29, 2005

Re: Make more of the OLE interface vtables const

by Andreas Mohr

Hi, On Sun, May 29, 2005 at 07:05:49PM +0900, Dmitry Timoshkov wrote: > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Make more of the OLE interface vtables const. You do know that those will *not* end up const? filemoniker.c:static const IClassFactoryVtbl FileMonikerCFVtbl = objdump -x ole32.dll.so: 0008efb0 l O .data 00000014 FileMonikerCFVtbl My suspicion is that this is due to winegcc compile, all other binaries with normal compile (e.g. winedump, ...) have all their const data in .rodata segment... So, does anybody know what seems to be wrong with winegcc or why it chose to do that? BTW, I already completely constified programs/ and tools/, will send a patch soon. Andreas

May 29, 2005

Re: dlls/oleaut32/olepicture.c won't compile

by Marcus Meissner

> Hmm, this seems weird, I looked into the config.log after running > configure, but the tests for libgif already do fail when using the wrong > library version (DGifOpen (); is missing; it reads: > > configure:15519: checking for -lungif soname > configure:15549: gcc -o conftest -g -O2 conftest.c -lungif >&5 > /tmp/ccie7Kbp.o(.text+0xa): In function `main': > /home/jorishuizer/.wine-source/wine/conftest.c:176: undefined reference > to `DGifOpen' > collect2: ld returned 1 exit status > configure:15555: $? = 1 > configure: failed program was: > ... > configure:15584: result: libungif.so This is a result of the dynamically loaded libungif.so / libgif.so, it expects that it has this symbol. So exactly what distro has this problem, all modern ones should not have it. Ciao, Marcus

May 29, 2005

Re: [ddraw] Mipmap creation with DDSCAPS_COMPLEX, DDSCAPS_MIPMAP, and no mipmap count

by Lionel Ulmer

As already said by Mike, nice patch (and also nice test script). I think I was the one who added the previous comment (and it's true that I only tested it without the COMPLEX bit set). The only (minor) gripe I would have with this patch is the use of the 'log() / log()' to compute the mipmap count (I usually dislike floating point match - it's maybe my background in embedded programming where FPU are inexistant :-) )... I would have found it simpler to just have a 'while (min > 0) { min >>= 1; count += 1 }'. Lionel -- Lionel Ulmer - http://www.bbrox.org/

May 29, 2005

Re: [ddraw] Mipmap creation with DDSCAPS_COMPLEX, DDSCAPS_MIPMAP, and no mipmap count

by Mike Hearn

On Sat, 28 May 2005 23:36:52 +0200, Antoine Chavasse wrote: > I don't know if I did this right, any comment is welcome. I can't comment on the DirectX side of things, but this looks like a textbook case of how to do a patch correct. Unified diff from the source root, test cases, clear explanation, good comments, no extra changes ... good going! We need every patch to be like this! (And I say that as somebody who breaks those rules a lot ;)

May 29, 2005

Re: [DPlay] Added keys for the various DPlay service providers

by Mike Hearn

On Sat, 28 May 2005 17:04:59 +0200, Lionel Ulmer wrote: > After, if I continue to be motivated to hack on DPlay, I may take a shot at > implementing a built-in version of 'dpwsockx.dll' (I never touched any > Windows networking programming so it could be nice to change a bit). Good luck! Be warned, the DirectPlay network protocol is undocumented (well, maybe somebody reverse engineered it and put the specs up somewhere but I'm not sure). thanks -mike

May 29, 2005

Re: tab: Shift selected tab text up instead of down

by Vitaliy Margolen

Sunday, May 29, 2005, 2:17:12, Vitaliy Margolen wrote: > Hi, > Changelog > * Shift selected tab text up instead of down. >- drawRect->>bottom += 3; >+ drawRect->>bottom -= 3; This does not shift tab up. This will shrink tab text area instead of growing it. Also you missed note above about keeping TAB_DrawItem in sync with this part. All these numbers had been verified against native, including custom drawn tabs (see WM_DRAWITEM message). Vitaliy.

May 29, 2005

Re: Translate the WineFAQ to French

by Dimi Paun

On Sun, 2005-05-29 at 02:27 +0200, Francois Gouget wrote: > They response to my email regarding the Po4a dependencies was very > positive. They waid they were ok with making the Locale::gettext, > Text::WrapI18N and Term::ReadKey dependencies optional. Beautiful. It is actually great that they are receptive to our suggestions, I think it will help them too. > SGMLS is a pure perl module so the best is to just check it in. The > quick and dirty way would be to check it in as po4a/lib/SGMLS.pm. The > cleaner way would be to import the module in the SGMLSpm directory. If it's only a file, maybe the quick and dirty method is simpler. What about suggesting to the po4a folks that _they_ do the import in their tree? > Then we are just left with the nsgmls dependency which is packaged with > each distribution (it's either the sp, opensp, openjade or sgml-tools > package). Yeah, that's cool. Isn't this the same package we need anyway to process our SGML? > The po4a team has been pretty responsive. They have already committed a > lot of my patches (9 of them so far). I need to rework the attribute > translation patch a bit but I hope I can get it in in the first half of > next week. I may also get the patch making Text::WrapI18N and > Term::ReadKey a soft dependency some time next week and once all this is > in I think we'll be ready to do a CVS import. Perfect! World domination is at hand... :) This is great Francois, thanks for doing all the hard work on getting this cleaned up properly. It's important to simplify things, as translation is the type of project where we can expect less technical people to contribute. And we really don't want to scare them off. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

May 29, 2005