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

compile error
by Stefan Leichter April 21, 2006

April 21, 2006

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

April 21, 2006

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

April 20, 2006

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

April 20, 2006

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

April 20, 2006

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

Re: search for /dev/input/js as well as /dev/js
by Mike McCormack April 20, 2006

April 20, 2006

Mike Frysinger wrote: > with udev now, joystick nodes are created as /dev/input/js# and /dev/js# no > longer exists ... attached patch will search for /dev/input/js# first and if > that doesnt exist, fall back to /dev/js# You could easily maintain compatibility with Wine and any other application using joysticks simply by adding some symlinks in /dev. That's what my system has, and it's using udev. Mike

7 12

File dialog regression?
by Mike Hearn April 20, 2006

April 20, 2006

Has anybody else got a problem with no icons appearing in the file dialogs? I just see the generic "blank document" icon - it's as if the shell icons aren't being loaded anymore. My Sherlock-Holmes-esque 6th sense leads me to think that either my setup is borked or the fake stub DLL patch is to blame. thanks -mike

2 1

Re: [usp10] Fix return-codes of ScriptGetFontProperties (resend)
by Joris Huizer April 20, 2006

April 20, 2006

Paul Vriens wrote: > + /* Now a NULL hdc again */ > + hr = ScriptGetFontProperties(NULL,&psc,&sfp); > + /* Save the psc pointer */ > + old_psc = psc; > + ok( hr == S_OK, "(NULL,&psc,&sfp), expected S_OK, got %08x\n", (unsigned int)hr); > + ok( psc == old_psc, "Expected psc not to be changed, was %p is now %p\n", old_psc, psc); > + ScriptFreeCache(&psc); > + ok( psc == NULL, "Expected psc to be NULL, got %p\n", psc); actually You didn't test anything about psc here, after setting old_psc nothing happens with psc -- save the pointer before calling ScriptGetFontProperties(NULL,&psc,&sfp); HTH, Joris

1 0

Using msvcmon to debug
by Ryan Miller April 20, 2006

April 20, 2006

Hi, I've been using msvcmon previously to remote debug application in Visual Studio on Wine. It's great to have an IDE to debug Wine with the breakpoints and watch windows and all. I'm now using Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. I'm getting the log message (which is new): epoll_ctl: Operation not permitted Followed by an exception dialog and an abort. I compared the exception address to my app's map file and I'm thinking it's a Wine address/exception. Does anyone else use msvcmon to debug? Any clues where I should start looking? Thanks. Ryan

3 2

x11drv: question about byte-swapping for DIBs
by Eric Frias April 20, 2006

April 20, 2006

I'm trying to debug a problem in which 24-bit .bmps don't display correctly from a winelib application on a big-endian sparc host when displaying on a little-endian intel PC. In this case, the image is garbled, with most of the colors being wrong and a pattern of vertical stripes over the image. The code passes through convert_888_to_0888_reverse_dst_byteswap which is what mangles the image data. I looked through the other conversion functions, and it seems the corresponding 'src' function (convert_888_to_0888_reverse_src_byteswap) actually does the correct transformation. I don't have a very good grasp of why the conversions are chosen, but it seemed like a likely fix would be to edit dib.c and make the lines in the SetImageBits functions that select the conversion structure look like: #ifdef WORDS_BIGENDIAN const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_src_byteswap; #else const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_dst_byteswap; #endif Doing this fixed my problem and didn't seem to cause any others, but I'm wondering whether this fix is correct or if I just got lucky. Can someone who knows this code tell me if this makes logical sense? (If it's correct, there probably needs to be a related patch in the GetImageBits functions, just going in the other direction). Eric

3 4

usp10: Remove the need to pass chars to ScriptPlace
by Jeff L April 20, 2006

April 20, 2006

This patch uses GetCharABCWidthsI to remove the need to pass chars from ScriptShape to ScriptPlace in the scriptcache work space. Change log: Remove the need to pass chars from ScriptShape to ScriptPlace Jeff Latimer

1 0

Re: Race in rpc__cn_network_receiver()?
by Luke Kenneth Casson Leighton April 20, 2006

April 20, 2006

