September 2006 - Wine-Devel

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

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches. P.S. I won't be available from the 15th for about a week or so. So, if you have any questions, I'm afraid you might have to be patient. Hope this is of interest to someone -Rob. ******Applications: Current status*********** ***In Painter 5 *Cursor pressure works. (Therefore is usable by most) *Cursor orientation is a little odd: The orientation maths needs to be re-done. *No eraser. Haven't yet cracked what enables the eraser. *Doesn't work in desktop mode: Need to map to desktop coordinates. *Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) *Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions. ***In Photoshop 6. *Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode. * Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs. *******To Do************* 1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this) 2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done. 3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen) 4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows. 5. Tests ~ --My current philosophy on tests is... ~ Use Photoshop & Painter, any formal tests ~ can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict. **********Long term to do (Anyone interested?):********* There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;) 1. Improve configuration of wintab. Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file. 2. Handle Z-Order of context properly. This entails *sharing Z-Order between apps. *Working out exactly what role windows have in determining tablet context z-orders. *Allow tablet contexts that don't cover the whole screen/tablet. *Handle inter-application clipping of tablet contexts *Allow all application's windows to receive tablet events when tablet context is on top 3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse) 4. Unicodify 5. Implement various wintab extensions. 6. Implement wintab manager functions. 7. Tests. *********Unknowns********* 1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop? 2. How Painter detects the eraser. Have 3 possibilities i. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!) ii. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only). iii. I've missed something 3. Requirements of other applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s /ZKMUGwQOuw/SIIbOkIUbd0= =R4M7 -----END PGP SIGNATURE-----

2 1

Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1
by Vitaliy Margolen Feb. 19, 2007

Feb. 19, 2007

Same as before. Just recompiled with new version. http://www.kievinfo.com/wine-0.9.18-1.2.i586.rpm http://www.kievinfo.com/wine-0.9.18-1.2.src.rpm -- Best regards, Vitaliy

3 3

Font issue - workaround found
by Timm Feb. 18, 2007

Feb. 18, 2007

My one win app that makes me a devotee of WINE is TablEdit (demo at www.tabledit.com/download/tabled32.exe) has a custom font , tef260.ttf, that has failed to display since somewhere after ver 9.6. The program installs the font into c:\windows\font, but can not display it within the program, instead displaying for the most part, empty squares. I tried putting/removing tef260.ttf into /usr/local/share/wine/fonts, /usr/local/share/fonts, and the wine windows/fonts directories in all permutations. The only way I got it to display was to remove ALL fonts from these three directories and install tef260.ttf into an X11 font directory along with other win ttf fonts. This forces WINE to build a cachedmetrics file like it used to, and the font is displayed properly in the program. Hope this is a clue for some developer, as I merely lurk here, looking for clues about wine behavior. I can't do a regression back to ver 9.6 (the version I was using that last worked) because my upgrades to freetype cause it to complain of missing functions. current (pertinent ? ) specs libfreetype.so.6.3.7 ] built from source libfontconfig.so.1.0.4 ] built from source fontforge 20060715 ] built from source WINE 0.9.20 ] built from source kernel 2.6.17.11 Slack current (10.2, with upgrades from "current" tree) -- Timm

3 2

re: What operating systems will Winelib run on non-x86 systems?
by Dan Kegel Nov. 21, 2006

Nov. 21, 2006

Hi Wei Li, last year, you asked in http://www.winehq.org/hypermail/wine-users/2004/06/0086.html > I could not find the info regarding what operating systems > (such as AIX 5L v5.2, HP-UX 11i, Solaris Release Level > 9) will Winelib run on non-x86 machines. I'll really > appreciate it if someone can provide my related link or > info. I can only find the following link regarding the > supporting OS but it does not provide Winelib's supporting > OS info: > http://www.winehq.org/site/docs/wine-faq/index 3.1. > Under what hardware > platform(s) and operating system(s) will Wine(Lib) run? I'm sorry nobody got back to you -- the wine-devel mailing list might have been a better place to ask. I believe winelib runs on the following non-x86 operating systems: Linux, Solaris, Mac OS X, and FreeBSD. There's no reason in principle it couldn't run on AIX or HP/UX. Some work has been done on an HP/UX port, but some assembly would be required to complete it: http://www.winehq.com/site/?issue=241#HP-UX%20Port Cheers, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

re: Wine-wiki broken by design
by Dan Kegel Nov. 16, 2006

Nov. 16, 2006

Maybe the wine wiki could publish a machine-readable sitemap; see http://www.xml-sitemaps.com/ http://www.google.com/webmasters/sitemaps/docs/en/about.html That would put less load on the server than letting Yahoo and Google crawl the wiki themselves. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

Bugs with new 'installer' keyword
by Dan Kegel Nov. 3, 2006

Nov. 3, 2006

I think the new 'installer' keyword is on every bug that needs it now. http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keyw… shows 94 downloadable apps with keyword 'installer'. Here's a breakdown by component: 24 wine-misc 17 wine-ole 15 wine-msi 7 wine-binary 6 wine-net 4 wine-x11 4 wine-msxml 3 wine-programs 3 wine-kernel 2 wine-user 2 wine-setupapi 2 wine-richedit 1 wine-shdocvw 1 Wine-Rebar 1 wine-msvcrt 1 wine-gdi-(printing) 1 wine-directx-d3d James is taking on the msi and setupapi ones, I think. Anyone else interested in plowing through these to see if we can resolve all the installer bugs before 1.0? - Dan

4 6

compiling wine for amd64 on ubuntu dapper 6.06
by Gerald Britton Oct. 18, 2006

Oct. 18, 2006

Hi -- I'm trying to get wine going on my ubuntu dapper installation on an amd 64 box. I have followed the wiki instructions in http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. Two things go wrong: 1. /configure can't find opengl, and produces these messages: configure: WARNING: Wine will be build without OpenGL or Direct3D support configure: WARNING: because something is wrong with the OpenGL setup: configure: WARNING: No OpenGL library found on this system. 2. make depend works, but make all fails with this: LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res version.rc ../../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 -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' make: *** [dlls] Error 2 I'm not sure what to do now. Any feedback/suggestions would be appreciated.

4 6

Appdb as application regression finder
by Dan Kegel Oct. 16, 2006

Oct. 16, 2006

The appdb has a "browse by ratings" page, e.g. you can see all apps that have at least one Gold-rated version at http://appdb.winehq.org/browse_by_rating.php?sRating=Gold This can serve as a kind of poor man's application regression finder; look at each app on that page, and look for apps whose latest version is rated lower than gold. For instance, WinZip is listed on the Gold page. WinZip 9 is indeed rated gold, but winzip 10 is only silver. Likesize, Sametime Connect has an old version rated gold, and a new one rated garbage. If nothing else, it would be great for someone to look at all such 'regressions', test them with current wine, and update the appdb and bugzilla with what they find. Who knows, maybe we can clear a few of these up without too much effort. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 11

Anybody have a RegDeleteTree[A|W] implementation lying around?
by Paul Vriens Oct. 11, 2006

Oct. 11, 2006

Hi, I was browsing some code and found that we have several places where we made our own implementation of a recursive delete of registry keys/value. Apparently there is an official one in Vista: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/ba… I don't know if somebody has this already lying around somewhere. If not, I'll have a go (not soon though). Would be a nice code cleanup, or are there any pitfalls? Cheers, Paul.

6 9

Please create wine-msxml and wine-setupapi components in bugzilla
by Dan Kegel Oct. 10, 2006

Oct. 10, 2006

Bugzilla currently lacks categories for several important parts of wine. This is natural - nothing's perfect. Rather than fix this all at one go, let's just add categories as we find we need them. I propose adding categories for msxml and setupapi now. Here are bugzilla queries that find quite a few bugs that are candidates for moving into those categories: http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=msxml… http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=setup… I think they show enough hits to make the categories worth it. IIRC, James Hawkins has said he thinks we need a setupapi category, so I'm not alone in this. The categories might help shake loose bugs like http://bugs.winehq.org/show_bug.cgi?id=2223 which have patches associated with them but haven't gotten any attention. The MSXML category will help me as I dredge together projects for cs130 to focus on... So, what does it take to create a new category? Can the admin just do it? We can move the appropriate bugs over to the new categories later. Thanks, Dan

4 6

Re: [PATCH 1/3] lz32/tests: Test more last errors set by LZOpenFile[AW].
by Dmitry Timoshkov Oct. 8, 2006

Oct. 8, 2006

"Saulius Krasuckas" <saulius.krasuckas(a)ieee.org> wrote: > memset(&filled_0xA5, 0xA5, OFS_MAXPATHNAME); > memset(&test, 0xA5, sizeof(test)); > full_file_path_name_in_a_CWD(filename_, expected, FALSE); > + SetLastError(0xfaceabee); Please use a usual value we all agreed to use: 0xdeadbeef. It makes sense to check last error value only if an API has failed, while you are adding last error checks everywhere. Unless you have an application that depends on it, that's wrong. -- Dmitry.

3 4

Re: [Tools/Wine.inf] Set Internet Explorer version
by Sven Paschukat Oct. 8, 2006

Oct. 8, 2006

Maarten Lankhorst schrieb: > Windows seems to set internet explorer only during a new installation or > upgrade of internet explorer, so I put it in wine.inf, which seemed > appropriate. > > Changelog: > Set version strings for Internet Explorer so programs dependent on it > can install. This breaks installation of real IE. Setting version to IE 5.5 would give the users a chance to install at least version 6.0. BTW, you should fix the typo in the third line. Sven

7 8

Re: clusapi: [RESEND] Implements stub dll for clusapi
by Robert Shearman Oct. 5, 2006

Oct. 5, 2006

Benjamin Arai wrote: > +@ stdcall -private DllMain(long long ptr) > There's no need to export DllMain. -- Rob Shearman

2 2

Re: Wine 0.9.21 fails to run
by Ken Zalewski Oct. 4, 2006

Oct. 4, 2006

