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

compile error
by Stefan Leichter April 21, 2006

April 21, 2006

Hi, i am getting a compile error on current cvs. Does anyone else seeing this problem e.g. on git ? My system is SuSE Linux 9.0 Bye Stefan bison -d -t ../../../wine/tools/widl/parser.y -o parser.tab.c ../../../wine/tools/widl/parser.y:283.11: parse error, unexpected ":", expecting ";" or "|" ../../../wine/tools/widl/parser.y:283.35-38: $$ von »importlib« hat keinen deklarierten Typ ../../../wine/tools/widl/parser.y:283.35-43: $2 von »importlib« hat keinen deklarierten Typ make[2]: *** [parser.tab.c] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/tools/widl' make[1]: *** [widl] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/tools' make: *** [tools] Fehler 2 sle(a)sle3:/usr/src/wine/wine-build> bison --version bison (GNU Bison) 1.75 Geschrieben von Robert Corbett und Richard Stallman. Copyright © 2002 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt keine Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.

2 2

SOC: More Ideas
by Detlef Riekenberg April 21, 2006

April 21, 2006

Hi Some more Ideas for SOC: Printer-Dialogs: PrintDlgEx* is the Default Printing-Dialog since w2k, but we have only a stub. Some Apps fail to Print for that reason. A usable Implementation need to Support the Properties from the Application (Example from IE: Print actual Frame / Print Links only) and the Properties from the Printer-Driver (provided by wineps.drv from the PPD-File). Fun-Project: Support Native Printer Drivers The CUPS-Backend "ddiwrapper" (GPL) uses Ghostscript to render BMP-Images on Linux, forward them to an modified wine (winspool.drv and gdi32.dll are replaced) that used a native driver (reported to work with some Cannon-Printers) to print that BMP-Image to the Printer (/dev/lp0 or /dev/usb/lp0). A usable Implementation will enhance winspool.dev and gdi32.dll in such a way, that "ddiwrapper" will work "out of the box" Fun-Project: Support Native Scanner Drivers A usable Implementation will work with a modified twain_32.dll (and kernel32.dll / ntdll.dll), but without a Kernel-Module (Example: via libusb). -- By By ... ... Detlef

2 1

Getting wrc to support long long
by Bill Medland April 20, 2006

April 20, 2006

I just tried wrc for the first time and fell over this. Internal error (please report) ./ppl.l 824: long long constants not implemented yet Is anyone intending doing anything about it in the near future? Is it a reasonably simple thing to implement? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

DIB section problem
by Stefan Dösinger April 20, 2006

April 20, 2006

Hello, While working on an implementation for IWineD3DSurface::GetDC and IWineD3DSurface::ReleaseDC, I think I stubled accross a bug in the DIB code. It appears to me that the memory of the DIB section isn't unprotected correctly when the dib section is destroyed. I have pasted my code here: http://wine.pastebin.com/671601 What I do is basically: ->Lock the surface ->Create a DIB section for the locked surface memory(Allocated with VirtualAlloc) ->Get a DC for the dib section ->Setup the dc and return it to the app In ReleaseDC, I do it the reverse way: ->Release the DC ->Delete the DIB section ->Unlock the surface But all accesses to the surface's memory fail after deleting the dib section. Therefore I unlock the surface before destroying the dib, and upload the texture to opengl, to be able to free the memory. For testing, I've inserted VirtualProtect(This->resource.allocatedMemory, This->resource.size, PAGE_READWRITE,&oldProtect); after the DeleteObject, and then I can access the surface normally again. But the image that the app wrote with GDI commands isn't there, it looks like the image is left in the X server and dropped. Can someone with more knowledge of the DIB code have a quick look at this? Thanks, Stefan

2 1

RE: Using msvcmon to debug
by Ryan Miller April 20, 2006

April 20, 2006

I'm using Redhat ES 4. The wine version is: Wine 20050830. Does this message typically get followed by an exception? Ryan -----Original Message----- From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] Sent: Thursday, April 20, 2006 1:06 AM To: Ryan Miller Cc: wine-devel(a)winehq.org Subject: Re: Using msvcmon to debug >>>>> "Ryan" == Ryan Miller <rmiller(a)auctionpay.com> writes: Ryan> Hi, I've been using msvcmon previously to remote debug application Ryan> in Visual Studio on Wine. It's great to have an IDE to debug Wine Ryan> with the breakpoints and watch windows and all. I'm now using Ryan> Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. Ryan> I'm getting the log message (which is new): Ryan> epoll_ctl: Operation not permitted What distribution are you using? What wine version is involved? The "epoll_ctl: Operation not permitted" problem appeared now and then, but mostly only Suse Distribution was involved. If I remember right, the dll/kernel/test directory provoked such an error for me, but does not now, with a nearly up-to-date CVS wine on Suse 10.0 Ryan> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 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 ----------

