February 2011 - Wine-Devel - list.winehq.org

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Matteo Bruni

2011/1/31 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am 31.01.2011 um 17:08 schrieb Matteo Bruni: >> The attached patch should follow your idea, does it look right? FWIW, >> I can't see any 1-pixel offset in The Sims 3 with this patch. Yes, I >> know that's not how it should be tested... > Looks OK on first sight. Does it work as well? > It seems to work. :) > I can't think of any game where you could see a half pixel issue wrt clipplanes. Maybe the d3d7 clipping example can shows something, but I think to be sure you'd have to write a test. > Is the test I attached a good way to check for that? I could send this test to wine-patches too (or a fixed version if it happens to be broken).

Feb. 2, 2011

Re: Wine FAQ edits

by Rosanne DiMesio

On Wed, 2 Feb 2011 10:09:16 -0500 Albert Lee <trisk(a)forkgnu.org> wrote: > The Open Group even more strongly objects to the phrase "Unix-like". > They also state explicitly on their website that Linux is not Unix. http://www.unix.org/what_is_unix/flavors_of_unix.html Ozan's suggestion of "Posix-compatible" is more accurate. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Qian Hong

On Wed, Feb 2, 2011 at 11:08 PM, Dan Kegel <dank(a)kegel.com> wrote: > Qian wrote: >>1. If a function is implemented in wine dll as a stup, then usually >>this function won't cause crash, >>and the wine debug will output "fix:me ...stup" rather then >>"Unimplemented function", is it right? > > I think "stub" is somewhat ambiguous, it can mean either > something without an implementation, or something > with a very minimal implementation. > But yes, if something is listed in dlls/*/*.spec as a stub, > you get 'Unimplemented function', and if something is listed in > grep FIXME.*stub dlls/*/*.c > as a stub, you get > "fixme: ... stub". > Thanks very much! I think now I understand. Thanks Ricardo as well. Grateful to you all! >>2. If a function is listed in the Wine API guide, >>http://source.winehq.org/WineAPI/ , and marked as stup, >>then this function must be implemented as a stup in wine source code, >>is it right? > > The Wine API guide is not a very reliable guide, it might be out > of date. Better to just look in the source code. > - Dan > -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Feb. 2, 2011

Re: Wine FAQ edits

by Albert Lee

I notice you reverted the changes after I addressed these issues, care to explain why? On Tue, Feb 1, 2011 at 11:47 PM, Albert Lee <trisk(a)forkgnu.org> wrote: > On Sat, Jan 29, 2011 at 4:36 PM, Vitaliy <vitaliy(a)kievinfo.com> wrote: >> On 01/29/2011 12:21 PM, Dan Kegel wrote: >>> >>> Hi Albert, >>> http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks >>> like it was a pretty big edit. >>> >>> Try smaller ones, and try to do just one kind of change per edit. >> >> That, and the fact that some changes where questionable, and broken: >> >>> -cd ~/.wine/drive_c/Program\ Files >>> +cd .wine/drive_c/Program\ Files >> >> This will break if current directory is not $HOME. >> > > 'cd' immediately precedes this. > >>> - You can also use double quotes, but you need two backslashes instead of >>> one: >>> - >>> -{{{ >>> -wine start "C:\\Games\\Tron\\tron.exe" >>> -}}} >> >> Backslashes still have special meaning inside double quotes. So they should >> be escaped. > > Yes, I'll fix this. > >> >>> -/bin/sh -c glxgears >>> +/usr/bin/env glxgears >> >> What advantage does "env" has over full featured shell? This is unnecessary. > > Why do you need a full shell to run a single external program? It > complicates e.g. argument passing if you used this as a template. > >> >>> -@="/bin/sh run_linx_program acroread \"%1\"" >>> +@="/bin/sh -c \"acroread `wine winepath -u '%1'`\"" >> >> Have you actually tested this? This won't work for paths with spaces. If it >> will work at all. >> > > Not with spaces, I'll fix this as well. > > -Albert >

Feb. 2, 2011

Re: Wine FAQ edits

by Albert Lee

