- wine-devel - winehq.org

Registry problem
by steve.lustbader＠philips.com 09 Oct '02

09 Oct '02

I started having a problem with today's source that appears to be either registry or sound related. When I tried to install Winamp (v 2.81 lite) in wine, I get this error: wine client error:8091280: sendmsg: Bad file descriptor Output from +reg,+relay ends with 08091280:Call ntdll.NtQueryValueKey(00000048,40124878,00000002,406e2acc,00000100,406e2ac0) ret=40977acc trace:reg:NtQueryValueKey (0x48,L"WaveMapper",2,0x406e2acc,256) wine client error:8091280: sendmsg: Bad file descriptor (the last 100 lines of the output can be seen at http://www.lustbader.net/winamp.txt) I tried getting rid of my ~/fake_c and ~/.wine directories and running wineinstall again, but that didn't help. -Steve

4 4

Re: Re: jack audio driver
by chrismorgan＠rcn.com 08 Oct '02

08 Oct '02

> > From: Eric Pouech <eric.pouech(a)wanadoo.fr> > Date: 2002/10/08 Tue PM 03:48:04 EDT > To: Chris Morgan <cmorgan(a)alum.wpi.edu> > CC: wine-devel(a)winehq.com > Subject: Re: jack audio driver > > Chris Morgan a écrit : > > > > I have an audio driver for the jack audio server, > > http://jackit.sourceforge.net. This is a callback based server, so each time > > the server needs audio data it executes a client callback function. I was > > wondering if there was any interest in having this driver as part of mainline > > wine code as an example of how to write a wine audio driver for a callback > > based architecture. > well, it depends what you look at > jack way well be the standardized API for audio application > interoperability on Linux > but, some folks may argue that arts may well become the same > as of today, I don't like the number of sound drivers that we already > have (OSS, alsa, arts, nas) just for linux > it, of course, reflects the mess in low level audio interface in linux It really is a mess. It seems clear that we should do away for the most part with having applications interface directly with sound drivers like oss/alsa, and instead go through sound servers like arts/jack/etc. In technical aspects a callback based architecture is far superior to a polling based architecture. It has a lower latency and enforces a cleaner sound implementation on applications. What I haven't seen yet is a widely used audio server that people agree upon. Someone really needs to take the lead and start pushing a callback based sound server that is under active development(arts appears not to be) that is not kde/gnome specific.</rant> > what I really fear is the real maintenance of those drivers > as of today, OSS is maintained, I cannot really tell the same for the > others > it's never a bad idea to share code, but I fear we're not going to be > able to maintain all the drivers (but we don't maintain them all today > anyway) > so go for it > (sorry for thinking while writing ;-) Wonder when we can phase out the OSS driver and concentrate on the ALSA one. Seems like a waste to support two drivers that fulfill the same role. Chris

2 1

jack audio driver
by Chris Morgan 08 Oct '02

08 Oct '02

I have an audio driver for the jack audio server, http://jackit.sourceforge.net. This is a callback based server, so each time the server needs audio data it executes a client callback function. I was wondering if there was any interest in having this driver as part of mainline wine code as an example of how to write a wine audio driver for a callback based architecture. Chris

2 1

sound problem
by Rein Klazes 08 Oct '02

08 Oct '02

