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

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