wine-devel June 2005

wine-devel@winehq.org

163 participants
316 discussions

Re: [include/winternl.h #7] SYSTEM_PROCESS_INFORMATION
by Alexandre Julliard 06 Jun '05

06 Jun '05

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > I removed the __WINESRC__ bit as it will never be used and it makes the > (coming) tests look better (no private structure needed). > The Windows struct part in SYSTEM_PROCESS_INFORMATION is wrong anyway > (both by size and members). Actually in most cases the non __WINESRC__ case is the one you want to keep, since it comes from the Microsoft headers. You can replace the Reserved things with better names but you should keep at least the fields that have explicit names in the MS headers. If you have to change the layout more than that something is seriously wrong. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Delete version sniffing logic
by Stefan Dösinger 06 Jun '05

06 Jun '05

> The rationale for this change is simple: the version sniffing > code is unreliable and gets it wrong frequently. Out of the box, > you can't run "WINEDLLOVERRIDES=msi,msiexec.exe=n wine InstMsiA.exe" > because of this code. You just get silence. It turns out that even > though this is the Win98 version of the installer, it's detected > as a Windows XP binary. > > It's a lot simpler to have a single, sane default. This makes it > easier for users to understand, easier for us to control, and avoids > the case where different processes in the same program get different > version information. > > This patch defaults us to Win98 mode. Shouldn't we default to WinXP? I know no apps except Win98 specific system files like InstMsiA.exe and dcom98.exe which fail with Winver=winxp. Contrary many apps need winver=winxp(or win2k or nt40) to work, like the setup programs for MS Visual Studio and Microsoft Office 2003. Anyone who has an app which doesn't work with winver=winxp but works with real Windows XP? I think we should at least target Winver=winxp and fix broken apps. Stefan

4 4

Re: Wine on Sparc
by Chuck Hall 06 Jun '05

06 Jun '05

> Chuck Hall wrote: >> Well it looks good. I did get a few failures on the patching, but it >> wnet >> through 'make depend' without a problem. >> >> Now I run into the problem in kthread.c: >> sed -e 's,@bindir\@,/usr/local/bin,g' -e >> 's,@dlldir\@,/usr/local/lib/wine,g' -e 's,@PACKAGE_STRING\@,Wine >> 20050524,g' ./wine.man.in >wine.man || (rm -f wine.man && false) >> gcc -c -I. -I. -I../include -I../include -Wall -pipe >> -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o kthread.o >> kthread.c >> kthread.c:322:3: #error You must implement wine_pthread_init_current_teb >> for your platform >> kthread.c:361:3: #error wine_pthread_get_current_teb not defined for >> this >> architecture >> kthread.c: In function `wine_pthread_get_current_teb': >> kthread.c:340: warning: 'ret' might be used uninitialized in this >> function >> *** Error code 1 >> make: Fatal error: Command failed for target `kthread.o' >> Current working directory /tmp/wine-20050524/loader >> *** Error code 1 >> The following command caused the error: >> cd loader && make >> make: Fatal error: Command failed for target `loader' >> >> Guess this is the next problem to work on :) > > Sounds like configure isn't detecting things properly. It should be > detecting '_lwp_create' and '_lwp_self', thus defining HAVE__LWP_CREATE > and HAVE__LWP_SELF (in addition to HAVE_SYS_LWP_H). Check your > config.log to see what's going on. > > I did have problems with this stuff in older versions of wine, and I > actually hacked the configure scripts to use wine-pthread instead of > wine-kthread. I don't recall the exact reasons, but it wine-kthread > seems to be working fine for me now. Started to go through this and found something intresting. lwp.h does exist and is found, so HAVE_SYS_LWP_H is defined. The test for _lwp_create fails. Looking a bit deeper I found that the lwp.h for Solaris 9 is different from the one in Solaris 10 (which is what I am using). Based on this and something I read awhile ago, I belive that Sun is attempting to phase out the lwp stuff on Solaris. It looks like a workaround will need to be created for _lwp_create. I will look into this and see what is the "official" way to write the code now, if any. Also a workaround will need to be made for all other _lwp_* calls that no longer exist. Have Fun! Chuck Hall

3 3

Re: [OLE #94] Correctly marshal NULL ppUnk refptrs in NdrPointerMarshall
by Robert Shearman 06 Jun '05

06 Jun '05

Mike Hearn wrote: >This corrects an attempt to demarshal garbage during InstallShield10 >startup. For full InstallShield 10 support we need a stdole2.tlb > >Mike Hearn <mh(a)codeweavers.com> >Correctly marshal NULL ppUnk refptrs in NdrPointerMarshall > >Index: dlls/rpcrt4/ndr_marshall.c >=================================================================== >RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v >retrieving revision 1.24 >diff -u -p -d -u -r1.24 ndr_marshall.c >--- dlls/rpcrt4/ndr_marshall.c 1 Jun 2005 11:04:03 -0000 1.24 >+++ dlls/rpcrt4/ndr_marshall.c 5 Jun 2005 22:03:11 -0000 >@@ -575,19 +575,19 @@ void WINAPI PointerMarshall(PMIDL_STUB_M > TRACE("(%p,%p,%p,%p)\n", pStubMsg, Buffer, Pointer, pFormat); > TRACE("type=0x%x, attr=", type); dump_pointer_attr(attr); > pFormat += 2; >+ > if (attr & RPC_FC_P_SIMPLEPOINTER) desc = pFormat; > else desc = pFormat + *(const SHORT*)pFormat; >+ > if (attr & RPC_FC_P_DEREF) { >+ if (!Pointer) >+ RpcRaiseException(RPC_X_NULL_REF_POINTER); > Pointer = *(unsigned char**)Pointer; > TRACE("deref => %p\n", Pointer); > } > > switch (type) { >- case RPC_FC_RP: /* ref pointer (always non-null) */ >-#if 0 /* this causes problems for InstallShield so is disabled - we need more tests */ >- if (!Pointer) >- RpcRaiseException(RPC_X_NULL_REF_POINTER); >-#endif >+ case RPC_FC_RP: /* ref pointer (always non-null but may point to null) */ > break; > case RPC_FC_UP: /* unique pointer */ > case RPC_FC_OP: /* object pointer - same as unique here */ > > > This looks wrong. A ref pointer shouldn't be treated as a unique pointer in any circumstances AFAIK. I'll add this case to my mini test suite to confirm or deny this hypothesis. -- Rob Shearman

2 3

Re: spi.pszProcessName should be UNICODE_STRING
by Paul Vriens 06 Jun '05

06 Jun '05

On Mon, 2005-06-06 at 12:15, Felix Nawothnig wrote: > This lets the taskname appear in WinXP's taskmgr.exe. > > ChangeLog: > Make SYSTEM_THREAD_INFORMATION.pszProcessName an UNICODE_STRING > > ______________________________________________________________________ Thanks for the fix. The change is however done to the SYSTEM_PROCESS_INFORMATION struct :-). The process name now shows nicely in Process Explorer as well. I saw it's committed so I'll build on that one. Paul.

1 0

Re: Temp fix for SetWindowTextA()
by Christoph Frick 06 Jun '05

06 Jun '05

On Sun, Jun 05, 2005 at 02:26:40PM -0400, Jason Campbell wrote: > A possible better patch may be to see if D2 is a child of the D2 bot > (since most bots can load D2) and allow the title change if it is and > not allow it if it's not a parent/child. there are no stupid questions, so i ask: i doubt that windows has there some "if d2 bot, then remove restrictions"... either this software overwrites this data in the process it spawns (many trainers or actually even mods (Grand Prix Legends) work this way. or windows allows changing the title for the spaning process. so the best thing to do is write a test for this, try it in windows and wine and do the correct thing then? -- cu

1 0

Re: [msvcrt] Implement %I types for printf
by Dmitry Timoshkov 06 Jun '05

06 Jun '05

"Jesse Allen" <the3dfxdude(a)gmail.com> wrote: > + if( flags->IntegerLength == 'I' ) > + { > + sprintf(p, "l"); > + p++; > + } > + if( flags->IntegerSize == INTEGERSIZE_LONGLONG ) > + { > + sprintf(p, "l"); > + p++; > + } sprintf is very inefficient here, why not use simple strcpy instead? -- Dmitry.

2 1

Half Life 2 error -- err:mmio:MMIO_ParseExtA
by J. Grant 06 Jun '05

06 Jun '05

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

4 7

Re: shell32: BindToObject should fail, if called with empty pidl
by Uwe Bonnes 06 Jun '05

06 Jun '05

>>>>> "Michael" == Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: Michael> This fixes the problem in DVD Shrink's SHBrowseForFolder Michael> dialog, reported by Wolfgang Scherer. Can you perhaps provide a testcase? I pays off the long term... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

WWN #277 correction.
by Chuck Hall 06 Jun '05

06 Jun '05

In the WWN #277 there is mention that I am using Solaris 9 while attempting to get Wine to work. I am actually using Solaris 10 not Solaris 9. What I did was compare what was different between Solaris 9 and Solaris 10 so I could figure out what the problem is/was. -- Have Fun! Chuck Hall

1 0

← Newer
1
...
24
25
26
27
28
29
30
31
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2005