3 2

Re: search for /dev/input/js as well as /dev/js
by Mike McCormack April 20, 2006

April 20, 2006

Mike Frysinger wrote: > with udev now, joystick nodes are created as /dev/input/js# and /dev/js# no > longer exists ... attached patch will search for /dev/input/js# first and if > that doesnt exist, fall back to /dev/js# You could easily maintain compatibility with Wine and any other application using joysticks simply by adding some symlinks in /dev. That's what my system has, and it's using udev. Mike

7 12

File dialog regression?
by Mike Hearn April 20, 2006

April 20, 2006

Has anybody else got a problem with no icons appearing in the file dialogs? I just see the generic "blank document" icon - it's as if the shell icons aren't being loaded anymore. My Sherlock-Holmes-esque 6th sense leads me to think that either my setup is borked or the fake stub DLL patch is to blame. thanks -mike

2 1

Re: [usp10] Fix return-codes of ScriptGetFontProperties (resend)
by Joris Huizer April 20, 2006

April 20, 2006

Paul Vriens wrote: > + /* Now a NULL hdc again */ > + hr = ScriptGetFontProperties(NULL,&psc,&sfp); > + /* Save the psc pointer */ > + old_psc = psc; > + ok( hr == S_OK, "(NULL,&psc,&sfp), expected S_OK, got %08x\n", (unsigned int)hr); > + ok( psc == old_psc, "Expected psc not to be changed, was %p is now %p\n", old_psc, psc); > + ScriptFreeCache(&psc); > + ok( psc == NULL, "Expected psc to be NULL, got %p\n", psc); actually You didn't test anything about psc here, after setting old_psc nothing happens with psc -- save the pointer before calling ScriptGetFontProperties(NULL,&psc,&sfp); HTH, Joris

1 0

Using msvcmon to debug
by Ryan Miller April 20, 2006

April 20, 2006

Hi, I've been using msvcmon previously to remote debug application in Visual Studio on Wine. It's great to have an IDE to debug Wine with the breakpoints and watch windows and all. I'm now using Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. I'm getting the log message (which is new): epoll_ctl: Operation not permitted Followed by an exception dialog and an abort. I compared the exception address to my app's map file and I'm thinking it's a Wine address/exception. Does anyone else use msvcmon to debug? Any clues where I should start looking? Thanks. Ryan

3 2

x11drv: question about byte-swapping for DIBs
by Eric Frias April 20, 2006

April 20, 2006

I'm trying to debug a problem in which 24-bit .bmps don't display correctly from a winelib application on a big-endian sparc host when displaying on a little-endian intel PC. In this case, the image is garbled, with most of the colors being wrong and a pattern of vertical stripes over the image. The code passes through convert_888_to_0888_reverse_dst_byteswap which is what mangles the image data. I looked through the other conversion functions, and it seems the corresponding 'src' function (convert_888_to_0888_reverse_src_byteswap) actually does the correct transformation. I don't have a very good grasp of why the conversions are chosen, but it seemed like a likely fix would be to edit dib.c and make the lines in the SetImageBits functions that select the conversion structure look like: #ifdef WORDS_BIGENDIAN const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_src_byteswap; #else const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_dst_byteswap; #endif Doing this fixed my problem and didn't seem to cause any others, but I'm wondering whether this fix is correct or if I just got lucky. Can someone who knows this code tell me if this makes logical sense? (If it's correct, there probably needs to be a related patch in the GetImageBits functions, just going in the other direction). Eric

3 4

usp10: Remove the need to pass chars to ScriptPlace
by Jeff L April 20, 2006

April 20, 2006

This patch uses GetCharABCWidthsI to remove the need to pass chars from ScriptShape to ScriptPlace in the scriptcache work space. Change log: Remove the need to pass chars from ScriptShape to ScriptPlace Jeff Latimer

1 0

Re: Race in rpc__cn_network_receiver()?
by Luke Kenneth Casson Leighton April 20, 2006

April 20, 2006