Hi, Last nights cvs commits gives a problem with sound in Agent. It is the ping played when new mail is received. The first time goes alright, the second time it kills agent: | trace:wave:OSS_wodMessage (0, 0005, 42E12C74, 42E12CA4, 00030008); | trace:wave:wodOpen (0, 0x42e12ca4, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp (Device or resource busy) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! | trace:wave:OSS_wodMessage (1, 0005, 42E12C74, 42E12CA4, 00030008); | trace:wave:wodOpen (1, 0x42e12ca4, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp1 (No such device) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! | trace:wave:OSS_wodMessage (2, 0005, 42E12C74, 42E12CA4, 00030008); | trace:wave:wodOpen (2, 0x42e12ca4, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp2 (No such device) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! | wine client error:806fe00: sendmsg: Bad file descriptor And the wine returns to the prompt in the xterm from which it is started. Some other thread continues: | trace:wave:OSS_wodMessage (0, 0005, 42E12C48, 42E12C78, 00030008); | trace:wave:wodOpen (0, 0x42e12c78, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp (Device or resource busy) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! [these 4 messages repated 11 times] | trace:wave:OSS_wodMessage (1, 0005, 42E12C48, 42E12C78, 00030008); | trace:wave:wodOpen (1, 0x42e12c78, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp1 (No such device) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! [those too] | trace:wave:OSS_wodMessage (2, 0005, 42E12C48, 42E12C78, 00030008); | trace:wave:wodOpen (2, 0x42e12c78, 00030008); | warn:wave:OSS_RawOpenDevice Couldn't open out /dev/dsp2 (No such device) | err:wave:wodOpen ioctl can't 'SNDCTL_DSP_GETOSPACE' ! [and those] | err:ntdll:RtlpWaitForCriticalSection section 0x40875b7c "../../windows/user.c: USER_SysLevel" wait timed out, retrying (60 sec) tid=08fc03c0 this happens sometimes. If so it is followed by an attempt to start the debugger. Any suggestions? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

automagical .sym symbol loading in winedbg?
by Greg Turner 08 Oct '02

08 Oct '02

Is there any way to get winedbg to automagically load .sym files from some particular directory? winedbg> "symbolfile [full unix path of .sym file]/[filename.sym]" it seems to work; but what a hassle! All that crap is in "/var/src/nosrc/DOTwine/fake_windows/windows/Symbols," quite a lot to type over and over (yes, I have cut-and-paste capabilities... but it still sucks). I see it looking for ".dbg" files but not ".sym". I'm experimenting with the Windows 98/98SE DDK symbol files, installed into my fake_windows. I also noticed _NT_SYMBOL_PATH references floating around in there, but that's for ".pdb" files, and unlikely to help, right? Anyways, I tried it, it doesn't help. :( -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 1

Re: Re: Environment passing
by chrismorgan＠rcn.com 08 Oct '02

08 Oct '02

A very similar approach to what I was working on and it looks like the right thing to do. I haven't had time to test it yes but if you have it should be ok to go in. I'll mail another patch or two to fix other issues relating to environment passing soon. Thanks, Chris > > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 2002/10/08 Tue PM 12:24:28 EDT > To: Chris Morgan <cmorgan(a)alum.wpi.edu> > CC: <wine-devel(a)winehq.com> > Subject: Re: Environment passing > > Chris Morgan <cmorgan(a)alum.wpi.edu> writes: > > > I've been looking into exactly what is broken with environment passing in > > CreateProcess() and the functions it uses. What appears to be breaking > > things at this point is just what Eric mentioned, that we mess with the PATH > > environment variable inside of fork_and_exec() and then we call out to > > execve() with this modified environment. It appears that we really do need > > to mess with the PATH environment variable to ensure that execve() finds > > things in the correct unix path locations. I was thinking that before we > > execve() that we could copy the current PATH into a variable called __PATH. > > We would then restore PATH in PROCESS_InitWine() from this __PATH. > > Yes, I wrote a patch some time ago to do this, here it is. I think it > should still work but I haven't tested it. Let me know if it works for > you and I'll put it in. > > Index: files/directory.c > =================================================================== > RCS file: /opt/cvs-commit/wine/files/directory.c,v > retrieving revision 1.54 > diff -u -r1.54 directory.c > --- files/directory.c 13 Sep 2002 18:52:01 -0000 1.54 > +++ files/directory.c 8 Oct 2002 15:09:58 -0000 > @@ -160,17 +160,21 @@ > DRIVE_Chdir( drive, DIR_Windows.short_name + 2 ); > } > > - PROFILE_GetWineIniString(wineW, pathW, path_dirW, longpath, MAX_PATHNAME_LEN); > - if (strchrW(longpath, '/')) > + /* Set the environment variables */ > + > + /* set PATH only if not set already */ > + if (!GetEnvironmentVariableW( path_capsW, longpath, MAX_PATHNAME_LEN )) > { > - MESSAGE("Fix your wine config to use DOS drive syntax in [wine] 'Path=' statement! (no '/' allowed)\n"); > - PROFILE_UsageWineIni(); > - ExitProcess(1); > + PROFILE_GetWineIniString(wineW, pathW, path_dirW, longpath, MAX_PATHNAME_LEN); > + if (strchrW(longpath, '/')) > + { > + MESSAGE("Fix your wine config to use DOS drive syntax in [wine] 'Path=' statement! (no '/' allowed)\n"); > + PROFILE_UsageWineIni(); > + ExitProcess(1); > + } > + SetEnvironmentVariableW( path_capsW, longpath ); > } > > - /* Set the environment variables */ > - > - SetEnvironmentVariableW( path_capsW, longpath ); > SetEnvironmentVariableW( temp_capsW, tmp_dir.short_name ); > SetEnvironmentVariableW( tmp_capsW, tmp_dir.short_name ); > SetEnvironmentVariableW( windirW, DIR_Windows.short_name ); > Index: memory/environ.c > =================================================================== > RCS file: /opt/cvs-commit/wine/memory/environ.c,v > retrieving revision 1.37 > diff -u -r1.37 environ.c > --- memory/environ.c 24 Sep 2002 18:29:40 -0000 1.37 > +++ memory/environ.c 8 Oct 2002 15:10:07 -0000 > @@ -152,7 +152,11 @@ > /* Compute the total size of the Unix environment */ > > size = sizeof(BYTE) + sizeof(WORD) + sizeof(ENV_program_name); > - for (e = environ; *e; e++) size += strlen(*e) + 1; > + for (e = environ; *e; e++) > + { > + if (!memcmp( *e, "PATH=", 5 )) continue; > + size += strlen(*e) + 1; > + } > > /* Now allocate the environment */ > > @@ -164,7 +168,10 @@ > > for (e = environ; *e; e++) > { > - strcpy( p, *e ); > + /* skip Unix PATH and store WINEPATH as PATH */ > + if (!memcmp( *e, "PATH=", 5 )) continue; > + if (!memcmp( *e, "WINEPATH=", 9 )) strcpy( p, *e + 4 ); > + else strcpy( p, *e ); > p += strlen(p) + 1; > } > > Index: scheduler/process.c > =================================================================== > RCS file: /opt/cvs-commit/wine/scheduler/process.c,v > retrieving revision 1.200 > diff -u -r1.200 process.c > --- scheduler/process.c 3 Oct 2002 19:54:57 -0000 1.200 > +++ scheduler/process.c 8 Oct 2002 15:10:10 -0000 > @@ -820,9 +820,16 @@ > /* now put the Windows environment strings */ > for (p = env; *p; p += strlen(p) + 1) > { > - if (memcmp( p, "PATH=", 5 ) && > - memcmp( p, "HOME=", 5 ) && > - memcmp( p, "WINEPREFIX=", 11 )) *envptr++ = (char *)p; > + if (!memcmp( p, "PATH=", 5 )) /* store PATH as WINEPATH */ > + { > + char *winepath = malloc( strlen(p) + 5 ); > + strcpy( winepath, "WINE" ); > + strcpy( winepath + 4, p ); > + *envptr++ = winepath; > + } > + else if (memcmp( p, "HOME=", 5 ) && > + memcmp( p, "WINEPATH=", 9 ) && > + memcmp( p, "WINEPREFIX=", 11 )) *envptr++ = (char *)p; > } > *envptr = 0; > } > > -- > Alexandre Julliard > julliard(a)winehq.com > > >

1 0

Re: Re: another MZ_Exec() problem...
by chrismorgan＠rcn.com 08 Oct '02

08 Oct '02

Anyone planning on looking into this in the near term? It could be fixed relatively easily in MZ_Exec() if I knew of some way to get the environment variables and their values. I'm not sure if the same kind of fix would apply to fixing CreateProcess(). Chris > > From: "Eric POUECH" <Eric.Pouech(a)wanadoo.fr> > Date: 2002/09/24 Tue PM 04:48:24 EDT > To: <cmorgan(a)alum.wpi.edu>, <wine-devel(a)winehq.com> > Subject: Re: another MZ_Exec() problem... > > > Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. > moreover, explicit env heritage (ie passed in CreateProcess) is currently bugged > A+ > > >

3 2

W(w)indows messages
by Fabian Cenedese 08 Oct '02

08 Oct '02

Hi all I still try to solve the problems I have in window handling. There is a function X11_ShowWindow. First comes a big switch/case of all show commands. Then is the call to SetWindowPos with the new coords. But this newPos is only filled in few cases. So most of the times I end up with a SetWindowPos with coords 0. But still it somehow seems to work so I continued my search. In SetWindowPos is a call to WIN_SetRectangles with newWindowRect and newClientRect as parameters. But in the end is a message generated WM_WINDOWPOSCHANGED where the old winpos with the 0s inside is given as argument. Shouldn't that be also one of the new rects resp. shouldn't these new coords be set in newpos? I tried it but wine broke off with a stack overflow as I somehow generated a recursive calling. I have a call to ShowWindow in my OnWindowPosChanged handler. This works fine in Windows but wine seems to generate a new message WindowPosChanged what Windows doesn't. The use of ShowWindow in OnWindowPosChanged is maybe questionable but nonetheless it shows that there is something different in wine. Deleting this call to ShowWindow makes it run ok. But I noticed also previously that wine seems to generate more messages than Windows does. The main reason why I started this exploration is that some of my docked windows didn't show up. Then I found that I always get coords of 0 in my OnWindowPosChanged. So we come back to the above mentioned newPos. I'm quite new to wine and especially this window handling stuff, but this seems to be the biggest problem to make my app work with wine so I'd really appreciate some hints. If someone knows a book about Windows Messages I'm game. Thanks for reading :) bye Fabi

1 0

Re: updated LT keyboard
by Nerijus Baliunas 08 Oct '02

08 Oct '02

On Sat, 7 Sep 2002 18:36:00 +0200 (EET) Nerijus Baliunas <nerijus(a)users.sourceforge.net> wrote: > It is still not detected, but at least wine chooses it as closest match now, > so it is an improvement. Rewind also can include it. Hello, why this patch is still not applied? Regards, Nerijus

1 0

Languages/Locales
by steve.lustbader＠philips.com 08 Oct '02

08 Oct '02

ChangeLog (memory/codepage.c): Implement GetUserDefaultUILanguage Implement GetSystemDefaultUILanguage I implemented these functions in codepage.c since similar functions (GetDefaultLangID and GetDefaultLCID) were already there. Why are these functions in this file, instead of in dlls/kernel/locale.c? It seems locales and languages aren't really implemented yet (just hardcoded to English) - is this going in for 1.0 or is it not planned for the immediate future? -Steve (See attached file: patch.diff)

4 3

Re: Listview L10
by Paul Rupe 08 Oct '02

08 Oct '02

On 07 Oct 2002, dpaun(a)rogers.com wrote: > This one fixes a lot of nasty bugs. It also fixes Xnews, > among other things. Yeah, it works great now. Cool. :) > This one should bring the listview to a decent state. > I am interested to hear about outstanding problems. One thing I noticed is that File Open/Save As dialogs in any app now show only icons (the filenames are all blank). I think this must have happened somewhere in the L-series of patches, but I haven't delved in to figure out which one yet. -- Paul Rupe "She smiled, in the end." p r u p e @ m y r e a l b o x . c o m | Oppose government police-ware on your PC! | Stop the Consumer Broadband and Digital Television Promotion Act! | <http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html>

3 2

Re: wine/dlls/rpcrt4 Makefile.in rpcrt4.spec rpcrt ...
by Greg Turner 07 Oct '02

07 Oct '02

On Monday 07 October 2002 04:49 pm, Alexandre Julliard wrote: > ChangeSet ID: 5665 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/10/07 16:49:49 > > Modified files: > dlls/rpcrt4 : Makefile.in rpcrt4.spec rpcrt4_main.c > Added files: > dlls/rpcrt4 : rpc_binding.c rpc_binding.h > > Log message: > Ove Kaaven <ovek(a)transgaming.com> > Implemented RpcBindingInqObject, RpcBindingSetObject, > RpcBindingVectorFree, RpcBindingToStringBindingA/W, > RpcBindingFromStringBindingA/W, RpcStringBindingParseA/W, > I_RpcBindingSetAsync, RpcStringBindingComposeA/W, RpcBindingFree, > RPCStringFreeW, UUIDHash, UuidToStringW, and associated junk. > > Patch: http://cvs.winehq.com/patch.py?id=5665 > > Old revision New revision Changes Path > 1.8 1.9 +1 -0 wine/dlls/rpcrt4/Makefile.in > 1.19 1.20 +11 -10 wine/dlls/rpcrt4/rpcrt4.spec > 1.29 1.30 +78 -73 wine/dlls/rpcrt4/rpcrt4_main.c > Added 1.1 +0 -0 wine/dlls/rpcrt4/rpc_binding.c > Added 1.1 +0 -0 wine/dlls/rpcrt4/rpc_binding.h Interesting that you unrolled the #define macros in rpc_binding.c. I guess the argument against this is that it creates code duplication. The argument for it is more obvious (reduces insanity). In general, should I avoid submitting patches with big nasty #define's that are really inline functions like this, even at the expense of duplicating some code? Personally, I kind of dislike this sort of thing (big nasty #define's); but I notice that, to an extent, they abound in wine, and I must say that I dislike code duplication almost as much. STL is a good compromise, for C++; but obviously that doesn't help us here in C land (or does it? anyhow, STL is probably not a desirable dependency for wine IMHO). M4 is already a dependency but would be a pretty big break from the current way of doing things... if we're to drag in M4 then we'd might as well rework all of wine to use it in place of the big nasty #defines.... sounds like a miserable and tedious process, and when it's all done, nobody can understand the code (including me, and M4 ignoramus). Ugh. !%&!%& script-soup. When did coding become so much like web-page design? I blame Richard Stallman ;) Rule of thumb: Any program with backquoted backquotes is misdesigned! :) Anyhow, now that I've gotten my bitching and moaning out of the way... let me know if you'd like me to break up #defines like this in future patches and I'll do it. As for the stuff that's already checked in, I'm gonna look at the possibility of dropping some of it into RPCRT4_ functions (/real/ functions) to reduce the duplication. -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 1

Re: d3d8 patch
by Christian Costa 07 Oct '02

07 Oct '02

Ann and Jason Edmeades wrote: >Changelog: > >o Various fixes, typos corrected and clarifying trace points > >Note I am quickly reaching the end of my ability in this area - This brings >the wine tree up to date with all my changes, so some help from anyone would >be appreciated. There are some 'simple' tutorials type dx8 pgms I just cant >get working and I cant see why - email me if you can help > >Additionally, my understanding is in Windows a HAL lives under direct3d and >earlier directdraw functionality - Does anyone know where the interface is >actually documented? I have had it mentioned to me it would be better to try >to make the functionality more common with direct draw and want to see how >this is done under windows. > >Jason > Jason, The Windows HAL is documented in the DDK (Driver Development Kit). It's a package of 60MBytes or so . You can find it at : http://www.microsoft.com/ddk/ If think (but I'm not sure) the actual HAL is the Win98's one. So you should try the Win98 DDK. It's the one I use. Christian

1 0

Re: Languages/Locales
by steve.lustbader＠philips.com 07 Oct '02

07 Oct '02

Should I resubmit this patch with the my functions moved to locale.c or ole2nls.c? Which one? Alexandre Julliard To: Steve Lustbader/ANR/MS/PHILIPS@AMEC <julliard@winehq cc: wine-devel(a)winehq.com .com> Subject: Re: Languages/Locales Sent by: wine-devel-admin Classification: @winehq.com 10/07/2002 02:02 PM steve.lustbader(a)philips.com writes: > I implemented these functions in codepage.c since similar functions > (GetDefaultLangID and GetDefaultLCID) were already there. Why are > these functions in this file, instead of in dlls/kernel/locale.c? Because they are needed by ntdll. This will be fixed eventually. > It seems locales and languages aren't really implemented yet > (just hardcoded to English) - is this going in for 1.0 or is it not planned > for the immediate future? Most of it is already implemented; the relevant stuff is in dlls/kernel/locale.c and ole/ole2nls.c. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Listview L2
by Paul Rupe 07 Oct '02

07 Oct '02

On 06 Oct 2002, dpaun(a)rogers.com wrote: > Another rounds of cleanups > > ChangeLog > -- Cleanup of the way we maintain/lookup the item count > -- Rename GetItemWidth to CalculateMaxWidth > -- Misc trivial changes. It looks like this one breaks Xnews again. With CVS+L0+L1+L2+my patch, the listviews all display as blank. A later patch adds a missing line "infoPtr->nItemCount = nItems;" in LISTVIEW_SetItemCount. This fixes the display problem, but I am still unable to open any newsgroups. Highlighting one and hitting Enter gives me an error from the app "List index (-1) out of bounds," suggesting that it doesn't know that anything is focused/selected. L0 and L1 appear to be fine, but L2-L8 all have this behavior. -- Paul Rupe "She smiled, in the end." p r u p e @ m y r e a l b o x . c o m | Oppose government police-ware on your PC! | Stop the Consumer Broadband and Digital Television Promotion Act! | <http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html>

2 1

is it winetest or me?
by György 'Nog' Jeney 07 Oct '02

07 Oct '02

While cominuing on my msvcrt test, I ran accross the following anomily(mabe?). If I have ok(0 == 0, NULL) in my test, then everything works fine, but if I get ok(1 == 0, NULL) then the whole thing crashes with an exection to a write error. Anyone have any ides? nog.

2 1

is winemaker working?
by Michael Cardenas 07 Oct '02

07 Oct '02

Hello all. I'm trying to compile a number of winelib programs that are part of the lindows-wine package. To do so, I removed all the makefiles and make.rules files and configure files, and ran winemaker --cuiexe . from the directories containing the source for runonce, geticon, and initcache. The resulting makefiles did compile, after changing the install target to strip the .exe off of the names, but the applications do not run. They look for <appname>.exe in C:\windows\system, but even if I put the apps in that dir with that name, they still don't run and complain tht they can't find <appname>.exe So, is anyone using winemaker? Has anyone used it to make a simple winelib app recently? Does it still work? There seem to have been a lot of changes to the spec file format recently, which have probably rendered it unusable. thanks michael -- michael cardenas | lead software engineer lindows.com hyperpoem.net | GNU/Linux software developer debian.org "What the poet is looking for is not the fundamental I but the deep you." - Antonio Machado

3 2

Re: DOS DPMI32, interrupt handlers in 32-bit code
by Sylvain Petreolle 07 Oct '02

07 Oct '02

Hi Jukka, I tried your patch on the latest CVS. This doesn't compile at the moment, complaining about FARPROC48 : gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o ../../memory/instr.o ../../memory/instr.c../../memory/instr.c: In function `INSTR_EmulateInstruction': ../../memory/instr.c:689: `FARPROC48' undeclared (first use in this function) ../../memory/instr.c:689: (Each undeclared identifier is reported only once ../../memory/instr.c:689: for each function it appears in.) ../../memory/instr.c:689: parse error before "addr" ../../memory/instr.c:697: `addr' undeclared (first use in this function) make[2]: *** [../../memory/instr.o] Erreur 1 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

Re: How to add a new test dir? (Update)
by Greg Turner 07 Oct '02

07 Oct '02

On Sunday 06 October 2002 06:25 pm, Greg Turner wrote: > I'm trying to create a tests directory for rpcrt4. So far I've > done the following: > > o Create a dlls/rpcrt4/tests directory > > o Change dlls/rpcrt4/Makefile.in: > > o add dlls/rpcrt4/tests/Makefile.in: > > o add dlls/rpcrt4/tests/rpc.c: > > but I get no love. configure seems to go OK; > When I run make depend it fails: > > <============== > make[2]: Entering directory `/var/src/wine/dlls/rpcrt4' > cd `dirname tests/__depend__` && make depend > make[3]: Entering directory `/var/src/wine/dlls/rpcrt4/tests' > make[3]: *** No rule to make target `depend'. Stop. > make[3]: Leaving directory `/var/src/wine/dlls/rpcrt4/tests' > make[2]: *** [tests/__depend__] Error 2 > make[2]: Leaving directory `/var/src/wine/dlls/rpcrt4' > make[1]: *** [rpcrt4/__depend__] Error 2 > make[1]: Leaving directory `/var/src/wine/dlls' > make: *** [dlls/__depend__] Error 2 > ==============> > > What am I missing? Is this documented somewhere? > Thanks, I found it: Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.81 diff -u -r1.81 configure.ac --- configure.ac 2 Oct 2002 19:58:27 -0000 1.81 +++ configure.ac 7 Oct 2002 03:09:02 -0000 @@ -1435,6 +1435,7 @@ dlls/rasapi32/Makefile dlls/richedit/Makefile dlls/rpcrt4/Makefile +dlls/rpcrt4/tests/Makefile dlls/serialui/Makefile dlls/setupapi/Makefile dlls/shdocvw/Makefile Now I'm sure it'll get even more confusing ;) -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

1 0

pain and agony... a +relay,+seh trace from my cxxexcept problem case:
by Greg Turner 06 Oct '02

06 Oct '02

OK, here is what looks to me like the relevant stuff... I'm determined to get this fixed, I "need" this app (ya right... I've got vmware...) =================> 0807bf40:Ret ws2_32.recv() retval=00000010 ret=410d966a 0807bf40:Call ws2_32.recv(00000174,42a908b0,0000004d,00000000) ret=410d966a 0807bf40:Call ntdll.wine_server_handle_to_fd(00000174,80000000,406f1cec,406f1d54,406f1d64) ret=411976f5 0807bf40:Ret ntdll.wine_server_handle_to_fd() retval=00000000 ret=411976f5 0807bf40:Call kernel32.GetProcessHeap() ret=4119693e 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=4119693e 0807bf40:Call ntdll.RtlAllocateHeap(403d0000,00000000,00000008) ret=4119695a 0807bf40:Ret ntdll.RtlAllocateHeap() retval=404d1be8 ret=4119695a 0807bf40:Call kernel32.GetProcessHeap() ret=41196c0c 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=41196c0c 0807bf40:Call ntdll.RtlFreeHeap(403d0000,00000000,404d1be8) ret=41196c25 0807bf40:Ret ntdll.RtlFreeHeap() retval=00000001 ret=41196c25 0807bf40:Ret ws2_32.recv() retval=0000004d ret=410d966a 0807bf40:Call msvcrt.malloc(00000008) ret=5f40384f 0807bf40:Call kernel32.GetProcessHeap() ret=40f216bf 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=40f216bf 0807bf40:Call ntdll.RtlAllocateHeap(403d0000,00000000,00000008) ret=40f216d6 0807bf40:Ret ntdll.RtlAllocateHeap() retval=404d1be8 ret=40f216d6 0807bf40:Ret msvcrt.malloc() retval=404d1be8 ret=5f40384f <================ so far, so good, right? Looks like pretty normal stuff going on here; the exception is raised by proprietary code within starteam, but they like to catch their own exceptions, I think it's supposed to pass and be handled. In the debugger, the stack looks great, goes back cleanly all the way to init. =================> 0807bf40:Call msvcrt._CxxThrowException(406f1f4c,410dff80) ret=410d4d0a 0807bf40:Call kernel32.RaiseException(e06d7363,00000001,00000003,406f1e24) ret=40f15b9e trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f1f4c trace:seh:EXC_RtlRaiseException info[2]=410dff80 trace:seh:EXC_CallHandler calling handler at 0x410de5e6 code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f1cc4,406f1f68,406f1960,406f1940) ret=4010c420 fs=008f eax=410dff20 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1f70 edi=406f195c ebp=406f18a4 esp=406f1860 ds=002b es=002b gs=0000 flags=00000212 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1f70 edi=406f195c ebp=406f18a4 esp=406f1860 ds=002b es=002b gs=0000 flags=00000212 trace:seh:EXC_CallHandler handler returned 1 <=============== OK, one handler called, ExceptionContinueSearch. now here comes something more significant.... =============> trace:seh:EXC_CallHandler calling handler at 0x410de4b4 code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f1cc4,406f1fc8,406f1960,406f1940) ret=4010c420 fs=008f eax=410dfc20 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1fd0 edi=406f195c ebp=406f18a4 esp=406f1860 ds=002b es=002b gs=0000 flags=00000212 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1cc4 frame 0x406f1fc8 trylevel 0 descr 0x410dfc20 exception type: flags 0 destr (nil) handler (nil) type info 0x410dff68 0: flags 1 type 0x410e4400 ((nil) .PAVCStCommandExceptionDetected@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x410e43e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x410e4440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x410e4430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410dfc40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x410dfc60 2 0: start 2 end 2 catchlevel 3 catch 0x410dfc88 1 0: flags 0 offset -28 handler 0x410d2b63 type 0x410e43e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x410dfc98 2 0: flags 0 offset -24 handler 0x410d2b36 type 0x410e4400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410d2b52 type (nil) trace:seh:call_catch_block matched type 0x410dff48 in tryblock 1 catchblock 0 <============ allright, obviously we're in cxx_frame_handler, at "normal_handler:". So far, everyone seems happy. Off we go into call_catch_block ============> trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410de5e6 code=e06d7363 flags=3 0807bf40:Call msvcrt.__CxxFrameHandler(406f1cc4,406f1f68,406f0ea4,406f0dd8) ret=4010c420 fs=008f eax=410dff20 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1f70 edi=406f0ea0 ebp=406f0da0 esp=406f0d5c ds=002b es=002b gs=0000 flags=00000216 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1f70 edi=406f0ea0 ebp=406f0da0 esp=406f0d5c ds=002b es=002b gs=0000 flags=00000216 trace:seh:EXC_CallHandler handler returned 1 0807bf40:Ret ntdll.RtlUnwind() retval=00000000 ret=40f15d99 <========== Presumably we're still in call_catch_block, really justin the RtlUnwind parts. Now the catch block is called... ============> trace:seh:call_catch_block calling catch block 0x410dfc98 for type 0x410dff48 addr 0x410d2b36 ebp 0x406f1fd4 0807bf40:Call msvcrt.free(404d1be8) ret=5f40388b 0807bf40:Call kernel32.GetProcessHeap() ret=40f21687 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=40f21687 0807bf40:Call ntdll.RtlFreeHeap(403d0000,00000000,404d1be8) ret=40f216a0 0807bf40:Ret ntdll.RtlFreeHeap() retval=00000001 ret=40f216a0 0807bf40:Ret msvcrt.free() retval=00000001 ret=5f40388b 0807bf40:Call msvcrt.malloc(00000050) ret=5f40384f 0807bf40:Call kernel32.GetProcessHeap() ret=40f216bf 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=40f216bf 0807bf40:Call ntdll.RtlAllocateHeap(403d0000,00000000,00000050) ret=40f216d6 0807bf40:Ret ntdll.RtlAllocateHeap() retval=404d55d8 ret=40f216d6 0807bf40:Ret msvcrt.malloc() retval=404d55d8 ret=5f40384f 0807bf40:Call msvcrt.memcpy(406f1234,42a908b0,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f1234 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(406f11fc,42a908b4,00000012) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f11fc ret=410d4a2e 0807bf40:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 0807bf40:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 0807bf40:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 0807bf40:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 0807bf40:Call msvcrt.memcpy(42a902c0,5f4d1b58,00000001) ret=5f402676 0807bf40:Ret msvcrt.memcpy() retval=42a902c0 ret=5f402676 0807bf40:Call msvcrt.memcpy(406f1234,42a908c6,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f1234 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(406f1294,42a908ca,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f1294 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(406f1290,42a908ce,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f1290 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(404d5600,42a908d2,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=404d5600 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(404d55f8,42a908d6,00000008) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=404d55f8 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(406f1234,42a908de,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f1234 ret=410d4a2e 0807bf40:Call msvcrt.memcpy(406f11f8,42a908e2,00000017) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f11f8 ret=410d4a2e 0807bf40:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 0807bf40:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 0807bf40:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 0807bf40:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 0807bf40:Call msvcrt.memcpy(42a90310,5f4d1b58,00000001) ret=5f402676 0807bf40:Ret msvcrt.memcpy() retval=42a90310 ret=5f402676 0807bf40:Call msvcrt.memcpy(406f122c,42a908f9,00000004) ret=410d4a2e 0807bf40:Ret msvcrt.memcpy() retval=406f122c ret=410d4a2e 0807bf40:Call msvcrt.malloc(00000194) ret=5f40384f 0807bf40:Call kernel32.GetProcessHeap() ret=40f216bf 0807bf40:Ret kernel32.GetProcessHeap() retval=403d0000 ret=40f216bf 0807bf40:Call ntdll.RtlAllocateHeap(403d0000,00000000,00000194) ret=40f216d6 0807bf40:Ret ntdll.RtlAllocateHeap() retval=42aeaf30 ret=40f216d6 0807bf40:Ret msvcrt.malloc() retval=42aeaf30 ret=5f40384f 0807bf40:Call msvcrt.memset(42aeaf30,00000000,00000194) ret=410d3b8b 0807bf40:Ret msvcrt.memset() retval=42aeaf30 ret=410d3b8b 0807bf40:Call msvcrt._CxxThrowException(406f12b0,410dfdf8) ret=410d2f3c <=============== The handler wants to raise a new exception. ===============> 0807bf40:Call kernel32.RaiseException(e06d7363,00000001,00000003,406f1190) ret=40f15b9e trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f12b0 trace:seh:EXC_RtlRaiseException info[2]=410dfdf8 trace:seh:EXC_CallHandler calling handler at 0x410de4e6 code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f1030,406f12c8,406f0ccc,406f0cac) ret=4010c420 fs=008f eax=410dfce8 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f12d0 edi=406f0cc8 ebp=406f0c10 esp=406f0bcc ds=002b es=002b gs=0000 flags=00000216 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f12d0 edi=406f0cc8 ebp=406f0c10 esp=406f0bcc ds=002b es=002b gs=0000 flags=00000216 trace:seh:EXC_CallHandler handler returned 1 <=============== looks familiar, we're at normal_handler again, and calling call_catch_block once more...? ================> trace:seh:EXC_CallHandler calling handler at 0x410de4b4 code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f1030,406f1fc8,406f0ccc,406f0cac) ret=4010c420 fs=008f eax=410dfc20 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1fd0 edi=406f0cc8 ebp=406f0c10 esp=406f0bcc ds=002b es=002b gs=0000 flags=00000216 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1030 frame 0x406f1fc8 trylevel 1 descr 0x410dfc20 exception type: flags 0 destr (nil) handler (nil) type info 0x410dfde0 0: flags 1 type 0x410e4478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x410e4458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x410e43e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x410e4440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x410e4430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410dfc40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x410dfc60 2 0: start 2 end 2 catchlevel 3 catch 0x410dfc88 1 0: flags 0 offset -28 handler 0x410d2b63 type 0x410e43e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x410dfc98 2 0: flags 0 offset -24 handler 0x410d2b36 type 0x410e4400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410d2b52 type (nil) 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1fd0 edi=406f0cc8 ebp=406f0c10 esp=406f0bcc ds=002b es=002b gs=0000 flags=00000216 trace:seh:EXC_CallHandler handler returned 1 <============ looks like it wasn't interested... Not sure if I really understand what happened there... ===========> trace:seh:EXC_CallHandler calling handler at 0x410a5add code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f1030,406f2108,406f0ccc,406f0cac) ret=4010c420 fs=008f eax=410ab3f8 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f2110 edi=406f0cc8 ebp=406f0c10 esp=406f0bcc ds=002b es=002b gs=0000 flags=00000216 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1030 frame 0x406f2108 trylevel 1 descr 0x410ab3f8 exception type: flags 0 destr (nil) handler (nil) type info 0x410dfde0 0: flags 1 type 0x410e4478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x410e4458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x410e43e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x410e4440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x410e4430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410ab418 7 0: prev -1 func (nil) 1: prev 0 func (nil) 2: prev 1 func 0x410a5abd 3: prev 2 func 0x410a5ac6 4: prev 3 func 0x410a5acf 5: prev 0 func (nil) 6: prev -1 func (nil) try table: 0x410ab450 2 0: start 1 end 4 catchlevel 5 catch 0x410ab478 2 0: flags 0 offset -80 handler 0x41082e43 type 0x410b5070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x41082e6d type (nil) 1: start 0 end 5 catchlevel 6 catch 0x410ab498 2 0: flags 0 offset -84 handler 0x41082e9c type 0x410b5070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x41082eb9 type (nil) trace:seh:call_catch_block matched type 0x410dfd80 in tryblock 0 catchblock 0 <============= Allright, I'm kind of lost now, but we've obviously found our way back into normal_handler once more, and this time call_catch_block is going to take some action, calling back into Starteam once more; first it does the RtlUnwind ritual: ============> 0807bf40:Call ntdll.RtlUnwind(406f2108,00000000,406f1030,00000000) ret=40f15d99 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410de4e6 code=e06d7363 flags=3 0807bf40:Call msvcrt.__CxxFrameHandler(406f1030,406f12c8,406f0210,406f0144) ret=4010c420 fs=008f eax=410dfce8 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f12d0 edi=406f020c ebp=406f010c esp=406f00c8 ds=002b es=002b gs=0000 flags=00000202 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f12d0 edi=406f020c ebp=406f010c esp=406f00c8 ds=002b es=002b gs=0000 flags=00000202 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410de4b4 code=e06d7363 flags=3 0807bf40:Call msvcrt.__CxxFrameHandler(406f1030,406f1fc8,406f0210,406f0144) ret=4010c420 fs=008f eax=410dfc20 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1fd0 edi=406f020c ebp=406f010c esp=406f00c8 ds=002b es=002b gs=0000 flags=00000202 0807bf40:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=4010c420 fs=008f eax=00000001 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f1fd0 edi=406f020c ebp=406f010c esp=406f00c8 ds=002b es=002b gs=0000 flags=00000202 trace:seh:EXC_CallHandler handler returned 1 0807bf40:Ret ntdll.RtlUnwind() retval=00000000 ret=40f15d99 <============= Allright, here it goes. ==============> trace:seh:call_catch_block calling catch block 0x410ab478 for type 0x410dfd80 addr 0x41082e43 ebp 0x406f2114 0807bf40:Call ntdll.RtlLeaveCriticalSection(42a00434) ret=41085594 0807bf40:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=41085594 0807bf40:Call msvcrt.clock() ret=40f3e262 0807bf40:Ret msvcrt.clock() retval=0000d354 ret=40f3e262 0807bf40:Call ntdll._ftol() ret=40f3e279 0807bf40:Ret ntdll._ftol() retval=0000d354 ret=40f3e279 0807bf40:Call kernel32.lstrcpynA(406ee63c,42a90310 "Event Handler not found",00002000) ret=4104386c 0807bf40:Ret kernel32.lstrcpynA() retval=406ee63c ret=4104386c 0807bf40:Call kernel32.lstrlenA(406ee63c "Event Handler not found") ret=5f4038e2 0807bf40:Ret kernel32.lstrlenA() retval=00000017 ret=5f4038e2 0807bf40:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 0807bf40:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 0807bf40:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 0807bf40:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 0807bf40:Call msvcrt.memcpy(42a90360,406ee63c,00000017) ret=5f403910 0807bf40:Ret msvcrt.memcpy() retval=42a90360 ret=5f403910 0807bf40:Call msvcrt._CxxThrowException(00000000,00000000) ret=41082e6d <============== StarTeam wants to re-raise again. So now, if I understand correctly, they're going to nest another Raise within the already nested Raise. That's it for Starteam. >From here on out, it's all wine. This is where TSHTF. Note that this time, the arguments to ThrowException are both NULL... ostensibly (to me ;) this is the root of the problem. ==============> 0807bf40:Call kernel32.RaiseException(e06d7363,00000001,00000003,406f0530) ret=40f15b9e trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException info[2]=00000000 <============= info[1] and [2] come from the ThrowException arguments (NULL, and NULL of course). At this point, in cxx_excpeption_handler, info[2] becomes exc_type, and gets deferenced: exc_type = (cxx_exception_type *)rec->ExceptionInformation[2]; if (rec->ExceptionCode != CXX_EXCEPTION) goto normal_handler; if (rec->ExceptionInformation[0] != CXX_FRAME_MAGIC) goto normal_handler; if (exc_type->custom_handler) <<<<<<<<<< SEGFAULT on NULL pointer deference here Now chaos ensues: ===============> trace:seh:EXC_CallHandler calling handler at 0x410a5add code=e06d7363 flags=1 0807bf40:Call msvcrt.__CxxFrameHandler(406f03d0,406f2108,406f006c,406f004c) ret=4010c420 fs=008f eax=410ab3f8 ebx=40149d30 ecx=401614a8 edx=00000034 esi=406f2110 edi=406f0068 ebp=406effb0 esp=406eff6c ds=002b es=002b gs=0000 flags=00000216 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f159a3 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000008 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410a5add code=c0000005 flags=10 0807bf40:Call msvcrt.__CxxFrameHandler(405e09d8,406f2108,405e0a44,405e099c) ret=4010c420 fs=008f eax=410ab3f8 ebx=40149d30 ecx=401614a8 edx=00000035 esi=406f2110 edi=00000004 ebp=405e0900 esp=405e08bc ds=002b es=002b gs=0000 flags=00000212 trace:seh:cxx_frame_handler handling C++ exception rec 0x405e09d8 frame 0x406f2108 trylevel 5 descr 0x410ab3f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f151f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410a5add code=c0000005 flags=10 0807bf40:Call msvcrt.__CxxFrameHandler(405dfd68,406f2108,405dfdd4,405dfd2c) ret=4010c420 fs=008f eax=410ab3f8 ebx=40149d30 ecx=401614a8 edx=00000035 esi=406f2110 edi=00000004 ebp=405dfc90 esp=405dfc4c ds=002b es=002b gs=0000 flags=00000212 trace:seh:cxx_frame_handler handling C++ exception rec 0x405dfd68 frame 0x406f2108 trylevel 5 descr 0x410ab3f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f151f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000021e trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410a5add code=c0000005 flags=10 0807bf40:Call msvcrt.__CxxFrameHandler(405df0f8,406f2108,405df164,405df0bc) ret=4010c420 fs=008f eax=410ab3f8 ebx=40149d30 ecx=401614a8 edx=00000035 esi=406f2110 edi=00000004 ebp=405df020 esp=405defdc ds=002b es=002b gs=0000 flags=00000212 trace:seh:cxx_frame_handler handling C++ exception rec 0x405df0f8 frame 0x406f2108 trylevel 5 descr 0x410ab3f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f151f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000021e trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410a5add code=c0000005 flags=10 <============ and so on. What have we learned, except that StarTeam was probably written in Visual Basic? Not sure. I guess I need to focus on: "where are the NULL's passed to ThrowException coming from?"?? Or is there something more obvious going on here that I'm to ign'ant to grok? thanks for your help,... -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 2

