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 April 23, 2006

April 23, 2006

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) April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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) April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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 April 23, 2006

April 23, 2006

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

Re: MAPI32: class IProfAdmin, functions MAPIAdminProfiles & MAPIFindNext
by Dimi Paun April 23, 2006

April 23, 2006

On Sat, April 22, 2006 9:10 am, Konstantin Petrov said: > changelog: > mapi.h : added comments to structure MapiFileDesc > mapix.h : added declaration of the interface (class) IProfAdmin > mapi32_main.c : implemented the function MAPIFindNext with FIXME message > created iprofadmin.c : MAPI Default IProfAdmin implementation. There are > implemented 12 functions of class IProfAdmin. Functions > IProfAdmin::AddRef, > IProfAdmin::QueryInterface and IProfAdmin::Release are realized, and other > functions return declared error. > iprofadmin.c : the function MAPIAdminProfiles implemented. > as consequence there were fixed Makefile.in and mapi32.spec Did you use a tab setting that is not 8 spaces, 'cause the indentation looks pretty weird. If you did, please reformat assuming an 8-space tab and resubmit. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

About the web forums and why it's just a waste of time
by Segin April 22, 2006

April 22, 2006

This is a big of a nag, but mostly truth. Hear me out. Most of users' problem with the email is the lack of spiffy graphics. I don't understand why people rant and rave onver the email because it doesn't have spiffy graphics. Also, this extends to HTML formatting. They want to be able to use god awful formatting and colors and fonts that make your stomach churn, or at least hurt your eyes. Now that I did my mostly truthful rant, let's get to business: I have also heard about problems configuring their email client for certain features. Guess what? Forums require the exact same thing! If you want people to reply via email to a different address, you normally setup a reply-to field in your email client. This is usually done for better notification of replies. With forums, you register your email that you recieve notices with, then you have to set for every topic oyu start (or reply to) that you want email notification. This is expodentally more complex than email! While admin-set global stickies are something that only forums can do, that's basically the only thing going for them (and we could just instruct users to setup a sticky filter based on a string that only admins can put into subjects, save replies). User-set custom stickys - These are a pain to set with forums, that is if the forum software supports it, and 99% of forums software doesn't. Users like this, and switching to a forum can really piss them off with this. With an email client, you have more flexibility, cause depending on your client, you can setup these by user, subject, regex on the user or subject, if a attachment exists or not, body of message, size, time, date, who is in the 'cc' list (to hide those not sent directly to the list), and so on. The only forum software that I saw that did this would only do it if you selected a thread for a personal sticky -- this isn't really flexible compared to email.

1 0

SoC idea: get Sun's JRE working well
by Dan Kegel April 22, 2006

April 22, 2006

A lot of applications rely on Sun's JRE, some even use it in their installers! (cf. http://bugs.winehq.org/show_bug.cgi?id=5040 ) Getting Sun's JRE working properly on Wine would be a great project. -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

REALLY old backwards compatability and Wine
by Segin April 22, 2006

April 22, 2006

