April 2006 - Wine-devel - list.winehq.org

PROT_EXEC mmap/mprotect, i386 PAE + NX broken, x86-64 2.6.17-rc2
by Alistair John Strachan 23 Apr '06

23 Apr '06

Hi, Just a heads up that WINE seems to suffer from breakage if executed as a 32bit binary on an x86-64 kernel as of 2.6.17-rc, because (according to Andi Kleen) i386 NX is now enabled by default, and on x86-64 i386 behaves like a PAE enabled i386 kernel when performing IA32 emulation. I've attached the entire thread for reference, as unfortunately I do not have the time to debug this problem, but thought that probably one of you would like to know. Thread is also available to read here: http://lkml.org/lkml/2006/4/21/99 Andi suspects that WINE is not making one of its mappings PROT_EXEC which causes a fault with NX enabled. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.

5 16

Requested change in bugzilla
by Tom Spear (Dustin Booker, Dustin Navea) 23 Apr '06

23 Apr '06

Hi all, just posting this publicly for anyone that wants to either second this idea or shoot it down :-). Jeremy, one of my biggest (minor) nits about using Bugzilla is the component box. It isn't very user friendly.. What I mean is that a lot of the components are rarely (never?) used while sometimes (often) a bug gets submitted that doesn't belong to any of the components listed, so I mark it wine-misc, etc.. I noticed that there are a few more entries there now such as usp10.dll and richedit, shdocvw, and various directx dll's, but could we possibly put even more in there? That way in a glance someone can tell if the bug is in an area of wine that they know a lot about and might be able to fix it faster.. I do have another nit about the "assign to owner of selected component" button not working, but thats another thread after this first nit is fixed..

2 1

Re: KERNEL: [2/2] changed test for FindFirstFileEx
by Detlef Riekenberg 23 Apr '06

23 Apr '06

Am Samstag, den 22.04.2006, 18:05 +0400 schrieb Konstantin Petrov: > patch for test No Patch attached. btw, the indention looks strange in your other Patch. -- By By ... ... Detlef

1 0

SOC: D3D Test Suite
by Sagar Mittal 23 Apr '06

23 Apr '06

It doesn't look like there are many unit tests for D3D in general, but D3D8 and WineD3D don't seem to have any. The ones that D3D9 has also don't test the generated graphics for conformance. Would it be a viable/appropriate SOC project to put together a test suite for D3D, including graphical conformance tests? I should probably note that I have no experience using DirectX and minimal experience using OpenGL. Still, a whole summer should be enough time to put together a reasonably comprehensive test suite (perhaps excluding shaders). Thanks, Sagar Mittal

5 8

Bug 5112 - Explorer (wine builtin) fails when run with no command line args
by Tom Spear (Dustin Booker, Dustin Navea) 23 Apr '06

23 Apr '06

Hi everyone, just a simple question. According to this bug, winefile and explorer are bit-by-bit identical, but yet 1 crashes when run with no command line, while the other does not. As the subject of this email says, explorer crashes but winefile doesn't. This particular has no problem with running winefile to open his explorer window, but I agree with comment 3 on this one, that users should be able to run explorer with no command line args to get an explorer window. That makes more sense to windows users who run explorer.exe to open up Windows Explorer.. Is this something that is worth looking into? For right now the bug is wontfix because we do have winefile working, but if someone wants to reopen it to figure out why (if it isnt supposed to) explorer crashes, feel free. Tom

2 1

wine through e-mail/forum/faq
by Francesco Pietra 23 Apr '06

23 Apr '06

I do believe that the choice among e-mail/forum/faq for wine depends on the individual approach to wine. For people, like me, who approach wine to solve their specific problems, and when solved they forget about wine until a new need arises, if ever (but i am aware my own are general problems in science) the faq solution is the best one. Just a couple of examples: 1) I posted a query about the feasibility of running the chemical drawing package "chemdraw" on wine. Lack of a package on unix that allows exchanging files with chemdraw is today the hindrance to have molecular scientists fully to unix (linux). Not a minor gap in science because most chemdraw users do not know unix and thrive on restrictive OSs that limit their science and their minds. 2)I posted a query about the feasibility of running nikon film scanner through wine, just to have the nikon coolscan V (most unfortunately my own, as available in europe, is usb and not scsi). This is by far a minor problems with respect to the one above but it is anyway another example of query. Well, I got no answer (except one privately from my country). What about access now to my queries? Practically no access, so that I have no hope to get further help about. It might be different with faq. I agree however that a forum may be of interest to those who approach wine per se and have a standing supply of problems for wine. I hope this is a contribution (although i am aware that having both faq and forum requires having people to maintain both them). If not, forget about my mail. Cheers francesco pietra

2 2

CVS build problems
by Segin 23 Apr '06

23 Apr '06

I just refreshed my CVS source tree, and on configure, it failed while writing the final makefiles with tihs error: config.status: error: cannot find input file: dlls/comdlg32/Makefile.in The folder dlls/comdlg32/ is empty -- is this a CVS glitch?

2 1

possible bug in wine, programs/winecfg/appdefaults.c
by Segin 23 Apr '06

23 Apr '06

