May 2008 - Wine-Devel - list.winehq.org

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

re: Wine t-shirts?
by Dan Kegel Sept. 3, 2009

Sept. 3, 2009

Maarten wrote: > Why don't we have wine t-shirts any more? I dunno, where were they before? I just looked, couldn't find any on cafepress.com. I'd like to bring back the Codeweavers drunken penguin t-shirts, perhaps with a slightly more generic Wine design. Coincidentally, I found some site on the net had taken the logo from that shirt and erased the Crossover logo from the wine bottle; here's a cleaned-up copy: http://kegel.com/wine/wine-penguin-corkscrew.png

15 34

winequartz.drv Mac OS X UI discontinued?
by Adam Strzelecki July 11, 2009

July 11, 2009

Hi, I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv. Do you guys think about reviving winequartz.drv? This would greatly improve Wine on Mac as we could have native Mac fonts handling that's faster than FreeType, Dock icons for Wine applications, and few others. There's still old copy of the it hanging around, but it is abandoned, and no longer compiles with Wine. Or I think it would be cool to write new winecocoa.drv or sthing like that, as Apple officially states that Carbon is deprecated. While it is not well documented, it is pretty easy with Cocoa to make console non-bundled process to be UI foreground process and handle events and Dock: (This code is copyrighted by myself ;P) > int main(int argc, const char * argv[]) { > ProcessSerialNumber psn = {0, kCurrentProcess}; > OSStatus returnCode = TransformProcessType(&psn, > kProcessTransformToForegroundApplication); > SetFrontProcess(&psn); > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > [NSApplication sharedApplication]; > > NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"]; > [NSApp setApplicationIconImage:icon]; > > [NSApp finishLaunching]; > > NSWindow *window = [[NSWindow alloc] > initWithContentRect:NSMakeRect(0, 0, 100, 100) > styleMask:NSTitledWindowMask| > NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask > backing:NSBackingStoreBuffered defer:NO]; > [window center]; > [window setTitle:@"Test"]; > > NSButton *button = [[NSButton alloc] > initWithFrame:NSMakeRect(10, 10, 80, 80)]; > [button setTitle:@"What?"]; > [button setBezelStyle:1]; > [[window contentView] addSubview:button]; > [button release]; > > [window makeKeyAndOrderFront:NSApp]; > > while(1) { > NSEvent *event = [NSApp > nextEventMatchingMask:NSAnyEventMask > untilDate > :[NSDate distantFuture] > inMode:NSDefaultRunLoopMode > dequeue:YES > ]; > if(event) [NSApp sendEvent:event]; > } > [pool release]; > return 0; > } BTW. I heard that someone previously working for Wine project is now in Apple, it is true? Regards, -- Adam Strzelecki |: nanoant.com :|

20 55

Wine desktop integration: current directory of app launched with doubleclick?
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

4 9

Free apps bundled with msvcp71?
by Dan Kegel Sept. 29, 2008

Sept. 29, 2008

Adobe Contribute 4, released in Nov 2006 or so, had a nice online trial at http://trials.adobe.com/Applications/Contribute/Adobe_Contribute_4_Win/Adob… and still online, I think, at http://www.soft32.com/download/63-129953-1/Adobe_Contribute_4_Win.exe Starting it fails with err:module:import_dll Library MSVCP71.dll (which is needed by L"C:\\Program Files\\Adobe\\Contribute 4\\CoreTypes.dll") not found Wine has a nice implementation of msvcr71.dll, but not the C++-oriented msvcp71.dll, nor is it likely to get one soon. This brings back the question: what's a good place to legally and freely download an application bundled with a full set of msvcp71.dll et al? Ideally something at Microsoft.com and/or something small and suitable for use in winetricks. Any ideas? - Dan

2 3

mono progress on mixed-mode assemblies...
by Dan Kegel Aug. 2, 2008

Aug. 2, 2008

http://lists.ximian.com/pipermail/mono-devel-list/2008-May/027767.html shows that Pál Kornél is now working on supporting apps that use msvcrt. Go Pal go!

7 15

Lots of input messages lingering in server slowing down wine tremendously?
by Alexander Dorofeyev July 8, 2008

July 8, 2008

Hi. There was a problem found recently in a fan-made mod of Forsaken (game), that certain input combinations were slowing wine very seriously. Holding down a keyboard button and moving mouse was found to be especially devastating to performance (200 fps to 10fps in a matter of 10-20 seconds). With help from people who develop this mod, I was able to isolate it in a very small and simplistic testcase, which shows this same problem. It will be included as attachment. Holding a key and moving mouse over the window steadily increases main loop latency from 10 to 50 (and even 100) in a short time, especially so if quickly clicking both mouse buttons as well. In a game this means going from 100 fps to 20 or 10 just because of input messages. Has to be noted that in the actual game the rate of slowdown seemed at least 2-3 times faster for reasons I don't know, but the testcase still should enough to show the problem. Now, I do realize that what the testcase is doing is bad practice, it's basically refusing to process certain types of messages, and PeekMessage just once during a loop is probably bad as well, but that's what the game was originally doing in its main game loop. They do plan to fix it in the game. Still, there are several concerns about it: 1) No slowdown happens of Windows as far as I can tell. No matter how much I move the mouse holding key and clicking madly, it shows same stable 15-16 ticks latency in the testcase. I don't know what it does, but somehow it handles this situation better than Wine. 2) Can this (broken) way of doing things be exposing some inefficiency in message handling, maybe something that could use optimization? I tried to put debug hacks into queue_hardware_message(), it seems that when slowdown is already VERY bad in Forsaken (10fps), message queue in wine server has about 400 or maybe 600 messages. Is that kind of processing overhead per message inevitable? (This is happening on AMD Athlon(tm) 3200+). Perhaps somebody who knows that part of code well may be interested in looking into performance issues in this case. Because, if 400-600 messages in the queue slow down the application to a crawl, then who knows, perhaps it decreases performance of more well-behaved but input-intensive apps as well, just less drastically (holding one or several keys to move, all the while aiming with mouse and abusing mouse buttons is a common thing in games, so there can be quite a few input messages flooding the server). The reason I decided to post it to wine-devel is because I'm not sure if this kind of thing is expected and unavoidable or a bug that can be fixed, so better to hear some comments first, then a bug entry can be opened if needed. #include <windows.h> HWND window; int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASS wc = {0}; MSG msg; DWORD ticks, ticks2; HHOOK kbd_hook, mouse_hook; wc.lpfnWndProc = &DefWindowProc; wc.lpszClassName = "testwc"; RegisterClass(&wc); window = CreateWindow("testwc", "test", WS_OVERLAPPED | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); ticks = GetTickCount(); for (;;) { if (PeekMessage(&msg, NULL, WM_NULL, WM_KEYFIRST, PM_REMOVE)) { if (msg.message == WM_QUIT) { DestroyWindow(window); break; } TranslateMessage(&msg); DispatchMessage(&msg); } //simulated work ticks2 = GetTickCount(); for (;;) { UINT i; volatile int dummy = 1; for (; i < 10000 && dummy; i++) ; if (GetTickCount() - ticks2 >= 10) break; } printf("main loop %u tick latency\n", GetTickCount() - ticks); ticks = GetTickCount(); } }