On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote: luke, you are a star: thank you for helping out with this. just for people's information (in case it's not been mentioned here - i must admit i forgot to notify opendce(a)opengroup.org!) about 6-8 months ago i did a coding-spree on freedce, with a view to achieving two, maybe three, major things: 1) porting to win32 (if you use pthreads-win32) 2) using posix final draft (7?) threads not posix draft 4. 3) proving to the people on wine and reactos that they have a hell of a lot of work to do (measured in man-decades) by not using the open group's DCE/RPC reference implementation. here's the gotchas that i encountered, and had to give up: - udp worked, but tcp did not - reactos had some problems at the time with the code behind ipconfig.exe (NetTransportEnum i think it was) - pthreads-win32 was too strictly posix compliant (!) and there is a cancellation exception or something which makes it fail in the dcethreads exception library tests, where linux does not fail (!) maybe this is related to what lukeh is talking about. *shrug*. anyway, the upshot is that freedce/latest-cvs also doesn't work on TCP, and thank you so much people for helping track down why. it's only been ten years so far: hopefully some time within the next decade, freedce will be used for some real MSRPC-related free software projects. l > >In rpc__cn_network_receiver(), rpc__socket_close() is called without an > >exception handler in place. According to IEEE Std 1003.1 (2004), close() > >is a cancellation point, see: > > > >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html > > > >Given this, a receiver thread could receive a cancel whilst closing the > >socket, which will cause to entire program to abort. (We have seen this > >occur when the RPC server is under load.) > > > >A suggested fix is to move the call to rpc__socket_close() inside the > >TRY/CATCH_ALL block that removes any pending cancels. > > It seems like the real fix is to disable cancellation within > rpc__socket_close(), because in other places the OSF code appears to > assume that this is not a cancellation point. > > Ditto for open(), socket(), etc (but not I/O routines that may block). > > I should note that the Linux dcethreads library does actually disable > cancellation for these calls, however in our own DCE thread library > we opted not to override any system calls to avoid changing semantics > when used by non-DCE code. > > -- Luke > > -- > -- -- lkcl.net - mad free software computer person, visionary and poet. --

1 0

Wine or WINE?
by Ivan Leo Puoti April 20, 2006

April 20, 2006

I was reading WWN yesterday and read something about Microsoft using the incorrect "WINE" form, I email them about it and they appear willing to fix it. Probably the first example of cooperation from them :-) Ivan.

1 0

SoC Mentor Signup!
by Dan Kegel April 20, 2006

April 20, 2006

Jeremy White asked earlier for people to volunteer for the review committee. I think anybody who wants to be a SoC mentor should also volunteer for the review committee. And we need a list of mentors soon, so please, if you are interested in helping, email Jeremy as soon as you can. The great thing about being a Wine mentor is the leverage... you get to help Wine without doing all the heavy lifting yourself. And, if you're lucky, the student you mentor will keep on helping the Wine project even after you're done, so it's a gift that keeps on giving... Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Menus [3/6]: Draw the column separator properly
by Dimi Paun April 19, 2006

April 19, 2006

On Wed, 2006-04-19 at 21:39 +0200, Michael Kaufmann wrote: > --- menu.c 2006-04-19 21:07:47.000000000 +0200 > +++ menu-new.c 2006-04-19 21:07:44.000000000 +0200 Only top-level patches, please: http://winehq.org/site/sending_patches -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

[SOC] proposal -> valgrind
by Eric Pouech April 19, 2006

April 19, 2006