While looking over this file, I came across something that just doesn't look right: { "win31", "Windows 3.1", 2, 10, 0, VER_PLATFORM_WIN32s, "Win32s 1.3", 0, 0, ""}, (for those that don't pay attention to the winecfg code, the third value is the major version for the emulated version of Windows) Now, this is the Windows 3.1 emulation selection, but the major/minor here is 2.10 Is this a bug, or a "compatability bug", as in an intentional fault to be compatable with windows? Attached is a patch to "correct" this behaviour (assuming that it is wrong) ChangeLog: Modified the dwMajorVersion of the Windows 3.1 emulation from 2 to 3 in programs/winecfg/appdefaults.c Index: appdefaults.c =================================================================== RCS file: /home/wine/wine/programs/winecfg/appdefaults.c,v retrieving revision 1.23 diff -u -r1.23 appdefaults.c --- appdefaults.c 18 Mar 2006 18:52:29 -0000 1.23 +++ appdefaults.c 23 Apr 2006 03:17:30 -0000 @@ -55,7 +55,7 @@ { "win95", "Windows 95", 4, 0, 0x3B6, VER_PLATFORM_WIN32_WINDOWS, "", 0, 0, ""}, { "nt40", "Windows NT 4.0", 4, 0, 0x565, VER_PLATFORM_WIN32_NT, "Service Pack 6a", 6, 0, "WinNT"}, { "nt351", "Windows NT 3.5", 3, 51, 0x421, VER_PLATFORM_WIN32_NT, "Service Pack 2", 0, 0, "WinNT"}, - { "win31", "Windows 3.1", 2, 10, 0, VER_PLATFORM_WIN32s, "Win32s 1.3", 0, 0, ""}, + { "win31", "Windows 3.1", 3, 10, 0, VER_PLATFORM_WIN32s, "Win32s 1.3", 0, 0, ""}, { "win30", "Windows 3.0", 3, 0, 0, VER_PLATFORM_WIN32s, "Win32s 1.3", 0, 0, ""}, { "win20", "Windows 2.0", 2, 0, 0, VER_PLATFORM_WIN32s, "Win32s 1.3", 0, 0, ""} };

2 2

GLSL - Compile time check for OpenGL 2.0?
by Phil Costin 23 Apr '06

23 Apr '06

Hi, Let me introduce myself, I'm a final year student of Software Engineering from the UK and I'm beginning to take more of an active interest in Wine. I believe that one of the main reasons people stick with Windows over Linux or BSD is because they miss their games. I have an interest in OpenGL and Direct3D and would be interested in helping to get the Shader code up to a nice level of functionality. This is no small task and I'm still figuring things out. It seems we still need a HLSL to GLSL translator for SM 3.0 but that is for future discussion :) I have noticed that at the moment, shaders are parsed and converted to AFP_FP/VP 1 and if a particular opcode is not supported, a FIXME states a requirement for GLSL. I was curious as to whether it would be acceptable to provide a compile-time check for OpenGL 2.0? It would be no different than checking for any other dependency, with the only disadvantage being that we can not be sure which version the user has when distributing binaries. We could get by this by distributing binaries for ARB_vertex_program and ARB_fragment_program 1 support and requiring a compile for users who want OpenGL 2.0 functionality. I think it would have to be compile-time because we need to know whether we can use the GL 2.0 shader methods at that point. If it is supported, we could then leave the current code in place for OpenGL < 2.0 Then we could use "#ifdef GL_VERSION_2" or similar to allow linking to the GL 2.0 shader loading interfaces and define and make use of a function to convert the shader ASM for versions less than 2.0 straight to GLSL at runtime, skipping the current issue of beginning to convert to ARB shaders, hitting a GLSL-requiring opcode and having to start again with GLSL. I could have this all wrong so a little guidance and feedback on the proposal would be very helpful! Kind Regards, Phil Costin

2 2

DIB to OpenGL? was Re: SOC: Integrate DIB Engine
by Jesse Allen 22 Apr '06

22 Apr '06

Hey! On 4/19/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Hi, > For DirectX games, such as Age of Empires 2, I propably have an OpenGL-ish > solution for the problem. I haven't looked at it in detail, so no promises > that it is possible at all, but this was my idea: > > Basically, DirectDraw apps do the following things with surfaces: > *Locking > *Blits > *GetDC > > Basically there are two surface types: Render targets and offscreen surfaces. > In the general case, locking is only done for offscreen surfaces, and > basically during loading time, or when a surface has to be updated. In the > current ddraw code, Blits are done in software, and they involve locking both > surfaces. GetDC also holds a lock on the surface, which is essentially a dib > section, and then doing the usual gdi stuff. > > With opengl, the situation is a bit changed: Locking the surface requires > transfering the data from and to video memory with glTexSubImage, > glDrawPixels and friends. This is quite slow for full surfaces, but it > usually occurs at loading time only. If some apps are bad-behaved and do a > full lock of the rendertarget, this has a big performance impact at the > moment, but this can be optimized a lot. Blits can be handled in hardware > with 3D drawing, so they should work nice and fast :-) > > The remaining problem is GetDC. At the moment this requires copying the > complete surface from opengl to main memory, converting it to the servers bit > depth, and copying it to a server-side pixmap. Here the new > texture-from-pixmap glx extension can help. It should allow us to link the > opengl texture directly to the pixmap gdi works on, without the need to copy > it through wined3d. This extension is beeing designed for the new aiglx (and > xgl?) stuff, so we can expect driver support soon, and the x server/opengl > driver can optimize the image transfer nicely. > > Well, what problems occur: The extension is not finished yet, we have to wait > for this first. It's also not clear to me if the image transfer is supported > in both ways, from pixmap to texture and from texture to pixmap. Furthermore, > the textures should be in the server's color depth. For palettized surfaces, > the conversion can be done when the game loads the surfaces, which is at the > game loading time, if it is well-behaved. WineD3D already does that, if the > card doesn't support palettized gl textures(most modern cards do not support > that) > > That's my basic idea, I haven't done any deeper investigation if that is > possible at all, so I might be woken up from my daydreams now :-D > Maybe you aren't day-dreaming! Have you read this? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnopen/htm… Jesse

1 0