September 2005 - Wine-Devel

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 17 septembre à 21:27:23 wino(a)piments.com écrit notamment: | On Mon, 12 Sep 2005 13:14:44 +0200, Jean Magnan de Bornier | <jean(a)bornier.net> wrote: > | > | > OK, I added rpcrt4.dll in c/windows/system, and now dns starts all right, | > although slowly and with strange messages, and WORKS! | > | Hmm, I found it is very slow to open on more recent wine versions : ie | after 20050524 but was getting crashes as soon as I tried to open | dragonpad. This is regression, it used to work. > | Could you post which (all) dlls you have had to run native to get this | working? Did you have to install IE6 first or not. (I cheated but it | worked) > | > I have not figured out I could save the output that is written on | > the "dragon | > editor"; if I try to save in a file dns crashes, if I try to save to | > clipboard (C-c) and then open it in e.g. emacs, I have nothing. | > Any ideas? | > Thanks, > | To copy text dictated into DragonPad I simply highlight it with the mouse. | Standard X behaviour will copy this to the clipboard without any other | clicking or hotkeys. Then I paste where I want it . [...] Hi, Had some issues with my ns7 lately, so I decided I'd try to solve them before I answer, but right now I'm rather lost: With my install as previously described, ns has been working poorly; copy to the clipboard was impossible, the only place where it worked was in wine's notepad, where things were copied ok, but I never could see them; I had to save the file and then open it with some true app (less, emacs, anything...) to see its content. I decided I could not work with such a setup... I tried several wine versions, none really working to install ns7, using sidenet; I tried using winetools, with no results to now. I read it works really well with wine 20041019 but cannot install this version, either from the gentoo ebuild or with its own installer. Here's what I get (with portage): In file included from /usr/include/alsa/asoundlib.h:48, from alsa.h:23, from audio_05.c:49: /usr/include/alsa/conf.h:189: error: erreur de syntaxe before "struct" make[2]: *** [audio_05.o] Erreur 1 make[2]: Leaving directory `/home/tmp/portage/wine-20041019-r3/work/wine-20041019/dlls/winmm/winealsa' make[1]: *** [winmm/winealsa] Erreur 2 make[1]: Leaving directory `/home/tmp/portage/wine-20041019-r3/work/wine-20041019/dlls' make: *** [dlls] Erreur 2 !!! ERROR: app-emulation/wine-20041019-r3 failed. !!! Function src_compile, Line 84, Exitcode 2 (alsa not being compiled in my kernel) thanks for any help, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 22, 2005

Re: WooHoo get a load of this :-)

by Kuba Ober

> As a side track, Win4Lin contacted me a while back, and wanted Lingnu to > represent them in Israel. I sent back a few technical questions, and > NEVER HEARD FROM THEM AGAIN! Does the company still exist? Yes, but they keep spitting into the face of their loyal userbase, so I don't wish them too well anymore :( Cheers, Kuba

Sept. 22, 2005

Re: [DOCS, POLICY] Documenting stuff that doesn't work right?

by Alexandre Julliard

Holly Bostick <motub(a)planet.nl> writes: > I was installing Icewind Dale, and like all games and Wine-installed > programs, I meant to install to the partition I have set aside for that > purpose, which is mounted to /usr/local/games, with a symlink in my home > directory. So naturally I usually set this partition to be a Wine drive, > and I prefer to use d: as the browse dialog naturally defaults to the c: > drive and it's faster to change if I only have to change to the next drive. > > When I went to the 'Drives' tab in winecfg, I had > > c: (of course) > e: (tmp) > f: (my home directory) > z: (/) There is something wrong here, if you are starting from a clean install you should only have c: and z:. Did you completely remove your .wine directory before trying? > Obviously I know how to get around this, having just done so, but is > this appropriate to document? Or is it likely to be fixed before the > updated docs go 'live'? I only ask because I can't think of a way to > write this up atm without explicitly exposing a flaw in Wine, and Wine > doesn't really deserve that-- even winecfg doesn't deserve that, being > much improved from even last month's release (which improvement is > obvious, even though I've only done this single operation). I mean, I'll > take notes on everything, but this looks like a policy question to me. Well, there's a bug here that winecfg doesn't show an existing drive, this should be fixed. And the policy at this point is to only create c: and z: by default in wineprefixcreate, the rest is done from winecfg (either manually or with the autodetect button). -- Alexandre Julliard julliard(a)winehq.org

