December 2008 - Wine-Devel - list.winehq.org

Re: dlls/user32/dde_client.c warning fixes (RESEND)

by Gerald Pfeifer

On Wed, 31 Dec 2008, Alexandre Julliard wrote: > Gerald Pfeifer <gerald(a)pfeifer.com> writes: >> The current version likely is actually broken since the ! operator has >> a higher priority than bitwise & in C. Unless someone really wanted to >> use a very, hmm, unusual construct here? > No, it's clearly not intended, but fixing this breaks the tests, this > would need to be addressed first. Well, I found the bug and provided a fix, alas the testsuite is not exactly territory I feel home at. :-( I hope we won't keep the bug for the sake of not breaking a bogus test... Jeff, the vast majority of dlls/user32/tests/dde.c has been contributed by you -- is this something you could help with? Thanks, Gerald

Dec. 31, 2008

iPod synced with iTunes v7.6!

by Michael Siebert

Hallo Maarten! I'd like to reproduce iPhone access via Wine + iTunes, but your description is not detailed enough for me. How did you actually perform steps 1.-3.? Happy New Year, Michael

Dec. 31, 2008

RE: Contribution to the Toolbar common control

by ricardo filipe

although he used disassembly to check our implementation, he gave msdn proof for the notifications he talked about... and didn't contribute code. ---------------------------------------- > Date: Wed, 31 Dec 2008 08:45:43 -0600 > From: austinenglish(a)gmail.com > To: alanfeld(a)gmail.com > Subject: Re: Contribution to the Toolbar common control > CC: wine-devel(a)winehq.org > > On Wed, Dec 31, 2008 at 3:49 AM, Alan Feldman wrote: >> Hello Wine developers, >> >> I am writing to this forum because I wanted to contribute some useful >> development information to your community while at the same time not >> have to get too involved as I currently have no plans to stay involved >> going forward. >> >> I wanted to say that I am *really* impressed with the codebase that >> you guys have developed! I stumbled across the Winehq site as I was >> looking for more information on Microsoft's Toolbar common control. >> The source code you guys have has made understanding the internals of >> the Toolbar control really easy and I really appreciate the work you >> guys have done. (I even took a peek at Microsoft's comctl32.dll >> disassembly to confirm a couple of the things you guys wrote and it >> checked out) ;-) > > Wine doesn't allow reverse engineering. Sorry, but you won't be able > to contribute code if you looked at its disassembly. > > -- > -Austin > > _________________________________________________________________ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/photos.aspx

Dec. 31, 2008

Re: winmm: Check param in joyConfigChanged

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: >> There's no reason to rename the parameter, 'flags' is a perfectly good >> name. >> > It was just to reflect more the MSDN. Maybe it's not that usefull. No it's not, MSDN uses the stupid Hungarian notation everywhere, and we should stay as far away as possible from that monstrosity. 'flags' is a much better name than 'dwFlags'. -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2008

Re: winmm: Check param in joyConfigChanged

by Christian Costa

Alexandre Julliard a écrit : > Christian Costa <titan.costa(a)wanadoo.fr> writes: > > >> -MMRESULT WINAPI joyConfigChanged(DWORD flags) >> +MMRESULT WINAPI joyConfigChanged(DWORD dwFlags) >> { >> - FIXME("(%x) - stub\n", flags); >> + FIXME("(%x) - stub\n", dwFlags); >> + >> + if (dwFlags) >> + return JOYERR_PARMS; >> > > There's no reason to rename the parameter, 'flags' is a perfectly good > name. > > It was just to reflect more the MSDN. Maybe it's not that usefull.

Dec. 31, 2008

Re: Wine on Windows - wiki notes

by Steven Edwards

On Tue, Dec 30, 2008 at 5:02 PM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Cygwin/Mingw doesn't work due to missing functionality for wineserver I believe (not sure what). Someone recently claimed that he indeed had wine working on Interix on a 32-bit WinXP. Right now he was trying to compile it on a 64-bit Windows but had all sorts of troubles. For instance there is some define for ELF stuff which he had to disable. He didn't succeed in compiling it and I have doubts that he succeeded before but Interix looks the most promosing of the options right now. I've poked at it off and on over the years Its been my experience building on Cygwin was actually less trouble. Cygwin and SFU/Internix both require the same basic lowlevel magic. Proper signal handling, getting the thread management right and sendmsg/recvmsg support. I think someone on the cygwin side was working on the sendmsg/recvmsg part so maybe that could be ported over to SFU. Honestly though I think this is the wrong approach. If you want to emulate an older windows environment you should look at something like VMware's Thinapp. The Wine on Windows method is going to involve either emulating Win32 on Cygwin on Win32 or Win32 on POSIX on NTOS. I think its too many layers of abstraction and redirection. I don't know the internals of the Thinapp design, (if Ge van Geldorp is lurking he can explain more), but I believe it uses Side by Side assemblies to link on older versions of Windows dlls or Windows replacement dlls to trick the applications in to thinking they are on older Windows. You could take the existing Wine for Mingw32 dlls and a good bit of other Wine code and try to start a project doing something like this without the overhead of the wineserver and posix emulation. A FOSS Thinapp clone sounds like a reall fun project actually... Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 31, 2008

Re: Contribution to the Toolbar common control

by Austin English

On Wed, Dec 31, 2008 at 3:49 AM, Alan Feldman <alanfeld(a)gmail.com> wrote: > Hello Wine developers, > > I am writing to this forum because I wanted to contribute some useful > development information to your community while at the same time not > have to get too involved as I currently have no plans to stay involved > going forward. > > I wanted to say that I am *really* impressed with the codebase that > you guys have developed! I stumbled across the Winehq site as I was > looking for more information on Microsoft's Toolbar common control. > The source code you guys have has made understanding the internals of > the Toolbar control really easy and I really appreciate the work you > guys have done. (I even took a peek at Microsoft's comctl32.dll > disassembly to confirm a couple of the things you guys wrote and it > checked out) ;-) Wine doesn't allow reverse engineering. Sorry, but you won't be able to contribute code if you looked at its disassembly. -- -Austin