Another potential proposal for SOC would be upgrading valgrind to work with Wine. I've tweaked it a bit (some patches still floating around), but: - that's not complete (some items still don't work) - what's also completly missing is the support of native modules (especially when generating backtraces) - 16bit support (but we can safely leave it out for now) - and testing (and fixing) most of the implementations we have I've updated the Wiki page accordingly. A+ -- Eric Pouech

2 1

Re: widl: Added importlib parsing code.
by Robert Shearman April 19, 2006

April 19, 2006

Jacek Caban wrote: >+importlib: tIMPORTLIB '(' aSTRING ')' {} >+ > > You should warn here that you're not doing anything with the importlib, as typelibs with an importlib statement probably aren't going to work. -- Rob Shearman

1 0

Winelib: SIGTERM or SIGQUIT?
by Michael Ost April 19, 2006

April 19, 2006

I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally. >From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort. It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits. So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical? Or maybe my reading of the "canon of signals" is incorrect? Thanks for any help... mo PS: recently someone was asking a question about winelib and was directed to wine-user. What's the protocol here? Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. I'd appreciate any help with the protocol of all this... =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

3 7

Re: enhmetafile: Create little-endian EMF files on big-endian machines (fixed)
by Phil Krylov April 19, 2006

April 19, 2006

Hi, On Tue, 11 Apr 2006 20:03:22 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > This patch fixes the generation of EMF files (which are little-endian by nature) > on big-endian machines. It is by no means complete - some record types are still > unsupported, and reading of little-endian EMFs on big-endian machines still does > not work - but it works for my app and can be used as a base for future > improvements. Anything wrong with this patch? Should I try to improve it in the direction of supporting more metafile record types and supporting reading little-endian EMFs from disk? Or change everything at all? The subject was recently discussed in this thread: http://www.winehq.org/pipermail/wine-devel/2006-April/046606.html -- Ph.

2 2

Re: gdi: [3 of 3] Add headers for GetCharABCWidthI
by Alexandre Julliard April 19, 2006

April 19, 2006

Jeff L <lats(a)yless4u.com.au> writes: > This add GetCharABCWidthsI and tests. > There is no A or W suffix for this function as it works from a glyph > rather than a char. > > Change log: > Add GetCharABCWidthsI and tests. The tests fail here, probably because they rely on the Arial font: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:366: Test failed: GetCharABCWidthsI should have returned TRUE 3 font.c:372: Test failed: GetCharABCWidthsI should have returned TRUE 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Forming a SOC review committee
by Dan Kegel April 19, 2006

April 19, 2006

Dimi wrote: >One thing that I would like to see is to establish a more >formal post-mortem for every project accepted. ... Sounds good to me. It can even be a condition of completion (and thus of payment). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

SOC: Integrate DIB Engine
by Jesse Allen April 19, 2006

April 19, 2006

One thing I'd like to try to work on is the DIB engine. Do we need someone to work on it still? This one is also interesting to me because we have some documentation already and that I have worked with bitmaps before too. I'd also like to find out how this stuff might integrate with the current changes going into ddraw. http://www.winehq.org/?page=fun_projects GDI Engine Integrate the GDI engine contributed by the TransGaming folks. * workers: wanted * status: to do * updated: June 24, 2005 Jesse

5 5

SOC Idea: Easy usage of native DLLs in Linux programs
by Mike Hearn April 19, 2006

April 19, 2006

Various projects have re-implemented the code necessary to host Win32 DLLs in-process, for instance Xine, MPlayer and GStreamer all have (different) forked, badly hacked copies of the Wine codebase inside themselves to load and use codec DLLs. The GIMP now has the ability to use Photoshop plugins using Wine. And so on. It'd be nice if there was a simple API programs could use to do this, for instance, wine_dlopen("whatever.dll"), wine_adopt_thread() and so on to make re-use of Win32 components and COM objects easy. This has been discussed before and Alexandre wasn't sure it was worth it as it'd be a significant extension to the (stable??) Wine APIs, so IMHO this one shouldn't be judged on whether it gets checked in or not but rather whether it works and how easy it is to use. Thoughts? I know roughly what needs to be done so I could mentor this one, but students be warned - it requires _excellent_ understanding of operating system design and things like threading. There's a reason such a thing doesn't already exist, and it's because it's hard. On the flip side it's not a massive amount of code IMHO so the work would mostly involve learning, debugging, etc rather than simply being a hard typing slog. Also, a student has all summer and the nice thing is, it's mostly generic computing knowledge that'd be useful for future work (whereas learning a specific api in depth probably isn't ...). Such a thing has many uses: * Hosting ActiveX controls inside a native Firefox * Allowing more apps to use plugins from popular Windows apps. GIMP is a bit weird in that its plugin system is out of process and has a simple wire protocol .... a hangover from the days before ELF (!!), but most programs aren't like that. EG imagine being able to use WinAmp visualizion plugins in your music player of choice. * Maybe getting the xine/mplayer/gst mess sorted out a bit (on the other hand they need to run only a small, relatively unchanging amount of code so it may not be worth it) * Allowing piece-by-piece porting of a modular Windows app without Winelib (which is annoying as you have to switch toolchains all at once, you may not even have the sources to some DLLs etc ...) * Actually there is a huge component marketplace in Windows which is especially rich in the boring sort of business components (grid views etc) that open source hackers tend to ignore ... this could allow developers to embed some of the very sophisticated Win32 business objects into native Linux apps, so reducing development costs (of course the result would not be free software, but for in house custom apps that's not really a concern anyway) I'm sure you can think of some more. Discuss! :) thanks -mike

3 4

Re: WineD3D: Allocate the resources with VirtualAlloc
by Alexandre Julliard April 19, 2006

April 19, 2006

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This patch allocates the memory of Surfaces, Indexbuffers and Vertexbuffers > with VirtualAlloc instead of HeapAlloc. This will be needed for GetDC to > work. It is done for Index- and Vertexbuffers too because they are also > managed by the WineD3D resource manager. I'm not sure I agree with that. Are you planning to trap accesses like the DIB code does? That sucks pretty badly in the DIB code, I don't think we want to do any more of that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi: [2 of 3] Add header for GetCharABCWidthI
by Mike McCormack April 19, 2006

April 19, 2006

Jeff L wrote: > I have repackaged this as package. Please don't split patches that depend on each other to make Wine compile and work correctly, or add dead code. The point of having small patches is to make Wine easier to regression test, so we want things to work between every commit. > +// FIXME("%p, %d, %d, %p\n", font, firstChar, count, buffer); Either remove the FIXME completely, or make it a TRACE. Also, C++ comments are not portable in C, so use standard C comments. > + } > + else > + for(c = 0; c < count; c++) { How about using indenting consistent with the rest of the code in the file? thanks, Mike

3 2