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

RE: DIB engine

by Steven Edwards

I don't expect my comments will add much to this discussion because of my lack of coding ablity but this something ReactOS is going to need also. > Is the following accurate, complete, etc? Comments? Other > ideas? Any volunteers? I will help with documentation/testing on this if that is needed. > 1. Have X export the required API This wont help ReactOS out but it seems to me this is the quick/easy way to do it for you guys. > 2. Copy the relevant X code into Wine I'm kinda like this idea. If this is the road you guys chose we should be able to make use of the code also. > 3. Copy the relevant code from MicroWindows/NanoGUI to Wine Microwindows is GPL/MPL so Wine most likely cannot use its code. Greg might relicense some of the code for you though. Seeing as how DIB support is in use or needed by a lot of projects, why not take the X11 code And make a independent project? One that is licensed under X11 that can then be used By Wine, WineX, ReactOS, Microwindows and anyone else that needs it. Ok I'll shut up now Steven _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

March 31, 2002

Re: DIB engine

by Lionel Ulmer

> 1. Have X export the required API > --------------------------------- > > XFree86 4 has all the needed code, for all bit depths and layouts we > care about. We could try to have the X guys export this in the form of > an API ala Xft. Wine could then link with this library to implement the > DIB engine (or dlopen that library). Well, when I look at the bug report, I see this : '* the X bitmap has to be in the format of the X display. So if X is running in 15bpp, a 32bpp DIB is converted to 15bpp, the operation is performed in 15bpp, and the bitmap is then converted back to 32bpp. Obviously this implies that each operation occurs a loss of color resolution (fortunately they should not accumulate).' This is, AFAIK, not a problem anymore on XFree 4 (at least on the drivers based on the 'fb' driver) as they support all Pixmap depth whatever the depth of the current screen. For example, on my 16bpp display, 'xdpyinfo' gives me this : number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 So it should support almost all 'usual' formats (except the funky non 555 / 565 formats or BGR ones that are pretty rare). As far as I can remember, my Solaris box at work does also support a lot of Pixmap formats even on a 32bpp screen. There may be problems with the palette for the 'depth 8' format though. But, as far as I can remember, the other big problem comes from the 'exception handler' that is needed to detect direct write from the Windows program to the DIB (or maybe I am thinking about something completely else :-) ) to be sure that the X pixmap and the Windows DIB are always in sync one with the other. And that cannot be solved easily with X Pixmaps at all (maybe hacking around with XShmPixmaps). Anyway, enough of my ramblings for tonight :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

March 30, 2002

DIB engine

by Francois Gouget

The DIB engine was discussed quite a lot at WineConf. I am now trying to summarize these discussions to update bug 421 - Implement a DIB engine. http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421 Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers? This was discussed quite a bit at WineConf. Ideas that were floated around are: 1. Have X export the required API --------------------------------- XFree86 4 has all the needed code, for all bit depths and layouts we care about. We could try to have the X guys export this in the form of an API ala Xft. Wine could then link with this library to implement the DIB engine (or dlopen that library). * Is the needed API already available? * If not, are the XFree86 guys willing to export it? * Almost everyone is using XFree86, but what about people who don't (embedded devices, Wine on Solaris...). We need a fallback. * We won't have to maintain that code which is a good thing, although it is not supposed to change much once written. * Will we be able to do all that we need with that API? Probably yes since it can be expected to match the X API quite closely and we are abel to use the X API. 2. Copy the relevant X code into Wine ------------------------------------- Since X has all the code and that code is under the X11 license we could copy it all into Wine. * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 3. Copy the relevant code from MicroWindows/NanoGUI to Wine ----------------------------------------------------------- MicroWindows/NanoGUI also has code that could help us bootstrap our DIB engine. We probably don't want Wine to depend on these projects but we could copy their code into Wine. * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 4. Copy the relevant code from GGI to Wine ------------------------------------------ GGI also has similar code. Again we probably don't want to introduce a dependency on GGI so the same questions apply: * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

March 30, 2002

Re: make test leaves 2 wine processes running

by Sylvain Petreolle