2 1

Alternate shell?
by Dan Kegel July 6, 2008

July 6, 2008

For a maximal dogfood experience, I was looking around for a way to use a replacement Windows shell with Wine as my desktop environment instead of gnome or kde. So far, all the ones I've found are either broken, hard to use, or just plain weird. I've been working through the list at http://www.dmoz.org/Computers/Software/Operating_Systems/Microsoft_Windows/… http://www.astonshell.com/aston/ - couldn't figure out how to run it? http://www.emergedesktop.org/ - kind of works, but very minimal, no start menu http://www.labyrinth.net.au/~mosses/rob/liteshell.html - works, but very minimal, no start menu http://purels.org - no help, just exits, saying "ha ha, you didn't configure me". Obviously not meant for me :-) http://www.lighttek.com/talisman.htm - pretty, but no Programs menu?! (Maybe that's there but broken, wine bug?) http://www.sky.franken.de/explorer/download.html - ROS explorer - prebuilt binary there is 3 years out of date, doesn't work too well Anyone have a favorite I should try? - Dan

11 19

New winetricks 20080402: new verbs dotnet20, win2k, flash, msls31; updated mono, liberation
by Dan Kegel July 3, 2008

July 3, 2008

Big news: as of today or so, wine doesn't need any patches to install the .net 2.0 runtime or run trivial .net 2.0 apps, so I've added a dotnet20 verb. No more futzing with recipes to try out simple .net 2 apps, huzzah! There are lots of other little changes, too: 20080402 r21 Added dotnet20, removed one kludge from dotnet11, added win2k verb, plus shorthand for winver=foo r20 Updated liberation fonts. 20080328 r19 Added flash. 20080326 r18 Fix i18n problem reported by Ricardo Cabral 20080321 r17 Added msls31 (seems to be needed by e-Sword) 20080317 r16 update mono12 to 1.2.9 ... As always, winetricks is downloadable from http://kegel.com/wine/winetricks and change history is at http://code.google.com/p/winezeug Thanks to the folks who keep feeding me improvements and suggestions! - Dan