How to add a new test dir?
by Greg Turner 06 Oct '02

06 Oct '02

I'm trying to create a tests directory for rpcrt4. So far I've done the following: o Create a dlls/rpcrt4/tests directory o Change dlls/rpcrt4/Makefile.in: <============= --- Makefile.in.A_PL2 2002-10-04 09:26:11.000000000 -0500 +++ Makefile.in 2002-10-06 17:59:31.000000000 -0500 @@ -13,6 +13,8 @@ rpc_binding.c \ rpcrt4_main.c +SUBDIRS = tests + @MAKE_DLL_RULES@ ### Dependencies: ===========> o add dlls/rpcrt4/tests/Makefile.in: <=============== TOPSRCDIR = @top_srcdir@ TOPOBJDIR = ../../.. SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = rpcrt4.dll IMPORTS = rpcrt4 CTESTS = \ rpc.c @MAKE_TEST_RULES@ ### Dependencies: ==============> o add dlls/rpcrt4/tests/rpc.c: <============ #include "wine/test.h" #include <winbase.h> #include <winnt.h> #include <winerror.h> START_TEST( rpc ) { trace ( " **** STARTING TEST %d **** \n", 0 ); ok (1); Exit(); } ============> but I get no love. configure seems to go OK; When I run make depend it fails: <============== make[2]: Entering directory `/var/src/wine/dlls/rpcrt4' cd `dirname tests/__depend__` && make depend make[3]: Entering directory `/var/src/wine/dlls/rpcrt4/tests' make[3]: *** No rule to make target `depend'. Stop. make[3]: Leaving directory `/var/src/wine/dlls/rpcrt4/tests' make[2]: *** [tests/__depend__] Error 2 make[2]: Leaving directory `/var/src/wine/dlls/rpcrt4' make[1]: *** [rpcrt4/__depend__] Error 2 make[1]: Leaving directory `/var/src/wine/dlls' make: *** [dlls/__depend__] Error 2 ==============> What am I missing? Is this documented somewhere? Thanks, -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

