December 2003 - Wine-devel - list.winehq.org

Question about simple profiling implementation
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, the last thing I have to do with the profiling stuff is the trickiest: To decide what is the best way to determine the times. To get times that are useful, I'm using the RDTSC opcode (which returns the number of CPU clock cycles since the machine was powered on).. basically I've added a couple of defines to wine/debug.h: #define GET_COUNTER(__COUNTER) __asm__ __volatile__ ( "rdtsc" : "=a" (__COUNTER.LowPart), "=d" (__COUNTER.HighPart) ) and theres another, GET_ELAPSED which takes a start time, and calculates the difference. (BTW: I don't think these names are very good; I'm going to change them) The elapsed value is output when the relay trace for the function return is printed. I've also created a new script to analyse these to give you the average times, total times etc, and I've fixed tools/examine-relay to cope with the addition to the trace output. The problem is.. not all i386-derived CPUs support this feature. As far as I can see there are three ways of determining this. Which would people prefer? 1) Check in /proc/cpuinfo for the "tsc" flag. 2) I could write a short amount of assembly to interrogate the chip itself for this feature (a couple of instructions) 3) Use the existing QueryPerformanceCounter(). Personally, I'm favouring (2)... but what do other people think?

6 12

Re: debugger problems
by Chris Morgan 03 Dec '03

03 Dec '03

Nope, still doesn't appear to work. Rein, you see the same? Chris On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > Chris Morgan wrote: > > Still isn't working with build from todays cvs. Is this patch in there? > > it seems that AJ applied it after your mail had been sent > A+

5 10

Re: bc21en209 at Odin
by Dietrich Teickner 03 Dec '03

03 Dec '03

Hi Craig, The best way is for the future the first, removing '\\?\' in Odin and Wine. This way will need some times in odin, we are not prepaired for this, And I have no update access for wine. I will try to inform wine about the problem. I thing You have implemented this methods and You modify this without full forthing w98-api. This can us help for this build. We can test BC2.1 and can work with them as w2k(without , and we can also test the new api modifications. The switch should only force the w98 behavior in the path handling. For 'all', Odin and Wine can set the configuration-file. And Wine and Odin should work in the next time at the \\?\ problem. Please save also the last BC2.0 Build. Dietrich Scooter Support wrote: > Hi Dietrich, > > That would definitely cause problems in BC. We detect the Windows > version on startup and when running under WinNT4/2K/XP we use the \\?\ > notation for all file access, including sessions and rules. Under > Win9x we use the standard ANSI functions. > > In our current usage it wouldn't be a problem if ODIN simply removed > the \\?\ prefix and converted the paths back to ANSI. If it would be > easier I can add a command line switch to force BC to use the Win9x > behavior. > > Best Regards, > Craig > > > >>Hi Craig, > > >>I know where the problenm is in the comunication between BC21 and Odin. >>BC21 used only the long path notation for the filenames if the version >>set in Odin (Wine ?) as w2k or xp. If I set Win98 (nt4.0?), I have no >>problems with accessing folders. >>Currently is the \\?\h:\... notation only partialy supported in >>Odin (for eCS or OS/2) and in >>wine (for Linux). > > >>Start in native w98 ok, >>also in my xp >>Also in w98 in virtual PC. > > >>Can it be that many problems comes from the \\?\ prefix ? >>Also no access to the session database ? > > >>Best regards, >>Dietrich > > >>Log as w2k > > >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win2000' >>t01 ( 0): (FS=150B) version 5.0 >>t01 ( 0): (FS=150B) build nr 893 >>t01 ( 0): (FS=150B) Platform Id 2 >>t01 ( 0): (FS=150B) szCSDVersion Service Pack 2 >>... >>t02 ( 0): attachThread to dll NTDLL.DLL >>t02 ( 0): attachThread to dll NTDLL.DLL DONE >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003f1b8 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesW 3016994 >>t02 ( 1): KERNEL32: SetLastError to 123 >>t02 ( 1): KERNEL32: GetFileAttributes of \\?\h:\ returned -1 >>t02 ( 0): KERNEL32: GetFileAttributesW returned ffffffff >>t02 ( 0): KERNEL32: GetLastError returned 123 >>t02 ( 0): KERNEL32: SetLastError to 123 >>t02 ( 0): KERNEL32: RaiseException eedfade 1 7 327fd80 >>t02 ( 1): KERNEL32: RaiseException(0eedfadeh) >>t02 ( 1): KERNEL32: RtlDispatchException entered >>t02 ( 1): Win32 exception chain: > > >>Log as w98 > > >>t01 ( 0): (FS=150B) KERNEL32: SetEnvironmentVariable HOMEPATH to \ >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win98' >>t01 ( 0): (FS=150B) version 4.a >>t01 ( 0): (FS=150B) build nr 40a07ce >>t01 ( 0): (FS=150B) Platform Id 1 >>t01 ( 0): (FS=150B) szCSDVersion Win98 > > >>.. > > >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003ea14 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesA 2003e9f4 >>t02 ( 1): KERNEL32: GetFileAttributes of h:\ returned 16 >>t02 ( 0): KERNEL32: GetFileAttributesA returned 10 >>t02 ( 0): KERNEL32: SetErrorMode 1 >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) >>t02 ( 0): KERNEL32: SetErrorMode returned 0 >>t02 ( 0): KERNEL32: GetVolumeInformationA 2003ea24 329fc8b 104 2003ea3c >>2003ea40 2003ea44 329fb86 104 >>t02 ( 1): GetVolumeInformationA h:\ >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) > > >

