January 2003 - Wine-Devel - list.winehq.org

Stuck in SetMenuItemInfo

by Mike Hearn

Hi, Debugging a crash in IE in the menus, I traced it to this check in SetMenuItemInfoA, apparently trying to stop apps passing in bad data. if ((lpmii->fType & (MF_HILITE|MF_POPUP)) || (lpmii->fState)) { /* QuickTime does pass invalid data into SetMenuItemInfo. * do some of the checks Windows does. */ WARN("Bad masks for type (0x%08x) or state (0x%08x)\n", lpmii->fType,lpmii->fState ); return FALSE; } In particular, it seems to check for a couple of bits set that aren't by IE, this is the function trace in Windows: SetMenuItemInfoW( 0x000B032B 0 TRUE [0x0013E070] -> 44 , MIIM_ID | MIIM_SUBMENU , MFT_BITMAP | MFT_RIGHTORDER , MFS_CHECKED , 3169 , NULL , 0x003C7FC8 , 0x40000064 , 0x003C806C , NULL , 2012758772 , 0x003B0000 ) -> TRUE So as you can see it sets MFT_BITMAP, MFT_RIGHTORDER and MFT_CHECKED, but not HILITE or POPUP. This is where I got stuck. I can't see what this check should actually be, but it's clearly incomplete at the moment, as Windows doesn't return false with this input. Has anybody got any advice? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 8, 2003

Re: widl patch

by Greg Turner

On Wednesday 08 January 2003 12:31 pm, Ove Kaaven wrote: > Feel free to recompile the .idl files after applying this patch... > it's not necessary, but sooner or later someone is going to try what > I'm currently trying... to compile MIDL-generated proxy/stub code > with Wine headers. Indeed, I am doing this now with my RPC test. I'm not sure we are targeting the same stuff, however. You can see my work-in-progress in the K patchseries, which only has one (rejected) "official" patch: K01. Actually, what I'm really trying to do is mix and match. I want the .h header to be generated by widl, and the _s.c and _c.c stubs to be generated by MIDL. wire_marshall should be a barrel of laughs ;) Maybe after I get this batch working I'll whip up some tests for 'ya that use it. I encounter the following gaps: o widl doesn't generate forward declarations for MIDL_user_allocate and MIDL_user_free, should be trivial to fix. o widl doesn't parse the implicit_handle stuff in the .acf, which cause MIDL to put an extern declaration in for the handle. o RpcTry/Except/etc. Ugh, what a $&^@$*% train wreck. More-or-less unfixable, and not widl's fault anyhow. ATM I may hack around this using some evil, incorrect, and, frankly, downright offensive macros. Long term, of course, I'm interested in seeing exception handling souce-compatibility in wine... perhaps, winegcc, or some cousin, could parse VC++ __try & family and generate wine-compatible __TRY & family to match? Given the freedom to parse/generate, regardless of the implementation specifics, it becomes a surmountable problem IMO. Otherwise, it works perfectly. Good work! Any chance either of the first two points will be fixed soon? This would leave me with only one inelegant hack (two if calling MIDL counts), and an otherwise tolerable build process. Thanks, -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 8, 2003

Re: Registering DLL's

by Steven Edwards

> > > http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html) but I haven't > > > gotten any responses, not even "looks fine" or "you are a moron". I guess I'll > > > just start submitting patches, then. As long as they will self-register on Windows/ReactOS then it "looks fine" to me. =) If not I still cant write it so I wont say "you are a moron". Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Steven Edwards

> Yeah. From what I remember, Bochs uses only software emulation, which > means it's very slow but very portable. Ideally there would be a > libbochs that lets you pass in a block of code of any given architecture > and have it translated into any other architecture. If there was such a > library (not sure if there is) it could be integrated with the Wine PE > loader code. Possibly. Such a thing did exist in TWIN I think as libintp32.a If I remeber correctly they adapted dosemu's X86 emulation and used it as a base for the dos/win3.1 support on other non-x86 arches Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 8, 2003

dsound test fails