1 0

msvcrt tests
by György 'Nog' Jeney 06 Oct '02

06 Oct '02

Im trying to write regression tests for the sscanf function but ran into some problems. First, there were some conflicts with the defines in the headers with my linux ones, but that was fixed simply by defining USE_MSVCRT_PREFIX. Whenever I try to run the test it spews out an error: undefind reference to func_sscanf. Ofcourse there is no export for func_sscanf because it was prefixed to avoid a naming conflict with the unix defines. How do I get this to work? If its not prefixed, then there is a conflict but if it is then it cant find the export.

2 2

Hello wine-devel ��a��d�A�N�a�L�ӼW�j�C
by 130924wine-devel 06 Oct '02

06 Oct '02

1 0

Re: some rpcrt4 stuff
by Greg Turner 06 Oct '02

06 Oct '02

On Wednesday 02 October 2002 08:49 am, Jrgen Schmied wrote: > > Implementations of these and much more can be found in this patch > > submission, which was apparently never applied: > > http://www.winehq.com/hypermail/wine-patches/2002/06/0103.html > > Alexandre did not like the rpc-stuff in the server. I did start > implementing the NT-LPC functions but I have not so much time at the moment > so it will take a while. > Nevertheless, large parts of the patch could be applied. > > juergen > > > --- > juergen.schmied(a)debitel.net are we allowed to merge in stuff from Rewind/Transgaming? I thought no? Anyhow, assuming it's OK, I'd be happy to sort this out and produce a patch. BTW, I've already noticed a mistake in my patch, UuidIsNil should return true if the Uuid arg is NULL. the above patch lacks UuidFromString, which my patch provides (I "need" this). UuidFromStringW should also be provided but I've no knoweldge of how to work with widechar's in C; is there somewhere in wine or elsewhere with good examples of how to work with these? My algo should basically work if I just substitude "sscanf" with "swscanf", but I don't know how to do the verification steps. Thanks, -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

5 9

Re: Wine language problem
by Armish 06 Oct '02

06 Oct '02

