July 2002 - Wine-Devel - list.winehq.org

Re: warcraft 3

by Rizsanyi Zsolt

On Friday 05 July 2002 01:53, Bobby Bingham wrote: > After buying Warcraft 3, and reading on the mailing list that the beta had > worked under wine, I decided to try the final version under wine. It > installed fine, but won't run. Or rather, when I try to run it, it prints > this out, and just sits there: > > fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 not > supported > fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 > not supported You have an scsi cdrom drive. My code works just with the ide cdrom drives. But this should not be a too big problem, unless the game uses SafeDisc copy protection. And even then it may be not so important. You can check if the cd is safedisk protected by looking for files: secdrv.sys drvmgt.dll clcd16.dll clcd32.dll clokspl.exe If they are present, you need safedisc protection working. You can try winex, or you can try to apply the safedisc patch to the winehq wine. If you are willing to test I can provide the patch, and try to make it work with scsi drives... If it is not safedisc protected, then you can simply ignore the above messages... > fixme:midi:OSS_MidiInit Synthesizer support MIDI in. Not > supported yet (please report) you can ignore this too > I don't know much about the various debug messages, but if I run it with > --debugmsg +relay, i see thousands upon thousands of lines like this: > > 0809c7f8:Call ntdll.dll.RtlEnterCriticalSection(403e0534) ret=40bf1e46 > 0809c7f8:Ret ntdll.dll.RtlEnterCriticalSection() retval=00000000 > ret=40bf1e46 > > over and over, with these occasionally interspersed: > > 0809c7f8:Call kernel32.dll.GetTickCount() ret=40bf2013 > 0809c7f8:Ret kernel32.dll.GetTickCount() retval=00001f07 ret=40bf2013 The above two type of messages in the relay trace are not important. You should filter them out. There are more ways to do it, but for me the easiest is to rember is this: grep -v RtlEnterCriticalSection wine.log > wine2.log And so on with all the animportant messages. That way maybe you (or somebody else), can see something more interesting... > now, how would one go about debugging this. It doesn't seem as convenient > as just crashing in one specific function and bringing up the debugger ... You did not write which version of wine you are using. That could be quite important... Regards Zsolt Rizsanyi

July 5, 2002

Re: Added support for APPMODE=<type>[:<mainFunc>]

by Alexandre Julliard

Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > - .spec files can't be compiled with -g when using Forte C. This causes static > variables to have a "random" prefix attached to their name, and prevents the > assembly code from linking to them correctly. > - Forte C has linker issues, so cui executables with main() conflicted with > main() in $WINELOADER. Renaming main() to main2() solved the issue, so I added > support to winebuild to allow the main function name to be optionally specified > in the makefile. I have applied the rest of the patch, but these are bugs that need to be fixed, not simply worked around. -- Alexandre Julliard julliard(a)winehq.com

July 5, 2002

warcraft 3

by Bobby Bingham

After buying Warcraft 3, and reading on the mailing list that the beta had worked under wine, I decided to try the final version under wine. It installed fine, but won't run. Or rather, when I try to run it, it prints this out, and just sits there: fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 not supported fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 not supported fixme:midi:OSS_MidiInit Synthesizer support MIDI in. Not supported yet (please report) I don't know much about the various debug messages, but if I run it with --debugmsg +relay, i see thousands upon thousands of lines like this: 0809c7f8:Call ntdll.dll.RtlEnterCriticalSection(403e0534) ret=40bf1e46 0809c7f8:Ret ntdll.dll.RtlEnterCriticalSection() retval=00000000 ret=40bf1e46 over and over, with these occasionally interspersed: 0809c7f8:Call kernel32.dll.GetTickCount() ret=40bf2013 0809c7f8:Ret kernel32.dll.GetTickCount() retval=00001f07 ret=40bf2013 now, how would one go about debugging this. It doesn't seem as convenient as just crashing in one specific function and bringing up the debugger ... Thanks, Bobby Bingham

July 4, 2002

Re: dlls/advapi32/registry.c patch for RegEnumValuesA

by Tony Lambregts