This is a email that serves multiple purposes, and you all may find intersting. Wine, as we all know, is able to load and run native programs that the real McCoy can't run, but these programs are also close to 20 years old, so nobody really cares anyways. That's right, programs for Windows 2.0 I recently downloaded a full distrib (bin+src) of one such program. It is a xeyes clone with color. Orignally, it worked in Wine, showing a large window with a pair of eyes that followed the cursor, with a blue-green background (the part where the "eyes" aren't drawn in the window) This program was running in a window, and this appears to be broken, as under the real McCoy, version 3.1 (*gasp!*), it runs minimized, cannot be restored, and modifies it's own icon to preform the eyes deal (with a grey "background", as described above). I went to make sure that Wine wasn't broken, so I re-exec'd the binary, but only to get this: First chance exception: page fault on write access to 0x000f0400 in 32-bit code (0xb7df2e97). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:b7df2e97 ESP:7fbff570 EBP:7fbff5b0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7eee7ff0 ECX:00000023 EDX:00000000 ESI:000f0400 EDI:000f0400 Stack dump: 0x7fbff570: 00000000 7eed0e49 000f0400 00000000 0x7fbff580: 0000008c 7ffd50f0 00010000 7ffb190b 0x7fbff590: 7ffdcc24 7fc94988 00000000 0000ffff 0x7fbff5a0: 0000f30f 7eee7ff0 00000000 00000001 0x7fbff5b0: 7fbff5bc 7eed158d 7eee7ff0 7fbff5dc 0x7fbff5c0: 7eee51c4 7eec0000 00000001 00000000 Backtrace: =>1 0xb7df2e97 memset+0x37 in libc.so.6 (0xb7df2e97) 2 0x7eed158d DllMain+0x22 in winedos (0x7eed158d) 3 0x7eee51c4 in winedos (+0x251c4) (0x7eee51c4) 4 0x7ffb0a2d call_dll_entry_point+0x15 in ntdll (0x7ffb0a2d) 5 0x7ffb11f2 in ntdll (+0x211f2) (0x7ffb11f2) 6 0x7ffb13c5 in ntdll (+0x213c5) (0x7ffb13c5) 7 0x7ffb2d8c LdrLoadDll+0x5e in ntdll (0x7ffb2d8c) 8 0x7fc6bab1 in kernel32 (+0x2bab1) (0x7fc6bab1) 9 0x7fc6bb36 LoadLibraryExW+0x4f in kernel32 (0x7fc6bb36) 10 0x7fc6bbe5 LoadLibraryExA+0x2d in kernel32 (0x7fc6bbe5) 11 0x7fc6bc0b LoadLibraryA+0x1b in kernel32 (0x7fc6bc0b) 12 0x7fc1f219 main+0xb7 in winevdm (0x7fc1f219) 13 0x7fc1fb0b in winevdm (+0xfb0b) (0x7fc1fb0b) 14 0x7fc730f3 in kernel32 (+0x330f3) (0x7fc730f3) 15 0xb7ee654b wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ee654b) 0xb7df2e97 memset+0x37 in libc.so.6: repe stosl %es:(%edi) Now, I am no debugger expert, but it appears that Wine is trying to write to a NULL pointer using memset. (I could be reading the stack dump wrong, bear with me here) I hope this helps.

3 3

SoC idea: improve dsound/winmm
by Roderick Colenbrander April 22, 2006

April 22, 2006

Hi, One of the things users complain about is wine's sound quality. Problems which you experience range from crackling sound in media players to buffer underruns and high latencies in games. For a part the problem is caused by crappy audio drivers and soundcards. None the less are there things in wine which can be improved to reduce the issues. I don't know this part of the code well but I believe the alsa driver is far from optimal and second the dsound contains some bugs too. In this SoC project a student would need to look into the causes of wine's bad sound quality and try to improve it by fixing winealsa and other parts. Regards, Roderick Colenbrander -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

7 7

Re-proposal: web forums
by Dan Kegel April 22, 2006

April 22, 2006