Hi I have a nap.exe file. $ wine nap.exe (errors are in the withoutLANG) I got these errors and then $ export LANG=us_US $ wine nap.exe (print out is in the withLANG) and when I use the second way ( with LANG ) the program runs. If I add "export LANG=us_US" to my .bash_profile, some of programs runs in english though the whole system is turkish. So I cannot add this line to .bash_profile. Can smth be done while compiling it or can some codes be changed to fix it? Thanks __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com

2 2

Wine language problem
by Armish 05 Oct '02

05 Oct '02

Hi all, I installed the latest version of wine on my Turkish Linux system. But to run without any errors, I have to do a "LANG=US_us" before running wine. Can anything be done about this problem? We have to fix it because end-users dont like doing this... Thanks -- Armish __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com

2 1

Re: AVI resources in shell32.dll
by Sylvain Petreolle 05 Oct '02

05 Oct '02

--- Stefan Leichter <Stefan.Leichter(a)camLine.com> a écrit : > I did not extract the original. The tool resgrab ( > http://www.Inner-Smile.com/dl_resg.htm#downl) told me the size. > > Using the original is hopefuly a joke!?! No, if it's only for testing purpose. You can extract it using ResHacker, as Greg said. But you didn't answer to my second question : does the size really matter? After all it's only 50k... ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

Re: [patch] Fix listview scrolling
by Dimitrie O. Paun 05 Oct '02

05 Oct '02

> instead of the very bottom. Lastly, I'm pretty sure there should be > separate nPartialAdjust variables for horz and vert scrolling. You are right, we do need separate nPartialAdjust. My bad. THe other bug was (half of it) in the old code, when I changed it I noticed the inconsistency, is just that I picked the wrong half :). Thanks for the fix. This looks good, it should go in. -- Dimi.

1 0

Need help interpreting debug log for Wine hard loop
by Sean Millichamp 04 Oct '02

04 Oct '02

I hope this isn't too off-topic for the wine-devel list but I asked for debugging help on wine-users a couple of days ago and got no reply so maybe that isn't the right place to ask about debugging help? I bought and use Codeweaver's Crossover product to drive Office and have fiddled with Wine briefly on and off over the years but other then that I am mostly a Wine newbie. I am trying to make an old Windows 3.1 application work and it appears to be causing Wine to go into a hard loop while loading. For what it's worth, this application is called "Travex" and is used in the health care industry. I think it uses the Win 3.1 era Borland GUI toolkit in case it matters. I followed the directions on the website for debugging and have a --debugmsg warn+all +loaddll output that I only can vaguely interpret. Wine enters the hard loop somewhere following the debug log. I tried debug logs at various other levels including a relay log/trace (though I have no idea what it is) and +all and under those levels the same output keeps getting outputted to the log as Wine loops. I am not a Windows developer although I have done a little with C under Linux. Is there anyone who could help me figure out what is going wrong? I'd be happy to make the logs available for http or send them in email. Unfortunately, I can't provide the application itself due to licensing issues (it's a commercial package). I have tested it with Wine from RH 7.3, Wine from 10/01 CVS, and Codeweavers Crossover Office 1.0 (just for kicks). All three exhibit the same behavior. I tried the Wine from 10/01 in both Win98 and Win31 behavior mode. No change. The application runs just fine in Windows 98. I installed it in my fake_windows in Wine and have tried running it from there as well as my real Windows partition. No change. Any help would be greatly appreciated. Thanks in advance. Sean

3 7

Re: Major tidy up of Scroll.c to add foundations for flatscroll bars
by György 'Nog' Jeney 04 Oct '02

04 Oct '02

> I have used this code to implement flat scroll bars in two ways however > I run into problems and I am looking for advice. Hi, I was thinking about implementing flatscrollbars but never got round to implement the Flatscrollbars itself. I thought about doig it like this: Subclass the window with flatscrollbars, with the Subclassing functions that I have implemented recently. Implement GetScrollBarInfo and use it to get all of the scrollbar properties like thump position and size, arrow sizes etc. Store an internal list of the System metricies (just like native) and then draw the control. All of the functions that pertain to flat scroll bars will just call their user counterparts and the same goes for messages. nog.

3 2

VB errors (treeview, debugger)
by Fabian Cenedese 04 Oct '02

04 Oct '02

Hi again Problem 1: I have found something strange in a VB app. If I run it with "wine vberror" it works quite ok. But if I call it with "winedbg vberror" it freaks out on pressing the button. Maybe it's a timing problem that an exception couldn't be caught as wine could do it being faster. Problem 2: Quite simple to test: If I click in the treeview it disappears :) Both problems can be tested with this little sample proggy: http://www.indel.ch/ftp/VBError.zip I had to use the native oleaut32.dll as the builtin worked even worse on the treeview. The rest is out of the (cvs-)box 20021004, SuSE 8.0 Thanks bye Fabi

1 0

Listview K6
by Dimitrie O. Paun 04 Oct '02

04 Oct '02

This one fixes a nasty little bug in OWNERDATA listviews. Xnews should now refresh properly. Selection is still borken, but that's the subject of a different patch. Bug reports are always welcomed. ;) ChangeLog Fix condition so we actually store the state in virtual listviews. Assorted code cleanups. --- dlls/comctl32/listview.c.K5 Fri Oct 4 02:39:12 2002 +++ dlls/comctl32/listview.c Fri Oct 4 11:38:11 2002 @@ -1236,7 +1236,7 @@ LONG lStyle = infoPtr->dwStyle; UINT uView = lStyle & LVS_TYPEMASK; POINT Origin, Position, TopLeft; - RECT Icon, Boundary, Label; + RECT Icon, Boundary, Label, FullText; INT nIndent = 0; if (!LISTVIEW_GetOrigin(infoPtr, &Origin)) return FALSE; @@ -1380,7 +1380,6 @@ if (infoPtr->himlNormal != NULL) { INT nLabelWidth; - RECT FullText; Label.left = TopLeft.x + Origin.x; Label.top = TopLeft.y + Origin.y + ICON_TOP_PADDING_HITABLE + @@ -1404,10 +1403,6 @@ InflateRect(&FullText, 2, 0); if (lprcLabel) *lprcLabel = Label; if (lprcText) *lprcText = FullText; - TRACE("hwnd=%x, item=%d, label=(%d,%d)-(%d,%d), fulltext=(%d,%d)-(%d,%d)\n", - infoPtr->hwndSelf, nItem, - Label.left, Label.top, Label.right, Label.bottom, - FullText.left, FullText.top, FullText.right, FullText.bottom); } else return FALSE; } @@ -1433,9 +1428,6 @@ Label.right = nLeftPos + infoPtr->nItemWidth; if (lprcLabel) *lprcLabel = Label; if (lprcText) *lprcText = Label; - TRACE("hwnd=%x, item=%d, label=(%d,%d)-(%d,%d)\n", - infoPtr->hwndSelf, nItem, - Label.left, Label.top, Label.right, Label.bottom); } else /* LVS_LIST or LVS_REPORT */ { @@ -1461,7 +1453,8 @@ if (lprcText) *lprcText = Label; } - TRACE("hwnd=%x, item=%d, label=%s\n", infoPtr->hwndSelf, nItem, debugrect(&Label)); + TRACE("hwnd=%x, item=%d, label=%s, fulltext=%s\n", + infoPtr->hwndSelf, nItem, debugrect(&Label), debugrect(lprcText)); /***********************************************************/ /* compute boundary box for the item (ala LVM_GETITEMRECT) */ @@ -2296,6 +2289,8 @@ { LVITEMW lvItem; + TRACE("nItem=%d\n", nItem); + LISTVIEW_RemoveAllSelections(infoPtr); lvItem.state = LVIS_FOCUSED | LVIS_SELECTED; @@ -2485,14 +2480,16 @@ NMLISTVIEW nmlv; INT oldState; - /* a virtual livst view stores only state for the main item */ + /* a virtual listview stores only the state for the main item */ if (lpLVItem->iSubItem || !(lpLVItem->mask & LVIF_STATE)) return FALSE; oldState = LISTVIEW_GetItemState(infoPtr, lpLVItem->iItem, LVIS_FOCUSED | LVIS_SELECTED); + TRACE("oldState=%x, newState=%x, uCallbackMask=%x\n", + oldState, lpLVItem->state, infoPtr->uCallbackMask); /* we're done if we don't need to change anything we handle */ - if ( (oldState ^ lpLVItem->state) & lpLVItem->stateMask & - ~infoPtr->uCallbackMask & (LVIS_FOCUSED | LVIS_SELECTED)) return FALSE; + if ( !((oldState ^ lpLVItem->state) & lpLVItem->stateMask & + ~infoPtr->uCallbackMask & (LVIS_FOCUSED | LVIS_SELECTED))) return TRUE; /* * As per MSDN LVN_ITEMCHANGING notifications are _NOT_ sent for @@ -2517,7 +2514,7 @@ add_selection_range(infoPtr, lpLVItem->iItem, lpLVItem->iItem, TRUE); } else - remove_selection_range(infoPtr, lpLVItem->iItem, lpLVItem->iItem, TRUE); + remove_selection_range(infoPtr, lpLVItem->iItem, lpLVItem->iItem, TRUE); } /* notify the parent now that things have changed */ @@ -3267,7 +3264,7 @@ } /* Get scroll info once before loop */ - LISTVIEW_GetOrigin(infoPtr, &ptOrig); + if (!LISTVIEW_GetOrigin(infoPtr, &ptOrig)) return; /* we now narrow the columns as well */ nLastCol = nColumnCount - 1; @@ -3315,7 +3312,8 @@ item.mask = LVIF_PARAM | LVIF_STATE; item.stateMask = LVIS_SELECTED | LVIS_FOCUSED; if (!LISTVIEW_GetItemW(infoPtr, &item, TRUE)) continue; - + + ZeroMemory(&dis, sizeof(dis)); dis.hwndItem = infoPtr->hwndSelf; dis.hDC = hdc; dis.CtlType = ODT_LISTVIEW; @@ -3323,7 +3321,6 @@ dis.itemID = nItem; dis.itemAction = ODA_DRAWENTIRE; dis.itemData = item.lParam; - dis.itemState = 0; if (item.state & LVIS_SELECTED) dis.itemState |= ODS_SELECTED; if (item.state & LVIS_FOCUSED) dis.itemState |= ODS_FOCUS; dis.rcItem.left = lpCols[0].rc.left; @@ -3333,7 +3330,7 @@ OffsetRect(&dis.rcItem, ptOrig.x, 0); TRACE("item=%s, rcItem=%s\n", debuglvitem_t(&item, TRUE), debugrect(&dis.rcItem)); - if (SendMessageW(GetParent(infoPtr->hwndSelf), WM_DRAWITEM, uID, (LPARAM)&dis)) + if (SendMessageW(GetParent(infoPtr->hwndSelf), WM_DRAWITEM, dis.CtlID, (LPARAM)&dis)) continue; } @@ -3481,7 +3478,7 @@ if(GETITEMCOUNT(infoPtr) == 0) return; - LISTVIEW_GetOrigin(infoPtr, &ptOrigin); + if (!LISTVIEW_GetOrigin(infoPtr, &ptOrigin)) return; GetClipBox(hdc, &rcClip); @@ -4746,7 +4743,7 @@ } /* we store only a little state, so if we're not asked, we're done */ - if (!(lpLVItem->mask & LVIF_STATE) || lpLVItem->iSubItem) return FALSE; + if (!(lpLVItem->mask & LVIF_STATE) || lpLVItem->iSubItem) return TRUE; /* if focus is handled by us, report it */ if ( !(infoPtr->uCallbackMask & LVIS_FOCUSED) ) @@ -6790,28 +6787,26 @@ */ static LRESULT LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem) { - BOOL bResult = TRUE; - LVITEMW lvItem; - - TRACE("(nItem=%d, state=%x, stateMask=%x)\n", nItem, lpLVItem->state, - lpLVItem->stateMask); + BOOL bResult = TRUE; + LVITEMW lvItem; - lvItem.iItem = nItem; - lvItem.iSubItem = 0; - lvItem.mask = LVIF_STATE; - lvItem.state = lpLVItem->state; - lvItem.stateMask = lpLVItem->stateMask; - - if (nItem == -1) - { - /* apply to all items */ - for (lvItem.iItem = 0; lvItem.iItem < GETITEMCOUNT(infoPtr); lvItem.iItem++) - if (!LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE)) bResult = FALSE; - } - else - bResult = LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE); + lvItem.iItem = nItem; + lvItem.iSubItem = 0; + lvItem.mask = LVIF_STATE; + lvItem.state = lpLVItem->state; + lvItem.stateMask = lpLVItem->stateMask; + TRACE("lvItem=%s\n", debuglvitem_t(&lvItem, TRUE)); + + if (nItem == -1) + { + /* apply to all items */ + for (lvItem.iItem = 0; lvItem.iItem < GETITEMCOUNT(infoPtr); lvItem.iItem++) + if (!LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE)) bResult = FALSE; + } + else + bResult = LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE); - return bResult; + return bResult; } /***

1 0

Window flags problem
by Fabian Cenedese 04 Oct '02

04 Oct '02

Hi I have a problem with my VC6 MFC MDI app. Every child window that is docked inside isn't painted anymore and doesn't receive any messages. Together with a friend (THX ic) I found out that the wrapper window that does the docking doesn't have the visible flag set. Even if I create the window with the flag set it gets deleted somewhere in CreateWindowEx or ShowWindow. In Windows the flag can even get set even if it wasn't set before but I just couldn't find out why. I scrutinized the MoveWindow call. It sends the messages WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_WINDOWPOSCHANGED, WM_MOVE and WM_SIZE (in this order) to the window. After these there is an additional WM_SHOWWINDOW. In every handler the visible flag isn't changed yet. After leaving the MoveWindow call the flag can be set or deleted. So this must happen between WM_SHOWWINDOW and the end of MoveWindow. But I couldn't find out what reason Windows uses to change it so I can't say where in wine the error is. I'd be very thankful if somebody with knowledge about windows and their style flags could shed some light upon this. Here is a small sample app (only exe, source is quite complicated, but I can deliver that too if anybody is interested). There is a toolbar docked below the menu but in wine there is just a dead area. http://www.indel.ch/ftp/TestIMD.zip BTW winedbg doesn't show the class information for walk wnd. The same problem has MS-Spy++ but besides that it runs quite well in wine :) Thanks for any hint/help/patch... bye Fabi