Sept. 22, 2005

Re: ntdll: Add few tests for object manager

by Alexandre Julliard

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > All of them are to-do. Thanks to Robert Shearman for examples. ;-) > Can't really test nothing more since most of the om functions are stubs. Come on, you can test a lot more than that. Even if you only test create and open functions, if you test the various case combinations, with or without the CASE_INSENSITIVE flag, for mutexes, events, semaphores, pipes, mappings, files, etc. you should be able to easily come up with a few hundred tests. -- Alexandre Julliard julliard(a)winehq.org

Sept. 22, 2005

Re: memory leak detection patch

by Mike McCormack

Andreas Mohr wrote: > I think that we should concentrate on making valgrind the default leak > detection method in Wine, however. > > Reasons: > - it catches many, many leaks *without any reprogramming effort* > - it catches many, many other problems > - it has other tools which are very useful, too (cache profiling, ...) > - it's so much better than any other "clever hack" that people come up with > in 2 hours Valgrind is great, and I've used it before, but it's a little heavy duty for what I want at the moment. The main disadvantages are: - it slows down Wine and programs running Wine. (Office 2003 install already takes a minute or so) - it doesn't differenciate between Wine leaking memory and a program running in Wine leaking memory - it requires a patched version of Wine to run - it isn't built into Wine (ie. I could ship this patch with minimal overhead, and have my users point out memory leaks) - it has issues following forks, and being run from scripts The patch is not meant to replace valgrind, just to provide another way of finding problems in Wine code. Mike

Sept. 22, 2005

Re: Running Wine from source tree

by Andreas Mohr

Hi, On Thu, Sep 22, 2005 at 03:57:24PM +0900, Mike McCormack wrote: > > James Liggett wrote: > > >I'm doing a lot of testing, and I was wondering if I can run Wine from > >within its source tree without having to reinstall it after every build. > >If it can be done without conflicting with an existing installation of > >Wine, how do I do it? > > Yes, it can be done. In fact, I don't have Wine installed to make sure > that I don't get confused as to which version I'm testing. This *really* should be in the devel guide. (no, I didn't check whether something like this is in there already, but I'm sure that if there was something like that, then you would have mentioned a URL instead of writing that whole text ;) Holly? ;) Andreas

Sept. 22, 2005

Re: memory leak detection patch

by Andreas Mohr

Hi, On Thu, Sep 22, 2005 at 12:08:20AM +0900, Mike McCormack wrote: > > Hi, > > This patch is written for MSI, but could be adapted to other code. It > keeps a linked list of allocated memory and removes free'd memory from > the list. > > It requires that you change all the HeapAlloc's or mallocs in a dll to > msi_alloc (for example), but can detect unfree'd memory and invalid free's. > > I have discovered quite a few problems in my own code with this patch, > so hopefully somebody else will find it useful too. First, thanks for fixing so many leaks! I think that we should concentrate on making valgrind the default leak detection method in Wine, however. Reasons: - it catches many, many leaks *without any reprogramming effort* - it catches many, many other problems - it has other tools which are very useful, too (cache profiling, ...) - it's so much better than any other "clever hack" that people come up with in 2 hours Thus IMHO valgrind should work perfectly with Wine, and it should be the first thing that pops up when people want to do things like this: IOW it should be documented rather prominently which are some useful ways of using it in combination with Wine. OTOH we might want to put a safety net in place in case valgrind somehow becomes impossible to use in combination with Wine, so maybe we should investigate a second leak tracer, too. Or am I completely mistaken here? Andreas