On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote: luke, you are a star: thank you for helping out with this. just for people's information (in case it's not been mentioned here - i must admit i forgot to notify opendce(a)opengroup.org!) about 6-8 months ago i did a coding-spree on freedce, with a view to achieving two, maybe three, major things: 1) porting to win32 (if you use pthreads-win32) 2) using posix final draft (7?) threads not posix draft 4. 3) proving to the people on wine and reactos that they have a hell of a lot of work to do (measured in man-decades) by not using the open group's DCE/RPC reference implementation. here's the gotchas that i encountered, and had to give up: - udp worked, but tcp did not - reactos had some problems at the time with the code behind ipconfig.exe (NetTransportEnum i think it was) - pthreads-win32 was too strictly posix compliant (!) and there is a cancellation exception or something which makes it fail in the dcethreads exception library tests, where linux does not fail (!) maybe this is related to what lukeh is talking about. *shrug*. anyway, the upshot is that freedce/latest-cvs also doesn't work on TCP, and thank you so much people for helping track down why. it's only been ten years so far: hopefully some time within the next decade, freedce will be used for some real MSRPC-related free software projects. l > >In rpc__cn_network_receiver(), rpc__socket_close() is called without an > >exception handler in place. According to IEEE Std 1003.1 (2004), close() > >is a cancellation point, see: > > > >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html > > > >Given this, a receiver thread could receive a cancel whilst closing the > >socket, which will cause to entire program to abort. (We have seen this > >occur when the RPC server is under load.) > > > >A suggested fix is to move the call to rpc__socket_close() inside the > >TRY/CATCH_ALL block that removes any pending cancels. > > It seems like the real fix is to disable cancellation within > rpc__socket_close(), because in other places the OSF code appears to > assume that this is not a cancellation point. > > Ditto for open(), socket(), etc (but not I/O routines that may block). > > I should note that the Linux dcethreads library does actually disable > cancellation for these calls, however in our own DCE thread library > we opted not to override any system calls to avoid changing semantics > when used by non-DCE code. > > -- Luke > > -- > -- -- lkcl.net - mad free software computer person, visionary and poet. --

1 0

Wine or WINE?
by Ivan Leo Puoti April 20, 2006

April 20, 2006

I was reading WWN yesterday and read something about Microsoft using the incorrect "WINE" form, I email them about it and they appear willing to fix it. Probably the first example of cooperation from them :-) Ivan.

1 0

SoC Mentor Signup!
by Dan Kegel April 20, 2006

April 20, 2006

Jeremy White asked earlier for people to volunteer for the review committee. I think anybody who wants to be a SoC mentor should also volunteer for the review committee. And we need a list of mentors soon, so please, if you are interested in helping, email Jeremy as soon as you can. The great thing about being a Wine mentor is the leverage... you get to help Wine without doing all the heavy lifting yourself. And, if you're lucky, the student you mentor will keep on helping the Wine project even after you're done, so it's a gift that keeps on giving... Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Menus [3/6]: Draw the column separator properly
by Dimi Paun April 19, 2006

April 19, 2006

On Wed, 2006-04-19 at 21:39 +0200, Michael Kaufmann wrote: > --- menu.c 2006-04-19 21:07:47.000000000 +0200 > +++ menu-new.c 2006-04-19 21:07:44.000000000 +0200 Only top-level patches, please: http://winehq.org/site/sending_patches -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

[SOC] proposal -> valgrind
by Eric Pouech April 19, 2006

April 19, 2006

