October 2005 - Wine-Devel - list.winehq.org

preload libGL
by Tomas Carnecky Oct. 23, 2005

Oct. 23, 2005

I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it. I've ended up doing this: glXSwapBuffersType preload__glXSwapBuffers = (glXSwapBuffersType) wine_dlsym(RTLD_DEFAULT, "glXSwapBuffers", NULL, 0); preload__glXSwapBuffers(gdi_display, physDev->drawable); but that is not a nice solution. What about linking x11drv directly with libGL? tom

3 11

Caching for X11DRV_SetImageBits?
by Michael Carlson Oct. 23, 2005

Oct. 23, 2005

Let me start off with an introduction. I'm a veteran C programmer, but I'm unfamiliar with programming X11 and unfamiliar with wine, although I've been looking into both recently to correct a problem I'm having with wine. I posted about the same problem in August on the same mailing list, about making function parameters const. This was a simplistic solution, but I suggested it simply because I didn't feel I had the time to familiarize myself with all the inner-workings of wine. Now, I believe I do have the time. To repeat the situation, I found that in several of the games I like to run, the same problem is causing wine to be slow: using oprofile, I find that nearly all of wine's CPU usage lies in x11drv, and 98-99% of the cpu usage in x11drv is taken up by calls to some of the convert functions in dib_convert.c. For example, in Civilization 3, some 98% of the CPU usage in x11drv is taken up by two functions: convert_555_to_565_asis, and convert_565_to_555_asis. This summer I had a similar problem on my laptop, where fce ultra was using the function convert_888_to_0888_asis for most of its cpu. Essentially, it seems that most of the work wine is doing when running these programs is just for converting between one pixel format and back, and I hope to find a good solution to this speed problem, preferably through caching. I'm writing to this list in hope of other more experienced wine hackers giving their advice, telling me what is possible, and what the best solution is, before I go too far on my own with this. I'm looking at a group of related functions in wine, in dlls/x11drv/dib.c. It came to my attention that in X11DRV_SetDIBits and X11DRV_SetDIBitsToDevice, wine always seems to end up calling X11DRV_DIB_SetImageBits, which calls (in my case, probably because my desktop is 16-bit color) X11DRV_DIB_SetImageBits_16, which in every case calls a convert function of one type or another (all of which are CPU hogs). These are the core functions that seem to be related to the problem. Here is my early analysis of the problem: X11DRV_DIB_SetImageBits always creates and destroys an XImage during the life of the function, and calls X11DRV_DIB_SetImageBits_16 (or another bit depth), which ends up converting the bitmap to the proper color format / bit depth. It seems to me the best solution is to use some kind of caching to save the converted bitmap in its cached form, preferably as an XImage. Inside X_PHYSBITMAP the HBITMAP is stored, windows' unique handle for that particular bitmap. So, what if we stored the appropriate converted XImage per-HBITMAP, per-bpp, so that it doesn't need to be created, converted, and destroyed each time, and we could delete all cached XImages corresponding to the HBITMAP from the cache when DeleteObject() is called for that HBITMAP? I'm doing a lot of guesswork on the inner-workings of wine, X, and the windows GDI here. Please tell me, am I on the right track for eliminating these unnecessary conversions? If not, where should I be looking? Again I'm new to wine, X, and somewhat new to GDI programming - but I would like to learn. Please, GDI/X11 experts, give me some advice on the best solution to this problem!

2 1

Mystery solved: acoc breaks Wine's configure!
by Dan Kegel Oct. 23, 2005

Oct. 23, 2005

