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

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