Another potential proposal for SOC would be upgrading valgrind to work with Wine. I've tweaked it a bit (some patches still floating around), but: - that's not complete (some items still don't work) - what's also completly missing is the support of native modules (especially when generating backtraces) - 16bit support (but we can safely leave it out for now) - and testing (and fixing) most of the implementations we have I've updated the Wiki page accordingly. A+ -- Eric Pouech

2 1

Re: widl: Added importlib parsing code.
by Robert Shearman April 19, 2006

April 19, 2006

Jacek Caban wrote: >+importlib: tIMPORTLIB '(' aSTRING ')' {} >+ > > You should warn here that you're not doing anything with the importlib, as typelibs with an importlib statement probably aren't going to work. -- Rob Shearman

1 0

Winelib: SIGTERM or SIGQUIT?
by Michael Ost April 19, 2006

April 19, 2006

I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally. >From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort. It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits. So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical? Or maybe my reading of the "canon of signals" is incorrect? Thanks for any help... mo PS: recently someone was asking a question about winelib and was directed to wine-user. What's the protocol here? Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. I'd appreciate any help with the protocol of all this... =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

3 7

Re: enhmetafile: Create little-endian EMF files on big-endian machines (fixed)
by Phil Krylov April 19, 2006

April 19, 2006

Hi, On Tue, 11 Apr 2006 20:03:22 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > This patch fixes the generation of EMF files (which are little-endian by nature) > on big-endian machines. It is by no means complete - some record types are still > unsupported, and reading of little-endian EMFs on big-endian machines still does > not work - but it works for my app and can be used as a base for future > improvements. Anything wrong with this patch? Should I try to improve it in the direction of supporting more metafile record types and supporting reading little-endian EMFs from disk? Or change everything at all? The subject was recently discussed in this thread: http://www.winehq.org/pipermail/wine-devel/2006-April/046606.html -- Ph.

2 2

Re: gdi: [3 of 3] Add headers for GetCharABCWidthI
by Alexandre Julliard April 19, 2006

April 19, 2006

Jeff L <lats(a)yless4u.com.au> writes: > This add GetCharABCWidthsI and tests. > There is no A or W suffix for this function as it works from a glyph > rather than a char. > > Change log: > Add GetCharABCWidthsI and tests. The tests fail here, probably because they rely on the Arial font: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:366: Test failed: GetCharABCWidthsI should have returned TRUE 3 font.c:372: Test failed: GetCharABCWidthsI should have returned TRUE 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Forming a SOC review committee
by Dan Kegel April 19, 2006

April 19, 2006

Dimi wrote: >One thing that I would like to see is to establish a more >formal post-mortem for every project accepted. ... Sounds good to me. It can even be a condition of completion (and thus of payment). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

SOC: Integrate DIB Engine
by Jesse Allen April 19, 2006

April 19, 2006

One thing I'd like to try to work on is the DIB engine. Do we need someone to work on it still? This one is also interesting to me because we have some documentation already and that I have worked with bitmaps before too. I'd also like to find out how this stuff might integrate with the current changes going into ddraw. http://www.winehq.org/?page=fun_projects GDI Engine Integrate the GDI engine contributed by the TransGaming folks. * workers: wanted * status: to do * updated: June 24, 2005 Jesse

5 5

SOC Idea: Easy usage of native DLLs in Linux programs
by Mike Hearn April 19, 2006

April 19, 2006

Various projects have re-implemented the code necessary to host Win32 DLLs in-process, for instance Xine, MPlayer and GStreamer all have (different) forked, badly hacked copies of the Wine codebase inside themselves to load and use codec DLLs. The GIMP now has the ability to use Photoshop plugins using Wine. And so on. It'd be nice if there was a simple API programs could use to do this, for instance, wine_dlopen("whatever.dll"), wine_adopt_thread() and so on to make re-use of Win32 components and COM objects easy. This has been discussed before and Alexandre wasn't sure it was worth it as it'd be a significant extension to the (stable??) Wine APIs, so IMHO this one shouldn't be judged on whether it gets checked in or not but rather whether it works and how easy it is to use. Thoughts? I know roughly what needs to be done so I could mentor this one, but students be warned - it requires _excellent_ understanding of operating system design and things like threading. There's a reason such a thing doesn't already exist, and it's because it's hard. On the flip side it's not a massive amount of code IMHO so the work would mostly involve learning, debugging, etc rather than simply being a hard typing slog. Also, a student has all summer and the nice thing is, it's mostly generic computing knowledge that'd be useful for future work (whereas learning a specific api in depth probably isn't ...). Such a thing has many uses: * Hosting ActiveX controls inside a native Firefox * Allowing more apps to use plugins from popular Windows apps. GIMP is a bit weird in that its plugin system is out of process and has a simple wire protocol .... a hangover from the days before ELF (!!), but most programs aren't like that. EG imagine being able to use WinAmp visualizion plugins in your music player of choice. * Maybe getting the xine/mplayer/gst mess sorted out a bit (on the other hand they need to run only a small, relatively unchanging amount of code so it may not be worth it) * Allowing piece-by-piece porting of a modular Windows app without Winelib (which is annoying as you have to switch toolchains all at once, you may not even have the sources to some DLLs etc ...) * Actually there is a huge component marketplace in Windows which is especially rich in the boring sort of business components (grid views etc) that open source hackers tend to ignore ... this could allow developers to embed some of the very sophisticated Win32 business objects into native Linux apps, so reducing development costs (of course the result would not be free software, but for in house custom apps that's not really a concern anyway) I'm sure you can think of some more. Discuss! :) thanks -mike

3 4

Re: WineD3D: Allocate the resources with VirtualAlloc
by Alexandre Julliard April 19, 2006

April 19, 2006

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This patch allocates the memory of Surfaces, Indexbuffers and Vertexbuffers > with VirtualAlloc instead of HeapAlloc. This will be needed for GetDC to > work. It is done for Index- and Vertexbuffers too because they are also > managed by the WineD3D resource manager. I'm not sure I agree with that. Are you planning to trap accesses like the DIB code does? That sucks pretty badly in the DIB code, I don't think we want to do any more of that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi: [2 of 3] Add header for GetCharABCWidthI
by Mike McCormack April 19, 2006

April 19, 2006

Jeff L wrote: > I have repackaged this as package. Please don't split patches that depend on each other to make Wine compile and work correctly, or add dead code. The point of having small patches is to make Wine easier to regression test, so we want things to work between every commit. > +// FIXME("%p, %d, %d, %p\n", font, firstChar, count, buffer); Either remove the FIXME completely, or make it a TRACE. Also, C++ comments are not portable in C, so use standard C comments. > + } > + else > + for(c = 0; c < count; c++) { How about using indenting consistent with the rest of the code in the file? thanks, Mike

3 2