1 0

I found what I believe is a bug in include/wine/prsht.h in ReactOS
by Jonathan Wilson 03 Dec '03

03 Dec '03

cc-ing WINE list in case its also present in the WINEHQ CVS this line: typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW; If this is a bug, can someone fix it? If its not, can someone explain why this construct is present (it looks very wierd to mix an A structure and a W structure in this typedef)

4 5

Re: winetest: the Wine test shell
by Ferenc Wagner 03 Dec '03

03 Dec '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- removed the CROSS compilation support. It should work > with a different build tree, but I haven't tested that Works just fine, thanks! Interestingly, yesterday evening I got all kinds of problems, like the build process trying to run WINDRES=false in the elf tree and other silly things. :) > -- removed striping the tests from the build. This wasn't > right for multiple reasons: > * it was using a hardcoded 'strip' command instead > of the configure one What about the following in maketest(s? cf. 8.3) STRIP="$3" DLLEXT="$4" [...] filename="$BINDIR/${test}_test.exe$DLLEXT" [...] $STRIP -s $filename and in Makefile.in (cf. tests.list vs 8.3 again): winetest.rc: maketest tests.list $(SRCDIR)/maketest -r $(SRCDIR)/tests.list "$(STRIP)" "$(DLLEXT)" > $@ || ( $(RM) $@ && exit 1 ) > * it seems strange that building winetest should > magically affect all the tests Maybe. But nothing depends on those, so I can't see it cause problems. And stripping reduces the final size of the program by an order of magnitude! It counts on a not-so-wide download link. > * why should we strip every time Stripping stripped programs doesn't take much time or effort. > Maybe we should replace this with an explicit > make strip-tests > or some such. Suggestins are welcome. Another possibility is to $STRIP -s -o ${testname}_test.exe$DLLEXT $filename It's sterile, but I'm not sure if it's better. > But I think it looks decent enough that it can go in, so we > can start sending small incremental patches to it. Shall not we put copyright notices into the files? > + if (remove (logname)) > + fatal (strmake (NULL, "Can't remove logfile: %d.", errno)); Maybe a warning would be enough here, too... :) Not that it makes any difference, of course. Best wishes, Feri.

1 0

Re: [clock04] Tidy up resources
by Alexandre Julliard 03 Dec '03

03 Dec '03

Richard Cohen <richard(a)daijobu.co.uk> writes: > Alexandre Julliard wrote: > > Your mailer has corrupted the 8-bit chars, could you please resend >> differently? > > Hmm, .. mozilla sent it as text/plain,8-bit,inline > Looks fine to me, and I can save and apply the patch OK. You are right, the problem was on my side; looks like a recent update had broken my sendmail config. My apologies to your mailer <g> -- Alexandre Julliard julliard(a)winehq.com

1 0

IDA speed problem analysis
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, I've been doing some more work on this, and I think I've found the culprit (my apologies to everyone for the crap I've been talking recently). Whenever IDA opens the Save box.. and in fact when it does a lot of operations, it seems to completely regenerate its menus. It uses an MDI interface, and so uses the WM_MDISETMENU message to set menus. The problem function is controls/menu.c/SetMenu(). Specifically, the call to SetWindowPos() passing the SWP_FRAMECHANGED flag. If I comment this call out, IDA becomes very fast... as fast as is it in windows. If I add in Y copies of that call, IDA becomes about Y times slower. Looking at the docs on MSDN for WM_MDISETMENU, it says "After sending this message, an application must call the DrawMenuBar function to update the menu bar". Which implies that the application is in charge of telling the menu bar to redraw, meaning the call to SetWindowPos() is superfluous. However, SetMenu() is used non by MDI menus as well, which DO expect the menu to be updated automatically (MSDN: "The window is redrawn to reflect the menu change"), which means it can't just be removed. Does anyone have any suggestions for the cleanest way to resolve this? Perhaps MDI should have an internal copy of SetMenu() tailored to its needs? BTW, under windows, the MDI code does not call the USER32.SetMenu() function.

1 0

Re: WineX 3.2
by Ivan Leo Murray-Smith 03 Dec '03

03 Dec '03

My free RPMs can't hurt Transgaming. For a start, on my winex page, I have a complete list of the features that only the commercial version has, and an invitation to subscribe to Transgaming if you want those extra features. As the freeware version doesn't include installshield, lots of games won't even install with the freeware version, for a start max payne. Also, even if a game does work, it won't run full screen, so if a users has lots of games that work with the free version, but wants them to run full screen, he'll probably go to the transgaming store. For all these reasons, I don't think my free RPMs are a financial threat to Transgaming in any way. Transgaming has taken a lot from Wine (Well it wouldn't have much to sell without wine), and I don't think there is anything wrong if someone takes something back. I think Transgaming should worry about those web sites that distribute the full commercial version of WineX, you just have to look for winex 3.2 download free on google , I reported this to Transgaming many months ago, and they still haven't taken any action. Ivan.

2 1

64bit Wine?
by J. Grant 02 Dec '03

02 Dec '03

Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. Kind regards JG p.s. I'm not subscribed to this list from this email address, so please include my email address in any replies.

4 4

wine in the press
by Tom 02 Dec '03

02 Dec '03

http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom

2 1