Mike Hearn wrote: > [Let's set up web forums for wine users] I dislike the thought of having to monitor multiple forums. Worse still, if a particular web forum goes offline, all its content is lost; not so for mailing lists, which are archived in multiple locations and so are much more reliable and long-lived. Let's keep it all in wine-users, please. If your goal is to make sure that the average person can get answers to his or her questions about Wine, that's a noble enterprise. I would prefer a solution that doesn't have the reliability and usability problems of the current crop of web forums. I would also prefer an evidence-based approach to demonstrating the problem(s) with the current situation. "Some people prefer web forums" is not sufficient evidence. As I've said before, Mike is brilliant but misguided :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 6

undefined reference to `GetCharABCWidthsI'
by Gerald Pfeifer April 22, 2006

April 22, 2006

After the following change to dlls/gdi/font.c revision 1.32 date: 2006-04-19 18:16:36 +0000; author: julliard; state: Exp; lines: +49 -0 Jeff Latimer <lats(a)yless4u.com.au> gdi: Added implementation of GetCharABCWidthsI. I now get the following build error on FreeBSD 5.4: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdrv.o region.o version.res -Wl,--rpath,\$ORIGIN/`../../tools/relpath /tmp/WINE/lib/wine /tmp/WINE/lib` -o gdi32.dll.so -L../../dlls -ladvapi32 -lkernel32 -lntdll -L../../libs -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port font.o(.text+0x3f28): In function `GetCharABCWidthsI': /sw/test/wine/dlls/gdi/font.c:2390: undefined reference to `WineEngGetCharABCWidthsI' winegcc: /usr/bin/gcc failed. SUSE Linux 10.1 works fine. WOuld you mind having a look? Gerald

2 2

git & sharing patches (was: SoC idea: improve dsound/winmm)
by Molle Bestefich April 22, 2006

April 22, 2006

Mike Hearn wrote: > Do the artifacts change or disappear if you use my thread priority patch? I'd like to try out your patch with a couple of apps where sound is shoddy. What's the correct GIT way to apply your patch (and still be able to pull changes from the Wine tree)? Apologies if it's a stupid question, but git --help seems to give a plethora of commands and I've absolutely no idea which are meant for common use and which are completely useless or will corrupt my local tree...

2 1

msvcrt: sharing violation caused by duplicated hande in _get_osfhandle
by qingdoa daoo April 22, 2006

April 22, 2006

Hi, wine's implementation of _get_osfhandle is found to cause sharing violation in some apps. The author commented this piece of code with a block of FIXME warning about possible leakage. It turns out it's no just a matter of leakage. A simple test program ------------------------------------------------------------ #include "windows.h" #include "io.h" #include "fcntl.h" #include "share.h" int main() { int fd, bWritten; fd = _sopen("foo", _O_CREAT|_O_RDWR,_SH_DENYRW, 0); WriteFile((HANDLE)_get_osfhandle(fd), "bar", 3, &bWritten, NULL); _close(fd); fd = _open("foo", _O_RDONLY, 0); _write(1, fd==-1? "F\n" : "S\n", 2); } ------------------------------------------------------------ The second _open fails with builtin msvcrt, not with native one. The comment says that the duplication is to make an inheritable hande. With the recent change in msvcrt's io init procedure, that shouldn't be a problem anymore. --------------------------------- Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

2 1

Re: kernel: fix determination of using locale
by Dmitry Timoshkov April 22, 2006

April 22, 2006

"Sergei Butakov" <butsergej(a)yandex.ru> wrote: > This patch fix for me two bugs: > 1. I'm using locale > # export LANG="POSIX" > # export LC_CTYPE="ru_RU.CP1251" > # export LC_COLLATE="ru_RU.CP1251" > with which in many programs some Russian glyphs look wrong or as square. > 2. in many programs English/Russian glyphs are ugly. > > There are workaround by > # export LANG="ru_RU.CP1251" > but it not suit for me. Probably you just need to set LC_MESSAGES to en_US. -- Dmitry.

3 10

Re: There May Be an End-run for Apple Around Windows After All
by Shachar Shemesh April 22, 2006

April 22, 2006

Hi Robert, I am an occasional reader of your column (truthfully, mostly when it comes up on slashdot). I usually find your comments insightful, or at least thought provocing. I'm afraid the column at the subject is a stark exception to this rule (http://www.pbs.org/cringely/pulpit/pulpit20060420.html) If you'll excuse the strong words, the claim made was nothing more then wishful thinking, with no possibility of basing it on anything real. Before I get to "why", allow me to introduce myself. My name, as you can probably see from the email headers, is Shachar Shemesh. I am founder and CEO of a small Linux consulting company in Israel (http://www.lingnu.com) More to the point, however, I am (or, at least, used to be) a Wine hacker. Feel free to search for my name at http://www.winehq.com/site/who. As the task you claim Apple has undertaken is, in fact, identical to developing a second "Wine", I think I have some authority in assessing how likely that is. I also took the liberty of CCing the wine-devel list, so that if anyone there wishes to claim me wrong, they can. And as for the likelihood, I can answer that question rather easilly. The answer is "not very". I would even go as far as to say that the answer is "extremely unlikely". Wine is a huge project. On last count it had over 1.5 million lines of code. Most of the code inside Wine is written in Win32. Yes, it's a Linux project written, mostly, in Win32. The reason is that the so called "Win32 API" is a convulted huge heap of layers upon layers of miscellanious implementations of anything Microsoft decided to give developers because it seemed like a good idea at the time. Some of these functions misbehave, and some programs rely on this misbehaviour in order to work. Not all of the functions, and hardly any of the misbehaviours, are documented in any way. The Wine project has been busy, for over ten years now, in duplicating said development. Despite what may appear in your column, the reason it has been taking so long is NOT Microsoft's disapproval. For all intent and purposes, MS has no technical means of slowing Wine down, and here is the main reason - Wine only cares about running actual applications. Microsoft is, of course, at liberty to change and add interfaces as much as it wants, but Wine will only care about these interface changes if and when actual applications start to use them. Over this last point MS has very little control. In that respect, I think it should be clear that Apple is in no better starting position to duplicate the Wine effort than Wine is, and there is no reason to think it will do better. Which brings us to the task at hand. Because the purpose of an API replacement is to be "bug compatible" with the original, we can already know how the first versions of such an effort from Apple will look. They will probably be able to run "Solitare" and "notepad", but not much more. We know that simply because Wine used to be there itself. Getting from this "90%" to "100%" takes a considerable amount of time. It makes little sense, and has little return on investment, for Apple to take this herculean task upon itself, when it can get to 95% of the task by simply taking the Wine code and adapting it to Mac OS X. Don't understand this to mean that the next OS X on Intel will not be able to run Windows code without emulation. What I am saying is that it likely WILL be able to do so, but using Wine as its technology. After all, work to get Windows programs running on a Mac using Wine was underway long before Apple made the CPU switch, using thin emulation services. Dumping the emulation (and, more importantly, the endianity misalignment) is only likely to boost this effort. This, however, will happen whether Apple endorses it or not. Hoping your next column will bring us back to the level of writing you usually produce. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

1 0

Re: user: Fix and test behavior when selecting disabled menu items, and fix GetMenuItemRect()
by James Hawkins April 22, 2006

April 22, 2006

On 4/21/06, tkho(a)ucla.edu <tkho(a)ucla.edu> wrote: > Hello, > > This patch 1) changes the behavior of selecting disabled menu items, 2) > recognizes VK_LMENU and VK_RMENU messages to the menu WndProc and 3) fixes > GetMenuItemRect(). > You should send one change/fix per patch. The best option is to send one patch for the tests, with todo_wine around them, and then send separate patches to fix each problem. -- James Hawkins

