December 2005 - Wine-devel - list.winehq.org

Re: Implement Old Names Option
by Dimi Paun 05 Dec '05

05 Dec '05

From: "Robert Shearman" <rob(a)codeweavers.com> > Implement '-o' option. This is equivalent to MIDLs '/oldnames' option. Not a good choice, '-o' is used for output typically. How about --oldnames? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

git patch to gmail draft script
by James Hawkins 05 Dec '05

05 Dec '05

Hey all, I've hacked up a little script that takes your committed git changes and puts a draft in your gmail draft folder for each committ that contains a changelog and the attached diff. To use the script, make sure you have python installed. You'll also need to change the variables at the top of the script to match your specifics. The script is pretty simple, so if you don't like the format of the email it wouldn't be hard to change. The process goes like so: 1) make your committs, but when you're writing the changelog entry for the committ, make sure to put all the changes you would have in the Changelog section of the email ie for one of my recent patches, the committ message was, * Use DelNode itself for the directory recursion. * Handle the dwFlags parameter. * Factor out file creation and deletion. * Add test cases for DelNode and make them pass. you can use asterisks if you like or not, it won't affect the script. 2) ./makedraft.py 3) the script calls git-format-patch for you and loops through all the committs 4) the script asks you for a subject (of the email) for each committ 5) if you don't want to send a patch to wine-patches, enter 'stop' as the subject (minus the quotes) 6) the diffs will be in diff_dir and the drafts will be in your gmail drafts folder 7) append anything you need to the email and press send If you have any comments or suggestions, I'd like to hear them (I think the script is rather ugly myself, but it gets the job done :)) -- James Hawkins

1 1

Re: winspool: Add Documentation for the Port-Functions (without line-wrap)
by Vitaliy Margolen 05 Dec '05

05 Dec '05

Monday, December 5, 2005, 7:03:46 AM, Detlef Riekenberg wrote: > Second try with git. This Time without line-wrap > Changelog: > - Add Documentation for the Port-Functions > Content-Disposition: attachment; filename=document_port_functions.diff > Content-Type: text/x-patch; name=document_port_functions.diff; charset=UTF-8 > Content-Transfer-Encoding: 7bit Could you drop "; charset=UTF-8" part? It's not UTF-8 at all (since it's 7-bit and text/x-path). Vitaliy

1 0

Re: winspool: Add Documentation for the Port-Functions
by James Hawkins 05 Dec '05

05 Dec '05