Hi Nick, Thanks for the advice and patches. However, Wine still fails to run ANY programs at all. This is with both of the patches applied (the "ATI" patch and the "NVidia" patch). Moving back to 0.9.20 makes everything work again. My OpenGL library is from NVidia driver 8774 (the most recent), and x11 is 6.8.2. If there is anything you would like me to provide in order to diagnose this, let me know. Thanks. -kz Nick Law wrote: > Ken Zalewski wrote: >> I just upgraded from 0.9.20 to 0.9.21, and now nothing will run, >> including simple programs such as sol.exe and notepad.exe. >> >> The error message I'm receiving is: >> >> X Error of failed request: BadWindow (invalid Window parameter) >> Major opcode of failed request: 145 (NV-GLX) >> Minor opcode of failed request: 4 () >> Resource id in failed request: 0x242 >> Serial number of failed request: 19 >> Current serial number in output stream: 19 >> >> >> My system is a Slackware 10.2 system, running kernel 2.6.17.13, x11 >> 6.8.2, and NVidia driver 8774. >> >> I have seen some other postings on the Net about this, including >> postings in the Ubuntu forums (which means that this is not limited >> to Slackware). >> >> Downgrading to 0.9.20 gets everything working again. My guess, based >> on the "NV-GLX" message, is that something was changed in the OpenGL >> support between 0.9.20 and 0.9.21, and it has broken Wine. >> >> I'll be happy to help debug this. >> >> Sincerely, >> >> Ken Zalewski >> Slackware package maintainer >> Linuxpackages.net >> >> >> >> >> > That's correct, on the wow 1.12 AppDB page in the latest news section > you'll find two patches, the patch marked ATI ( or FBconfigregression > ) will fix the opengl & D3D problems. > > You can download and apply both irrespective of what graphics card you > have. > > Regards > Nick Law >

2 2

Re: LOSTWAGES: Instructions for getting additional modules
by Mike McCormack Oct. 3, 2006

Oct. 3, 2006

Detlef Riekenberg wrote: > When switching the Instructions for the Wine tree > from cvs to git, the Instructions for the > additional modules (docs, lostwages, ...) got lost. They're still available at the old link: http://www.winehq.org/site/cvs It would be nice to move the remaining modules to Git too, IMO. Mike

4 3

RFC: dlls/user/tests/win.c fix
by Juan Lang Oct. 3, 2006

Oct. 3, 2006

The attached patch (sorry, crappy mailer) fixes the win.c failure I was seeing. Is it correct? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 7

Scrambled VB Fonts improving.
by Joe Baker Oct. 2, 2006

Oct. 2, 2006

2 1

todo_wine problems
by Jeff L Oct. 1, 2006

Oct. 1, 2006

I am having trouble with getting todo_wine working. It seems to be ignored and the test is being executed on wine and failing as expected. Is there a trick to setting todo up? According to all the examples and the text this should work: todo_wine { ok(hr == S_OK, "ScriptStringOut Stub should return S_OK not %08lx\n", hr); } Jeff

4 3

Re: [PATCH] local fixes in ioctl for google video.
by Dmitry Timoshkov Sept. 30, 2006

