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

Re: [COMCTL32] Listview: Store DC before calling PREPAINT

by Robert Shearman

Maarten Lankhorst wrote: > Some applications like to use PREPAINT to set fonts, nothing wrong > with that, only DC is never restored, resulting in drawing glitches. > > Changelog: > Save and restore DC on every listview item drawn. I don't think native would do this. SaveDC / RestoreDC seems like an overkill. It would seem better to just call SelectObject to save and restore the font each time. You should then also test for the CDRF_NEWFONT flag and act appropriately. -- Rob Shearman

Jan. 30, 2006

Re: Text Object Model and Richedit?

by Phil Krylov

On Mon, 30 Jan 2006 08:31:59 -0800 Dan Kegel <dank(a)kegel.com> wrote: > I stumbled across the doc for the "Text Object Model", > which looks like the COM interface to Richedit and > anything like it: > > http://windowssdk.msdn.microsoft.com/library/en-us/shellcc/platform/commctl… > > Is anyone poking around at adding this interface > to our Richedit? Not me, at least in the nearest future... It has rather poor documentation on MSDN, and most apps don't use it (probably due to the same poor documentation). -- Ph.

Jan. 30, 2006

Re: D3D8: Fixed D3DRS fixes

by H. Verbeet

On 30/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { ARB_POINT_PARAMETERS is defined in d3dcore_gl.h, but never checked for in directx.c. That means the check should always return false.

Jan. 30, 2006

Text Object Model and Richedit?

by Dan Kegel

I stumbled across the doc for the "Text Object Model", which looks like the COM interface to Richedit and anything like it: http://windowssdk.msdn.microsoft.com/library/en-us/shellcc/platform/commctl… Is anyone poking around at adding this interface to our Richedit? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 30, 2006

Re: Wine-wiki broken by design

by Dimi Paun

From: "Molle Bestefich" <molle.bestefich(a)gmail.com> > And why are "nofollow" on in the first place? The official explanation is: # if it is a normal page, index it, but do not follow the links, because # there are a lot of illegal links (like actions) or duplicates: Anyway, I've just enabled it for normal links, please let me know if there is anything else that needs adjusting. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Jan. 30, 2006

Re: Wine-wiki broken by design

by Dimi Paun

From: "Dan Kegel" <dank(a)kegel.com> > Maybe the wine wiki could publish a machine-readable sitemap; see > http://www.xml-sitemaps.com/ > http://www.google.com/webmasters/sitemaps/docs/en/about.html This seems like a good idea, but unless someone has time to come up with a patch, I'm afraid I don't have the time right now to do it. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Jan. 30, 2006

[frick@sc-networks.de: wined3d: support for WINED3D_A8B8G8R8]

by Christoph Frick

hiho, could someone enlighten me, what is wrong with that patch? -- cu

Jan. 30, 2006

Re: <DEL> key is sending an extra char when NumLock is ON

by zhilla

penna(a)bb.com.br wrote: > I was looking at an old problem I have with wine and saw some > record at the wine-devel and wine-users lists that I think are related > with the same problem. Look at: > http://www.winehq.org/hypermail/wine-users/2004.03.txt (look for "get a > comma on the place" in your browser) and also at: > http://www.winehq.org/hypermail/wine-devel/2000.10.txt (look for "but > then it inserts" in your browser) > When the NumLock is ON wine is sending an extra key. Wine deletes > the corresponding char but also send a period (.) or a comma (,) <- it > depends on the type of the keyboard. In my case, which is a brazilian > ABNT2, it sends an extra comma _only_ if the NumLock is ON. It does not > mater if I press the <del> key at the numeric key pad or at the "island" > that contais the <del> <ins> <home> <end> ... stuff. > I am going to open a bug at bugzilla and send the WINEDEBUG=+key > (just the piece where the stuff happens). dont, its already opened for a while. http://bugs.winehq.org/show_bug.cgi?id=2400 there is a working patch there... but some people claim its not very good since it hardwires the key to code. somebody should really look into this already... half of solution is already there :)

Jan. 30, 2006

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL? [FIXED]

by Molle Bestefich

Jonathan Ernst wrote: > Le samedi 28 janvier 2006 à 21:07 +0000, Molle Bestefich a écrit : > > Jonathan, what software do you use, if you don't mind revealing? :-) > > It's Evolution 2.4.2.1, pretty good e-mail client if you ask me. I'll agree that the GUI is pretty good. The MIME assembly lacks somewhat :-). And for some odd reason Gmail's aggregation feature doesn't like your mails either - the same email always shows up twice for me. I wonder.

Jan. 30, 2006

Re: Corel Draw and Printing

by Roland Kaeser

Hello Sorry, had to do something emergency stuff these days. I tried it to print into a postscript file sent it to the printer (we don't have local printers, all our, and mine, printers are only network printers, so I can't send the code to /dev/lp0). This worked fine. I think its a kind of missing config parameters and its behaviour in wine. It should be possible to force wine to spool everything first through the local cups instead of sending it "passthough". Can somebody see that this feature comes into wine asap. Roland Kaeser Kuba Ober wrote: >> There is, since a longer time ago, a wine bug #3599 about Corel Draw and >> printing. Its a very strange behaviour. I can configure what ever I want, >> I always uses the wine passthrough and sends the postscript code, of >> Corel Draw directly to the printer instead of spooling it first through >> the cups driver. I've readt all known documentations about wine and >> printing but cannot get one step ahead. Can somebody tell me the wine >> internal reason of this behaviour? I would really like to have this >> feature working. Why didn't wine spool everything first through the cups >> spooler (as the default behaviour) unless an other, explicity specified >> configuration tells wine to >> passthrough the spool output. The other question is, why shows wine a >> postscript printer to corel draw? I know, I know, on Linux all printer >> interfaces are postscript, but Corel takes this info literally and >> explicitly creates postscript code (by itself) and not uses the windows >> printer api to create the printer-document. > > That's probably how Corel was designed, and that's OK. > > Now as far as sending "directly" to the printer, what do you mean? Why do > you think it goes "directly" to the printer? Directly as in what -- wine > dumping to /dev/lp0? Have you looked at cups logs? > > Cheers, Kuba

Jan. 30, 2006

make check fails in iphlapi

by Marcus Meissner

Hi, make check here fails in dlls/iphlapi/tests with: make[1]: Entering directory `/home/marcus/projects/wine/dlls/iphlpapi/tests' ../../../tools/runtest -q -P wine -M iphlpapi.dll -T ../../.. -p iphlpapi_test.exe.so iphlpapi.c && touch iphlpapi.ok [..] trace:iphlpapi:GetAdaptersInfo pAdapterInfo (nil), pOutBufLen (nil) trace:iphlpapi:GetAdaptersInfo returning 87 trace:iphlpapi:GetAdaptersInfo pAdapterInfo (nil), pOutBufLen 0x55c2fae8 trace:iphlpapi:GetAdaptersInfo returning 111 trace:iphlpapi:GetAdaptersInfo pAdapterInfo 0x7c0097f0, pOutBufLen 0x55c2fae8 fixme:iphlpapi:GetAdaptersInfo table->numind 4, numnonloopback 4, ipaddrtab->numents 3, numipaddresses 3 trace:iphlpapi:GetAdaptersInfo returning 0 *** glibc detected *** free(): invalid next size (normal): 0x7c0096d8 *** The test is testGetAdaptersInfo() and I guess the GetAdaptersInfo() call overwrites the end of the malloc()ed buffer. I don't really know whats broken there. the values of the interesting parameters: table->numIndexes is 4 numNonLoopbackInterfaces is 4 ipAddrTable->dwNumEntries 3 numIPAddresses 3 Ciao, Marcus

Jan. 30, 2006

Re: shell32/shellpath [3/3]: (RESEND) Create symlinks to $HOME based directories during SHELL_RegisterFolders.

by Michael Jung

On Sunday 29 January 2006 10:38, Michael Jung wrote: > ChangeLog: > Create $HOME targeted symbolic links during SHELL_RegisterFolders. I've just realized that unixfs has a problem with the symlink stuff. It evaluates symbolic links in UNIXFS_get_unix_path and then doesn't find a DOS path for /home/mjung in GetDisplayNameOf (If there's no drive mapped to '/', that is.) The symlink evaluation is done to get rid of the '/home/mjung/.wine/dosdevices/c:' prefixes in unix paths. I guess we should get rid of the generic symlink evaluation in unixfs and implement something especially targeted at those prefixes? I guess this should be considered a bug in unixfs, so in my opinion it would be ok to apply the shellpath-patches. In a standard setup with Z:\ mapped to /, everything is fine. And even if it's removed, it's still better than with the current solution. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Jan. 30, 2006

Re: sudo vs su in wineinstall

by Tom Spear (Dustin Booker, Dustin Navea)

James Hawkins wrote: > If the user is not in the /etc/sudoers configuration file, it just > complains you're not in the configuration and asks for the root > password. > That is apparently distro-specific, as the last time I used sudo on my Slackware 10.2 box (a few months ago), as well as on my roommate's RH9 box, it wouldnt allow sudo period unless /etc/sudoers was configged for your user. Tom

Jan. 30, 2006

Re: sudo vs su in wineinstall

by Jesse Allen

On 1/29/06, Dan Kegel <dank(a)kegel.com> wrote: > Let's simply delete the wineinstall script. > It's not really needed anymore, it was just > there for compatibility. > > People have been talking about doing it for some time: > http://winehq.org/site/?issue=227#Nuking%20Wineinstall > perhaps now's the time. > What does it do that make install or wineprefixcreate can't already do? I haven't used wineinstall in a long time.

Jan. 30, 2006

Re: sudo vs su in wineinstall

by Chris Morgan

I've always liked wineinstall, even made a handful of improvements to it. Wineinstall was useful for setting up a default configuration but now that we setup a default configuration automatically with wineprefixcreate it doesn't seem necessary anymore. Users that compile via source should be fine with './configure&&make' and 'make install' like they use to build and install most other programs. Chris On Sunday 29 January 2006 11:57 pm, Dan Kegel wrote: > Let's simply delete the wineinstall script. > It's not really needed anymore, it was just > there for compatibility. > > People have been talking about doing it for some time: > http://winehq.org/site/?issue=227#Nuking%20Wineinstall > perhaps now's the time. > > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 30, 2006

re: sudo vs su in wineinstall

by Dan Kegel

Let's simply delete the wineinstall script. It's not really needed anymore, it was just there for compatibility. People have been talking about doing it for some time: http://winehq.org/site/?issue=227#Nuking%20Wineinstall perhaps now's the time. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 30, 2006

Re: sudo vs su in wineinstall

by James Hawkins

On 1/29/06, n0dalus <n0dalus+redhat(a)gmail.com> wrote: > On 1/30/06, James Hawkins <truiken(a)gmail.com> wrote: > > > > If the user is not in the /etc/sudoers configuration file, it just > > complains you're not in the configuration and asks for the root > > password. > > > > /etc/sudoers is not usually world-readable. The way to do it would be > with `sudo -l`, but this requires the user's password, and we'd have > to parse any fine-grained security options. > I think you misunderstood what I'm saying. We don't check /etc/sudoers for the user's configuration. If the user is not in /etc/sudoers and the user runs sudo, the sudo program complains that the user is not in the configuration and asks for the root password. -- James Hawkins

Jan. 30, 2006

Re: sudo vs su in wineinstall

by n0dalus

On 1/30/06, James Hawkins <truiken(a)gmail.com> wrote: > > If the user is not in the /etc/sudoers configuration file, it just > complains you're not in the configuration and asks for the root > password. > /etc/sudoers is not usually world-readable. The way to do it would be with `sudo -l`, but this requires the user's password, and we'd have to parse any fine-grained security options. Is there another way of checking to see if su(do) works? I still think a good way would be to have the script run as root and execute a child process as a non-root user for compiling and stuff. The problem is working out what user to run as. Alternatively, we could just split wineinstall into winecompile and wineinstall. n0dalus.

Jan. 30, 2006

Re: sudo vs su in wineinstall

by James Hawkins

On 1/29/06, Tom Spear (Dustin Booker, Dustin Navea) <speeddymon(a)gmail.com> wrote: > Hi guys, bug 4439 describes a problem where a machine (running ubuntu) > does not install wine when using wineinstall due to the fact that su dos > not work.. > > Just a couple of questions: > > Is this the case (su not working) on all Ubuntu machines, or just > something broken on that users' machine? > I believe it's a distro-specific design choice (for security) of Ubuntu, and maybe even Debian. > If it is the case on all Ubuntu machines, the user has mentioned that > sudo does work. sudo does require configuration prior to being used, > but we could always add into the wineinstall script to configure sudo > for the user, or we could ask the user to configure it themself, OR we > could fall back to using su if the user answers no to having used > sudo.. see below: > If the user is not in the /etc/sudoers configuration file, it just complains you're not in the configuration and asks for the root password. > > What do you think guys? > I think we should see if su exists/works and use it if it does, else use sudo. -- James Hawkins

Jan. 30, 2006

Re: sudo vs su in wineinstall

by n0dalus

On 1/30/06, Tom Spear (Dustin Booker, Dustin Navea) <speeddymon(a)gmail.com> wrote: > Hi guys, bug 4439 describes a problem where a machine (running ubuntu) > does not install wine when using wineinstall due to the fact that su dos > not work.. > > Just a couple of questions: > > Is this the case (su not working) on all Ubuntu machines, or just > something broken on that users' machine? I think Ubuntu comes without a set root password. This is to try to dumb down the idea of having a root user (just my take on it). > If it is the case on all Ubuntu machines, the user has mentioned that > sudo does work. sudo does require configuration prior to being used, > but we could always add into the wineinstall script to configure sudo > for the user, or we could ask the user to configure it themself, OR we > could fall back to using su if the user answers no to having used > sudo.. see below: Configuring or requiring an allow-everything sudo for people is a bad idea, as it weakens security on the machine. What would be much better and simpler for the user, is if you had to start the wineinstall script as root (using su, sudo, whatever is appropriate for the distribution/setup) and it would run a seperate process as a non-root user to perform the compiling, etc, and bits that need root would be run by the wineinstall script directly. n0dalus.

Jan. 30, 2006

sudo vs su in wineinstall

by Tom Spear (Dustin Booker, Dustin Navea)

Hi guys, bug 4439 describes a problem where a machine (running ubuntu) does not install wine when using wineinstall due to the fact that su dos not work.. Just a couple of questions: Is this the case (su not working) on all Ubuntu machines, or just something broken on that users' machine? If it is the case on all Ubuntu machines, the user has mentioned that sudo does work. sudo does require configuration prior to being used, but we could always add into the wineinstall script to configure sudo for the user, or we could ask the user to configure it themself, OR we could fall back to using su if the user answers no to having used sudo.. see below: ./tools/wineinstall Warning: the wineinstall script installs wine using the sudo command. Have you ever used sudo on this machine before? if (yes) continue as normal else # either of these could work # option 1 Would you like to have us try to configure sudo for you? # option 2 User has not used or configured sudo, falling back to su WARNING: su may be broken on your machine, and therefore wine may be built but not installed. If you are unable to run wine after this script completes, please login as root, and do 'make install' then login as your user again. Of course we could always just add a configure check to see if su works, and if it doesnt, die with a warning about wineinstall not working because of that. What do you think guys? Tom

Jan. 30, 2006

Re: Startup time of OOo2, Firefox 1.5. Some surprises.

by Dan Kegel

On 1/29/06, n0dalus <n0dalus+wine(a)gmail.com> wrote: > Very interesting. Keep in mind that the FC5t2 kernels and libraries > currently have some debugging stuff enabled that might have a big > effect in these tests. The few bits I've verified in Ubuntu 05.10 are the same as in FC5t2, so perhaps that isn't a problem. I'll do future measurements in Ubuntu, probably. There are some rendering problems in Firefox; to see them, run firefox 1.5 under wine, then log in to gmail.com; you'll see black streaks to the left of the text entry areas. Firefox also seems to render slowly; it's tempting to run wine under oprofile and see if that finds the bottleneck. cf. http://www.winehq.com/?issue=249#oprofile%20&%20Wine - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 30, 2006

Re: Startup time of OOo2, Firefox 1.5. Some surprises.

by n0dalus

On 1/30/06, Dan Kegel <dank(a)kegel.com> wrote: > To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 > under Wine routinely, I benchmarked their startup time > on a Fedora Core 5 test 2 system under four conditions: > native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM > (by booting with mem=96M; this was to simulate running on > one of those cheapo 128MB boxes that uses shared video RAM). > This was on a zippy Compaq Presario 3000 Athlon 64 3000+. > All apps were downloaded from openoffice.org and mozilla.com. Very interesting. Keep in mind that the FC5t2 kernels and libraries currently have some debugging stuff enabled that might have a big effect in these tests. You should think about posting these results to the fedora-devel or fedora-test list. n0dalus.

Jan. 30, 2006

Startup time of OOo2, Firefox 1.5. Some surprises.

by Dan Kegel

To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com. Results for first run of app after booting (1st column is startup time): 5 Firefox run1 native 416MB 12 Firefox run1 wine 416MB 11 Firefox run1 native 96MB 15 Firefox run1 wine 96MB 11 ooo run1 native 416MB 15 ooo run1 wine 416MB 60 ooo run1 native 96MB 37 ooo run1 wine 96MB So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?) I then measured how long it took to start up the app the second time, when the cache was nice and hot: 3 Firefox run2 native 416MB 4 Firefox run2 wine 416MB 4 ooo run2 native 416MB 6 ooo run2 wine 416MB 4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 30, 2006

Re: [patch] updated riched20 conformance test

by Phil Krylov

On Tue, 24 Jan 2006 12:23:09 -0800 Thomas Kho <tkho(a)ucla.edu> wrote: > Attached is a small patch to add a riched20 conformance test. I think it's a good test, but I'd add "flags %08x",...flags to the failing test messages, because all these failures are due to unimplemented flags. And probably the message names should be printed as well... -- Ph.

Jan. 29, 2006