Dec. 31, 2008

Re: winmm: Check param in joyConfigChanged

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > -MMRESULT WINAPI joyConfigChanged(DWORD flags) > +MMRESULT WINAPI joyConfigChanged(DWORD dwFlags) > { > - FIXME("(%x) - stub\n", flags); > + FIXME("(%x) - stub\n", dwFlags); > + > + if (dwFlags) > + return JOYERR_PARMS; There's no reason to rename the parameter, 'flags' is a perfectly good name. -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2008

Re: dlls/user32/dde_client.c warning fixes (RESEND)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > The current version likely is actually broken since the ! operator has > a higher priority than bitwise & in C. Unless someone really wanted to > use a very, hmm, unusual construct here? No, it's clearly not intended, but fixing this breaks the tests, this would need to be addressed first. -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2008

Please add glut to winetricks :)

by Couannette

Hi Dan, I found winetricks very helpful ! Thank you for this very nice script ;). Could you please add glut [1] to the packages winetricks knows about ? Thank you very much, Couannette [1] http://www.opengl.org/resources/libraries/glut/glut_downloads.php

Dec. 31, 2008

Re: Ouch.

by Marcus Meissner

On Wed, Dec 31, 2008 at 10:21:29AM +0100, Kai Blin wrote: > On Tuesday 30 December 2008 23:55:56 Dan Kegel wrote: > > http://enquiringmimes.com/wp/2008/12/30/a-rumor-we-hope-is-true/ > > said > > "WINE is the famous, this-would-be-so-cool-if-it-only-actually-worked > > way of running Windows on other platforms without needing Windows, > > kind of like how useful it might be to have your blood pumped through > > your body without needing a heart." > > Ah, a troll, just in time to be chased away by the new year fireworks. > > Happy new year, folks. The fun thing is that it likely is again the "Lame solution using Wine", but now for MacOS ;) Ciao, Marcus

Dec. 31, 2008

Contribution to the Toolbar common control

by Alan Feldman

Hello Wine developers, I am writing to this forum because I wanted to contribute some useful development information to your community while at the same time not have to get too involved as I currently have no plans to stay involved going forward. I wanted to say that I am *really* impressed with the codebase that you guys have developed! I stumbled across the Winehq site as I was looking for more information on Microsoft's Toolbar common control. The source code you guys have has made understanding the internals of the Toolbar control really easy and I really appreciate the work you guys have done. (I even took a peek at Microsoft's comctl32.dll disassembly to confirm a couple of the things you guys wrote and it checked out) ;-) So, anyway, in gratitude for what you guys have provided me I wanted to "give something back". I noticed that there are several Toolbar window messages which are listed as "unknown" which at the time of the writing of this e-mail are now definitely "known" and I would like to provide that information to someone to check in to your source code base. Here is my contribution: http://source.winehq.org/source/dlls/comctl32/toolbar.c Function: ToolbarWindowProc() TB_UNKWN45E is really TB_SETHOTITEM2 (WM_USER + 94) TB_UNKWN460 is really TB_SETLISTGAP (WM_USER + 96) TB_UNKWN462 is really TB_GETIMAGELISTCOUNT (WM_USER + 98) TB_UNKWN463 is really TB_GETIDEALSIZE (WM_USER + 99) TB_UNKWN467 (which is not in the Wine source yet) is really TB_GETITEMDROPDOWNRECT (WM_USER + 103) Those Toolbar window messages are currently not in the public Windows headers at this time but they have been *documented* on the MSDN Library web site now. Here are links to the MSDN Library help topics giving evidence to what I wrote up above: http://msdn.microsoft.com/en-us/library/cc835036(VS.85).aspx http://msdn.microsoft.com/en-us/library/bb787441(VS.85).aspx http://msdn.microsoft.com/en-us/library/cc835034(VS.85).aspx http://msdn.microsoft.com/en-us/library/cc835033(VS.85).aspx http://msdn.microsoft.com/en-us/library/cc835035(VS.85).aspx Also, in this source file: http://source.winehq.org/source/include/commctrl.h Someone took a REALLY good guess at the name of a Toolbar notification! TBN_WRAPHOTITEM is definitely the name of notification TBN_FIRST- 24. Good guess! I would say that the comment about this message being undocumented and just a "guess" can now be removed. Even though this message is also not in any public header file, this message is now *documented* and the documentation can be found here: http://msdn.microsoft.com/en-us/library/cc835032(VS.85).aspx Cheers! :-) Alan Feldman

Dec. 31, 2008

Re: Ouch.

by Kai Blin

On Tuesday 30 December 2008 23:55:56 Dan Kegel wrote: > http://enquiringmimes.com/wp/2008/12/30/a-rumor-we-hope-is-true/ > said > "WINE is the famous, this-would-be-so-cool-if-it-only-actually-worked > way of running Windows on other platforms without needing Windows, > kind of like how useful it might be to have your blood pumped through > your body without needing a heart." Ah, a troll, just in time to be chased away by the new year fireworks. Happy new year, folks. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 31, 2008

Re: winhttp: Correctly parse specified ports in WinHttpCrackUrl

by Paul TBBle Hampson

On Tue, Dec 30, 2008 at 11:51:13PM -0800, Dan Kegel wrote: > Hi Paul, > you wrote >> Depends on my previous patch: winhttp/tests:... > The way we usually express that is to prefix each patch > with its position in the series of patches. For instance, > your two-patch series might have used subject lines > [1/2] winhttp/tests: Add tests for WinHttpCrackUrl port number handling > [2/2] winhttp: Correctly parse specified ports in WinHttpCrackUrl Thanks for that, I'll keep that in mind for future. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