1 0

opengl demos start problem with wine current cvs
by Kovács András April 21, 2006

April 21, 2006

Hi, When i try to start some opengl demos from www.humus.ca (with wine latest cvs), I get error, that my card doesn't support some opengl extensions. The applications' wine output is: err:wgl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) err:wgl:internal_glGetString GL_EXTENSIONS returns NULL fixme:wgl:wglChoosePixelFormatARB unused pfAttribFList err:wgl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) err:wgl:internal_glGetString GL_EXTENSIONS returns NULL I attached the glxinfo's output. I use Xorg version 6.9.0, on Suse 10.1 beta9 with nvidia driver 2.0.2 NVIDIA 87.56, and I have a geforce 6600 256 mb pci-e vga card. Please help me. Best Regards, -- Lamarr Kovács András andras(a)csevego.net http://csevego.net

1 0

SoC idea: finish wcmd
by Dan Kegel April 21, 2006

April 21, 2006

wcmd isn't thought of as sexy, but it's important; for instance, some installers use it under the hood. Things like if "%1" == "%2" and the /wait commandline flag are not yet implemented. It wouldn't be all that hard to get wcmd far enough along to make those installers happy; I think it'd make a good SoC project. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

dosdevices
by Robert Lunnon April 21, 2006

April 21, 2006

All, I am having some considerable problems dealing with a simple issue. In .wine/dosdevices, devices are listed followed by a colon like in dos. This makes perfect sense except that the colon is often used in UNIX to separate elements of a path description and has special meaning tto some programs. Under solaris this causes problems with the runtime loader which can't dlopen a filename containing a colon, and seems to be problematic for stat as well. What is wrong with listing them without the colon so we don't risk these OS incompatibilities or perhaps adapt the code to accept the links with or without an appended colon. Comments anyone ?

3 6