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 19, 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 19, 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 19, 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 19, 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 19, 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 19, 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 19, 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 18, 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 18, 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 18, 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 18, 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