Dec. 31, 2008

re: winhttp: Correctly parse specified ports in WinHttpCrackUrl

by Dan Kegel

Hi Paul, you wrote > Depends on my previous patch: winhttp/tests:... The way we usually express that is to prefix each patch with its position in the series of patches. For instance, your two-patch series might have used subject lines [1/2] winhttp/tests: Add tests for WinHttpCrackUrl port number handling [2/2] winhttp: Correctly parse specified ports in WinHttpCrackUrl I like how you broke out the tests into a first patch. (These days it's probably also ok to just include both the tests and and the implementation in a single patch if you prefer.) - Dan

Dec. 31, 2008

Re: CreateScalableFontResourceW

by Jeremy White

I've had a series of patches on this, that I think have been gradually growing less wrong. The 9/17 patches were the last set that were useful by themselves; you should try to get those to apply: http://www.winehq.org/pipermail/wine-patches/2008-September/061696.html My current belief is that the font code needs to be refactored to enable a correct implementation. I submitted that refactoring to wine-devel back in October as an RFC: http://www.winehq.org/pipermail/wine-devel/2008-October/069654.html I believe that a fully correct implementation of CreateScalableFontResource flows from that refactoring and a fairly obvious adjustment of the 9/17 patches. But the importance of this code, my inexperience with it, and the part time nature of my efforts have all led Alexandre to reasonably be very leery of the code. At this point, I am waiting until I have enough time to really focus on it to submit it as a full patch set. I am intending to work on improving the tests around the related code as an intermediate step. But, importantly, it's not likely to see progress in the near term, so your best bet would be to grab the 9/17 patches and attempt to apply them. Cheers, Jeremy

Dec. 30, 2008

Re: kernel32: Add GetProductInfo() stub & defines.

by Alistair Leslie-Hughes

Hi Andrew, "Andrew Riedi" wrote in message news:689de9370812301624l74fc94f9xc200587f8f07c70a(a)mail.gmail.com... >This patch helps bug #15638. ( http://bugs.winehq.org/show_bug.cgi?id=15638 ) > >Changelog: >kernel32: Add GetProductInfo() stub & defines. > >Based on a patch by Alexander Nicolaysen Sørnes. >@ stdcall lstrlenA(str) >@ stdcall lstrlenW(wstr) >+@ stdcall GetProductInfo(long long long long ptr) We try to keep the spec file in alphabetical order. Its in the right section, just needs to be moved up. Best Regards Alistair Leslie-Hughes _________________________________________________________________ Time for change? Find your ideal job with SEEK. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2…

Dec. 30, 2008

re: CreateScalableFontResourceW

by Dan Kegel

I think Jeremy only worked on it in his spare time, and probably took a break from it after his September patch wasn't accepted. Does his 10/19 patch series make your app work? - Dan

Dec. 30, 2008

Ouch.

by Dan Kegel

http://enquiringmimes.com/wp/2008/12/30/a-rumor-we-hope-is-true/ said "WINE is the famous, this-would-be-so-cool-if-it-only-actually-worked way of running Windows on other platforms without needing Windows, kind of like how useful it might be to have your blood pumped through your body without needing a heart."

Dec. 30, 2008

CreateScalableFontResourceW

by Colin Davis

Good Evening, Can anyone help me to understand what the Status of CreateScalableFontResource is? I had asked the IRC room, which directed me to wine-users, and wine-users directed me here. I have an application that uses CreateScalableFontResourceW to load a bundled font, and unfortunately, in 1.1.11 it fails to load. Looking at the souce for this method, it appears to be a stub in the current development version, but Jeremy White had created an implementation for it back in April (http://article.gmane.org/gmane.comp.emulators.wine.patches/49885) I can also see that as of 10/19, he was still working on the feature (http://article.gmane.org/gmane.comp.emulators.wine.devel/63872/match=create…) If anyone has been able to get this to work successfully, I'd love to hear about it, and to try to understand what the current blockers on this feature. Thanks for any advice, Colin

Dec. 30, 2008

Re: Wine on Windows - wiki notes

by Roderick Colenbrander

> Wine on Windows is an idea of real-world usefulness, as newer versions > of Microsoft Windows increasingly fail to support apps Wine still > supports. > > I've started a wiki page: http://wiki.winehq.org/WineOnWindows > > This covers my experiments with the three main POSIX layers (Cygwin, > MinGW and Interix) on XPsp3. > > Various people have told me they've got it to work before (native > compilation and install on Windows), but I seem to be the one > gathering data :-) If anyone who's done it could please (a) put there > what they did with what versions of Wine and tools (b) check with > current Wine, that would be most appreciated. > > > - d. > Cygwin/Mingw doesn't work due to missing functionality for wineserver I believe (not sure what). Someone recently claimed that he indeed had wine working on Interix on a 32-bit WinXP. Right now he was trying to compile it on a 64-bit Windows but had all sorts of troubles. For instance there is some define for ELF stuff which he had to disable. He didn't succeed in compiling it and I have doubts that he succeeded before but Interix looks the most promosing of the options right now. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 30, 2008

Wine 1.0 "one of the great Linux innovations of 2008"

by Dan Kegel

http://www.phoronix.com/scan.php?page=article&item=great_linux_innovations_… "WINE 1.0: When the WINE project began as a compatibility layer to run Windows programs atop Linux, the Windows 3.1 operating system was dominating the market. It took fifteen years for this free software project to come out with a version 1.0 release, but it reached this milestone in June. WINE now is able to run many Windows programs out there, and even many OpenGL / DirectX video games, but the development community has been continuing in a steadfast manner working to prepare the WINE 1.2 stable release for next year. WINE is now even being used by Google for their Picasa Linux port as well as other uses. Some of the progress that's been made this year following the 1.0 release has been support for Google Chrome, substantial JS support, X11 desktop work areas, the start of Direct3D 10.0 support, improved memory management, and many other features."

Dec. 30, 2008

Wine on Windows - wiki notes

by David Gerard

Wine on Windows is an idea of real-world usefulness, as newer versions of Microsoft Windows increasingly fail to support apps Wine still supports. I've started a wiki page: http://wiki.winehq.org/WineOnWindows This covers my experiments with the three main POSIX layers (Cygwin, MinGW and Interix) on XPsp3. Various people have told me they've got it to work before (native compilation and install on Windows), but I seem to be the one gathering data :-) If anyone who's done it could please (a) put there what they did with what versions of Wine and tools (b) check with current Wine, that would be most appreciated. - d.

