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

Re: dos4gw stub exec failed

by Sylvain Petreolle

games demos: tomb raider grand theft auto absolute pinball a 64k demo called fukjobb, which works fine. comment : running dos4gw.exe itself hangs. it normally should return the usage message. --- Enrico Horn <EnricoHorn(a)t-online.de> a écrit : > On Tuesday 21 January 2003 22:32, Sylvain Petreolle wrote: > > please give me the name of the program, all dos4gw programs I have > > tried before just hang. > > > the message is from the game Callahans Crosstime Saloon, an old > Legend > adventure. It happens when I try to run the setsound.exe that comes > with the > game but the main game exe (ccs.exe) shows the same error so i guess > the > behaviour is similar. > I have also installed other legend adventures that all exhibit the > same > behaviour. > which have you tried that just hang? > > Ciao > Enrico > farmboy1(a)subdimension.com > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 23, 2003

Re: more HEAP_strdupAtoW removals.

by Dmitry Timoshkov

"Matthew Davison" <m.davison(a)virgin.net> wrote: > Changelog > Remove some more calls to HEAP_strdupWtoA First of all, thanks for doing this! > @@ -554,7 +555,11 @@ > lpwstr = NULL; > for(i=0; i<dwNumServiceArgs; i++) > - lpwstr[i]=HEAP_strdupAtoW(GetProcessHeap(), 0, lpServiceArgVectors[i]); > + { > + RtlCreateUnicodeStringFromAsciiz (&usBuffer,lpServiceArgVectors[i]); > + lpwstr[i]=usBuffer.Buffer; > + RtlFreeUnicodeString(&usBuffer); > + } Of course this is a typo and last RtlFreeUnicodeString should be removed. > @@ -760,24 +774,26 @@ > BOOL WINAPI OpenPrinterA(LPSTR lpPrinterName,HANDLE *phPrinter, > LPPRINTER_DEFAULTSA pDefault) > { > - LPWSTR lpPrinterNameW = HEAP_strdupAtoW(GetProcessHeap(),0,lpPrinterName); > + UNICODE_STRING lpPrinterNameW; > + UNICODE_STRING usBuffer; > + RtlCreateUnicodeStringFromAsciiz(&lpPrinterNameW,lpPrinterName); > PRINTER_DEFAULTSW DefaultW, *pDefaultW = NULL; > BOOL ret; Are you sure that mixed data declarations/function call will be accepted by any C compiler out there? I doubt that even gcc will accept this. -- Dmitry.

Jan. 23, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Duane Clark

Mike Hearn wrote: > Could you explain this to me please? I tried Kaleidograph and started > looking at why the "Demo version only" dialog that pops up at the > beginning wasn't blanking the background properly, which I decided was > because the app didn't call BeginPaint but I am very much a novice. > > So, if you could explain how you tracked down these bugs I'd very much > appreciate it! I ran the app under WinNT and Wine, and compared the messages generated using SPY++. There are non-client (border) and background fill messages missing. So then it becomes a matter of figuring out where they should be generated. Otherwise in the case of Kaleidagraph, there is an additional problem where GetMenuItemInfoA is called with invalid parameters, causing crashes. I temporarily hacked around that, and KGraph then seems to work quite well for me (though I did not test extensively). It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later.

Jan. 23, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Duane Clark

Rick Romero wrote: > > If Dan's app behaves the same as mine, I can create a prog that > displays a window :) > > FWIW, Transgaming's current CVS WILL display the text correctly, but > what appeared to be an MDI window is actually created unmanaged (with > windows decorations). If anything, that's one way to test and see if > you get your text.. Please do send me a test app. I plan on going after several painting bugs for the next few weekends.

Jan. 23, 2003

stupidity: a slighlty less horrible wine tree diff gizmo

by Greg Turner

Still up to the same old stupid bash tricks... but implemented slightly better. This will still have to be manually maintained to remain useful as wine's directory structure evolves, just like the old "version" of this awfulness. Use at your own (very real) risk as these are almost untested. License is bugroff. This version has better provisions for in-source compilation, runs in only one pass, and is cwd/location independant. It should also be a lot easier to maintain than the previous try winetreediff_excl (a text file listing shell-glob patterns to ignore): >> CVS *.o *.a *.s Makefile *.spec.c *.dll.dbg.c *.exe.dbg.c *.drv.dbg.c *.acm.dbg.c *.ocx.dbg.c *.so *.def *.glue.c *.ok *.mc.rc testlist.c aclocal.m4 *.res gmtdir Makeprog.rules Make.rules *.swp config.log config.status lex.yy.c y.tab.c y.tab.h *.so.?.? wineclipsrv doall doconfig wine.man autom4te.cache mydiffs gmt-cfg-vars Makedll.rules Maketest.rules tags delme.diff delme2.diff wine.texinfo <<EOF winetreediff (a script to filter out impossible-to-glob patterns and perform the real processing. Note the hard-coded path to winetreediff_excl. Change it to match where you put it. Needs the x bit, of course.) >> #!/bin/sh noslash=$( echo "$1" | sed s/\\/$// ) noslashquot=$( echo "$noslash" | sed s/\\//\\\\\\//g | sed s/\\./\\\\\\./g ) # echo "noslash=$noslash noslashquot=$noslashquot" rm -f delme.diff delme2.diff touch delme.diff delme2.diff diff -ur --minimal --exclude-from=/home/greg/bin/winetreediff_excl $noslash . | \ grep -v '^Only in.*wine$' | \ grep -v '^Only in .*dlls/rpcrt4/tests\: stringinput_server$' | \ grep -v '^Only in .*include\: config.h$' | \ grep -v '^Only in .*programs/avitools\: aviinfo$' | \ grep -v '^Only in .*programs/avitools\: aviplay$' | \ grep -v '^Only in .*programs/avitools\: icinfo$' | \ grep -v '^Only in .*programs/clock\: clock$' | \ grep -v '^Only in .*programs/cmdlgtst\: cmdlgtst$' | \ grep -v '^Only in .*programs/control\: control$' | \ grep -v '^Only in .*programs/expand\: expand$' | \ grep -v '^Only in .*programs/notepad\: notepad$' | \ grep -v '^Only in .*programs/osversioncheck\: osversioncheck$' | \ grep -v '^Only in .*programs/progman\: progman$' | \ grep -v '^Only in .*programs/regapi\: regapi$' | \ grep -v '^Only in .*programs/regedit\: regedit$' | \ grep -v '^Only in .*programs/regsvr32\: regsvr32$' | \ grep -v '^Only in .*programs/regtest\: regtest$' | \ grep -v '^Only in .*programs/rpcss\: rpcss$' | \ grep -v '^Only in .*programs/rundll32\: rundll32$' | \ grep -v '^Only in .*programs/uninstaller\: uninstaller$' | \ grep -v '^Only in .*programs/view\: view$' | \ grep -v '^Only in .*programs/wcmd\: wcmd$' | \ grep -v '^Only in .*programs\: wineapploader$' | \ grep -v '^Only in .*programs/wineboot\: wineboot$' | \ grep -v '^Only in .*programs/wineconsole\: wineconsole$' | \ grep -v '^Only in .*programs/winedbg\: winedbg$' | \ grep -v '^Only in .*programs/winefile\: winefile$' | \ grep -v '^Only in .*programs\: winelauncher$' | \ grep -v '^Only in .*programs/winemine\: winemine$' | \ grep -v '^Only in .*programs/winepath\: winepath$' | \ grep -v '^Only in .*programs/winhelp\: hlp2sgml$' | \ grep -v '^Only in .*programs/winhelp\: winhelp$' | \ grep -v '^Only in .*programs/winver\: winver$' | \ grep -v '^Only in .*server\: wineserver$' | \ grep -v '^Only in .*stringinput_server\: stringinput_server$' | \ grep -v '^Only in .*tools\: bin2res$' | \ grep -v '^Only in .*tools\: fnt2bdf$' | \ grep -v '^Only in .*tools\: makedep$' | \ grep -v '^Only in .*tools\: mingwrap$' | \ grep -v '^Only in .*tools/widl\: widl$' | \ grep -v '^Only in .*tools/winebuild\: winebuild$' | \ grep -v '^Only in .*tools/winebuild\: winebuild.man$' | \ grep -v '^Only in .*tools/winedump\: winedump$' | \ grep -v '^Only in .*tools\: winegcc$' | \ grep -v '^Only in .*tools\: winewrap$' | \ grep -v '^Only in .*tools/wmc\: wmc$' | \ grep -v '^Only in .*tools/wrc\: wrc$' | \ ( tee delme.diff | grep -v '^Only in .*\:' ) cat delme.diff | \ grep '^Only in .*\:' | \ sed s/^Only\ in\ // | \ sed s/\:\ /\\// | \ ( tee delme2.diff | grep "^\.\/" ) | \ sed "s/^\.\//diff\ -u\ \/dev\/null\ \.\//" | \ sed "s/$/;/" | \ bash -C - cat delme2.diff | \ grep -v "^\.\/" | \ sed "s/^$noslashquot\//diff\ -u\ \.\//" | \ sed "s/$/\ \/dev\/null;/" | \ ( cd $noslash && bash -C - ) rm -f delme.diff delme2.diff <<EOF still hardly a work of art. but ought to generate diffs between trees ready for submission to wine-devel, no cvs needed. For example, I use this as follows to update my horribly out-of-sync wine tree with the latest changes from cvs: .../wine> cd ../wine.test .../wine.test> winetreediff ../wine.vanilla | wc -l 0 .../wine> # great, these trees are identical w.r.t. winetreediff. .../wine> cd ../wine.vanilla .../wine.vanilla> cvs -qz4 up -dPA [cvs does something] .../wine.vanilla> # generate the difference between "../wine.test" and "." .../wine.vanilla> winetreediff ../wine.test > ../wine/mydiffs/cvsupdate.diff .../wine.vanilla> cd ../wine.test .../wine.test> patch -p0 < ../wine/mydiffs/cvsupdate.diff [ goes fine ] .../wine.test> cd ../wine Now I have a nice diff expressing the difference caused by the CVS update. If I am concerned about it, I could run .../wine> patch -p0 --dry-run < mydiffs/cvsupdate.diff To see what the damage will be, otherwise, just .../wine> patch -p0 < mydiffs/cvsupdate.diff would bring me up-to-date. LIMITATIONS: o Dangerous if used incautiously. o Breaks if wine changes. o Probably Buggy. o Only supports "." and "/" characters in directory argument. o Creates and destroys temp files named delme.diff and delme2.diff. (Should at least use something more obscure.) o Prefers (requires?) a matching directory structure between the two trees. -- gmt

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Dan Kegel

Christian Costa wrote: >>> I think, It would be cool to have all locks named and thus make >>> debugging and bug report easier. >>> It's not a hard task but names must be meaningfull. :-) >> >> I guess you mean all Wine locks should be named > > Yes! :-) >>... >> Naming the Wine locks would be nice (or is it done already?). > > No, it isn't. All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime. To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter. >> But more >> than meaningful names, what we would need are grep-able names :-) >> > What do you mean with grep-able ? Ones that are easy to search for, e.g. that contain the source filename. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 22, 2003

