May 2007 - Wine-devel - list.winehq.org

Re: localui/tests: Add tests for ConfigurePortUI
by Alexandre Julliard 21 May '07

21 May '07

Detlef Riekenberg <wine.dev(a)web.de> writes: > diff --git a/dlls/localui/tests/Makefile.in b/dlls/localui/tests/Makefile.in > index 191a312..634060b 100644 > --- a/dlls/localui/tests/Makefile.in > +++ b/dlls/localui/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = localui.dll > -IMPORTS = kernel32 > +IMPORTS = kernel32 msvcrt winspool You can't import msvcrt without using the headers and the appropriate compiler flags. It would be much better to avoid it though. -- Alexandre Julliard julliard(a)winehq.org

1 0

msi ole automation: where to next?
by Misha Koshelev 20 May '07

20 May '07

Hi everybody, Hope you are all having a nice Sunday. Since MSI OLE automation is a bit overwhelming, I have been using installers that have JScript/VBScript actions to guide me as to what specific functions/objects to implement next. I started out by implementing all the functions used by the Vector NTI installer (which is how I got into wine programming at all; and which was actually dependent on one of these actions for installing at the time), and for the past few weeks I have been following the functions required by the iTunes 7 installer. However, now that I have implemented all the functions used by both of these (yay), I am having trouble finding another installer that uses a lot of scripting, so I was wondering if anyone had any suggestions? It really helps to have something like that to guide/motivate me. (I googled "UNHANDLED ACTION TYPE" and tried the installers I found but all the installers I actually tried out didn't seem to use scripting or maybe just unimplmeneted scripting functions anymore). Alternately, is there any other use for MSI OLE automation besides installers with scriptable actions? If so, what functions would be important for that use? (I know Mike McCormack talked at one point about using these interfaces to run custom actions in a separate process, but I am not really clear as to why automation is really necessary for this and, if so, how exactly it would be used, since all the automation functions are just wrappers around existing functions anyway.) Thanks a lot Misha

2 1

Small Direct3D milestone
by Stefan Dösinger 20 May '07

20 May '07

Hi! With Wine 0.9.37 we've archieved something that I allow myself to call a small milestone - All Direct3D7 Immediate mode SDK demos successfully perform their intended rendering. I have some screenshots on my university junk server: http://stud4.tuwien.ac.at/~e0526822/sdkdemos1.png http://stud4.tuwien.ac.at/~e0526822/sdkdemos2.png Two major problems are left though, namely windowed opengl rendering(see the junk where a menu bar should be) and GetDC(there should be a little bit of text rendered, I disabled render target locking to get proper performance). Some demos have a few smaller problems too. The bump earth and bump waves need vendor specific extensions(GL_NV_texture_shader2 / GL_ATI_envmap_bumpmap) and the bend demo needs GL_ARB_vertex_blend which nvidia does not support. So I took that screenshot on my mac running linux(ati radeon X1600. The mipmap demo renders the mipmaped texture garbled, although this works on nvidia cards. The Z buffer demo says w buffers aren't supported, but the normal z buffer does what the w buffer is supposed to do. What does that mean for gamers? Nothing fancy really, the features used by games are implemented since a long time, the ones that used to miss(fixed function bump mapping, vertex blending) aren't really important for games. Other DirectDraw features like Overlays aren't implemented either, but we are Direct3D 7 feature complete. Where to go from here? I am currently fixing the DirectDraw rewrite regressions I can get hold of, and I am trying to make D3D thread safe finally. From the application point of view my focus will stay on fixing older apps first, which somewhat includes getting thread safety, render target locking and GetDC working properly. My hope is also to fix the other related DX7 sdk demos, like the DDraw demos(except overlays, they are highly tricky with the current wined3d-x11drv integration) and getting native d3drm.dll working. I also want to say thanks to all the small and big helpers who help with technical advise, debugging and regression testing. Special thanks goes to Henri without whom I'd be totally lost and who has to be credited for a huge majority of the shader work in the last half year, and a lot of other things too. Thanks and continue the good work :-) Stefan PS: As for the screenshots, my space on that server is limited, so they will be gone sooner or later. I didn't want to send huge screenshots as attachments, not even as jpgs.

10 17

Re: [localui} New Korean Resource
by Detlef Riekenberg 20 May '07

20 May '07

On So, 2007-05-20 at 19:54 +0900, Hwang YunSong(황윤성) wrote: > +LANGUAGE LANG_KOREAN, SUBLANG_DEFAULT > + > +STRINGTABLE DISCARDABLE > +{ > + IDS_LOCALPORT " Ʈ" > + IDS_NOTHINGTOCONFIG " Ʈ ɼ ϴ" > +} localui.dll has much more resources now. Please update your Translation-Patch. Thanks -- By by ... Detlef

1 0

user32: Exclude unused headers
by Andrew Talbot 20 May '07

20 May '07

Apologies for the duplicates: the originals were slow to arrive, so I presumed they got lost and sent them again. -- Andy.

1 0

ADVAPI32: service tests
by Rolf Kalbermatter 20 May '07

20 May '07

While working on some advapi32.service functions I found that having some tests for those APIs could be very useful. However nbot having added completely new tests so far there are a few issues I feel intimidated about. The actual task of adding a new test file service.c does seem fairly straightforward to me, considering I can just take some other test file and copy the framework from it, adding the new service.c to the Makefile.in. However there are a few issues I see. First almost any test won't make much sense without at least one service installed and activated. As it is now there seem to be no services installed by default in a clean Wine install. So I guess I would also need an extra executable somehow that implements a basic service that could for instance communicate through a pipe with the service test. It could be as simple as an executable that implements all the necessary communication with the service manager and offers some sort of pipe loopback as main service activity. But how am I going to add such an extra executable to the make logic of the advapi32 test? Also under real Windows installing a service will in many cases fail since that requires administrative privileges for the current process and I'm not sure we can and want to enforce something like that especially for the unattended wine test service if that is still working. I would really appreciate some help about adding an extra executable to the creation to the advapi32 make logic so that meaningful tests could be done on Wine. Or maybe someone knows of a service that is going to be added to a standard Wine installation soon? Rolf Kalbermatter

3 4

Wine keyboard driver+XKB. What am I to do?
by Oleh R. Nykyforchyn 20 May '07

20 May '07

Hello, I need an advice on what to do with some piece of code that I have written for about 3 years. I started to make changes in Wine keyboard driver because I was not able to use MS Office under it on my Linux box (3 or 4 XKB groups, 2 overlay groups used, English, Russian, Ukrainian, Belarusian, German and Polish layouts). First I submitted a patch that adds koi8-u encoding to Wine, and it was happily introduced. But my changes to X11DRV (now winex11) keyboard driver were large and I understand Wine people who didn't want to risk. Meanwhile I continued to polish my implementation to correct bugs and improve performance. I am heavily indebted to people that tested my patches, wrote me about problems with them and suggested possible solutions. I thank to L.Rahyen that supported me in my efforts. Now patched keyboard driver allows user to: 1) have up to 4 XKB groups working (current code uses 1 or 2); 2) detect and use XKB overlays to put 2 or 3 close layouts (e.g. Russian, Ukrainian and Belarusian) into one XKB group; 3) freely combine available XKB layouts in any order, e.g. "en,ru,fr"; 4) list all layouts available at the system, and implement ActivateKeyboardLayout(); 5) notify an application (e.g. MS Word) about change of layout, and make GetKeyboardLayout() work really, not just return LCID for current locale of Unix box; 6) input characters that do not fit into current Unix locale, e.g. German and French accented letters at a system with Cyrillic (not UTF) locale; 7) override any of detected layouts via registry, if user is not satisfied with Wine driver choice. In fact I made cosmetic changes to 3 files in winex11.drv directory: x11drv.h, x11drv_main.c, event.c, but the fourth file keyboard.c was changed much more. About half of functions in it were rewritten, and it now easier to read new keyboard.c than diff output to understand the changes. I got very reasonable advice from L.Rahyen to broke the patch into smaller parts. The problem is that I preserved the driver logic, but changed data structures, so any such patch (even very small one) will touch hundreds if lines across the whole file, probably introducing new bugs and being difficult to read and understand. Also, there is no reason to change code by a patch if we can benefit of it only after next patch. Now I will be grateful to any help. How can such big changes be introduced in Wine tree? I also attach a patch against wine-0.9.37 and copies of original and changed files. Perhaps somebody, who is interested in multilingual keyboard input, can test it and write me about results. Oleh

3 2

Re: msxml3 [1/4]: Add initial implementations of IXMLElement and IXMLElementCollection
by Huw Davies 20 May '07

20 May '07

On Thu, May 17, 2007 at 04:40:06PM -0500, James Hawkins wrote: > > Changelog: > * Add initial implementations of IXMLElement and IXMLElementCollection. I can't help thinking that it would have been cleaner to implement the IXML stuff using the IXMLDOM interfaces rather than straight on top of libxml. That way we only get one set of interfaces that depend on libxml. It may not be possible, but I think it would be worth a look. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Re: gdi32: check for null-pointer in CreateDIBSection
by Jesse Allen 20 May '07

20 May '07

On 5/19/07, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Hi , this fixes bug 8066, > http://bugs.winehq.org/show_bug.cgi?id=8066 > > See the crash log here: > http://bugs.winehq.org/attachment.cgi?id=5800&action=view , > CreateDIBSection is called with bitmapinfo = null. > > The program should be passing in a correctly initialized BITMAPINFO. We need to make sure this isn't hiding another bug. Could you provide a test case?

2 1

Success: Sim City 4 using DirectX
by Markus 20 May '07

20 May '07

Hello, just wanted to let you know that with Wine 0.9.37, Sim City 4 is running successfully in DirectX mode for the first time in the 3 years I've been playing it under Wine. Previously, to be able to play at all, one had to force the game to use OpenGL calls. The visual artifacts triggered by scrolling the map under that mode are now gone under DirectX as well. So all in all great work :) The only issue remaining seems to be related to the Z-buffer. Cars and pedestrians are always drawn on top of buildings. See http://bugs.winehq.org/show_bug.cgi?id=7260#c3 Regards, -- Markus

1 0