Dec. 30, 2008

Re: Wine Gecko packaging

by Jacek Caban

Mike Frysinger wrote: > actually, why not add a simple configure check ? if the .cab exists > but is > too old, abort. package maintainers will figure things out real quick :). > We can't do this, we don't have compile-time dependency on Gecko, so configure script doesn't know about it. Jacek

Dec. 30, 2008

Re: Wine Gecko packaging

by Mike Frysinger

On Tuesday 30 December 2008 13:24:27 Jacek Caban wrote: > Now that we have a new Gecko, the work isn't done yet. All packages have > to be updated. Wine can use only the new version now, so if a package > contains an older version, it won't work and Gecko installer will be > used instead. The update is as simple as providing the new file instead > of the old one, so I believe it's not too much work. Note that for older > Wine versions, older Gecko must be used. actually, why not add a simple configure check ? if the .cab exists but is too old, abort. package maintainers will figure things out real quick :). -mike

Dec. 30, 2008

Re: Wine Gecko packaging

by Mike Frysinger

On Tuesday 30 December 2008 13:24:27 Jacek Caban wrote: > The problem is that we don't have a way to inform all packagers about > updates (not all of them follow wine-devel) and it would be nice to have > a communication channel so future releases won't have such problems. > Austin suggested announcing on wine-announce. There are only a few > people interested, so I could have a list of e-mail address or a Wiki > page with e-mail addresses of interested people and send announcement > e-mail directly. Please let me know, what works better. sf already has a notification process for updates ... i use that personally. i think debian/ubuntu have an automated way of checking updates with upstream packages ? -mike

Dec. 30, 2008

Re: [1/2] mshtml: Rename stucture to avoid name clash

by Jacek Caban

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > HTMLStyle clashes with one defined in the mshtml.h > > Changelog: > mshtml: Rename stucture to avoid name clash There is no need for renaming. I've sent a patch that fixes the clash. Jacek

Dec. 30, 2008

Re: d3d9: Use the correct size for D3DFVF_XYZW [try 2]

by Henri Verbeet

2008/12/30 Stefan Dösinger <stefan(a)codeweavers.com>: > we have a similar, but not quite the same, routine in wined3d too, I think > in device.c. It creates a wined3d vertex declaration from a FVF, while the > d3d9 one creates a d3d9 declaration. Can you see if the wined3d routine is > affected too? > That's commit f197e8b1ca0662c32444741112b27cc98038e2ba. > I didn't unify the wined3d and d3d9 code because we'd need need some > wined3d->d3d9 decl backwards conversion which is probably as bug prone and > maintainance heavy as an almost-clone of the FVF->decl conversion routine, > and I dislike the idea of creating a d3d9 decl in wined3d. If anyone has a > nice solution for this feel free to suggest it. > ConvertFvfToDeclaration() returns an array of WINED3DVERTEXELEMENT. Converting from WINED3DVERTEXELEMENT to D3DVERTEXELEMENT is trivial.

Dec. 30, 2008

RE: d3d9: Use the correct size for D3DFVF_XYZW [try 2]

by Stefan Dösinger

we have a similar, but not quite the same, routine in wined3d too, I think in device.c. It creates a wined3d vertex declaration from a FVF, while the d3d9 one creates a d3d9 declaration. Can you see if the wined3d routine is affected too? I didn't unify the wined3d and d3d9 code because we'd need need some wined3d->d3d9 decl backwards conversion which is probably as bug prone and maintainance heavy as an almost-clone of the FVF->decl conversion routine, and I dislike the idea of creating a d3d9 decl in wined3d. If anyone has a nice solution for this feel free to suggest it. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Chris Robinson > Sent: Sunday, December 28, 2008 6:59 PM > To: wine-patches(a)winehq.org > Subject: d3d9: Use the correct size for D3DFVF_XYZW [try 2] > > Now with a test.

Dec. 30, 2008

Wine Gecko packaging

by Jacek Caban

Hi, Now that we have a new Gecko, the work isn't done yet. All packages have to be updated. Wine can use only the new version now, so if a package contains an older version, it won't work and Gecko installer will be used instead. The update is as simple as providing the new file instead of the old one, so I believe it's not too much work. Note that for older Wine versions, older Gecko must be used. The problem is that we don't have a way to inform all packagers about updates (not all of them follow wine-devel) and it would be nice to have a communication channel so future releases won't have such problems. Austin suggested announcing on wine-announce. There are only a few people interested, so I could have a list of e-mail address or a Wiki page with e-mail addresses of interested people and send announcement e-mail directly. Please let me know, what works better. I know about followed affected packages: - Gentoo ebuild I've CCed maintainer. - Ubuntu package - Mandriva Marco was recently interested in providing a package - winetricks BTW, Dan, I think it's a good idea to have a Gecko option, but people should learn about http://wiki.winehq.org/Gecko if possible instead of depending on winetricks to do something that we already have implemented in Wine. I don't know about other distros, so please let me know if I've missed something. Thanks, Jacek