On 12/5/05, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > /****************************************************************** > * DeletePortA [WINSPOOL.@] > * > + * Delete a specific Port (ANSI) > + * > + * See DeletePortW. > + * ... > /****************************************************************** > * DeletePortW [WINSPOOL.@] > * > + * Delete a specific Port (UNICODE) > + * The (ANSI) and (UNICODE) are superfluous. For the ansi version, all you need is the 'See DeletePortW' instead of reusing 'Delete a specific port' as well. -- James Hawkins

1 0

Re: ddraw: make some driver info not const
by Vitaliy Margolen 05 Dec '05

05 Dec '05

Friday, December 2, 2005, 11:46:39 AM, Rein Klazes wrote: > Hi, [skip] > Making this information not const makes the application proceed further. > Changelog: > dlls/ddraw : ddraw_hal.c, ddraw_user.c > Make some driver info not const, some applications want to modify it. This is wrong. No user program should modify our internal data. I think you need to copy this data into heap before passing it to the app. You should make simple test to check if the data returned on windows is within heap or not. Vitaliy

4 4

dsound buffer underrun
by Tomas Carnecky 05 Dec '05

05 Dec '05

I'm still having problems with the sound, something in the dsound mixer is wrong. I've created a trace (+dsound): first comes this, that shows that sdound detected a possible underrun and sets probably_valid_to to -1. trace:dsound:DSOUND_MixOne (0x55952b88,54684,54684,49392) trace:dsound:DSOUND_MixOne buf_writepos=8192, primary_writepos=54684 trace:dsound:DSOUND_MixOne buf_done=0, primary_done=0 trace:dsound:DSOUND_MixOne buf_mixpos=8192, primary_mixpos=54684, mixlen=49392 trace:dsound:DSOUND_MixOne looping=1, startpos=0, leadin=0 trace:dsound:DSOUND_MixOne streaming buffer probably_valid_to=8192, probably_valid_left=0 warn:dsound:DSOUND_MixOne probably_valid_to now within writelead, possible streaming underrun trace:dsound:DSOUND_MixOne remaining mixlen=49392 next time wine enters DSOUND_MixOne() this occurs: trace:dsound:DSOUND_MixOne (0x55952b88,54684,63504,49392) trace:dsound:DSOUND_MixOne buf_writepos=17012, primary_writepos=63504 trace:dsound:DSOUND_MixOne buf_done=7804, primary_done=40572 trace:dsound:DSOUND_MixOne buf_mixpos=24816, primary_mixpos=19404, mixlen=49392 trace:dsound:DSOUND_MixOne looping=1, startpos=0, leadin=0 trace:dsound:DSOUND_MixOne streaming buffer probably_valid_to=-1, probably_valid_left=32768 trace:dsound:DSOUND_MixOne clipping to probably_valid_left=32768 fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 < primary_done=40572) now wine clips mixlen to probably_valid_left which is smaller than primary_done. I don't know what primary_done, mixlen, probably_valid_left and probably_valid_to mean, but somthing with those variables is wrong. the full log is in the attachment tom

1 0

Re: Allow out-of-tree builds against configured source tree
by Alexandre Julliard 05 Dec '05

05 Dec '05

Pavel Roskin <proski(a)gnu.org> writes: > * Make.rules.in: Change include path to prefer include files in > the output tree over those in the source tree. This allows > compiling Wine outside the source tree even if Wine was already > compiled in the source tree, possibly with different options. You really don't want to do that, that's a recipe for trouble. Make will check the source dir for dependencies so if you have objects in there it won't rebuild things properly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [MSI] DllCanUnloadNow try2
by Dmitry Timoshkov 05 Dec '05

05 Dec '05

"Christian Gmeiner" <christian.gmeiner(a)students.fh-vorarlberg.ac.at> wrote: > +/********************************************************************** > + * Dll lifetime tracking declaration > + */ > +void LockModule(void) > +{ > + InterlockedIncrement(&dll_count); > +} > + > +void UnlockModule(void) > +{ > + InterlockedDecrement(&dll_count); > +} Since these 2 are used from inside single source file they can (and should) be made static. -- Dmitry.

2 1

Missing includes in dlls/wininet/netconnection.c
by Pavel Roskin 05 Dec '05

05 Dec '05

Hello, Robert! I'm sorry, but you keep breaking Wine for me. The latest change in dlls/wininet/netconnection.c (revision 1.18) doesn't compile. Two files need to be included - errno.h for error names and stdio.h for perror(). Actually, I think perror() should be avoided - Wine has its own error reporting mechanisms. But to be fair, there are instances of perror() in the current Wine code. -- Regards, Pavel Roskin

1 0

A better workaround for compiling on FC4/x86_64
by Pavel Roskin 05 Dec '05

05 Dec '05

Hello! When trying to set up printing from Wine on Fedora Core 4 for x86_64, I have discovered that Wine fails to find many libraries, including libcups. It turns out that the development packages on Fedora Core 4 don't always provide *.so symlinks for 32-bit libraries. So I wrote this script. The script creates all missing links in one directory (/usr/local/lib is the default). Not only was libcups found next time, but also the old workaround with imake has become unneeded. The configure script runs out-of-box and finds X11 libraries. I'm posting the script here in hope that it will be useful for some Wine users. I'm not sure it it merits inclusion in Wine, but I would not object. -- Regards, Pavel Roskin

2 2