Sept. 30, 2006

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > @@ -2125,6 +2125,13 @@ INT WINAPI WSAIoctl(SOCKET s, > > switch( dwIoControlCode ) > { > + case 0x8004667E: > + FIXME("8004667E: stub!\n"); > + break; > + case 0x4004667f: /* FIONREAD */ > + FIXME("4004667f/FIONREAD: stub, returning 1!\n"); > + *(DWORD*)lpbOutBuffer = 1; > + break; 0x8004667e is FIONBIO (set or clear non-blocking I/O). -- Dmitry.

1 0

str{n}casecmp(): unrecognized identifier
by Andrew Talbot Sept. 30, 2006

Sept. 30, 2006

Hi, It seems that, on my [x86_64] system, at least, string.h is not being included in the files where strcasecmp() or strncasecmp() is used (for example, in crypt32/oid.c), despite HAVE_STRCASECMP and HAVE_STRNCASECMP being defined as 1. I presume, because of the above defines, that just adding #include <string.h> ... in the affected files would not be a proper fix. I imagine it requires expert tweaking of the automake setup (or whatever) to ensure that this is done automatically (if it's not just a fault on my system), in which case I ask for suitable help, please. Thanks, -- Andy.

3 3

Re: [PATCH] Use correct headers for strcasecmp
by Mike McCormack Sept. 30, 2006

Sept. 30, 2006

Marcus Meissner wrote: > We need to include string.h and also wine/port.h > to get strcasecmp on platforms where it is missing. In Win32 code, shouldn't we be using lstrcmpi instead? Mike

1 0

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
by Mike McCormack Sept. 30, 2006

Sept. 30, 2006

Sam Dennis wrote: > +if PKG_CHECK_MINVER(fontforge, 20060406); then configure should check for features, not versions. This avoids problems with patched older versions or newer versions with features removed. To check for fontforge correctly, we need to check that it will generate a ttf file that works with Wine. The alternative is to fix up the sfd2ttf that somebody posted a month or two ago and use that so that we don't depend on fontforge. Mike

1 0

Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.
by Evil Jay Sept. 30, 2006

Sept. 30, 2006

The updates in yesterday's Git tree have broken compilation under 64-bit. Previously, it was working. I entered a bugzilla entry for it (http://bugs.winehq.org/show_bug.cgi?id=6304) but thought I would mention it here too - since I think it's a pretty big deal and it doesn't seem that many of the developers here are working under 64-bit (and therefore wouldn't notice the issue). ------------------------ ../../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 -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/data/install/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/data/install/wine/dlls' make: *** [dlls] Error 2 -J

2 1

Re: [D3D9] Remove const qualifier on state_test data.
by Michael Stefaniuc Sept. 30, 2006

Sept. 30, 2006

Ivan Gyurdiev wrote: > Type: Cleanup > > Why: > The const qualifier is unnecessarily restrictive. > I intend to allocate and free such data on the heap in a future patch. > Instead, const should be primarily used on function parameters. Question: do you realy have to use void pointers? Void pointers are compatible with every pointer type and thus will disable the type checking of the compiler. Also you do not need to to cast a rvalue to void * if the type of the lvalue is void *. bye michael > --- > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > 1 files changed, 20 insertions(+), 20 deletions(-) > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > index 65a11e6..68b431a 100644 > --- a/dlls/d3d9/tests/stateblock.c > +++ b/dlls/d3d9/tests/stateblock.c > @@ -105,20 +105,20 @@ typedef struct state_test { > * as the default data, but a write can have side effects. > * The initial data is tested first, before any writes take place > * The default data can be tested after a write */ > - const void* initial_data; > + void* initial_data; > > /* The default data is the standard state to compare > * against, and restore to */ > - const void* default_data; > + void* default_data; > > /* The test data is the experiment data to try > * in - what we want to write > * out - what windows will actually write (not necessarily the same) */ > - const void* test_data_in; > - const void* test_data_out; > + void* test_data_in; > + void* test_data_out; > > /* The poison data is the data to preinitialize the return buffer to */ > - const void* poison_data; > + void* poison_data; > > /* Return buffer */ > void* return_data; > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > shader_constant_arg* arg = buffer; > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > - test->test_data_in = &shader_constant_test_data; > - test->test_data_out = &shader_constant_test_data; > - test->default_data = &shader_constant_default_data; > - test->initial_data = &shader_constant_default_data; > - test->poison_data = &shader_constant_poison_data; > + test->test_data_in = (void*) &shader_constant_test_data; > + test->test_data_out = (void*) &shader_constant_test_data; > + test->default_data = (void*) &shader_constant_default_data; > + test->initial_data = (void*) &shader_constant_default_data; > + test->poison_data = (void*) &shader_constant_poison_data; > test->return_data = return_data; > test->data_size = sizeof(shader_constant_data); > test->set_handler = shader_constant_set_handler; > @@ -697,11 +697,11 @@ static void lights_queue_test( > light_arg* arg = buffer; > light_data* return_data = (light_data*) (arg + 1); > > - test->test_data_in = &light_test_data_in; > - test->test_data_out = &light_test_data_out; > - test->default_data = &light_default_data; > - test->initial_data = &light_initial_data; > - test->poison_data = &light_poison_data; > + test->test_data_in = (void*) &light_test_data_in; > + test->test_data_out = (void*) &light_test_data_out; > + test->default_data = (void*) &light_default_data; > + test->initial_data = (void*) &light_initial_data; > + test->poison_data = (void*) &light_poison_data; > test->return_data = return_data; > test->data_size = sizeof(light_data); > test->set_handler = light_set_handler; > @@ -856,11 +856,11 @@ static void transform_queue_test( > { > transform_data* return_data = buffer; > > - test->test_data_in = &transform_test_data; > - test->test_data_out = &transform_test_data; > - test->default_data = &transform_default_data; > - test->initial_data = &transform_default_data; > - test->poison_data = &transform_poison_data; > + test->test_data_in = (void*) &transform_test_data; > + test->test_data_out = (void*) &transform_test_data; > + test->default_data = (void*) &transform_default_data; > + test->initial_data = (void*) &transform_default_data; > + test->poison_data = (void*) &transform_poison_data; > test->return_data = return_data; > test->data_size = sizeof(transform_data); > test->set_handler = transform_set_handler; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
by Vitaliy Margolen Sept. 30, 2006

Sept. 30, 2006

Sam Dennis wrote: > aclocal.m4 | 16 ++++++++++++++++ > configure.ac | 6 +++++- > 2 files changed, 21 insertions(+), 1 deletions(-) > You missing change log. Please don't forget to include it in the email body not just subject. Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy.

2 1

Vista applications that work & those that don't
by Nick Law Sept. 30, 2006

Sept. 30, 2006

I thought this may be of interest... applications that work and those that don't in Vista RC1 It would be interesting on how this same list compares with wine 0.9.22 http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_… and the hardware compatibility list .. http://www.iexbeta.com/wiki/index.php/Windows_Vista_RC_1_Hardware_Compatibi… I don't believe Microsoft's official list has been made public yet, although they said they would sometime! Nick

1 0

Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
by Michael Stefaniuc Sept. 29, 2006

Sept. 29, 2006

Juan Lang wrote: > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 Ignoring VT_ERROR just masks a previous error. bye michael > Index: dlls/shdocvw/webbrowser.c > =================================================================== > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > retrieving revision 1.65 > diff -u -r1.65 webbrowser.c > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > @@ -675,7 +675,7 @@ > if(V_VT(URL) != VT_BSTR) > return E_INVALIDARG; > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > || V_ARRAY(PostData)->cDims != 1) { > WARN("Invalid PostData\n"); > @@ -686,7 +686,7 @@ > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > } > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > if(V_VT(Headers) != VT_BSTR) > return E_INVALIDARG; > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 3

Re: [PATCH 0/4] Janitorial: Win64 printf format warning fixes
by Michael Stefaniuc Sept. 29, 2006

Sept. 29, 2006

Michael Stefaniuc wrote: > For all the people wanting to help out with this janitorial task please > wait until Alexandre commits this patch series. After that i'll create a > page for this task on the Wine wiki and link it from > http://wiki.winehq.org/JanitorialProjects Ok, this janitorial task has now a Wiki page: http://wiki.winehq.org/Win64PrintfFormatWarnings This is a good opportunity for anybody that wants to start submitting patches for Wine and get accustomed to this process. > I will put in a download link for my perl script that can automaticly > fix around 20000 out of the remaining 25000 warnings. You realy do not > want to go manualy over 25k warnings. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Can't open DLL's without sudo
by Paul Wilkinson Sept. 29, 2006

Sept. 29, 2006

I'm running wine v 0.9.20 under Fedora Core 5. I'm trying to get the Syncrosoft License Control Center to run under wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I put 'sudo' on the command line: [paul(a)localhost LCC]$ wine LCC.exe err:module:import_dll Library MFC42.DLL (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\windows\\system32\\MSVCP60.dll") not found err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe" failed, status c0000135 [paul(a)localhost LCC]$ The NtOpenFile that tries to open the DLL (in loader.c) is returning c00000022 (ACCESS_DENIED). But the permissions for these DLL's are wide open. Any idea what's going on? - Paul

4 4

crypt32/sip: new test failures
by Marcus Meissner Sept. 29, 2006

Sept. 29, 2006

Hi, ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so sip.c && touch sip.ok sip.c:176: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:177: Test failed: Expected ERROR_SUCCESS, got 0x00000002 sip.c:179: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:187: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:188: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:190: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:199: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:200: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:202: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). fixme:crypt:CryptSIPLoad ((null) 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({7b845773-cc00-7ffd-0000-00003b933460} 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 1 0x33fda0) stub! make[2]: *** [sip.ok] Fehler 9 I did run "wineprefixcreate" before (just in case). Ciao, Marcus

1 0

Re: wine-devel Digest, Vol 14, Issue 93
by Anton Litvinov Sept. 29, 2006

Sept. 29, 2006

----- Original Message ----- From: <wine-devel-request(a)winehq.org> To: <wine-devel(a)winehq.org> Sent: Friday, September 29, 2006 8:58 PM Subject: wine-devel Digest, Vol 14, Issue 93 > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: Governance Ideas (Mike McCormack) > 2. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Michael Stefaniuc) > 3. Re: make test failure (Michael Stefaniuc) > 4. Re: [D3D9] Remove const qualifier on state_test data. > (Michael Stefaniuc) > 5. compiling wine for amd64 on ubuntu dapper 6.06 (Gerald Britton) > 6. Re: make test failure (Vitaliy Margolen) > 7. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Juan Lang) > 8. Re: USER32: Stub implementation of BlockInput (Juan Lang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Sep 2006 18:02:08 +0900 > From: Mike McCormack <mike(a)codeweavers.com> > Subject: Re: Governance Ideas > To: bobl(a)optushome.com.au > Cc: wine-devel(a)winehq.com, Alexandre Julliard <julliard(a)winehq.org> > Message-ID: <451CE110.5000708(a)codeweavers.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > Robert Lunnon wrote: > > > "Community Focused Process" means what it says, develop a process which is > > centred on the community the project serves. This requires the project to > > answer some introspective questions > > > > 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community > > it serves. > > A) Alexandre is a benelovent dictator. He manages Wine with the > interests of "the community" in mind, as he sees them. > > > 1. Answer the questions about the "ownership" of wine and identify the > > community it serves. Determine the right of the community to be involved is > > setting wines direction IE The Bill of rights I mentioned before (for each > > community Developers VS Users etc). > > Your "bill of rights" is the Wine license, the LGPL. > > > 2. Alexandre documents the exact logic he uses to determine patch > > acceptability which becomes the patch acceptance policy in the interim. > > It's very likely impossible to write that down. If you don't agree with > me, please write down your proposal. > > > 3. The project develops a community process for establishing project direction > > and maintaining the patch acceptance policy which includes stakeholders > > elected from the "owners" IE communities with a stakeholding in wine > > NetBSD is a project that is (was?) run by committees: > > http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html > > If you want Wine to be run by a committee, how about creating your own > fork so you can run it as you see fit? > > Mike > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Sep 2006 10:57:26 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: juan_lang(a)yahoo.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CDFF6.5060904(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Juan Lang wrote: > > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 > Ignoring VT_ERROR just masks a previous error. > > bye > michael > > > Index: dlls/shdocvw/webbrowser.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > > retrieving revision 1.65 > > diff -u -r1.65 webbrowser.c > > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > > @@ -675,7 +675,7 @@ > > if(V_VT(URL) != VT_BSTR) > > return E_INVALIDARG; > > > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > > || V_ARRAY(PostData)->cDims != 1) { > > WARN("Invalid PostData\n"); > > @@ -686,7 +686,7 @@ > > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > > } > > > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > > if(V_VT(Headers) != VT_BSTR) > > return E_INVALIDARG; > > > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Sep 2006 10:59:02 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451CE056.5000702(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > James Hawkins wrote: > > On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > > >> James Hawkins wrote: > >> > On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >> >> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >> >> > Hi, > >> >> > > >> >> > Running make test fails with: > >> >> > > >> >> > make[2]: Entering directory > >> `/usr/local/src/wine/dlls/comctl32/tests' > >> >> > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >> >> > comctl32_test.exe.so tab.c && touch tab.ok > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >> [56,20] > >> >> > make[2]: *** [tab.ok] Error 6 > >> >> > > >> >> Succeeds over here. > >> >> > >> > > >> > I know, it succeeds on a lot of machines, but the point is that it > >> > shouldn't fail on any machine. > >> > > >> Please remove your ~/.wine dir and try again. It seems your metrics are > >> set different. Or your fonts are wrong. > >> > > > > The tests still fail with a clean .wine. > Yes, i used an empty .wine too. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Sep 2006 12:33:27 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: [D3D9] Remove const qualifier on state_test data. > To: ivg231(a)gmail.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CF677.1040305(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Ivan Gyurdiev wrote: > > Type: Cleanup > > > > Why: > > The const qualifier is unnecessarily restrictive. > > I intend to allocate and free such data on the heap in a future patch. > > Instead, const should be primarily used on function parameters. > Question: do you realy have to use void pointers? Void pointers are > compatible with every pointer type and thus will disable the type > checking of the compiler. Also you do not need to to cast a rvalue to > void * if the type of the lvalue is void *. > > bye > michael > > > --- > > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > > 1 files changed, 20 insertions(+), 20 deletions(-) > > > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > > index 65a11e6..68b431a 100644 > > --- a/dlls/d3d9/tests/stateblock.c > > +++ b/dlls/d3d9/tests/stateblock.c > > @@ -105,20 +105,20 @@ typedef struct state_test { > > * as the default data, but a write can have side effects. > > * The initial data is tested first, before any writes take place > > * The default data can be tested after a write */ > > - const void* initial_data; > > + void* initial_data; > > > > /* The default data is the standard state to compare > > * against, and restore to */ > > - const void* default_data; > > + void* default_data; > > > > /* The test data is the experiment data to try > > * in - what we want to write > > * out - what windows will actually write (not necessarily the same) */ > > - const void* test_data_in; > > - const void* test_data_out; > > + void* test_data_in; > > + void* test_data_out; > > > > /* The poison data is the data to preinitialize the return buffer to */ > > - const void* poison_data; > > + void* poison_data; > > > > /* Return buffer */ > > void* return_data; > > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > > shader_constant_arg* arg = buffer; > > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > > > - test->test_data_in = &shader_constant_test_data; > > - test->test_data_out = &shader_constant_test_data; > > - test->default_data = &shader_constant_default_data; > > - test->initial_data = &shader_constant_default_data; > > - test->poison_data = &shader_constant_poison_data; > > + test->test_data_in = (void*) &shader_constant_test_data; > > + test->test_data_out = (void*) &shader_constant_test_data; > > + test->default_data = (void*) &shader_constant_default_data; > > + test->initial_data = (void*) &shader_constant_default_data; > > + test->poison_data = (void*) &shader_constant_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(shader_constant_data); > > test->set_handler = shader_constant_set_handler; > > @@ -697,11 +697,11 @@ static void lights_queue_test( > > light_arg* arg = buffer; > > light_data* return_data = (light_data*) (arg + 1); > > > > - test->test_data_in = &light_test_data_in; > > - test->test_data_out = &light_test_data_out; > > - test->default_data = &light_default_data; > > - test->initial_data = &light_initial_data; > > - test->poison_data = &light_poison_data; > > + test->test_data_in = (void*) &light_test_data_in; > > + test->test_data_out = (void*) &light_test_data_out; > > + test->default_data = (void*) &light_default_data; > > + test->initial_data = (void*) &light_initial_data; > > + test->poison_data = (void*) &light_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(light_data); > > test->set_handler = light_set_handler; > > @@ -856,11 +856,11 @@ static void transform_queue_test( > > { > > transform_data* return_data = buffer; > > > > - test->test_data_in = &transform_test_data; > > - test->test_data_out = &transform_test_data; > > - test->default_data = &transform_default_data; > > - test->initial_data = &transform_default_data; > > - test->poison_data = &transform_poison_data; > > + test->test_data_in = (void*) &transform_test_data; > > + test->test_data_out = (void*) &transform_test_data; > > + test->default_data = (void*) &transform_default_data; > > + test->initial_data = (void*) &transform_default_data; > > + test->poison_data = (void*) &transform_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(transform_data); > > test->set_handler = transform_set_handler; > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Sep 2006 09:06:48 -0400 > From: "Gerald Britton" <gerald.britton(a)gmail.com> > Subject: compiling wine for amd64 on ubuntu dapper 6.06 > To: wine-devel(a)winehq.org > Message-ID: > <5d1a32000609290606u56007017t6f8ace8de14bb0ab(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi -- I'm trying to get wine going on my ubuntu dapper installation on > an amd 64 box. I have followed the wiki instructions in > http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. > Two things go wrong: > > 1. /configure can't find opengl, and produces these messages: > > configure: WARNING: Wine will be build without OpenGL or Direct3D support > configure: WARNING: because something is wrong with the OpenGL setup: > configure: WARNING: No OpenGL library found on this system. > > 2. make depend works, but make all fails with this: > > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > --nostdinc -I. -I. -I../../include -I../../include > -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res > version.rc > ../../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 -o > gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a > -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > make[2]: *** [gdi32.dll.so] Error 2 > make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' > make[1]: *** [gdi] Error 2 > make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' > make: *** [dlls] Error 2 > > > > I'm not sure what to do now. Any feedback/suggestions would be appreciated. > > > > ------------------------------ > > Message: 6 > Date: Fri, 29 Sep 2006 07:36:58 -0600 > From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451D217A.4060808(a)kievinfo.com> > Content-Type: text/plain; charset=UTF-8 > > Michael Stefaniuc wrote: > > James Hawkins wrote: > >> On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > >> > >>> James Hawkins wrote: > >>>> On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >>>>> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Running make test fails with: > >>>>>> > >>>>>> make[2]: Entering directory > >>> `/usr/local/src/wine/dlls/comctl32/tests' > >>>>>> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >>>>>> comctl32_test.exe.so tab.c && touch tab.ok > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >>> [56,20] > >>>>>> make[2]: *** [tab.ok] Error 6 > >>>>>> > >>>>> Succeeds over here. > >>>>> > >>>> I know, it succeeds on a lot of machines, but the point is that it > >>>> shouldn't fail on any machine. > >>>> > >>> Please remove your ~/.wine dir and try again. It seems your metrics are > >>> set different. Or your fonts are wrong. > >>> > >> The tests still fail with a clean .wine. > > Yes, i used an empty .wine too. > > > And you guys have windows like "Arial" font? Any test that uses fonts > will not work if you don't have that font or it's not the same metrics > as the native one. > > Vitaliy. > > > > ------------------------------ > > Message: 7 > Date: Fri, 29 Sep 2006 08:36:46 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: Michael Stefaniuc <mstefani(a)redhat.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929153646.65850.qmail(a)web30008.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > > Ignoring VT_ERROR just masks a previous error. > > Hm.. are you sure? These are input arguments, not results. This isn't > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > Message: 8 > Date: Fri, 29 Sep 2006 09:57:35 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: USER32: Stub implementation of BlockInput > To: Jason Green <jave27(a)gmail.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929165735.77898.qmail(a)web30010.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > You forgot the patch.. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > End of wine-devel Digest, Vol 14, Issue 93 > ******************************************

1 0

Re: make test failure #6
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

Hi James, > make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so sysparams.c && touch sysparams.ok > sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 > sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 > make[2]: *** [sysparams.ok] Error 4 This, like many other errors, disappears for me when I rerun make test. (I'm not too happy with the 'rerun make test' option, but I don't see people falling all over themselves up to fix the tests, either.) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[rsaenh-test]: import&export of a plaintext public key + algID check
by Karsten Elfenbein Sept. 29, 2006

Sept. 29, 2006

* test for importing a PlainPublicKey * test for the correct ALG_ID after the import * test for the correct PlainPublicKey after exporting the key again Karsten

1 0

make test failure (#7?)
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

After I run make test a bunch of times to get other failures to disappear, I get this: make[2]: Entering directory `/home/juan/src/wine-20050725/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c && touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2554: Test failed: message 000f available make[2]: *** [win.ok] Error 1 make[2]: Leaving directory `/home/juan/src/wine-20050725/dlls/user/tests' make[1]: *** [user/tests/__test__] Error 2 make[1]: Leaving directory `/home/juan/src/wine-20050725/dlls' make: *** [dlls/__test__] Error 2 --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: shdocvw: Make sure BSTR is allocated before calling sink
by Jacek Caban Sept. 29, 2006

Sept. 29, 2006

Hi Cihan, Cihan Altinay wrote: > This fixes bug 6054 and let's MSN Messenger 7 start up. > http://bugs.winehq.org/show_bug.cgi?id=6054 > > --- > dlls/shdocvw/dochost.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shdocvw/dochost.c b/dlls/shdocvw/dochost.c > index 5bb40e0..8d78a49 100644 > --- a/dlls/shdocvw/dochost.c > +++ b/dlls/shdocvw/dochost.c > @@ -49,11 +49,12 @@ static void navigate_complete(DocHost *T > V_DISPATCH(params+1) = disp; > > V_VT(&url) = VT_BSTR; > - V_BSTR(&url) = This->url; > + V_BSTR(&url) = SysAllocString(This->url); > > call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams); > call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams); > > + SysFreeString(This->url); You should free V_BSTR(&url) here, not This->url. Jacek

1 0

make test failure
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c && touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 -- James Hawkins

4 8

Re: USER32: Stub implementation of BlockInput
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

You forgot the patch.. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Governance Ideas
by Robert Lunnon Sept. 29, 2006

Sept. 29, 2006

Alexandre said ========================================= To be honest, I have no idea what it is that you are suggesting. All I see is phrases like "community focused process" or "acceptance policy" which frankly are just meaningless buzzwords. If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice, and how it would be different from what we are doing now. -- Alexandre Julliard julliard(a)winehq.org ========================================== To which I said I would respond soon - well here goes. From the outset I want to say that I am not going to redefine the wine project or make suggestions in the sense of a particular change. I want the communities of developers users and others to define that change. What I will do here is suggest ways in which we could organise to make a change as a collective. Firstly the buzzwords "Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves. 2 If the answer is B then which community. It may surprise some to realise that a project like this has many communities. We discovered this when setting up the OpenSolaris community process. Some obvious ones are "The Developer Community" and "The User Community" and "Developer + User" Community. There are other less obvious communities, eg the community of distribution maintainers who may be neither developer or user. If we decide that the community "Owns" Wine then it needs to be established whether the community has a right to direct wine's development. As the "Owner" I'd argue the community should have this right. Second Buzzword "Patch Acceptance Policy" means the rules by which a patch is deemed acceptable or not. At the moment this is pretty close to "It's acceptable if Alexandre commits it" This is OK in a community process as long as the community that wine serves supports this approach. I think the recent thread throws significant doubt on this. This particular patch acceptance policy is not Transparent, this is the key reason why dropped patches cause so much argument, why many developers leave the project and possibly why Wine doesn't get the major backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project is risky business. Now what do I propose... 1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine 4. A community process is run to A.) Establish the communities objective for wine - this will actually probably be reasonably argumentative, but that is exactly how it should be. If it's not there is probably something wrong. It was with OpenSolaris and governance was the greatest concern with that project too. B) review the Patch acceptance policy in line with the community objective. For example the policy may be adjusted to favour functionality improvements, or loosen gating on changes leading to solutions that wine critically needs or even establish a "must have" application. 5. A mechanism is created to independently review patches (appeal process) for acceptability IE Whether a patch meets the acceptance policy. Note that if a patch acceptable to the policy is rejected then the policy may need to change (Requiring a new community process to review that change) or an architectural decision needs to be taken. This is done by the architecture review board in the OpenSolaris process. Among other things when a patch is sent to appeal the owner of the patch is guaranteed an explanation of how the patch doesn't meet the acceptance policy. Now if we did all this we would * Have a picture of the needs of the community * Have a way to direct the project toward meeting that need * Have a way to demonstrate we intend to meet that need * Have a consistent review process for patches * Have a way to multistream patches * Have an open transparent, trusting and consistent environment in which to work * Have a way to change and grow * Open ways to allow business to confidently invest in Wine. Even if we ended up with exactly what we have now we will have improved transparency resulting in higher quality of work and less resentment of the process, improving developer retention rates and reducing disputes. Bob

6 5

make test failure #3
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 make[2]: *** [shlfileop.ok] Error 1 -- James Hawkins

2 1

make test failure #5
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected 0000 - actual 0021 msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected 0000 - actual 0014 make[2]: *** [msg.ok] Error 3 -- James Hawkins

2 2

make test failure #2
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c && touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 -- James Hawkins

3 3

make test failure #6
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, This is with a clean .wine. make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 make[2]: *** [sysparams.ok] Error 4 -- James Hawkins

1 0

make test failure #4
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[0]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[1]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[2]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[3]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) make[2]: *** [monitor.ok] Error 4 -- James Hawkins

1 0

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 28, 2006

Sept. 28, 2006

On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: > Again as mentioned by Huw, the gdi32.spec file wasn't correct. > It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw.

2 1

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
by Vitaliy Margolen Sept. 28, 2006

Sept. 28, 2006

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. > > - Thomas > It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. Vitaliy.

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp Sept. 28, 2006

Sept. 28, 2006

> From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > > So in a sense you will require some one to respond for any > incoming e-mail to wine-patches. And if no one does, > Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. > What if he already > applied the patch? Now you slowing down what would have > worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. > Ok now you making it dependant on an e-mail client. Yet > that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. > Not really. You can't make some one to review something that > don't understand. Or if they are busy/on vacation/away from > PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. > So in the end you'll end up with either huge queue > that no one wants to touch. Or a "clean up" jobs that will > once in a while go and mark all patches as old and will > require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html > When people well send out right hacks and expect some one to > tell then what they really should do. Current system allows > to no waste any time on such craft. We seem to have fundamentally different views of the "peripheral" (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. > No, by requiring some one to respond you making them > responsible (at least until they respond). Of course > responses like "sucks" wouldn't be nice, so some one who does > understand the subject will have to spend their time to > understand the patch, write a review of the patch and send > it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? > And you want that ASAP! Which means whenever patch > arrives in wine-patches some one (most likely more then one > person) will stop everything they are doing, and start > writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.

4 6

Award for solving bug 6183
by Mirek Sept. 28, 2006

Sept. 28, 2006

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: Setupapi: add stubs [resend]
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

Julien <julienc(a)psychologie-fr.org> writes: > +/*********************************************************************** > + * SetupDiDestroyClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} > + > +/*********************************************************************** > + * SetupDiGetClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiGetClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} It makes no sense to set last error if you return success. And you really shouldn't return success unless you also store the right things in that data structure. -- Alexandre Julliard julliard(a)winehq.org

1 0

Award for solving bug 6183
by Mirek Sept. 28, 2006

Sept. 28, 2006

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: msi: Implement MsiDatabaseImport [try2]
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR msi_read_text_archive(LPCWSTR path) > { > - FIXME("%p %s %s\n", db, debugstr_w(folder), debugstr_w(file) ); > + HANDLE file; > + LPSTR data = NULL; > + DWORD read, size = 0; > + > + file = CreateFileW( path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL ); > + if (file == INVALID_HANDLE_VALUE) > + return NULL; > + > + size = GetFileSize( file, NULL ); > + data = msi_alloc( size + 1 ); > + if (!data) > + return NULL; > + > + if (!ReadFile( file, data, size, &read, NULL )) > + return NULL; > + > + data[size] = '\0'; > + return strdupAtoW( data ); > +} You're leaking both the file and the ascii string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Coverity coverage of Wine
by Paul Vriens Sept. 28, 2006

Sept. 28, 2006

Hi, the latest run (with report) on the Coverity site seems to be from July 21st. It appears that the main page is updated though (not for the lines of code but for the errors fixed). Does anybody know more about the why? I've tried to contact Coverity for the last month and my last email (where I've requested a read-receipt, shame on me) was deleted without being read. Cheers, Paul.

2 5

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 28, 2006

Sept. 28, 2006

On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote: > As mentioned by Huw, I forgot to attach the gdi32.spec changes :( > This is (hopefully) a full patch. > > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 > +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 > @@ -396,5 +396,5 @@ > @ stdcall wglSwapLayerBuffers(long long) > @ stdcall wglUseFontBitmapsA(long long long long) > @ stdcall wglUseFontBitmapsW(long long long long) > -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) > -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) > +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA > +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You're still forwarding the wrong set of UseFont functions here. Your patch moved wglUseFontBitmaps to gdi32, so you should forward those not wglUseFontOutlines. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: oleaut32 1/2: [RESEND 2] Implements function varformat:VarWeekdayName
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); iFirstDay == 0 is supposed to mean system default, but that is locale-dependent, you can't simply hardcode it. -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d base GLX requirement
by Ivan Gyurdiev Sept. 28, 2006

Sept. 28, 2006

The current base GLX requirement for wined3d seems to be v1.3. It won't compile otherwise... I wrote a patch for pbuffers, which adds proper extension support for SGIX_PBUFFER and SGIX_FBCONFIG, but: - even with the patch there's additional offenders in directx.c that prevent a compile with glx < 1.3 [ more FBCONFIG dependencies ] - there's comments in the source saying ATI supports pbuffers, but only advertises GLX_VERSION_1_3, without the appropriate extensions. So - should GLX 1.3 be considered a base requirement for wined3d, or should I send patches to clean up pbuffer dependencies?

5 6

Linklint results for winehq
by Tom Wickline Sept. 28, 2006

Sept. 28, 2006

Hello, I ran our linklint script on winehq and here's the results. I will try and fix as many errors as possible over the next couple weeks. Tom --- Processing ... writing files to linklint wrote 25 txt files wrote 23 html files wrote index file index.html found 1 default index found 476 cgi files found 3 html files found 17 image files found 208 other files found 3833 http links found 5 https links found 20 ftp links found 54 mailto links found 15 news links found 2 unknown links found 2658 named anchors ----- 766 ignored files ----- 3 actions skipped ----- 125 files skipped warn 3 warnings ERROR 1 missing image file ERROR 3 missing other files ERROR 99 missing named anchors Linklint found 705 files and checked 500 html files. There were 4 missing files. 13 files had broken links. 103 errors, 3 warnings. real 5m58.972s user 0m6.960s sys 0m0.320s checking 3833 urls ...

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp Sept. 28, 2006

Sept. 28, 2006

> From: Alexandre Julliard <julliard(a)winehq.org> > > If you expect > anything to happen, you'll need to make much more concrete > suggestions, and provide examples to make us understand how > what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out "obviously" wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a "decision" command. You can decide to accept the patch, that would send an "accept" message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. > and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.

6 6

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Vitaliy Margolen Sept. 28, 2006

Sept. 28, 2006

Christoph Frick wrote: > hi > > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. > > -static const unsigned int depths[] = {8, 16, 32}; > +static const unsigned int depths[] = {8, 16, 32, 24}; > +static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]); > Can you make a test that demonstrates presence of 24-bit color depth on native? I have checked winnt40, win2k, winxp and none offering 24-bit. Also I seen some programs and games that will crash if you tell them that we really in 24-bit (as most X users are). Vitaliy.

1 0

Re: Problem with NtReadVirtualMemory and wine server connection
by Juan Lang Sept. 28, 2006

Sept. 28, 2006

Hi Peter, I'm guessing the fact that no one has replied means that no one has a strong opinion, or no one feels qualified to answer, or that AJ would prefer to see a patch first. I'll give my opinion in the hope of stimulating discussion, as I think it's important. > 1. allocate a temporary buffer in NtReadVirtualMemory, read server > answer to this buffer, and then inside a try / catch block copy to > application memory This would be my preference, for two reasons: 1. This would allow the test to pass, that is, we could successfully return STATUS_ACCESS_VIOLATION in this case. 2. The server protocol appears to be robust enough, as it crashes the client, not the server. The problem is mapping the fault to an NTSTATUS, and recovering from it. The disadvantage may be that each server request would have to be checked whether it could fail in the same way. Any other opinions? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

How hard is Uniscribe's ScriptLayout() to implement?
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

See http://bugs.winehq.org/show_bug.cgi?id=5772 Quicktime 6.5.x, Eclipse 3.2, Word XP, and other apps crash because usp10.ScriptLayout() isn't implemented. How hard would it be to fix this? - Dan

2 4

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 27, 2006

Sept. 27, 2006

On Wed, Sep 27, 2006 at 11:34:35PM +0200, Roderick Colenbrander wrote: > Hi, > > This patch routes the WGL font code through gdi32.dll. The patch depends on the other routing patch which routed the WGL context code through gdi32.dll. > --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.000000000 +0200 +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.000000000 +0200 @@ -396,5 +396,5 @@ @ stdcall wglSwapLayerBuffers(long long) @ stdcall wglUseFontBitmapsA(long long long long) @ stdcall wglUseFontBitmapsW(long long long long) -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You want to forward the wglUseFontBitmaps functions here since that's what the rest of your patch touches ;-) You also forgot to include the changes to gdi32.spec. Huw.

1 0

re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

Alexandre wrote: > How will this test work in non-English locales? How about if it calls SetThreadLocale(LOCALE_INVARIANT)?

3 2

Re: start.exe: Implement /D option, add new wine specific feature allowing to specify the shell operation name (resend)
by James Hawkins Sept. 27, 2006

Sept. 27, 2006

On 9/26/06, Paul Chitescu <paulc(a)voip.null.ro> wrote: > Changelog: start.exe: Implement /D option, add new wine specific feature > allowing to specify the shell operation name. > > The new /O[peration] command line option allows to specify a shell operation > other than "open". This is very valuable for testing or implementing actions > from shell scripts. > > It is also possible to pass a NULL operation by specifying the empty string > '' (or whatever looks like in your preferred shell). > > Examples: > wine start /d 'c:\' notepad.exe > wine start /o print README.txt > Only submit one fix per patch. Please read the WineHQ patch guidelines: http://winehq.org/site/sending_patches Why are you adding a new switch? This isn't provided by native start.exe, so we shouldn't add it. -- James Hawkins

2 2

Re: localspl: [1/3] Build the Importlib
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > We need the importlib for the tests It doesn't seem that we should have an importlib, there isn't one in the SDK either. The tests can always use GetProcAddress. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Stefan Dösinger Sept. 27, 2006

Sept. 27, 2006

Hi, > would someone please comment on that patch? this is a nearly unchanged > version of my previous attempt - but this time against current git. Not so sure about it. I am afraid I do not completely understand the color depth issue, but it appears to me that a patch like that rather hides the problem than fixing it. It is not possible to chance the depth on the fly on X11, so we may want a solution for all color depths.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Dmitry Timoshkov Sept. 27, 2006

Sept. 27, 2006

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Then it should be changed to 'ULONG' or 'unsigned LONG' for compatibility with Win64. -- Dmitry.

2 2

Re: oleaut32 2/2: [RESEND] Conformance test for varformat:VarWeekdayName
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > +void test_VarWeekdayName(void) > +{ > + WCHAR day_LongFormat[][10] = > + { > + {'S','u','n','d','a','y',0}, > + {'M','o','n','d','a','y',0}, > + {'T','u','e','s','d','a','y',0}, > + {'W','e','d','n','e','s','d','a','y',0}, > + {'T','h','u','r','s','d','a','y',0}, > + {'F','r','i','d','a','y',0}, > + {'S','a','t','u','r','d','a','y',0} > + }; How will this test work in non-English locales? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: clusapi: Implements stub dll for clusapi
by Alexandre Julliard Sept. 27, 2006

Sept. 27, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=6265 > > The application for bug 6265 checks if clusapi.dll exists and attempts > to call clusapi:GetNodeClusterState from it. This patch adds a stub > implementation for the DLL clusapi and GetNodeClusterState. You need to add a DLL_WINE_PREATTACH handler when adding a stub dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wintrust.h: add missing defines
by Paul Vriens Sept. 27, 2006

Sept. 27, 2006

On Tue, 2006-09-26 at 22:08 -0700, Juan Lang wrote: > #define WTD_UI_ALL 1 > #define WTD_UI_NONE 2 > @@ -115,6 +118,42 @@ > DWORD dwUIContext; > } WINTRUST_DATA, *PWINTRUST_DATA; > > +#define WTD_UI_ALL 1 > +#define WTD_UI_NONE 2 > +#define WTD_UI_NOBAD 3 > +#define WTD_UI_NOGOOD 4 > + > +#define WTD_REVOKE_NONE 0 > +#define WTD_REVOKE_WHOLECHAIN 1 > + > +#define WTD_CHOICE_FILE 1 > +#define WTD_CHOICE_CATALOG 2 > +#define WTD_CHOICE_BLOB 3 > +#define WTD_CHOICE_SIGNER 4 > +#define WTD_CHOICE_CERT 5 Hi Juan, these ones you've added are already in (see also first line in the excerpt from your email). Cheers, Paul.

2 1

Re: H. Verbeet : wined3d: Add support for native NPOT textures.
by Frank Richter Sept. 27, 2006

Sept. 27, 2006

On 27.09.2006 10:46, Alexandre Julliard wrote: > @@ -765,6 +768,12 @@ #undef USE_GL_FUNC > > gl_info->max_sampler_stages = max(gl_info->max_samplers, gl_info->max_texture_stages); > > + /* We can only use NP2_NATIVE when the hardware supports it. */ > + if (wined3d_settings.nonpower2_mode == NP2_NATIVE && !gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO]) { > + WARN_(d3d_caps)("GL_ARB_texture_non_power_of_two not supported, falling back to NP2_NONE NPOT mode.\n"); > + wined3d_settings.nonpower2_mode = NP2_NONE; > + } > + FYI, ATI r300+ hardware has some limited support for NP2 textures - that is, 2D textures without mipmaps and repeat mode CLAMP. But since that does not fulfill the ARB_tnpot requirements this extension isn't published. Still, maybe you can exploit that feature somehow... -f.r.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Michael Stefaniuc Sept. 27, 2006

Sept. 27, 2006

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Won't work on Win64. long is 32bits on Win32 and Win64. On Linux64 long is 64bits. bye michael > ------------------------------------------------------------------------ > > Index: dlls/rpcrt4/rpc_server.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/rpc_server.c,v > retrieving revision 1.58 > diff -u -r1.58 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 30 Jun 2006 19:16:38 -0000 1.58 > +++ dlls/rpcrt4/rpc_server.c 27 Sep 2006 12:38:00 -0000 > @@ -1008,7 +1008,7 @@ > /*********************************************************************** > * RpcMgmtSetServerStackSize (RPCRT4.@) > */ > -RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned int ThreadStackSize) > +RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned long ThreadStackSize) > { > FIXME("(0x%x): stub\n", ThreadStackSize); > return RPC_S_OK; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Paul Vriens Sept. 27, 2006

Sept. 27, 2006

On Wed, 2006-09-27 at 14:40 +0200, Thomas Weidenmueller wrote: > FIXME("(0x%x): stub\n", ThreadStackSize); Shouldn't that be (0x%lx) then ? Cheers, Paul.

1 0

some wineconference pictures
by Marcus Meissner Sept. 27, 2006

Sept. 27, 2006

Hi, Some Wine conference pictures from David and myself: http://gallery.kuschelt.net/main.php?g2_view=core.ShowItem&g2_itemId=100617 Ciao, Marcus

2 1

Governance revisited
by Robert Lunnon Sept. 27, 2006

Sept. 27, 2006

I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser) Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint. The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues. No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time. Wine needs process... The issue is not code, It's governance. Governance to establish balance, balance between beauty and function. Bob

24 55

WineD3D: glBlend* fixes
by Roland Scheidegger Sept. 27, 2006

Sept. 27, 2006

> Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does > the spec. I don't know what exactly uses the min_max form. Is this a > typo? Apart from the blend_minmax typo, it appears to be me this patch has some other problems. >> This patch changes the detection extension detection for >> glBlendColor/glBlendEquation. The function glBlendColor is part of >> OpenGL 1.1 and is supported on all OpenGL implementations. No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color is an imaging subset feature, and is only allowed when the imaging subset is supported"). It is however part of OpenGL 1.4. So, a really correct detection would be to check for ogl version 1.4, EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be omitted, but it is possible there are drivers out there which only announce support for ARB_imaging but not EXT_blend_color, according to www.delphi3d.net there are indeed some tnt2's out there which claim support for ARB_imaging but not EXT_blend_color - if I'd have to guess I'd suspect the call to glBlendColor results in a sw fallback. >> Further glBlendEquation is part of GL_ARB_imaging aswell. For the >> same reason GL_ARB_imaging can't be used to detect glBlendEquation. >> This call isn't supported on all OpenGL implementations. Luckily it >> is part of 'GL_EXT_blend_min_max' so that is used now. This is not quite so simple. If OGL 1.4 is supported, or the version is lower but ARB_imaging itself is supported, all the blend function stuff from ARB_imaging is ok. If only either EXT_blend_minmax or EXT_blend_subtract is supported, then glBlendEquation is supported, but only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). But if all you care is that glBlendEquation is available, you should probably detect ogl 1.4, and EXT_blend_subtract (some cards only support EXT_blend_subtract but not EXT_blend_minmax), but really for correctness EXT_blend_minmax and ARB_imaging should be checked too. Roland (not subscribed to wine-devel - include me in cc for answers)

