March 2006 - Wine-Devel - list.winehq.org

Re: disallow networking flag

by n0dalus

On 3/20/06, rauschenimweltnetz(a)web.de <rauschenimweltnetz(a)web.de> wrote: > > I think it would be very usefull to disallow an application started with wine to connect to the network/internet by an options flag. > > Unless somebody would help me to find out what I have to change... So I would try it by myself. But in consideration of the fact that I need this feature as soon as possible I would better like to just watch and learn... ;) > I don't know how much of wine's source would need to be changed to disallow all network commands, but I know that this kind of thing is possible using iptables (particularly with the owner extension). If you create a new user id (which will be the one you use to start the application, using su or sudo), something like 'nonet', then run the following: iptables -I OUTPUT -m owner --uid-owner nonet -j REJECT --reject-with imcp-net-unreachable or something like that (I haven't tested it), it will block the 'nonet' user and any applications started as it from sending network packets. HTH, n0dalus.

March 20, 2006

disallow networking flag

by rauschenimweltnetz＠web.de

Ahoi! I think it would be very usefull to disallow an application started with wine to connect to the network/internet by an options flag. I'm new to this list and my coding skills are in its fledgling stages. So my part in this whole thing probably would be to watch and learn... :) Unless somebody would help me to find out what I have to change... So I would try it by myself. But in consideration of the fact that I need this feature as soon as possible I would better like to just watch and learn... ;) rauschi ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

March 20, 2006

Re: Vitaly Lipatov : gdi32: Look for ttf fonts in the Wine font dir.

by Vitaly Lipatov

В сообщении от 18 марта 2006 21:51 Alexandre Julliard написал(a): > + /* load the system truetype fonts */ > + data_dir = wine_get_data_dir(); > + if (data_dir && (unixname = HeapAlloc(GetProcessHeap(), 0, I did not use if (!data_dir) data_dir = wine_get_build_dir(); also for ttf mixing problem in fonts dir. What about to place source fonts and result (.fon, .ttf) in separate directories in source tree? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 20, 2006

Re: crt0.o versus crtdll.dll etc - suggestions?

by Wesley Parish

Thanks, and my apologies for wasting your time. Wesley Parish Quoting Segin <segin2005(a)gmail.com>: > crt0.o is everything from the program's entry point until main() -- If > the OS doesn't parse arguments in the way main() handles them, the > crt0.o code converts them. Most unix systems have /usr/lib/crt?.o > > crtdll.dll is equilvant to libc.so, and therefore unrelatted > > Wesley Parish wrote: > > >Hi. > > > >I've got some Clipper files I want to translate to C for incorporation > into > >another program, and a program x2c to do the work. > > > >But it asks for crt0.o, which I don't have as such; I'm wondering which > of the > >*crt* files in Wine are most suitable for aliasing or linking as > crt0.o? > > > >Thanks > > > >Wesley Parish > > > >"Sharpened hands are happy hands. > >"Brim the tinfall with mirthful bands" > >- A Deepness in the Sky, Vernor Vinge > > > >"I me. Shape middled me. I would come out into hot!" > >I from the spicy that day was overcasked mockingly - it's a symbol of > the > >other horizon. - emacs : meta x dissociated-press > > > > > > > > > > > > "Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge "I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press

March 20, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Alexandre Julliard

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Just one random example out of the committed Winefile patch: > > - int idx = ListBox_AddString(hlbox, infoStr); > - ListBox_SetItemData(hlbox, idx, pTxt); > + int idx = SendMessage(hlbox, LB_ADDSTRING, 0L, (LPARAM)infoStr); > + SendMessage(hlbox, LB_SETITEMDATA, idx, (LPARAM) pTxt); > > You can't tell us those SendMessage calls are cleaner and more easy to > understand. They contain those ugly (LPARAM) type casts, unused "0L" > wparam parameters and result in longer, less readable code. Not necessarily; the code makes it obvious that we are sending a message here, not calling a function (or worse, a macro disguised as a function). In many cases that's important information, for instance when you try to match a message trace with the code. The casts are ugly but they are present in the macro too, so it isn't any more typesafe, it just looks like it is. -- Alexandre Julliard julliard(a)winehq.org

March 20, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > Alex wrote: > >It seems that I will have to wait until I code > >enough of a test case for a *successful* > >ITypeInfo::Invoke() A few more vaguely relevant notes: http://codeguru.earthweb.com/Cpp/COM-Tech/atl/article.php/c3565/ briefly mentions how ATL uses ITypeInfo::Invoke(). http://www.opengroup.org/onlinepubs/009899899/CHP18GDC.HTM is the Open Group's documentation for ActiveX (!) which also covers this a bit. And, more usefully, http://groups.google.com/group/comp.os.ms-windows.programmer.ole/msg/c1417f… says: 0) Call CoCreateInstance() to get a pointer to the object 1) Create a ITypeLib interface (via the 'LoadTypeLib' API function). 2) Call ITypeLib::GetTypeInfo to obtain ITypeInfo interface. 3) Call ITypeInfo::Invoke (almost like IDispatch::Invoke) which is exactly what I was starting to gather by reading the Automation and Type Libraries chapters of "Essence of COM". - Dan

March 20, 2006

Re: winedbg: add diplay for floating point status

by Jeff Latimer

Thanks for the advice and encouragment. I will be submitting patches again soon. Should the all-regs be invoked at the exception or just the regs? I suppose the FPU errors are rather rare. Jeff Eric Pouech wrote: > Jeff L wrote: > >> This patch adds code to examine the floating point save area in the >> context being examined. For the want of a better place I have in >> included it with the registers area. >> >> Changelog: added code to examine and display floating point uint >> status into be_i386.c > > your patch is definitively needed > > However, I'd rather do it the way gdb does it: > - 'info regs' shows only 'general purpose' and segment registers > - 'info all-regs' shows all the registers (including floating point ones) > > that'd mean adding an extra parameter to all be_???_print_context to > drive this. > > A+

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dan Kegel <dank(a)kegel.com> wrote: > [Let's use Abiword as the app to test, as I proposed long ago:] > http://www.winehq.com/hypermail/wine-users/2001/08/0086.html > Wine wasn't ready for that back then, but it is now; > abiword-2.0.8 works fine under current wine (newer versions > run into http://bugs.winehq.org/show_bug.cgi?id=4887 ). > I'll go check to see if they've got an automated regression test > of their own yet... They don't. So we'd have to write one. Shouldn't be hard to do - either as a cxtest script, or as a C program that sends Windows events and looks at the resulting files abiword creates, or some combination... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Re: Easy applications to write automated tests for?

by Segin

Dan Kegel wrote: >On 3/19/06, Dimi Paun <dimi(a)lattica.com> wrote: > > >>On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: >> >> >>>I tried [mauve on msys on wine] ... >>> >>> >>I personally think this is a very exciting thing to get right. >>Being able to run an emulation layer like msys/cygwin would >>stress the hell out of the fundamental APIs, and would ensure >>a solid implementation in Wine. Not to mention that: >> -- they are OSS, making debugging a bit easier >> -- they have _lots_ of tests that can be run automatically >> -- said tests could dramatically enhance and broaden the >> available regression tests we have >> >> > >Totally. FWIW, the old, minimal snapshot of cygwin in msys >is probably easier to support than the modern cygwin. (See >http://www.mingw.org/MinGWiki/index.php/mSysFromScratch for >how to build it, if you're interested.) > > > >>Adding to this mix stuff like Java can only extend coverage. >>And we would be tapping into a huge barrage of tests. >> >> > >Yes, it would be an amazing amount of leverage, test-wise. >Having msys working would make a whole new level of >dogfooding possible (e.g. building windows mozilla/firefox >on msys on wine). >- Dan > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv > > > > > Well, that would be good for dogfooding, but so would getting Dev-C++ to work perfectly on Wine -- it uses MingW/gcc to compile.

March 20, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Segin <segin2005(a)gmail.com> wrote: > ... getting Dev-C++ to work perfectly on Wine [would be good > for dogfooding] -- it uses MingW/gcc to compile. Sure, good idea. I encourage Dev-C++ users to test it with Wine and file bug reports at http://bugs.winehq.org for any problems they find. I just looked, and only found one report, http://bugs.winehq.org/show_bug.cgi?id=4483 which was really fixed already by wine-0.9.7. In my own test of dev-c++, it looks like there are a few small cosmetic problems. I didn't try it on any real apps, though. I'll let IDE users do that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 20, 2006

Fwd: Regression: new systray implementation ... - analysis, demo, etc.

by qingdoa daoo

http://bugs.winehq.org/show_bug.cgi?id=4853 --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments.

March 20, 2006

function counting script, memcheck.sh

by Segin

Attached is version 0.2 of this script, with a lot of additional functionality. You will need to be able to write to /tmp and make a file /tmp/grep to use the extended functionality (default functionality needs none of that, and is unmodified.) For those that are intested, you can fetch memcheck.sh from my project CVS tree: cvs -d:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/overdose login (when propted for a password, simply push enter) cvs -z3 -d:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/overdose co overdose You'll find the memcheck.sh script in the CVS checkout. Could someone tell me how to checkout just a single CVS file? Anyways, there's the docs, which you should read (failure to do so will get a reply of RTFM): ----------------------------------8<--------------------------------- memcheck.sh version 0.2 documentation To change the functions searched for, edit the file's top line. make sure all functions are space seperated and in quotes, to search for recv() and send() make sure that top line looks like this: FUNCTIONS="recv send"; Three are 2 command line arguments supported, they must be the only argument and verbatim to work, yada yada. -l List the line number with a code sample -C Like above, but with context. You need write access to /tmp to create, read, write and destroy files. Your grep implementation needs to be GNU grep or you need to edit the script. Most systems have given up using their own grep for GNU grep cause GNU grep kicks ass. ----------------------------------8<---------------------------------

March 20, 2006

GoogleEarth

by James Courtier-Dutton

Hi, Can one run GoogleEarth under wine? It does not seem to run here under the default settings. James

March 19, 2006

Re: rpaths not working?

by Mike Hearn

On Sat, 2006-03-18 at 10:55 +0100, Alexandre Julliard wrote: > AFAIK the rpath of the main binary is supposed to apply to > dependencies too, not sure why it doesn't in your case. What libc > version is that? This is glibc 2.4 - time to consult the ELF specs I think ...

March 19, 2006

OLEAUT32: bug 4502 - request for comment before trying to fix

by Dan Kegel

Alex wrote: >It seems that I will have to wait until I code >enough of a test case for a *successful* ITypeInfo::Invoke() (there are >two tests of failing calls, but none of a successful one) I'm a complete COM newbie, but I've been reading "The Essence of COM" lately for entertainment; it almost describes that call. (FWIW, the example code for the book is at http://www.rollthunder.com/Books/OldBooksFrame.htm.) I went poking around online looking for examples of that call in C, and only found two :-( http://viewcvs.php.net/viewcvs.cgi/php-src/ext/com_dotnet/com_com.c http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ercp/org.eclipse.ercp.… I also found a muddled discussion here: http://www.codeproject.com/atl/multidisp.asp Good luck writing that test case! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Martin Fuchs

2006/3/19, Alexandre Julliard <julliard(a)winehq.org>: > I think these windowsx macros are confusing things more than helping, > especially since they don't look like macros. It's better to have > explicit SendMessage calls than some pseudo function calls, it makes > much more obvious what's going on, especially for people who try to > debug the code without being very familiar with the Windows API. The > fact that getting rid of the macros also avoids the warnings is just > icing on the cake. Just one random example out of the committed Winefile patch: - int idx = ListBox_AddString(hlbox, infoStr); - ListBox_SetItemData(hlbox, idx, pTxt); + int idx = SendMessage(hlbox, LB_ADDSTRING, 0L, (LPARAM)infoStr); + SendMessage(hlbox, LB_SETITEMDATA, idx, (LPARAM) pTxt); You can't tell us those SendMessage calls are cleaner and more easy to understand. They contain those ugly (LPARAM) type casts, unused "0L" wparam parameters and result in longer, less readable code. Regards, Martin

March 19, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/19/06, Dimi Paun <dimi(a)lattica.com> wrote: > On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: > > I tried [mauve on msys on wine] ... > > I personally think this is a very exciting thing to get right. > Being able to run an emulation layer like msys/cygwin would > stress the hell out of the fundamental APIs, and would ensure > a solid implementation in Wine. Not to mention that: > -- they are OSS, making debugging a bit easier > -- they have _lots_ of tests that can be run automatically > -- said tests could dramatically enhance and broaden the > available regression tests we have Totally. FWIW, the old, minimal snapshot of cygwin in msys is probably easier to support than the modern cygwin. (See http://www.mingw.org/MinGWiki/index.php/mSysFromScratch for how to build it, if you're interested.) > Adding to this mix stuff like Java can only extend coverage. > And we would be tapping into a huge barrage of tests. Yes, it would be an amazing amount of leverage, test-wise. Having msys working would make a whole new level of dogfooding possible (e.g. building windows mozilla/firefox on msys on wine). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Lionel Ulmer

On Fri, Mar 17, 2006 at 11:47:14AM +0000, Mike Hearn wrote: > There's a new patch to try here: > > http://plan99.net/~mike/files/glteb.patch > > Does that work any better? Well, to make this work better, one would need a two-tiered approach: = use thread-local variables to check if it's a 'special' buffer or not (like this patch does) = only do this check on GL APIs that actually modify or read from the frame buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...). The last is easy to do for 'core' stuff, a bit harder for extensions though. But anyway, this is mandatory if one day we want to fix the 'windowed' OpenGL code properly (whatever the method we choose as long as we do not have the GLX extension exporting the clip list feature to the application). Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 19, 2006

Re: Function counting script

by Segin

Jim White wrote: > Joris Huizer wrote: > >> Segin wrote: >> >>> It's not a C interpeter, it's literally a frint end of sorts to >>> grep. There's only one textual occurence of malloc() in the code, so >>> it only returns one. >>> >>> Think before you speak. >>> >>> P.S. I'll add a C interpeter when there becomes a need for one. >>> >> >> It was my impression that the goal was to find leaks by counting >> allocating and freeing of memory; >> My example was about that: the counts do not have to indicate correct >> usage of malloc()/free() >> Sorry if this was an incorrect assumption > > > Right. And by reading the code that is doing alloc/free you can > determine if they are balanaced. But first you have to *find* where > those calls are made. > > Jim > > > > This gives me an idea: I can add a command line flag to determine how to invoke grep (e.g. just a count, or a count plus occurences by line)

March 19, 2006

Re: Function counting script

by Segin

That's ok, I failed to document that myself. In truth, it would truthfully be inpossible to find run-time memory leaks like that using a script because of a potential unknown variable in a for loop which is derived from an argument or return from another function. I will try to add code for detecting contant for loops at one point. Also, the script is designed to be edited and whatever function you want to look for inserted into the code. Joris Huizer wrote: > Segin wrote: > >> It's not a C interpeter, it's literally a frint end of sorts to grep. >> There's only one textual occurence of malloc() in the code, so it >> only returns one. >> >> Think before you speak. >> >> P.S. I'll add a C interpeter when there becomes a need for one. >> > > It was my impression that the goal was to find leaks by counting > allocating and freeing of memory; > My example was about that: the counts do not have to indicate correct > usage of malloc()/free() > Sorry if this was an incorrect assumption > > regards, > > Joris > > >

March 19, 2006

Re: crt0.o versus crtdll.dll etc - suggestions?

by Segin

crt0.o is everything from the program's entry point until main() -- If the OS doesn't parse arguments in the way main() handles them, the crt0.o code converts them. Most unix systems have /usr/lib/crt?.o crtdll.dll is equilvant to libc.so, and therefore unrelatted Wesley Parish wrote: >Hi. > >I've got some Clipper files I want to translate to C for incorporation into >another program, and a program x2c to do the work. > >But it asks for crt0.o, which I don't have as such; I'm wondering which of the >*crt* files in Wine are most suitable for aliasing or linking as crt0.o? > >Thanks > >Wesley Parish > >"Sharpened hands are happy hands. >"Brim the tinfall with mirthful bands" >- A Deepness in the Sky, Vernor Vinge > >"I me. Shape middled me. I would come out into hot!" >I from the spicy that day was overcasked mockingly - it's a symbol of the >other horizon. - emacs : meta x dissociated-press > > > > >

March 19, 2006

Re: Function counting script

by Jim White

Joris Huizer wrote: > Segin wrote: > >> It's not a C interpeter, it's literally a frint end of sorts to grep. >> There's only one textual occurence of malloc() in the code, so it only >> returns one. >> >> Think before you speak. >> >> P.S. I'll add a C interpeter when there becomes a need for one. >> > > It was my impression that the goal was to find leaks by counting > allocating and freeing of memory; > My example was about that: the counts do not have to indicate correct > usage of malloc()/free() > Sorry if this was an incorrect assumption Right. And by reading the code that is doing alloc/free you can determine if they are balanaced. But first you have to *find* where those calls are made. Jim

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > It seemed to be ignored by both you and Alexandre last time it was > sent, and all of your patches applied anyway despite objections from > several developers. I think these windowsx macros are confusing things more than helping, especially since they don't look like macros. It's better to have explicit SendMessage calls than some pseudo function calls, it makes much more obvious what's going on, especially for people who try to debug the code without being very familiar with the Windows API. The fact that getting rid of the macros also avoids the warnings is just icing on the cake. -- Alexandre Julliard julliard(a)winehq.org

March 19, 2006

Re: Easy applications to write automated tests for?

by Dimi Paun

On Sun, 2006-03-19 at 09:09 -0800, Dan Kegel wrote: > OK, I looked. It has a big configure script. > I tried running it under msys on wine, but that > failed miserably. So I guess it's not easy, offhand > (big surprise). I suppose there might be other ways > to run parts of the mauve test suite on wine, but I'll pass for now. I personally think this is a very exciting thing to get right. Being able to run an emulation layer like msys/cygwin would stress the hell out of the fundamental APIs, and would ensure a solid implementation in Wine. Not to mention that: -- they are OSS, making debugging a bit easier -- they have _lots_ of tests that can be run automatically -- said tests could dramatically enhance and broaden the available regression tests we have Adding to this mix stuff like Java can only extend coverage. And we would be tapping into a huge barrage of tests. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 19, 2006

Re: How hard would it be to support Java?

by Dan Kegel

On 3/19/06, Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> wrote: > > So I played around a bit with Sun's latest 1.5 JRE. > > ... it can't run applets; first, it runs into a nasty glx error, > > http://bugs.winehq.org/show_bug.cgi?id=4143 > > As a work-around you can try to force it to use gdi. Turn off ddraw. I > think their is a jvm parameter for this, can't quite recall. Good call. -Dsun.java2d.noddraw=true does the trick, and lets you get to the more serious error. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: Easy applications to write automated tests for?

by Dan Kegel

On 3/18/06, Dan Kegel <dank(a)kegel.com> wrote: > Which got me thinking: what are the easiest set of > application regression tests we could throw together > that go further than just verifying the installer runs? >... > And then on the somewhat ambitious end, > now that Sun's JVM basically installs and > runs trivial programs, we could run through > the Java regression test suite at > http://sourceware.org/mauve/ > Heck, I might give that a shot myself. OK, I looked. It has a big configure script. I tried running it under msys on wine, but that failed miserably. So I guess it's not easy, offhand (big surprise). I suppose there might be other ways to run parts of the mauve test suite on wine, but I'll pass for now. I remember now a post from almost five years ago, proposing using Abiword as the app to test: http://www.winehq.com/hypermail/wine-users/2001/08/0086.html Wine wasn't ready for that back then, but it is now; abiword-2.0.8 works fine under current wine (newer versions run into http://bugs.winehq.org/show_bug.cgi?id=4887 ). I'll go check to see if they've got an automated regression test of their own yet... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: How hard would it be to support Java?

by Ulrich Czekalla

On Fri, Mar 17, 2006 at 06:21:43PM -0800, Dan Kegel wrote: > Quite a few apps use embedded JVM's. > Case in point: SPSS, one of the apps requested by Munich. > > So I played around a bit with Sun's latest 1.5 JRE. > It can run trivial apps, so I closed > http://bugs.winehq.org/show_bug.cgi?id=2953 > (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). > > But it can't run applets; first, it runs into a nasty glx error, > http://bugs.winehq.org/show_bug.cgi?id=4143 > As a work-around you can try to force it to use gdi. Turn off ddraw. I think their is a jvm parameter for this, can't quite recall. Another option is to set the dll override for ddraw to "". /Ulrich

March 19, 2006

msys on wine - partial success

by Dan Kegel

Last year, I poked at using msys under wine: http://www.winehq.com/hypermail/wine-devel/2004/04/0149.html but didn't follow up on the hint that wineconsole would help. Finally got around to it. Sure enough, you can run msys's sh.exe in a wineconsole! It's ugly and can't seem to run configure scripts yet, but it does run simple shell scripts and interactive commands like cd, pwd, and ls. Sort of. Here's what I tried: Installing http://easynews.dl.sourceforge.net/sourceforge/mingw/MSYS-1.0.10.exe created c:\msys\1.0. Looking in that directory, I saw a script MSYS.BAT that one uses to start a shell. Rather than figuring out how to invoke that batch file in Wine, I read it, saw that it invoked sh as "sh --login -i", and wrote a little shell script that did something similar: wineconsole ~/.wine/drive_c/msys/1.0/bin/sh.exe --login -i This had problems with the path -- it couldn't find msys's external commands. Running "echo $PATH" showed that it defaulted to including /mingw/bin, so I cheated and added a symlink: ln -s ~/.wine/drive_c/msys/1.0 ~/.wine/drive_c/mingw That worked; I can now use msys's external commands in the msys sh. I probably should have modified the PATH, but that was hard to script. The ugly part is, when you give any command, the first thing that happens is a pair of warnings: sh: fork: No such file or directory sh: child setpgid (-45 to -50): Invalid argument And if you try to run mauve's configure script. it stops after the second statement. It seems that anything involving subshells or eval confuses it greatly. Also, if you're not very careful with the first command you type, it gets into a bad state where it ignores half the keys you type, or something. All in all not very healthy, but that's not too surprising for a first try. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: patch opengl.c, wgl.c

by Leon Freitag

> This is not a patch but rather partial reversal of the patch that caused > this regression. It's not a complete reversal though. That doesn't imply that it's not a fix. Perhaps the original patch had a bug in it. > - GLXDrawable drawable; > - enum x11drv_escape_codes escape = X11DRV_GET_GLX_DRAWABLE; > + Drawable drawable; > + enum x11drv_escape_codes escape = X11DRV_GET_DRAWABLE; This part seems to be very interesting. > It works for all my opengl applications, including GoogleEarth, World of > Warcraft (wow -opengl), Warcraft III, 3DEditor, Iconoclast, Glview > & Moray 3.5. Tested on latest CVS with Nvidia > 6800 graphics card on my 64 bit OS, Fedora Core 4_64, AMD64. That's more than an argument. Yet there's no application that has been broken with it. > + if (ppfd->>dwFlags & PFD_DRAW_TO_BITMAP) { > + ERR("Flag not supported !\n"); > + /* Should SetError here... */ > + return 0; > + } Well Wine should report ERRs instead of crashing with an Xlib error, shouldn't it? OK, if you don't like these five lines so much, does the patch work without it? Leon

March 19, 2006

Re: kernel/heap: Avoid heap corruption on invalid Parameter in GlobalFree(), with Test

by Dmitry Timoshkov

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > --- a/dlls/kernel/tests/heap.c > +++ b/dlls/kernel/tests/heap.c > @@ -25,6 +25,8 @@ > #include "winbase.h" > #include "wine/test.h" > > +#define MAGIC_DEAD 0x00dead00 > + SetLastError(MAGIC_DEAD); > + hsecond = GlobalFree(gbl); /* invalid handle: free memory twice */ There is no need to invent a new magic number, a usual convenience for Wine tests is to use 0xdeadbeef. -- Dmitry.

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Mike McCormack

Robert Shearman wrote: > We're trying to work around GCC warnings that probably aren't generated > using any other compiler so using non-portable C > constructs is perfectly fine. Here is Francois' solution again: I understand Francois's solution, as I mentioned that the gcc guys proposed it in the first place. Sorry, but I don't think using non-portable C constructs to solve a warning is a good solution. Why layer on complexity when there's a simple solution? > It seemed to be ignored by both you and Alexandre last time it was sent, > and all of your patches applied anyway despite objections from several > developers. If you don't like it, show me your patches to fix the problem. Mike

March 19, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Mike McCormack

Robert Shearman wrote: >> Using the following example: >> >> #define ComboBox_AddString(hwndCtl, lpsz) \ >> ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, >> (LPARAM)(LPCTSTR)(lpsz))) >> >> In Wine source, UNICODE is not defined. So should the above be using >> SendMessageW/LPCWSTR or SendMessageA/LPCSTR? > > Either "void *" as I mentioned above or only the LPARAM cast for Wine > source files, and LPCTSTR still for Winelib. You seem to miss the point about SendMessage. A or W? You have to choose, and you don't know what is appropriate. Mike

March 19, 2006

Re: Function counting script

by Joris Huizer

Segin wrote: > It's not a C interpeter, it's literally a frint end of sorts to grep. > There's only one textual occurence of malloc() in the code, so it only > returns one. > > Think before you speak. > > P.S. I'll add a C interpeter when there becomes a need for one. > It was my impression that the goal was to find leaks by counting allocating and freeing of memory; My example was about that: the counts do not have to indicate correct usage of malloc()/free() Sorry if this was an incorrect assumption regards, Joris

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Robert Shearman

Mike McCormack wrote: > > Robert Shearman wrote: > >> Why don't we fix the macros as suggested by Francois, rather than >> preventing its use? It seems like a big waste of time to have submitted >> all of the patches to the files using windowsx.h when fixing the macros >> is necessary for Winelib anyway. > > > No, it's not a waste of time. Having warning free Wine source code is > far more important than any warnings that might be in 3rd party > winelib code. > > Francois' solution is still not perfect, as it requires use of a > non-portable C construct. We're trying to work around GCC warnings that probably aren't generated using any other compiler so using non-portable C constructs is perfectly fine. Here is Francois' solution again: > +#ifndef WINE_CAST > +# if __GNUC__ > +# define WINE_CAST(ctype, val) ({ctype r=(ctype)(val);r;}) > +# else > +# define WINE_CAST(ctype, val) ((ctype)(val)) > +# endif > +#endif > + > + #define Header_SetImageList(hwnd,himl) \ > - (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl) > + WINE_CAST(HIMAGELIST, > SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl)) > + It seemed to be ignored by both you and Alexandre last time it was sent, and all of your patches applied anyway despite objections from several developers. -- Rob Shearman

March 19, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Robert Shearman

Mike McCormack wrote: > Robert Shearman wrote: > >>> Despite containing some useful macros, those macros are somewhat >>> broken as they are ignorant of UNICODE, so cannot be "fixed" by simple >>> conversion to inline functions. >> >> >> Unicode isn't a problem as "void *" could simply be used, but there are >> other compatibility reasons why inline functions shouldn't be used. > > > Using the following example: > > #define ComboBox_AddString(hwndCtl, lpsz) \ > ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, > (LPARAM)(LPCTSTR)(lpsz))) > > In Wine source, UNICODE is not defined. So should the above be using > SendMessageW/LPCWSTR or SendMessageA/LPCSTR? Either "void *" as I mentioned above or only the LPARAM cast for Wine source files, and LPCTSTR still for Winelib. > Furthermore, using an inline function requires that we've included > winuser.h to get the definition of SendMessageA/W, whereas windowsx.h > on its own doesn't require that. > > The commctrl.h macros don't have this problem as they define A/W > versions of the macros. I am in the process of adding inline > functions to commctrl.h, and will submit a patch for that soon. Well, I guess I am relieved that you're not putting an #error at the top of the include file like you did with windowsx.h. -- Rob Shearman

March 19, 2006

crt0.o versus crtdll.dll etc - suggestions?

by Wesley Parish

Hi. I've got some Clipper files I want to translate to C for incorporation into another program, and a program x2c to do the work. But it asks for crt0.o, which I don't have as such; I'm wondering which of the *crt* files in Wine are most suitable for aliasing or linking as crt0.o? Thanks Wesley Parish "Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge "I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press

March 19, 2006

Re: winedbg: add diplay for floating point status

by Eric Pouech

Jeff L wrote: > This patch adds code to examine the floating point save area in the > context being examined. For the want of a better place I have in > included it with the registers area. > > Changelog: added code to examine and display floating point uint status > into be_i386.c your patch is definitively needed However, I'd rather do it the way gdb does it: - 'info regs' shows only 'general purpose' and segment registers - 'info all-regs' shows all the registers (including floating point ones) that'd mean adding an extra parameter to all be_???_print_context to drive this. A+ -- Eric Pouech

March 19, 2006

Easy applications to write automated tests for?

by Dan Kegel

I noticed a probable regression in an app (kid pix 3) tonight. Which got me thinking: what are the easiest set of application regression tests we could throw together that go further than just verifying the installer runs? I'm thinking not just of things that could be automated with cxtest, but also stuff that might not fit into that framework. In the case of Kid Pix 3, a test that simply started the app, waited ten seconds, and made sure an error dialog didn't pop up would have detected the problem. ('Course, only a few people would be able to run that, as Kid Pix 3 is not a free download.) cxtest should be able to handle that. A bit more complex would be to launch WinZip, have it compress one file, and make sure the compressed file was as expected. It shouldn't be too hard to make cxtest handle that. And then on the somewhat ambitious end, now that Sun's JVM basically installs and runs trivial programs, we could run through the Java regression test suite at http://sourceware.org/mauve/ Heck, I might give that a shot myself. There's probably no reason to try to shove that into cxtest, is there? Or would it fit? And beyond the looking glass, one could imagine running the OpenOffice 2.0 automated test suite. (That's unlikely to work well at the moment, given that OpenOffice 2.0's open dialog locks up reliably.) That would probably flush out a few problems. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 19, 2006

Re: patch opengl.c, wgl.c

by Vitaliy Margolen

Saturday, March 18, 2006, 11:48:12 AM, Henry Kroll wrote: > Changelog: > Henry Kroll, admin(a)comptune.com corrects X "bad match" errors when > running opengl apps. > Ref: http://bugs.winehq.org/show_bug.cgi?id=4143 > ========================== > --- wine/dlls/x11drv/opengl.c.orig 2006-03-11 11:58:01.000000000 -0900 > +++ wine/dlls/x11drv/opengl.c 2006-03-11 11:58:09.000000000 -0900 > @@ -199,6 +199,12 @@ > dump_PIXELFORMATDESCRIPTOR((const PIXELFORMATDESCRIPTOR *) ppfd); > } + if (ppfd->>dwFlags & PFD_DRAW_TO_BITMAP) { > + ERR("Flag not supported !\n"); > + /* Should SetError here... */ > + return 0; > + } > + > /* Now, build the request to GLX */ [skip] This is not a patch but rather partial reversal of the patch that caused this regression. You should fix this and not revert it back to what it was before. Unless you have a prove that this is the way native works. Vitaliy Margolen

March 19, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Thanks for the link, i'll get those installed to try to find out why it is expecing a 24-bit value. Perhaps it is designed to work on a video card that supports 24-bit, I know a lot of modern hardware don't really support true 24-bit mode, but this app probably would support it. On 3/18/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > Am Samstag, 18. März 2006 07:59 schrieb pagefault: > > Updated again, this should be the final patch. Sorry for spamming. :) > > > This patch actually made it somewhat worse. Mirage shows the same bug as with > your previous patch, only draws the backgound but no widgets. The background, > however, is grey (which is correct), not blue as it used to be without your > patch. Aura shows the missing widgets bug like before, but the background is > transparent instead of light grey with your new patch applied. > > -- > Willie Sippel > > //////// | Tritium Studios > // | ______________________________ > //// /// | http://www.tritium-studios.com > > <willie(a)froq.net> > > >

March 19, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Mike McCormack

Robert Shearman wrote: >>Despite containing some useful macros, those macros are somewhat >>broken as they are ignorant of UNICODE, so cannot be "fixed" by simple >>conversion to inline functions. > > Unicode isn't a problem as "void *" could simply be used, but there are > other compatibility reasons why inline functions shouldn't be used. Using the following example: #define ComboBox_AddString(hwndCtl, lpsz) \ ((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L, (LPARAM)(LPCTSTR)(lpsz))) In Wine source, UNICODE is not defined. So should the above be using SendMessageW/LPCWSTR or SendMessageA/LPCSTR? Furthermore, using an inline function requires that we've included winuser.h to get the definition of SendMessageA/W, whereas windowsx.h on its own doesn't require that. The commctrl.h macros don't have this problem as they define A/W versions of the macros. I am in the process of adding inline functions to commctrl.h, and will submit a patch for that soon. Mike

March 19, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Mike McCormack

Robert Shearman wrote: > Why don't we fix the macros as suggested by Francois, rather than > preventing its use? It seems like a big waste of time to have submitted > all of the patches to the files using windowsx.h when fixing the macros > is necessary for Winelib anyway. No, it's not a waste of time. Having warning free Wine source code is far more important than any warnings that might be in 3rd party winelib code. Francois' solution is still not perfect, as it requires use of a non-portable C construct. Mike

March 19, 2006

Re: Function counting script

by Segin

It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one. Think before you speak. P.S. I'll add a C interpeter when there becomes a need for one. Joris Huizer wrote: > Segin wrote: > >> As my small contribution, attached is a small shell script that, >> unmodified, finds out how many times certain functions are called in >> a given sample of files. The default functions are 'malloc', >> 'realloc', and 'free', and the sample files are all files ending in >> .c in the current directory. It even prints out the result in a neat >> manner on ANSI colourized terminals. >> >> The script is very flexible, and easy to modify. >> >> Current version is 256bytes long. >> >> >> ------------------------------------------------------------------------ >> >> > > Hmmm, I'm affraid this isn't telling much, consider: > > int main() > { > int i; > char *ptr; > for (i = 0; i < 10; i++) > ptr = malloc(20); > free(ptr); > return 0; > } > > you're script will report one 'malloc' and one 'free', but ten times a > 'malloc' is executed and only one 'free' ... :-/ > > >

March 19, 2006

Re: Function counting script

by Joris Huizer

Segin wrote: > As my small contribution, attached is a small shell script that, > unmodified, finds out how many times certain functions are called in a > given sample of files. The default functions are 'malloc', 'realloc', > and 'free', and the sample files are all files ending in .c in the > current directory. It even prints out the result in a neat manner on > ANSI colourized terminals. > > The script is very flexible, and easy to modify. > > Current version is 256bytes long. > > > ------------------------------------------------------------------------ > > Hmmm, I'm affraid this isn't telling much, consider: int main() { int i; char *ptr; for (i = 0; i < 10; i++) ptr = malloc(20); free(ptr); return 0; } you're script will report one 'malloc' and one 'free', but ten times a 'malloc' is executed and only one 'free' ... :-/

March 18, 2006

Function counting script

by Segin

As my small contribution, attached is a small shell script that, unmodified, finds out how many times certain functions are called in a given sample of files. The default functions are 'malloc', 'realloc', and 'free', and the sample files are all files ending in .c in the current directory. It even prints out the result in a neat manner on ANSI colourized terminals. The script is very flexible, and easy to modify. Current version is 256bytes long.

March 18, 2006

Re: How hard would it be to support Java?

by Dan Kegel

Christoph wrote: >>Quite a few apps use embedded JVM's. >>Case in point: SPSS, one of the apps requested by Munich. > > WTF? > There is a JVM for Linux available. > To my mind contact the manufacture of your software and explain to them > that Java is platform independent ... As Joris pointed out, many apps are not pure java. Instead, they are Windows apps that load the JVM somewhere in the middle, perhaps using the JNI interface. Untangling that mess to let the Windows app part talk to a Linux JVM would be a can of worms. Sadly, the only realistic way to get apps like the SPSS client running on Linux in the next year or two may be Wine. And that means getting Sun's JVM running on Wine. When you think about it, supporting Sun's JVM on Wine is a good idea. That would let us use Java's regression test suite as an additional Wine regression test. This goes for OpenOffice, too. - Dan

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Samstag, 18. März 2006 07:59 schrieb pagefault: > Updated again, this should be the final patch. Sorry for spamming. :) > This patch actually made it somewhat worse. Mirage shows the same bug as with your previous patch, only draws the backgound but no widgets. The background, however, is grey (which is correct), not blue as it used to be without your patch. Aura shows the missing widgets bug like before, but the background is transparent instead of light grey with your new patch applied. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

Re: How hard would it be to support Java?

by Joris Huizer

Christoph wrote: > Dan Kegel schrieb: > >>Quite a few apps use embedded JVM's. >>Case in point: SPSS, one of the apps requested by Munich. > > > WTF? > There is a JVM for Linux available. > To my mind contact the manufacture of your software and explain to them > that Java is platform independent ... > Having it available for linux is not enough, at least wine would need to offer a wrapper dll that forwards java calls to the java engine (as executables try to hook into a java dll, and just fail if it isn't available) - the better option would ofcourse be... getting java working; I have no idea how hard that wrapper dll would be though HTH, Joris

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Samstag, 18. März 2006 06:53 schrieb pagefault: > Ok, this is rather odd. Do those apps work properly when the patch is > not applied? Also do you know if these apps are using DirectDraw? > Like I said, Aura used to work. Mirage used to have drawing errors, but completely different from the errors introduced by your patch. A demo of Mirage is available at: http://www.bauhaussoftware.com/downloads/Trials/download_MIRAGE_PC.aspx And Aura at: ftp://ftp.newtek.com/pub/Aura/Patches/AVP25_installer.exe Both applications are able to use DDraw for the canvas AFAIK, but DDraw is not used for the GUI. I'll check your updated patch and report again later. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Martin Fuchs

2006/3/18, Robert Shearman <rob(a)codeweavers.com>: > Mike McCormack wrote: > > > > > Martin Fuchs wrote: > > > >> "Eliminating" windowsx.h sounds like you consider this header file a > >> bad thing. > >> I don't think so - it provides a bunch of very usefull type safe > >> macro definitions. > >> (SelectFont, ListBox_SetSel, Button_SetCheck, ...) > >> > >> I understand you want to eliminate some useless warnings printed by > >> newer GCC versions. Wouldn't it be better to correct the wrong warnings > >> of GCC instead? > > > > I agree with this comment that we shouldn't remove the uses of these > macros, but I have to disagree with them being typesafe - they aren't. Well, I meant kind of "type safe" in this sense: You can use SelectFont instead of SelectObject and now you are working with a font handle - not just any type of GDI handle. Or you can use SelectBitmap instead of the plain SelectObject API call... Of course the macros are not type safe in the sense of C++ type safety. Regards, Martin

March 18, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Jacek Caban

Robert Shearman wrote: > Mike McCormack wrote: > > >> +#ifdef __WINESRC__ >> +/* This file contains macros that cause warnings on gcc 4.1, so avoid it. */ >> +#error Please avoid use of windowsx.h in Wine source code. >> +#endif >> + >> >> > > Why don't we fix the macros as suggested by Francois, rather than > preventing its use? It seems like a big waste of time to have submitted > all of the patches to the files using windowsx.h when fixing the macros > is necessary for Winelib anyway. > There is one more solution that wasn't mentioned here. How about using a form like: (void)ListView_GetItem(...); It's a fix on the caller side, but it's really a minimal change and it could be even done by a script. BTW I agree that code like that looks ugly. Jacek

March 18, 2006

Re: shlwapi: Fix compilaction with GCC 4.1.

by Jacek Caban

Robert Shearman wrote: > Jacek Caban wrote: > > >> Without this patch GCC 4.1 fails with message >> string.c:531: undefined reference to `strncmpW' >> >> >> > > That would seem to be a bug in GCC 4.1. I'm no expert on the C spec, but > if the compiler can't inline the function, as it can't here when a > function pointer is used then I think it should include the static > version of the function in the object file. > Yeah, that's what I'd expect gcc should do, but if there is a bug in official release of gcc that is easy to workaround, we should do it in Wine IMO. Can anyone confirm that it's really a bug in gcc (I'm not C spec expert too)? Jacek

March 18, 2006

Re: shlwapi: Fix compilaction with GCC 4.1.

by Robert Shearman

Jacek Caban wrote: >Without this patch GCC 4.1 fails with message >string.c:531: undefined reference to `strncmpW' > > That would seem to be a bug in GCC 4.1. I'm no expert on the C spec, but if the compiler can't inline the function, as it can't here when a function pointer is used then I think it should include the static version of the function in the object file. -- Rob Shearman

March 18, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Robert Shearman

Mike McCormack wrote: > > Martin Fuchs wrote: > >> "Eliminating" windowsx.h sounds like you consider this header file a >> bad thing. >> I don't think so - it provides a bunch of very usefull type safe >> macro definitions. >> (SelectFont, ListBox_SetSel, Button_SetCheck, ...) >> >> I understand you want to eliminate some useless warnings printed by >> newer GCC versions. Wouldn't it be better to correct the wrong warnings >> of GCC instead? > I agree with this comment that we shouldn't remove the uses of these macros, but I have to disagree with them being typesafe - they aren't. > > Please see my previous email for a discussion of the problem: > > http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html > > Despite containing some useful macros, those macros are somewhat > broken as they are ignorant of UNICODE, so cannot be "fixed" by simple > conversion to inline functions. Unicode isn't a problem as "void *" could simply be used, but there are other compatibility reasons why inline functions shouldn't be used. -- Rob Shearman

March 18, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Robert Shearman

Mike McCormack wrote: >+#ifdef __WINESRC__ >+/* This file contains macros that cause warnings on gcc 4.1, so avoid it. */ >+#error Please avoid use of windowsx.h in Wine source code. >+#endif >+ > Why don't we fix the macros as suggested by Francois, rather than preventing its use? It seems like a big waste of time to have submitted all of the patches to the files using windowsx.h when fixing the macros is necessary for Winelib anyway. -- Rob Shearman

March 18, 2006

Re: How hard would it be to support Java?

by Christoph

Dan Kegel schrieb: > Quite a few apps use embedded JVM's. > Case in point: SPSS, one of the apps requested by Munich. WTF? There is a JVM for Linux available. To my mind contact the manufacture of your software and explain to them that Java is platform independent ... > > So I played around a bit with Sun's latest 1.5 JRE. > It can run trivial apps, so I closed > http://bugs.winehq.org/show_bug.cgi?id=2953 > (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). > > But it can't run applets; first, it runs into a nasty glx error, > http://bugs.winehq.org/show_bug.cgi?id=4143 > > Once you patch your way past that, it complains about not finding > a native method, see > http://bugs.winehq.org/show_bug.cgi?id=4873 > > And it doesn't show up in Firefox's about:plugins by default, see > http://bugs.winehq.org/show_bug.cgi?id=4860 > > Can anyone shed some light on these, especially bug 4143? > Thanks, > Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > >

March 18, 2006

Re: rpaths not working?

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: > And sure enough the .dll.so files don't have an $ORIGIN/../ runpath in them. > This seems like winebuild magic, at least, I didn't see any obvious places > in the build system to add the flags. Any idea what's going wrong here? AFAIK the rpath of the main binary is supposed to apply to dependencies too, not sure why it doesn't in your case. What libc version is that? -- Alexandre Julliard julliard(a)winehq.org

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Updated again, this should be the final patch. Sorry for spamming. :) On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Updated my patch. I had placed it in the wrong function, this is a lot > lower in the pipeline and should not conflict with other code. Please > test. > > --- dlls/gdi/dc2.c 2006-03-18 00:46:11.000000000 -0500 > +++ dlls/gdi/dc.c 2006-03-15 09:50:32.000000000 -0500 > @@ -905,11 +905,6 @@ > } > GDI_ReleaseObj( hdc ); > } > - > - // Windows returns a 32-bit depth (24-bit effective) > - > - if (caps == BITSPIXEL && ret == 24) ret = 32; > - > return ret; > } > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Ok, this is rather odd. Do those apps work properly when the patch is > > not applied? Also do you know if these apps are using DirectDraw? > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > Thanks for testing it out. I will try to get a copy of these apps and > > > figure out whats going on. > > > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > > Thanks for testing it out. I will try to get a copy of these apps and > > > > figure out whats going on. > > > > > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > > > Hi there, I work on ZSNES and I was trying to get it working > under > > > > > > wine and I ran into a small bug when running under a 32 bit > > desktop. > > > > > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return > the > > > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. > I > > > > > > have seen in the code where it does change the 24 to 32, but I > have > > > > > > discovered a spot where this has been missed. > > > > > > > > > > > > The following is the changes I made, it simply returns 32 if the > > user > > > > > > has a 24 bit desktop. > > > > > > > > > > > With your patch applied, two applications I tested (Newtek Aura and > > Bauhaus/ > > > > > TVPaint Mirage) show an odd bug. Only the window background gets > > drawn, but > > > > > all the widgets are missing, or, more precisely, invisible. Both > > applications > > > > > use their own toolkit - Mirage is infact Aura's successor, so their > > drawing > > > > > code should be very similar. But Aura's used to work, while > Mirage's > > always > > > > > produced borked results - painting stuff blue and distorted instead > of > > gray. > > > > > > > > > > -- > > > > > Willie Sippel > > > > > > > > > > //////// | Tritium Studios > > > > > // | ______________________________ > > > > > //// /// | http://www.tritium-studios.com > > > > > > > > > > <willie(a)froq.net> > > > > > > > > > > > > > > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Updated my patch. I had placed it in the wrong function, this is a lot lower in the pipeline and should not conflict with other code. Please test. --- dlls/gdi/dc2.c 2006-03-18 00:46:11.000000000 -0500 +++ dlls/gdi/dc.c 2006-03-15 09:50:32.000000000 -0500 @@ -905,11 +905,6 @@ } GDI_ReleaseObj( hdc ); } - - // Windows returns a 32-bit depth (24-bit effective) - - if (caps == BITSPIXEL && ret == 24) ret = 32; - return ret; } On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Ok, this is rather odd. Do those apps work properly when the patch is > not applied? Also do you know if these apps are using DirectDraw? > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Thanks for testing it out. I will try to get a copy of these apps and > > figure out whats going on. > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > Thanks for testing it out. I will try to get a copy of these apps and > > > figure out whats going on. > > > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > > Hi there, I work on ZSNES and I was trying to get it working under > > > > > wine and I ran into a small bug when running under a 32 bit > desktop. > > > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > > > have seen in the code where it does change the 24 to 32, but I have > > > > > discovered a spot where this has been missed. > > > > > > > > > > The following is the changes I made, it simply returns 32 if the > user > > > > > has a 24 bit desktop. > > > > > > > > > With your patch applied, two applications I tested (Newtek Aura and > Bauhaus/ > > > > TVPaint Mirage) show an odd bug. Only the window background gets > drawn, but > > > > all the widgets are missing, or, more precisely, invisible. Both > applications > > > > use their own toolkit - Mirage is infact Aura's successor, so their > drawing > > > > code should be very similar. But Aura's used to work, while Mirage's > always > > > > produced borked results - painting stuff blue and distorted instead of > gray. > > > > > > > > -- > > > > Willie Sippel > > > > > > > > //////// | Tritium Studios > > > > // | ______________________________ > > > > //// /// | http://www.tritium-studios.com > > > > > > > > <willie(a)froq.net> > > > > > > > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Ok, this is rather odd. Do those apps work properly when the patch is not applied? Also do you know if these apps are using DirectDraw? On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Thanks for testing it out. I will try to get a copy of these apps and > figure out whats going on. > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Thanks for testing it out. I will try to get a copy of these apps and > > figure out whats going on. > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > Hi there, I work on ZSNES and I was trying to get it working under > > > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > > have seen in the code where it does change the 24 to 32, but I have > > > > discovered a spot where this has been missed. > > > > > > > > The following is the changes I made, it simply returns 32 if the user > > > > has a 24 bit desktop. > > > > > > > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ > > > TVPaint Mirage) show an odd bug. Only the window background gets drawn, but > > > all the widgets are missing, or, more precisely, invisible. Both applications > > > use their own toolkit - Mirage is infact Aura's successor, so their drawing > > > code should be very similar. But Aura's used to work, while Mirage's always > > > produced borked results - painting stuff blue and distorted instead of gray. > > > > > > -- > > > Willie Sippel > > > > > > //////// | Tritium Studios > > > // | ______________________________ > > > //// /// | http://www.tritium-studios.com > > > > > > <willie(a)froq.net> > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Thanks for testing it out. I will try to get a copy of these apps and figure out whats going on. On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Thanks for testing it out. I will try to get a copy of these apps and > figure out whats going on. > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > Hi there, I work on ZSNES and I was trying to get it working under > > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > current bitdepth of the desktop. It is my understanding that X11 > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > have seen in the code where it does change the 24 to 32, but I have > > > discovered a spot where this has been missed. > > > > > > The following is the changes I made, it simply returns 32 if the user > > > has a 24 bit desktop. > > > > > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ > > TVPaint Mirage) show an odd bug. Only the window background gets drawn, but > > all the widgets are missing, or, more precisely, invisible. Both applications > > use their own toolkit - Mirage is infact Aura's successor, so their drawing > > code should be very similar. But Aura's used to work, while Mirage's always > > produced borked results - painting stuff blue and distorted instead of gray. > > > > -- > > Willie Sippel > > > > //////// | Tritium Studios > > // | ______________________________ > > //// /// | http://www.tritium-studios.com > > > > <willie(a)froq.net> > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Freitag, 17. März 2006 20:12 schrieb pagefault: > Hi there, I work on ZSNES and I was trying to get it working under > wine and I ran into a small bug when running under a 32 bit desktop. > > This fixed a bug in the DeviceGetCaps() function used to return the > current bitdepth of the desktop. It is my understanding that X11 > returns "24" as the bitdepth while running a 32 bit framebuffer. I > have seen in the code where it does change the 24 to 32, but I have > discovered a spot where this has been missed. > > The following is the changes I made, it simply returns 32 if the user > has a 24 bit desktop. > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ TVPaint Mirage) show an odd bug. Only the window background gets drawn, but all the widgets are missing, or, more precisely, invisible. Both applications use their own toolkit - Mirage is infact Aura's successor, so their drawing code should be very similar. But Aura's used to work, while Mirage's always produced borked results - painting stuff blue and distorted instead of gray. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

How hard would it be to support Java?

by Dan Kegel

Quite a few apps use embedded JVM's. Case in point: SPSS, one of the apps requested by Munich. So I played around a bit with Sun's latest 1.5 JRE. It can run trivial apps, so I closed http://bugs.winehq.org/show_bug.cgi?id=2953 (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). But it can't run applets; first, it runs into a nasty glx error, http://bugs.winehq.org/show_bug.cgi?id=4143 Once you patch your way past that, it complains about not finding a native method, see http://bugs.winehq.org/show_bug.cgi?id=4873 And it doesn't show up in Firefox's about:plugins by default, see http://bugs.winehq.org/show_bug.cgi?id=4860 Can anyone shed some light on these, especially bug 4143? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Samstag, 18. März 2006 02:33 schrieb Tony Lambregts: > pagefault wrote: > > Hi there, I work on ZSNES and I was trying to get it working under > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > current bitdepth of the desktop. It is my understanding that X11 > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > have seen in the code where it does change the 24 to 32, but I have > > discovered a spot where this has been missed. > > > > The following is the changes I made, it simply returns 32 if the user > > has a 24 bit desktop. > > > > I could also post code which exposes this bug if needed. > > > > *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 > > --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 > > *************** > > *** 190,196 **** > > case VERTRES: > > return screen_height; > > case BITSPIXEL: > > ! return screen_depth; > > case PLANES: > > return 1; > > case NUMBRUSHES: > > --- 190,196 ---- > > case VERTRES: > > return screen_height; > > case BITSPIXEL: > > ! return (screen_depth == 24) ? 32 : screen_depth; > > case PLANES: > > return 1; > > case NUMBRUSHES: > > > > > > > > Thanks. > > does this actually fix it so that some program works that did not before? > > I'm not the expert for this area (X-11) but here are a couple of comments. > Patches for wine are in "diff -u format and if you want it included to wine > it is best submit it to wine-patches(a)winehq.org with a change log. IE: > > Change log: Fix GetDevCaps for 32 bit screen depth. Well, I know at least one problem this patch might fix - with DAZ|Studio. It worked with WINVER=win98, but with w2k or xp, an error message popped up ("DAZ|Studio requires 32bit color depth" or something"), and the program exited. I think more recent versions of DAZ|Studio still give the error message but continue to load. Haven't tested the program in the last few months, though (it's unusable as it uses OpenGL viewports)... -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Tony Lambregts

pagefault wrote: > Hi there, I work on ZSNES and I was trying to get it working under > wine and I ran into a small bug when running under a 32 bit desktop. > > This fixed a bug in the DeviceGetCaps() function used to return the > current bitdepth of the desktop. It is my understanding that X11 > returns "24" as the bitdepth while running a 32 bit framebuffer. I > have seen in the code where it does change the 24 to 32, but I have > discovered a spot where this has been missed. > > The following is the changes I made, it simply returns 32 if the user > has a 24 bit desktop. > > I could also post code which exposes this bug if needed. > > *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 > --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 > *************** > *** 190,196 **** > case VERTRES: > return screen_height; > case BITSPIXEL: > ! return screen_depth; > case PLANES: > return 1; > case NUMBRUSHES: > --- 190,196 ---- > case VERTRES: > return screen_height; > case BITSPIXEL: > ! return (screen_depth == 24) ? 32 : screen_depth; > case PLANES: > return 1; > case NUMBRUSHES: > > > > Thanks. > > > does this actually fix it so that some program works that did not before? I'm not the expert for this area (X-11) but here are a couple of comments. Patches for wine are in "diff -u format and if you want it included to wine it is best submit it to wine-patches(a)winehq.org with a change log. IE: Change log: Fix GetDevCaps for 32 bit screen depth.

March 18, 2006

Re: kernel32: fix last error result on CreateFile

by Mike McCormack

Víctor Manuel Álvarez García wrote: > If CreateFile is called with CREATE_ALWAYS or > OPEN_ALWAYS flags, and the file already exists, the > function should success but the result of GetLastError > after the call must be ERROR_ALREADY_EXISTS. Wine was > not not setting the proper error code and GetLastError > just returned ERROR_SUCCESS. > > Wine is great, good work guys! > > Here goes my contribution, Thanks for the contribution! It would be great to write a test for this behaviour too, and add it to dlls/kernel/tests/file.c Mike

March 18, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Mike McCormack

Martin Fuchs wrote: > "Eliminating" windowsx.h sounds like you consider this header file a bad thing. > I don't think so - it provides a bunch of very usefull type safe macro definitions. > (SelectFont, ListBox_SetSel, Button_SetCheck, ...) > > I understand you want to eliminate some useless warnings printed by > newer GCC versions. Wouldn't it be better to correct the wrong warnings > of GCC instead? Please see my previous email for a discussion of the problem: http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html Despite containing some useful macros, those macros are somewhat broken as they are ignorant of UNICODE, so cannot be "fixed" by simple conversion to inline functions. Mike

March 18, 2006

re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462 (revised)

by Dan Kegel

Brian wrote: + /* FIXME: EM_GETSEL needs to return proper ending value */ + todo_wine + { + ok(start == 0 && end == 18, "EM_EXSETSEL: expected (0,18) actual:(%d,%d)\n", start,end); + } What does EM_GETSEL return right now? It might be worth looking at that to see if you can fix it in the same patch, if it's easy. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: Wine and RDPRINT

by Mariusz Kiełpiński

Dnia piątek, 17 marca 2006 14:35, Frederico Bertucci napisał: Hi > Good morning guys > > I did my system works with wine no problem, but when I try print using > then, doesnt work... if I print from any other aplication, works. > > I talked with my developer and he told me that are using a delphi componet > called RDPRINT, this in windows, to create better graphics. > > So, Are there any way to print in wine, using this RDPRINT ?? any dll, any > configuration > > I am using latest wine configured with winetools, the printer is a lx300. > > I am trying do this works since 2 weeks ago and not sucefull > > Tks guys > > try this patch ================================= wine.15.03.06.19.02.59.diff ? dlls/msvideo/Makefile ? dlls/win32s/Makefile ? dlls/winsock/Makefile ? dlls/winsock/libws2_32.def ? dlls/winsock/version.res ? dlls/winsock/tests/Makefile ? dlls/winsock/tests/testlist.c Index: dlls/gdi/printdrv.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v retrieving revision 1.46 diff -u -p -1 -r1.46 printdrv.c --- dlls/gdi/printdrv.c 12 Sep 2005 10:30:06 -0000 1.46 +++ dlls/gdi/printdrv.c 15 Mar 2006 18:03:01 -0000 @@ -471,3 +471,3 @@ static int CreateSpoolFile(LPCSTR pszOut if (!psCmd[0] && !strncmp("LPR:",pszOutput,4)) - sprintf(psCmd,"|lpr -P%s",pszOutput+4); + sprintf(psCmd,"|lp -d'%s' ",pszOutput+4); =======================================

March 17, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Martin Fuchs

Hi, "Eliminating" windowsx.h sounds like you consider this header file a bad thing. I don't think so - it provides a bunch of very usefull type safe macro definitions. (SelectFont, ListBox_SetSel, Button_SetCheck, ...) I understand you want to eliminate some useless warnings printed by newer GCC versions. Wouldn't it be better to correct the wrong warnings of GCC instead? Regards, Martin

March 17, 2006

PATCH: GetDevCaps() bitdepth flag

by pagefault

Hi there, I work on ZSNES and I was trying to get it working under wine and I ran into a small bug when running under a 32 bit desktop. This fixed a bug in the DeviceGetCaps() function used to return the current bitdepth of the desktop. It is my understanding that X11 returns "24" as the bitdepth while running a 32 bit framebuffer. I have seen in the code where it does change the 24 to 32, but I have discovered a spot where this has been missed. The following is the changes I made, it simply returns 32 if the user has a 24 bit desktop. I could also post code which exposes this bug if needed. *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 *************** *** 190,196 **** case VERTRES: return screen_height; case BITSPIXEL: ! return screen_depth; case PLANES: return 1; case NUMBRUSHES: --- 190,196 ---- case VERTRES: return screen_height; case BITSPIXEL: ! return (screen_depth == 24) ? 32 : screen_depth; case PLANES: return 1; case NUMBRUSHES: Thanks.

March 17, 2006

Re: PATCH: Re: Problem with virtual memory rlimits

by Marcus Meissner

On Fri, Mar 17, 2006 at 06:10:40PM +0100, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > Got an idea... > > > > It helps if the process is started with the ADDR_COMPAT_LAYOUT personality > > flag set. > > We should still be reserving the high memory area, so it shouldn't > make any difference WRT ulimits. Something else must be going on here. Umm, I actually commented out this reservation in our RPMs *whistle innocently* :) If I add it back in the original behaviour (out of memory) is still there with or without my patch. Again I am out of ideas, short of writing WINEs own virtual memory manager. Ciao, Marcus

March 17, 2006

Re: PATCH: Re: Problem with virtual memory rlimits

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > Got an idea... > > It helps if the process is started with the ADDR_COMPAT_LAYOUT personality > flag set. We should still be reserving the high memory area, so it shouldn't make any difference WRT ulimits. Something else must be going on here. -- Alexandre Julliard julliard(a)winehq.org

March 17, 2006

Re: wglMakeCurrent

by Wino Rojo

> >It is accelerated, and it uses Mesa too. If it wasn't, it would say >indirect renderer. oops, my mistake.. I missed the line "Direct Rendering: Yes" _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 17, 2006

PATCH: Re: Problem with virtual memory rlimits

by Marcus Meissner

On Fri, Feb 24, 2006 at 02:12:46PM +0100, Marcus Meissner wrote: > Hi, > > I am having a problem with virtual ulimits/rlimits. > > If you limit the virtual memory size using "ulimit -v 1400000" for > instance, wine will only crash. > > The problem is, that VIRTUAL_alloc_teb() tries to allocate a memory > area within the acceptable userspace ... but it does so much mmap()s > that it runs out of available mmap space before. > > I was only able to reproduce this on AMD64 machines up to now, > which pass out memory starting from 0xf7fffffff somewhere. > > Any clue how to solve this? Got an idea... It helps if the process is started with the ADDR_COMPAT_LAYOUT personality flag set. So if we are running without it, we can just set the personality and execve ourselves. Btw, this trick might even help execshield and avoid the need for the preloader at all, but I do not have Fedora/Redhat here to test. Ciao, Marcus Changelog: Change to ADDR_COMPAT_LAYOUT personality to avoid problems with AMD64 memory layout and ulimits set. Index: loader/preloader.c =================================================================== RCS file: /home/wine/wine/loader/preloader.c,v retrieving revision 1.20 diff -u -r1.20 preloader.c --- loader/preloader.c 6 Feb 2006 13:35:58 -0000 1.20 +++ loader/preloader.c 17 Mar 2006 15:36:21 -0000 @@ -208,6 +208,14 @@ return SYSCALL_RET(ret); } +static inline int wld_personality( int perso ) +{ + int ret; + __asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" + : "=a" (ret) : "0" (SYS_personality), "r" (perso) ); + return SYSCALL_RET(ret); +} + static inline ssize_t wld_read( int fd, void *buffer, size_t len ) { int ret; @@ -226,6 +234,14 @@ return SYSCALL_RET(ret); } +static inline int wld_execve( const char * path, char **argv, char ** envp ) +{ + int ret; + __asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" + : "=a" (ret) : "0" (SYS_execve), "r" (path), "c" (argv), "d" (envp) ); + return SYSCALL_RET(ret); +} + static inline int wld_mprotect( const void *addr, size_t len, int prot ) { int ret; @@ -886,6 +902,7 @@ ElfW(auxv_t) new_av[12], delete_av[3], *av; struct wld_link_map main_binary_map, ld_so_map; struct wine_preload_info **wine_main_preload_info; + unsigned int perso; pargc = *stack; argv = (char **)pargc + 1; @@ -894,6 +911,14 @@ /* skip over the parameters */ p = argv + *pargc + 1; + perso = wld_personality(0xffffffff); + if (!(perso & 0x200000)) { + wld_personality(perso | 0x200000); + wld_execve(argv[0],argv,p); + fatal_error( "Failed execve %s\n", argv[0] ); + return NULL; + } + /* skip over the environment */ while (*p) {

March 17, 2006

A few apps Munich was interested in

by Dan Kegel

I've been trying to figure out why Munich doesn't like Wine for some time. Here's what I've learned: In 2004 six apps were briefly tested by ITOMIG under both plain Wine and Crossover Office 3.0.1 as part of initial studies for the Munich migration to Linux. The test results aren't especially important (wine has progressed since then), but it's interesting to know which apps were tested. Here's a list of the apps, along with links to related Wine bugs. SPSS11 - statistics http://spss.com (free trial!) Bugs: http://bugs.winehq.org/show_bug.cgi?id=3038 (multiple problems) http://bugs.winehq.org/show_bug.cgi?id=2953 (Sun's JVM crashes on trivial app, fixed?) http://bugs.winehq.org/show_bug.cgi?id=4860 (Sun's JVM doesn't work for applet, not really related, but an indication that java isn't happy) Keeptool5-Hora - Entity Relationship diagrammer, SQL debugger http://keeptool.com/de/keeptool_hora.php (free trial!) Bugs: http://bugs.winehq.org/show_bug.cgi?id=4801 (app locks up on some systems?) http://bugs.winehq.org/show_bug.cgi?id=4802 (Oracle client library won't install) Frontpage2000 - Microsoft Office 2000's html editor Mephisto - a specialized app built using MS Access Darwin - a specialized app used in tourism offices; needs a dongle (For more info, contact stefan.munz at itomig.de.) Until apps like these work well under Wine, cities like Munich are unlikely to use Wine as part of their migration to Linux desktops. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

On 3/17/06, Joachim von Thadden <thadden(a)web.de> wrote: > Am Do, Mär 16, 2006 at 11:41:53 -0800 schrieb Dan Kegel: > > Instead, it should just be a couple of checkboxes for > > optional things like dcom98 and IE6, shouldn't it? > > I think this is not enough. After you installed IE6 how do you want to > disable it? Many apps are looking directly for it. They will behave > different in that case. Or did I misunderstood? Once you've installed IE6 or dcom98, they're there for good. I just want to make sure you don't encourage users to install them. One other thing we need is an easy way to defeat those checks for particular versions of IE. For instance, many apps check one registry key, and some apps check for one particular DLL (it can be zero size, even!). Wine itself should probably come with a shell script that creates these, and wineconf and/or your tool should provide an easy way to run it... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Wine and RDPRINT

by Frederico Bertucci

Good morning guys I did my system works with wine no problem, but when I try print using then, doesnt work... if I print from any other aplication, works. I talked with my developer and he told me that are using a delphi componet called RDPRINT, this in windows, to create better graphics. So, Are there any way to print in wine, using this RDPRINT ?? any dll, any configuration I am using latest wine configured with winetools, the printer is a lx300. I am trying do this works since 2 weeks ago and not sucefull Tks guys -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

March 17, 2006

Re: Add a test for bitmap font metrics to ensure that they match the Windows ones

by Dmitry Timoshkov

"Huw Davies" <huw(a)codeweavers.com> wrote: >> Looks like it's a sfnt2fnt bug and not a fontforge or FreeType problem. >> >> This patch tests bitmap font metrics to ensure that they match the Windows >> ones. The patch discovers a bug in sfnt2fnt which causes Courier font to >> have wrong ascent and descent values (13/0 instead of 11/2). courier.ttf >> generated by fontforge from courier.sfd has correct values, but courier-*.fnt >> files have wrong values. > > Well we get the ascent from the height of the Aring glyph. As far as > I can tell this is 11 in fontforge. So somewhere between fontforge's > export as a ttf and sfnt2fnt reading that ttf (using FreeType) the > value has changed to 13. Hence my comment that either fontforge or > FreeType is doing something odd. I was going to point out that I tried to replace in tools/sfnt2fnt.c ascent = face->glyph->metrics.height >> 6; by ascent = face->size->metrics.ascender >> 6; which is what is used in dlls/gdi/freetype.c,get_bitmap_text_metrics(), but that breaks MS Sans Serif bitmap fonts. It looks like fontforge doesn't allow to have a different font header for each different bitmap size in the bitmap font. -- Dmitry.

March 17, 2006

Re: Add a test for bitmap font metrics to ensure that they match the Windows ones

by Huw Davies

On Fri, Mar 17, 2006 at 02:01:41PM +0800, Dmitry Timoshkov wrote: > "Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > > > Looks like this might be a fontforge or FreeType problem. Windows > > courier at 13 ppem should have an ascent of 11 and a descent of 2, > > which is what we have in the .sfd. Now, when I run sfnt2fnt on the > > generated .ttf I get an ascent of 13, ppem of 13 and hence a descent > > of 0. > > > > I'm not going to have time to look into this soon, so please feel free > > to investigate more. > > Looks like it's a sfnt2fnt bug and not a fontforge or FreeType problem. > > This patch tests bitmap font metrics to ensure that they match the Windows > ones. The patch discovers a bug in sfnt2fnt which causes Courier font to > have wrong ascent and descent values (13/0 instead of 11/2). courier.ttf > generated by fontforge from courier.sfd has correct values, but courier-*.fnt > files have wrong values. Well we get the ascent from the height of the Aring glyph. As far as I can tell this is 11 in fontforge. So somewhere between fontforge's export as a ttf and sfnt2fnt reading that ttf (using FreeType) the value has changed to 13. Hence my comment that either fontforge or FreeType is doing something odd. Huw. -- Huw Davies huw(a)codeweavers.com

March 17, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Mike Hearn

There's a new patch to try here: http://plan99.net/~mike/files/glteb.patch Does that work any better?

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by brianch＠seas.ucla.edu

Indeed. Thanks for pointing that out. The modifications will be made and posted. > On Thu, 16 Mar 2006 22:31:40 -0800 (PST) > Brian Chang <brianch(a)seas.ucla.edu> wrote: > >> + /* get the current selection and text length */ >> + RichEditANSIWndProc(hWnd, EM_GETSEL, (WPARAM) &start, (LPARAM) >> &end); >> + textlen = RichEditANSIWndProc(hWnd, WM_GETTEXTLENGTH, 0, 0); > > This looks strange... Why not use ME_GetSelection() and > ME_GetTextLength()? > > -- Ph. > >

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Brian Chang

Hi Dan, Thanks again for the suggestions. I did indeed run the conformance tests on Windows -- passes with no problem. The conformance tests confirm that the return value is not the range. Good catch for the limiting of cpMax, it simplified the return logic. I also fixed the whitespace violations I found. Brian Dan Kegel wrote: >Nice touch including the link to the bug! > >Did you run the new test on Windows? > >+ if(range.cpMin < 0) >+ { >+ range.cpMin = end; >+ range.cpMax = end; >+ } >+ ... >+ >+ return (range.cpMax < textlen+1 ? range.cpMax : textlen+1) ; > >MSDN says the return value is the range, not just cpMax. Are they really wrong? >Also, I suspect you want to limit cpMax at the same time as you do cpMin, >not after the fact... otherwise aren't you passing an invalid cpMax to >ME_SetSelection() ? > >Finally, there are trivial whitespace style violations, I think >(missing space between if and the open paren). >- Dan > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv > >

March 17, 2006

Re: wglMakeCurrent

by Raphael

On Thursday 16 March 2006 10:21, Wino Rojo wrote: > Hi Raphael, > > >No it's use the "best visual" who match asked capacities > > - is this "best visual" the same as the one returned by "glxinfo -b" ? no the best matching caps asked by wine init (see X11DRV_setup_opengl_visual on x11drv/opengl.c and x11drv/x11drv_main.c) > - the capacities asked by who? at this point we haven't call > ChoosePixelFormat or SetPixelFormat yet Yes, but wine init need to setup a default visual at startup :( (and too many times it'll not compatible with future created visuals) > >No your problem don't seems to be here. > >can you send you glxinfo output. I presume you don't have glx1.3 support > >In this case wine don't be able to get a fb config compatible with wine > >window > >(one day we'll fix the wine init ...) > > This is the output of my glxinfo: > > According to this, I do have glx 1.3 Strange ... need to investigate what happened :( > Thanks, > > W. > Regards, Raphael > > PS. Guys, I'm sorry if I'm asking too many basic questions. I know about > OpenGL and some X-Window programming, but I'm just learning wine, and I'd > like to contribute to this amazing project, especially with the OpenGL/3D > graphics stuff. No problem, it's always good to see more people working on wine (specially directX/Opengl) :) I have no time to improve wine now but i have little time sufficient for mails :p

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Do, Mär 16, 2006 at 11:41:53 -0800 schrieb Dan Kegel: > Instead, it should just be a couple of checkboxes for > optional things like dcom98 and IE6, shouldn't it? I think this is not enough. After you installed IE6 how do you want to disable it? Many apps are looking directly for it. They will behave different in that case. Or did I misunderstood? Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 17, 2006

re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Dan Kegel

Nice touch including the link to the bug! Did you run the new test on Windows? + if(range.cpMin < 0) + { + range.cpMin = end; + range.cpMax = end; + } + ... + + return (range.cpMax < textlen+1 ? range.cpMax : textlen+1) ; MSDN says the return value is the range, not just cpMax. Are they really wrong? Also, I suspect you want to limit cpMax at the same time as you do cpMin, not after the fact... otherwise aren't you passing an invalid cpMax to ME_SetSelection() ? Finally, there are trivial whitespace style violations, I think (missing space between if and the open paren). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

On 3/16/06, Joachim von Thadden <thadden(a)web.de> wrote: > > >This is exactly what we try to have with the next version of WineTools. > > > > Right, but Mike meant "without installing any Microsoft libraries". > > Sure, that's why we integrate a "native Wine" mode. > > I think we are looking in the same direction now. Now you're talking! But I think it shouldn't really be a mode. Instead, it should just be a couple of checkboxes for optional things like dcom98 and IE6, shouldn't it? - Dan

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Do, Mär 16, 2006 at 05:13:15 -0800 schrieb Dan Kegel: > Joachim wrote: > >> IMO, the best thing for Wine would be to have a simple front end with a > >> list of freely downloadable applications that work "out of the box" with > >> no configuration changes. > >> > >> Click -> Download application -> Install -> Run > > > >This is exactly what we try to have with the next version of WineTools. > > Right, but Mike meant "without installing any Microsoft libraries". Sure, that's why we integrate a "native Wine" mode. I think we are looking in the same direction now. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Phil Krylov

On Thu, 16 Mar 2006 22:31:40 -0800 (PST) Brian Chang <brianch(a)seas.ucla.edu> wrote: > + /* get the current selection and text length */ > + RichEditANSIWndProc(hWnd, EM_GETSEL, (WPARAM) &start, (LPARAM) &end); > + textlen = RichEditANSIWndProc(hWnd, WM_GETTEXTLENGTH, 0, 0); This looks strange... Why not use ME_GetSelection() and ME_GetTextLength()? -- Ph.

March 17, 2006

re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

Joachim wrote: >> IMO, the best thing for Wine would be to have a simple front end with a >> list of freely downloadable applications that work "out of the box" with >> no configuration changes. >> >> Click -> Download application -> Install -> Run > >This is exactly what we try to have with the next version of WineTools. Right, but Mike meant "without installing any Microsoft libraries". - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/16/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Interesting... according to your log file, it seems you are using Mesa > instead of any ATI accelerated driver. > > It is accelerated, and it uses Mesa too. If it wasn't, it would say indirect renderer.

March 17, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Mike Hearn

On Thu, 16 Mar 2006 09:27:42 +0100, Leon Freitag wrote: > I'm getting undefined references to `___tls_get_addr' when trying to build > with this patch. However my ld has this symbol for sure... Odd. Worked for me, but it's probably something to do with the Wine build system. Here's a version that properly uses the TEB. Does it work any better? diff --git a/dlls/opengl32/Makefile.in b/dlls/opengl32/Makefile.in diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index 56c8ad1..71f7511 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -31,6 +31,8 @@ #include "winerror.h" #include "winreg.h" #include "wingdi.h" +#include "winternl.h" +#include "winnt.h" #include "wgl_ext.h" #include "opengl_ext.h" @@ -82,6 +84,7 @@ typedef struct wine_glcontext { XVisualInfo *vis; GLXFBConfig fb_conf; GLXContext ctx; + BOOL do_escape; struct wine_glcontext *next; struct wine_glcontext *prev; } Wine_GLContext; @@ -96,18 +99,13 @@ static inline Wine_GLContext *get_contex void enter_gl(void) { - GLXContext gl_ctx; - Wine_GLContext *ctx; - enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; - - wine_tsx11_lock_ptr(); - gl_ctx = glXGetCurrentContext(); - if(!gl_ctx) return; - ctx = get_context_from_GLXContext(gl_ctx); - wine_tsx11_unlock_ptr(); /* unlock before calling GDI apis */ - - if(ctx && GetObjectType(ctx->hdc) == OBJ_MEMDC) - ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + Wine_GLContext *curctx = (Wine_GLContext *) NtCurrentTeb()->glContext; + + if (curctx && curctx->do_escape) + { + enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; + ExtEscape(curctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + } wine_tsx11_lock_ptr(); return; @@ -541,6 +539,7 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, ENTER_GL(); if (hglrc == NULL) { ret = glXMakeCurrent(default_display, None, NULL); + NtCurrentTeb()->glContext = NULL; } else { Wine_GLContext *ctx = (Wine_GLContext *) hglrc; Drawable drawable = get_drawable( hdc ); @@ -571,8 +570,12 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, } TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); ret = glXMakeCurrent(ctx->display, drawable, ctx->ctx); + NtCurrentTeb()->glContext = ctx; if(ret && type == OBJ_MEMDC) + { + ctx->do_escape = TRUE; glDrawBuffer(GL_FRONT_LEFT); + } } LEAVE_GL(); TRACE(" returning %s\n", (ret ? "True" : "False"));

March 17, 2006

rpaths not working?

by Mike Hearn

Hi Alexandre, On my system at least it seems DLLs need the rpaths too, from a clean build of HQ git tree I get this when starting: 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; needed by /opt/wine/bin/../lib/libwine.so.1 [0] 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; generating link map 8697: dynamic: 0x7ffd52dc base: 0x7ff63000 size: 0x0007cb58 8697: entry: 0x7ff6f000 phdr: 0x7ff63034 phnum: 5 8697: 8697: 8697: file=libwine_unicode.so.1 [0]; needed by /opt/wine/lib/wine/ntdll.dll.so [0] 8697: 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; destroying link map wine: failed to initialize: libwine_unicode.so.1: cannot open shared object file: No such file or directory And sure enough the .dll.so files don't have an $ORIGIN/../ runpath in them. This seems like winebuild magic, at least, I didn't see any obvious places in the build system to add the flags. Any idea what's going wrong here? thanks -mike

March 17, 2006

getwinegit.sh 0.3 released!

by Christian Lachner

Weehaa, my getwinegit.sh-script now reached a next major version-step! It's not perfect but it should do it's job very smoothly. Here's, what has changed: 0.3_Yea, new features and some fixes ;) - Mode 4: installs an already compiled source - fixed a bug when mode was 3 and the target-dir was _not_ found - Now uses PID-Files to ensure, that getwinegit.sh does not run twice - very small enhancements in logger - Logfile is now stored at /var/log/ as default - small stuff I don't remember... again... - Granatenstark, Hoschi! ;) (who of you german speakings know bill and ted?) This release is meant to be a stable-version. IF there are bugs, then post them to wine-users. Questions? PLEASE read the readme-file and if you really can't sort things out, post to wine-users. Ok, that's it for now. greets, chris

March 16, 2006

re: riched20: implement EM_FINDWORDBREAK and its tests

by Dan Kegel

Brian Chang wrote: > ... > +#include <wctype.h> http://www.winehq.org/pipermail/wine-devel/2006-March/045373.html says: You can't use anything from wctype.h in Wine. Use the functions from wine/unicode.h instead. >+ /* Windows returns 0 if start is negative and len+1 if start is >= len */ >+ if(code != WB_ISDELIMITER) >+ { >+ if(start < 0) >+ return 0; >+ if(start > len) >+ return len+1; >+ } Do you test that in your conformance test? If not, please do. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 16, 2006

fonts

by Mihael Simonic

I am test to install Google Earth. It is work, but fonts not show. problem 1: how I configure fonts problem 2: not file (library) /system32/psapi.dll Greetings, Miha

March 16, 2006

Re: GDI32: Fix logical error of italic,bold determination

by Byeong-Sik Jeon

2006-03-15 (수), 14:50 +0000, Huw D M Davies 쓰시길: > On Mon, Mar 13, 2006 at 04:10:04AM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > Fix the logical error of the italic, bold determination. > > > > Index: dlls/gdi/freetype.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > > retrieving revision 1.114 > > diff -u -u -r1.114 freetype.c > > --- dlls/gdi/freetype.c 9 Mar 2006 12:30:52 -0000 1.114 > > +++ dlls/gdi/freetype.c 12 Mar 2006 10:01:22 -0000 > > + for(i = 0; !face && i < 4; ++i) { > > best = NULL; > > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > > face = LIST_ENTRY(face_elem_ptr, Face, entry); > > - if((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0]) { > > + if((!(face->Italic ^ it) ^ ((i >> 1) & 1)) && (!(face->Bold ^ bd) ^ (i & 1)) && > > + ((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0])) { > > > It doesn't seem right to compare these with 'i', the order of the faces is random. > > The right way to do this is to rewrite all this font matching code so > that we loop through the families and faces once and score each one. > At the end we pick the one with the lowest score. > > Huw. Hi. I'm late... A B A xor B 0 0 0 0 1 1 1 0 1 1 1 0 ===> 0 ^ A == A ^ 0 == A, 1 ^ A == A ^ 1 == !A This code is just a compression of my old patch [3/5]. but, this dirty code did not satisfy me too. I will rework this and others(FT_Bitmap_Convert, FT_Sfnt_Name). Thanks your advice. :)

March 16, 2006

Re: build stand alone binaries

by Tom Wickline

On 3/16/06, Dimi Paun <dimi(a)lattica.com> wrote: > From: "Benjamin Zeller" <zeller.benjamin(a)web.de> > > is it possible to build real elf binaries with winelib? > > If i go through the tutorial on winehq.org i get only a appname.exe.so > > and i have to invoke wine to start the application. > > Is it possible to compile a binary wich can run stand alone? > > No, you would still need the DLLs. It's like having a Win32 binary > that includes _all_ the DLLs that come with Windows. Also: http://winehq.org/site/docs/wine-faq/index See 9.4 Tom > > -- > Dimi Paun <dimi(a)lattica.com> > Lattica, Inc. > > >

March 16, 2006

Re: build stand alone binaries

by Dimi Paun

From: "Benjamin Zeller" <zeller.benjamin(a)web.de> > is it possible to build real elf binaries with winelib? > If i go through the tutorial on winehq.org i get only a appname.exe.so > and i have to invoke wine to start the application. > Is it possible to compile a binary wich can run stand alone? No, you would still need the DLLs. It's like having a Win32 binary that includes _all_ the DLLs that come with Windows. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 16, 2006

Re: wglMakeCurrent

by Wino Rojo

Interesting... according to your log file, it seems you are using Mesa instead of any ATI accelerated driver. >From: "Jesse Allen" <the3dfxdude(a)gmail.com> >To: "Wino Rojo" <winorojo(a)hotmail.com> >Subject: Re: wglMakeCurrent >Date: Wed, 15 Mar 2006 11:45:16 -0700 > > > > > > > Jesse, I can't access your log at that page (I got an error). Could you > > please send it to me? > > > > Thanks, > > > > W > >attachment ><< logfile >> _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 16, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi Raphael, >No it's use the "best visual" who match asked capacities - is this "best visual" the same as the one returned by "glxinfo -b" ? - the capacities asked by who? at this point we haven't call ChoosePixelFormat or SetPixelFormat yet >No your problem don't seems to be here. >can you send you glxinfo output. I presume you don't have glx1.3 support >In this case wine don't be able to get a fb config compatible with wine >window >(one day we'll fix the wine init ...) > This is the output of my glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float client glx vendor string: NVIDIA Corporation client glx version string: 1.3 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: NV41/PCI/SSE2/3DNOW! OpenGL version string: 2.0.0 NVIDIA 76.76 OpenGL extensions: GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fence, GL_NV_float_buffer, GL_NV_fog_distance, GL_NV_fragment_program, GL_NV_fragment_program_option, GL_NV_fragment_program2, GL_NV_half_float, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_primitive_restart, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_expand_normal, GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NV_vertex_program2, GL_NV_vertex_program2_option, GL_NV_vertex_program3, GL_NVX_conditional_render, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x23 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x2a 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x2f 24 tc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x30 24 tc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x31 24 tc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x32 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x33 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x34 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x35 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x36 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x37 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x38 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x39 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x3a 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x3b 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x3c 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x3d 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x3e 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x3f 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x40 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x41 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x42 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x43 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x44 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x45 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x46 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x47 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x48 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x49 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x4a 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x4b 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x4c 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x4d 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x4e 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x4f 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x50 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x51 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x52 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x53 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x54 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x55 24 dc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x56 24 dc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x57 24 dc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x58 24 dc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x59 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x5a 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x5b 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x5c 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x5d 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x5e 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x5f 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x60 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x61 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x62 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x63 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x64 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x65 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x66 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x67 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x68 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x69 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x6a 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x6b 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x6c 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x6d 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x6e 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x6f 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x70 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon According to this, I do have glx 1.3 Thanks, W. PS. Guys, I'm sorry if I'm asking too many basic questions. I know about OpenGL and some X-Window programming, but I'm just learning wine, and I'd like to contribute to this amazing project, especially with the OpenGL/3D graphics stuff. _________________________________________________________________ Scan and help eliminate destructive viruses from your inbound and outbound e-mail and attachments. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 16, 2006

Re: [RESEND] riched20: Fixed crash when the window procedure is called with NULL hWnd

by Alexandre Julliard

Phil Krylov <phil(a)newstar.rinet.ru> writes: > > ChangeLog: > > riched20: Fixed crash when the window procedure is called with NULL hWnd. You should check that you got a valid pointer from GetWindowLong, NULL is not the only invalid window handle you can get here. -- Alexandre Julliard julliard(a)winehq.org

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Tony Lambregts

Philip V. Neves wrote: > What I'm seeing here with the whole debate with wine and winetools is > that its a configuration management issue. The project is getting into > the stage where testing needs to be accomodated and so does getting > things working. I think whats currently available for managing > configurations to wine is innadequate. Even winecfg provides an > interface that is innadequate for making many changes in terms of dll > overrides. Plus it doesn't provide a mechanism for rolling those > changes back. Or even managing multiple configurations or modes so that > problems can be issolated. I think whats is comming out of the > winetools debate is better tools are needed for configuration > management. This isn't very revolutionary. Its a natural part of the > software development life cycle. As a project starts emerging from the > development phase ways to provide better configuration management start > showing themselves. > > Something that interfaces with the AppDB would be good. It would make > things easier. I think, given the complaints given by the developers are > also valid but so are the complaints made by the people trying to use > the program and even the testers. Most other projects don't need such > tools but this one does given what its trying to accomplish and the > complexity of whats being accomplished. Besides even windows XP has a > roll back feature now to fix problems. Why doesn't wine considering its > attempting a bug for bug compatibility with windows. This would be a > wise thing to implement just for sanities sake. > [Snip] > Something that allows the AppDB maintainers to distribute tweeks to > the configuration changes in the AppDB to users. So that even if we > aren't installing the programs on the system. The tweeks can still be > made on the fly. This would eliminate having to blow away the .wine > directory all the time. Blowing away the .wine directory is not a > desirable. A way for wine developers to distribute a test configuration > would also be a useful thing. That way we can test the software with > what the developers want us to test rather then shooting in the dark > only to see that the bug we reported is the same as some other bug we > reported. > > Such tools would be useful in debugging the entire framework and speed > up development. These are suggestions. I hope they help a bit. > I grudgingly have to agree that winecfg is at least partly inadequate. One of the things it is lacking is an export and and import function. I do not know how many times I have "blown away" my .wine directory. It would certainly save me some time if I could export the settings for a program and import them later. If we had the ability to import and export the settings for a program then it would also be possible for someone to upload that file somewhere (lets say the AppDB) and someone else could download it and use the same settings. The one problem that I can see with this is in the DLL overrides section. That is: if the import file contains a DLL override and the person does not have that dll installed we have a problem. Probably the best idea would be to search in the windows directories and warn the user if it could not find that file. Of course this does not address actually getting these dlls which is part of what WineTools does. Tony Lambregts

March 16, 2006

build stand alone binaries

by Benjamin Zeller

Hi there, is it possible to build real elf binaries with winelib? If i go through the tutorial on winehq.org i get only a appname.exe.so and i have to invoke wine to start the application. Is it possible to compile a binary wich can run stand alone? (Sorry for maybe posting this message twice i had some trouble with my email programm) regards benjamin z.

March 16, 2006

build stand alone binaries

by Benjamin Zeller

Hi there, is it possible to build real elf binaries with winelib? If i go through the tutorial on winehq.org i get only a appname.exe.so and i have to invoke wine to start the application. Is it possible to compile a binary wich can run stand alone? regards benjamin z.

March 16, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

> I don't see any other way to speed this up the way it's being synced now, the > question is however, whether the apps really _should_ modify the bitmap on > windows too (don't know whether they would try to draw controls onto the > window and then it would be overdrawn by the opengl image; application like > Steam are trying to achieve similar, but they seemed to work well before) > Does this very rough&ready patch work any better? I'm getting undefined references to `___tls_get_addr' when trying to build with this patch. However my ld has this symbol for sure... $ nm /lib/ld-2.3.5.so | grep __tls_get_addr 0000dfc0 T ___tls_get_addr 0000d9d0 T __tls_get_addr 0000dfc0 t ___tls_get_addr_internal > If this patch improves performance I'll fix it to use Win32 TLS instead > of ELF TLS, it'll be interesting to see if that changes makes a > difference too. perhaps it will compile on my machine then... Leon

March 16, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Joachim von Thadden

Am Fri, Mar 10, 2006 at 12:55:20AM +0100 schrieb Sven Paschukat: > Marcus Meissner schrieb: > >Hmm, I have some kind of recommendation here. > > > >What about winetools using ".winetools" as WINEPREFIX setting? > > > >This would make it possible to keep a ".wine" for the purists, and > >".winetools" for the "just get things done" people. > > > >Up to now winetools does not seem to honor a WINEPREFIX setting > >(also a bug I think). > > > >Ciao, Marcus > > Hey, you steal Joachim's ideas ;-) > > That's one point we have discussed in similar form. One directory for > the present winetools mode and another for a new builtin mode where > winetools just acts as a menu driven loader and installer. Sorry for the delay: I have been on CeBIT computer fair. To come to an end with that: Sven and I are doing the following for WineTools at the moment: - change WineTools to use WINEPREFIX - using a standard WINEPREFIX="$HOME/.winetools" if not set otherwise - change * to builtin,native - change version to WinXP - run as many apps as possible without tweaking The last one is the annoying one as it needs many testing *and* I know of no way to say "do not use the default" in winecfg or the registry. If there is a way, please mail me. I think using the AppDB for getting install and execution infos for programs is very hard to accomplish. We were already thinking about a way to send data of successful installations or executions automatically into a DB but dropped that. It would be very nice to have but it has to be - repeated for every version of wine - checked for correctness - if there are competing entries they have to be manually resolved - probably many other problems Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Thu, Mar 16, 2006 at 10:48:06AM +0900 schrieb Mike McCormack: > > Philip V. Neves wrote: > > >Something that interfaces with the AppDB would be good. It would make > >things easier. I think, given the complaints given by the developers are > >also valid but so are the complaints made by the people trying to use > >the program and even the testers. Most other projects don't need such > >tools but this one does given what its trying to accomplish and the > >complexity of whats being accomplished. Besides even windows XP has a > >roll back feature now to fix problems. Why doesn't wine considering its > >attempting a bug for bug compatibility with windows. This would be a > >wise thing to implement just for sanities sake. > > IMO, the best thing for Wine would be to have a simple front end with a > list of freely downloadable applications that work "out of the box" with > no configuration changes. > > Click -> Download application -> Install -> Run This is exactly what we try to have with the next version of WineTools. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Mike McCormack

Philip V. Neves wrote: > Something that interfaces with the AppDB would be good. It would make > things easier. I think, given the complaints given by the developers are > also valid but so are the complaints made by the people trying to use > the program and even the testers. Most other projects don't need such > tools but this one does given what its trying to accomplish and the > complexity of whats being accomplished. Besides even windows XP has a > roll back feature now to fix problems. Why doesn't wine considering its > attempting a bug for bug compatibility with windows. This would be a > wise thing to implement just for sanities sake. IMO, the best thing for Wine would be to have a simple front end with a list of freely downloadable applications that work "out of the box" with no configuration changes. Click -> Download application -> Install -> Run This would make it easy to for users to get applications working, find and report regressions, and fully test Wine, and would fully support developers in our quest to build a fully free environment for running Windows applications. Mike

March 16, 2006

Yet Another MS Windows API Emulation - SanOS, an small OS

by agaro

I don't know if somebody already found this, but may be relevant to wine-devel comunity (google don't found nothing about in this list): http://www.jbox.dk/sanos/ And the code (I haven't really looked much there): http://www.jbox.dk/sanos/source/index.html The code is released under an "BSD style" license. The win32 exception handling implementation is based on Wine code: http://www.jbox.dk/sanos/contributions.htm []s Augusto Arcoverde da Rocha

March 16, 2006

re: More dogfood tests

by Dan Kegel

> I have found very few problems, mainly just images being color-reversed, > and only on PNG of certain types. That sounds like the .gif bug here: http://bugs.winehq.org/show_bug.cgi?id=4529 Can you give the URL of one of the busted PNG's? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 16, 2006

More dogfood tests

by Segin

I have also started using Firefox in Wine for everything, namely because native lost a lib, old mozilla and opera and native firefox cause X to malloc() like mad (pkill -9 the broswer to cause X to free() ). I have found very few problems, mainly just images being color-reversed, and only on PNG of certain types. Also, Wine is MUCH faster if you have NPTL as your only threading method in glibc. (think a 15x improvement in speed here...) Wine also seems to know about the XDND X extension, cause it knows what GTK+2 widgets can be dragged and dropped onto, but otherwise the actual drag-and-drop procedure is a null effect. Ahh to hell with it, let's get to the speed tests. time wine firefox.exe, cold cache: real 0m48.895s (about 45s, really) user 0m4.116s sys 0m1.589s hot cache: real 0m9.287s (about 7.5s, really) user 0m3.966s sys 0m1.026s (Please note that the "real" time is off by about 1-2 seconds, to allow for me to quit Firefox.) Here we do the 7-Zip File Manager. Errors: err:listview:LISTVIEW_WindowProc unknown msg 2005 wp=00000001 lp=00000000 err:rebar:REBAR_AdjustBands Phase 1 failed, x=1000, maxx=-4, start=1, end=1 time wine 7zFM.exe, cold cache: real 0m34.815s (about 30s) user 0m1.044s sys 0m0.672s and with a hot cache: real 0m5.105s (about 4s, actually) user 0m0.997s sys 0m0.378s And now we do PuTTY: (no errors) Cold cache: real 0m39.382s (37s) user 0m1.023s sys 0m0.868s Hot cache: real 0m3.170s (no ajustment) user 0m0.978s sys 0m0.395s On a normal Windows system, the cache is always hot (all the core DLLs are always loaded), so the hot cache times actually rival a real Windows system, especially the one for PuTTY (which beats every test on a real Windows box I have done except those on more powerful hardware)

March 16, 2006

Re: wglMakeCurrent

by Raphael

Sorry for my late response but i haven't much time now > I'm not familiar at all with wine, so I'm not sure how we should fix this > (but it seems this would fix a lot of opengl related problems) > > When we first call X11DRV_setup_opengl_visual, I guess it's using the first > visual ID. No it's use the "best visual" who match asked capacities > But later, when we create a pixelformat descriptor, maybe we > should select a better visual (one equal or similar to the description > given in pixelformat), so when we later call wlgMakeCurrent, both visuals > will be the same No your problem don't seems to be here. can you send you glxinfo output. I presume you don't have glx1.3 support In this case wine don't be able to get a fb config compatible with wine window (one day we'll fix the wine init ...) Regards, Raphael

March 16, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by James E. Lang

Francois Gouget wrote at 0:06 on 12 Mar 2006: > Rein Klazes wrote: > [...] > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > > cause termination of the complete program. [...] I see that this is still a problem in 0.9.10 so I've fallen back again to 0.9.8. -- Jim

March 16, 2006

Re: Vista compatibility page

by Stefan Dösinger

> I mean .... 5 years! FIVE YEARS! And this is what they have to show for > it? A bunch of .NET APIs that they intend to backport to XP, and which > require a runtime nobody seems to be using for desktop apps anyway. An > improved file protection hack. Some improved security, and a display > rewrite equivalent to what David Reveman was able to produce on his own > in only 2 years? Not to forget the Digital Rights Management stuff. But thats definitly something I don't want. Improved security with a lot of "backdoors" for Windows Installer to stay user-friedly. It doesn't look like Vista will enlarge Wines ToDo list noticeable ;)

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

>See if you can tell from my log: >http://www.chez.com/alors/logfile > Jesse, I can't access your log at that page (I got an error). Could you please send it to me? Thanks, W _________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

My two cents about winetools and the suggestions I read in Issue 308

by Philip V. Neves

What I'm seeing here with the whole debate with wine and winetools is that its a configuration management issue. The project is getting into the stage where testing needs to be accomodated and so does getting things working. I think whats currently available for managing configurations to wine is innadequate. Even winecfg provides an interface that is innadequate for making many changes in terms of dll overrides. Plus it doesn't provide a mechanism for rolling those changes back. Or even managing multiple configurations or modes so that problems can be issolated. I think whats is comming out of the winetools debate is better tools are needed for configuration management. This isn't very revolutionary. Its a natural part of the software development life cycle. As a project starts emerging from the development phase ways to provide better configuration management start showing themselves. Something that interfaces with the AppDB would be good. It would make things easier. I think, given the complaints given by the developers are also valid but so are the complaints made by the people trying to use the program and even the testers. Most other projects don't need such tools but this one does given what its trying to accomplish and the complexity of whats being accomplished. Besides even windows XP has a roll back feature now to fix problems. Why doesn't wine considering its attempting a bug for bug compatibility with windows. This would be a wise thing to implement just for sanities sake. So I'd like to provide an addition to Jason Greens brain dump * AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information. * Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version. (I think multiple versions of the AppDB would be useful. Similar to the Release and Release candidate type way of doing things.) * Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app. * AppDB could dump this information to an xml format which "Winetools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org. * The 'Winetools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it. * Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out. * A Way to roll back DLL overrides. * A Way store roll multiple registry configurations so that we establish a base reference configuration and a test configuration. Or even multiple test configurations. * An AppDB tool that allows changes to the DLL configuration in the AppDB to be made easily. * A way to detect the version of wine and provide configuration changes given that version of wine. * A way to report bugs to the appDB maintainers about configuration problems. A nice to have would be Something that allows the AppDB maintainers to distribute tweeks to the configuration changes in the AppDB to users. So that even if we aren't installing the programs on the system. The tweeks can still be made on the fly. This would eliminate having to blow away the .wine directory all the time. Blowing away the .wine directory is not a desirable. A way for wine developers to distribute a test configuration would also be a useful thing. That way we can test the software with what the developers want us to test rather then shooting in the dark only to see that the bug we reported is the same as some other bug we reported. Such tools would be useful in debugging the entire framework and speed up development. These are suggestions. I hope they help a bit.

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

so, in your system the default visual ID is 0x28, and later my app create contexts with visual ID 0x23 but everything works fine for you... ok, back to square one :-( _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Ok, so now we know what's is going on here :-) > > I'm not familiar at all with wine, so I'm not sure how we should fix this > (but it seems this would fix a lot of opengl related problems) > > When we first call X11DRV_setup_opengl_visual, I guess it's using the first > visual ID. Hold on, the log shows it picking another in your test program: trace:opengl:X11DRV_setup_opengl_visual Visual ID 28 Chosen >From glxinfo: 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > But later, when we create a pixelformat descriptor, > maybe we > should select a better visual (one equal or similar to the description given > in pixelformat), so when we later call wlgMakeCurrent, both visuals will be > the same > > I hope this makes sense... > > Cheers, > > Wino > See if you can tell from my log: http://www.chez.com/alors/logfile Someone that knows wgl want to comment? Jesse

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Ok, so now we know what's is going on here :-) I'm not familiar at all with wine, so I'm not sure how we should fix this (but it seems this would fix a lot of opengl related problems) When we first call X11DRV_setup_opengl_visual, I guess it's using the first visual ID. But later, when we create a pixelformat descriptor, maybe we should select a better visual (one equal or similar to the description given in pixelformat), so when we later call wlgMakeCurrent, both visuals will be the same I hope this makes sense... Cheers, Wino _________________________________________________________________ Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The new MSN Search! Check it out!

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Hi Jesse, > > That's very interesting... Yes, I'm using a nvidia card. I think I know the > reason why is working for you but not for me > > glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards > glxinfo reports 0x23 as the first visual, which is the same visual ID of the > contexts I create. > > So maybe my program works fine for you because, just by coincidence, the > visual ID of my contexts are the same as the first visual ID reported by > X-Window > > Please, let me know the first visual ID reported by glxinfo is 0x23 in your > system. This will confirm my theroy :-) > > Thanks, > > Wino > Yes, you are correct that 0x23 is the first one.

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi Jesse, That's very interesting... Yes, I'm using a nvidia card. I think I know the reason why is working for you but not for me glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards glxinfo reports 0x23 as the first visual, which is the same visual ID of the contexts I create. So maybe my program works fine for you because, just by coincidence, the visual ID of my contexts are the same as the first visual ID reported by X-Window Please, let me know the first visual ID reported by glxinfo is 0x23 in your system. This will confirm my theroy :-) Thanks, Wino _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Hi guys > > I send a reply to the list a couple of days ago, but I attached my exe file > and it seems it was blocked but hotmail... > > First, thanks a lot for all your replies... Jesse, I've made the changes > proposed in those patches, but it didn't work :-( > > After further inspection, it seems the problem is when I call wglMakeCurrent > for a context which shares display lists with another context. I've attached > the program and the source code, so you can try it. > > > As I said, this program works just fine in Windows, so we must be doing > something differente in wine > > Any ideas/hints? > > Thanks > > Hi I tried your test program. I have the same results as with War3. Your program worked for me. I can't reproduce the same problem using DRI (Radeon 9200). So there is something specific about your configuration. I think you are using an nvidia card. Anyways, those patches didn't work either so 4604 is likely not a duplicate of 4143. Jesse

March 15, 2006

Re: ie6sp1 install failure

by James Hawkins

On 3/15/06, Samium Gromoff <_deepfire(a)mail.ru> wrote: > I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET > framework to be installed, and it failed like this: > I'll look into this soon. I'm on vacation right now though. -- James Hawkins

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi guys I send a reply to the list a couple of days ago, but I attached my exe file and it seems it was blocked but hotmail... First, thanks a lot for all your replies... Jesse, I've made the changes proposed in those patches, but it didn't work :-( After further inspection, it seems the problem is when I call wglMakeCurrent for a context which shares display lists with another context. I've attached the program and the source code, so you can try it. This is the output of the trace+opengl: trace:opengl:has_opengl GLX is up and running error_base = 77 trace:opengl:X11DRV_setup_opengl_visual Visual ID 21 Chosen trace:opengl:X11DRV_ChoosePixelFormat (0x403a28a8,0x406afdac) trace:opengl:dump_PIXELFORMATDESCRIPTOR - size / version : 40 / 1 trace:opengl:dump_PIXELFORMATDESCRIPTOR - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL trace:opengl:dump_PIXELFORMATDESCRIPTOR - iPixelType : PFD_TYPE_RGBA trace:opengl:dump_PIXELFORMATDESCRIPTOR - Color : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Red : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Green : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Blue : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Alpha : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Accum : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Depth : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Stencil : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Aux : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - iLayerType : PFD_MAIN_PLANE trace:opengl:X11DRV_SetPixelFormat (0x403a28a8,3,0x406afdac) trace:opengl:X11DRV_SetPixelFormat FBConfig have : trace:opengl:X11DRV_SetPixelFormat - FBCONFIG_ID 0x73 trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 trace:opengl:X11DRV_SetPixelFormat - DRAWABLE_TYPE 0x7 trace:opengl:X11DRV_GetPixelFormat (0x403a28a8): returns 3 trace:opengl:wglCreateContext (0x1cc)->(PF:3) trace:opengl:wglCreateContext creating context 0x403a2a40 (GL context creation delayed) trace:opengl:X11DRV_ChoosePixelFormat (0x403a2cc0,0x406afdac) trace:opengl:dump_PIXELFORMATDESCRIPTOR - size / version : 40 / 1 trace:opengl:dump_PIXELFORMATDESCRIPTOR - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL trace:opengl:dump_PIXELFORMATDESCRIPTOR - iPixelType : PFD_TYPE_RGBA trace:opengl:dump_PIXELFORMATDESCRIPTOR - Color : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Red : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Green : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Blue : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Alpha : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Accum : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Depth : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Stencil : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Aux : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - iLayerType : PFD_MAIN_PLANE trace:opengl:X11DRV_SetPixelFormat (0x403a2cc0,3,0x406afdac) trace:opengl:X11DRV_SetPixelFormat FBConfig have : trace:opengl:X11DRV_SetPixelFormat - FBCONFIG_ID 0x73 trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 trace:opengl:X11DRV_SetPixelFormat - DRAWABLE_TYPE 0x7 trace:opengl:X11DRV_GetPixelFormat (0x403a2cc0): returns 3 trace:opengl:wglCreateContext (0x1dc)->(PF:3) trace:opengl:wglCreateContext creating context 0x403a2e58 (GL context creation delayed) trace:opengl:wglShareLists (0x403a2a40, 0x403a2e58) trace:opengl:describeContext Context 0x403a2a40 have (vis:0x7c1782d0): trace:opengl:describeContext - FBCONFIG_ID 0x73 trace:opengl:describeContext - VISUAL_ID 0x23 trace:opengl:wglShareLists created a delayed OpenGL context (0x7c190318) for Wine context 0x403a2a40 trace:opengl:describeContext Context 0x403a2e58 have (vis:0x7c18a4d0): trace:opengl:describeContext - FBCONFIG_ID 0x73 trace:opengl:describeContext - VISUAL_ID 0x23 trace:opengl:wglShareLists created a delayed OpenGL context (0x7c1b1590) for Wine context 0x403a2e58 sharing lists with OpenGL ctx 0x7c190318 trace:opengl:wglGetCurrentDC () trace:opengl:wglGetCurrentDC no Wine context found for GLX context 0x7c096448 trace:opengl:wglGetCurrentContext () trace:opengl:wglGetCurrentContext returning (nil) (GL context 0x7c096448) trace:opengl:wglMakeCurrent (0x1dc,0x403a2e58) trace:opengl:wglMakeCurrent make current for dis 0x7c0657f0, drawable 0x3800002, ctx 0x7c1b1590 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 120 Current serial number in output stream: 120 My guess is that when we call wglMakeCurrent for the context with the shared lists, it has a VISUAL_ID of 0x23, but X11DRV_setup_opengl_visual chosed a Visual ID of 0x21, and hence the BadMatch error. As I said, this program works just fine in Windows, so we must be doing something differente in wine Any ideas/hints? Thanks _________________________________________________________________ Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The new MSN Search! Check it out!

March 15, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Alex Villacís Lasso

Robert Shearman wrote: > > The fix is to do the following in the conversion loop in > ITypeInfo::Invoke: > if (rgvt[i] == VT_VARIANT) > VariantCopy(&rgvarg[i], src_arg); > else if ((rgvt[i] & VT_BYREF) && !V_ISBYREF(src_arg)) > ... > > I don't have time to put this into patch form and test it, but > hopefully someone else will. > I tried this on the test app. It did not work. Sure, the code reaches the DispCallFunc call, but then the actual code from inside the control fails the call. It seems that the type of the variant is not adequate for the parameter. Visual Basic shows a message: "Application-defined or user defined error". It seems that I will have to wait until I code enough of a test case for a *successful* ITypeInfo::Invoke() (there are two tests of failing calls, but none of a successful one), so that I can see what native OLEAUT32.DLL is sending as the parameter. Unless somebody else beats me on this. Alex Villacís Lasso

March 15, 2006

Re: Vista compatibility page

by Mike Hearn

On Wed, 2006-03-15 at 09:24 +0100, Andreas Mohr wrote: > Not to mention that they're handing a near-fatal blow to OpenGL support, too. Maybe ... last I heard, word on the street was that vendors had found a way to write an Aero compatible ICD, so potentially nothing will change. If nothing else, it's not like video makers will just delete all their GL code the day Vista is released (whenever that is). They still have to support XP, and anyway Vista has been looking like a dead duck for a long time now. I mean .... 5 years! FIVE YEARS! And this is what they have to show for it? A bunch of .NET APIs that they intend to backport to XP, and which require a runtime nobody seems to be using for desktop apps anyway. An improved file protection hack. Some improved security, and a display rewrite equivalent to what David Reveman was able to produce on his own in only 2 years? I don't think Vista is going to be dealing near-fatal blows to anything anytime soon ...

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Mike Hearn

On Wed, 2006-03-15 at 14:01 +0000, Huw D M Davies wrote: > Sorry, maybe I should read the patch properly before commenting :-) I > assumed that you were setting need_escape to FALSE after sending the > escape, but you're not. Indeed it would be interesting to know if > this helped. Heh, you had me a bit worried for a second there! Indeed I do not know what the original patch does or why it's needed, but the slowdown just seems related to looking up the Wine_GLContext and testing it. If this patch improves performance I'll fix it to use Win32 TLS instead of ELF TLS, it'll be interesting to see if that changes makes a difference too.

March 15, 2006

Re: GDI32: Fix logical error of italic,bold determination

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:04AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Fix the logical error of the italic, bold determination. > > Index: dlls/gdi/freetype.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > retrieving revision 1.114 > diff -u -u -r1.114 freetype.c > --- dlls/gdi/freetype.c 9 Mar 2006 12:30:52 -0000 1.114 > +++ dlls/gdi/freetype.c 12 Mar 2006 10:01:22 -0000 > + for(i = 0; !face && i < 4; ++i) { > best = NULL; > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > face = LIST_ENTRY(face_elem_ptr, Face, entry); > - if((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0]) { > + if((!(face->Italic ^ it) ^ ((i >> 1) & 1)) && (!(face->Bold ^ bd) ^ (i & 1)) && > + ((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0])) { It doesn't seem right to compare these with 'i', the order of the faces is random. The right way to do this is to rewrite all this font matching code so that we loop through the families and faces once and score each one. At the end we pick the one with the lowest score. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef. (more better patch)

by Mike McCormack

Saveliy Tretiakov wrote: > +typedef: tTYPEDEF m_attributes type pident_list { > + attr_t *a = $2; > + int public = 0; > + while(a){ > + switch(a->type) > + { > + case ATTR_CONTEXTHANDLE: > + case ATTR_STRING: > + case ATTR_HANDLE: > + case ATTR_SWITCHTYPE: > + case ATTR_TRANSMITAS: > + case ATTR_POINTERTYPE: > + case ATTR_IGNORE: > + break; > + case ATTR_PUBLIC: > + public = 1; > + break; > + default: > + yyerror("Inapplicable attribute\n"); How about changing the grammar to define something like: attributes: td_attribs | tCONTEXTHANDLE | tSTRING | ... /* other things that can't be a typedef */ ; td_attribs: tAGGREGATABLE | ... /* other things in the existing attributes rule */ ; typedef: tTYPEDEF td_attribs type pident_list .... That way the parser can deal with the problem. Mike

March 15, 2006

Re: ie6sp1 install failure

by Mike McCormack

Samium Gromoff wrote: > I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET > framework to be installed, and it failed like this: Please post this kind of thing to wine-users, not wine-devel. IE6 is known to work in Wine with the correct configuration. Mike

March 15, 2006

Re: GDI32: using the embeded bitmap in antialias mode

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:20AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Using the embeded bitmap in the antialias mode. > > > PS2. FT_Bitmap_Convert() is simple, but I used it. > "ftbitmap.h" is define FT_Bitmap_Embolden(), and I will use it in the > furure. Looks like FT_Bitmap_Convert is a relatively new function - I don't have it in fc4. You're going to need to provide a fallback or simply ignore it completely and code it yourself. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: ntdll: test to get and set junctions

by Mike McCormack

I don't have alot of time to look over your code at the moment, but: tkho(a)ucla.edu wrote: > dlls/ntdll/tests/Makefile.in | 1 > dlls/ntdll/tests/file.c | 165 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/tests/ntifs.h | 66 +++++++++++++++++ This is one patch, and you should roll ntifs.h into file.c > include/ntifs.h | 63 ++++++++++++++++ This should be a separate patch, and it may be better to put it in the include/ddk directory, since it doesn't seem to exist in the Windows SDK. > include/winnt.h | 4 + This is another separate patch, which should be easy enough to get accepted on its own. Mike

March 15, 2006

Re: GDI32: Using the FT_Sfnt_Name for font FamilyName

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:36AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Using the FT_Sfnt_Name for font FamilyName Hi, This one could be broken down too. Start off with a patch that moves FontSubst to using the struct list stuff. Then try sending a patch that uses FT_Sfnt_Name. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef.

by Robert Shearman

Saveliy Tretiakov wrote: > Sorry, previous patch was broken. > > ChangeLog: > Saveliy Tretiakov <saveliyt(a)mail.ru> > Add missing ignore attribute. > Check for inapplicable attributes in typedef. > Register type in typelibrary only when ATTR_PUBLIC is set. Please respect the indentation style in the files you are editing. Also, the attribute lists are all sorted to make it easier to find a given attribute in it. Therefore, please add the attribute in the correct place. >+ break; >+ default: >+ yyerror("Inapplicable attribute\n"); >+ } >+ a = NEXT_LINK(a); >+ } >+ typeref_t *tref = uniq_tref($3); > You can't mix variable declarations in between statements as it won't compile on some compilers. -- Rob Shearman

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Huw D M Davies

On Wed, Mar 15, 2006 at 01:52:19PM +0000, Huw D M Davies wrote: > On Wed, Mar 15, 2006 at 12:21:56AM +0000, Mike Hearn wrote: > > Does this very rough&ready patch work any better? > > I'm sure it's much faster, problem is it doesn't work. How do we know > if the app has fiddled with the dib section bits? Sorry, maybe I should read the patch properly before commenting :-) I assumed that you were setting need_escape to FALSE after sending the escape, but you're not. Indeed it would be interesting to know if this helped. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Huw D M Davies

On Wed, Mar 15, 2006 at 12:21:56AM +0000, Mike Hearn wrote: > On Tue, 14 Mar 2006 17:18:21 +0100, Leon Freitag wrote: > > I don't see any other way to speed this up the way it's being synced now, the > > question is however, whether the apps really _should_ modify the bitmap on > > windows too (don't know whether they would try to draw controls onto the > > window and then it would be overdrawn by the opengl image; application like > > Steam are trying to achieve similar, but they seemed to work well before) > > Does this very rough&ready patch work any better? I'm sure it's much faster, problem is it doesn't work. How do we know if the app has fiddled with the dib section bits? Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: Vista compatibility page

by Andreas Mohr

Hi, On Tue, Mar 14, 2006 at 05:51:37PM -0800, Scott Ritchie wrote: > On Tue, 2006-03-14 at 21:56 +0000, Mike Hearn wrote: > > Potentially this is old news, but via Raymond Chen we learn of this page: > > > > So there we have it - this appears to be the first release in which they > > simply started dropping APIs. > > > And, therefore, the first time for which we can categorically state that > Wine will be more compatible with Windows applications than Windows > itself. Not to mention that they're handing a near-fatal blow to OpenGL support, too. Andreas

March 15, 2006

ie6sp1 install failure

by Samium Gromoff

I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET framework to be installed, and it failed like this: deepfire(a)betelheise:/mnt/etherstorm/win32$ wine ie6setup.exe fixme:advapi:CheckTokenMembership ((nil) 0x7fd3b6b0 0x7fbefd78) stub! fixme:advapi:DecryptFileA "C:\\windows\\temp\\IXP000.TMP\\" 00000000 wine: Unhandled page fault on read access to 0x0000000e at address 0x7e69c1ba (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x0000000e in 32-bit code (0x7e69c1ba). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7e69c1ba ESP:7fbdeff0 EBP:7fbdeff8 EFLAGS:00210212( - 00 - RIA1) EAX:00000002 EBX:7e6ad280 ECX:00000000 EDX:00000000 ESI:00000002 EDI:00000001 Stack dump: 0x7fbdeff0: 00000001 00000002 7fbdf01c 7e69d8bc 0x7fbdf000: 00000001 7fd43120 0000000b 7fbdf018 0x7fbdf010: 7e6dec3c 7fbdf788 7fd43120 7fbdf7cc 0x7fbdf020: 7e6daa8a 7fbdf788 00000001 7fbdf7ab 0x7fbdf030: 00000005 7fbdf7b0 7fbdf07c 00000000 0x7fbdf040: 7fbdf788 7fbdf7b8 7fbdf7b4 7fbdf7b0 0200: sel=1007 base=7fe4a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x7e69c1ba in setupapi (+0x1c1ba) (0x7e69c1ba) 2 0x7e69d8bc SetupGetStringFieldA+0x2c in setupapi (0x7e69d8bc) 3 0x7e6daa8a in advpack (+0xaa8a) (0x7e6daa8a) 4 0x7e6db2df TranslateInfStringA+0xff in advpack (0x7e6db2df) fixme:dbghelp:sffip_cb NIY on 'ie6wzdex.pdb' 5 0x01016f73 in ie6wzd (+0x16f73) (0x01016f73) 6 0x010199e4 in ie6wzd (+0x199e4) (0x010199e4) 7 0x00000000 (0x00000000) 0x7e69c1ba: cmpl 0xc(%eax),%edx Modules: Module Address Debug info Name (74 modules) PE 0x01000000-01034000 Export ie6wzd ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7e154000-7e15c000 Deferred librt.so.1 ELF 0x7e675000-7e6c8000 Export setupapi<elf> \-PE 0x7e680000-7e6c8000 \ setupapi ELF 0x7e6c8000-7e6e0000 Export advpack<elf> \-PE 0x7e6d0000-7e6e0000 \ advpack ELF 0x7e7f7000-7e83c000 Deferred riched20<elf> \-PE 0x7e810000-7e83c000 \ riched20 ELF 0x7e83c000-7e850000 Deferred riched32<elf> \-PE 0x7e840000-7e850000 \ riched32 ELF 0x7e934000-7e98c000 Deferred shlwapi<elf> \-PE 0x7e950000-7e98c000 \ shlwapi ELF 0x7e98c000-7ea51000 Deferred shell32<elf> \-PE 0x7e9a0000-7ea51000 \ shell32 ELF 0x7ea51000-7ea82000 Deferred uxtheme<elf> \-PE 0x7ea60000-7ea82000 \ uxtheme ELF 0x7eac6000-7eaca000 Deferred libxfixes.so.3 ELF 0x7eaca000-7ead3000 Deferred libxcursor.so.1 ELF 0x7ead3000-7eaef000 Deferred imm32<elf> \-PE 0x7eae0000-7eaef000 \ imm32 ELF 0x7eaef000-7eaf2000 Deferred libxrandr.so.2 ELF 0x7eaf2000-7eafa000 Deferred libxrender.so.1 ELF 0x7eafa000-7eb01000 Deferred libdrm.so.2 ELF 0x7eb01000-7eb67000 Deferred libgl.so.1 ELF 0x7eb67000-7ec4d000 Deferred libx11.so.6 ELF 0x7ec4d000-7ec65000 Deferred libice.so.6 ELF 0x7ec65000-7ece4000 Deferred winex11<elf> \-PE 0x7ec70000-7ece4000 \ winex11 ELF 0x7ece4000-7ed03000 Deferred libexpat.so.1 ELF 0x7ed03000-7ed31000 Deferred libfontconfig.so.1 ELF 0x7ed31000-7ed45000 Deferred libz.so.1 ELF 0x7ed45000-7edae000 Deferred libfreetype.so.6 ELF 0x7edae000-7edcc000 Deferred iphlpapi<elf> \-PE 0x7edc0000-7edcc000 \ iphlpapi ELF 0x7edcc000-7ee14000 Deferred rpcrt4<elf> \-PE 0x7ede0000-7ee14000 \ rpcrt4 ELF 0x7ee14000-7eea0000 Deferred ole32<elf> \-PE 0x7ee30000-7eea0000 \ ole32 ELF 0x7eea0000-7eeb9000 Deferred version<elf> \-PE 0x7eeb0000-7eeb9000 \ version ELF 0x7eeb9000-7ef6d000 Deferred comctl32<elf> \-PE 0x7eec0000-7ef6d000 \ comctl32 ELF 0x7ef6d000-7ef8b000 Deferred mpr<elf> \-PE 0x7ef70000-7ef8b000 \ mpr ELF 0x7ef8b000-7f0ad000 Deferred user32<elf> \-PE 0x7efb0000-7f0ad000 \ user32 ELF 0x7f0ad000-7f0b7000 Deferred libgcc_s.so.1 ELF 0x7f0b7000-7f0cb000 Deferred lz32<elf> \-PE 0x7f0c0000-7f0cb000 \ lz32 ELF 0x7f1a0000-7faa3000 Deferred gdi32<elf> \-PE 0x7f1e0000-7faa3000 \ gdi32 ELF 0x7faa3000-7fae0000 Deferred advapi32<elf> \-PE 0x7fab0000-7fae0000 \ advapi32 ELF 0x7fbe2000-7fce0000 Deferred kernel32<elf> \-PE 0x7fc00000-7fce0000 \ kernel32 ELF 0x7fce3000-7fcf0000 Deferred libxext.so.6 ELF 0x7fe02000-7fe05000 Deferred libxau.so.6 ELF 0x7fe05000-7fe0f000 Deferred libnss_files.so.2 ELF 0x7fe0f000-7fe18000 Deferred libnss_nis.so.2 ELF 0x7fe18000-7fe2d000 Deferred libnsl.so.1 ELF 0x7fe2d000-7fe36000 Deferred libnss_compat.so.2 ELF 0x7fe36000-7fe3b000 Deferred libxxf86vm.so.1 ELF 0x7fe3b000-7fe40000 Deferred libxxf86dga.so.1 ELF 0x7fe42000-7fe4a000 Deferred libsm.so.6 ELF 0x7fe4d000-7fe6f000 Deferred libm.so.6 ELF 0x7fe6f000-7ff66000 Deferred libwine_unicode.so.1 ELF 0x7ff66000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff80000-7ffe0000 \ ntdll ELF 0xb7df1000-b7df4000 Deferred libdl.so.2 ELF 0xb7df4000-b7f23000 Deferred libc.so.6 ELF 0xb7f23000-b7f35000 Deferred libpthread.so.0 ELF 0xb7f4a000-b7f64000 Deferred libwine.so.1 ELF 0xb7f67000-b7f7d000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a (D) C:\windows\temp\IXP000.TMP\ie6wzd.exe 0000000b 0 <== 00000008 00000009 0

March 15, 2006

Re: Dogfood status

by Dan Kegel

Louis wrote: >As a frequent wine-user my favourite commands are >"rm -rf ~/.wine" and "wineserver -k" Me, too. Hard to control that urge while dogfooding, it's it? >And that's where i ran into trouble... First >problem solved by consequently using > WINEPREFIX="/c" wine "c:\Program Files/Winamp/winamp.exe". >Second problem was a bit more thinking. >I compiled an extra wine package in /tmp/wine and run by >WINEPREFIX="/c" /tmp/wine/wine "c:\Program Files/Winamp/winamp.exe" >Now i can do wineserver -k without killing winamp :). Good ideas! I'll probably do something like that. >So far Mozilla runs really great; Winamp has some issues but sound plays well. Bugzilla shows four open bugs against winamp: 729 3245 4373 4825 Do you have some new ones to file? - Dan

March 15, 2006

Re: Updated DDraw over WineD3D patch

by Joseph Garvin

So I gave the latest version of Fallout1 a try with the patch, imageshack link to screenshot below :) http://img293.imageshack.us/img293/311/fallout7xc.png The game looks and works mostly correctly with only two issues: 1) The mouse lags, even though the game itself seems to be rendering pretty quickly. There was no mouse lag in the old ddraw implementation. 2) When selecting new game, load game, etc. from the main menu, the menu used to nicely fade out. This effect was really slow under the old implementation and was what motivated me to try this patch. Now the effect doesn't happen at all, it goes black and then immediately to the next screen. Nice for me but still a regression ;) 3) There's an error on exit. Output from running below. Let me know if there are any traces that would be useful to you. fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd49868) : stub, emulating 64Mib for now, returning 64Mib fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->(0x10024,00000011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:ddraw:IDirectDrawImpl_CreatePalette (0x7fd49188)->(44,0x7fb9f6a8,0x539 dec,(nil)) fixme:d3d:IWineD3DDeviceImpl_CreatePalette (0x7fd49868)->(44, 0x7fb9f6a8, 0x 7fd979a8, 0x7fd979a0) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->((nil),0000000 8) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 135 Current serial number in output stream: 137 I'm running the 8.23.7 (latest version) of the proprietary fglrx drivers on a Radeon 9700 Pro (native linux opengl apps like neverball and tuxracer work great) on the dapper drake (unstable) release of ubuntu. I tried the patch against current cvs but it won't apply so I tested it with the CVS time from your site, March 9th 23:40. P.S. Ooops, sorry Stefan, didn't mean to send you with attachment :P On Fri, 2006-03-10 at 00:30 +0100, Stefan Dösinger wrote: > Hi, > I've uploaded anothe update of my DDraw->WineD3D patch to > http://stud4.tuwien.ac.at/~e0526822/. It fixes some refcounting issues and > the D3D renderer of the Half-Life 1 Steam version works. It also takes the > merged header patches into account ;) > > I am quite busy the next time, so I won't be able to do a lot ddraw > development. I'll continue to send patches, but only header changes, no added > functionality. I'll keep myself up to date and anser feedback mails, but I > don't think I've the time to do intensive development. I expect I can > continue in April. > > Have fun playing, > Stefan

March 15, 2006

Free mirror for .deb APT repository (forwarded correspondance)

by Scott Ritchie

Hey guys. For the past few days I've been corresponding with Pieter de Bruijn, who has graciously offered us a huge amount of bandwidth to host the APT repository for our .deb packages, rather than having to put it in the sourceforge webspace where it is rather slow and times out a lot. By my estimates, we get about 800 downloads of Wine from the APT repository per day, which is about 10 gigabytes. All other package downloads from sourceforge combined constitute about 4000 downloads, so roughly 20% of our package downloads are using the APT repository. As for what percentage of our user base uses current .debs, I don't know, because more or less up to date Wine packages derived from mine can be also grabbed from the Ubuntu backports server, the Ubuntu development server, and likely some other place I don't know of. It wouldn't surprise me if over half our users were on Ubuntu at this point, though. One important advantage of Peter's offer is that it allows us much more storage space, possibly including multiple APT repositories for different distributions. This would be far preferable to the ~100 megs or so we get on Sourceforge, which can barely fit one package. Anyway, I'd like to inform everyone about the hosting offer and gather some additional feedback, if you have any comments about the change. Thanks, Scott Ritchie

March 15, 2006

Re: Vista compatibility page

by Scott Ritchie

On Tue, 2006-03-14 at 21:56 +0000, Mike Hearn wrote: > Potentially this is old news, but via Raymond Chen we learn of this page: > > So there we have it - this appears to be the first release in which they > simply started dropping APIs. > And, therefore, the first time for which we can categorically state that Wine will be more compatible with Windows applications than Windows itself. Cheers, Scott Ritchie

March 15, 2006

Re: Updated DDraw over WineD3D patch

by Joseph Garvin

So I gave the latest version of Fallout1 a try with the patch, imageshack link to screenshot below :) http://img293.imageshack.us/img293/311/fallout7xc.png The game looks and works mostly correctly with only two issues: 1) The mouse lags, even though the game itself seems to be rendering pretty quickly. There was no mouse lag in the old ddraw implementation. 2) When selecting new game, load game, etc. from the main menu, the menu used to nicely fade out. This effect was really slow under the old implementation and was what motivated me to try this patch. Now the effect doesn't happen at all, it goes black and then immediately to the next screen. Nice for me but still a regression ;) 3) There's an error on exit. Output from running below. Let me know if there are any traces that would be useful to you. fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd49868) : stub, emulating 64Mib for now, returning 64Mib fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->(0x10024,00000011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:ddraw:IDirectDrawImpl_CreatePalette (0x7fd49188)->(44,0x7fb9f6a8,0x539 dec,(nil)) fixme:d3d:IWineD3DDeviceImpl_CreatePalette (0x7fd49868)->(44, 0x7fb9f6a8, 0x 7fd979a8, 0x7fd979a0) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->((nil),0000000 8) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 135 Current serial number in output stream: 137 I'm running the 8.23.7 (latest version) of the proprietary fglrx drivers on a Radeon 9700 Pro (native linux opengl apps like neverball and tuxracer work great) on the dapper drake (unstable) release of ubuntu. I tried the patch against current cvs but it won't apply so I tested it with the CVS time from your site, March 9th 23:40. On Fri, 2006-03-10 at 00:30 +0100, Stefan Dösinger wrote: > Hi, > I've uploaded anothe update of my DDraw->WineD3D patch to > http://stud4.tuwien.ac.at/~e0526822/. It fixes some refcounting issues and > the D3D renderer of the Half-Life 1 Steam version works. It also takes the > merged header patches into account ;) > > I am quite busy the next time, so I won't be able to do a lot ddraw > development. I'll continue to send patches, but only header changes, no added > functionality. I'll keep myself up to date and anser feedback mails, but I > don't think I've the time to do intensive development. I expect I can > continue in April. > > Have fun playing, > Stefan

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Mike Hearn

On Tue, 14 Mar 2006 17:18:21 +0100, Leon Freitag wrote: > I don't see any other way to speed this up the way it's being synced now, the > question is however, whether the apps really _should_ modify the bitmap on > windows too (don't know whether they would try to draw controls onto the > window and then it would be overdrawn by the opengl image; application like > Steam are trying to achieve similar, but they seemed to work well before) Does this very rough&ready patch work any better? --- wgl.c~ 2006-02-11 01:58:59.000000000 +0000 +++ wgl.c 2006-02-16 19:11:33.000000000 +0000 @@ -77,11 +77,14 @@ XVisualInfo *vis; GLXFBConfig fb_conf; GLXContext ctx; + BOOL needs_escape; struct wine_glcontext *next; struct wine_glcontext *prev; } Wine_GLContext; static Wine_GLContext *context_list; +Wine_GLContext __thread *curctx = NULL; + static inline Wine_GLContext *get_context_from_GLXContext(GLXContext ctx) { Wine_GLContext *ret; @@ -91,18 +94,14 @@ void enter_gl(void) { - GLXContext gl_ctx; - Wine_GLContext *ctx; enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; - wine_tsx11_lock_ptr(); - gl_ctx = glXGetCurrentContext(); - if(!gl_ctx) return; - ctx = get_context_from_GLXContext(gl_ctx); - wine_tsx11_unlock_ptr(); /* unlock before calling GDI apis */ - - if(ctx && GetObjectType(ctx->hdc) == OBJ_MEMDC) - ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + if (curctx && curctx->needs_escape) + { + ERR("foo\n"); + ExtEscape(curctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + } + wine_tsx11_lock_ptr(); return; @@ -536,6 +535,7 @@ ENTER_GL(); if (hglrc == NULL) { ret = glXMakeCurrent(default_display, None, NULL); + curctx = NULL; } else { Wine_GLContext *ctx = (Wine_GLContext *) hglrc; Drawable drawable = get_drawable( hdc ); @@ -566,8 +566,12 @@ } TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); ret = glXMakeCurrent(ctx->display, drawable, ctx->ctx); + curctx = ctx; if(ret && type == OBJ_MEMDC) + { + curctx->needs_escape = TRUE; glDrawBuffer(GL_FRONT_LEFT); + } } LEAVE_GL(); TRACE(" returning %s\n", (ret ? "True" : "False"));

March 15, 2006

Vista compatibility page

by Mike Hearn

Potentially this is old news, but via Raymond Chen we learn of this page: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/htm… Which talks about Vistas application compatibility. Interesting points that stand out: * They are dropping WinHelp and CHM support. You'll have to install it from their website for it to work (my first thought: wtf?) * IsBadReadPtr/IsBadWritePtr are now "banned". I wonder what that means. Presumably it just means they don't use them internally for the APIs anymore. * Windows will now silently fail to modify certain protected system files even if you're the administrator (basically the STATUS_ACCESS_DENIED error is suppressed to stop installers tripping up). * They dropped D3D RM. Not many apps use this but I think at least my fathers sailing game does. So there we have it - this appears to be the first release in which they simply started dropping APIs.

March 14, 2006

Re: Some Processor(s) specific environment variables

by Alexandre Julliard

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > Would it be acceptable to put some sane defaults in wine.inf and have > GetSystemInfo check and fill the correct keys in the registry? Or do we > need a way to fill these keys at every boot of the system (start of > wineserver)? We can either put defaults in wine.inf, or if that's not good enough compute the proper values at run-time. It doesn't really make sense to do both. -- Alexandre Julliard julliard(a)winehq.org

March 14, 2006

Re: Dogfood status

by Tom Spear

While we are on the subject of dogfooding things, to the best of anyone's knowledge, has anyone ever tried to do something as crazy as oh i dunno, defragging their hard drive (or even one of the virtual partitions) with win98's defragger? What about running win98's gui'based scandisk on either of the above? I'd do it, but my linux machine still needs a new motherboard. Anyone got a test machine they need to reformat? Tom On 3/14/06, Dan Kegel <dank(a)kegel.com> wrote: > > Oh, Picasa works pretty well, actually. (I did dogfood it earlier.) > It's just not the kind of image editor I usually reach for when > cropping screenshots etc. > > I've also tested photoshop, it's not so happy. > > I may try Irfanview, too. Thanks! > - Dan > > On 3/14/06, Tom Spear <speeddymon(a)gmail.com> wrote: > > > > Try Irfanview. It's not a full featured editor, but it can do small > jobs. > > Kinda like Picasa, but much more user friendly. Of course you could do > > Picasa, but good luck. Same for Photoshop and Paintshop. > > > > > > Tom > > > > > > > > On 3/14/06, Dan Kegel <dank(a)kegel.com> wrote: > > > Since those are the *only two gui apps I use* > > > on Linux, I'm running out of things to dogfood! > > > Oh, once in a while I need an image editor. > > > Maybe I'll dogfood windows gimp next (quadruple yuck)... > > > > > > - Dan > > > > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv >

March 14, 2006

Re: Dogfood status

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > I've been dogfooding Wine with Firefox for some time. > It's totally usable and good looking now. Hi Dan, inspired by you i decided to go this way as well. I've remeoved shortcut buttons to xmms and mozilla (linux) from my task bar and replaced them by shortcuts to little scripts that start mozilla.exe and winamp in wine. Just want to share some experiences. As a frequent wine-user my favourite commands are "rm -rf ~/.wine" and "wineserver -k" And that's where i ran into trouble... First problem solved by consequently using WINEPREFIX="/c" wine "c:\Program Files/Winamp/winamp.exe". Second problem was a bit more thinking. I compiled an extra wine package in /tmp/wine and run by WINEPREFIX="/c" /tmp/wine/wine "c:\Program Files/Winamp/winamp.exe" Now i can do wineserver -k without killing winamp :). So i've now put some aliases in /etc/bashrc for most common commands: alias _wine='WINEPREFIX="/c" /tmp/wine/wine' alias _winecfg='WINEPREFIX="/c" /tmp/wine/programs/winecfg/winecfg' alias _regedit='WINEPREFIX="/c" /tmp/wine/programs/regedit/regedit' So now i can do _wine "c:\Program Files/Winamp/winamp.exe" _and_ rm -rf ~/.wine and wineserver -k, without any trouble. Sofar Mozilla runs really great; Winamp has some issues but sound plays well.

March 14, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Robert Shearman

Alex Villacís Lasso wrote: > Alex Villacís Lasso wrote: > >> I would like to draw attention to bug 4502. This bug can cause any VB >> application to crash when the DatePicker control is used, and an >> attempt is made to assign a date value in VB code. Even though I >> found this bug while testing an application I wrote, this might not >> be specific to this application. It is only recently that I have some >> time to dedicate to this bug, but I would like somebody to comment on >> this. >> >> When the sample application is run with WINEDEBUG=ole,variant, the >> failing invocation looks like this: >> >> trace:ole:ITypeInfo_fnInvoke >> (0x7fdd5440)(0x7fd9f61c,id=20,flags=0x00000004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c) >> >> trace:ole:dump_DispParms args=1 named args=1 >> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) >> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) >> trace:ole:dump_Variant ,2006/03/12 00:00:00} >> trace:ole:ITypeInfo_fnInvoke invoking: >> L"Value"(1) >> parm0: L"Value" >> memid is 00000014 >> Param 0: >> tdesc.vartype 12 (VT_VARIANT) >> u.paramdesc.wParamFlags PARAMFLAG_FIN >> u.paramdesc.lpex (nil) >> funckind: 1 (pure virtual) >> invkind: 4 (property put) >> callconv: 4 (stdcall) >> oVft: 224 >> cParamsOpt: 0 >> wFlags: 3c >> elemdescFunc (return value type): >> tdesc.vartype 25 (VT_HRESULT) >> u.paramdesc.wParamFlags PARAMFLAGS_NONE >> u.paramdesc.lpex (nil) >> helpstring: L"Returns/sets the current date." >> entry: (null) >> trace:ole:ITypeInfo_fnInvoke changing args >> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) >> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) >> trace:ole:dump_Variant ,2006/03/12 00:00:00} >> trace:variant:VariantChangeTypeEx >> (0x7fdd5520->(VT_DATE),0x7fa3eef4->(VT_DATE),0x00000400,0x0000,VT_VARIANT) >> >> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) >> trace:variant:VariantCopyInd >> (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) >> trace:variant:VariantCopy (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) >> trace:variant:VARIANT_Coerce >> (0x7fa3ec40->(VT_EMPTY),0x00000400,0x0000,0x7fa3ec30->(VT_DATE),VT_VARIANT) >> >> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_DATE)) >> trace:variant:VariantChangeTypeEx returning 0x80020005, >> 0x7fdd5520->(VT_DATE) >> err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT >> from VT_DATE >> trace:ole:ITypeInfo_fnInvoke -- 0x80020005 >> >> The Property Put seems to be declared as taking one VT_VARIANT >> parameter, and the VB code supplies a VT_DATE value. Therefore, an >> attempt is made to coerce VT_DATE --> VT_VARIANT. However, >> VariantChangeTypeEx() does not support conversion of *any* kind of >> variant into VT_VARIANT, so the call fails, and this brings down the >> application. I was on half a mind to add the VT_VARIANT conversion to >> VariantChangeTypeEx() myself, but then I checked the tests for this >> operation, and it seems that the absence of support for VT_VARIANT is >> actually expected (unless I am misreading the code). Therefore, one >> of the following two things is happening: >> >> 1) There is some error in the reading of the typelib, since a >> Property Put should not have a VT_VARIANT parameter in the first place. >> 2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself, >> precisely because VariantChangeTypeEx() won't do it. > The fix is to do the following in the conversion loop in ITypeInfo::Invoke: if (rgvt[i] == VT_VARIANT) VariantCopy(&rgvarg[i], src_arg); else if ((rgvt[i] & VT_BYREF) && !V_ISBYREF(src_arg)) ... I don't have time to put this into patch form and test it, but hopefully someone else will. -- Rob Shearman

March 14, 2006

Re: need advise with new open-source project

by Nuno Lopes

First let me thank you for your fast answer. On 3/14/06, Jim White <jim(a)pagesmiths.com> wrote: > Please note: http://en.wikipedia.org/wiki/IANAL > > Nuno Lopes wrote: > > > I'm currently trying to start a new open-source project that will do > > the same as WINE did with the windows API, but for a Sony framework, > > named OPEN-R. > > ... > > I would love if you could answer my questions, so that I can make the > > project public as soon as possible. > > Your questions are quite involved and many do not have clear cut > answers. And while there are some similarities between your project's > issues and WINE's, there are some key legal differences, including > particularly legal decisions regarding Microsoft's monopoly. > > Another similar situation existed with LEGO Mindstorms. While initial > community developments were technically in violation of some terms of > the EULA (which may or may not be enforceable in some jurisdictions) the > key was LEGO's reaction. Rather than pursuing legal action against the > community developers, they decided instead to embrace them and provide > tacit and subsequently explicit support. I (and many others) have already contacted Sony, but they don't even answer our e-mails, so I don't have much hope to hear from them. Also I'm not planing to run this software on the robots themselves, as I would need to reverse-engeneering the hardwares BUS, which are proprietary. So, even if they make the code public, some (probably many) changes need to be done, so that it can run on a normal pc. > If Sony were to pursue legal action against you, whether your activities > are legal or not is only secondary as the cost of defense is bound to be > prohibitive. Perhaps you can use LEGO's example to help persuade Sony > to release the software (with no support of course) using a suitable > open source license (ideally GPL of course). For now, I think I'll open a project at sourceforge to let them see that the code already runs without any problems. > In addition to looking to the LEGO community for ideas, you might find > some help at OSI and EFF. > > http://www.opensource.org/ > http://www.eff.org/ > http://www.crynwr.com/lego-robotics/ I've already contacted OSI, but not EFF. I'll also contact them. > Good luck! Thanks :) Nuno

March 14, 2006

Re: Dogfood status

by Mike Hearn

On Tue, 14 Mar 2006 07:54:28 -0800, Dan Kegel wrote: > 3) It took me a while to figure out how to copy and paste in putty, Heh, it takes me a while to figure that out on Windows too. I don't think there IS any UI for it, I keep expecting it to be in the window menu but to paste you actually have to right click IIRC. Maybe it's changed now. I keep meaning to find a decent Win32 news/email reader, but haven't found one yet. I'd be happy to dogfood a newsreader if anybody knows a good one. Only requirements are that it must support multiple news servers and gmane specifically, and it needs to understand threading. thanks -mike

March 14, 2006

Re: Some Processor(s) specific environment variables

by Paul Vriens

On Tue, 2006-03-14 at 19:13 +0100, Marcus Meissner wrote: > On Tue, Mar 14, 2006 at 06:35:39PM +0100, Paul Vriens wrote: > > Hi, > > > > there are some processor specific environment variables: > > > > NUMBER_OF_PROCESSORS=1 > > PROCESSOR_ARCHITECTURE=x86 > > PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 8, GenuineIntel > > PROCESSOR_LEVEL=6 > > PROCESSOR_REVISION=0908 > > > > (from a VMware box). > > > > These variables exist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet > > \Control\Session Manager\Environment. > > > > Psinfo.exe (from SysInternals) uses these env-variables to produce some > > information. > > > > When I remove the entries and reboot the box they are auto-generated > > again. > > > > My question is where to put the generation of these variables? We most > > likely want this with some defaults in wine.inf. Furthermore > > GetSystemInfo() could be changed, but that seems cheating. > > dlls/kernel/cpu.c does stuff like that, for instance. > > Ciao, Marcus > Yeah, that's where GetSystemInfo resides :-). GetSystemInfo however doesn't generate the mentioned keys. Would it be acceptable to put some sane defaults in wine.inf and have GetSystemInfo check and fill the correct keys in the registry? Or do we need a way to fill these keys at every boot of the system (start of wineserver)? Paul.

March 14, 2006

Re: Some Processor(s) specific environment variables

by Marcus Meissner

On Tue, Mar 14, 2006 at 06:35:39PM +0100, Paul Vriens wrote: > Hi, > > there are some processor specific environment variables: > > NUMBER_OF_PROCESSORS=1 > PROCESSOR_ARCHITECTURE=x86 > PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 8, GenuineIntel > PROCESSOR_LEVEL=6 > PROCESSOR_REVISION=0908 > > (from a VMware box). > > These variables exist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet > \Control\Session Manager\Environment. > > Psinfo.exe (from SysInternals) uses these env-variables to produce some > information. > > When I remove the entries and reboot the box they are auto-generated > again. > > My question is where to put the generation of these variables? We most > likely want this with some defaults in wine.inf. Furthermore > GetSystemInfo() could be changed, but that seems cheating. dlls/kernel/cpu.c does stuff like that, for instance. Ciao, Marcus

March 14, 2006

Some Processor(s) specific environment variables

by Paul Vriens

Hi, there are some processor specific environment variables: NUMBER_OF_PROCESSORS=1 PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 9 Stepping 8, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0908 (from a VMware box). These variables exist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Control\Session Manager\Environment. Psinfo.exe (from SysInternals) uses these env-variables to produce some information. When I remove the entries and reboot the box they are auto-generated again. My question is where to put the generation of these variables? We most likely want this with some defaults in wine.inf. Furthermore GetSystemInfo() could be changed, but that seems cheating. Any ideas? Cheers, Paul.

March 14, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Leon Freitag

> On Sun, Mar 12, 2006 at 05:44:57PM +0100, Leon Freitag wrote: > > The patch > > http://source.winehq.org/git/?p=wine.git;a=commit;h=13268261bbe0d4013937a > >6a9804fbda378244512 has introduced an annoying performance regression > > which affected all opengl games. (see > > http://bugs.winehq.org/show_bug.cgi?id=4499) > > Does this help? > > Huw. It is indeed a bit faster, however the performance is still far from the old value. I don't see any other way to speed this up the way it's being synced now, the question is however, whether the apps really _should_ modify the bitmap on windows too (don't know whether they would try to draw controls onto the window and then it would be overdrawn by the opengl image; application like Steam are trying to achieve similar, but they seemed to work well before) Leon

March 14, 2006

Re: Dogfood status

by Dan Kegel

On 3/14/06, Dimi Paun <dimi(a)lattica.com> wrote: > From: "Dan Kegel" <dank(a)kegel.com> > > Anyway, since Firefox is in fairly good good shape, I'm > > now running putty under wine instead of using linux's built-in ssh. > > Cool. IIRC putty builds as a Winelib app just fine, not that > it makes a difference... :) If I were on Sparc, PowerPC, or HPPA, I'd be glad about that :-) -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 14, 2006

Re: Dogfood status

by Dimi Paun

From: "Dan Kegel" <dank(a)kegel.com> > Anyway, since Firefox is in fairly good good shape, I'm > now running putty under wine instead of using linux's built-in ssh. Cool. IIRC putty builds as a Winelib app just fine, not that it makes a difference... :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 14, 2006

Dogfood status

by Dan Kegel

I've been dogfooding Wine with Firefox for some time. It's totally usable and good looking now. The four open bugs, http://bugs.winehq.org/show_bug.cgi?id=4523 (copy/paste problem) http://bugs.winehq.org/show_bug.cgi?id=4528 (too tall) http://bugs.winehq.org/show_bug.cgi?id=4762 (flash crash) http://bugs.winehq.org/show_bug.cgi?id=4829 (jerky animations) while serious, do not prevent me from getting work done. A new problem is that apps have been crashing with X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 every day. This is on Ubuntu 5.10 with updates, and might be a problem with the X server. I'll try updating to Ubuntu 6.04 flight 5 and see if that makes it go away. Anyway, since Firefox is in fairly good good shape, I'm now running putty under wine instead of using linux's built-in ssh. Works fine. Three annoyances: 1) takes a while (ten seconds) to open up session after clicking 'open'. 2) every keystroke yields the console message fixme:imm:ImmReleaseContext (0xb014e, 0x7fdbee18): stub 3) It took me a while to figure out how to copy and paste in putty, since Linux doesn't have the 'copy / paste' items in the upper left corner menu. (ctrl-insert and shift-insert work fine.) But that's a linux window manager issue, not a wine issue. Overall, I'm productive and happy. Success! Since those are the *only two gui apps I use* on Linux, I'm running out of things to dogfood! Oh, once in a while I need an image editor. Maybe I'll dogfood windows gimp next (quadruple yuck)... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 14, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Huw D M Davies

On Sun, Mar 12, 2006 at 05:44:57PM +0100, Leon Freitag wrote: > The patch > http://source.winehq.org/git/?p=wine.git;a=commit;h=13268261bbe0d4013937a6a… > has introduced an annoying performance regression which affected all opengl > games. (see http://bugs.winehq.org/show_bug.cgi?id=4499) Does this help? Huw. -- Huw Davies huw(a)codeweavers.com diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index 56c8ad1..aecba9c 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -78,6 +78,7 @@ static char* internal_gl_extensions = NU typedef struct wine_glcontext { HDC hdc; + DWORD type; Display *display; XVisualInfo *vis; GLXFBConfig fb_conf; @@ -106,7 +107,7 @@ void enter_gl(void) ctx = get_context_from_GLXContext(gl_ctx); wine_tsx11_unlock_ptr(); /* unlock before calling GDI apis */ - if(ctx && GetObjectType(ctx->hdc) == OBJ_MEMDC) + if(ctx && ctx->type == OBJ_MEMDC) ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); wine_tsx11_lock_ptr(); @@ -250,6 +251,7 @@ HGLRC WINAPI wglCreateContext(HDC hdc) ret = alloc_context(); LEAVE_GL(); ret->hdc = hdc; + ret->type = GetObjectType(hdc); ret->display = display; ret->fb_conf = cur_cfg; /*ret->vis = vis;*/ @@ -673,7 +675,7 @@ BOOL WINAPI wglShareLists(HGLRC hglrc1, if (org->ctx == NULL) { ENTER_GL(); describeContext(org); - org->ctx = glXCreateContext(org->display, org->vis, NULL, GetObjectType(org->hdc) == OBJ_MEMDC ? False : True); + org->ctx = glXCreateContext(org->display, org->vis, NULL, org->type == OBJ_MEMDC ? False : True); LEAVE_GL(); TRACE(" created a delayed OpenGL context (%p) for Wine context %p\n", org->ctx, org); } @@ -681,7 +683,7 @@ BOOL WINAPI wglShareLists(HGLRC hglrc1, ENTER_GL(); describeContext(dest); /* Create the destination context with display lists shared */ - dest->ctx = glXCreateContext(org->display, dest->vis, org->ctx, GetObjectType(org->hdc) == OBJ_MEMDC ? False : True); + dest->ctx = glXCreateContext(org->display, dest->vis, org->ctx, org->type == OBJ_MEMDC ? False : True); LEAVE_GL(); TRACE(" created a delayed OpenGL context (%p) for Wine context %p sharing lists with OpenGL ctx %p\n", dest->ctx, dest, org->ctx); return TRUE;

March 14, 2006

Launch native Linux apps? YES!!

by penna＠bb.com.br

Hi all, You can find more information on launching native Linux apps at the wiki: http://wiki.jswindle.com/index.php/Advanced_Wine_User_Information#Runing_Li… The example there works for any extension you want: .ODT, .DOC, .XLS, .PDF, .ODS, .RTF, .JPG and so on You just have to use your imagination and make your own shell scripts .... I already have some! Regards (I am not subscribed at wine-devel list). --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------

March 14, 2006

Re: wine and rpath

by Alexandre Julliard

Ivars Strazdins <ivarss(a)sets.lv> writes: > Hello all, > recently introduced rpath sets rpath to $ORIGIN > I wonder if $ORIGIN/../lib would not be more appropriate? Or is this > something my build-system specific? It's supposed to be set to $ORIGIN/../lib, it sounds like something went wrong with your build. -- Alexandre Julliard julliard(a)winehq.org

March 14, 2006

Re: need advise with new open-source project

by Jim White

Please note: http://en.wikipedia.org/wiki/IANAL Nuno Lopes wrote: > I'm currently trying to start a new open-source project that will do > the same as WINE did with the windows API, but for a Sony framework, > named OPEN-R. > ... > I would love if you could answer my questions, so that I can make the > project public as soon as possible. Your questions are quite involved and many do not have clear cut answers. And while there are some similarities between your project's issues and WINE's, there are some key legal differences, including particularly legal decisions regarding Microsoft's monopoly. Another similar situation existed with LEGO Mindstorms. While initial community developments were technically in violation of some terms of the EULA (which may or may not be enforceable in some jurisdictions) the key was LEGO's reaction. Rather than pursuing legal action against the community developers, they decided instead to embrace them and provide tacit and subsequently explicit support. If Sony were to pursue legal action against you, whether your activities are legal or not is only secondary as the cost of defense is bound to be prohibitive. Perhaps you can use LEGO's example to help persuade Sony to release the software (with no support of course) using a suitable open source license (ideally GPL of course). In addition to looking to the LEGO community for ideas, you might find some help at OSI and EFF. http://www.opensource.org/ http://www.eff.org/ http://www.crynwr.com/lego-robotics/ Good luck! Jim White

March 14, 2006

Re: Fwd: Hi

by Segin

The letter seems to check out as valid from what I can find. at any rate, there is a little-known solution that Microsoft has produced themselves that barely anyone ever used. Not many Microsoft employees still remember it cause it was a back-burner feature for 95/98: QuickView. You coul right-click on a file, select QuickView, and a window would popup showing the document, or if an executable, a list of infomation about it that is highly detailed, including ordinals, synbols, relocations, all sorts of offsets, and a number of useful things. It would dump infomation for PE and NE executables, and also MZ headers (DOS exec and stubs). Sadly, I don't know why a Microsoft employee didn't think of this before. It would be simple to get the Wine system libraries from the wine-win32-dlls package, and use a test Win98 box or so to find out what ordinals are in them. Of couse, the gre/Winedump/Linux solution is also suggested. Try running that in combination of gdb. Hans Leidekker wrote: >Hi list, > >I'm forwarding a question from someone at Microsoft(!). I could >recommend grep, winedump and Linux of course but I was wondering if >anyone on this list has a good suggestion for this guy? > >Don't believe it? I didn't either, but look at the headers, this mail >was accepted from a mailserver in the microsoft.com domain: > >Return-Path: <a-gaolap(a)microsoft.com> >Received: from mail.vu.nl (IDENT:MU9AWzJpIWdhZlkI0e97gBGdUUEagQyZ(a)mail.vu.nl [130.37.129.161]) > by mail.it.vu.nl (8.11.6/8.11.6) with ESMTP id k2DHsnL15211 > for <hans(a)mail.it.vu.nl>; Mon, 13 Mar 2006 18:54:49 +0100 >Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) > by mail.vu.nl (8.11.6/8.11.6) with ESMTP id k2DHsjW13651 > for <hans(a)it.vu.nl>; Mon, 13 Mar 2006 18:54:46 +0100 >Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); > Mon, 13 Mar 2006 09:54:41 -0800 >Received: from RED-MSG-50.redmond.corp.microsoft.com ([157.54.61.146]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); > Mon, 13 Mar 2006 09:54:41 -0800 > >And here's the line from our mailserver log: > >Mar 13 18:54:46 nath sendmail[13651]: k2DHsjW13651: from=<a-gaolap(a)microsoft.com>, size=6136, class=0, nrcpts=1, > msgid=<22DDEC51216B404E8C056F8F5198E9270616976E(a)RED-MSG-50.redmond.corp.microsof…>, proto=ESMTP, daemon=MTA, > relay=mail1.microsoft.com [131.107.3.125] > > -Hans > >---------- Forwarded Message ---------- > >Subject: Hi >Date: Monday 13 March 2006 18:54 >From: "Gaolai Peng $Volt$" <a-gaolap(a)microsoft.com> >To: hans(a)it.vu.nl > >Hi Hans, > > > >My name is Gaolai. I am working on antivirus software for MS exchange. > > > >One of our customers gets following error when he opened our product, >"the ordinal 319 could not be located in the Dynamic link library >wldap32.dll, "initialization of dll msrd2x40.dll terminated". For sure >our product doesn't need ordinal 319, ldap_create_vlv_control. His >environment is NT 4.0 SP 6. I looked up the msdn, func >ldap_create_vlv_control requires Windows Vista or Windows XP. So I >figured the user must have installed some software that needs at least >XP or Vista? > >>From http://source.winehq.org/source/ChangeLog, I found out you were the > >first person who implemented this function. Can you give some suggestion >about how do I find out what software needs ordinal 319? What I am >supposed to do to fix this without suggesting the user to install XP? > > > >Thanks. > > > >Gaolai > >------------------------------------------------------- > > > > >

March 14, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi guys, Thanks a lot for all your replies... After further inspection, it seems the problem is when I try to share display lists from one context to another. I've attached the program and the source code, so you can try it. As you can see, I first create a context and then I create a second context but sharing the display lists of the first one. If you run this program, you'll see the BadMatch error I was reporting in my first email. However, if you don't share display lists (that is, change the line Context.Create(0, 0, true) to Context.Create(0, 0, false)), everything works ok. Jesse, I've made the changes proposed in those patches, but it didn't work :-( By the way, I'm using wine .9.9. Cheers, Wino _________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 13, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Alex Villacís Lasso

Alex Villacís Lasso wrote: > I would like to draw attention to bug 4502. This bug can cause any VB > application to crash when the DatePicker control is used, and an > attempt is made to assign a date value in VB code. Even though I found > this bug while testing an application I wrote, this might not be > specific to this application. It is only recently that I have some > time to dedicate to this bug, but I would like somebody to comment on > this. > > When the sample application is run with WINEDEBUG=ole,variant, the > failing invocation looks like this: > > trace:ole:ITypeInfo_fnInvoke > (0x7fdd5440)(0x7fd9f61c,id=20,flags=0x00000004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c) > > trace:ole:dump_DispParms args=1 named args=1 > trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) > trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) > trace:ole:dump_Variant ,2006/03/12 00:00:00} > trace:ole:ITypeInfo_fnInvoke invoking: > L"Value"(1) > parm0: L"Value" > memid is 00000014 > Param 0: > tdesc.vartype 12 (VT_VARIANT) > u.paramdesc.wParamFlags PARAMFLAG_FIN > u.paramdesc.lpex (nil) > funckind: 1 (pure virtual) > invkind: 4 (property put) > callconv: 4 (stdcall) > oVft: 224 > cParamsOpt: 0 > wFlags: 3c > elemdescFunc (return value type): > tdesc.vartype 25 (VT_HRESULT) > u.paramdesc.wParamFlags PARAMFLAGS_NONE > u.paramdesc.lpex (nil) > helpstring: L"Returns/sets the current date." > entry: (null) > trace:ole:ITypeInfo_fnInvoke changing args > trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) > trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) > trace:ole:dump_Variant ,2006/03/12 00:00:00} > trace:variant:VariantChangeTypeEx > (0x7fdd5520->(VT_DATE),0x7fa3eef4->(VT_DATE),0x00000400,0x0000,VT_VARIANT) > > trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) > trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) > trace:variant:VariantCopyInd > (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) > trace:variant:VariantCopy (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) > trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) > trace:variant:VARIANT_Coerce > (0x7fa3ec40->(VT_EMPTY),0x00000400,0x0000,0x7fa3ec30->(VT_DATE),VT_VARIANT) > > trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) > trace:variant:VariantClear (0x7fa3ec30->(VT_DATE)) > trace:variant:VariantChangeTypeEx returning 0x80020005, > 0x7fdd5520->(VT_DATE) > err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT > from VT_DATE > trace:ole:ITypeInfo_fnInvoke -- 0x80020005 > > The Property Put seems to be declared as taking one VT_VARIANT > parameter, and the VB code supplies a VT_DATE value. Therefore, an > attempt is made to coerce VT_DATE --> VT_VARIANT. However, > VariantChangeTypeEx() does not support conversion of *any* kind of > variant into VT_VARIANT, so the call fails, and this brings down the > application. I was on half a mind to add the VT_VARIANT conversion to > VariantChangeTypeEx() myself, but then I checked the tests for this > operation, and it seems that the absence of support for VT_VARIANT is > actually expected (unless I am misreading the code). Therefore, one of > the following two things is happening: > > 1) There is some error in the reading of the typelib, since a Property > Put should not have a VT_VARIANT parameter in the first place. > 2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself, > precisely because VariantChangeTypeEx() won't do it. > > I am inclined to the second option, but I want to hear some comment > before attempting to create a patch. > > Alex Villacís Lasso > After some digging, I found that bugs 4370 and 4573 seem to expose the same problem. The root cause (in bug 4370) seems to be a patch by Robert Shearman that rewrites ITypeInfo::Invoke to use VariantChangeTypeEx (commit at http://source.winehq.org/git/?p=wine.git;a=commit;h=8cf5373f60aca5345a0c55d…) Saved me the trouble of the regression testing. Alex Villacís Lasso

March 13, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/13/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Hi > > I'm pretty new to wine, and this is my first post to the wine-devel > list....I hope this is the correct place to send my question > > I'm having problems with wglMakeCurrent. I wrote a small OpenGL test > program, but it's not working under wine (it works perfectly on Windows). > When I call wglMakeCurrent, wine outputs this error: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 144 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 120 > Current serial number in output stream: 120 > > I activated the debug output for opengl, and I can see that the problem is a > mismatch between the default visual ID and my program visual ID. At the top > of the debug output, I see this: > trace:opengl:X11DRV_setup_opengl_visual Visual ID 21 Chosen > > and later, when I create my OpenGl context: > > trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 > > Obviously, the problem is that my visual ID doesn't match with the > X-Window's default, but I need to work using my visual (because I need alpha > planes) > > Any known workaround or is this a bug on wine's implementation of > wglMakeCurrent? > > Thanks > > Wino > > Looks like another example of bug 4143 or 4604. Proposed patches are here: http://bugs.winehq.org/show_bug.cgi?id=4143 Please try them out and see if it fixes the problem. It will also help for you to post the test program somewhere so other people can try and maybe it can be included in the wine test suite. Jesse

March 13, 2006

Fwd: Hi

by Hans Leidekker

Hi list, I'm forwarding a question from someone at Microsoft(!). I could recommend grep, winedump and Linux of course but I was wondering if anyone on this list has a good suggestion for this guy? Don't believe it? I didn't either, but look at the headers, this mail was accepted from a mailserver in the microsoft.com domain: Return-Path: <a-gaolap(a)microsoft.com> Received: from mail.vu.nl (IDENT:MU9AWzJpIWdhZlkI0e97gBGdUUEagQyZ(a)mail.vu.nl [130.37.129.161]) by mail.it.vu.nl (8.11.6/8.11.6) with ESMTP id k2DHsnL15211 for <hans(a)mail.it.vu.nl>; Mon, 13 Mar 2006 18:54:49 +0100 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.vu.nl (8.11.6/8.11.6) with ESMTP id k2DHsjW13651 for <hans(a)it.vu.nl>; Mon, 13 Mar 2006 18:54:46 +0100 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 13 Mar 2006 09:54:41 -0800 Received: from RED-MSG-50.redmond.corp.microsoft.com ([157.54.61.146]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Mar 2006 09:54:41 -0800 And here's the line from our mailserver log: Mar 13 18:54:46 nath sendmail[13651]: k2DHsjW13651: from=<a-gaolap(a)microsoft.com>, size=6136, class=0, nrcpts=1, msgid=<22DDEC51216B404E8C056F8F5198E9270616976E(a)RED-MSG-50.redmond.corp.microsof…>, proto=ESMTP, daemon=MTA, relay=mail1.microsoft.com [131.107.3.125] -Hans ---------- Forwarded Message ---------- Subject: Hi Date: Monday 13 March 2006 18:54 From: "Gaolai Peng $Volt$" <a-gaolap(a)microsoft.com> To: hans(a)it.vu.nl Hi Hans, My name is Gaolai. I am working on antivirus software for MS exchange. One of our customers gets following error when he opened our product, "the ordinal 319 could not be located in the Dynamic link library wldap32.dll, "initialization of dll msrd2x40.dll terminated". For sure our product doesn't need ordinal 319, ldap_create_vlv_control. His environment is NT 4.0 SP 6. I looked up the msdn, func ldap_create_vlv_control requires Windows Vista or Windows XP. So I figured the user must have installed some software that needs at least XP or Vista? >From http://source.winehq.org/source/ChangeLog, I found out you were the first person who implemented this function. Can you give some suggestion about how do I find out what software needs ordinal 319? What I am supposed to do to fix this without suggesting the user to install XP? Thanks. Gaolai -------------------------------------------------------

March 13, 2006

need advise with new open-source project

by Nuno Lopes

Hi, I'm currently trying to start a new open-source project that will do the same as WINE did with the windows API, but for a Sony framework, named OPEN-R. This framework allows users to write programs for Sony's robots (namely the dog AIBO). But Sony has discontinued the robotics division and they won't provide support for the framework. I already have the initial code running. I can already compile the code for a non-MIPS platform (their robots are MIPS based) and also load the code and run it. Of course there are still many function stubs. My question is about legal things. Is it considered reverse-engineering to re-implement the Sony's framework (the API is somewhat documented)? Did you have some law problems with Microsoft? One more thing: How do you do with the headers? do you use original Microsoft's headers or did you rewrite them? I'm currently using Sony's headers, which can't be redistributed. So I also have a problem here. How can I rewrite the headers, so that they aren't considered a copy?? I would love if you could answer my questions, so that I can make the project public as soon as possible. Best Regards, Nuno P.S.: btw, nice work with valgrind ;) I think I'll start to test my windows apps for memleaks in linux.

March 13, 2006

Re: x11drv: One more fix for "stuck" ctrl, shift & alt.

by Kuba Ober

On Saturday 11 March 2006 14:03, Tomas Carnecky wrote: > Vitaliy Margolen wrote: > > Anything wrong with this patch? It does fix the "stuck alt" problem for > > games I use alt+tab on. > > I can confirm that this fixes the bug. This patch is very important for > me as I don't have to switch back and forth between desktop and WoW to > un-stuck they alt-key. This patch works fine and I don't see any > side-effects. This problem affects non-game applications as well. Happens all the time with Zilog Developer Studio II, an IDE for embedded application development. So, here's my vote for this patch :) Cheers, Kuba Ober

March 13, 2006

Re: wglMakeCurrent

by Victor Pelt

Hey Wino i think it might be helpfull to at least include the code you wrote. furthermore, my understanding (and someone please correct me if i'm wrong) of wine-devel is to discuss solutions and the like, not for filing bug reports regards Victor Pelt On Mon, 2006-03-13 at 13:00 -0500, Wino Rojo wrote: > Hi > > I'm pretty new to wine, and this is my first post to the wine-devel > list....I hope this is the correct place to send my question > > I'm having problems with wglMakeCurrent. I wrote a small OpenGL test > program, but it's not working under wine (it works perfectly on Windows). > When I call wglMakeCurrent, wine outputs this error: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 144 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 120 > Current serial number in output stream: 120 > > I activated the debug output for opengl, and I can see that the problem is a > mismatch between the default visual ID and my program visual ID. At the top > of the debug output, I see this: > trace:opengl:X11DRV_setup_opengl_visual Visual ID 21 Chosen > > and later, when I create my OpenGl context: > > trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 > > Obviously, the problem is that my visual ID doesn't match with the > X-Window's default, but I need to work using my visual (because I need alpha > planes) > > Any known workaround or is this a bug on wine's implementation of > wglMakeCurrent? > > Thanks > > Wino > > _________________________________________________________________ > Take advantage of powerful junk e-mail filters built on patented Microsoft > SmartScreen Technology. > http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… > Start enjoying all the benefits of MSN Premium right now and get the > first two months FREE*. > >

March 13, 2006

OLEAUT32: bug 4502 - request for comment before trying to fix

by Alex Villacís Lasso

I would like to draw attention to bug 4502. This bug can cause any VB application to crash when the DatePicker control is used, and an attempt is made to assign a date value in VB code. Even though I found this bug while testing an application I wrote, this might not be specific to this application. It is only recently that I have some time to dedicate to this bug, but I would like somebody to comment on this. When the sample application is run with WINEDEBUG=ole,variant, the failing invocation looks like this: trace:ole:ITypeInfo_fnInvoke (0x7fdd5440)(0x7fd9f61c,id=20,flags=0x00000004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c) trace:ole:dump_DispParms args=1 named args=1 trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) trace:ole:dump_Variant ,2006/03/12 00:00:00} trace:ole:ITypeInfo_fnInvoke invoking: L"Value"(1) parm0: L"Value" memid is 00000014 Param 0: tdesc.vartype 12 (VT_VARIANT) u.paramdesc.wParamFlags PARAMFLAG_FIN u.paramdesc.lpex (nil) funckind: 1 (pure virtual) invkind: 4 (property put) callconv: 4 (stdcall) oVft: 224 cParamsOpt: 0 wFlags: 3c elemdescFunc (return value type): tdesc.vartype 25 (VT_HRESULT) u.paramdesc.wParamFlags PARAMFLAGS_NONE u.paramdesc.lpex (nil) helpstring: L"Returns/sets the current date." entry: (null) trace:ole:ITypeInfo_fnInvoke changing args trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) trace:ole:dump_Variant ,2006/03/12 00:00:00} trace:variant:VariantChangeTypeEx (0x7fdd5520->(VT_DATE),0x7fa3eef4->(VT_DATE),0x00000400,0x0000,VT_VARIANT) trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) trace:variant:VariantCopyInd (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) trace:variant:VariantCopy (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) trace:variant:VARIANT_Coerce (0x7fa3ec40->(VT_EMPTY),0x00000400,0x0000,0x7fa3ec30->(VT_DATE),VT_VARIANT) trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) trace:variant:VariantClear (0x7fa3ec30->(VT_DATE)) trace:variant:VariantChangeTypeEx returning 0x80020005, 0x7fdd5520->(VT_DATE) err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT from VT_DATE trace:ole:ITypeInfo_fnInvoke -- 0x80020005 The Property Put seems to be declared as taking one VT_VARIANT parameter, and the VB code supplies a VT_DATE value. Therefore, an attempt is made to coerce VT_DATE --> VT_VARIANT. However, VariantChangeTypeEx() does not support conversion of *any* kind of variant into VT_VARIANT, so the call fails, and this brings down the application. I was on half a mind to add the VT_VARIANT conversion to VariantChangeTypeEx() myself, but then I checked the tests for this operation, and it seems that the absence of support for VT_VARIANT is actually expected (unless I am misreading the code). Therefore, one of the following two things is happening: 1) There is some error in the reading of the typelib, since a Property Put should not have a VT_VARIANT parameter in the first place. 2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself, precisely because VariantChangeTypeEx() won't do it. I am inclined to the second option, but I want to hear some comment before attempting to create a patch. Alex Villacís Lasso

March 13, 2006

Re: wglMakeCurrent

by Christoph Frick

On Mon, Mar 13, 2006 at 01:00:08PM -0500, Wino Rojo wrote: > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 144 (GLX) > Minor opcode of failed request: 5 (X_GLXMakeCurrent) > Serial number of failed request: 120 > Current serial number in output stream: 120 just FYI: I have the same problem with NASCAR Racing Season 2003 in OpenGL mode. And I had the same problem with Pacific Fighters (but not with IL2, which is basically the same engine - but I use now the comined installation). On the other hand several other OpenGL games work flawless (Grand Prix Legends, IL2). -- cu

March 13, 2006

wglMakeCurrent

by Wino Rojo

Hi I'm pretty new to wine, and this is my first post to the wine-devel list....I hope this is the correct place to send my question I'm having problems with wglMakeCurrent. I wrote a small OpenGL test program, but it's not working under wine (it works perfectly on Windows). When I call wglMakeCurrent, wine outputs this error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 120 Current serial number in output stream: 120 I activated the debug output for opengl, and I can see that the problem is a mismatch between the default visual ID and my program visual ID. At the top of the debug output, I see this: trace:opengl:X11DRV_setup_opengl_visual Visual ID 21 Chosen and later, when I create my OpenGl context: trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 Obviously, the problem is that my visual ID doesn't match with the X-Window's default, but I need to work using my visual (because I need alpha planes) Any known workaround or is this a bug on wine's implementation of wglMakeCurrent? Thanks Wino _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 13, 2006

wine and rpath

by Ivars Strazdins

Hello all, recently introduced rpath sets rpath to $ORIGIN I wonder if $ORIGIN/../lib would not be more appropriate? Or is this something my build-system specific? $ORIGIN just does not work to me, I really need $ORIGIN/../lib, if --prefix is set to non-default, non /usr value. Thank you, Ivar

March 13, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Jan Z.

Thank you, Andreas Jaeger for the clarification regarding the inclusion of Winetools in SUSE. On Thu, Mar 09, 2006 at 02:27:23PM +0100, Joachim von Thadden wrote: > Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki: > > Winetools is only sporadically updated for new versions of Wine > > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this > > site also contains some warnings regarding the support status). > > WineTools is not "sporadically" updated as it makes no sense to update > it with every new Wine release. The purpose is not to keep track Wine, > the purpose is to have a stable basis. As such WineTools often stays > with a specific Wine version for a time. This is the same what > Crossover-Office does. So you would also not include that if you were > allowed to? Sorry, I wasn't aware of that. Perhaps then the best for Winetools users and Wine developers is to enable Winetools to be distributed with it's own version of Wine (as cx-office and cedega do it) and (as someone else already suggested) to save it's data and fake Windows under .winetools . That would also prevent problems when a distribution contains a version of Wine that is not supposed to be used with the contained version of Winetools. For example afaik the SUSE factory tree contains Wine 0.9.5 and Winetools 0.9jo but your website suggests Wine 0.9.{1,2,3} for that Winetools version. What do you think about this? > > Winetools radically alters some vital Wine settings and thus > > makes many other apps fail. > > This first part is true, the second definitely not. WineTools is at the > moment the only way to have all major commercial windows programs run > simultaneously with Wine under Linux if you do not want to pay for > Crossover-Office. I think you forgot that one can manually configure wine to support that, even if it is a bit of work. > If what you say is true then name the apps that fail with WineTools and > run with *plain* Wine. I am waiting for your list. And I will include > them in the next release (if I can download them legaly). >From various users i got the impression the most problems where with Steam and apps that don't work with Windows version set to win98. But all this may be the fault of those users and i never tried winetools my self... So better ask your users if you want to make winetools better. Jan

March 13, 2006

Re: dlls: Move the call to MODULE_DllThreadAttach from kernel32 code to NTDLL code

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Move the call to MODULE_DllThreadAttach from kernel32 code to NTDLL code. The problem with this is that the call is no longer inside the exception handler, so it would prevent debugging crashes that happen during thread attach. -- Alexandre Julliard julliard(a)winehq.org

March 13, 2006

Re: wine dev packages

by Segin

Jason Green wrote: >>I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, >>and I believe that they are at least 95% accurate, although I might >>have missed one somewhere. If someone can add the package names >>required for a gentoo build (or possibly create and maintain wine-cvs >>packages with all of the necessary deps???), it would probably help >>out many users trying to compile from source. >> Gentoo users have a Wine ebuild to build from CVS, with version major '9999' Simply put, you install the latest Wine CVS like this: emerge =wine-9999 and it also pulls all deps.

March 13, 2006

Re: GDI32: using the embeded bitmap in antialias mode

by Byeong-Sik Jeon

2006-03-13 (월), 04:10 +0900, Byeong-Sik Jeon 쓰시길: > If format == WINE_GGO_GRAY16_BITMAP at the "WineEngGetGlyphOutline()", > set on "FT_LOAD_NO_BITMAP". > I mistake. When format == WINE_GGO_GRAY16_BITMAP, skip that set on "FT_LOAD_NO_BITMAP".

March 12, 2006

Re: ddraw design flaw

by Tomas Carnecky

Stefan Dösinger wrote: > Hi, >> I have found a design flaw in ddraw and described it in my 'World of >> Warcraft 0.10 Public Test Real (PTR)' thread. Why has nobody adressed >> this issue? In my eyes it is a severe design flaw if an application >> can't unload ddraw.dll without side effects (especially if this >> side-effect is that all opengl/directx applications are unusable after >> that). > The ddraw implementation has some unloading bugs at the moment. Not restoring > the glx context(that's the problem you reported, right) is only one of them. > Another is that the screen resolution isn't restored when the app doesn't > care for releasing it's object. > > I have this problem in mind, and I'll check WineD3D for it, as it most likely > affects all D3D libs. Once it's fixed in wineD3D and ddraw uses wineD3D for > rendering, this should be sorted out. > > Sorry for not fixing this at once, but time is limited ;). If you want a > solution now, you're free to fix ddraw. But I registered that issue and it's > on my lenghty todo list. > > Thanks for the info. It's good to see that it's a known issue and that it's on someones TODO list. I'm trying to find out whether Survey.dll will be part of the final 1.10 release or if it's only part of the PTR client. I haven't had any luck so far. I don't know why Blizzard doesn't want to give me this information, we'll find out sooner or later (eg. the day when they release 1.10), it just would be nice to know whether the WoW players need a patch or not. I'm not very familiar with wine so I probably won't be able to write a better patch. tom

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Tony Lambregts

James Trotter wrote: > > > On 3/12/06, *Jesse Allen* <the3dfxdude(a)gmail.com > <mailto:the3dfxdude(a)gmail.com>> wrote: >> >> Yeah, that's bad, but so is this AppDB page: >> http://appdb.winehq.org/appview.php?versionId=1177 >> >> People seem to think that the AppDB comment sections are a good place >> to post logs. It made the page really long. So I put this as the >> first thing in the howto: >> >> "Reporting Problems >> >> If you encounter a problem, send your report to Wine-Users Mailing >> List or WineHQ Bugzilla. These places are much faster for getting >> help, and bugzilla is better for posting logs." >> >> And it mostly seemed to work. And there are alot more new bug links >> now. But then they added the "testing" section and people use that >> too to report their problems and for pasting logs. I wish they would >> be brief in those and link to bug #'s instead. >> >> And true it is the same that the logs aren't good in the bugzilla >> comments either. They should upload them seperate. I guess there are >> a lot of new people that haven't dealt with this system. The new note >> should help. >> >> One of these days I'd really like to clean up the old comments on the >> AppDB page, but I don't want to scare anyone with mass deletions. It >> takes a long time to load on dialup. > > I'm curious what the policy about cleaning up comments on the appdb is. If a > user posts about a comment about some problem with the application, and the > problem later is fixed, should the comment be removed? Yes these can be deleted > What about bug links? Should they be removed once the bug is fixed or closed? > No at least for now. There probably should be an option to hide resolved and closed bugs though. > > The maintainer's guidelines page says: "If a comment is useless or is not > true anymore, you can safely delete it." Though, if you look at AppDB entries > like the one above, this doesn't seem to happen. Perhaps the maintainer's > guidelines could be a bit more specific? That seems pretty straight for ward to me. Could you clarify what you mean. > Also, the guidelines don't even mention bug links. > Well the guideline is not to delete bug links unless they never did apply to the application version. (If the bug link was submitted in error then delete it) -- Tony Lambregts

March 12, 2006

Re: RFC: Make SetThreadContext work properly

by Vitaliy Margolen

Sunday, March 12, 2006, 7:18:30 AM, Dimi Paun wrote: > Hi Alexandre, >>From a quick look at the code, it seems that you've already fixed > the problem addressed by Mike's patch: > http://wiki.winehq.org/Make_SetThreadContext_work_properly > revision 1.53 > date: 2006/01/11 20:36:17; author: julliard; state: Exp; lines: +38 > -24 > Alexandre Julliard <julliard(a)winehq.org> > ntdll: Handle NtSetContextThread on the client side (as far as > possible) when setting the context of the current thread. > Just checking so I can remove the patch from the wiki if it's > no longer relevant. Yes it is fixed with that Alexandre's patch you mentioned. Vitaliy.

March 12, 2006

wine dev packages (was: Can't run DirectX games on x86_64 Linux)

by Detlef Riekenberg

Jason Green wrote: > Correct, wine will compile and run without a lot of features and never > warn you that they don't exist. See this wiki page for an example of > what your include/config.h file should probably look like: > > http://wiki.winehq.org/Recommended_Packages > > I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, > and I believe that they are at least 95% accurate, although I might > have missed one somewhere. If someone can add the package names > required for a gentoo build (or possibly create and maintain wine-cvs > packages with all of the necessary deps???), it would probably help > out many users trying to compile from source. IMHO, wine-cvs with all packages is not a good idea. I'm testing xubuntu and i do not want to install kde/gnome. Using multiple packages (wine-kde-cvs / wine-gnome-cvs / ...) are hard to maintain. And what about the different audio-driver? Even more difficult is the OpenGL-Part (mesa / nvidia / ati) I split the List in the Wiki to make clear, for which dlls which packages are needed. The split is not complete yet, and IMHO the List is also wrong (examples: libusb-dev, libqt3-mt-dev) Feel free to update Fedora similar. -- By by ... Detlef

March 12, 2006

RFC: Make SetThreadContext work properly

by Dimi Paun

Hi Alexandre, >From a quick look at the code, it seems that you've already fixed the problem addressed by Mike's patch: http://wiki.winehq.org/Make_SetThreadContext_work_properly revision 1.53 date: 2006/01/11 20:36:17; author: julliard; state: Exp; lines: +38 -24 Alexandre Julliard <julliard(a)winehq.org> ntdll: Handle NtSetContextThread on the client side (as far as possible) when setting the context of the current thread. Just checking so I can remove the patch from the wiki if it's no longer relevant. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 12, 2006

Re: My guess why Munich doesn't like Wine

by Tom Wickline

On 3/12/06, Dan Kegel <dank(a)kegel.com> wrote: > > Given that the world kind of treats this as a must, > perhaps it could be added as a criterion for > a 1.0 release. Say, where's the existing page > describing our release criteria? The page we had was for a 0.9 release, I suppose the criteria for the 1.0 release will be discussed at this year's conference. Tom > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > >

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by James Trotter

On 3/12/06, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > What? You mean having all the pastes in this bug: > http://bugs.winehq.org/show_bug.cgi?id=4131 > > adds to it's readability? This is just one bug that I could think of. > > Also note that the biggest paste by author has nothing to do with the > bug > > itself. > > > > Vitaliy > > > > > > > > Yeah, that's bad, but so is this AppDB page: > http://appdb.winehq.org/appview.php?versionId=1177 > > People seem to think that the AppDB comment sections are a good place > to post logs. It made the page really long. So I put this as the > first thing in the howto: > > "Reporting Problems > > If you encounter a problem, send your report to Wine-Users Mailing > List or WineHQ Bugzilla. These places are much faster for getting > help, and bugzilla is better for posting logs." > > And it mostly seemed to work. And there are alot more new bug links > now. But then they added the "testing" section and people use that > too to report their problems and for pasting logs. I wish they would > be brief in those and link to bug #'s instead. > > And true it is the same that the logs aren't good in the bugzilla > comments either. They should upload them seperate. I guess there are > a lot of new people that haven't dealt with this system. The new note > should help. > > One of these days I'd really like to clean up the old comments on the > AppDB page, but I don't want to scare anyone with mass deletions. It > takes a long time to load on dialup. > > > I'm curious what the policy about cleaning up comments on the appdb is. If a user posts about a comment about some problem with the application, and the problem later is fixed, should the comment be removed? What about bug links? Should they be removed once the bug is fixed or closed? The maintainer's guidelines page says: "If a comment is useless or is not true anymore, you can safely delete it." Though, if you look at AppDB entries like the one above, this doesn't seem to happen. Perhaps the maintainer's guidelines could be a bit more specific? Also, the guidelines don't even mention bug links. -James

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by Rein Klazes

On Sat, 11 Mar 2006 19:23:14 -0800, you wrote: >Pardon intrusion by this Wine user into this technical discussion. > >Is the problem with Pegasus Mail (PM) that is mentioned below something that is >new with Wine 0.9.9? I know that I saw termination of "the complete program" >whenever I sent a message using PM 4.31 and Wine 0.9.9. As a result I've >reverted to Wine 0.9.8 and have none of this. You do not even have to send the message, just closing the compose new message window is enough. Yes, it is new in 0.9.9. Rein.

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Rein Klazes

On Sat, 11 Mar 2006 12:30:39 -0700, you wrote: >> Not pasting back traces will make following the bug list by email rather >Well it might be true, but to a point. Most of the debug traces are too >wide and e-mail wraps them (so does maillist archive). That _does_ make >it nearly impossible to see anything. I said "backtraces". You talk about debug traces, the backtraces are good to follow. I agree that logs are mostly too large to post, but then most people already attach those. > >> useless. IMO what people are currently posting in bugzilla do not >> require such recommendations. > >What? You mean having all the pastes in this bug: http://bugs.winehq.org/show_bug.cgi?id=4131 >adds to it's readability? Honestly I do not see your problem here. To me it is readable both on the web and by email. Perhaps the web form could be reversed so that new reactions are on top, if the scrolling is your problem. Rein.

March 12, 2006

My guess why Munich doesn't like Wine

by Dan Kegel

After poking at the apps they tested with, the conclusion is: they wanted something that could run Access and Oracle client apps, and Wine just wasn't there yet. It still isn't, judging by my quick tests. Given that the world kind of treats this as a must, perhaps it could be added as a criterion for a 1.0 release. Say, where's the existing page describing our release criteria? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 12, 2006

Oracle Express Client under Wine - install fails in advapi.CreateService

by Dan Kegel

At the risk of posting too much information, here's another roadblock faced by an important potential user. keeptool.com's hora.exe (one of the apps needed by the european government desktop migration) is an Oracle DBA helper tool, and testing it means connecting to an Oracle database. That means, I think, installing the Oracle client library under Wine. Sadly, this fails during install; the installer claims that advapi.CreateService is crashing. ( See http://bugs.winehq.org/show_bug.cgi?id=4802 ) Somebody with a little free time could probably learn more by adding more trace statements in CreateService. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by James E. Lang

Pardon intrusion by this Wine user into this technical discussion. Is the problem with Pegasus Mail (PM) that is mentioned below something that is new with Wine 0.9.9? I know that I saw termination of "the complete program" whenever I sent a message using PM 4.31 and Wine 0.9.9. As a result I've reverted to Wine 0.9.8 and have none of this. -- Jim Rein Klazes wrote at 15:20 on 11 Mar 2006: > On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: > > > >Author: Francois Gouget <fgouget(a)codeweavers.com> > >Date: Fri Feb 24 15:34:09 2006 +0100 > > > >user32: Handle WM_ENDSESSION in DefWinProc(). > >DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the > >shutdown is proceeding. > > Hi Francois, > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. <snip>

March 12, 2006

Re: spss can't even install...

by Willie Sippel

Am Samstag, 11. März 2006 07:06 schrieb Dan Kegel: > p.s. one downside of using wine to run firefox as your main > browser is it's a bit more dangerous to do the > rm -rf ~/.wine > needed to do a really clean install of a test app :-) > so this test was done with a fairly cluttered fake wine directory. > But it seems to match the results in the PR. Why not simply use a seperate dir for your experiments? "WINEPREFIX=~/.winetest wineprefixcreate" and "WINEPREFIX=~/.winetest wine $RANDOM_TEST_APP" should be all you need, no? ;-) -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 12, 2006

DDraw over WineD3D - Indexed colour visuals

by Adam Luchjenbroers

I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D and decided try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues). Short answer, no. Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution. -- "Most people would rather die than think; in fact, they do so." - Bertrand Russell (1872 - 1970)

March 12, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Jesse Allen

On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > What? You mean having all the pastes in this bug: http://bugs.winehq.org/show_bug.cgi?id=4131 > adds to it's readability? This is just one bug that I could think of. > Also note that the biggest paste by author has nothing to do with the bug > itself. > > Vitaliy > > > Yeah, that's bad, but so is this AppDB page: http://appdb.winehq.org/appview.php?versionId=1177 People seem to think that the AppDB comment sections are a good place to post logs. It made the page really long. So I put this as the first thing in the howto: "Reporting Problems If you encounter a problem, send your report to Wine-Users Mailing List or WineHQ Bugzilla. These places are much faster for getting help, and bugzilla is better for posting logs." And it mostly seemed to work. And there are alot more new bug links now. But then they added the "testing" section and people use that too to report their problems and for pasting logs. I wish they would be brief in those and link to bug #'s instead. And true it is the same that the logs aren't good in the bugzilla comments either. They should upload them seperate. I guess there are a lot of new people that haven't dealt with this system. The new note should help. One of these days I'd really like to clean up the old comments on the AppDB page, but I don't want to scare anyone with mass deletions. It takes a long time to load on dialup.

March 12, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by Francois Gouget

Hi, Rein Klazes wrote: [...] > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. > Here is a part of SPY++ log when run under win2000, when I close the > edit new mail dialog: > > |<00202> 00130A82 S ..........................WM_SYSCOMMAND uCmdType:SC_CLOSE xPos:672 yPos:121 [wParam:0000F060 lParam:007902A0] > |<00203> 00130A82 S ...........................WM_CLOSE wParam:00000000 lParam:00000000 > |<00204> 00130A82 S ............................WM_QUERYENDSESSION nSource:1 (End Task from Task List dialog) [wParam:00000001 lParam:00000000] > |<00951> 00130A82 R ............................WM_QUERYENDSESSION fShutdownIsOk:True [lResult:00000001] > ... > |<00952> 00130A82 S ............................WM_ENDSESSION fEndSession:True [wParam:00000001 lParam:00000000] > |<00953> 00130A82 R ............................WM_ENDSESSION lResult:00000000 > > The WM_QUERYENDSESSION and WM_ENDSESSION are sent by the program: > > |0009:Call user32.SendMessageA(00030024,00000011,00000001,00000000) ret=0040641d It's pretty weird that the application is sending a WM_QUERYENDSESSION/WM_ENDSESSION to itself. > How did you check the behavior of the Windows DefWindowProc? If I put a > DefWindowProc(hwnd, WM_ENDSESSION, 1, 0); some where in a windows > program nothing happens, while a PostQuitMesage certainly closes the > app. I used a modified poppad sample app from Petzold and used Spy++ to check that a WM_ENDSESSION caused the app to exit eventhough that application's main loop did not contain any special handling for WM_ENDSESSION. So, since the decision to exit on WM_ENDSESSION is not made in the application's main loop I placed it in the DefWindowProc. But I must have gotten some detail wrong. Unfortunately I'm away from my computer for the next week, so I can't investigate right now. -- Francois Gouget fgouget(a)codeweavers.com

March 11, 2006

Re: "IE5 or higher required". Grr.

by Stefan Dösinger

Hi, > That's exactly right (wish I'd thought to try WINEDEBUG=+file). > touch ~/.wine/drive_c/windows/system32/shdocvw.dll > fixes it (thanks to Tony for the tip). Thanks for the hint - Need for Speed Porsche Unleashed Demo needs ddraw.dll, as I found out this way ;)

March 11, 2006

Re: DDraw over WineD3D - Indexed colour visuals

by Stefan Dösinger

Hi, > Long answer, Screen displays blank, trace log shows that glReadPixels at > line 615 in wined3d\surface.c (LockRect) is failing with error > GL_INVALID_OPERATION. Further investigation reveals that this is because > glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably > because an indexed colour visual was not available, and this buffer is > connected directly to the screen). That is not supported right now. My current priority is to get all previously supported apps working in the way they where working before. Roderic has posted a patch for the current ddraw code to address this, this could be used to extend WineD3D. At the moment I have problems with LockRect / UnlockRect, described here: http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The sf.net archives broke the attachmet). This is needed for DDraw, and it's also a showstopper for many D3D7 games. So what's basically needed for DDraw over opengl: * Indexed colours * Better UnlockRect code * Handling for all Blit cases in BltOverride * A opengl accellerated BltFast override

March 11, 2006

Re: Can't run DirectX games on x86_64 biarch Linux SOLVED

by Christian Schneider

Am Mittwoch, den 08.03.2006, 00:09 +0100 schrieb Christian Schneider: > Hi all. > > About half a year ago I replaced my old desktop by an AMD64 box and my > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > LFS. And since then I'm not able to run any DirectX title anymore that > used to work before. > > This is the way I usually compile wine (GCC 3.4.4): > > ./configure --prefix=/opt/wine-CVS20060307 \ > --x-libraries=/usr/X11R6/lib && > make depend && make && su -c "make install" > > Here are some games that used to work on my old LFS, their behaviour and > the error messages. I've also attached a short log of each game to this > messages. All these logs have been recorded with the CVS version of wine > from 2006/03/05. > > Age of Empires 2 starts up, I can hear sound. When I click on "Single > Player", the game hangs with the following message: > > err:seh:setup_exception stack overflow 24 bytes in thread 0009 eip 55726262 esp 55ca0fe8 stack 0x55ca1000-0x55db0000 > > Backgammon Pro is an older (7 years or so) backgammon game, quite simple > and 2D, but uses DirectDraw. It crashes at startup: > > err:ntdll:RtlpWaitForCriticalSection section 0x5574d040 "directory.c: dir_section" wait timed out in thread 000b, blocked by 000c, retrying (60 sec) > err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 > > Diablo 2 VidTest (D2VidTest.exe) runs fine and suggests Direct3D for > rendering. When I click on the ok-button to quit, it keeps hanging: > > err:ntdll:RtlpWaitForCriticalSection section 0x6ffa0730 "?" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) > > Diablo 2 crashes at startup after some time: > > err:ntdll:RtlpWaitForCriticalSection section 0x5574d6c0 "virtual.c: csVirtual" wait timed out in thread 0010, blocked by 0000, retrying (60 sec) > err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 > > Half-Life crashes at startup: > > err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 > > Monkey Island 4 (OpenGL-mode) crashes at startup: > > err:seh:setup_exception stack overflow 240 bytes in thread 0009 eip 557013e6 esp 55ca0f10 stack 0x55ca1000-0x55db0000 > > StarCraft starts to the title menu, but clicking on "Single Player" > crashes it: > > err:seh:setup_exception stack overflow 276 bytes in thread 0009 eip 557013e6 esp 55ca0eec stack 0x55ca1000-0x55db0000 > > WarCraft 3 (OpenGL-mode) doesn't show up anything, just hangs silently. > > As you can see, the most common errors are err:seh:setup_exception and > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > with other games like Revolt, Anno 1503, Half-Life 2, and the errors all > look alike. > > I have tried the following things to solve the problem: > * Deleted my ~/.wine, over and over again ;-) > * Compiled wine without any optimization flags > * Compiled wine on a x86 Debian box and copied the installation > over > * Copied my ~/.wine to that Debian box, where most of the games > run fine > * Tried different wine versions, starting with pre-0.9 versions, > ending with the latest CVS version > * Used winetools to setup an environment with many native DLLs. > Installation of most of the software including IE worked fine, > but did not help though. > * Searched this mailing list archive and the web for similar > errors > > Something is definitely going wrong with this. Anybody an idea? I would > appreciate any help. > > Cheers, > > Christian Schneider I found out that the problem doesn't seem to be related DirectX nor x86_64 libs. My games were all installed on a FAT32 partition which is also available for my parallel installed Windows XP. But the programs that worked I had installed directely to drive C: (~/.wine/drive_c). Now after I installed any of the games to the fake windows directory, they worked again! Renaming the installation directory and setting a symlink to the same game directory on the FAT32 parition, and the game crashed again. The debug messages showed that the last called function always was ntdll.NtQueryDirectoryFile. Grepping this function name from the log file showed the last call to it: 0009:Call ntdll.NtQueryDirectoryFile(0000001c,00000000,00000000,00000000,55daeac8,55899bb0,00002000,00000003,00000000,55899b94,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1dd0,00002000,00000003,00000000,558d1db4,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=00000000 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1dd0,00002000,00000003,00000000,558d1db4,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=00000000 ret=559c6246 0009:Call ntdll.NtQueryDirectoryFile(00000070,00000000,00000000,00000000,55dade68,558d1e28,00002000,00000003,00000000,558d1e0c,00000000) ret=559c6246 0009:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c6246 000b:Call ntdll.NtQueryDirectoryFile(0000001c,00000000,00000000,00000000,55daea48,5588d4b8,00002000,00000003,00000000,5588d49c,00000000) ret=559c8246 000b:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=559c8246 0009:Call ntdll.NtQueryDirectoryFile(0000009c,00000000,00000000,00000000,55dad048,558f2a58,00002000,00000003,00000000,558f2a3c,00000000) ret=559c6246 err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 Now what to do. Should I open a bug report? Cheers, Christian Schneider

March 11, 2006

Re: "IE5 or higher required". Grr.

by Dan Kegel

On 3/11/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Ah ok. I want to apologize then. I'm trying to get reasonable bug reports > with enough information so any developer can go in and look without > downloading giga-bytes of stuff to just get something like > WINEDEBUG=warn+all. Amen. I occasionally go on bug triage sprints, to help winnow out and add detail to the poor bug reports. (Heck, I even have a web page about it, http://kegel.com/wine/qa/ ) > In this particular case, I won't be surprised if all that software does > is checks for one particular file somewhere in system32 directory. That's exactly right (wish I'd thought to try WINEDEBUG=+file). touch ~/.wine/drive_c/windows/system32/shdocvw.dll fixes it (thanks to Tony for the tip). Now I just have to set up an Oracle database to test against! - Dan It's > long know outstanding problem. I think if we search bugzilla we will come > up with at least dozen of files that programs check for in this way. > > Again, sorry for the extra noise. > > Vitaliy. > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

Re: "IE5 or higher required". Grr.

by James Liggett

I must really say I agree with you here, Jeremy. I think what Dan is doing for wine is excellent, and I for one appreciate him keeping us abreast of his efforts and the problems he encounters. The apps he's working with are really important for a lot of people, and as such they probably need our attention so we can make Wine a more viable alternative. I don't think Dan is spamming wine-devel at all; in fact I'd like to see him keep letting us know about all of these things. Just my two cents... James On Sat, 2006-03-11 at 09:27 -0600, Jeremy White wrote: > > BTW is there are some particular reason that you have to cc every > > single bug that you file to wine-devel mailing as well? I'm sorry, but > > quality of those bugs are not that good really to go directly to > > wine-devel list. With this particular bug you could at least try to find > > what is that program looks at to decide if you do have IE installed or > > not. > > I certainly don't want wine-devel to turn into wine-users, > but I think you are wrong to lump Dan's emails into that category. > > Dan is a very capable developer; he may not be the most > accomplished Wine hacker, but he is not without his chops. > Note that many of the @ucla.edu patches that come to wine-devel > are from his students. > > Further, I think that Dan is triaging issues that are > of fairly critical interest to Wine. > > For example, IE dependence is a very hard problem for Wine; > a lot of programs have that as an issue. I, for one, am > grateful to Dan for running with the Windows version > of Firefox, as it helps us be better ready to understand > how to use Firefox to solve that problem. > > Further, I happen to know that the Munich considered > using Wine for their desktop migration, and they felt that > Wine was 'awful'; so it is very interesting to me, personally, > to explore why that might be. > > Cheers, > > Jeremy > >

March 11, 2006