Here's the strangest thing I've seen for a while. I was tracking down why I could build Wine, but another guy on the same machine could only build a slightly broken Wine that gave the error Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. whenever you tried to use it. The first clue was funny output from Wine's configure script, though it was hard to see until I diff'd against good output, and used cat -v to make invisible chars visible: --- configure.log.good.txt 2005-10-20 10:57:21.000000000 -0700 +++ configure.log.bad.txt 2005-10-21 14:41:59.000000000 -0700 ... -checking for ldd... /usr/bin/ldd -checking for -lX11 soname... libX11.so.6 -checking for -lXext soname... libXext.so.6 ... +checking for ldd... /home/mmoss/bin/ldd +checking for -lX11 soname... libX11.so.6^[[0m +checking for -lXext soname... libXext.so.6^[[0m And what's that funny ldd? And what are those escape sequences? Turns the ldd is one wrapped by acoc (http://www.caliban.org/ruby/acoc.shtml) which colorizes the output, which also explains the funny escape sequences. This error went away when we stopped using acoc to colorize the output of commands like ldd. We had been using acoc-0.5.2, but the latest version (0.7.1) also exhibits the problem. I hope this helps somebody else who's scratching their head over strange build failures! - Dan

2 1

Re: shell32: Remove redundant .\\ from test files
by Jakob Eriksson Oct. 23, 2005

Oct. 23, 2005

James Hawkins wrote: >Hi, > >I started by removing all .\\ from the shlfileop.c test file in msvc >and the tests all passed , but three of the tests failed in wine. > > If the tests fail on wine, should they not be todo_wine{} then? regards, Jakob

2 1

Re: Shell32 File Property dialog
by Mike McCormack Oct. 22, 2005

Oct. 22, 2005

Johannes Anderwald wrote: > I have a patch which adds file property dialogs to shell32 Looks like you've written the patch for ReactOS... it doesn't apply to the current Wine tree. I think you need to do a little bit more work to get it ready for submission: * use TRACE instead of DPRINT * don't use %S in debug statements (with TRACE) it's not portable, use %s and debugstr_w(str) instead * in SH_FileVersionDlgProc you miss a break at the end of WM_COMMAND * the formatting is all over the place. 4 space indent, no tabs is prefered * make sure to use the A or W functions and types explicitly. eg. you use PROPSHEETPAGE where you should use PROPSHEETPAGEW. * this comments looks dodgy: "SH_FileTimerProc is invoked every 100ms to check if the property sheet should be closed required because the property sheet pages are MODELESS" Your Window proc will get a WM_CLOSE when you need to close, or WM_DESTROY when it is destroyed. Freeing memory and other things that need to be done when the window is closed should happen in the Window procedure, and there should be no need for a timer. Please take the time to build you patch with and generate it against the CVS version of WineHQ. thanks for the patch, Mike

1 0

Solaris Updates
by Robert Lunnon Oct. 22, 2005

Oct. 22, 2005

I have posted my local patches to wine-patches. Note that for 0.9 I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions). Patches not sent are listed hereunder long with the reasons... Possibly essential (Show stoppers) ptrace stub patch - Disable debugger by returning error for all ptrace calls, add ptrace stubs (framework) to allow work on ptrace emulation layer for wine. -Previously rejected linking patch - since libwinecrt0.a was added wine has been broken due to the linker wanting to import main() in dlls, this results in unresolved symbols. I have temporarily worked around this and can build wine with a change to winegcc that links another archive (I call winedllcrt0.a) which omits the main() definitions in the case where -shared is passed to winegcc. Alexandre has asked that I keep looking for a way to make the Solaris linker successfully link an archive containing main() to dlls without the need to have two runtime startoff libraries. Patch won't be submitted until a final solution is found. Recommended functionality patches cpuid patch - CPUID detection using x86 cpuid instruction - previously rejected wineconsole/curses.c - Patch non-essential and FAR too hacky at this point - just removes all mouse code. Other Patches tools - automation patches to allow unattended build No interest to Wine project Debugger - work in progress, not working A complete set of patches (even the gross ones) are maintained at http://www.blastwave.org/wine

1 0

Re: dinput: Fix mouse poll and few other bugs
by Stefan Dösinger Oct. 22, 2005

Oct. 22, 2005

Am Samstag, 15. Oktober 2005 18:49 schrieb Magnus Olsen: > Hi > This change allown me run all MS DirectInput sample with out any problem. > it also take care of bad writen dinput program that try getting the mouse, > Without calling on right api, see my commmect in dinput. I have not > tested in wine, But I have tested it in ReactOS and Windows. Did you forget to attach the patch?

1 0

autoexec.bat and pif's which run batch files
by paul Oct. 22, 2005

Oct. 22, 2005

I have not seen this one problem listed and it may be a 1.0 target. Filed bug 3638. Legacy installers modify autoexec.bat to add the install directory to the path and may also use set's. After the installer installs the program will not run as it's bin directory is not in the path. This also could be a reason why many applications only work when run from the directory it is installed in. If windows type is set to 95 or less in winecfg then autoexec should be processed before running the program. I also have programs which uses a pif to run a batch file. The batch in a pif is disabled/stubbed. I plan to look at filling it that feature when I get some time. Paul Romanyszyn

1 0

Roadblock #1 for VB installers: MDAC
by Dan Kegel Oct. 22, 2005

Oct. 22, 2005

A lot of VB apps use MDAC (http://msdn.microsoft.com/data/mdac/downloads/) They tend to include mdac_typ.exe, the mdac installer, and run it, but unfortunately, Wine doesn't seem to run it properly. (I'm testing using mdac 2.7 sp1, fwiw.) First, the MDAC installer refuses to run unless the registry key for IE6 is present. (OK, that's easy to work around... if you're a programmer. It probably ought to be a winecfg pulldown.) Second, even if the MDAC installer runs, all it does is install a bunch of directories under c:\windows\RegisteredPackages. The DLLs needed by the VB app are locked up in .cab's in those directories. In the app I'm trying to install, the installer then fails with err:module:import_dll Library MSDART.DLL (which is needed by L"C:\\windows\\system32\\msadox.dll") not found Something, somehow, is supposed to be triggering an unpack, but it's not happening. (See http://msdn.microsoft.com/workshop/delivery/download/download_node_entry.asp for a discusion of how the unpacking is supposed to go on Windows.) I've filed a bug report at http://bugs.winehq.org/show_bug.cgi?id=3636

1 0

Are Visual Basic install problems common?
by Dan Kegel Oct. 21, 2005

Oct. 21, 2005

Is it common for Visual Basic applications to have problems installing under Wine? Take the recent post by Denis, for instance. He's trying to install a fairly complex Visual Basic app that uses MDAC, and the installer just won't run properly under Wine. (I've corresponded with him privately, and can give more details if desired.) I have this feeling that this isn't an isolated instance. Maybe there are hundreds of thousands of businesses and government offices that have large collections of VB apps written in-house, not yet ported over to VB.NET, which they'd like to run under Wine -- but they take one look at the trouble they have installing, and give up. Does anyone have experience rolling VB (not VB.net) apps here? Is it easy to create VB apps that install fine under Windows, but not under Wine?

3 6