September 2006 - Wine-Devel

Re: Alexandre Julliard : explorer: Work around the latest HAL binary compatibility breakage.
by Marcus Meissner Sept. 26, 2006

Sept. 26, 2006

On Tue, Sep 26, 2006 at 03:04:47PM -0500, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 9ae4e8d98efc952918bcdae86b2f640c4b062a3b > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9ae4e8d98efc952918bcdae… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Sep 26 20:29:15 2006 +0200 > > explorer: Work around the latest HAL binary compatibility breakage. > - if (!(dbus_handle = wine_dlopen(SONAME_LIBDBUS_1, RTLD_NOW, error, sizeof(error)))) goto failed; > - if (!(hal_handle = wine_dlopen(SONAME_LIBHAL, RTLD_NOW, error, sizeof(error)))) goto failed; > + /* Load libhal with RTLD_GLOBAL so that the dbus symbols are available. > + * We can't load libdbus directly since libhal may have been built against a > + * different version but with the same soname. Binary compatibility is for wimps. */ Yet another Redhat stumbling block ;) But they warn in pretty large letters: cat /usr/lib/pkgconfig/hal.pc ... Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal ... #ifndef DBUS_API_SUBJECT_TO_CHANGE #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-BUS hasn't reached 1 .0 and is subject to protocol and API churn. See the README for a full explanation." #endif ciao, Marcus

1 0

Using gdb
by Craig Keogh Sept. 26, 2006

Sept. 26, 2006

Hi, I am trying to use gdb for debugging. I run the command: winedbg --gdb sol.exe I then get the following output: WineDbg starting on pid 0xa fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for wine-pthread fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ntdll<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for msvcrt<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for advapi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for gdi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for user32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for cards<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shell32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shlwapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ole32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for rpcrt4<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for iphlpapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for comctl32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for winex11<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for imm32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for uxtheme<elf> 0x7eecaf5a start_process+0xde in kernel32: movl %edi,0x0(%esp) I don't end up with a gdb prompt. It is just stuck there. I am following: http://www.winehq.com/site/docs/winedev-guide/dbg-others I compiled wine (from GIT) using gcc v4.0.3, I am using gdb v6.4-debian. Running without gdb ('winedbg sol.exe') works fine. Thanks in advance,

2 2

Problem with NtReadVirtualMemory and wine server connection
by Peter Oberndorfer Sept. 26, 2006

Sept. 26, 2006

Hi, throught a problem in winedbg i found out that NtReadVirtualMemory has a problem, when reading into a invalid local buffer. it uses wine_server_set_reply( req, buffer, size ); to read the data supplied by the server directly into application memory of unknown state. when the read call hits bad(non present/readonly ) memory it returns EFAULT and the client dies with "wine client error:<process id>: read: Bad address" i see 3 ways to deal with this problem 1. allocate a temporary buffer in NtReadVirtualMemory, read server answer to this buffer, and then inside a try / catch block copy to application memory 2. change server protocol so it is not as sensitive when read returns EFAULT (i do not really like this idea) 3. just fix the bug in winedbg and wait until a real world app needs this behavior. (of course i will send a patch for windbg even if one of the other ways is choosen) Any ideas? Greetings Peter PS: attached a testcase for NtReadVirtualMemory(testcase itself not tested on windows, but tests were) the test should probably also live in its own file, but i didn't want to create a almost empty file

1 0

Re: msi [1/5]: Implement MsiDatabaseImport
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static const WCHAR insert_fmts[][100] = > +{ > + {'I','N','S','E','R','T',' ','I','N','T','O',' ','`','%','s','`',' ','(',' ',0}, > + {'`','%','s','`',',',' ',0}, > + {' ',')',' ','V','A','L','U','E','S',' ','(',' ',0}, > + {'\'','%','s','\'',',',' ',0}, > + {'%','s',',',' ',0}, > + {' ',')',0}, > +}; It would be cleaner to use separate variables for the separate strings, there's no reason this needs to be an array. It would avoid wasting a lot of space, and make it more explicit what the strings mean, unlike something like insert_fmts[3]. Also since all you do is copy strings, it may be even cleaner to avoid sprintf and simply strcat the strings and the separators. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: D3D9: Add a pitch test for a 1x1 texture
by H. Verbeet Sept. 26, 2006

Sept. 26, 2006

On 26/09/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > To verify that the 32 bit alignment is true for 1x1 textures too. > >+ /* test is deactivated until out np2 support doesn't report the full power of 2 pitch to the app */ >+ todo_wine ok(lockedRect.Pitch == 4, "Got pitch %d, expected 4\n", lockedRect.Pitch); Shouldn't the test be about alignment, rather than the exact size? I that case the power-of-two stuff shouldn't matter either, as long as it's properly aligned. I do have an initial patch for native NPOT support, but it will (of course) only work on cards that support the relevant extension.

2 3