Max wrote: >Here a patch that corrects a nasty bug in dll/advapi32/registry.c, causing >AutoCAD R14 (and I guess other apps too...) to hang. > >Regards > >Max > > > >------------------------------------------------------------------------ > >--- dlls/advapi32/registry.c Sat Jul 6 01:29:08 2002 >+++ /home/massimo/wine-patches/registry.c Sat Jul 6 01:35:32 2002 >@@ -1157,6 +1157,9 @@ > RtlUnicodeToMultiByteSize( &len, info->Name, info->NameLength ); > if (len >= *val_count) > { >+ /* CHANGELOG : 04.07.2002 by Max >+ MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ > The comment is OK I suppose, but it is part of the change log. Change log entries should not be part of the patch itself. >+ *val_count = len + 1 ; > status = STATUS_BUFFER_OVERFLOW; > goto done; > } >@@ -1174,6 +1177,9 @@ > { > if (len > *count) > { >+ /* CHANGELOG : 04.07.2002 by Max >+ MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ > Same here. >+ *count = len+1 ; > status = STATUS_BUFFER_OVERFLOW; > goto done; > } > > Sorry to nitpick could you resubmit something like this ---- This is the first part. This is where you can say what you did, and say what you wanted to say, in as long and as rambling way as you want. It is for expaining whatever you wanted to expain, why you wanted to do it the way you wanted to do it section. next comes the change log . after that your name and contact. Change log: Change In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it did), and also return correct buffer size (now it does). Max max(a)veneto.co ----- attched patch

July 4, 2002

Re: MS' hidden API

by Tom Schutter

On 2002-07-03 10:59 Duane Clark wrote: > Vincent Béron wrote: >> Le mer 03/07/2002 à 11:39, Andreas Mohr a écrit : >> >>> On Wed, Jul 03, 2002 at 01:33:46AM +0300, P. Christeas wrote: >>> >>>> My view is that we should focus on professional apps, such as CAD, >>>> some multimedia etc. There is professionals that won't switch to >>>> Linux until some unique apps they use can run under Linux. Games >>>> are an issue, too. >>> >>> Very true. >>> IMHO AutoCAD is *very* important, as it's considered to be a >>> leading CAD >>> package, with no UNIX version, ever. >> >> >> Was a leading CAD package. It's still vastly used, but (in my >> experience) mostly to get access to old drawings. Newer stuff gets >> designed on SolidWorks, ProE, Catia, Mechanical Desktop and a couple >> others which do real 3D. > > Just barely on topic, hope people don't mind... > > So, any hints on which would be a good one to get? I am planning to > buy a mechanical CAD package, and would then attempt to fix any bugs > to get it running under wine. I have managed to do fairly well > getting my Xilinx FPGA software working (though getting the patches > committed has been a little harder), so I figure I would try a CAD > package, too. > > My needs are pretty simple, so I don't really want the high dollar > stuff, perhaps under $1K (the further under the better ;)? I would be > doing things like mechanical drawings for machining front panels and > brackets for electronic equipment (which I have done in Autocad in > the past). Try QCad. At $0, it is hard to beat. http://www.qcad.org -- Tom Schutter t.schutter(a)att.net

July 4, 2002

Re: Better fix for [bug 829] (same surface display corruption)

by Tony Lambregts

Lionel Ulmer wrote: >>I took Lionel's sugestions to heart and came up with a better fix for >>bug 829. This has a better check for defining when the corruption could >>occur and should be a little faster >> >> > >Well, I had not in mind exactly what you did. > > > >>+ SameSurfaceOK = (!((src == iface)&&(sbase < dbuf)&&(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right))); >> >> > >I do not really understand all the details of this check, so a comment would >be nice, but well, I think it is unneeded (see below). > Well I suppose a comment would be nice. The problem with this corruption is that it only occures when the following are true 1.) Both the source and destination are the same surface. -->(src == iface) 2.) The start of the source is less than the destination . -->(sbase < dbuf) 3.) There is overlap. -->(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right) If we were copying one pixle at a time then my soloution needs on more check and that is: 4.) Is the top of the source the same as the top of the destination. (xdst.top > xsrc.top) checking for this situation ...... Damb...! When I checked this out memcpy caused a problem, but memove does not! # 4.) is invalid. One more time this time with comments.... > > > >>+ if (SameSurfaceOK) { >>+ for (y = 0; y < dstheight; y++) { >>+ memcpy(dbuf, sbuf, width); >>+ sbuf += sdesc.u1.lPitch; >>+ dbuf += ddesc.u1.lPitch; >>+ } >>+ } else { >>+ >>+ sbuf += (sdesc.u1.lPitch*dstheight); >>+ dbuf += (ddesc.u1.lPitch*dstheight); >>+ >>+ for (y = 0; y < dstheight; y++) { >>+ sbuf -= sdesc.u1.lPitch; >>+ dbuf -= ddesc.u1.lPitch; >>+ memcpy(dbuf, sbuf, width); >>+ } >>+ } >>+ >> >> > >The problem I can see is that you use 'memcpy' even in the SameSurfaceNotOK >case. And this is bad as memcpy does NOT handle overlapping memory zones. >Moreover, you only have the 'descending' copy order in that case and not >both cases. > >What I had in mind in my comments to your patch was something like that : > > if (src != iface) > Do the standard memcpy code path > else > if source_Y > dest_Y > do the ascending memmove copy > else > do the descending memmove copy > I had it coded kinda that way for a while..... > >This way you did not hurt the common case (ie Blt from two different >surfaces). Now I agree that even in the same surface case, one could add >some checks to see if the rectangles overlap or not, but I do not know if it >would be worth the pain as memmove should not be THAT slower than memcpy. > > Lionel > > > I appreciate your comments. The reason I wanted the checks is that the same problems can occure with flags set. I therefore wanted to make sure that the fixme was only produced when those conditions were met. I believe that it would be unlikely for anyone to use the same surface if stretching is involved, so there is no fixme there.... This whole problem could be avoided if we were working with a copy of the source. This may be a better solution in the long run... By the way how did it it work out with FalloutTactics. Tony Lambregts

July 4, 2002

RegEnumValueA bugs and patch in dlls/advapi32/registry.c

by Max

Well, finally found and corrected a bug that made AutoCAD R14 hang... I guess some other apps could have the same problem solved, but had no time to test more :) In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it does), but also return correct buffer size (as it doesn't). Found in AutoCAD; it asked for a reistry key value, got error, and then looped forever trying to get val with wrong buffer size. I guess, but had no time yet to check, that this problem could happen somwhere else in Registry.c, I'll check it out next days. With this patch, finally AutoCAD R14 is perfectly usable in wine, even without a native windows installed ! Here the patch : --- dlls/advapi32/registry.c Sat Jul 6 01:29:08 2002 +++ /home/massimo/wine-patches/registry.c Sat Jul 6 01:35:32 2002 @@ -1157,6 +1157,9 @@ RtlUnicodeToMultiByteSize( &len, info->Name, info->NameLength ); if (len >= *val_count) { + /* CHANGELOG : 04.07.2002 by Max + MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *val_count = len + 1 ; status = STATUS_BUFFER_OVERFLOW; goto done; } @@ -1174,6 +1177,9 @@ { if (len > *count) { + /* CHANGELOG : 04.07.2002 by Max + MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *count = len+1 ; status = STATUS_BUFFER_OVERFLOW; goto done; } I'll just post it to wine-patches too. Regards Max

July 4, 2002

Re: Better fix for [bug 829] (same surface display corruption)

by Lionel Ulmer

> I took Lionel's sugestions to heart and came up with a better fix for > bug 829. This has a better check for defining when the corruption could > occur and should be a little faster Well, I had not in mind exactly what you did. > + SameSurfaceOK = (!((src == iface)&&(sbase < dbuf)&&(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right))); I do not really understand all the details of this check, so a comment would be nice, but well, I think it is unneeded (see below). > + if (SameSurfaceOK) { > + for (y = 0; y < dstheight; y++) { > + memcpy(dbuf, sbuf, width); > + sbuf += sdesc.u1.lPitch; > + dbuf += ddesc.u1.lPitch; > + } > + } else { > + > + sbuf += (sdesc.u1.lPitch*dstheight); > + dbuf += (ddesc.u1.lPitch*dstheight); > + > + for (y = 0; y < dstheight; y++) { > + sbuf -= sdesc.u1.lPitch; > + dbuf -= ddesc.u1.lPitch; > + memcpy(dbuf, sbuf, width); > + } > + } > + The problem I can see is that you use 'memcpy' even in the SameSurfaceNotOK case. And this is bad as memcpy does NOT handle overlapping memory zones. Moreover, you only have the 'descending' copy order in that case and not both cases. What I had in mind in my comments to your patch was something like that : if (src != iface) Do the standard memcpy code path else if source_Y > dest_Y do the ascending memmove copy else do the descending memmove copy This way you did not hurt the common case (ie Blt from two different surfaces). Now I agree that even in the same surface case, one could add some checks to see if the rectangles overlap or not, but I do not know if it would be worth the pain as memmove should not be THAT slower than memcpy. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 4, 2002

Re: Running half-life turns X display into garbage

by Serge Ryabchun

On Wed, 3 Jul 2002, Joshua Thielen wrote: > > > >Try "UseDGA"="no" in config or run HL without root rights. > > > This worked! Well, at least now I can get to the menu. But what is > wrong? Is there a bug in wine's use of DGA? I think it because HL's menu is usual window and usual controls with redefined draw methods. -- Serge Ryabchun sr(a)energy.uch.net

July 4, 2002

2 quick things on the Cygwin/Mingw port

by Steven Edwards

Hola 1. This is simple but as you guys know I have this lysdexic thing when it comes to configure. Libwine needs to import certain functions from the c library to compile, at present it is hard coded for -lmsvcrt. This needs to be changes to import -lcygwin if configure detects a cygwin host/target. I know its simple we just need to have the check in configure that sets CLIBRARY=(lmsvcrt or lcygwin) then Makefile.in in libwine needs to be changed like this: libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) -lmsvcrt to libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) $(CLIBRARY) 2. I was able to get Wineserver.exe to compile under cygwin when I stubbed getthreadcontext and setthreadcontext. Kernel32.dll implements these to functions so on the Mingw or Cygwin port can I import it for these needed functions? Thanks and have a good 4th Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

July 3, 2002