Did you set the "Desktop" parameter at any value other than "N" ? Running it whitout a desktop window gives no problem. Noted another thing : occasionnally the program goes to debugger and is in X processes. > I'm running the same and don't see the problem, no > wine process is left > after make test. > > bye > michael Here is my backtrace: ../../programs/winetest/runtest -q -P wine -M user32.dll -T ../.. -p tests/user32_test tests/sysparams.c && touch tests/sysparams.ok wine: Unhandled exception, starting debugger... <snip> Unhandled exception: page fault on read access to 0x0000000e in 32-bit code (0x40b9e28b). In 32-bit mode. Symbol h_errno is invalid Symbol __strtol_internal is invalid 0x40b9e28b (_end+0x33fad7 in libGLcore.so.1): cmpl $0,0xc(%edi) Wine-dbg>bt Backtrace: =>0 0x40b9e28b (_end+0x33fad7 in libGLcore.so.1) (ebp=405c6e30) 1 0x4024950b (exit+0x87(status=0x0) [exit.c:55] in libc.so.6) (ebp=405c6e60) 2 0x401e8482 (main+0x6e(argc=0x2, argv=0xbffff284) [wtmain.c:213] in user32_test.so) (ebp=405c6e74) 3 0x401e702d (__wine_exe_main+0x2d [user32_test.spec.c:167] in W:\wine) (ebp=405c6e90) 4 0x400be21a (start_process+0x226 [process.c:415] in libntdll.dll.so) (ebp=405c6f38) 5 0x400c14fb (call_on_thread_stack+0x77(func=0x400bdff4) [sysdeps.c:105] in libntdll.dll.so) (ebp=405c6ff4) 6 0x400c163c (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

March 30, 2002

Re: make test leaves 2 wine processes running

by Michael Stefaniuc

On Fri, Mar 29, 2002 at 05:42:45AM +0100, Sylvain Petreolle wrote: > > Aha, this error is interesting. I'm not the only > > one getting this > > kind of error then. And I bet that your kernel is > > >2.4.5, and most > > likely >=2.4.9. > I'm running 2.4.9-31 on RH 7.2. I'm running the same and don't see the problem, no wine process is left after make test. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

March 30, 2002

CreateProcess design

by Eric Pouech

before latest Alexandre patch, CreateProcess was able to use stuff like: CreateProcess(NULL, "foo.exe --wine_opt -- --foo_opt") --wine_opt was seen by foo as options for wine, whereas foo_opt could be a command line option for foo (in foo, the command line would only be "--foo_opt") since last night, this is broken: - --wine_opt is still seen as a wine option - however, the command line passed to foo isn't cleaned up... we get the whole line "--wine_opt -- --foo_opt"... what should we do. I think Alexandre long term option is to really get rid of the options on the command line and use the WINEOPTION(S) env var (we could still have a wrapper script to do the conversion) should we adopt this right away or clean up the command line option ? as a consequence, you no longer can use any CUI program in the user/graphical mode, including winedbg - it still work as a unix console though A+

March 30, 2002

Re: problem creating/finding files

by Uwe Bonnes

>>>>> "Insyde" == Insyde <insyde(a)insyde.com.br> writes: Insyde> Hi, I'm getting this error running a system under WINE: Insyde> C:\WIN\IY032097.DAT GENERIC_READ FILE_SHARE_READ Insyde> FILE_SHARE_WRITE OPEN_EXISTING ^^^^^^^^^^^^ Insyde> 0806faa8:trace:dosfs:DOSFS_GetFullName C:\WIN\IY032097.DAT Insyde> Seems like the file isn't being created. (Uwe Bonnes helped me Insyde> with this). But we disagree what part of WINE (or outside WINE) Insyde> is wrong. The first part of the log shows a CreateFileA that is Insyde> unable to create a file. This API works fine when the file is Insyde> in the same dir as the application (had tested it). The second Yes, and wine does right to not create the file. The program explicity requests to open an _existing_ file. Understand that the CreateFile Api is also used to only open existing files. As the file is not yet created by the other process, the CreateFile Call fails here, as the API requires. Insyde> part of the log shows the last screen I get after start the Insyde> program (MessageBox API). MFRTS32 is a .dll the program Insyde> calls. We thougth of there too. But this program works under Insyde> Windows. Everything is in the path. Both wine.conf and Linux. As I told in private mail, I suspect something wrong in synchronization between the processes involved. ... Insyde> Thanks, Ricardo. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Please, no HTML in mail. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 30, 2002

Re: dynamic .fon conversion

by Francois Gouget

On Sat, 30 Mar 2002, David Chow wrote: > Hi, > > I am new to Wine develop, I wish to investigate and join, the following > is the topic I am interested in. > > Does Wine develpers planning to implement .fon files support? I mean > loading it dynamically? Since Xfree86 4 supports true type fonts, and > most of the Linux distribution are now using XFree86-4 . We can actually > load these fonts into the Xsever dynamically at run time providing we > have some dynamic conversion between the font files. This issue was raised during WineConf. Wine is now able to use FreeType to perform client-side rendering of TrueType fonts. This results in fonts that look really great, and you can even get anti-aliasing. Now, IIRC (Huw will correct me if I'm wrong), it was said that FreeType also supports Postscript fonts and .fon fonts. So the way to go would be to extend Wine's FreeType support to .fon fonts. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

March 30, 2002

dynamic .fon conversion

by David Chow

Hi, I am new to Wine develop, I wish to investigate and join, the following is the topic I am interested in. Does Wine develpers planning to implement .fon files support? I mean loading it dynamically? Since Xfree86 4 supports true type fonts, and most of the Linux distribution are now using XFree86-4 . We can actually load these fonts into the Xsever dynamically at run time providing we have some dynamic conversion between the font files. David

March 30, 2002

Re: Improving the regression testing infrastructure

by Eric Pouech

> > yup... but we want to test CreateProcess, and some test cases will > > change the stdout handle > > But do you need to write to stdout for these tests. Do you need to > write to stdout at all for that matter? that has to be defined. But how can you test the child gets the correct stdout ? either the child knows (by other ways) what stdout really is (a file...) and can test it, either it doesn't care to know, and let the parent check what the child just wrote. Again, stdout has not to be used as a generic way to pass all information back to parent, just the stdout inheritance. A+

March 30, 2002