by Zsolt Rizsanyi

Hi! I tried doing make test, and got the next errors for the dsound test: make[2]: Entering directory `/home/zsolt/src/wine/dlls/dsound' make[3]: Entering directory `/home/zsolt/src/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4025e290,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4025e290,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4025e290,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4025e290,00010020,1):stub err:ntdll:RtlpWaitForCriticalSection section 0x400d9d44 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=081b0f88 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400d9d44 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=081b0f88 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400ab624 make[3]: Leaving directory `/home/zsolt/src/wine/dlls/dsound/tests' make[2]: Leaving directory `/home/zsolt/src/wine/dlls/dsound' What does that mean? I got similar errors when trying to run some games. I have a Creative SB Live card. Using alsa 0.9.0rc1 with oss emulation (using wineoss and not winealsa - tough I have tried with winealsa and nothing changes). I know that the problem is with my system, but dont know where. Thanks Zsolt

Jan. 8, 2003

Re: DirectSound and i810 soundcards

by Glen Kaukola

Francois Gouget wrote: > So even with WAVE_FORMAT_DIRECT the sound plays fine. Interesting. Do > you have Linux installed on this machine? What's the output if you run > the test as follows? > > WINEOPTIONS="--debugmsg +wave" ../../../tools/runtest -P wine -M > winmm.dll -T ../../.. -p winmm_test.exe.so wave.c 2>&1 | grep "OSS dsp > out mask" Here's what I get: trace:wave:OSS_WaveOutInit OSS dsp out mask=00000010

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Mike Hearn

> Old PC? All my old PCs have X86 processors and they're running Linux. > Are you saying there are sources of extremely cheap PPC motherboards to > stick in a PC chasis? Sorry, a thinko :) I meant an old PPC machine.... > Bochs has full support for Mac OS X including a .dmg binary on their > download page, so the port for that package is done already by the Bochs > team. The tricky bit will be going from Bochs virtual machine approach > to an in-process extension sort of deal. Yeah. From what I remember, Bochs uses only software emulation, which means it's very slow but very portable. Ideally there would be a libbochs that lets you pass in a block of code of any given architecture and have it translated into any other architecture. If there was such a library (not sure if there is) it could be integrated with the Wine PE loader code. Possibly. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 8, 2003

Re: Symbol stripping=?iso-8859-1?Q?=3F ?=

by Mike Hearn

I can look into doing this, but is there a reason we can't use -gstabs+ for all compilers? Will some compilers barf with this flag? I can see the benefits of doing it this way, but configure already takes ages :) On Wed, 2003-01-08 at 10:04, Eric POUECH wrote: > IMO the test should be: > - compile a little test program > - test if it contains stabs info (this adds a dependency on binutils, but since the test is meant to compile wine it shouldn't be too much an issue) > - if it doesn't, and if compiler is gcc then rerun the test with the -gstabs+ flag > - it the test passes add the flag to CFLAG, otherwise warn the user (at the end of configuration) as we do for opengl > however, this would be better in wine.ac (or equivalent) so that we can make use of it for other winelib programs for instance > > A+ > >Messsage du 08/01/2003 08:59 > >De : Mike Hearn <m.hearn(a)signal.qinetiq.com> > >A : Shachar Shemesh <wine-devel(a)sun.consumer.org.il> > >Copie à : Eric Pouech <eric.pouech(a)wanadoo.fr>, Mike Hearn <m.hearn(a)signal.dera.gov.uk>, <wine-devel(a)winehq.org> > >Objet : Re: Symbol stripping? > > > > What does gcc prior to 3.1 do with the -gstabs+ flag? If it ignores it, > > or it's implied anyway, we could just have it always on. > > > > If not then I have some bash here that can parse the output of gcc -v > > and determine whether it's >= 3.1, would that be acceptable as a patch > > to configure.ac? > > > > The only other way would be to compile a little test app then run > > objdump on it to figure out if stabs data was included, but testing the > > GCC version would be faster. > > > > On Tue, 2003-01-07 at 09:19, Shachar Shemesh wrote: > > > Eric Pouech wrote: > > > > > > > aren't you, by any chance, compiling with gcc >= 3.1 ? > > > > if so, you need to force emission of stabs as a debugging format while > > > > running configure > > > > something like this should work > > > > CFLAGS=-gstabs+ ./configure > > > > > > Maybe we should patch configure.ac to detect this and add the apropriate > > > compile switch? > > > > > > > > > > > A+ > > > > > > > > -- > > Mike Hearn <m.hearn(a)signal.qinetiq.com> > > QinetiQ - Malvern Technology Center > > > > > > > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 8, 2003