Sept. 22, 2005

Re: Running Wine from source tree

by Uwe Bonnes

>>>>> "James" == James Liggett <jrliggett(a)cox.net> writes: James> Hi, I'm doing a lot of testing, and I was wondering if I can run James> Wine from within its source tree without having to reinstall it James> after every build. If it can be done without conflicting with an James> existing installation of Wine, how do I do it? Try it. For me it works. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 22, 2005

Re: Running Wine from source tree

by Mike McCormack

James Liggett wrote: > I'm doing a lot of testing, and I was wondering if I can run Wine from > within its source tree without having to reinstall it after every build. > If it can be done without conflicting with an existing installation of > Wine, how do I do it? Yes, it can be done. In fact, I don't have Wine installed to make sure that I don't get confused as to which version I'm testing. I have the attached script (exists at ~/bin/wine_envsetup) to set up my environment (assumes wine in ~/wine), but running ~/wine/wine will also work. You can set up a ~/.wine from the source tree using: ./tools/wineprefixcreate --use-wine-tree . Then add an alias to set up your environment to your ~/.bashrc, something like this: export OLDPATH=$PATH alias winehq='. $HOME/bin/wine_envsetup' You can then run 'winehq' to setup your environment. I find this configuration useful to because I have multiple wine environments, so multiple ~/bin/*_envsetup scripts. It points everything to the right place so that running 'wine' on the command line will run the wine binary from the setup I'm interested in, not a shell script. Again, you don't need to go to all this trouble if you're happy to run the ~/wine/wine script in the source directory. Mike #!/bin/sh # set up the Wine environment CVSROOT=:pserver:cvs(a)cvs.winehq.org:/home/wine PATH=$OLDPATH:$HOME/wine:$HOME/wine/tools/winegcc WINESERVER=$HOME/wine/server/wineserver WINELOADER=$HOME/wine/loader/wineloader WINEPREFIX=$HOME/.cxoffice/default LD_LIBRARY_PATH=$HOME/wine/libs/unicode:$HOME/wine/dlls:$HOME/wine/libs/wine WINEDBG=$HOME/wine/debugger/winedbg WINEDLLPATH=$HOME/wine/dlls:$HOME/wine/programs export CVSROOT PATH WINESERVER WINEPREFIX LD_LIBRARY_PATH WINEDBG WINEDLLPATH WINELOADER

Sept. 22, 2005

Running Wine from source tree

by James Liggett

Hi, I'm doing a lot of testing, and I was wondering if I can run Wine from within its source tree without having to reinstall it after every build. If it can be done without conflicting with an existing installation of Wine, how do I do it? Thanks, James

Sept. 22, 2005

Re: [DOCS, POLICY] Documenting stuff that doesn't work right?

by Dimi Paun

On Wed, 2005-09-21 at 22:01 +0200, Holly Bostick wrote: > Obviously I know how to get around this, having just done so, but is > this appropriate to document? I have no idea why you encountered that sort of behavior, but it doesn't seem right. Unless Alexandre tells us this is the way it should work, I'd consider it a bug and hope that it's going to get fixed before the release. So no, no need to document it just yet. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 22, 2005

Re: XEmbed Systray Support

by James Liggett

Adding the locking fixes the problem about icons not docking properly that I described in one of my posts yesterday. It's much better now. James On Wed, 2005-09-21 at 13:58 -0500, Robert Shearman wrote: > Alexandre Julliard wrote: > > >Robert Shearman <rob(a)codeweavers.com> writes: > > > > > >>+ ev.xclient.type = ClientMessage; > >>+ ev.xclient.window = systray_window; > >>+ ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); > >>+ ev.xclient.format = 32; > >>+ ev.xclient.data.l[0] = CurrentTime; > >>+ ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; > >>+ ev.xclient.data.l[2] = data->whole_window; > >>+ XSendEvent( display, systray_window, False, NoEventMask, &ev ); > >>+ XSync( display, False ); > >> > >> > > > >You need to get the tsx11 lock when calling X functions. Also what's > >the reason for having an XSync here? > > > > I've added the locking. The XSync is needed because without it the > systray window ends up with a width of 1. I don't understand why this is > happening. What debug channels would be good to turn on to investigate this? >

Sept. 21, 2005

Re: DDRAW: Fix reference counting

by Jakob Eriksson

Stefan Dösinger wrote: >Hello, > > > >>In that case, it would be really beneficial with a unit test. >>Both as documentation and to see what Windows does. >> >> >Excuse my ignorance, but what exactly is meant with 'unit test'? As far as >I've learned, it's a small piece of code which uses this functionality and >checks the results. My patch includes such a test: > > I'm sorry. The test looks excellent. //Jakob

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Lionel Ulmer

On Wed, Sep 21, 2005 at 10:54:28PM +0300, Shachar Shemesh wrote: > As a side track, Win4Lin contacted me a while back, and wanted Lingnu to > represent them in Israel. I sent back a few technical questions, and > NEVER HEARD FROM THEM AGAIN! Does the company still exist? Last I know they still exist and plan to sell a packaged version of QEMU as their Windows emulator. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 21, 2005

Re: D3D7 -> WineD3D

by Stefan Dösinger

> > > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html > > > > I've seen it, but I've spent all my time hacking on D3D7->WineD3D > > Great.. It's not so great at the moment, I've stopped trying for now. WineD3D and D3D7 are too different to allow an easy translation between them. My plan was to copy some interfaces from d3d9 and use them to translate between d3d7 and wined3d, so I can use wined3d with the directx 9 interface, but I ended up with copying more and more code. I stopped when I tried to do something usefull with DD7 surfaces. I didn't want to make huge changes into WineD3D, and I have to understand the way how newer Direct3D versions are working better. Stefan

Sept. 21, 2005

[DOCS, POLICY] Documenting stuff that doesn't work right?

by Holly Bostick

Hey, So I just blew away my previous install of Wine and reinstalled from yesterday's CVS, and went to install a program, so I could take notes on the most current user experience for the docs. I immediately realized that I hadn't run winecfg to set my drives, so I went to do that-- and that's where I ran into this problem. I was installing Icewind Dale, and like all games and Wine-installed programs, I meant to install to the partition I have set aside for that purpose, which is mounted to /usr/local/games, with a symlink in my home directory. So naturally I usually set this partition to be a Wine drive, and I prefer to use d: as the browse dialog naturally defaults to the c: drive and it's faster to change if I only have to change to the next drive. When I went to the 'Drives' tab in winecfg, I had c: (of course) e: (tmp) f: (my home directory) z: (/) You will notice that no removeable media device appears. So I go to add a drive, which is automatically called D: , as you would expect, and I set it to point to /usr/local/games, and I also add G: and set it to point to /media/cdrecorder. Hit apply and all appears well (no errors or anything of that sort). Run the IWD install again and get to the installation location section, and G appears in the browser, but D does not. Cancel and back to winecfg to try again. After several attempts, I finally opened up a file manager and went to ~/.wine/dosdevices and looked at what was there. To my surprise, there was already a link to d:, which was set to /cdrom (which is an invalid location for me anyway since I use hal, which puts stuff in /media). Since I had already set the correct mount point of my DVD drive to the g: link, I just changed d: to my preferred location of /usr/local/games, and was able to complete the install to the d:\iwd directory as I had planned. So the problem is that an automatically created (but wrongly targeted, in these days of hal/dbus) link is created to the cdrom device does not appear in the Winecfg drive list (unless you do autodetect, which may well add additional, unwanted drives to the list that the user would have to remove), making a drive letter that 'seems' to be available in fact unavailable for use (the reason that I couldn't set /usr/local/games to d was because d already existed and couldn't apparently be changed in its invisibility), and also causing the user to think that no drive letter is set for the CD/DVD device, so that they create an unnecessary second link. Obviously I know how to get around this, having just done so, but is this appropriate to document? Or is it likely to be fixed before the updated docs go 'live'? I only ask because I can't think of a way to write this up atm without explicitly exposing a flaw in Wine, and Wine doesn't really deserve that-- even winecfg doesn't deserve that, being much improved from even last month's release (which improvement is obvious, even though I've only done this single operation). I mean, I'll take notes on everything, but this looks like a policy question to me. Holly

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Shachar Shemesh

Michael Stefaniuc wrote: > Tom Wickline wrote: > >> Fom : >> http://archives.free.net.ph/message/20050921.093916.4717740b.en.html > > This can be because TurboLinux announced today that they will > distribute the DAVID technology from SpecOpS: > http://www.turbolinux.com/cgi-bin/newsrelease/index.cgi?date2=2005082117324… > > > bye > michael I'd understand it more if I knew WHAT the David technology actually was! Did they release ANYTHING? Regarding the challenge, it seems that they will give you the application they want working if you contact them. Oh, and about David. Their web site claims to use a hybrid approach to the matter. They integrate emulation and Wine (and wine style) reimplementation. I have no idea how such a thing is supposed to help them along. Also, it will be interesting to see whether this turns out to be any different than what Win4Lin are doing. As a side track, Win4Lin contacted me a while back, and wanted Lingnu to represent them in Israel. I sent back a few technical questions, and NEVER HEARD FROM THEM AGAIN! Does the company still exist? Shachar

Sept. 21, 2005

Re: listview: infoPtr might be invalid after WM_NOTIFY

by Lionel Ulmer

On Tue, Sep 20, 2005 at 11:32:38PM -0400, Dimi Paun wrote: > This is true only if we rely on the access violation exception > (which is a possibility, I admit). But the test patch that I sent > checked the hwnd after each notify message with IsWindow(), and > if invalid it was throwing a custom exception. OK, so next time I will read the patch before saying stupid things :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 21, 2005

Re: XEmbed Systray Support

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > I've added the locking. The XSync is needed because without it the > systray window ends up with a width of 1. I don't understand why this is > happening. What debug channels would be good to turn on to investigate this? Probably +event and check for ConfigureNotify and that sort of things. -- Alexandre Julliard julliard(a)winehq.org

Sept. 21, 2005

Re: XEmbed Systray Support

by Robert Shearman

Alexandre Julliard wrote: >Robert Shearman <rob(a)codeweavers.com> writes: > > >>+ ev.xclient.type = ClientMessage; >>+ ev.xclient.window = systray_window; >>+ ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); >>+ ev.xclient.format = 32; >>+ ev.xclient.data.l[0] = CurrentTime; >>+ ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; >>+ ev.xclient.data.l[2] = data->whole_window; >>+ XSendEvent( display, systray_window, False, NoEventMask, &ev ); >>+ XSync( display, False ); >> >> > >You need to get the tsx11 lock when calling X functions. Also what's >the reason for having an XSync here? > I've added the locking. The XSync is needed because without it the systray window ends up with a width of 1. I don't understand why this is happening. What debug channels would be good to turn on to investigate this? -- Rob Shearman

Sept. 21, 2005

Re: OLEAUT32: add full multiplication/division support for DECIMAL (in small patches)

by Dimi Paun

From: "Alex Villacís Lasso" <a_villacis(a)palosanto.com> > By popular request, I am resending the implementation for DECIMAL > multiplication/division in small patches. Good, but please send one patch per email. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Michael Stefaniuc

Tom Wickline wrote: > Fom : http://archives.free.net.ph/message/20050921.093916.4717740b.en.html This can be because TurboLinux announced today that they will distribute the DAVID technology from SpecOpS: http://www.turbolinux.com/cgi-bin/newsrelease/index.cgi?date2=2005082117324… bye michael > > $10,000 Open Challenge > > Top Page > This message is part of the following thread: > M the complete thread tree sorted by date > > > Author: El Cid Ablang > Date: > To: linuxjobs > Subject: $10,000 Open Challenge > SpecOpS Laboratories > > $10,000 Open Challenge > > > > > > SpecOpS Laboratories (SpecOpS Labs) invites the Philippine > > ICT Community to participate in the DAVID Project. We are seeking a > highly talented Consultant or Consulting Team that can contribute to the > DAVID Project. > > > > SpecOpS Labs is searching the Philippines for Systems-Level > > Hacker/s to serve as Development Consultant to the DAVID Project. As > proof or our sincerity, we are offering US$10,000.00* to the first > Consultant or Consulting Team who can take our challenge and prove their > capabilities. Our challenge requires the delivery of a solution that > will allow an MS-XP compatible application to install and run under > Linux using x.org and open source WINE by October 5, 2005. > > > > So, take the challenge now! > > > > > Criteria to Award and Conditions: > > > > 1. System has no proprietary software imbedded / required. > > 2. System is stable. > > 3. MS-XP compatible modules / functions are working as expected. > > 4. System becomes the property of SpecOpS Laboratories. > > > > Registration Procedure: > > > > 1. Send us an Email indicating your intent to take up the challenge > at <mailto:ablang@???> ablang@???. Attach your > CV(s) or company profile (if applicable). > > 2. SpecOpS will Email you the Challenge Registration Form and > further instructions. > > > > Challenge Activities: > > > > 1. Present the running solution at SpecOpS Labs office before > October 5, 2005. > > 2. Validation of solution using SpecOpS Labs's criteria. > > 3. Award immediately. > > > > > > * All monies in this challenge are subject to tax. The decision of > SpecOpS Labs for the award is final. -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Tom Wickline

On 9/21/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Tom Wickline wrote: > > 4. System becomes the property of SpecOpS Laboratories. > > Oh yeah, someone writes a full windows API implementation in a month or so, capable of replacing an > OS that generates 1 billion US dollars a month in revenue, beating over a decade of open source > wine development, and sells it to SpecOpS Laboratories for 10k, that's sure going to happen. > I think anybody with the means to do that would make it open source, or sell it to the highest bidder. I agree, I thought this was some kind of joke.. 10k? 10k isn't squat.. I use to blow more than 10k a year on beer and party. But Ive been sent a couple links that show that there is interest in there offerings. http://www.turbolinux.com/cgi-bin/newsrelease/index.cgi?date2=2005082117324… http://www.specopslabs.com/content/ibm-loi.pdf I just hope they turn out to be good members in the OSS community and give back to Wine as they have taken from it. Tom > > Ivan. >

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Kuba Ober

> > 4. System becomes the property of SpecOpS Laboratories. > > Oh yeah, someone writes a full windows API implementation in a month or so, > capable of replacing an OS that generates 1 billion US dollars a month in > revenue, beating over a decade of open source wine development, and sells > it to SpecOpS Laboratories for 10k, that's sure going to happen. I think > anybody with the means to do that would make it open source, or sell it to > the highest bidder. I'm pretty sure with a correct price tag the wine team could get some more people involved and do it. I bet $10 billion would be a good price tag :) Kuba

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Kuba Ober

The most frightening thing is that, apparently, someone clueless enough at IBM Phillipines, Inc. got 'involved' with it: http://www.specopslabs.com/content/ibm-loi.pdf If I were IBM, I'd start doing some serious PR mopping up/fallout prevention. This is quadruple-sad. Cheers, Kuba

Sept. 21, 2005