4 8

re: shlwapi: Resupply array sizes stripped by function interface
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

Andrew Talbot wrote: >A formal parameter declared as an array is treated as a pointer; any size >specifier is ignored. So here, sizeof decimal_buffer, for example, would >equate to the size of a pointer to WCHAR, not to that of an array of eight >WCHARs. Why are you doing this? - Dan

3 8

re: start.exe: New feature allowing to specify the shell operation name
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

>The new /O[peration] command line option allows to specify a shell >operation other than "open". > This is very valuable for testing or implementing actions from shell scripts. Hmm. I don't see that option in the Win XP documentation: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… There's already one clash (/l) between wine's start and Windows'. I hesitate to say that adding another extension is a good idea. I'd feel better if the help mentioned that this is a Wine-specific extension. - Dan

2 2

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Hi, Dmitry Timoshkov wrote: > > > How many projects have you ever participated in? Every developers' > mailing list > of an open source I personally participated in *doesn't guarantee* not > only patch > acceptance, but even a reply with explanations why the patch has been > silently > dropped, and it doesn't matter how many maintainers a project has. Why > do you > request that from Wine, and particularly from Alexandre? > > Alexandre is not a robot, he is a human. Please take that into account. Sounds like he need more help. > > It's a metter of the fact, that if you can't cope with other people's > requirements, > you can't work in a team. > Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine . It is your job to provide support for this product, I spend money and I need help, where do I go? Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list? This project needs a course in technical sales support. Good idea for the next WineConf! Remember you represent CodeWeavers, start acting like it. 8^D, James