1 0

Regression Test - kernel atom test
by Steven Edwards 04 Oct '02

04 Oct '02

Here is another one on my win2k sp3 box. All tests compiled with cygwin atom.c:81: Test failed: succeeded adding ff74 atom.c:84: Test failed: succeeded adding ff74 atom.c:81: Test failed: succeeded adding ff75 atom.c:84: Test failed: succeeded adding ff75 atom.c:81: Test failed: succeeded adding ff76 atom.c:84: Test failed: succeeded adding ff76 atom.c:81: Test failed: succeeded adding ff77 atom.c:84: Test failed: succeeded adding ff77 atom.c:81: Test failed: succeeded adding ff78 atom.c:84: Test failed: succeeded adding ff78 atom.c:81: Test failed: succeeded adding ff79 atom.c:84: Test failed: succeeded adding ff79 atom.c:81: Test failed: succeeded adding ff7a atom.c:84: Test failed: succeeded adding ff7a atom.c:81: Test failed: succeeded adding ff7b atom.c:84: Test failed: succeeded adding ff7b atom.c:81: Test failed: succeeded adding ff7c atom.c:84: Test failed: succeeded adding ff7c atom.c:81: Test failed: succeeded adding ff7d atom.c:84: Test failed: succeeded adding ff7d atom.c:81: Test failed: succeeded adding ff7e atom.c:84: Test failed: succeeded adding ff7e atom.c:81: Test failed: succeeded adding ff7f atom.c:84: Test failed: succeeded adding ff7f atom.c:81: Test failed: succeeded adding ff80 atom.c:84: Test failed: succeeded adding ff80 atom.c:81: Test failed: succeeded adding ff81 atom.c:84: Test failed: succeeded adding ff81 atom.c:81: Test failed: succeeded adding ff82 atom.c:84: Test failed: succeeded adding ff82 atom.c:81: Test failed: succeeded adding ff83 atom.c:84: Test failed: succeeded adding ff83 atom.c:81: Test failed: succeeded adding ff84 atom.c:84: Test failed: succeeded adding ff84 atom.c:81: Test failed: succeeded adding ff85 atom.c:84: Test failed: succeeded adding ff85 atom.c:81: Test failed: succeeded adding ff86 atom.c:84: Test failed: succeeded adding ff86 atom.c:81: Test failed: succeeded adding ff87 atom.c:84: Test failed: succeeded adding ff87 atom.c:81: Test failed: succeeded adding ff88 atom.c:84: Test failed: succeeded adding ff88 atom.c:81: Test failed: succeeded adding ff89 atom.c:84: Test failed: succeeded adding ff89 atom.c:81: Test failed: succeeded adding ff8a atom.c:84: Test failed: succeeded adding ff8a atom.c:81: Test failed: succeeded adding ff8b atom.c:84: Test failed: succeeded adding ff8b atom.c:81: Test failed: succeeded adding ff8c atom.c:84: Test failed: succeeded adding ff8c atom.c:81: Test failed: succeeded adding ff8d atom.c:84: Test failed: succeeded adding ff8d atom.c:81: Test failed: succeeded adding ff8e atom.c:84: Test failed: succeeded adding ff8e atom.c:81: Test failed: succeeded adding ff8f atom.c:84: Test failed: succeeded adding ff8f atom.c:81: Test failed: succeeded adding ff90 atom.c:84: Test failed: succeeded adding ff90 atom.c:81: Test failed: succeeded adding ff91 atom.c:84: Test failed: succeeded adding ff91 atom.c:81: Test failed: succeeded adding ff92 atom.c:84: Test failed: succeeded adding ff92 atom.c:81: Test failed: succeeded adding ff93 atom.c:84: Test failed: succeeded adding ff93 atom.c:81: Test failed: succeeded adding ff94 atom.c:84: Test failed: succeeded adding ff94 atom.c:81: Test failed: succeeded adding ff95 atom.c:84: Test failed: succeeded adding ff95 atom.c:81: Test failed: succeeded adding ff96 atom.c:84: Test failed: succeeded adding ff96 atom.c:81: Test failed: succeeded adding ff97 atom.c:84: Test failed: succeeded adding ff97 atom.c:81: Test failed: succeeded adding ff98 atom.c:84: Test failed: succeeded adding ff98 atom.c:81: Test failed: succeeded adding ff99 atom.c:84: Test failed: succeeded adding ff99 atom.c:81: Test failed: succeeded adding ff9a atom.c:84: Test failed: succeeded adding ff9a atom.c:81: Test failed: succeeded adding ff9b atom.c:84: Test failed: succeeded adding ff9b atom.c:81: Test failed: succeeded adding ff9c atom.c:84: Test failed: succeeded adding ff9c atom.c:81: Test failed: succeeded adding ff9d atom.c:84: Test failed: succeeded adding ff9d atom.c:81: Test failed: succeeded adding ff9e atom.c:84: Test failed: succeeded adding ff9e atom.c:81: Test failed: succeeded adding ff9f atom.c:84: Test failed: succeeded adding ff9f atom.c:81: Test failed: succeeded adding ffa0 atom.c:84: Test failed: succeeded adding ffa0 atom.c:81: Test failed: succeeded adding ffa1 atom.c:84: Test failed: succeeded adding ffa1 atom.c:81: Test failed: succeeded adding ffa2 atom.c:84: Test failed: succeeded adding ffa2 atom.c:81: Test failed: succeeded adding ffa3 atom.c:84: Test failed: succeeded adding ffa3 atom.c:81: Test failed: succeeded adding ffa4 atom.c:84: Test failed: succeeded adding ffa4 atom.c:81: Test failed: succeeded adding ffa5 atom.c:84: Test failed: succeeded adding ffa5 atom.c:81: Test failed: succeeded adding ffa6 atom.c:84: Test failed: succeeded adding ffa6 atom.c:81: Test failed: succeeded adding ffa7 atom.c:84: Test failed: succeeded adding ffa7 atom.c:81: Test failed: succeeded adding ffa8 atom.c:84: Test failed: succeeded adding ffa8 atom.c:81: Test failed: succeeded adding ffa9 atom.c:84: Test failed: succeeded adding ffa9 atom.c:81: Test failed: succeeded adding ffaa atom.c:84: Test failed: succeeded adding ffaa atom.c:81: Test failed: succeeded adding ffab atom.c:84: Test failed: succeeded adding ffab atom.c:81: Test failed: succeeded adding ffac atom.c:84: Test failed: succeeded adding ffac atom.c:81: Test failed: succeeded adding ffad atom.c:84: Test failed: succeeded adding ffad atom.c:81: Test failed: succeeded adding ffae atom.c:84: Test failed: succeeded adding ffae atom.c:81: Test failed: succeeded adding ffaf atom.c:84: Test failed: succeeded adding ffaf atom.c:81: Test failed: succeeded adding ffb0 atom.c:84: Test failed: succeeded adding ffb0 atom.c:81: Test failed: succeeded adding ffb1 atom.c:84: Test failed: succeeded adding ffb1 atom.c:81: Test failed: succeeded adding ffb2 atom.c:84: Test failed: succeeded adding ffb2 atom.c:81: Test failed: succeeded adding ffb3 atom.c:84: Test failed: succeeded adding ffb3 atom.c:81: Test failed: succeeded adding ffb4 atom.c:84: Test failed: succeeded adding ffb4 atom.c:81: Test failed: succeeded adding ffb5 atom.c:84: Test failed: succeeded adding ffb5 atom.c:81: Test failed: succeeded adding ffb6 atom.c:84: Test failed: succeeded adding ffb6 atom.c:81: Test failed: succeeded adding ffb7 atom.c:84: Test failed: succeeded adding ffb7 atom.c:81: Test failed: succeeded adding ffb8 atom.c:84: Test failed: succeeded adding ffb8 atom.c:81: Test failed: succeeded adding ffb9 atom.c:84: Test failed: succeeded adding ffb9 atom.c:81: Test failed: succeeded adding ffba atom.c:84: Test failed: succeeded adding ffba atom.c:81: Test failed: succeeded adding ffbb atom.c:84: Test failed: succeeded adding ffbb atom.c:81: Test failed: succeeded adding ffbc atom.c:84: Test failed: succeeded adding ffbc atom.c:81: Test failed: succeeded adding ffbd atom.c:84: Test failed: succeeded adding ffbd atom.c:81: Test failed: succeeded adding ffbe atom.c:84: Test failed: succeeded adding ffbe atom.c:81: Test failed: succeeded adding ffbf atom.c:84: Test failed: succeeded adding ffbf atom.c:81: Test failed: succeeded adding ffc0 atom.c:84: Test failed: succeeded adding ffc0 atom.c:81: Test failed: succeeded adding ffc1 atom.c:84: Test failed: succeeded adding ffc1 atom.c:81: Test failed: succeeded adding ffc2 atom.c:84: Test failed: succeeded adding ffc2 atom.c:81: Test failed: succeeded adding ffc3 atom.c:84: Test failed: succeeded adding ffc3 atom.c:81: Test failed: succeeded adding ffc4 atom.c:84: Test failed: succeeded adding ffc4 atom.c:81: Test failed: succeeded adding ffc5 atom.c:84: Test failed: succeeded adding ffc5 atom.c:81: Test failed: succeeded adding ffc6 atom.c:84: Test failed: succeeded adding ffc6 atom.c:81: Test failed: succeeded adding ffc7 atom.c:84: Test failed: succeeded adding ffc7 atom.c:81: Test failed: succeeded adding ffc8 atom.c:84: Test failed: succeeded adding ffc8 atom.c:81: Test failed: succeeded adding ffc9 atom.c:84: Test failed: succeeded adding ffc9 atom.c:81: Test failed: succeeded adding ffca atom.c:84: Test failed: succeeded adding ffca atom.c:81: Test failed: succeeded adding ffcb atom.c:84: Test failed: succeeded adding ffcb atom.c:81: Test failed: succeeded adding ffcc atom.c:84: Test failed: succeeded adding ffcc atom.c:81: Test failed: succeeded adding ffcd atom.c:84: Test failed: succeeded adding ffcd atom.c:81: Test failed: succeeded adding ffce atom.c:84: Test failed: succeeded adding ffce atom.c:81: Test failed: succeeded adding ffcf atom.c:84: Test failed: succeeded adding ffcf atom.c:81: Test failed: succeeded adding ffd0 atom.c:84: Test failed: succeeded adding ffd0 atom.c:81: Test failed: succeeded adding ffd1 atom.c:84: Test failed: succeeded adding ffd1 atom.c:81: Test failed: succeeded adding ffd2 atom.c:84: Test failed: succeeded adding ffd2 atom.c:81: Test failed: succeeded adding ffd3 atom.c:84: Test failed: succeeded adding ffd3 atom.c:81: Test failed: succeeded adding ffd4 atom.c:84: Test failed: succeeded adding ffd4 atom.c:81: Test failed: succeeded adding ffd5 atom.c:84: Test failed: succeeded adding ffd5 atom.c:81: Test failed: succeeded adding ffd6 atom.c:84: Test failed: succeeded adding ffd6 atom.c:81: Test failed: succeeded adding ffd7 atom.c:84: Test failed: succeeded adding ffd7 atom.c:81: Test failed: succeeded adding ffd8 atom.c:84: Test failed: succeeded adding ffd8 atom.c:81: Test failed: succeeded adding ffd9 atom.c:84: Test failed: succeeded adding ffd9 atom.c:81: Test failed: succeeded adding ffda atom.c:84: Test failed: succeeded adding ffda atom.c:81: Test failed: succeeded adding ffdb atom.c:84: Test failed: succeeded adding ffdb atom.c:81: Test failed: succeeded adding ffdc atom.c:84: Test failed: succeeded adding ffdc atom.c:81: Test failed: succeeded adding ffdd atom.c:84: Test failed: succeeded adding ffdd atom.c:81: Test failed: succeeded adding ffde atom.c:84: Test failed: succeeded adding ffde atom.c:81: Test failed: succeeded adding ffdf atom.c:84: Test failed: succeeded adding ffdf atom.c:81: Test failed: succeeded adding ffe0 atom.c:84: Test failed: succeeded adding ffe0 atom.c:81: Test failed: succeeded adding ffe1 atom.c:84: Test failed: succeeded adding ffe1 atom.c:81: Test failed: succeeded adding ffe2 atom.c:84: Test failed: succeeded adding ffe2 atom.c:81: Test failed: succeeded adding ffe3 atom.c:84: Test failed: succeeded adding ffe3 atom.c:81: Test failed: succeeded adding ffe4 atom.c:84: Test failed: succeeded adding ffe4 atom.c:81: Test failed: succeeded adding ffe5 atom.c:84: Test failed: succeeded adding ffe5 atom.c:81: Test failed: succeeded adding ffe6 atom.c:84: Test failed: succeeded adding ffe6 atom.c:81: Test failed: succeeded adding ffe7 atom.c:84: Test failed: succeeded adding ffe7 atom.c:81: Test failed: succeeded adding ffe8 atom.c:84: Test failed: succeeded adding ffe8 atom.c:81: Test failed: succeeded adding ffe9 atom.c:84: Test failed: succeeded adding ffe9 atom.c:81: Test failed: succeeded adding ffea atom.c:84: Test failed: succeeded adding ffea atom.c:81: Test failed: succeeded adding ffeb atom.c:84: Test failed: succeeded adding ffeb atom.c:81: Test failed: succeeded adding ffec atom.c:84: Test failed: succeeded adding ffec atom.c:81: Test failed: succeeded adding ffed atom.c:84: Test failed: succeeded adding ffed atom.c:81: Test failed: succeeded adding ffee atom.c:84: Test failed: succeeded adding ffee atom.c:81: Test failed: succeeded adding ffef atom.c:84: Test failed: succeeded adding ffef atom.c:81: Test failed: succeeded adding fff0 atom.c:84: Test failed: succeeded adding fff0 atom.c:81: Test failed: succeeded adding fff1 atom.c:84: Test failed: succeeded adding fff1 atom.c:81: Test failed: succeeded adding fff2 atom.c:84: Test failed: succeeded adding fff2 atom.c:81: Test failed: succeeded adding fff3 atom.c:84: Test failed: succeeded adding fff3 atom.c:81: Test failed: succeeded adding fff4 atom.c:84: Test failed: succeeded adding fff4 atom.c:81: Test failed: succeeded adding fff5 atom.c:84: Test failed: succeeded adding fff5 atom.c:81: Test failed: succeeded adding fff6 atom.c:84: Test failed: succeeded adding fff6 atom.c:81: Test failed: succeeded adding fff7 atom.c:84: Test failed: succeeded adding fff7 atom.c:81: Test failed: succeeded adding fff8 atom.c:84: Test failed: succeeded adding fff8 atom.c:81: Test failed: succeeded adding fff9 atom.c:84: Test failed: succeeded adding fff9 atom.c:81: Test failed: succeeded adding fffa atom.c:84: Test failed: succeeded adding fffa atom.c:81: Test failed: succeeded adding fffb atom.c:84: Test failed: succeeded adding fffb atom.c:81: Test failed: succeeded adding fffc atom.c:84: Test failed: succeeded adding fffc atom.c:81: Test failed: succeeded adding fffd atom.c:84: Test failed: succeeded adding fffd atom.c:81: Test failed: succeeded adding fffe atom.c:84: Test failed: succeeded adding fffe atom.c:81: Test failed: succeeded adding ffff atom.c:84: Test failed: succeeded adding ffff atom.c:110: Test failed: bad buffer contents atom.c:112: Test failed: GlobalGetAtomNameW succeeded on short buffer atom.c:116: Test failed: succeded atom.c:118: Test failed: succeded atom.c:120: Test failed: succeded atom.c:122: Test failed: succeded atom.c:140: Test failed: bad length 0 atom.c:143: Test failed: bad buffer contents aaaaaaaaaaha?xA

