wine-devel May 2006

wine-devel@winehq.org

151 participants
288 discussions

Last Call for SoC applications
by Dan Kegel 08 May '06

08 May '06

According to http://code.google.com/soc/studentfaq.html#timeline applications are due in by 5PM PST Monday. That's about 17 hours away. We have just about enough proposals to choose from now, but there's still time for a well-written proposal to be accepted. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Wine regression; app stopped working after 0.9.9
by Herman Bos 08 May '06

08 May '06

Hi, We are using Ambrasoft, a Dutch educational software suite. It currently works on wine 0.9.9. But unfortunately not on later versions. When it just got out I tried wine 0.9.10, but unfortunately Ambrasoft hangs on start up with this release. I was fairly busy but now I'm giving it another shot. Currently using wine 0.9.12 and it doesn't hang however the application reports the following errors: [3][error] [13] in functie [MT6SchoolMenu::Main] Type mismatch --------------------------------------------------------------------------- [2][error] [13] in functie [T6SchoolMenu::MT6SchoolMenu::Init] Type mismatch --------------------------------------------------------------------------- [1][error] [13] in functie [CGroepCollection::Initialize] Type mismatch --------------------------------------------------------------------------- [0][error] [13] in functie [MDBAccess::GetGroepLijst] Type mismatch --------------------------------------------------------------------------- Log string: AmbraSoft.Ini bestand gevonden, Access version (location=M:\Ambrasoft\ provider=Microsoft.Jet.OLEDB.4.0) Schoolpakket 9 The software uses an MS Access database and it looks like it goes bad in that department. I'm not sure how to supply more information. If requested I could build it with debug symbols and backtrace it (although i'm not sure with which parameters). Currently I'm using the ubuntu package from winehq but that probably doesn't matter. The number 1 reason I would like to try this new version is because I noticed improved esd support in the changelog of 0.9.10. I hope it works (we use thinclients that use esd for sound). Any hints/tips/tricks/feedback would be appeciated. Kind regards, Herman Bos

3 2

SoC proposal: shell integration
by Mikołaj Zalewski 07 May '06

07 May '06

I've had an idea for a SoC project and filled the application. In a comment I was advised to discuss it on wine-devel. The idea is to integrate the wine shell32 with the Linux desktops. The main problem is of course that there are many desktop environments and only some things are standardized by freedesktop.org. Even if all is standardised the wine's shell32 might be used on other platforms like MacOS X which, I guess, doesn't comply to freedesktop.org. That's why I think the implementation should allow many implementations of e.g. the trash or MIME database through e.g. COM interfaces. The actual implementation used will be configured by winecfg/registry or (if I will a way to implement it) autodetected. There would be one generic library (e.g. shell32_unix) implementing mainly the freedesktop standards with no dependencies on desktop environments (DE) libraries. If this generic code would integrate badly with a DE then a specific implementation would be provided by specific libraries (e.g. shell32_gnome, shell32_kde) that could link to the DE libraries. Of course if there are no libraries for a specific DE on the host system then the appropriate shell32_* isn't built. I would focus on recent version of KDE and Gnome and I thought of implementing: - The Trash. The freedesktop has a nice standard. It is a draft but it seems KDE from version 3.4 is already using it so wine would integrate with them. Gnome is using another Trash format but if that would be a big problem I could provide an implementation in shell32_gnome through the Gnome libs. The shell32 would contain a stub implementation of the Trash that would say no trash is available - so that shell32 could work even if the shell32_unix is not available. - The Start Menu. This is currently handled by wineshelllink but if we'd like to implement file associations we might need more control over it. Creating the 'app.desktop' file is easy. A bit harder is to know where to create it. The freedesktop standard specifies a standard place for the file. The older version of KDE and Gnome used different directories (usually ~/.kde/share/applnk or ~/.gnome/apps) but their shell32_* libraries could check the version of the DE and if it is old store the app.desktop in the DE private directory obtained by a DE library call. There could be a problem with detecting the Windows Start Menu changes. The links creation can be trapped in IShellLink like it is currently done but traping link removal can't be done that way as it is done with filesystem calls bypassing the shell32. We may need to put a filesystem change notify on the start menu directory and start a synchronization program if a change is detected. - The file associations. This might be the hardest part. If we detect a change to the Windows associations (here again we might need to put a change notify on HKEY_CLASSES_ROOT) we should get the class MIME type from the registry. If there is no we search the Linux MIME database for this extension. If none was found we can make a dummy one e.g. applicaton/x-wineapp.extension.xxx. If the found/created MIME type is not in the Linux database we should register it. The next step is to check if this application has a menu item. If there is no we should create a hidden one. Once we have the menu 'app.desktop' file we add the line that it handles the specified MIME type. (there are three MIME databases I think we should care about - the freedesktop /usr/share/mime the KDE /usr/share/mimelnk and maybe the old Gnome /usr/share/mime-info) Where was also a comment that this may be to much for one summer. If implementing only a part of this plan is enough then of course I'll agree. Mikolaj Zalewski