Re: Symbol stripping=?iso-8859-1?Q?=3F ?=

by Eric POUECH

IMO the test should be: - compile a little test program - test if it contains stabs info (this adds a dependency on binutils, but since the test is meant to compile wine it shouldn't be too much an issue) - if it doesn't, and if compiler is gcc then rerun the test with the -gstabs+ flag - it the test passes add the flag to CFLAG, otherwise warn the user (at the end of configuration) as we do for opengl however, this would be better in wine.ac (or equivalent) so that we can make use of it for other winelib programs for instance A+ >Messsage du 08/01/2003 08:59 >De : Mike Hearn <m.hearn(a)signal.qinetiq.com> >A : Shachar Shemesh <wine-devel(a)sun.consumer.org.il> >Copie à : Eric Pouech <eric.pouech(a)wanadoo.fr>, Mike Hearn <m.hearn(a)signal.dera.gov.uk>, <wine-devel(a)winehq.org> >Objet : Re: Symbol stripping? > > What does gcc prior to 3.1 do with the -gstabs+ flag? If it ignores it, > or it's implied anyway, we could just have it always on. > > If not then I have some bash here that can parse the output of gcc -v > and determine whether it's >= 3.1, would that be acceptable as a patch > to configure.ac? > > The only other way would be to compile a little test app then run > objdump on it to figure out if stabs data was included, but testing the > GCC version would be faster. > > On Tue, 2003-01-07 at 09:19, Shachar Shemesh wrote: > > Eric Pouech wrote: > > > > > aren't you, by any chance, compiling with gcc >= 3.1 ? > > > if so, you need to force emission of stabs as a debugging format while > > > running configure > > > something like this should work > > > CFLAGS=-gstabs+ ./configure > > > > Maybe we should patch configure.ac to detect this and add the apropriate > > compile switch? > > > > > > > > A+ > > > > > -- > Mike Hearn <m.hearn(a)signal.qinetiq.com> > QinetiQ - Malvern Technology Center > > >

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Jim White

Mike Hearn wrote: > I'm suggesting you use it as a place to start the port. If you decide > to make things hard for yourself due to some bizarre hatred of desktop > Linux, then you're just increasing the amount of work you'd need to do. > > You don't even have to dual boot or anything, just stick it on an old PC > and ssh into it if you absolutely must have glowing buttons. Old PC? All my old PCs have X86 processors and they're running Linux. Are you saying there are sources of extremely cheap PPC motherboards to stick in a PC chasis? > (I don't think anybody has attempted Bochs integration before), it makes > sense to get it out the way. But - if you want to leave it until later, > you do it how you think is best. Bochs has full support for Mac OS X including a .dmg binary on their download page, so the port for that package is done already by the Bochs team. The tricky bit will be going from Bochs virtual machine approach to an in-process extension sort of deal. Mac OS X has had lots of attention from folks doing source level porting, notably the Fink group which has a Debian-based apt-get for a large number of the most used package. Even OpenOffice can launch and do a few things. But as I've said, I'm not really keen on making large changes in two directions at once. Hopefully some more folks with ideas and skills will get interested in Wine for Mac OS X. I think I will investigate the Linux compatible angle for a bit. I've already had some interest from some hard core Linux kernel hackers (although they seem pretty convinced Mach was the wrong solution, it is here to stay and at least the microkernel approach means we can neatly have multiple environments). Jim

Jan. 8, 2003