Dec. 30, 2008

Please add glut to winetricks :)

by Michel Briand

Hi Dan, I found winetricks very helpful ! Thank you for this very nice script ;). Could you please add glut [1] to the packages winetricks knows about ? Thank you very much, Michel [1] http://www.opengl.org/resources/libraries/glut/glut_downloads.php

Dec. 30, 2008

Wine Gecko packaging

by Jacek Caban

Hi, Now that we have a new Gecko, the work isn't done yet. All packages have to be updated. Wine can use only the new version now, so if a package contains an older version, it won't work and Gecko installer will be used instead. The update is as simple as providing the new file instead of the old one, so I believe it's not too much work. Note that for older Wine versions, older Gecko must be used. The problem is that we don't have a way to inform all packagers about updates (not all of them follow wine-devel) and it would be nice to have a communication channel so future releases won't have such problems. Austin suggested announcing on wine-announce. There are only a few people interested, so I could have a list of e-mail address or a Wiki page with e-mail addresses of interested people and send announcement e-mail directly. Please let me know, what works better. I know about followed affected packages: - Gentoo ebuild I've CCed maintainer. - Ubuntu package - Mandriva Marco was recently interested in providing a package - winetricks BTW, Dan, I think it's a good idea to have a Gecko option, but people should learn about http://wiki.winehq.org/Gecko if possible instead of depending on winetricks to do something that we already have implemented in Wine. I don't know about other distros, so please let me know if I've missed something. Thanks, Jacek

Dec. 30, 2008

Re: 260 tests passing on win64!

by Alexandre Julliard

Alexandre Julliard <julliard(a)winehq.org> writes: > "Dan Kegel" <dank(a)kegel.com> writes: > >> Ladies and gentlemen, I believe it's time >> for a 64 bit winetest.exe to be added to the daily build, >> and for 64 bit test data to start showing up at http://test.winehq.org. > > I'm working on that. I haven't uploaded the results but the current > status is that there are about 60 more failing tests on Vista 64-bit > compared to 32-bit. The 64-bit winetest.exe is now built on WineHQ along with the 32-bit one. You can get the latest build at: http://test.winehq.org/builds/winetest64-latest.exe Please give it a try if you have a 64-bit Windows box. -- Alexandre Julliard julliard(a)winehq.org

Dec. 30, 2008