6 7

Re: cabinet: Fix NULL pointer dereference (Coverity)
by James Hawkins Sept. 26, 2006

Sept. 26, 2006

On 9/26/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Fix NULL pointer dereference (Coverity). > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 23:59:28.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-26 18:27:03.000000000 +0100 > @@ -176,18 +176,22 @@ > if ((!perf) || (!pfnalloc) || (!pfnfree) || (!pfnopen) || (!pfnread) || > (!pfnwrite) || (!pfnclose) || (!pfnseek) || (!pfndelete) || > (!pfnfcigtf) || (!pccab)) { > - perf->erfOper = FCIERR_NONE; > - perf->erfType = ERROR_BAD_ARGUMENTS; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_NONE; > + perf->erfType = ERROR_BAD_ARGUMENTS; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_BAD_ARGUMENTS); > return NULL; > } > > if (!((hfci = ((HFCI) (*pfnalloc)(sizeof(FCI_Int)))))) { > - perf->erfOper = FCIERR_ALLOC_FAIL; > - perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_ALLOC_FAIL; > + perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > This last check is pointless. If perf is NULL, we bail out and return NULL a few lines up. Also, please add a test showing that native does not crash if a NULL perf is sent in. It's weird, but we need to be consistent with native, as some apps depend on such a crash. -- James Hawkins

2 1

Re: Alexandre Julliard : explorer: Work around the latest HAL binary compatibility breakage.
by Marcus Meissner Sept. 26, 2006

Sept. 26, 2006

On Tue, Sep 26, 2006 at 03:04:47PM -0500, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 9ae4e8d98efc952918bcdae86b2f640c4b062a3b > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9ae4e8d98efc952918bcdae… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Sep 26 20:29:15 2006 +0200 > > explorer: Work around the latest HAL binary compatibility breakage. > - if (!(dbus_handle = wine_dlopen(SONAME_LIBDBUS_1, RTLD_NOW, error, sizeof(error)))) goto failed; > - if (!(hal_handle = wine_dlopen(SONAME_LIBHAL, RTLD_NOW, error, sizeof(error)))) goto failed; > + /* Load libhal with RTLD_GLOBAL so that the dbus symbols are available. > + * We can't load libdbus directly since libhal may have been built against a > + * different version but with the same soname. Binary compatibility is for wimps. */ Yet another Redhat stumbling block ;) But they warn in pretty large letters: cat /usr/lib/pkgconfig/hal.pc ... Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal ... #ifndef DBUS_API_SUBJECT_TO_CHANGE #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-BUS hasn't reached 1 .0 and is subject to protocol and API churn. See the README for a full explanation." #endif ciao, Marcus

