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

Re: wineprefixcreate failing?

by Austin English

On Fri, Feb 22, 2008 at 2:02 PM, Austin English <austinenglish(a)gmail.com> wrote: > > On Thu, Feb 21, 2008 at 12:18 PM, Maarten Lankhorst <crumb(a)google.com> wrote: > > Hi all, > > > > Is it just me or is wineprefixcreate crashing horribly for others as well? > > > > Cheers, > > Maarten. > > > > > > > > > > Are you running ubuntu by chance? Seems to be a bug in Hardy/Gutsy > that may be related to gcc. See: > https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/191575 > > -Austin > I ran a regression test, and got all the way back to wine-0.9.56 without a failure. I was about to book an appointment with a psychiatrist or a bartender, then found that the failure only occurs when calling wine from a different directory. I.e.: austin(a)austin-desktop:~/wine-git$ rm -rf ~/.wine && ~/wine-git/wine notepad # this works fine austin(a)austin-desktop:~$ rm -rf ~/.wine && ~/wine-git/wine notepad # fails So I'm rerunning the tests now. However, thought I'd let everyone know just in case they need a workaround until the problem can be fixed... -Austin

Feb. 22, 2008

Re: WineD3D: request alpha in backbuffer mode, to work correctly with multiple opengl pixel formats

by Stefan Dösinger

Am Freitag, 22. Februar 2008 23:31:43 schrieb Roderick Colenbrander: > Hi, > > In the default backbuffer based renderer in WineD3D the front and > backbuffer share the same pixel format while D3D itself decouples them. A > lot of applications use alpha on the backbuffer, so make sure we have > alpha. This change is needed because the single pixel format which we had > before always had alpha. > + /* In case of ORM_BACKBUFFER, make sure to request an alpha component for X4R4G4B4/X8R8G8B8 as we might need it for the backbuffer. */ It would be for offscreen buffers, not the back buffer. I'm sorry for the confusion in the earlier mail

Feb. 22, 2008

Re: 1/2 WGL: remove the pixel format limitation (!)

by Stefan Dösinger

Am Freitag, 22. Februar 2008 22:10:41 schrieb Stefan Dösinger: > The proper fix is to switch to FBOs for onscreen rendering I meant *off*screen rendering, sorry for the confusion

Feb. 22, 2008

Re: wined3d: ActivateContext: try to fix wrong parameter?

by Stefan Dösinger

Am Freitag, 22. Februar 2008 22:45:23 schrieb Rico Schüller: > I didn't step deep into this problem. So if I could help with some logs > or other things, please let me know. Properly, the real bug is somewhere > else? Did you intend to attach a file to the mail, or did you refer to the last attachment to the bug?

Feb. 22, 2008

Re: Next big app(s) to try?

by Louis Lenders

> By the way, AutoCAD and 3ds max are very popular applications. It's easy to check how they are popular by using Google. For example, for AutoCAD alone > you will get 43,800,000 results [1]. So there is a really a lot of people who > depends on Autodesk products such as AutoCAD. > So I think it's about time to get .Net 2.0 support into wine. Actually all the info is there in bugzilla to get a lot of .net applications running . I know .net support is not a target of wine-1.0.0, but why not reconsider? I got 3dmax 9 somehow running, but it seems to suffer from opengl bug; AutoCad 2008 only made it into the main screeen,then threw up a messagebox about a fatal error. So if someone could pick this up , and fix the remaining .net issues, i think wine could get another boost...........

Feb. 22, 2008

Re: wined3d: ActivateContext: try to fix wrong parameter?

by Rico Schüller

Stefan Dösinger wrote: > What happens if e.g. the current render target is an offscreen target and the > application tries to read back the front or back buffer? In this case you'll > read the offscreen target back. > > So I am not sure this patch is correct I have no idea I just tried a bit around and got cod4 (http://bugs.winehq.org/show_bug.cgi?id=11584) working again with this patch. I didn't step deep into this problem. So if I could help with some logs or other things, please let me know. Properly, the real bug is somewhere else? Cheers Rico

Feb. 22, 2008

Re: 1/2 WGL: remove the pixel format limitation (!)

by Stefan Dösinger

Am Freitag, 22. Februar 2008 21:16:23 schrieb Roderick Colenbrander: > WineD3D has some small issues due to this change but those should be > investigated by Stefan, Chris, me and others. The code should get a lot of > testing as soon as possible. We discussed this on IRC. The problem is that we're still defaulting to back buffer / aux buffer offscreen rendering, and thus offscreen targets are bound to use the same format as the back buffer. In the D3D9 test this means that the backbuffer is X8R8G8B8, and the onscreen target is A8R8G8B8. The alpha is missing with this patch(used to be always there), so the test fails. The proper fix is to switch to FBOs for onscreen rendering whereever possible(FBO support still has problems that prevent that though), and on cards without FBOs try to use A8R8G8B8 instead of X8R8G8B8 for the backbuffer, and similarly for X1R5G5B5 and X4R4G4B4.

Feb. 22, 2008

Re: wineprefixcreate failing?

by Austin English

On Thu, Feb 21, 2008 at 12:18 PM, Maarten Lankhorst <crumb(a)google.com> wrote: > Hi all, > > Is it just me or is wineprefixcreate crashing horribly for others as well? > > Cheers, > Maarten. > > > > Are you running ubuntu by chance? Seems to be a bug in Hardy/Gutsy that may be related to gcc. See: https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/191575 -Austin

Feb. 22, 2008

Re: [Wine] Windows Kernel & Executive implementation

by Volodymyr Shcherbyna

Unfortunately, that code just do stubs, and it is not actually executed in kernel mode. -- with best regards, Volodymyr 2008/2/22, Dan Kegel <dank(a)kegel.com>: > > On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna > <v_scherbina(a)mvps.org> wrote: > > > I discovered that WineHQ project does not have support for drivers (am > I > > wrong?). In other words, quite a big amount of applications will fail > to > > function properly, because many of them are using helper device drivers > to > > get some extended functionality. I can just mention RegMon, FileMon, > TDIMom, > > and others. > > > I know very little about this, but my impression is that > Wine supports a limited set of NT os kernel APIs already. > The initial support was added by this patch: > http://www.winehq.org/pipermail/wine-cvs/2007-May/032546.html > The current set of supported calls can be seen here: > http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c > > Feel free to implement more, or file enhancement requests > describing what nt os apis a popular app needs. > > - Dan >

Feb. 22, 2008

Re: msi: MsiMergeDatabaseA/W stub

by James Hawkins

On Fri, Feb 22, 2008 at 12:32 PM, Johan Dahlin <jdahlin(a)async.com.br> wrote: > James Hawkins wrote: > > On Thu, Feb 21, 2008 at 2:26 PM, Johan Dahlin <jdahlin(a)async.com.br> wrote: > [..] > > > Please use the same style as the rest of the file (4 space > > indentation). The A version should be before the W version. > > It appears that the coding style is different from different dlls, is there > a general agreement how to configure emacs (or any other editors) properly > so it picks up the right coding style for each sub-part of wine? > There are minor variations everywhere, but most of the code uses 4 space indentations. -- James Hawkins

Feb. 22, 2008