2 2

Re: pt_BR
by Marcelo Duarte 07 May '06

07 May '06

Hi, I´ll write the comments in portuguese, it is for us only (maybe): grandao escreveu: > patch for README.pt_BR > some minor corrections ;D > > > -- > [grandão] > ------------------------------------------------------------------------ > > > Grandão, que bom ter alguém na atividade. Logo no começo tem grafado 2 palavras erradas: --- README.pt_br 2006-05-01 08:55:36.000000000 -0300 +++ copia 2006-05-01 08:55:36.000000000 -0300 @@ -8,40 +8,42 @@ ou do X11. A biblioteca também pode ser usada para portar código Win32 em executáveis nativos Unix. -Wine é software livre, liberado segundo a GNU LGPL; veja o arquivo -LICENÇA para detalhes. +Wine é software livre, distrído sob a licensa GNU LGPL; veja o arquivo +LICENCE para detalhes. AQUI: distrído e licensa, o correto é licença. [....] -Como o Wine requer suporte a tarefas a nível de kernel para executar, +Como o Wine requer suporte à tarefas à nível de kernel para que seja executado, somente os sistemas operacionais acima mencionados são suportados. -Outros sistemas operacionais que suportarem tarefas do kernel poderão +Outros sistemas operacionais que suportarem tarefas à nível de kernel poderão ter suporte no futuro. AQUI: Segundo já vi em programas do professor Pasquale, a expressão "à nivel de" é desnecessária, em qq frase. @@ -173,11 +175,11 @@ 7. OBTENDO MAIS INFORMAÇÃO WWW: Uma grande quantidade de informação sobre o Wine está disponivel - pelo WineHQ em http://www.winehq.org/ : vários guias do Wine, - base de dados de aplicações, rastreamento de erros. Este é + no sítio do Wine(http://www.winehq.org): vários guias do Wine, + base de dados de aplicações, rastreamento de erros, etc... Este é provavelmente o melhor ponto para começar. AQUI: Eu particularmente não gosto dessa tradução "sítio", mas acho q já está sendo bem usado né? -- Tradução para Português do Brasil: Marcelo Duarte +Revisão (01/05/2006): Daniel Oliveira

1 0

Current Status of MIDI support under wine
by Kevin Walker 07 May '06

07 May '06

Hi all, I would like to know if MIDI is supported under wine?

3 2

will the real winedbg experts please stand up / please stand up
by Molle Bestefich 07 May '06

07 May '06

Oi Trying to attach a debugger to an application crashing in X11DRV. Enabled the synchronous trace, and the debugger does start, but it's output doesn't show up on the console. It accepts commands such as c for continue, but it's useless if I want a backtrace, for example. Which I do :-). Here's the output that it generates: =========================== err:x11drv:error_handler X protocol error: serial=23409562, request_code=53 - breaking into debugger err:ntdll:RtlpWaitForCriticalSection section 0x7f2c5e20 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7f2c5e20 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0011, blocked by 0009, retrying (60 sec) =========================== I had expected that winedbg start printing something after "breaking into debugger" but before "X11DRV_CritSection wait timed out". I'm going to spend a lot of time fiddling with it now, I'd just like to ask if anyone has a ready explanation (while my story is still short enough to be readable in 5 mins).. Anyone? If someone can enlighten me, I'd also like to know why a timeout occurs while in the debugger. I had expected debugging to completely suspend the process being debugged?

