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