Re: Games Swat 3d

by Greg Turner

> >> >I am wondering if Swat3d will be added to the list anytime soon > >> > for use with wine ?? > >> what do you mean by "added to the list" ? > >Presumably, added to the list of programs that work ;) > It's what i have thought first, > but "will be added ... for use ..." sound like "will be added to the > priority list" for me :) > >Swat3d is a great game, and one that I happen to own. Haven't tried > > it in wine for a while, maybe I'll give it a try after work today. > :) > can you report the current working state of the game under wine Dx > after ? As d3d<8 not support multi-texturing yet, i think you should > have some graphics problems OK, I gave this a whorl. It went surprisingly well. The installer, and all the upgrades up to 2.1 (except maybe the mission pack) seem to go fine. As for the game itself, no dice, it uses safedisc. But, I found a no-cd at gamecopyworld ;) After swapping in their exe, it gets pretty far, but still no dice. It behaves something like Rogue Spear: xvidmode changes, it complains about some BitBlt stuff, and "locks up" silently without a crash. With native devenum (thanks to the familiar DllGetClassObject unimplemented in that dll), it even starts to play the intro music (via winealsa, my audio is kind of screwed up ATM). It's having trouble with the intel codec dlls, but, nevertheless, I get the feeling that it's a lot closer to actually showing me something than it was the last time I tried this game under wine. According to Transgaming's website, it runs better under winex, but still exhibits some problems. Great game, I hope it improves. I wouldn't mind debugging this, I really like this game a lot.... but I have a lot of wine stuff going on right now, might not be the best moment to take on yet another pet project. I guess it goes on my "fun" queue, which gets processed in times of boredom :) I am a little concerned that once wine starts running my favorite games well I am going to have a hard time getting work done :) -- gmt