2 3

Re: [WINED3D] QueryInterface corrections
by H. Verbeet 07 May '06

07 May '06

On 25/04/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > (2) write a NULL argument on no match. > > This patch corrects those issues, and also changes GetContainer() for > surfaces and volumes to use the return value as MSDN specifies > (WINED3D_INVALIDCALL), not E_NOINTERFACE on failure. Did you verify this on Windows? MSDN tends to lie about these kind of things. Also not that te value that wined3d returns isn't necessarily the same as what the respective d3d8/d3d9 call returns, although in practice it often is.

3 7

Re: [WINED3D] Flip red/blue for R8G8B8 format.
by H. Verbeet 07 May '06

07 May '06

On 06/05/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > [ applies on top of Mike's tree, but hopefully on the main tree too ] > > R8G8B8 means red is the most significant bit. > On a little-endian system, the texture is stored starting with blue. > It is read byte-by-byte (GL_UNSIGNED_BYTE), therefore it needs to be > flipped to GL_BGR. > > This makes Demo #2 (texture mapping: > http://www.zanir.szm.sk/dx00-09.html) show the correct colors. > Also, in HL2, it makes Barney's face human color (previously it was blue). > I think Stefan Dosinger saw improvement on some other demos. There might be more to this. This was changed the other way around not too long ago. See http://source.winehq.org/git/?p=wine.git;a=commit;h=252c4adb965a26db19c1c91… It might just be that the glDrawPixels call should've been changed instead last time. (Shouldn't those simply use the format in This->glDescription.glFormat in the first place?)

3 3

OpenGL-Accelerated DirectDraw: Experiances and expectations
by Stefan Dösinger 07 May '06

07 May '06

Hi, Now that the new ddraw code in my tree is almost feature-complete, I decided to take a look at opengl-accelerated DirectDraw. I have implemented Blts from and to rendertargets already for Direct3D games like Tomb Raider 3 and Swat3, so I thought it would work. Palettized surfaces(d3d demos) and color keying(moto racer 2) are also in place. Well, I started Anno 1602 with opengl surfaces, got a black screen and looked at the logs. The basic problem is that directdraw games tend to do a lot of 'nasty' things(The same applied to d3d games which do ddraw-rendering) One of these nasty things is GetDC on the render target. Age of Empires 2 and Settlers 3 to that to draw text. This is going to be unplayably slow I'm afraid. Wine will need a dib engine for that to work. Another issue is 'stupid' rendering. I tested Tibia 3(d3d with a ddraw main menu). It creates a single-buffered, non-d3d primary, and a offscreen d3d surface. Now it blts to the offscreen device(which is the wined3d back buffer, no problem), reads everything to an non-d3d offscreen surface and blts the result to the front buffer. This can work, but it needs some pretty good opengl magic to work at a usable speed(At the moment it just produces a black screen). Swat3 showed another problem: It renders the main menu, mouse pointer and the in-game hud with ddraw blts, which works just great basically. In opengl the main menu renders at ~500 fps, instead of ~40 fps with the old gdi code. But whenever I move the mouse pointer over a control, it starts locking all it's surfaces in read-write mode, which requires them to be reloaded to gl and takes performance down(2-3 fps). This is made worse by the surface convertion for color keying emulation. I expect opengl-accelerated directdraw to take some more time, and there will be some games(GetDC) which are unlikely to work well at all. I will make some modifications to the WineD3D texture loading code to only upload changed areas, which should improve the problems a bit. Stefan

3 2

SoC ideas: fix 2398 wine bug
by gamemaker＠tlen.pl 07 May '06

07 May '06

I would like to fix http://bugs.winehq.org/show_bug.cgi?id=2398 bug. On http://wiki.winehq.org/OpenGL there are some ideas how to do this and I think that this one with glViewport and glScissor is the best one. I wrote test program and I think it should work. What do you think about it and do you think that this idea has any chances in SoC?

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2006