4 13

AVI resources in shell32.dll
by Stefan Leichter 03 Oct '02

03 Oct '02

Hello, i have an installer that fails because of a missing AVI resource (the magnifier in front of the computer) in the buildin shell32.dll. To get the installer running i tried to build the resource. i used Paintshop Pro 6 to create the single pictures of the AVI and built the AVI with the animation builder of Paintshop Pro. The created AVI work (at least in the Media Player), but my new AVI is 53k big instead of the 7k of the native shell32.dll. Reducing the color deep of the single picturs does not have any effect to the size of the AVI. What do i need to change to get the resource as small as the native on? Are other tools needed to build the resource? Using compression ? Is there a tool to analyse the native resource in deep ? Any ideas? Thanks Stefan

3 4

Re: Need help interpreting debug log for Wine hard loop
by Miguel Feitosa 03 Oct '02

03 Oct '02

On Thu, 2002-10-03 at 18:35, Sean Millichamp wrote: > On Thu, 2002-10-03 at 17:03, Miguel Feitosa wrote: > > I forgot to ask. > > What are the DLLs that your app links? > > It seems that your code is failing before mine. > > Mine actually got to start drawing a window...and yours hasnt. > > I was able to track done my erros to Borlands BWCC or something > > like that .DLL > > Well... I'm not sure how to see what DLL the app links but I suspect it > does need BWCC. I looked and it was installed in C:\Windows\System on > my fake_windows area. I use +file and +dll [I think] I've never done +loaddll Do a simple grep in the wine src and you can see the channels that exist. > > When I do a --debugmsg +loaddll I don't see any mention of bwcc.dll or > any non-builtin DLL. Is there a way I can force-load bwcc? Is there > some reason Wine wouldn't be loading it automatically? No, wine loades DLLs very well. I have never had any problems with that. > > Here are the DLLs that it's installer installed in Windows\System: > bwcc.dll dewcc.dll dewsc.dll dewtc.dll winsys.dll The only one I know is bwcc.dll > > I presume it needs all of them at some point but I see none of them in > use with loaddll before the loop. Do I need to configure this special > in .wine/config? I thought that it was supposed to know to auto-load > them but.... No need to put them in config, they will be loaded, your app is failing before bwcc get's loaded... > > I'm sorry if these are simple questions. I really appreciate you taking > the time to try to help me. If I don't get this working I will have to > install Windows where the application is needed (currently it's all > Linux) and I want to avoid that if possible. No problem, I had to sort through all this too a couple months ago. At the time I was trying to do this, I seach alot and didnt find a whole lot about wine + Borland C... I finally gave it up... I believe that expert wine programmers with the relay can pinpoint the issue that is bugging your app...8-) > > Thanks, > Sean > > See ya! Miguel

1 0

miscemu/wine gets into the way in map_image
by Uwe Bonnes 03 Oct '02

03 Oct '02

Hallo, the full installer for XILINX Webpack 5.1 is a 160 MByte executable. It doesn't start with wine: > ~/tmp/wine/compile/wine/wine WebPACK_51_fcfull_i.exe err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? Clearly my kernel isn't "security-patched". Printing out /proc/maps/self in this situation shows: 08048000-0805c000 r-xp 00000000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine 0805c000-0805d000 rw-p 00013000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine An strace on wine shows the mmap call in map_image: 23236 mmap2(0x400000, 161087488, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404c2000 Adding 0x400000 and 161087488 gives someting in the 0x09d0000 range. This overlaps with the wine executable itself and mmap2 can't satisfiy the request in place. Any ideas what to do about that? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 5

What do you guys make of this?
by Greg Turner 03 Oct '02

03 Oct '02

I'm trying to run StarTeam Client, which used to work as recently as earlier this month. Nowadays, I get infinite recursion in the exception handlers, caused by various NULL pointer deferences within dlls/msvcrt/cppexcept.c. Any ideas? Looks like stack corruption to me... Here's some +seh output: trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f17f0 trace:seh:EXC_RtlRaiseException info[2]=41108f80 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f1750 frame 0x406f186c trylevel 0 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108f68 0: flags 1 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:call_catch_block matched type 0x41108f48 in tryblock 1 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411075e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x41108c98 for type 0x41108f48 addr 0x410fbb36 ebp 0x406f1878 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=406f0e6c trace:seh:EXC_RtlRaiseException info[2]=41108df8 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=1 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f186c trylevel 1 descr 0x41108c20 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x41108c40 4 0: prev -1 func (nil) 1: prev -1 func (nil) 2: prev 1 func (nil) 3: prev 1 func (nil) try table: 0x41108c60 2 0: start 2 end 2 catchlevel 3 catch 0x41108c88 1 0: flags 0 offset -28 handler 0x410fbb63 type 0x4110d3e0 ((nil) .PAVCException@@) 1: start 0 end 0 catchlevel 3 catch 0x41108c98 2 0: flags 0 offset -24 handler 0x410fbb36 type 0x4110d400 ((nil) .PAVCStCommandExceptionDetected@@) 1: flags 0 offset 0 handler 0x410fbb52 type (nil) trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:cxx_frame_handler handling C++ exception rec 0x406f0dd4 frame 0x406f19ac trylevel 1 descr 0x410d43f8 exception type: flags 0 destr (nil) handler (nil) type info 0x41108de0 0: flags 1 type 0x4110d478 ((nil) .PAVCStBaseServerException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 1: flags 1 type 0x4110d458 ((nil) .PAVCStException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 2: flags 1 type 0x4110d3e0 ((nil) .PAVCException@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 3: flags 1 type 0x4110d440 ((nil) .PAVCObject@@) offset 0 vbase -1,0 size 4 copy ctor (nil) 4: flags 1 type 0x4110d430 ((nil) .PAX) offset 0 vbase -1,0 size 4 copy ctor (nil) function descr: magic 19930520 unwind table: 0x410d4418 7 0: prev -1 func (nil) 1: prev 0 func (nil) 2: prev 1 func 0x410ceabd 3: prev 2 func 0x410ceac6 4: prev 3 func 0x410ceacf 5: prev 0 func (nil) 6: prev -1 func (nil) try table: 0x410d4450 2 0: start 1 end 4 catchlevel 5 catch 0x410d4478 2 0: flags 0 offset -80 handler 0x410abe43 type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abe6d type (nil) 1: start 0 end 5 catchlevel 6 catch 0x410d4498 2 0: flags 0 offset -84 handler 0x410abe9c type 0x410de070 ((nil) .PAVCException@@) 1: flags 0 offset 0 handler 0x410abeb9 type (nil) trace:seh:call_catch_block matched type 0x41108d80 in tryblock 0 catchblock 0 trace:seh:EXC_RtlUnwind code=e06d7363 flags=3 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074e6 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x411074b4 code=e06d7363 flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:call_catch_block calling catch block 0x410d4478 for type 0x41108d80 addr 0x410abe43 ebp 0x406f19b8 trace:seh:EXC_RtlRaiseException code=e06d7363 flags=1 addr=0x401060f4 trace:seh:EXC_RtlRaiseException info[0]=19930520 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException info[2]=00000000 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=e06d7363 flags=1 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e9a3 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000008 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405e09d8 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 trace:seh:cxx_frame_handler handling C++ exception rec 0x405dfe98 frame 0x406f19ac trylevel 5 descr 0x410d43f8 exception type: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x40f3e1f5 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=0000000c trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x4010c310 code=c0000005 flags=10 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at 0x410ceadd code=c0000005 flags=10 . . . and so on, forever. The experience in a debugger is that the exception type becomes NULL and is passed around like that until it gets deferenced. Then all hell breaks loose. I don't understand where __wine_call_from_32_regs lives in the source, and lose track of what's going on in there, thwarting my debugging efforts. -- gmt "If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or your arms. Crouch down and lick the hands, which feed you. May your chains set lightly upon you, and may posterity forget that ye were our countrymen." -Samuel Adams

2 3

spec files and handles
by steve.lustbader＠philips.com 03 Oct '02

03 Oct '02

With functions that take HANDLEs as arguments, what should that argument be listed as in the spec file? I thought HANDLEs were void *'s, so ptr would seem right. I found a function (DebugBreakProcess in kernel32.spec) that takes a HANDLE and has that listed as long in the spec. So which should it be - ptr or long? -Steve

2 1

Re: RPC merge (PL0)
by Ove Kaaven 03 Oct '02

03 Oct '02

On Wed, 2 Oct 2002, Greg Turner wrote: > OK, here's a first chunk of Jürgen Schmied's RPC patches. > > This is roughly equivalent to the stuff I posted recently, just > not my code anymore (which is a good thing 'cause my code > had some bugs). Some very minor changes may exist between this > and the original patch but it's intended to be basically > the same stuff. > > LICENSE: > "OK to put it into Wine" Is it OK for you if it gets into ReWind too? Then just say X11, otherwise say LGPL. > just a thought: > are statics guaranteed to be zero'ed out, as this code > seems to assume? Yes, uninitialized static and global variables are allocated in the .bss section, which is always explicitly zeroed on load. You could make it an initialized variable if you don't feel comfortable with it, though (something like static UUID uuid_nil = {0};), which will allocate it in the .data section instead, so the initial value will be embedded in the compiled binaries.

1 0

Re: Patch - Makefile.in shell32
by Alexandre Julliard 02 Oct '02

02 Oct '02

Steven Edwards <Steven_Ed4153(a)yahoo.com> writes: > Changelog: Dont include win16 shell support when building without > win16. (Untested under *NIX) It doesn't link with --disable-win16: iconcache.o: In function `ExtractAssociatedIconA': /home/julliard/wine/wine/dlls/shell32/iconcache.c:465: undefined reference to `ExtractAssociatedIcon16' shell32_main.o: In function `ExtractIconA': /home/julliard/wine/wine/dlls/shell32/shell32_main.c:526: undefined reference to `InternalExtractIcon16' -- Alexandre Julliard julliard(a)winehq.com

1 0

cursor:create_cursor ?
by Nick 02 Oct '02

02 Oct '02

Hi, fixme:cursor:create_cursor Currently no support for cursors with 10 bits per pixel and similar messages are (seemingly) the only things preventing Heroes of Might and Magic 2 from being fully playable. Is this function really uncommonly used or something? It looks so basic... Just wondering, Nick

2 1

RE: winaspi+libscg
by Patrik Stridvall 02 Oct '02

02 Oct '02

> Szombathelyi György <gyurco(a)freemail.hu> writes: > > > And how about a configure option to enable it? Default > option would be only > > the platform specific code, but a user can enable libscg > with a compile time > > option, and will receive a warning message about the license. Is it > > acceptable? If it is, I will make a patch. > > I don't think that would necessarily solve the issue. Some would argue > that the source itself is a derivative work that has to be under the > GPL. But the SOURCE is already under the LGPL which is compatible with the GPL so it doesn't matter if some part (whatever part) of the source might be required to be under the GPL. BINARIES might be required to be GPL:ed if and ONLY IF you enable the option. So it not really a problem for Wine AFAICS. > I don't want to debate the merits of that legal theory, Yes, we have debated this before. I know what you are going to answer, and you probably know what I'm going to say in return, so let us save the time and don't bother. :-) > but I > think it's better to avoid the issue completely. SIGH. As you wish.

1 0

Re: winaspi+libscg
by Alexandre Julliard 02 Oct '02

02 Oct '02

Szombathelyi György <gyurco(a)freemail.hu> writes: > Here's my winaspi patches that uses libscg for the scsi transport layer. It > statically links libscg, which is the part of the cdrtools package (all > distribution have it). As far as I can tell libscg is under the GPL, not the LGPL. So we cannot use it in Wine. -- Alexandre Julliard julliard(a)winehq.com

2 2

Wine installation troubles on Solaris
by Juraj Hercek 02 Oct '02

02 Oct '02

Hi, We have problem installing wine on solaris running on sparc. After some troubles we were able to compile and then partially install wine. Partially because, _$(WINE_ROOT)/tools/wineinstall_ script uses winelib's _regedit_ to register some entries in wine registry. But _regedit_ crashes. Here goes part of the output from _wineinstall_ script which tries to run _regedit_: ===========BEGIN OUTPUT=========== ... Created /home/user/.wine/config using default Wine configuration. You probably want to review the file, though. Compiling regedit... make: Nothing to be done for `all'. Preparing to install default Wine registry entries... Installing default Wine registry entries... err:heap:HEAP_GetPtr Invalid heap 00000000! Registry install failed. ===========END OUTPUT=========== Running wine alone (just to get help output) ends up in the same way - heap crash. Running "wine --debugmsg", the same... We used binutils-2.11.2 and gcc-2.95.3-toolchain for build process. Some information you could be interested in: ===========BEGIN OUTPUT=========== user% uname -a SunOS spruce.company 5.8 Generic_111433-02 sun4u sparc SUNW,Sun-Blade-1000 user% ldd miscemu/wine libntdll.dll.so => /usr/local/lib/libntdll.dll.so libwine.so => /usr/local/lib/libwine.so libwine_unicode.so => /usr/local/lib/libwine_unicode.so libresolv.so.2 => /usr/lib/libresolv.so.2 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 ===========END OUTPUT=========== My questions are: 1) Do you know the reason of the crash? (If so, please explain.) 2) Do you have any idea how to solve this problem? (If so, please explain) I'm asking because I'd like to avoid debugging... Thanks for reply! Juraj Hercek

1 0

[Fwd: [BUGZILLA] Security Advisory]
by Shachar Shemesh 02 Oct '02

02 Oct '02

Who is maintaining our Bugzilla system? Shachar

2 1

VB app broke again
by Fabian Cenedese 02 Oct '02

02 Oct '02

Hi I recently had a problem with a simple VB app, available as project and exe: http://www.winehq.com/hypermail/wine-devel/2002/09/0627.html I tried again with today's cvs and now the app doesn't even start. There is just an error "not enough memory" and the program quits again. So some recent changes must have broken something. bye Fabi

1 0

Re: some rpcrt4 stuff
by Ove Kaaven 02 Oct '02

02 Oct '02

On Tue, 1 Oct 2002, Greg Turner wrote: > > CHANGELOG: > > * dlls/rpcrt4/rpcrt4.spec: Greg Turner <gmturner007(a)ameritech.net> > - flesh out some stubs. Implementations of these and much more can be found in this patch submission, which was apparently never applied: http://www.winehq.com/hypermail/wine-patches/2002/06/0103.html You can probably try to extract what you need from that patch if you want more rpcrt4 stuff.

1 0

wine ToDo's Final
by Thomas Wickline 01 Oct '02

01 Oct '02

Hello, Here is the ToDo's to put on the status page. If anyone is aware of something that is wrong or out of place please let me know .. If everything looks good I will call it Final.......... Tom Wine ToDo's as of 10/01/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * Make sure ASCII functions call the Unicode one and not the other way around. * BiDi support * Add support for Hebrew and Arabic * Add support for more keyboard layouts to x11drv * Figure out what should be done for better support of Chinese, Korean, Japanese Winsock: * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec. DirectSound: * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Sound drivers: * Alsa driver (on final 0.9 interface) Video: * Implement native codecs (RLE...) GDI: * Write a DIB engine * DIB engine to do 32-bit graphics manipulation GDB: * Add the MSC/PDB info support to gdb Winedbg: * Speed up PDB support DDE: * Enhance memory management issues (interprocess sending) Wineconsole: * Add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) Native programs: * Winhelp: fix invocation thru WinHelp * Winedbg: make winedbg use dbghelp DLL File management: * Implement NT file namespace * UNC support * Allow flexibility in FS "mounting" (for example, SMB shares) Fonts: * Support for non-TT fonts (eg Type1, bitmap, ...) * Support for client side rendering on non-RENDER enabled XServers * Subpixel rendering - a.k.a. ClearType. * Integration with libfontconfig * Reduce per font startup time. * Libfontconfig support Printers: * Write a printer configuation applet * Fix the Type1 font downloader for HP4000 printers Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Create replacement of browser component (Internet Explorer/I Porting issues for Mingw/Cygwin/MS_VC * Better seperation of win16/32 code. * Remove/rewite win16/9x api dependancy on newer code * Remove/rewrite wineisms from code * Rewrite/fix unixisms in most WINE dlls * Documentation fixes low priority items: * VxD support with dynamic loading Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

1 0

Re: winapi: new tool winapi_test for generating tests (again)
by Alexandre Julliard 01 Oct '02

01 Oct '02

Patrik Stridvall <ps(a)leissner.se> writes: > You have not applied it or replied. > > I would very must like an answer and > that you at the very least apply the > nocontroversial parts (winapi.*). Sorry, I have applied it now. The only change is that I don't think we should have multiple generated_xxx.c files for each dll, we should put all generated tests for a dll into the same file, so I have renamed the file to just generated.c. I'll let you change the corresponding winapi part. BTW as discussed recently, if you could please do diffs against /dev/null instead of attaching tar files, that would make it easier for me (and may prevent your patches from getting forgotten...) -- Alexandre Julliard julliard(a)winehq.com

1 0

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