1 0

Using gdb
by Craig Keogh Sept. 26, 2006

Sept. 26, 2006

Hi, I am trying to use gdb for debugging. I run the command: winedbg --gdb sol.exe I then get the following output: WineDbg starting on pid 0xa fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for wine-pthread fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ntdll<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for msvcrt<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for advapi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for gdi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for user32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for cards<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shell32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shlwapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ole32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for rpcrt4<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for iphlpapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for comctl32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for winex11<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for imm32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for uxtheme<elf> 0x7eecaf5a start_process+0xde in kernel32: movl %edi,0x0(%esp) I don't end up with a gdb prompt. It is just stuck there. I am following: http://www.winehq.com/site/docs/winedev-guide/dbg-others I compiled wine (from GIT) using gcc v4.0.3, I am using gdb v6.4-debian. Running without gdb ('winedbg sol.exe') works fine. Thanks in advance,

2 2

Problem with NtReadVirtualMemory and wine server connection
by Peter Oberndorfer Sept. 26, 2006

Sept. 26, 2006

Hi, throught a problem in winedbg i found out that NtReadVirtualMemory has a problem, when reading into a invalid local buffer. it uses wine_server_set_reply( req, buffer, size ); to read the data supplied by the server directly into application memory of unknown state. when the read call hits bad(non present/readonly ) memory it returns EFAULT and the client dies with "wine client error:<process id>: read: Bad address" i see 3 ways to deal with this problem 1. allocate a temporary buffer in NtReadVirtualMemory, read server answer to this buffer, and then inside a try / catch block copy to application memory 2. change server protocol so it is not as sensitive when read returns EFAULT (i do not really like this idea) 3. just fix the bug in winedbg and wait until a real world app needs this behavior. (of course i will send a patch for windbg even if one of the other ways is choosen) Any ideas? Greetings Peter PS: attached a testcase for NtReadVirtualMemory(testcase itself not tested on windows, but tests were) the test should probably also live in its own file, but i didn't want to create a almost empty file