On Wed, Feb 2, 2011 at 8:03 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Sat, 29 Jan 2011 13:18:40 -0500 > Albert Lee <trisk(a)forkgnu.org> wrote: > >> >> I notice you have reverted my edits to the FAQ on the wiki ( >> http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify >> the shell metacharacter information and operating system/platform >> support, and add new file association instructions, I would like to >> know why this happened and what changes should be done. >> > Albert, > > Besides the problems Vitaliy has pointed out with your edits, your repeated attempts to substitute "Unix" for "Linux" in multiple places is flat-out wrong. "Unix" is a trademarked name, with a specific meaning. It is not a generic synonym for Linux, BSD, etc. and should not be used as such. > While "UNIX" is a trademark for Open Group certification, it has long existed as a generic term in engineering and academia to refer to the to set of standards that define systems with this heritage, and where these are being referred to it is much better than listing the implementations (and Wine does run on "UNIX" certified platforms). The Open Group even more strongly objects to the phrase "Unix-like". -Albert

Feb. 2, 2011

re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Dan Kegel

Qian wrote: >1. If a function is implemented in wine dll as a stup, then usually >this function won't cause crash, >and the wine debug will output "fix:me ...stup" rather then >"Unimplemented function", is it right? I think "stub" is somewhat ambiguous, it can mean either something without an implementation, or something with a very minimal implementation. But yes, if something is listed in dlls/*/*.spec as a stub, you get 'Unimplemented function', and if something is listed in grep FIXME.*stub dlls/*/*.c as a stub, you get "fixme: ... stub". >2. If a function is listed in the Wine API guide, >http://source.winehq.org/WineAPI/ , and marked as stup, >then this function must be implemented as a stup in wine source code, >is it right? The Wine API guide is not a very reliable guide, it might be out of date. Better to just look in the source code. - Dan

Feb. 2, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Ken Thomases

On Feb 1, 2011, at 10:19 AM, Juan Lang wrote: > I may be flogging a dead horse here, but I personally am loath to see > another implementation creep in, side by side with the existing one, > that has no guarantee of working any better. Well, it won't work any better, just as well as. > I don't see how this > helps CodeWeavers, either, other than reducing installation > complexity. Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does. > If there are bugs in the new implementation, and I expect > there will be, you'll still have a large support load. Worse, even if > you succeed in fixing bugs for your Mac customers, the rest of us > don't benefit, as the current implementation still isn't getting any > support. That's not true. First, if there are bugs that affect our products, it will likely affect both our Linux and Mac products, and we'd fix it in both. But more to the point, as I've said before, the schan_imp_* stuff is a very, very thin wrapper around the platform library (Secure Transport on the Mac and GnuTLS elsewhere). It is quite unlikely that the sorts of bugs you're concerned about -- in the logic of schannel -- would be in the platform-specific code. They'd be in the code that's shared. So, the fixes would be shared, too. > If there are development resources available to work on > schannel, why not put them into something that benefits the project as > a whole? Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that. For us, it's largely to meet customer needs. This work did that. The work you describe doesn't, particularly. It may, someday. It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it. (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.) Lots of work contributed to Wine doesn't benefit everybody, but only improves things for one particular use case. It's still an improvement to the project as a whole, even if most don't receive the benefit. Regards, Ken

Feb. 2, 2011

Re: Wine FAQ edits

by Rosanne DiMesio

On Sat, 29 Jan 2011 13:18:40 -0500 Albert Lee <trisk(a)forkgnu.org> wrote: > > I notice you have reverted my edits to the FAQ on the wiki ( > http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify > the shell metacharacter information and operating system/platform > support, and add new file association instructions, I would like to > know why this happened and what changes should be done. > Albert, Besides the problems Vitaliy has pointed out with your edits, your repeated attempts to substitute "Unix" for "Linux" in multiple places is flat-out wrong. "Unix" is a trademarked name, with a specific meaning. It is not a generic synonym for Linux, BSD, etc. and should not be used as such. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Ricardo Filipe

2011/2/2 Qian Hong <fracting(a)gmail.com> > Dear Nikolay and James, > > On Sun, Jan 30, 2011 at 11:09 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: > > Qian: > > > > I would like to echo Nikolay's comment and add one more: > > > > Please search through the Bug Reports before submitting a new one. > > I really feel very sorry, I apologize for posting such issues the > wrong place and making noise. Thank you for your reminder and your > nice work on wine. > I have searched the Bugzilla with ntoskrnl.exe as keyword carefully, > it seems that none of the current bugs mentions unimplemented function > ntoskrnl.exe.IoGetDeviceInterfaces, so I report a new issue here: > http://bugs.winehq.org/show_bug.cgi?id=25964 > Wish it not a duplicate. > > > > > You might receive more assistance on the Wine User list as well. Most of > > the developers lurk there. > > > > I'll post such mails on the Wine User list from now on. > However, may I modestly consults below questions here: > > 1. If a function is implemented in wine dll as a stup, then usually > this function won't cause crash, > and the wine debug will output "fix:me ...stup" rather then > "Unimplemented function", is it right? > 2. If a function is listed in the Wine API guide, > http://source.winehq.org/WineAPI/ , and marked as stup, > then this function must be implemented as a stup in wine source code, > is it right? > > I've read http://wiki.winehq.org/DebugChannels and > http://wiki.winehq.org/Developers-Hints, > but I still have some confusion. > > > Thanks a lot! > > > > Thank you. > > > > > > > -- > Regards, > Qian Hong > - > Sent from Ubuntu > http://www.ubuntu.com/ > > > Yes, a stub is a first step to implement a function. Sometimes a stub is enough for the application to proceed. WineAPI is parsed from wine code, so if it says "stub" in the spec file of that dll it means there is no implementation yet, and a stub can be produced.

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Qian Hong

Dear Nikolay and James, On Sun, Jan 30, 2011 at 11:09 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Qian: > > I would like to echo Nikolay's comment and add one more: > > Please search through the Bug Reports before submitting a new one. I really feel very sorry, I apologize for posting such issues the wrong place and making noise. Thank you for your reminder and your nice work on wine. I have searched the Bugzilla with ntoskrnl.exe as keyword carefully, it seems that none of the current bugs mentions unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, so I report a new issue here: http://bugs.winehq.org/show_bug.cgi?id=25964 Wish it not a duplicate. > > You might receive more assistance on the Wine User list as well. Most of > the developers lurk there. > I'll post such mails on the Wine User list from now on. However, may I modestly consults below questions here: 1. If a function is implemented in wine dll as a stup, then usually this function won't cause crash, and the wine debug will output "fix:me ...stup" rather then "Unimplemented function", is it right? 2. If a function is listed in the Wine API guide, http://source.winehq.org/WineAPI/ , and marked as stup, then this function must be implemented as a stup in wine source code, is it right? I've read http://wiki.winehq.org/DebugChannels and http://wiki.winehq.org/Developers-Hints, but I still have some confusion. Thanks a lot! > Thank you. > -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Feb. 2, 2011