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

[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