4 3

today's valgrind results online
by Dan Kegel June 23, 2008

June 23, 2008

Online at http://kegel.com/wine/valgrind/20071002/ (I now include more info about memory leaks, but I still only report anything if there was an invalid memory reference.) The following tests were fixed in git yesterday, and no longer have any valgrind warnings: comctl32/rebar comctl32/status crypt32/chain crypt32/crl crypt32/msg cryptnet/cryptnet user32/msg wintrust/softpub Juan thinks nearly all of the remaining crypt32 errors can be suppressed (some are intentional). Here are the directories that still have warnings: advapi32 advpack cabinet comctl32 crypt32 d3d8 d3d9 d3dx8 dplayx dsound gdi32 gdiplus hlink kernel32 mlang msacm32 mscms mshtml msi msvcrt msxml3 netapi32 ntdll ole32 oleaut32 quartz riched20 riched32 rpcrt4 rsaenh setupapi shdocvw shell32 urlmon user32 usp10 wininet winmm wintrust - Dan

3 4

Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
by Robert Shearman June 17, 2008

June 17, 2008

Huang, Zhangrong wrote: > See dlls/ole32/compobj.c, > > static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath, > BOOL apartment_threaded, > REFCLSID rclsid, REFIID riid, > void **ppv) > { > ................... > if (SUCCEEDED(hr)) > { > .................. > TRACE("calling DllGetClassObject %p\n", > apartment_loaded_dll->dll->DllGetClassObject); > /* OK: get the ClassObject */ > hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv); > ^^^^ > if (hr != S_OK) > ERR("DllGetClassObject returned error 0x%08x\n", hr); > } > .............. > } > > Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx, > > riid > > [in] Reference to the identifier of the interface that the caller > is to use to communicate with the class object. Usually, this is > IID_IClassFactory (defined in the OLE headers as the interface > identifier for IClassFactory). > This doesn't mean anything other than CoCreateInstance is usually used instead of CoGetClassObject (and CoCreateInstance always passes in IID_IClassFactory for the IID). > We can't pass riid to DllGetClassObject directly sometimes, causes some dlls' > DllGetClassObject (like native adsldp.dll) can only return reference-counted > pointer to class factory via IID_IClassFactory, for retrieving the > pointer to the > class object interface requested in riid, we must try another way. > Thank you for your patch, but this behaviour seems a little strange and needs a little more investigation before I am happy that it is correct. What parameters are being passed in to CoGetClassObject to cause the call to fail for you? -- Rob Shearman

5 12

re: Bugs in Wine research
by Dan Kegel June 14, 2008

June 14, 2008