Jan. 22, 2003

Re: RtlpWaitForCriticalSection?

by Christian Costa

Francois Gouget wrote: >On Wed, 22 Jan 2003, Christian Costa wrote: >[...] > >>>err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed >>>out, retrying (60 sec) tid=08436988 >>> >[...] > >>I think, It would be cool to have all locks named and thus make >>debugging and bug report easier. >>It's not a hard task but names must be meaningfull. :-) >> > >I guess you mean all Wine locks should be named > Yes! :-) >(I'm not sure it would >be good to give a name to unnamed application locks). > Of course not. > > >Naming the Wine locks would be nice (or is it done already?). > No, it isn't. >But more >than meaningful names, what we would need are grep-able names :-) > What do you mean with grep-able ? Christian

Jan. 22, 2003

Re: Installshield 6 crash: ole trouble

by Dan Kegel

Marcus Meissner wrote: >>>>IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real >>>>windows to wine's system directory. > > I will add a large message suggesting that. Thanks. (I'm also looking forward to the possibility of wine having its own stdole32.tlb soon.) >>It looks like there's a Heisenbug here. If I run without >>logging, I get a window titled "Unhandled Exception", >>with contents >>"Error Number: 0x80040706 >>Description: Object reference not set >>Setup will now terminate." > > > I have seen this on and off, but I thought I fixed it. Interestingly, under wine20020605, I am able to complete the installation program. Thus we seem to have a regression. Which would be more helpful: me tracking down which patch caused the regression, or me sending some more knowledgeable person a minimal test case? Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 22, 2003

Re: RtlpWaitForCriticalSection?

by Francois Gouget

On Wed, 22 Jan 2003, Christian Costa wrote: [...] > >err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed > >out, retrying (60 sec) tid=08436988 [...] > I think, It would be cool to have all locks named and thus make > debugging and bug report easier. > It's not a hard task but names must be meaningfull. :-) I guess you mean all Wine locks should be named (I'm not sure it would be good to give a name to unnamed application locks). Naming the Wine locks would be nice (or is it done already?). But more than meaningful names, what we would need are grep-able names :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Jan. 22, 2003