Re: [D3D9] Update state test framework
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Changelog: > ========== > 1) Abandon central memory allocation, and the tracking that involves. > Write a setup() and teardown() handler for each test, and use heap > allocation. > > 2) Make the main test function configure test arguments. > Replace get/set arguments with a single test_arg. > > 3) Remove some const qualifiers on test data. > Const qualifiers should go on function parameters instead. When you find yourself writing a Changelog like this, it's a clear sign that it should be 3 separate patches. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: user: test and fix SwitchToThisWindow [3rd try]
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > diff --git a/dlls/user/winpos.c b/dlls/user/winpos.c > index 6bc9056..e78f484 100644 > --- a/dlls/user/winpos.c > +++ b/dlls/user/winpos.c > @@ -152,7 +152,20 @@ UINT WINAPI ArrangeIconicWindows( HWND p > */ > void WINAPI SwitchToThisWindow( HWND hwnd, BOOL restore ) > { > - ShowWindow( hwnd, restore ? SW_RESTORE : SW_SHOWMINIMIZED ); > + HWND hwndOld = GetForegroundWindow(); > + SetActiveWindow( hwnd ); > + SetForegroundWindow( hwnd ); > + if ( restore ) > + { > + if ( IsIconic( hwnd ) ) > + ShowWindow( hwnd, SW_RESTORE ); > + } > + else > + { > + if ( !( GetWindowLongW( hwndOld, GWL_EXSTYLE ) & WS_EX_TOPMOST ) ) > + SetWindowPos( hwndOld, HWND_BOTTOM, 0, 0, 0, 0, > + SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE ); > + } That HWND_BOTTOM thing looks very wrong, SwitchToThisWindow is supposed to move things to the front. Most likely your test case is flawed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Tips for vim users
by n0dalus Sept. 26, 2006

Sept. 26, 2006

Hi, Recently I learned a way to have vim automatically change settings when I'm editing wine source code: At the bottom of my ~/.vimrc (create it if it doesn't exist): if !exists("loaded_vimrc_autocmd") let loaded_vimrc_autocmd=1 autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8 softtabstop=4 endif In my case my wine tree is in /data/wine, so replace this with the first part of the path to your wine tree. Using the same syntax you can also put custom settings for other projects you might work on. This is helpful for me since I usually like to indent using tabs and a 4 space tab width, but now I can edit most of wine's code without having to worry about fixing my indents all the time. If anyone is interested, I've also got another Vim tip on the wiki (from last year), to automate the creation of wide character arrays: http://wiki.winehq.org/Character_arrays_in_Vim If any other vim users have tips that help out with wine coding, I'd love to hear them! Maybe we can make a page on the wiki for them. n0dalus.

2 4

Re: Governance revisited (Wineconf report)
by Ge van Geldorp Sept. 26, 2006

Sept. 26, 2006

> From: Kai Blin > > Now, getting back to the patch submission process, you're talking about a > patch management system. How would that look like, in your opinion. We were > discussing a couple of ideas, but in the end figured that most of those would > slow down the submission speed of patches that are accepted. > > Our idea was to have patches be recieved by the subsytem maintainers, and > Alexandre would only apply patches he got from those guys. We voted that one > down. > > Now I would be interested in your idea for such a system. I figure that > writing an emacs frontend won't be too troublesome if it's reasonably > designed, so let's ignore that for now. A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: "However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered." The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in "Waiting for developer" status too long (say a month) it could be automatically rejected. When "Waiting", the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in "Waiting" too long) or via a Withdraw. The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel. If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work. Gé van Geldorp.

6 6

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

James Hawkins wrote: > On 9/25/06, jimtabor <jimtabor(a)users.sourceforge.net> wrote: > >> >> Every Wine developer needs to read this, >> http://www.codeweavers.com/services/ and >> http://www.codeweavers.com/services/wine . >> > > I'm a Wine developer, and I don't work for codeweavers. Why should I > read that? > You don't need to. >> It is your job to provide support for this product, I spend money and I >> need help, where do >> I go? >> > > It is not my job to provide support for this product. Even if you're > referring to Dmitry and everyone else that works at Codeweavers, > you're still wrong. This is the wine-devel mailing list, and has > nothing to do with Codeweavers. You confuse Crossover Office and Wine > as being the same product/project. Just because they work at > Codeweavers, can they not also work on Wine and not have affiliation > with Codeweavers? Of course they can, as can anyone else who has a > real job outside of Wine. > NO! You are WRONG, sir! ~and I quote from http://www.codeweavers.com/services/ "Since 1999, CodeWeavers has been hiring the very best Wine developers. Chief among these is Alexandre Julliard <http://www.codeweavers.com/about/people/alexandre/>, the long-time maintainer of the Wine Project itself. In addition to Alexandre's prodigious talents, we have consistently hired the very best Wine resources, recruiting them literally worldwide." Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW would not have a product. They get paid for working on Wine to support CO. Don't you see that?! > First, he doesn't represent Codeweavers on the wine-devel mailing > list. Second, there's nothing unprofessional about his actions. > Missed my point! If his address has "name(a)codewreavers.com", than yes, that person does represent that organization. This project is NOT LINUX or X11, it is a paid for add on to it. I pay good money for support and I expect to get it. It is shocking to most FOSS code writers that maybe this is a real, truly, paid for project. "No! It can not be! I contribute to someones profit? NOOoooooooo~~~!". Thanks, James

3 2