tomecek wrote: > we are students from Department of computer science at Aalborg > university. During this semester we were working on project on static > analysis using the Coccinelle tool > (http://www.emn.fr/x-info/coccinelle/) and Flawfinder > (http://en.wikipedia.org/wiki/Flawfinder) We decided to search for > bugs in Wine source code. Great, thanks! We didn't have a wiki page about static analysis and Wine yet, so I created one, http://wiki.winehq.org/StaticAnalysis At least a couple of the memory leaks you found seem like they might be worth fixing. If you could put your full results up somewhere, and link to them from that wiki page, we'll take a look.

3 4

Re: Bugs in Wine research
by tomecek＠cs.aau.dk June 14, 2008

June 14, 2008

> Dan Kegel wrote: >> James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: >>>>> we are students from Department of computer science at Aalborg >>>>> university. During this semester we were working on project on static >>>>> analysis using the Coccinelle tool >>>> http://wiki.winehq.org/StaticAnalysis >>> I was wondering if results from Wine 0.9.57 would continue to be valid? >>> Maybe the effort could shift to RC1? >> >> Sure, lots of the unused vars bugs in particular are probably >> already fixed. But the other issues have a pretty good >> chance of still being valid. >> > > Are there any volunteers to do this? > > My experience with Wine C code is fairly minimal, but it shouldn't be > too hard to look at one of their changes and see if it applies to > current git, and if it does just forward-port it. > > Thanks, > Scott Ritchie > > > > Hi, the complete results are available at http://www.cs.aau.dk/~dechouxb/results/complete/, the scripts used at http://www.cs.aau.dk/~dechouxb/cocci_scripts/done/. It is valid for Wine 0.9.57. Sorry for the delay, we were very busy. Unfortunately we cannot rerun the tests because we are leaving Aalborg University in 3 weeks. If you are interested I should be able to rerun these tests (with some improvements) at my home university during late August and September. Jaroslav Tomecek ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 2

Re: user32: Allow a NULL foreground window in the tests
by Dmitry Timoshkov June 14, 2008

June 14, 2008

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > According to msdn, "The foreground window can be NULL in certain > circumstances, such as when a window is losing activation. " which is > exactly when these failures occur. > > Changelog: > * Allow a NULL foreground window in the tests. NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground. -- Dmitry.

2 11

Fixing crashes in Tests (OS version check)
by Alistair Leslie-Hughes June 4, 2008

June 4, 2008

Hi, I've being investigating crashes that occur on Win98 when the tests run. I have fixed a couple already which where trivial. When I attempted to fix the snmpapi tests, I have found that i will end up removing alot of tests (~ 17). If I add a check for the windows version, I can skip the tests that will crash, also there is already tests with if(0) around them. What is the policy about checking the version of the OS before running certain tests? Best Regards Alistair Leslie-Hughes

8 11

Winetest grrr...
by Juan Lang June 2, 2008

June 2, 2008

Since my tiny little menu patch didn't go in, I figured Alexandre wanted a test. So I tried to compile and run the existing one on Windows XP. It failed for me: lots of menu size tests failed. I checked the test.winehq.org data, and I don't see lots of failures on XP, so... I thought I'd run winetest.exe from Paul Millar's site, just in case the compilation environment had something to do with it. That locks up my laptop somewhere in the d3d/ddraw tests. I know some video drivers are so broken we don't want to run on them. I have an ATI Radeon Mobility 250. I thought this was a fairly common card. Is locking up the machine really acceptable here? How the ^$*@ am I supposed to produce a test when the existing ones fail/crash/burn for me? Grrr... --Juan

5 9

Re: [2/2] ddraw: Rename IDirectDraw functions (try 2)
by Christian Costa June 1, 2008

June 1, 2008

Hi Michael, I think it would be better to fix function names in IDirectDraw7. Christian Michael Karcher a écrit : > The functions implementing IDirectDraw are called IDirectDrawImpl_Foo, > the ones implementing IDirectDraw7 are called alike. As they are > static functions in different files, the compiler has no problems > distinguishing them, but it confuses the reader of TRACE messages. > --- > dlls/ddraw/ddraw_thunks.c | 92 ++++++++++++++++++++++---------------------- > 1 files changed, 46 insertions(+), 46 deletions(-) > > ------------------------------------------------------------------------ > >

3 3

Re: ddraw: Don't release ddraw if a surface is still using it.
by Michael Karcher May 31, 2008

May 31, 2008

Am Samstag, den 31.05.2008, 12:08 +0200 schrieb Jens Albretsen: The patch looks like it would work as advertised, but the following snippet in the testcase smells fishy: > +static unsigned long getRefcount(IUnknown *iface) > +{ > + IUnknown_AddRef(iface); > + return IUnknown_Release(iface); > +} [...] > + IDirectDraw_Release(lpDD); > + > + ref = getRefcount(lpDD); > + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); > + > + IUnknown_Release(surface); The IDirectDraw_Release seems to be dropping the reference count of the DirectDraw object to zero. This is OK, of course, as you might well drop the last reference. But this might put the DirectDraw object into a state where AddRef crashes, as parts of the object might get destroyed when the reference count drops down to zero. On wine, there is obviously no problem, as wine keeps the DirectDraw object itself alive for longer. On Windows, it is not clear to me that the DirectDraw object is not destroyed at the IDirectDraw_Release, the only thing we know is, that Direct Draw still is working (perhaps implemented by a subobject of the DirectDraw object which keeps living). I suggest to alternatively write the second part as + ref = IDirectDraw_Release(lpDD); + ok(ref == 0, "Got refcount %ld, expected 0\n", ref); + + IUnknown_Release(surface); Regards, Michael Karcher