1 0

Re: msi [1/5]: Implement MsiDatabaseImport
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static const WCHAR insert_fmts[][100] = > +{ > + {'I','N','S','E','R','T',' ','I','N','T','O',' ','`','%','s','`',' ','(',' ',0}, > + {'`','%','s','`',',',' ',0}, > + {' ',')',' ','V','A','L','U','E','S',' ','(',' ',0}, > + {'\'','%','s','\'',',',' ',0}, > + {'%','s',',',' ',0}, > + {' ',')',0}, > +}; It would be cleaner to use separate variables for the separate strings, there's no reason this needs to be an array. It would avoid wasting a lot of space, and make it more explicit what the strings mean, unlike something like insert_fmts[3]. Also since all you do is copy strings, it may be even cleaner to avoid sprintf and simply strcat the strings and the separators. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: D3D9: Add a pitch test for a 1x1 texture
by H. Verbeet Sept. 26, 2006

Sept. 26, 2006

On 26/09/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > To verify that the 32 bit alignment is true for 1x1 textures too. > >+ /* test is deactivated until out np2 support doesn't report the full power of 2 pitch to the app */ >+ todo_wine ok(lockedRect.Pitch == 4, "Got pitch %d, expected 4\n", lockedRect.Pitch); Shouldn't the test be about alignment, rather than the exact size? I that case the power-of-two stuff shouldn't matter either, as long as it's properly aligned. I do have an initial patch for native NPOT support, but it will (of course) only work on cards that support the relevant extension.

2 3

Re: [D3D9] Update state test framework
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Changelog: > ========== > 1) Abandon central memory allocation, and the tracking that involves. > Write a setup() and teardown() handler for each test, and use heap > allocation. > > 2) Make the main test function configure test arguments. > Replace get/set arguments with a single test_arg. > > 3) Remove some const qualifiers on test data. > Const qualifiers should go on function parameters instead. When you find yourself writing a Changelog like this, it's a clear sign that it should be 3 separate patches. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: user: test and fix SwitchToThisWindow [3rd try]
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > diff --git a/dlls/user/winpos.c b/dlls/user/winpos.c > index 6bc9056..e78f484 100644 > --- a/dlls/user/winpos.c > +++ b/dlls/user/winpos.c > @@ -152,7 +152,20 @@ UINT WINAPI ArrangeIconicWindows( HWND p > */ > void WINAPI SwitchToThisWindow( HWND hwnd, BOOL restore ) > { > - ShowWindow( hwnd, restore ? SW_RESTORE : SW_SHOWMINIMIZED ); > + HWND hwndOld = GetForegroundWindow(); > + SetActiveWindow( hwnd ); > + SetForegroundWindow( hwnd ); > + if ( restore ) > + { > + if ( IsIconic( hwnd ) ) > + ShowWindow( hwnd, SW_RESTORE ); > + } > + else > + { > + if ( !( GetWindowLongW( hwndOld, GWL_EXSTYLE ) & WS_EX_TOPMOST ) ) > + SetWindowPos( hwndOld, HWND_BOTTOM, 0, 0, 0, 0, > + SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE ); > + } That HWND_BOTTOM thing looks very wrong, SwitchToThisWindow is supposed to move things to the front. Most likely your test case is flawed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Tips for vim users
by n0dalus Sept. 26, 2006

Sept. 26, 2006

Hi, Recently I learned a way to have vim automatically change settings when I'm editing wine source code: At the bottom of my ~/.vimrc (create it if it doesn't exist): if !exists("loaded_vimrc_autocmd") let loaded_vimrc_autocmd=1 autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8 softtabstop=4 endif In my case my wine tree is in /data/wine, so replace this with the first part of the path to your wine tree. Using the same syntax you can also put custom settings for other projects you might work on. This is helpful for me since I usually like to indent using tabs and a 4 space tab width, but now I can edit most of wine's code without having to worry about fixing my indents all the time. If anyone is interested, I've also got another Vim tip on the wiki (from last year), to automate the creation of wide character arrays: http://wiki.winehq.org/Character_arrays_in_Vim If any other vim users have tips that help out with wine coding, I'd love to hear them! Maybe we can make a page on the wiki for them. n0dalus.

2 4

Re: Governance revisited (Wineconf report)
by Ge van Geldorp Sept. 26, 2006

Sept. 26, 2006

> From: Kai Blin > > Now, getting back to the patch submission process, you're talking about a > patch management system. How would that look like, in your opinion. We were > discussing a couple of ideas, but in the end figured that most of those would > slow down the submission speed of patches that are accepted. > > Our idea was to have patches be recieved by the subsytem maintainers, and > Alexandre would only apply patches he got from those guys. We voted that one > down. > > Now I would be interested in your idea for such a system. I figure that > writing an emacs frontend won't be too troublesome if it's reasonably > designed, so let's ignore that for now. A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: "However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered." The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in "Waiting for developer" status too long (say a month) it could be automatically rejected. When "Waiting", the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in "Waiting" too long) or via a Withdraw. The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel. If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work. Gé van Geldorp.

6 6

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

James Hawkins wrote: > On 9/25/06, jimtabor <jimtabor(a)users.sourceforge.net> wrote: > >> >> Every Wine developer needs to read this, >> http://www.codeweavers.com/services/ and >> http://www.codeweavers.com/services/wine . >> > > I'm a Wine developer, and I don't work for codeweavers. Why should I > read that? > You don't need to. >> It is your job to provide support for this product, I spend money and I >> need help, where do >> I go? >> > > It is not my job to provide support for this product. Even if you're > referring to Dmitry and everyone else that works at Codeweavers, > you're still wrong. This is the wine-devel mailing list, and has > nothing to do with Codeweavers. You confuse Crossover Office and Wine > as being the same product/project. Just because they work at > Codeweavers, can they not also work on Wine and not have affiliation > with Codeweavers? Of course they can, as can anyone else who has a > real job outside of Wine. > NO! You are WRONG, sir! ~and I quote from http://www.codeweavers.com/services/ "Since 1999, CodeWeavers has been hiring the very best Wine developers. Chief among these is Alexandre Julliard <http://www.codeweavers.com/about/people/alexandre/>, the long-time maintainer of the Wine Project itself. In addition to Alexandre's prodigious talents, we have consistently hired the very best Wine resources, recruiting them literally worldwide." Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW would not have a product. They get paid for working on Wine to support CO. Don't you see that?! > First, he doesn't represent Codeweavers on the wine-devel mailing > list. Second, there's nothing unprofessional about his actions. > Missed my point! If his address has "name(a)codewreavers.com", than yes, that person does represent that organization. This project is NOT LINUX or X11, it is a paid for add on to it. I pay good money for support and I expect to get it. It is shocking to most FOSS code writers that maybe this is a real, truly, paid for project. "No! It can not be! I contribute to someones profit? NOOoooooooo~~~!". Thanks, James

3 2

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Wow, just like that! James Hawkins wrote: >> It is shocking to most FOSS code writers that maybe this is a real, >> truly, paid for project. "No! It can not be! I contribute to someones >> profit? NOOoooooooo~~~!". > The above is a famous quote I read from Linux Journal magazine. > > I am well aware that Codeweavers funds most of Wine development, and I > appreciate every bit of support coming from them, but this project > would continue even without their support. > > -- > James Hawkins > >> NO! You are WRONG, sir! >> NOOoooooooo~~~! > > > P.S. You should really calm down. It's hard to take you seriously > when you act immature. > I am calm, lol! immature? just a little! 8^D So, after reading this ML for years and assessing. Seriously, If I was a contractor representative researching code weavers ability to support their product, the last thing I would expect from any of their developers would be the lack of customer support and poor attitude on IRC. At lest if one of my employees does go out and join wine IRC, I would hope they will not get kicked or banned for asking to many questions. Understanding this, has made my mind up and forced to stop linux migration due to the lack of support and maturity of wine and code weavers. We do have contracts with Red Hat, SCO, Solaris, Raytheon,,,,, Oh the shock of that, yes we are considering the use of wine for moving away from Microsoft windows. Wine was the stop gap in our mission to provide both Linux and Window applications in a real time environment. That M$ update thingy is a ass kicker on real time systems, that must operate 24/7. Having said that,,,, sorry I can't authorize any contracts with code weavers. Sorry, you just never know sometime, James