Re: [1/2] mshtml: Rename stucture to avoid name clash

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > static HRESULT WINAPI HTMLStyle_QueryInterface(IHTMLStyle *iface, REFIID riid, void **ppv) > { > - HTMLStyle *This = HTMLSTYLE_THIS(iface); > + HStyle *This = HTMLSTYLE_THIS(iface); A name like IHTMLStyleImpl would be a better choice. -- Alexandre Julliard julliard(a)winehq.org

Dec. 30, 2008

Re: Henri Verbeet : secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW().

by Christian Costa

Detlef Riekenberg a écrit : > On Mo, 2008-12-29 at 19:21 +0100, Christian Costa wrote: > > >> Compilation failed here (FC8), I got this error : >> >> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 >> -o >> schannel.o schannel.c >> schannel.c:61: erreur: ‘gnutls_mac_get_key_size’ undeclared here (not >> in >> a function) >> schannel.c:61: attention : type defaults to ‘int’ in declaration of >> ‘pgnutls_mac_get_key_size’ >> > > > Same here: > libgnutls-dev 2.04 on ubuntu 8.04 > > > It seems this function appeared in 2.2.0. I have a 1.6.3.

Dec. 30, 2008

Re: configure.ac: fix libpng detection on OpenBSD

by Vitaly Lipatov

В сообщении от 29 декабря 2008 Austin English написал(a): > then > - WINE_CHECK_SONAME(png,png_create_read_struct,,,-lm,[[libpng[[0-9]]*]]) > + WINE_CHECK_SONAME(png,png_create_read_struct,,,-lm > -lz,[[libpng[[0-9]]*]]) fi If libpng uses libz, package maintainer have to link it with libz, I do not sure we have to make workaround for libpng packaging bug. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 30, 2008

Re: [PATCH 2/2] mshtml: Wine Gecko 0.9.0 release.

by Jacek Caban

Dan Kegel wrote: > Doesn't build here, did you forget mutation.c? > Thanks, I've sent a complete version. Jacek

Dec. 29, 2008

Re: Henri Verbeet : secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW().

by Austin English

On Mon, Dec 29, 2008 at 10:17 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > On Mo, 2008-12-29 at 19:21 +0100, Christian Costa wrote: > >> Compilation failed here (FC8), I got this error : >> >> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >> -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 >> -o >> schannel.o schannel.c >> schannel.c:61: erreur: 'gnutls_mac_get_key_size' undeclared here (not >> in >> a function) >> schannel.c:61: attention : type defaults to 'int' in declaration of >> 'pgnutls_mac_get_key_size' > > > Same here: > libgnutls-dev 2.04 on ubuntu 8.04 > > > -- > > By by ... Detlef > > > > > Also breaks on OpenBSD 4.4, gnutls 2.0.4. -- -Austin

Dec. 29, 2008

re: [PATCH 2/2] mshtml: Wine Gecko 0.9.0 release.

by Dan Kegel

Doesn't build here, did you forget mutation.c? make depend fails with: mutation.c: No such file or directory make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dank/wine-git/dlls/mshtml'

Dec. 29, 2008

Re: Henri Verbeet : secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW().

by Detlef Riekenberg

On Mo, 2008-12-29 at 19:21 +0100, Christian Costa wrote: > Compilation failed here (FC8), I got this error : > > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 > -o > schannel.o schannel.c > schannel.c:61: erreur: ‘gnutls_mac_get_key_size’ undeclared here (not > in > a function) > schannel.c:61: attention : type defaults to ‘int’ in declaration of > ‘pgnutls_mac_get_key_size’ Same here: libgnutls-dev 2.04 on ubuntu 8.04 -- By by ... Detlef

Dec. 29, 2008

Re: oleaut32: Correct the printf placeholder types.

by Austin English

On Mon, Dec 29, 2008 at 2:49 PM, Danny Rawlins <monster.romster(a)gmail.com> wrote: > Fix between unsigned and signed types this is my first wine patch but > you may already know me in irc as <Romster>. > > Also I don't find any -W compiler option to warn against incorrect > placeholders like using a int for a string. > > Thanks to <arethusa> for help, I am still learning C but have patched > many programs. > > Regards, > Danny Rawlins > > > > I think you want to use: CFLAGS="-Wsign-compare" -- -Austin

Dec. 29, 2008

Re: Henri Verbeet : secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW().

by Christian Costa

Hi, Compilation failed here (FC8), I got this error : gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o schannel.o schannel.c schannel.c:61: erreur: ‘gnutls_mac_get_key_size’ undeclared here (not in a function) schannel.c:61: attention : type defaults to ‘int’ in declaration of ‘pgnutls_mac_get_key_size’ schannel.c: In function ‘schan_QueryContextAttributesW’: schannel.c:856: erreur: called object ‘pgnutls_mac_get_key_size’ is not a function make[2]: *** [schannel.o] Erreur 1 Christian Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 95fd8762665e65fedf7e2ede43e657f123dc4535 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=95fd8762665e65fedf7e2ede4… > > Author: Henri Verbeet <hverbeet(a)gmail.com> > Date: Sun Dec 28 22:21:35 2008 +0100 > > secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW(). > > --- > > dlls/secur32/schannel.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 64 insertions(+), 0 deletions(-) > > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index df5d56a..ed583d4 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -48,6 +48,7 @@ MAKE_FUNCPTR(gnutls_alert_get); > MAKE_FUNCPTR(gnutls_alert_get_name); > MAKE_FUNCPTR(gnutls_certificate_allocate_credentials); > MAKE_FUNCPTR(gnutls_certificate_free_credentials); > +MAKE_FUNCPTR(gnutls_cipher_get); > MAKE_FUNCPTR(gnutls_credentials_set); > MAKE_FUNCPTR(gnutls_deinit); > MAKE_FUNCPTR(gnutls_global_deinit); > @@ -56,6 +57,8 @@ MAKE_FUNCPTR(gnutls_global_set_log_function); > MAKE_FUNCPTR(gnutls_global_set_log_level); > MAKE_FUNCPTR(gnutls_handshake); > MAKE_FUNCPTR(gnutls_init); > +MAKE_FUNCPTR(gnutls_mac_get); > +MAKE_FUNCPTR(gnutls_mac_get_key_size); > MAKE_FUNCPTR(gnutls_perror); > MAKE_FUNCPTR(gnutls_set_default_priority); > MAKE_FUNCPTR(gnutls_transport_set_errno); > @@ -800,14 +803,69 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextA( > return ret; > } > > +static unsigned int schannel_get_cipher_block_size(gnutls_cipher_algorithm_t cipher) > +{ > + const struct > + { > + gnutls_cipher_algorithm_t cipher; > + unsigned int block_size; > + } > + algorithms[] = > + { > + {GNUTLS_CIPHER_3DES_CBC, 8}, > + {GNUTLS_CIPHER_AES_128_CBC, 16}, > + {GNUTLS_CIPHER_AES_256_CBC, 16}, > + {GNUTLS_CIPHER_ARCFOUR_128, 1}, > + {GNUTLS_CIPHER_ARCFOUR_40, 1}, > + {GNUTLS_CIPHER_DES_CBC, 8}, > + {GNUTLS_CIPHER_NULL, 1}, > + {GNUTLS_CIPHER_RC2_40_CBC, 8}, > + }; > + unsigned int i; > + > + for (i = 0; i < sizeof(algorithms) / sizeof(*algorithms); ++i) > + { > + if (algorithms[i].cipher == cipher) > + return algorithms[i].block_size; > + } > + > + FIXME("Unknown cipher %#x, returning 1\n", cipher); > + > + return 1; > +} > + > static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > PCtxtHandle context_handle, ULONG attribute, PVOID buffer) > { > + struct schan_context *ctx; > + > TRACE("context_handle %p, attribute %#x, buffer %p\n", > context_handle, attribute, buffer); > > + if (!context_handle) return SEC_E_INVALID_HANDLE; > + ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + > switch(attribute) > { > + case SECPKG_ATTR_STREAM_SIZES: > + { > + SecPkgContext_StreamSizes *stream_sizes = (SecPkgContext_StreamSizes *)buffer; > + gnutls_mac_algorithm_t mac = pgnutls_mac_get(ctx->session); > + size_t mac_size = pgnutls_mac_get_key_size(mac); > + gnutls_cipher_algorithm_t cipher = pgnutls_cipher_get(ctx->session); > + unsigned int block_size = schannel_get_cipher_block_size(cipher); > + > + TRACE("Using %zu mac bytes, block size %u\n", mac_size, block_size); > + > + /* These are defined by the TLS RFC */ > + stream_sizes->cbHeader = 5; > + stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbMaximumMessage = 1 << 14; > + stream_sizes->cbBuffers = 4; > + stream_sizes->cbBlockSize = block_size; > + return SEC_E_OK; > + } > + > default: > FIXME("Unhandled attribute %#x\n", attribute); > return SEC_E_UNSUPPORTED_FUNCTION; > @@ -822,6 +880,9 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesA( > > switch(attribute) > { > + case SECPKG_ATTR_STREAM_SIZES: > + return schan_QueryContextAttributesW(context_handle, attribute, buffer); > + > default: > FIXME("Unhandled attribute %#x\n", attribute); > return SEC_E_UNSUPPORTED_FUNCTION; > @@ -961,6 +1022,7 @@ void SECUR32_initSchannelSP(void) > LOAD_FUNCPTR(gnutls_alert_get_name) > LOAD_FUNCPTR(gnutls_certificate_allocate_credentials) > LOAD_FUNCPTR(gnutls_certificate_free_credentials) > + LOAD_FUNCPTR(gnutls_cipher_get) > LOAD_FUNCPTR(gnutls_credentials_set) > LOAD_FUNCPTR(gnutls_deinit) > LOAD_FUNCPTR(gnutls_global_deinit) > @@ -969,6 +1031,8 @@ void SECUR32_initSchannelSP(void) > LOAD_FUNCPTR(gnutls_global_set_log_level) > LOAD_FUNCPTR(gnutls_handshake) > LOAD_FUNCPTR(gnutls_init) > + LOAD_FUNCPTR(gnutls_mac_get) > + LOAD_FUNCPTR(gnutls_mac_get_key_size) > LOAD_FUNCPTR(gnutls_perror) > LOAD_FUNCPTR(gnutls_set_default_priority) > LOAD_FUNCPTR(gnutls_transport_set_errno) > > > > > >

Dec. 29, 2008

Re: [6/6] secur32: Implement schannel DecryptMessage().

by Henri Verbeet

2008/12/29 Rob Shearman <robertshearman(a)gmail.com>: > Is it really expected for gnutls_record_recv to return GNUTLS_E_AGAIN > on the first call and for the code to have to return that to the > caller? That is what the code as it is at the moment does. It seems to > me as though you should return SEC_E_INCOMPLETE_MESSAGE if you > decrypted all of the data in the supplied buffer, but gnutls still > returns GNUTLS_E_AGAIN. That then signals to the app to download more > data and call DecryptMessage() again with the new data. > No, gnutls_record_recv() is only supposed to return GNUTLS_E_AGAIN when schan_pull() can't find any more data to read (ie, once we've read data from all the relevant buffers in the buffer desc) and the record it's decryping is still incomplete.

Dec. 29, 2008

Re: [6/6] secur32: Implement schannel DecryptMessage().

by Rob Shearman

Sorry, this should have been in reply to patch [6/6]. 2008/12/29 Henri Verbeet <hverbeet(a)gmail.com>: > 2008/12/29 Rob Shearman <robertshearman(a)gmail.com>: >> 2008/12/28 Henri Verbeet <hverbeet(a)gmail.com>: >>> + while (received < data_size) >>> + { >>> + ret = pgnutls_record_recv(ctx->session, data + received, data_size - received); >>> + if (ret < 0) >>> + { >>> + if (ret == GNUTLS_E_AGAIN) >>> + { >>> + if (!received) >> >> Shouldn't this be "if (received == data_size)"? >> >>> + { >>> + pgnutls_perror(ret); >>> + HeapFree(GetProcessHeap(), 0, data); >>> + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); >>> + return SEC_E_INCOMPLETE_MESSAGE; >>> + } >>> + break; >>> + } >>> + else >>> + { >>> + pgnutls_perror(ret); >>> + HeapFree(GetProcessHeap(), 0, data); >>> + ERR("Returning SEC_E_INTERNAL_ERROR\n"); >>> + return SEC_E_INTERNAL_ERROR; >>> + } >>> + } >>> + received += ret; >>> + } >> > The idea was to only return SEC_E_INCOMPLETE_MESSAGE if there's less > than one complete TLS record in the buffer, it shouldn't be a problem > to have eg. one complete message plus some bytes from the next one, > setting the buffer size further down is supposed to take care of that. Is it really expected for gnutls_record_recv to return GNUTLS_E_AGAIN on the first call and for the code to have to return that to the caller? That is what the code as it is at the moment does. It seems to me as though you should return SEC_E_INCOMPLETE_MESSAGE if you decrypted all of the data in the supplied buffer, but gnutls still returns GNUTLS_E_AGAIN. That then signals to the app to download more data and call DecryptMessage() again with the new data. -- Rob Shearman

Dec. 29, 2008

Re: [5/6] secur32: Implement schannel EncryptMessage().

by Henri Verbeet

2008/12/29 Rob Shearman <robertshearman(a)gmail.com>: > 2008/12/28 Henri Verbeet <hverbeet(a)gmail.com>: >> + while (received < data_size) >> + { >> + ret = pgnutls_record_recv(ctx->session, data + received, data_size - received); >> + if (ret < 0) >> + { >> + if (ret == GNUTLS_E_AGAIN) >> + { >> + if (!received) > > Shouldn't this be "if (received == data_size)"? > >> + { >> + pgnutls_perror(ret); >> + HeapFree(GetProcessHeap(), 0, data); >> + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); >> + return SEC_E_INCOMPLETE_MESSAGE; >> + } >> + break; >> + } >> + else >> + { >> + pgnutls_perror(ret); >> + HeapFree(GetProcessHeap(), 0, data); >> + ERR("Returning SEC_E_INTERNAL_ERROR\n"); >> + return SEC_E_INTERNAL_ERROR; >> + } >> + } >> + received += ret; >> + } > The idea was to only return SEC_E_INCOMPLETE_MESSAGE if there's less than one complete TLS record in the buffer, it shouldn't be a problem to have eg. one complete message plus some bytes from the next one, setting the buffer size further down is supposed to take care of that.

Dec. 29, 2008

Re: [5/6] secur32: Implement schannel EncryptMessage().

by Rob Shearman

2008/12/28 Henri Verbeet <hverbeet(a)gmail.com>: > + while (received < data_size) > + { > + ret = pgnutls_record_recv(ctx->session, data + received, data_size - received); > + if (ret < 0) > + { > + if (ret == GNUTLS_E_AGAIN) > + { > + if (!received) Shouldn't this be "if (received == data_size)"? > + { > + pgnutls_perror(ret); > + HeapFree(GetProcessHeap(), 0, data); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } > + break; > + } > + else > + { > + pgnutls_perror(ret); > + HeapFree(GetProcessHeap(), 0, data); > + ERR("Returning SEC_E_INTERNAL_ERROR\n"); > + return SEC_E_INTERNAL_ERROR; > + } > + } > + received += ret; > + } -- Rob Shearman

Dec. 29, 2008

re: New Wine Gecko

by Dan Kegel

Thanks, Jacek, we're really looking forward to it!

Dec. 28, 2008

New Wine Gecko

by Jacek Caban

Hi, As there will be a new Gecko release soon, I'd like to give you a good background over what's going on as I feel that there is some misunderstanding on it that I'd like to clarify. I'm sorry for the long mail. First, let me give you a short history of the Gecko package. As we started using Gecko in our MSHTML implementation, we had to provide our own package and an easy way for its installation. I've prepared a package that actually was a temporary solution. It was a SeaMonkey build that had some files manually removed and modified to reduce its size. It was, of course, hacky and ugly but, as there was no urgent need for changing it, we used it for over a year. The next version was built by me. The build process was long and ugly - it needed a Windows installation and MSVC6. Except that I had to try many versions before finding one that worked fine for Wine, as it had both to compile with MSVC6 (back then they were switching to a newer compiler that needed actctx) and work with Wine (there were a few APIs that were not implemented in Wine that they started using). Also, there was the XULRunner project that looked promising but proved to not be good enough for us. I ended up with building the SeaMonkey target and, again, modifying and removing some files afterwards. Now, not only because of CS4 but because we really should follow new Gecko versions as well, the time to release a new package has come. The first decision was to try again by building with MinGW on Windows. I've tried it with limited success and then I found that Mozilla developers have recently worked on building Mozilla with MinGW under Linux (for code analyzers). That was something I hoped to do some day, so I gave it a try and it came out that it works better than compiling on Windows! Also XULRunner project has matured so that we may use it, avoiding other pains from previous packages. But not all is so good. Some changes introduced in the recent Gecko have prevented Wine from working correctly. It was unnoticed for long time because we were using the 1.8 branch, while the newest is 1.9. Because of it, I had to add serious patches (previous build had only minor changes in code) to fix it. I'm working with Mozilla developers to get these patches to official Gecko. We definitely want to avoid maintaining such differences. There are other advantages that will come with the new Gecko. I'm going to make a debug build that seems to work really well on Wine. Although it causes an assert in dbghelp that I didn't look at deeper, for one build I was even able to step through Gecko code with winedbg. Hopefully Valgrind will be happy with it. Also, I'm going to put the code to Git and provide a good building instruction. It's not trivial to build the package, but hopefully with some efforts everyone will be able to succeed with it. In this place I'd like to note: if you're not planning to work on Gecko (I mean not even MSHTML, but Gecko itself), there is no reason to do it. Also I know that some package maintainers would be interested in building it. Please, don't do it! You will realize that it is not possible with a fresh Linux installation without manually setting up environment. Also, due to its complexity, I'm worried about broken builds. I don't really see the reason to do it. If it's a matter of trust policy... well, you've trusted my builds for over three years now, so I'd like to ask you to keep trusting me... Also, I didn't really have a clear idea about version numbering. The first, temporary, package was numbered 0.0.1. The next one was 0.1.0 with plans to release 0.1.x if we'd release a new package on the same code base (there was 0.1.1 candidate that was never released). My plan was to release a package compiled under Linux as 1.0.0, and until then release next 0.x.y builds. Now that we compile the new package on Linux, I still don't like to call it 1.0.0, because of patches needed in our build. I'd prefer to wait with 1.0.0 hoping to fix the difference for next major release. I don't feel strongly about it so if anyone has any suggestion, I'm happy to change the plan. I plan to put Wine Gecko code into a public Git so developing it will be easier. Now releasing a new version should be much easier (as long as we won't find a new blocker, but if we'll find it quicker, it will be easier to fix). I'm happy with releasing the build I've written about a few days ago. I got feedback from Mozilla developer about things we could get to Mozilla tree and I'm going to try to get some patches to Mozilla. That shouldn't delay our release IMO, so I'm going to release tomorrow unless there are any objections. I hope to have another release in a few months that well be closer to main stream Gecko. Please let me know if you have any suggestion or question. Thanks, Jacek

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Dan Kegel

Louis wrote: > Wine needs a dxdiag.exe as some apps expect it to be present, > like for example GameShadow. I once gave it a shot already, see > http://bugs.winehq.org/show_bug.cgi?id=14118 Thanks for the link. I refreshed your patch, and also added in the parsing for the commandline options used by GameShadow. That game needs a lot of overrides, and I never got it to run far enough to check the output of dxdiag. Does anyone know of other apps that require dxdiag.exe (as opposed to dxdiagn.dll)? - Dan

Dec. 28, 2008

Re: [PATCH 5/6] dinput: Fix usage of HeapReAlloc.

by Vitaliy Margolen

Alexandre Julliard wrote: > While you are fixing it you should fix it properly by preserving the old > pointer on failure. > Thanks. Sent fixed patch. Vitaliy

Dec. 28, 2008