3 3

MinGW RPM packages - discontinued
by Hans Leidekker May 31, 2008

May 31, 2008

Hi all, This is a message for those who used or contributed to the cross compiler packages available from this URL: http://mirzam.it.vu.nl/mingw/ Quoting myself from that page: I have decided to stop maintaining these packages. The original incentive to create these packages was to be able to build Wine's test suite as PE executables on Fedora. Wine recently changed its build system to use Wine's own headers and import libraries when cross compiling the test suite, which means that the mingw-w32api package (where most of the action was) is no longer needed. Another reason is that I'm moving towards Ubuntu as my main development platform. -Hans

3 3

Re: #1 wininet: Make resolving hostnames thread-safe. try2
by Rob Shearman May 31, 2008

May 31, 2008

2008/5/31 Hans Leidekker <hans(a)it.vu.nl>: > Make resolving hostnames thread-safe. > > +/* critical section to protect non-reentrant gethostbyname() */ > +CRITICAL_SECTION cs_gethostbyname; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &cs_gethostbyname, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": cs_gethostbyname") } > +}; > +CRITICAL_SECTION cs_gethostbyname = { &critsect_debug, -1, 0, 0, 0, 0 }; cs_gethostbyname should be static. -- Rob Shearman

1 0

Re: Fix debug log incosistencies and function naming
by Vitaliy Margolen May 31, 2008

May 31, 2008

Michael Karcher wrote: > Debugging DirectDraw reference counting is confusing, > as the IDirectDraw{,2,3,4}_AddRef methods dump to ddraw_thunk, > whereas the matching Release methods dump to ddraw. This > patch changes to consistently use the ddraw channel. > > Furthermore, as the methods from IDirectDraw7 are named > like "IDirectDrawImpl_Foo", the functions from IDirectDraw > (Direct Draw 1) get renamed to "IDirectDraw1Impl_Foo" to > avoid non-unique function names in trace logs. > --- Please make it two patches. One to change debug channel. Second to rename IDirectDrawImpl into IDirectDraw1Impl. Vitaliy.

1 0

Re: winex11.drv: Place tablet cursors in slots based on type
by James Hawkins May 31, 2008

May 31, 2008

On Sat, May 31, 2008 at 12:19 PM, John Klehm <xixsimplicityxix(a)gmail.com> wrote: > This patch looks bigger than it really is. A more detailed changelog is this: > No, it's as big as it seems. > - I've added a lot of comments describing how cursor slotting works. > - added code to slot the cursor appropriately from the get go > - use local memory to temporarily store cursor info before slotting it > (this change results in a lot of inserts deletes of '->' to '.' ) > - iterate through cursors with CURSORMAX and ACTIVE instead of gNumCursors > - cursors will always have a type now: PEN, ERASER, or OTHER > - removed cursor slot fixup code. no longer needed > - removed counters used to place the cursor in slot. no longer needed > Each one of those items should be a separate patch. -- James Hawkins

1 0

Re: dxdiagn: PhysicalMemory parameter is a string not long long
by Vitaliy Margolen May 31, 2008

May 31, 2008

Vitaliy Margolen wrote: > --- > dlls/dxdiagn/provider.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > Was anything wrong with this patch? I've used a simple utility DxDiagOutput.exe from DXSDK to find and test this. Vitaliy.

2 4