1 0

make test failing in shell32
by Kai Blin Sept. 25, 2006

Sept. 25, 2006

Hi folks, running make test repeatedly in a new wine prefix finally gives this error: make[2]: Entering directory `/home/nowhere/dev/wine/wine-build/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 I've attached the +shell trace bzip2ed, the uncompressed trace is 2.2 megs. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > Changelog: > * Makes RPCRT4 use Winsock2 instead of native sockets (needed for > event object support) > * Adds support for TCP (ncacn_ip_tcp protocol) servers I appreciate your attempt at solving this hard problem, but I don't believe this is the right approach. Using winsock2 instead of Unix sockets adds overhead in terms of wineserver calls and extra processing time to mangle arguments, which we shouldn't need. The reasoning for this is that at some point I want to use Unix domain sockets for the ncalrpc provider, so it should be as fast as possible. More detailed comments inline: > > --- a/include/ws2tcpip.h 2006-08-28 20:35:33.000000000 +0200 > +++ b/include/ws2tcpip.h 2006-09-16 08:55:45.000000000 +0200 > @@ -137,6 +137,8 @@ > #define WS_IFF_MULTICAST 0x00000010 /* multicast is supported */ > #endif /* USE_WS_PREFIX */ > > +#define INET_ADDRSTRLEN 16 > + > #ifndef USE_WS_PREFIX > #define IP_OPTIONS 1 > #define IP_HDRINCL 2 > This change looks good. Please submit it separately. > +static const char *gai_strerror(int errcode) > +{ > + switch (errcode) > + { > + case EAI_AGAIN: return "Temporary failure in name resolution"; > + case EAI_BADFLAGS: return "Bad value for ai_flags"; > + case EAI_FAIL: return "Non-recoverable failure in name resolution"; > + case EAI_FAMILY: return "ai_family not supported"; > + case EAI_MEMORY: return "Memory allocation failure"; > + case EAI_NONAME: return "Name or service not known"; > + case EAI_SERVICE: return "Servname not supported for ai_socktype"; > + case EAI_SOCKTYPE: return "ai_socktype not supported"; > + } > + return "Unknown error"; > +} > + > +static const char *inet_ntop(int af, const void *src, char *dst, int cnt) > +{ > + if (af == AF_INET) > + { > + unsigned int addr = * (unsigned int*) src; > + if (cnt < INET_ADDRSTRLEN) > + return NULL; > + snprintf(dst, cnt, "%u.%u.%u.%u", (addr >> 24) & 0xFF, > + (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF); > + return dst; > + } > + else > + return NULL; > +} > + > These should obviously not be here. I believe gai_strerror is implemented as a macro in one of the winsock header files. I think inet_ntop should be implemented in ws2_32.dll. > @@ -506,51 +516,115 @@ > continue; > } > > - if (0>connect(sock, ai_cur->ai_addr, ai_cur->ai_addrlen)) > + if (Connection->server) > { > - WARN("connect() failed\n"); > - close(sock); > - continue; > + BOOL success = FALSE; > + if (bind(sock, ai_cur->ai_addr, ai_cur->ai_addrlen) == 0) > + { > + if (listen(sock, 5) == 0) > + { > + if ((tcpc->event = WSACreateEvent()) != NULL) > + { > + if (WSAEventSelect(sock, tcpc->event, FD_ACCEPT) == 0) > + success = TRUE; > + else > + WARN("WSAEventSelect() failed\n"); > Using WSAEVENTs is an interesting approach, but I'd rather see Unix sockets being used with a thread that select's on the socket and sets a Win32 event instead. Also, I think this amount of nesting is confusing and could be avoided. > > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, > void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > - return r; > + int rtotal = 0; > + int r = 0; > + do > + { > + r = recv(tcpc->sock, buffer, count, 0); > + if (r > 0) > + rtotal += r; > + else > + break; > + } while (rtotal < count); > + if (r < 0) > + rtotal = r; > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); > + return rtotal; > } > Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that should be fixed there. > > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, > const void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = write(tcpc->sock, buffer, count); > + int r = send(tcpc->sock, buffer, count, 0); > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > return r; > } > This is a good change. Please submit this as a separate fix. Thanks, -- Rob Shearman

3 3

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > On 9/22/06, Robert Shearman <rob(a)codeweavers.com> wrote: >> Using WSAEVENTs is an interesting approach, but I'd rather see Unix >> sockets being used with a thread that select's on the socket and sets a >> Win32 event instead. Also, I think this amount of nesting is confusing >> and could be avoided. > > Are you working on that approach, or am I free to try it? No, I am not working on that so you are free to try it. (You would be free to try it anyway, since your implementation might be better than an implementation I was working on.) > >> > >> > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, >> > void *buffer, unsigned int count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); >> > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > - return r; >> > + int rtotal = 0; >> > + int r = 0; >> > + do >> > + { >> > + r = recv(tcpc->sock, buffer, count, 0); >> > + if (r > 0) >> > + rtotal += r; >> > + else >> > + break; >> > + } while (rtotal < count); >> > + if (r < 0) >> > + rtotal = r; >> > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); >> > + return rtotal; >> > } >> > >> >> Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that >> should be fixed there. > > It isn't supported in the native winsock either. You think too highly > of winsock - remeber it was made by Microsoft ;-). Both MSDN and dlls/ws2_32/socket.c suggest that it is supported, although only in non-blocking mode. Is that the problem? > >> > >> > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, >> > const void *buffer, unsigned int >> count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = write(tcpc->sock, buffer, count); >> > + int r = send(tcpc->sock, buffer, count, 0); >> > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > return r; >> > } >> > >> >> This is a good change. Please submit this as a separate fix. > > But if we use UNIX sockets, it shouldn't matter? Correct. This won't make any difference either way, so we should use send. -- Rob Shearman

1 0

Re: kernel32: Remove unwanted null terminator
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > kernel32: Remove unwanted null terminator. There's no null terminator since the array size is specified explicitly. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dmime: Dangling references fix
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > dmime: Dangling references fix. The right way is to use wine_dbg_sprintf("%s") to allocate a copy of the buffer to return. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine translations statistics
by Mikołaj Zalewski Sept. 25, 2006

Sept. 25, 2006

To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Mikolaj Zalewski

6 7

Re: wined3d: fix typo in ResourceReleased
by Stefan Dösinger Sept. 25, 2006

Sept. 25, 2006

Hi, > if (This->stateBlock != NULL ) { > if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] == resource) { > TRACE("Vertex buffer released whlst bound to a state block > stream %d\n", streamNumber); > TRACE("Vertex buffer released while bound to a state block stream %d\n", streamNumber); > This->stateBlock->streamSource[streamNumber] = 0; > } > } This is not your code, but this is wrong, even if the msdn says otherwise. Once I had a hacky test for testing this stuff. What my test did was: 1) Create a Vertex buffer 2) check device refcount: increased 3) Bind to a stream 4) check the vb refcount: unchanged(still 1) 5) release the vb(release returns 0) 6) check the device refcount: decreased 7) GetStreamSource: returns old vertex buffer 8) Check device refcount: increased 9) check vb refcount: 1 It seems that the stream source is not uset if the buffer is released. And it seems that ms implements holding the reference to the device in VertexBuffer::AddRef if(oldref == 0) IDirect3DDevice9_AddRef(This->device) or something like that, simmilar to our release. CreateVertexBuffer seems to init the ref to 0 and call VertexBuffer::AddRef. To be sure I did tested the following too: 1) Create VB 2) Check device refcount: increased 3) Release vb. Device refcount decremented 4) AddRef the just destroyed vb: Device refcount increased I didn't submit the test because it doesn't contain anything really new, and the GetStreamSource which returns the released buffer works just by chance. Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as any app depending on that would randomly break on windows. Or is there some COM magic behind this, which keeps objects from beeing destroyed? Stefan

1 0

Re: Governance revisited
by Ge van Geldorp Sept. 25, 2006

Sept. 25, 2006

> From: Steven Edwards <winehacker(a)gmail.com> > > Which is why we want to have the ambassadors project to help > new people in to wine. The thinking goes that if we have some > people to help hold the hands of new developers and the > developers that are defacto maintainers of a certain section > of code will respond to patches as they seem them, this will > free julliard from having to answer every single patch with a > reply. You can have ambassadors and subsystem maintainers all you want, but in the end it's still going to be Alexandre who decides if a patch goes in. That means the end-responsibility of informing developers why a patch was rejected needs to be with Alexandre. If an ambassador or subsystem maintainer already explained it, fine, no need to create double work for Alexandre, but if noone responded I'd still expect Alexandre to send a notification. Just for the record, my own policy on patch submission (and I really hope to get back to working on Wine and submitting patches Real Soon Now :-)) is to submit a patch once. If I get feedback I'll try to improve and resubmit, but if it goes the black hole route I'm not going to beg for an explanation. If the Wine community can't be bothered to provide feedback I can't be bothered to resubmit. After all, I've already scratched my itch, the bug is already fixed in my tree, it's the communities loss, not mine. Ge van Geldorp

2 1

Last update to git 5 days ago?
by Paul Vriens Sept. 25, 2006

Sept. 25, 2006

Hi, is Alexandre on a holiday again? Or is this to recuperate from WineConf? Cheers, Paul

1 0