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

Re: There May Be an End-run for Apple Around Windows After All
by Shachar Shemesh 22 Apr '06

22 Apr '06

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 21 Apr '06

21 Apr '06

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 21 Apr '06

21 Apr '06

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 21 Apr '06

21 Apr '06

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 21 Apr '06

21 Apr '06

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

compile error
by Stefan Leichter 21 Apr '06

21 Apr '06

Hi, i am getting a compile error on current cvs. Does anyone else seeing this problem e.g. on git ? My system is SuSE Linux 9.0 Bye Stefan bison -d -t ../../../wine/tools/widl/parser.y -o parser.tab.c ../../../wine/tools/widl/parser.y:283.11: parse error, unexpected ":", expecting ";" or "|" ../../../wine/tools/widl/parser.y:283.35-38: $$ von »importlib« hat keinen deklarierten Typ ../../../wine/tools/widl/parser.y:283.35-43: $2 von »importlib« hat keinen deklarierten Typ make[2]: *** [parser.tab.c] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/tools/widl' make[1]: *** [widl] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/tools' make: *** [tools] Fehler 2 sle(a)sle3:/usr/src/wine/wine-build> bison --version bison (GNU Bison) 1.75 Geschrieben von Robert Corbett und Richard Stallman. Copyright © 2002 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt keine Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.

2 2

SOC: More Ideas
by Detlef Riekenberg 20 Apr '06

20 Apr '06

Hi Some more Ideas for SOC: Printer-Dialogs: PrintDlgEx* is the Default Printing-Dialog since w2k, but we have only a stub. Some Apps fail to Print for that reason. A usable Implementation need to Support the Properties from the Application (Example from IE: Print actual Frame / Print Links only) and the Properties from the Printer-Driver (provided by wineps.drv from the PPD-File). Fun-Project: Support Native Printer Drivers The CUPS-Backend "ddiwrapper" (GPL) uses Ghostscript to render BMP-Images on Linux, forward them to an modified wine (winspool.drv and gdi32.dll are replaced) that used a native driver (reported to work with some Cannon-Printers) to print that BMP-Image to the Printer (/dev/lp0 or /dev/usb/lp0). A usable Implementation will enhance winspool.dev and gdi32.dll in such a way, that "ddiwrapper" will work "out of the box" Fun-Project: Support Native Scanner Drivers A usable Implementation will work with a modified twain_32.dll (and kernel32.dll / ntdll.dll), but without a Kernel-Module (Example: via libusb). -- By By ... ... Detlef

2 1

Getting wrc to support long long
by Bill Medland 20 Apr '06

20 Apr '06

I just tried wrc for the first time and fell over this. Internal error (please report) ./ppl.l 824: long long constants not implemented yet Is anyone intending doing anything about it in the near future? Is it a reasonably simple thing to implement? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

DIB section problem
by Stefan Dösinger 20 Apr '06

20 Apr '06

Hello, While working on an implementation for IWineD3DSurface::GetDC and IWineD3DSurface::ReleaseDC, I think I stubled accross a bug in the DIB code. It appears to me that the memory of the DIB section isn't unprotected correctly when the dib section is destroyed. I have pasted my code here: http://wine.pastebin.com/671601 What I do is basically: ->Lock the surface ->Create a DIB section for the locked surface memory(Allocated with VirtualAlloc) ->Get a DC for the dib section ->Setup the dc and return it to the app In ReleaseDC, I do it the reverse way: ->Release the DC ->Delete the DIB section ->Unlock the surface But all accesses to the surface's memory fail after deleting the dib section. Therefore I unlock the surface before destroying the dib, and upload the texture to opengl, to be able to free the memory. For testing, I've inserted VirtualProtect(This->resource.allocatedMemory, This->resource.size, PAGE_READWRITE,&oldProtect); after the DeleteObject, and then I can access the surface normally again. But the image that the app wrote with GDI commands isn't there, it looks like the image is left in the X server and dropped. Can someone with more knowledge of the DIB code have a quick look at this? Thanks, Stefan

2 1

RE: Using msvcmon to debug
by Ryan Miller 20 Apr '06

20 Apr '06

I'm using Redhat ES 4. The wine version is: Wine 20050830. Does this message typically get followed by an exception? Ryan -----Original Message----- From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] Sent: Thursday, April 20, 2006 1:06 AM To: Ryan Miller Cc: wine-devel(a)winehq.org Subject: Re: Using msvcmon to debug >>>>> "Ryan" == Ryan Miller <rmiller(a)auctionpay.com> writes: Ryan> Hi, I've been using msvcmon previously to remote debug application Ryan> in Visual Studio on Wine. It's great to have an IDE to debug Wine Ryan> with the breakpoints and watch windows and all. I'm now using Ryan> Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. Ryan> I'm getting the log message (which is new): Ryan> epoll_ctl: Operation not permitted What distribution are you using? What wine version is involved? The "epoll_ctl: Operation not permitted" problem appeared now and then, but mostly only Suse Distribution was involved. If I remember right, the dll/kernel/test directory provoked such an error for me, but does not now, with a nearly up-to-date CVS wine on Suse 10.0 Ryan> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> Please, no HTML in Mail. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2