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

Whither msxml?
by Dan Kegel Sept. 25, 2006

Sept. 25, 2006

For the past two years, I've helped UCLA's cs130 by pointing them at an area of Wine that needs improvement and helping them get patches submitted. For Winter 2007, I'm considering having them focus on msxml3. So I'm starting to look at bugzilla (see my previous message) and dig up demo apps and articles that might help us understand where wine's msxml needs to go. Man, oh, man are there a lot of pages about msxml out there. If anyone has tips on sore spots with Wine's msxml, please let me know. A few random notes: MSDN on msxml: http://windowssdk.msdn.microsoft.com/en-us/library/ms763742.aspx I see the spec file for msxml3 has a bunch of stubbed ordinals. Anyone know what they are? Can Wine handle the "msxml3 jumpstart" demo app from year 2000 yet? http://msdn.microsoft.com/library/en-us/dnmsxml/html/sax2jumpstart.asp Or the "msxsl.exe" wrapper app? http://www.microsoft.com/downloads/details.aspx?familyid=2fb55371-c94e-4373… "Programming The SAX2 3.0 Using MSXML" (examples in vb6) http://xml.sys-con.com/read/40210.htm "MSXML, It's Not Just for VB Programmers Anymore" (examples in perl) http://www.perl.com/pub/a/2001/04/17/msxml.html "Python & XML" http://safari.oreilly.com/0596001282 Here's a page that seems to show how to use msxsl and explains differences between msxml3 and msxml4: http://www.perfectxml.com/articles/xml/XSLTInMSXML.asp msxml3 examples: http://www.perfectxml.com/articles/xml/msxml30.asp "A C++ Template Wrapper for the XML SAX API" http://www.ddj.com/showArticle.jhtml?articleID=184401778 etc. etc. - Dan

3 2

An MSVCRT_fgetc bug
by Tobias Ringström Sept. 25, 2006

Sept. 25, 2006

There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in that it sometimes sign extends the byte read from the file. The following program illustrates the problem: #include <stdio.h> int main() { FILE *f = fopen("tmp.bin", "w+"); fputc(0xe0, f); fputc(0xe0, f); rewind(f); printf("0x%08x\n", fgetc(f)); printf("0x%08x\n", fgetc(f)); fclose(f); return 0; } The output is: 0x000000e0 0xffffffe0 (should be 0x000000e0 too) The bug is likely this line: http://source.winehq.org/source/dlls/msvcrt/file.c#L2134 That line is now i = file->_ptr++; but should be i = *(unsigned char*)(file->_ptr++); I don't have a build environment for Wine, and it felt like overkill to set one up for this little bug, so I've not been able to verify my hypothesis. I hope that's acceptable. /Tobias

2 1

Re: LOSTWAGES: WWN 292 & 320 updates
by Tom Wickline Sept. 25, 2006

Sept. 25, 2006

On 9/23/06, Mirek <thunder.m(a)email.cz> wrote: > > > > Also Wine reports 64MB of video memory not 16MB > > I think there shuld be option in winecfg to set this, because it is not easy to > find how anyone can do that. http://wiki.winehq.org/UsefulRegistryKeys Tom

1 1

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

Sept. 25, 2006

> From: Kai Blin <kai.blin(a)gmail.com> > > On Saturday 23 September 2006 10:32, Scott Ritchie wrote: > > Frankly, all we really need is for Alexandre to write a 10-second > > reply to wine-devel for each patch he rejects. > > On WineConf, we decided against this. That would still slow > down the overall patch submission speed. Consider you have a > patch that's just fine, but before you sent that, I sent in > ten patches with C++ style comments. Alexandre would now have > to reply to ten patches with "No C++ style comments" before > processing your patch. Everybody reading wine-patches > could point out what was wrong with my patches. You must be kidding. Even in your somewhat convoluted example, it would be fine to receive just a single notification "No C++ style comments" and I really wouldn't care if the notification came from Alexandre or from someone else on wine-patches. The reality is that a lot of patches (I haven't kept a precise count, but I estimate about a third of my own patches) are dropped silently, without any feedback at all. I have absolutely no problem with a strict patch acceptance policy, designed to keep the Wine quality high. Alexandre is amazingly smart and when he tells me why a certain patch was rejected I'll usually agree with him and even if I don't agree, I have enough confidence in him to accept his judgement. But having your patches dropped silently is pretty annoying. The usual response from the core Wine developers is "well, just resubmit". I fail to see how this helps Alexandres productivity (or my own for that matter). If patches weren't dropped silently the sequence of events would be: 1) Submit patch 2) Alexandre looks at patch 3) Alexandre writes 10-second rejection reply With the resubmit: 1) Submit patch 2) Alexandre looks at patch 3) Wait a week 4) Resubmit patch 5) Alexandre looks at patch again 6) Alexandre writes 10-second rejection reply Seems to me this incurs extra work for Alexandre (number 5). The patch processes isn't very transparant. For example, I submitted a patch on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be unreachable for me at the moment so I can't give a URL to the message) to fix a problem with the heap on Win64. This patch was silently dropped. On July 21 a change very similar to what I submitted was committed but not attributed to me. Now, either the commit was not based on my patch (in which case someone else spent another 2-3 days (it was one of those problems where a chain of out-of-buffer memory writes take place and you have to work your way up the chain to find the root cause) on tracking down an already known problem for which a fix was already available) or it was based on my patch (in which case my patch shouldn't have been dropped and I should have been given credit). Like I said before, I have a lot of respect for Alexandres technical abilities. But when I read comments in the Wineconf report about git: "Developers might not like it, but Alexandre does so it's a success" (did I mention I dislike git also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. Ge van Geldorp.

2 1

Governance revisited
by Steven Edwards Sept. 25, 2006

Sept. 25, 2006

---------- Forwarded message ---------- From: Steven Edwards <winehacker(a)gmail.com> Date: Sep 25, 2006 1:27 AM Subject: Re: Governance revisited To: Troy Rollo <wine(a)troy.rollo.name> On 9/25/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The present system turns people off even before you've had time to learn > whether they are capable or not. 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. Now in the case of Ge where he was patching core functions of ntdll,kernel32,wineserver,etc I guess it would still fall to julliard to reply personally but in the case of other modules the experts in that area should take a step up and monitor wine-patches and say what patch X.Y.Zsucks and julliard most likely will not merge it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1

my dsound/winealsa hacks
by Tomas Carnecky Sept. 24, 2006

Sept. 24, 2006

My ultimate goal was to solve the dsound underruns which were so horrible that I had to disable sound in World of Warcraft. While I managed to get the sound working flawlessly (really... I never heard such clear sound under wine) in WoW, it required WoW-specific hacks so my patch will never make it (in its current form) into the official git tree, but maybe someone can use some of my ideas to improve dsound/winealsa. The basic idea is to let alsa mix the sound instead of the infamous dsound mixer. The advantage is that if the hardware supports mixing, there is very little overhead, if not, there's still dmix which can do that, but dsound doesn't need to care how it's done, it's entirely up to alsa. Now to the actual implementation, it's pretty straight-forward: I 'forced' CreateSoundBuffer to create a hardware buffer (right now it creates a hw buffer only for the primary buffer) and changed the winealsa driver to support that. Because winealsa driver opens only one 'connection' (snd_pcm_t) to the soundcar (allowing only one buffer per device), I simply opened a new 'connection' for each buffer and configured the hardware for 44100Hz/U16LE/stereo (that's what WoW expects). Up to this point it was easy. One of the big problems was that WoW requests a 16kb buffer, but alsa is unable to allocate a buffer with this exact size, and it caused problems if I passed the alsa buffer to WoW (so WoW could write directly to it). I had to allocate a separate buffer, keep track of the play/write positions in both buffers and copy the data from one to the other. I'm fairly sure this all could be done in a WoW-independent way, eg. configure the hardware as the application requests it (by passing LPCDSBUFFERDESC to the low-level driver etc) and keeping track of the read/write positions could also be done in a better way. There are a free questions that should be answered before someone can go on and make a 'proper' implementation. I simply bypassed the primary buffer, it doesn't exist since the data from the secondary buffers are written directly to the soundcard. If it should be possible to read the data from the primary buffer then we should forget this all and look for another solution. I believe that it's not possible (it's not possible to write to the primary buffer and the API doesn't differentiate between reads and writes), but someone should test that under windows. (this is only one question but I'm sure you'll come up with more ;) ) Here is the complete patch, I also changed the IDirectSound interface and a lot unrelated code, so the patch is a bit big :-/ There also are a few memory leaks, I didn't bother freeing the memory etc. http://dbservice.com/ftpdir/tom/dsound-alsa.patch tom

6 10

Call for Installer Bugs...
by Dan Kegel Sept. 24, 2006

Sept. 24, 2006

Lots of progress has been made in fixing installer bugs lately, but there are probably many such bugs hiding in plain view still. It would be very helpful if people could look for bugs which: a) appear to be MSI or setupapi related, and b) occur in freely downloadable executables (e.g. trial versions) c) aren't already in bugzilla (see http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-msi&keywords… for list) and file reports as appropriate at http://bugs.winehq.org. Thanks! - Dan

4 3

RFC: wine ASIO driver available for testing
by Robert Reif Sept. 24, 2006

Sept. 24, 2006

I just uploaded a simple wine ASIO driver to http://bugs.winehq.org/show_bug.cgi?id=2161 for testing and feedback. Please look at it and give me feedback. Playback works. Recording is untested due to lack of software. Full duplex doesn't work for me but I'm not sure if it's a software issue or a problem with my hardware and OS setup. The software is a long way from being ready for submission so any feedback or help would be appreciated.

4 4

Re: LOSTWAGES: WWN 292 & 320 updates
by H. Verbeet Sept. 24, 2006

Sept. 24, 2006

On 23/09/06, Mirek <thunder.m(a)email.cz> wrote: > > I also changed what benchmarks I had running at this years WineConf > > 3DMark2000, 3DMark2001SE and 3DMark2003... I have 3DMark2006 running > > and its beautiful, well beauty is in the eye of the beholder > > All of the test run in all three of the benchmarks to completion and > > there is only two test out of all test that have minor problems, and > > Henri has one of the test fixed in his tree. > > Can you post how i can get sources from his tree? The 3th and 4th 3DMark03 tests should pretty much work with current git, actually. The 4th test has some minor issues, afaik because of the wrong sampler types being bound. If there are other issues, those are separate bugs, and should probably be reported on bugzilla.

1 0

Server instability warning
by Jeremy White Sept. 24, 2006

Sept. 24, 2006

Hi Folks, The server crashed early yesterday evening, and again sometime over the night. It's a new server - and in fact, I think it's the new 'new' server - seems like it always takes a while to get a server stabilized). Jeremy Newman is coming back from England today, and I prefer to leave these sort of repairs to him, otherwise he grouses at me (rightly, I might add :-/). So it's back up now, but I'm not sure for how long that will be true. Sorry for the hassle; if it gets worse this afternoon before Jer gets back, I may break down and start dissecting it. Cheers, Jeremy

1 0

ALSA implementation
by Aaron Slunt Sept. 24, 2006

Sept. 24, 2006

Hi, I talked on #winehq in irc about how horribly alsa is implemented right now. I was told that winmm would need a complete re-write and the dsound needs some changes as well. My question is: anybody here who's familiar with all of the changes that need to be made to get alsa working properly? Thanks.

9 21

Re: Governance revisited (Wineconf report)
by J. Wesley Cleveland Sept. 24, 2006

Sept. 24, 2006

> From: Kai Blin <kai.blin(a)gmail.com> > On Saturday 23 September 2006 10:32, Scott Ritchie wrote: > > Frankly, all we really need is for Alexandre to write a 10-second reply > > to wine-devel for each patch he rejects. > > On WineConf, we decided against this. That would still slow down the overall > patch submission speed. Consider you have a patch that's just fine, but > before you sent that, I sent in ten patches with C++ style comments. > Alexandre would now have to reply to ten patches with "No C++ style comments" > before processing your patch. Everybody reading wine-patches could point out > what was wrong with my patches. How about emacs macros that would send "Patch rejected" or "Patch under consideration" to wine-patches or wine-devel ? This would get rid of the feeling that patches are dropping into a black hole while only costing Alexandre a fraction of a second per patch.

1 0

Re: Minimize window via style change
by Dmitry Timoshkov Sept. 23, 2006

Sept. 23, 2006

"Sebastian Reichelt" <SebastianR(a)gmx.de> wrote: > + if (winpos->flags & SWP_FRAMECHANGED) > + { > + DWORD style = GetWindowLongW( winpos->hwnd, GWL_STYLE ); > + X11DRV_set_iconic_state( winpos->hwnd ); > + if (style & WS_MINIMIZE) > + return TRUE; > + } > + > if (!SWP_DoWinPosChanging( winpos, &newWindowRect, &newClientRect )) return FALSE; > > /* Fix redundant flags */ X11DRV_set_iconic_state() call should be moved under the 'if' case. Next, you can't really avoid calling SWP_DoWinPosChanging and probably sending WM_WINDOWPOSCHANGED. This behaviour needs a good test case. -- Dmitry.

1 0

compiling wine for amd64
by Gerald Britton Sept. 23, 2006

Sept. 23, 2006

Hi -- I'm running ubuntu dapper on amd64. I want to compile wine but am hitting problems. I got the dependencies just fine, but the compile died. Here's what I get: $ sudo apt-get -y --build source wine Reading package lists... Done Building dependency tree... Done Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.dsc' Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06.orig.tar.gz' Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.diff.gz' Need to get 0B of source archives. Skipping unpack of already unpacked source in wine-0.9.21~winehq0~ubuntu~6.06 dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.21~winehq0~ubuntu~6.06-1 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. /usr/bin/make distclean make[1]: Entering directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06' make: [clean] Error 2 (ignored) #-/usr/bin/make -C documentation clean cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess dh_clean debian/rules build dh_testdir # Add here commands to configure the package. CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for x86_64-linux-gnu-gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Error 77 Build command 'cd wine-0.9.21~winehq0~ubuntu~6.06 && dpkg-buildpackage -b -uc' failed. E: Child process failed I attached the config.log. What must I do to complete the compiles?

4 7

Re: wined3d/CopyRects bug fix
by Stefan Dösinger Sept. 22, 2006

Sept. 22, 2006

Am Montag 18 September 2006 10:12 schrieb Christopher GAUTIER: > Hello there, > > I've identified a bug in IWineD3DDeviceImpl_CopyRects. When CopyRects() > is called to copy the source entirely into the destination surface, and > that the sizes matches, a plain memcpy() is done. However, this assumes > that the surfaces have the same pitch, and this is not always the case. Welcome to Wine :-) IWineD3DDevice::CopyRects is a subset of IWineD3DSurface::BltFast(from DirectDraw), and I thought some time ago I sent a patch which makes CopyRects call BltFast. This patch apparently wasn't applied, and I did a google search for it and couldn't find it either. Looks like I moved it to /dev/null accidentally. We should call BltFast to avoid duplicating code. BltFast is also able to handle corner cases like bad rectangles. Can you test the attached patch? I have no game which uses CopyRects, so I can't test my patch. This is just a quick per-msdn implementation. Thanks, Stefan

2 1

Re: DDraw: Don't destroy complex attached surfaces even if explicitely requested as they will be liquidated anyway when the root is destroyed.
by Michael Stefaniuc Sept. 22, 2006

Sept. 22, 2006

Elie Morisse wrote: > A new version of my refcounting patch, lighter and honoring Stefan Dösinger proposal. You forgot to attach the patch. 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

Re: msi: update target file paths on MsiSetTargetPath (for TARGETDIR)
by James Hawkins Sept. 22, 2006

Sept. 22, 2006

On 9/21/06, Andrey Turkin <pancha(a)mail.nnov.ru> wrote: > MsiSetTargetPath can be used to change target path for directory after > CostFinalize, and all affected file paths must be recalculated. James > Hawkins sent a patch to make Wine's MSI engine do it for most cases; > this patch fixes one remaining "corner" case with TARGETDIR, and adds > test for it. > > ChangeLog: > > msi: Don't treat TargetDir specifically in resolve_folder > > > diff -aur wine-0.9.21/dlls/msi/helpers.c wine-0.9.21-my/dlls/msi/helpers.c > --- wine-0.9.21/dlls/msi/helpers.c 2006-09-13 23:10:25.000000000 +0400 > +++ wine-0.9.21-my/dlls/msi/helpers.c 2006-09-22 04:26:42.000000000 +0400 > @@ -216,29 +216,13 @@ > if (!name) > return NULL; > > - /* special resolving for Target and Source root dir */ > - if (strcmpW(name,cszTargetDir)==0 || strcmpW(name,cszSourceDir)==0) > + /* special resolving for Source root dir */ > + if ( strcmpW(name,cszSourceDir)==0) > { > - if (!source) > - { > - LPWSTR check_path; > - check_path = msi_dup_property( package, cszTargetDir ); > - if (!check_path) > - { > - check_path = msi_dup_property( package, cszRootDrive ); > - if (set_prop) > - MSI_SetPropertyW(package,cszTargetDir,check_path); > - } > - > - /* correct misbuilt target dir */ > - path = build_directory_name(2, check_path, NULL); > - clean_spaces_from_path( path ); > - if (strcmpiW(path,check_path)!=0) > - MSI_SetPropertyW(package,cszTargetDir,path); > - msi_free(check_path); > - } > - else > + if (source) > path = get_source_root( package ); > + else > + path = NULL; > if (folder) > *folder = get_loaded_folder( package, name ); > return path; > @@ -251,6 +235,11 @@ > if (folder) > *folder = f; > > + if (strcmpW(name, cszTargetDir)==0 && !f->ResolvedTarget && !f->Property) > + { > + f->Property = msi_dup_property( package, cszRootDrive ); > + } > + > if (!source && f->ResolvedTarget) > { > path = strdupW( f->ResolvedTarget ); > This fix is incorrect. What happens now when we call resolve_folder(package, "TARGETDIR", FALSE, TRUE, folder)? Your changelog says "Don't treat TargetDir specifically in resolve_folder" yet you're treating it specifically right here, but without the functionality that's still needed. Please resend the tests with todo_wine around failing tests. > > +#define ADD_SLASH(x) do { char *t; if (x[0]) {t=x+strlen(x)-1;if(t[0] != '\\' ) {t[1] ='\\';t[2] ='\0';}}} while (0) > + This is a really bad macro. Please use PathAddBackslash. -- James Hawkins

1 0

Re: WineD3D: glBlend* fixes
by Jesse Allen Sept. 21, 2006

Sept. 21, 2006

On 9/21/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > 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. Officially it is part of the GL_ARB_imaging extension but not all vendors fully implement it and that's why only Nvidia and 3dlabs advertise it. This causes glBlendColor not to work on other implementations. So in case of GL 1.1, the detection is dropped. > > 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. > 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? http://www.opengl.org/registry/specs/EXT/blend_minmax.txt http://www.google.com/search?hl=en&lr=&q=GL_EXT_blend_min_max&btnG=Search Also, the TRACE call in device.c:4513 needs a \n added too ;) Jesse

1 0

Re: Status of dlls that you maintain
by Jeff Latimer Sept. 21, 2006

Sept. 21, 2006

Tom Wickline wrote: > On 9/21/06, Jeff L <lats(a)yless4u.com.au> wrote: > >> >> BTW, the WWN #292 looks to be out of date as those functions are now >> implemented. > > > Hmm, Brian Vincent does the WWN and I just link the WWN articles to > the status > pages.. > Tom > Brian, I have successfully run Notes 7 on wine and the problems mentioned in WWN #292 have been fixed. Jeff Latimer

1 0

Re: [c2man] remove hardcoded extension (try#2)
by Alexandre Julliard Sept. 21, 2006

Sept. 21, 2006

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> writes: > my $uc_dll_name = uc $dll_name; > + > + if (($dll_ext ne 'ds') && ($dll_ext ne 'acm') && ($dll_ext ne 'drv') > + ($dll_ext ne 'exe') && ($dll_ext ne 'ocx') && ($dll_ext ne 'vxd')) > + { > + $dll_ext='dll'; > + } You are still hardcoding things, there's really no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

3 4

ATI and GL_ARB_Imaging support
by Kapila De Silva Sept. 21, 2006

Sept. 21, 2006

Hi all, I noticed, that wine checks for GL_ARB_imaging, before performing operations like glBlendColor, glBlendEquation etc. However it appears that the ATI drivers do not support this extension, though they do support the blending operations. I posted about this on the Rage3d linux driver boards, and the response seems to suggest that it would be better to check for the individual operations rather than the GL_ARB_imaging extension. See bottom of http://rage3d.com/board/showthread.php?t=33814685 What do you guys think? Kap.

2 1

Re: msi [6/7]: Translate the INSTALLSTATE_UNKNOWN index into the INSTALLSTATE_ABSENT image index
by Juan Lang Sept. 21, 2006

Sept. 21, 2006

Hiya James, - TRACE("Feature %s -> %d %d %d\n", debugstr_w(feature->Title), + printf("Feature %s -> %d %d %d\n", debugstr_w(feature->Title), I don't think you meant that to slip in. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Text Layout Summit
by Daniel Glassey Sept. 21, 2006

Sept. 21, 2006

Hi folks, There is going to be a Text Layout Summit during the Boston Gnome Summit http://live.gnome.org/Boston2006/TextLayout We are going to discuss things related to text layout. Hopefully we will discuss a uniscribe compatible API that could be used by wine and mono SWF since afaik neither has uniscribe support. It would be great if someone from wine and mono could be there. If that wouldn't be possible we would appreciate your input on what you would need. Regards, Daniel P.S. OK to CC me on replies as I'm not subscribed to either list.

2 1

Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
by Dmitry Timoshkov Sept. 21, 2006

Sept. 21, 2006

"Huw Davies" <huw(a)codeweavers.com> wrote: > - ok(sz1.cx == sz2.cx && sz1.cy == sz2.cy, > - "results from GetTextExtentExPointW and GetTextExtentPointW differ\n"); > + ok(sz1.cy == sz2.cy, > + "cy from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld) differ\n", sz1.cy, sz2.cy); > +todo_wine { > + /* The \n in the string is apparently handled differently in GetTextExtentPoint and GetTextExtentExPoint */ > + ok(sz1.cx != sz2.cx, > + "cx from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld) are the same\n", sz1.cx, sz2.cx); > + } This test fails for me (i.e. sz1.cx == sz2.cx) under XP (SP2+all the latest fixes). -- Dmitry.

2 3

Re: X11DRV: wgl move font code [resubmit]
by Roderick Colenbrander Sept. 20, 2006

Sept. 20, 2006

This time with a patch. > Hi, > > This is a resubmit of the previous font moving patch against the latest > cvs/git version. The old version didn't apply anymore to winex11.drv. For the > rest the patch is the same. > > Regards, > Roderick Colenbrander > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > -- NEU: GMX DSL Sofort-Start-Set - blitzschnell ins Internet! Echte DSL-Flatrate ab 0,- Euro* http://www.gmx.net/de/go/dsl

1 0

Re: X11DRV: wgl move font code [resubmit]
by James Hawkins Sept. 20, 2006

Sept. 20, 2006

On 9/20/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This is a resubmit of the previous font moving patch against the latest cvs/git version. The old version didn't apply anymore to winex11.drv. For the rest the patch is the same. > You forgot to attach the patch. -- James Hawkins

1 0

EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
by Nick Law Sept. 20, 2006

Sept. 20, 2006

I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox & wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following.... It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 & state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name & state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus & figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints & tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun.

2 1

msi/iTunes and questions
by Paul Vriens Sept. 20, 2006

Sept. 20, 2006

Hi, just for fun I've tried to install iTunes 7 on a fresh .wine. According to the AppDB this fails (one should first install QuickTime). While going through some traces I saw something the apparently needs this fix, but I'm no MSI-guy: diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c index dad67a2..7b862fe 100644 --- a/dlls/msi/custom.c +++ b/dlls/msi/custom.c @@ -703,8 +703,8 @@ static UINT HANDLE_CustomType19(MSIPACKA static const WCHAR query[] = { 'S','E','L','E','C','T',' ','`','M','e','s','s','a','g','e','`',' ', 'F','R','O','M',' ','`','E','r','r','o','r','`',' ', - 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ', - '%','s',0 + 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ','\'', + '%','s','\'',0 }; MSIRECORD *row = 0; LPWSTR deformated = NULL; The single-quotes should be needed as the SQL statement in the trace showed: trace:msi:MSI_DatabaseOpenViewW L"SELECT `Message` FROM `Error` WHERE `Error` = The installlation of QuickTime did not complete successfully. iTunes requires QuickTime." 0x6669a498 and a bit further: err:msidb:WHERE_VerifyCondition Couldn't find column L"The" This is just one of many issues with this installation. Does the fix look OK? Should this be sent? If it has to be accompanied with tests then please use the above fix at will, as I don't have the time (nor the msi-skills to look into that). Cheers, Paul.

3 2

Re: oleaut32 1/2: Implements function variant:VarImp
by Alexandre Julliard Sept. 20, 2006

Sept. 20, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + case VT_I1: if (V_I1(left) == -1) resvt = VT_NULL; break; > + case VT_UI1: if (V_UI1(left) == 0xff) resvt = VT_NULL; break; > + case VT_I2: if (V_I2(left) == -1) resvt = VT_NULL; break; > + case VT_UI2: if (V_UI2(left) == 0xffff) resvt = VT_NULL; break; > + case VT_INT: if (V_INT(left) == -1) resvt = VT_NULL; break; > + case VT_UINT: if (V_UINT(left) == 0xffffffff) resvt = VT_NULL; break; > + case VT_I4: if (V_I4(left) == -1) resvt = VT_NULL; break; > + case VT_UI4: if (V_UI4(left) == 0xffffffff) resvt = VT_NULL; break; > + case VT_I8: if (V_I8(left) == -1) resvt = VT_NULL; break; > + case VT_UI8: if (V_UI8(left) == 0xffffffff) resvt = VT_NULL; break; Shouldn't the last one be something like ~(ULONGLONG)0 instead of 0xffffffff? -- Alexandre Julliard julliard(a)winehq.org

2 2

EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
by Nick Law Sept. 20, 2006

Sept. 20, 2006

I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox & wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following.... It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 & state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name & state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus & figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints & tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. -- Regards Nick Law Mobile: 07736 022165 Email: nick.law(a)mic-nucmed.co.uk Medical Imaging Consultancy Ltd (M.I.C) Sales and Service of ADAC and IS2 Products http://www.mic-nucmed.co.uk

2 2

Re: Implement GetKerningPairs for TrueType fonts, take 4
by Huw Davies Sept. 20, 2006

Sept. 20, 2006

On Thu, Sep 21, 2006 at 12:18:51AM +0900, Dmitry Timoshkov wrote: > this version of the patch incorporates another Huw's suggestion > in eliminating redundant local variable and simplifying the code. Thanks Dmitry, Looks good to me. -- Huw Davies huw(a)codeweavers.com

1 0

Recovering a patch accidentally removed by git reset
by Jeff L Sept. 20, 2006

Sept. 20, 2006

How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? git fetch does not seem to refresh the patch from the repository. I was going fairly well with git then stuffed this up. Jeff

4 4

Re: Implement GetKerningPairs for TrueType fonts, take 3
by Huw Davies Sept. 20, 2006

Sept. 20, 2006

On Wed, Sep 20, 2006 at 03:22:02PM +0900, Dmitry Timoshkov wrote: > Changelog: > Implement GetKerningPairs for TrueType fonts. Hi Dmitry, Looks good, apart from one small nitpick below. I still think it would be nice to add the tests that you have to the test suite, even if it's just something that checks the first few pairs of Arial at some fixed font height. .... > +static DWORD parse_format0_kern_subtable(GdiFont font, > + const struct TT_format0_kern_subtable *tt_f0_ks, > + const USHORT *glyph_to_char, > + KERNINGPAIR *kern_pair, DWORD cPairs) > +{ .... > + kern_pairs_copied = 0; > + > + for (i = 0; i < nPairs; i++) > + { > + kern_pair->wFirst = glyph_to_char[GET_BE_WORD(tt_kern_pair[i].left)]; > + kern_pair->wSecond = glyph_to_char[GET_BE_WORD(tt_kern_pair[i].right)]; > + kern_pair->iKernAmount = MulDiv((short)GET_BE_WORD(tt_kern_pair[i].value), font->ppem, font->ft_face->units_per_EM); > + > + TRACE("left %u right %u value %d\n", > + kern_pair->wFirst, kern_pair->wSecond, kern_pair->iKernAmount); > + > + kern_pair++; > + kern_pairs_copied++; > + if (!--cPairs) break; > + } Seems to me that if you set nPairs = min(cPairs, nPairs) at the start of the loop, then you can eliminate the break and get rid of the kern_pairs_copied variable that basically mirrors i. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

make test failure
by Ivan Leo Puoti Sept. 20, 2006

Sept. 20, 2006

Here is a make test failure I'm getting on my laptop (for those of you who were not at wineconf, make test should, in theory, work everywhere) ../../../../wine/tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so ../../../../wine/dlls/gdi/tests/font.c && touch font.ok font.c:276: Test failed: Courier(13): tm.tmAscent 10 != 11 font.c:277: Test failed: Courier(13): tm.tmDescent 3 != 2 make[2]: *** [font.ok] Error 2 make[2]: Leaving directory `/home/ivan/build/dlls/gdi/tests' make[1]: *** [gdi/tests/__test__] Error 2 make[1]: Leaving directory `/home/ivan/build/dlls' make: *** [dlls/__test__] Error 2

8 7

RegisterHotKey/UnregisterHotKey implementation...success?
by Aaron Slunt Sept. 20, 2006

Sept. 20, 2006

http://www.winehq.com/pipermail/wine-devel/2006-May/047460.html The above link I looked at, and I saw this person was apparently crashing with the patch when trying to register a hotkey twice (that's how I interpreted it). Anyways, I looked at the patch, and cleaned it up so it applies to the current git tree. Anyways, it seems that I simply cannot reproduce the crash he was talking about. I binded F1 in HLSS (Half-Life Sound Selector), and opened another copy of HLSS. It simply would not allow me to register the key again. So I closed the second copy of HLSS and opened Ventrilo. I attempted to bind F1, and again it simply would not allow it. And let me make this clear, not once did I crash with this patch. HLSS works (fundamentally, not perfectly) when using it with Counter-strike (the hotkey works, there are window management problems though which have nothing to do with this) and I just never crashed with it. I'm attaching the patch for others to test if they could, and to see if a crash can be reproduced. But to me it looks like the work Robert Reif and Vincent Povirk is a huge success.* *

2 2

COM
by Joe McCay Sept. 20, 2006

Sept. 20, 2006

A recent article in a Linux magazine talking about winelib mentioned using __attribute__((com_interface)). I thought that attribute was no longer valid in gcc. The reason I am asking is because I am trying to do COM development using mingw, C++, & (hopefully) WIDL. I thought the 3.x and higher version of gcc supported -fvtable-thunks by default making it binary compatible with windows COM. Does anyone know if this is really true? jmccay

1 0

Problem with a Turbolog4.exe application under wine
by James Courtier-Dutton Sept. 19, 2006

Sept. 19, 2006

Hi, A demo version of Turbolog4 can be downloaded from: http://www.turbolog.de/ The program installs ok, but fails to run correctly. It asks for a License key, one should be able to press cancel and bypass it into demo mode where a window is displayed for entering log records. Can anyone help be diagnose why it fails. James

2 1

Something's wrong with my GIT tree
by Aaron Slunt Sept. 19, 2006

Sept. 19, 2006

http://pastebin.ca/176787 I've had this for several days, and git fetch tells me everything's up to date. Is this a known issue? How do I get rid of this? ./configure --x-libraries=/emul/linux/x86/usr/lib/ LDFLAGS="-L/emul/linux/x86/usr/lib -L/emul/linux/x86/lib" && make depend && make That configure has always worked for me, and it gets through make depend, it's just failing on make with that error message.

2 1

Error in GDI (StretchBlt) - proper fix?
by David Gümbel Sept. 19, 2006

Sept. 19, 2006

Hello everybody, I am debugging an application and got up to the point where I have reason to believe that the StretchBlt function in GDI is part of the problem. A backtrace of the exception I always run into looks like this: err:syslevel:_CheckNotSysLevel Holding lock 0x7ecd0820 level 3 wine: Unhandled exception 0x80000003 at address 0x0000:0x7ee96b34 (thread 0011), starting debugger... WineDbg starting on pid 0x10 err:syslevel:_CheckNotSysLevel Holding lock 0x7ecd0820 level 3 0x7ee96b35 _CheckNotSysLevel+0x3d in kernel32: addl $36,%esp Wine-dbg>bt Backtrace: =>1 0x7ee96b35 _CheckNotSysLevel+0x3d in kernel32 (0x7ee96b35) 2 0x7ec84c81 GDI_CheckNotLock+0x20 in gdi32 (0x7ec84c81) 3 0x7ec628e8 DeleteDC+0x26 in gdi32 (0x7ec628e8) 4 0x7ec6420b GetDIBits+0x1fd in gdi32 (0x7ec6420b) 5 0x7ec6c282 in gdi32 (+0x2c282) (0x7ec6c282) 6 0x7ec5bfee StretchBlt+0xca in gdi32 (0x7ec5bfee) 7 0x0042a3aa in bav (+0x2a3aa) (0x0042a3aa) 8 0x00425460 in bav (+0x25460) (0x00425460) 9 0x005d1304 in bav (+0x1d1304) (0x005d1304) 10 0x005e4f5d in bav (+0x1e4f5d) (0x005e4f5d) 11 0x0066f10b in bav (+0x26f10b) (0x0066f10b) 12 0x00681f8b in bav (+0x281f8b) (0x00681f8b) 13 0x7ee7ff5f in kernel32 (+0x4ff5f) (0x7ee7ff5f) 14 0xb7e9d387 wine_switch_to_stack+0x17 in libwine.so.1 (0xb7e9d387) When looking at StretchBlt's source code, I see a comment saying that there is a race condition in this function[1]. If I'm not mistaken, this problem has been reported in january as bug #4284, causing trouble (a deadlock) with MS PowerPoint[2]. Walt Ogburn suggested in january that commenting out #define STRETCH_VIA_DIB in dlls/gdi/mfdrv/bitblt.c could work around the problem[3]. Does anybody have any idea on how a proper fix for that function might approximately look like? Thanks, David [1] http://source.winehq.org/source/dlls/gdi/bitblt.c#L139 [2] http://bugs.winehq.com/show_bug.cgi?id=4284 [3] http://www.winehq.org/pipermail/wine-devel/2006-January/044040.html

1 0

Re: Fix a memory leak, fix a typo in the comment, add a trace
by Huw Davies Sept. 19, 2006

Sept. 19, 2006

On Tue, Sep 19, 2006 at 11:44:52AM +0900, Dmitry Timoshkov wrote: > please apply after "Implement GetKerningPairs for TrueType fonts". > > Changelog: > - fix a memory leak > - fix a typo in the comment > - add a trace about skipped a not supported kerning table format Hi Dmitry, Wouldn't it be nicer to simply resend the first patch again with these fixes applied? Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [WINED3D] Pbuffer/ActiveRender cleanup #2
by H. Verbeet Sept. 19, 2006

Sept. 19, 2006

On 17/09/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > @@ -156,6 +160,7 @@ typedef struct wined3d_settings_s { > BOOL glslRequested; > int vs_selected_mode; > int ps_selected_mode; > + int offscreen_selected_mode; > /* nonpower 2 function */ > int nonpower2_mode; > int rendertargetlock_mode; When you change wined3d_settings, you should make sure that you update the defaults in wined3d_main.c as well. I know those are currently mismatched, but I've got a patch to clean it up. I'm currently waiting for Alexandre to apply/reject some of the wined3d patches sent over the past couple days before sending it (and some other patches). I'm not sure if using wined3d_settings is really the right place to store things that don't have a corresponding registry key, but it seems like the best place for now. To clarify what OFFSCREEN_NONE does, it renders to the backbuffer for the current context, rather than using a separate context, and copies it to a texture when done. That's also why, depending on the primitive drawing order, you sometimes see the offscreen surface in the lower left corner of the screen.

2 3

My Wineconf 2006 trip report
by Marcus Meissner Sept. 19, 2006

Sept. 19, 2006

Hi folks, I had to write it up for my dear colleagues anyway, so here my notes... Feel free to reuse as you like. Attendance was around 35 people, all developers. Location was the university campus of Reading, a lecture hall in the Agriculture Department. The conference was organized by CodeWeavers, but sponsored by mostly 2 donors of each 1000 (?) US$ to the Wine project, one private person and a Poker website (strange enough). Around 10 - 15 developers were CodeWeavers employees, the other were volunteer developers. 1. Keynote by Alexandre Julliard (CW) Alexandre Julliard, our resident dictator and lone committer held the keynote. - The beta (0.9.*) works out fine. The 2 month code freeze before Beta has helped, and bugs got nicely pruned. The bugzilla stat char showed a nice increase in reported and also in fixed bugs. - Wine 1.0 plans Code Freeze perhaps later this year, for several months, then 1.0 release early next year. - Post 1.0 Unclear. Likely will have a stable and a feature branch. - GIT GIT is working out nicely. Number of monthly (?) commits grew from 400 at the turnover point to around 700 now. Reasons: * More smaller and confined patches (also thanks to GIT allowing incremental local commits). * GIT patch submission is in one defined patch format. Earlier patches were occcasionaly generated from subdirectories, misformatted, hand edited or similar. GIT changes this to one defined format, making his work easier. * "Developers might not like it, but I do". - Goals for 1.0 * Better Game Support (DirectX). This is pretty much heavy work in progress currently. * Regressiontests, Documentation are fine as-is. * Copy Protection support for Games etc. Necessary to run lots of games. However this is not a release stopper. - LOC still increasing, around 1.800.000 now. - COM (Component Object Model) report by Rob Shearman (CW) Rob (and others) spent most of last year enhancing and fixing the COM, OLE and RPCRT parts of WINE and summarized it. The out of process COM used by InstallShield has seen lots of changes and is working much better now. Work on remote COM was necessary for Outlook which talks COM via RPC over TCP sockets with the Outlook server. - GIT Tutorial by Mike McCormack (CW) Not WINE specific, so no details. - cxtest by Martin Pilka (CW) cxtest is the ongoing developed GUI testing kit from Codeweavers. Basic idea is that it can generate keypresses, mouseclicks and similar things and then captures images at various intervals and compares them with previous runs. Needs review of problems, but has definitely spotted some already. - Google's use of WINE by Dan Kegel (Google) 2 major Windows applications that wanted a Linux port. - Picasa Requirement: _No_ Windows binary code change. Hired Codeweavers as company to fix issues: - lots of bugfixes - IWebBrowser implementation - File change notification (implemented with inotify) - Video Codec handling fixes (both in MSVIDEO and DSHOW) - However: Needed to disable CD Burning Module of Picasa. Works on almost all distros nicely. - Google Earth WINE has OpenGL-in-Window problems, otherwise this might have been a WINE job too likely. The Loki Installer guy (Brad something?) did the port on-site (this 1 person did the port). Exposes lots of OpenGL / GFX card related related problems. -> But received more press and recognition. No other Windows applications of Google need to be ported currently. (Google Desktop would be one, but it requires integration into native browsers, so it is too Windows specific.) Dan also oversees 4 Google interns working on Wine. - CrossOver on Mac by Andrew Bogott (CW) Beta on MacOS/X (Intel) of CrossOver Office available. Andrew demoed MS Excel, including installation of it. GUI toolkit is in TCL + Coco (? graphical Mac scripting language) Use X11 graphics driver, Quartz driver is currently being considered. Caused stability problems with Mac Kernel. Caused stability problems with Mac X Server. Is slower than on Linux due to lack of some fast methods we use on Linux (I guess something like threading, futexes or so. -Marcus) - Governance breakout session The point sometimes comes up whether to replace Alexandre. The present developers did not agree, so there was not much discussion. We evaluated _why_ they want it: - They want low quality hacks into the tree to make apps work. This is a no go, you need to fix it right. - They get no reply on their submission _why_ it was rejected. True reason, we discussed a bit how to improve. - A bot welcoming new patch posters? - checks for most common problem, // comments - people actively taking care of areas and responding to people - Alexandre waiting for comments from those responsibles on difficult patches - Branch Maintainership post 1.0 ... Briefly touched, but we will see when we get there. - Packaging breakout session Its unclear (to me at least) what is wanted ;) Paul Millar wants nightly regression tests (cxtest runs with downloaded binaries?) Some want nightly builds. Some want .spec files in a central repository. Marcus is trying to bring up RPM builds for SUSE, Mandriva 2006.0, Fedora Core 4 and 5 on the openSUSE buildservice. Debian to come. Ciao, Marcus

2 2

Wine 0.9.21 fails to run
by Ken Zalewski Sept. 19, 2006

Sept. 19, 2006

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

2 1

wine conf group photo
by EA Durbin Sept. 18, 2006

Sept. 18, 2006

The link on the winehq.org page for the photo is returning 404 not found.

2 1

Re: winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo
by Jesse Allen Sept. 18, 2006

Sept. 18, 2006

On 9/17/06, Phil Costin <philcostin(a)hotmail.com> wrote: > Roderick Colenbrander wrote: > > > The problem is that I'm not sure (and I think it is Alexandre his issue > > aswell) whether this patch is a workaround or a real fix. I think that > > wined3d created a GLX context in lets say thread '1' and that it wants to > > create lets say another one in a different thread. If this is the case it > > could happen that for the new thread the x11drv visual needs to be > > 'rechosen'. This causes the 'info' code to be called again. Because this > > code creates a context we mess up the already active context. > > > > Your patch indeed fixes that by storing the current GLX context and > > restoring it later on. Perhaps there's a nicer way to prevent this issue > > to happen at all. > > > > In any case I think it might be nicer to use glXGetCurrentContext in case > > there's already some GLX context around. So in that case don't create a > > new context and don't kill it at the end. This would already be cleaner. > > > > Roderick > > > > > > > >> I don't know myself either. I was just going to wait. I want to add a > >> little more to say about it. > >> > >> It's funny that the patch was only meant to affect the opengl/wgl code > >> and the crashing apps are all d3d ones. However winex11 will now > >> change the context on it's own when doing the opengl query and not set > >> it back. What I noticed a couple weeks ago and now is that winex11 > >> does usually gets inited twice, therefore it will change the current > >> context twice. One at the start of the program, and another later on > >> -- maybe on creation of a window or something. By that time wined3d is > >> probably inited too, and making glXMakeCurrent calls too since it's > >> based on opengl. So perhaps winex11 is causing wined3d to trip up at > >> some point by changing the context. So if InitOpenglInfo just sets > >> things back, then wined3d won't go boom. > >> > >> >>From comments in wined3d, I can tell there isn't any "context > >> manager". So what wined3d does at most is very simple management of > >> contextes. We probably need a manager to coordinate things like this > >> better between the two libraries. But that will likely be a bigger > >> patch and to do so... I don't know, we need a fix for all the broken > >> d3d apps now. > >> > >> Jesse > >> > > > > > At the moment, this patch fixes regressions so if we don't have the code in > there at all, many games do not work. > > It may not be the ideal solution but is it not better for now to fix the > regression and think about a proper solution separately without breaking > applications by not having the patch applied? > > Regards, > Phil > > > > Phil, Roderick, I'm going to look at what I can do to improve the patch and gather more information on the handling of contextes. I just haven't had time yet. And Roderick, I'll discuss with you the newer patch when I'm ready so to see if you agree with it. I do lean towards agreeing with Phil on that this is simply needed and more than a workaround. I've already been asked many times if the patch has gotten in and that is why I posted to wine-patches so quickly; your patch broke alot of D3D apps for alot of people... The d3d9 stateblock test is the best clue. Jesse

2 2

Visual C++ does not seem to have snprinft
by Jeff L Sept. 18, 2006

Sept. 18, 2006

When compiling dlls/gdi/tests/metafile.c on line 1357 I get a warning C4013: "snprintf" is undefined. Looking around, it seems that snprinft is in fact _snprintf in Visual C++. I have found a define #if !defined(HAVE_SNPRINTF) && defined(HAVE__SNPRINTF) #define snprintf _snprintf #endif in wine/port.h but it requires config.h and they don't appear in my Visual C++ system. What is the best way to address this problem? It seems to be fairly common but I have not found an example in a test. Jeff Latimer

6 5

Re: If there is no space for strings GetOutlineTextMetricsA should not indicate that they present
by Paul Vriens Sept. 18, 2006

Sept. 18, 2006

On Mon, 2006-09-18 at 19:00 +0900, Dmitry Timoshkov wrote: > Hello, > > this patch prevents my test application from crashing by dereferencing > memory beyond allocated memory block. > > Changelog: > If there is no space for strings GetOutlineTextMetricsA should not > indicate that they present. > > --- cvs/hq/wine/dlls/gdi/font.c 2006-08-15 14:51:46.000000000 +0900 > +++ wine/dlls/gdi/font.c 2006-09-18 18:38:57.000000000 +0900 > @@ -1483,6 +1483,20 @@ UINT WINAPI GetOutlineTextMetricsA( > if(output != lpOTM) { > memcpy(lpOTM, output, cbData); > HeapFree(GetProcessHeap(), 0, output); > + > + /* check if the string offsets really fit into the provided size */ > + /* FIXME: should we check string length as well? */ > + if ((UINT_PTR)lpOTM->otmpFamilyName >= lpOTM->otmSize) > + lpOTM->otmpFamilyName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpFaceName >= lpOTM->otmSize) > + lpOTM->otmpFaceName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpStyleName >= lpOTM->otmSize) > + lpOTM->otmpStyleName = 0; /* doesn't fit */ > + > + if ((UINT_PTR)lpOTM->otmpFullName >= lpOTM->otmSize) > + lpOTM->otmpFullName = 0; /* doesn't fit */ > } > > end: this one also fixes an issue I was looking into this morning: Try to create a key via regedit with the name {44444444-4444-4444-44444444} and press enter. Cheers and thanks, Paul.

1 0

OpenGL multiplexing and Wine
by Molle Bestefich Sept. 18, 2006

Sept. 18, 2006

A couple of OpenGL multiplexers for Xen (and VMWare, theoretically) exists: http://www.cs.toronto.edu/~andreslc/xen-gl/ http://www.diku.dk/hjemmesider/ansatte/jacobg/gfx/ They allow guest virtual machines to render 3D graphics using the host machine's graphics accelerator. I think they are very interesting in combination with Wine, because Wine can let Direct3D games run on top of OpenGL, making the multiplexers work for all modern games, whereas running a real Microsoft Windows guest would only allow acceleration for some games. There's a list of supported XGL versions and GL calls on this page under "Capabilities": http://www.cs.toronto.edu/~andreslc/xen-gl/ And a couple of whitepapers here: http://www.diku.dk/~jacobg/blink-techreport.pdf http://www.diku.dk/~jacobg/blink2.pdf Will WineGL run on top of a multiplexer, or does it lack support of some calls?

3 2

Wine directx and xinerama
by Roland Kaeser Sept. 17, 2006

Sept. 17, 2006

Hello all I just regognized that I get serious trouble trying to run apps on a xinerama screen (Matrox Parhelia) with Triple display configuration (http://www.matrox.com/graphics/workstation/cre_pro/products/pseries/p750.cfm / 01:00.0 VGA compatible controller: Matrox Graphics, Inc. Millenium P650/P750 (rev 02)). Running the same apps (such as Railroad Tycoon) on a "normal" machine with intel 945G (VGA compatible controller: Intel Corporation 945G/GZ Express Integrated Graphics Controller (rev 02)) its works fine. But running RT3 on my Matrox card makes it crashing or just bringing a error message, even when I configured a virtual desktop (1024x768). Does somebody has a idea about this behaviour? Thanks Roland

3 2

Will Wine run with Linspire 5?
by Ctm007 Sept. 17, 2006

Sept. 17, 2006

Will Wine run with Linspire 5? Carl Martin ctm007(a)houston.rr.com

1 0

Re: secur32: Add a warning if ntlm_auth is not found or in a wrongversion.
by Dmitry Timoshkov Sept. 17, 2006

Sept. 17, 2006

"Kai Blin" <kai.blin(a)gmail.com> wrote: > + else > + { > + WARN("ntlm_auth not found, or in an outdated version.\n" \ > + "Make sure you are using ntlm_auth =< 3.x and it is in your path.\n"); > + } If the message is supposed to be user visible (otherwise why to bother with wording?) it would be better to use either FIXME or MESSAGE. Also "=<" is not really understandable in this context. Did you mean that a version 3.x or better is required (then >= 3.x), or <= 3.x (then the word "outdated" is misleading)? -- Dmitry.

2 1

How to report code errors?
by Andrew Talbot Sept. 16, 2006

Sept. 16, 2006

How should one report minor code errors that don't necessarily produce known bad behaviour? To give a concrete example, in msacm32:driver.c acmDriverPriority(), formal parameter dwPriority is of type DWORD, which is unsigned, but it contains a line that reads: if (dwPriority < 0) dwPriority = -1; ... which can never happen. Bugzilla seems inappropriate, so does wine-devel. If Coverity has abandoned us, would it be worth having a web/wiki page for posting any such code anomalies, so that the knowledgable might consider fixing them? Thanks, -- Andy.

3 4

Already Error while installing MS Office 2003
by Roland Kaeser Sept. 16, 2006

Sept. 16, 2006

Hello Just tried to test install office 2003 on wine 0.9.21. But getting already errors. I read in C't (german it magazine) that office 2003 works on codeweavers. Can somebody declare me this? Does codeweavers voluntary not provide the corrections to wine to sell their product? Looks very strange to me. Roland Debug Output while installing office (breaks down when it trieds to start installation of the files (after setup configuration and serial number request) --------------------------------------------------------------------------------------------------------- fixme:imm:ImmDisableIME (-1): stub fixme:advapi:CheckTokenMembership ((nil) 0x190388 0x346d3c) stub! err:ole:CoUninitialize Mismatched CoUninitialize err:ole:CoUninitialize Mismatched CoUninitialize fixme:advapi:CheckTokenMembership ((nil) 0x1ad6f8 0x7d3683b8) stub! err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock" fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values err:msidb:WHERE_VerifyCondition Couldn't find column L"Lock" err:msi:msi_dialog_set_font No font entry for L"52" err:msi:msi_dialog_set_font No font entry for L"9" err:msi:msi_dialog_set_font No font entry for L"52" fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing fixme:msi:ControlEvent_SpawnWaitDialog Doing Nothing err:msi:msi_dialog_set_font No font entry for L"100" err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x1ed990 next block has PREV_FREE flag fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 67 ignored L"Upgrade" table values err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\1031\\OFREADME.HTM") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\1031\\OFREADME.HTM") fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders" fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"HTM_Editor_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Resource_DLLs_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"Core_IDE_Cmd_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"VS_SCC_Core_TeamCore_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"CSS_Package_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_SDM2_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"_VS_Debugging_VSDebug_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"WbBrwsrPckgRsrcDLLDEUX86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" fixme:msi:deformat_component component key L"URL_Font_Color_Picker_DEU_X86.3643236F_FC70_11D3_A536_0090278A1BB8" err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CSSPKGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CSSPKGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\HTMEDUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\HTMEDUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\htmdlgsUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\htmdlgsUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsdebugui.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsdebugui.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSDBGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSDBGUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSENVUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\MSENVUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsbrowseUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\vsbrowseUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\VisualStudioTeamCoreUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\VisualStudioTeamCoreUI.dll") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CMDDEFUI.DLL") err:msi:deformat_file Unable to get ShortPath size (L"c:\\Programme\\Microsoft Office\\OFFICE11\\VS Runtime\\1031\\CMDDEFUI.DLL") err:msi:ITERATE_Actions Execution halted, action L"SKURED" returned 1603 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603 fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default" fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"

10 14

Re: winex11.drv: cleanup better in X11DRV_WineGL_InitOpenglInfo
by Jesse Allen Sept. 16, 2006

Sept. 16, 2006

On 9/14/06, Phil Costin <philcostin(a)hotmail.com> wrote: > This patch fixes many games for me, what is the reason it was not applied? > > Regards > Phil Costin > > I don't know myself either. I was just going to wait. I want to add a little more to say about it. It's funny that the patch was only meant to affect the opengl/wgl code and the crashing apps are all d3d ones. However winex11 will now change the context on it's own when doing the opengl query and not set it back. What I noticed a couple weeks ago and now is that winex11 does usually gets inited twice, therefore it will change the current context twice. One at the start of the program, and another later on -- maybe on creation of a window or something. By that time wined3d is probably inited too, and making glXMakeCurrent calls too since it's based on opengl. So perhaps winex11 is causing wined3d to trip up at some point by changing the context. So if InitOpenglInfo just sets things back, then wined3d won't go boom. >From comments in wined3d, I can tell there isn't any "context manager". So what wined3d does at most is very simple management of contextes. We probably need a manager to coordinate things like this better between the two libraries. But that will likely be a bigger patch and to do so... I don't know, we need a fix for all the broken d3d apps now. Jesse

2 1

Re: X11DRV: fix fbconfig regression
by Roderick Colenbrander Sept. 16, 2006

Sept. 16, 2006

Ati doesn't advertise GLX_SGIX_fbconfig. They only advertise a GLX client version of 1.3. Because the Xserver only supports 1.2, the reported version is also 1.2 (only the client version number is 1.3, the rest not). Roderick > Roderick Colenbrander wrote: > > The issue is that ATI's drivers don't advertise GLX_SGIX_fbconfig (which > really all opengl drivers do) but on the other hand they advertise GLX > client version 1.3 which promoted GLX_SGIX_fbconfig to core functionality. So > ATI doesn't advertise GLX_SGIX_fbconfig but it is available because their > libs are 1.3. They only ship the 1.3 functions so not the SGIX ones. > > > > So, ATI correctly advertises what they support, I don't see any reason > to have workarounds there. > > tom -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

configure error
by Tijl Coosemans Sept. 16, 2006

Sept. 16, 2006

I get the following error running configure on FreeBSD: config.status: creating Makefile sed: 14: ./confstathEGAkR/subs-4.sed: unescaped newline inside substitute pattern There's one of those for every Makefile. The problem is with the following lines in configure.ac where I had to add '\\' to every line to work around the problem. Is this a FreeBSD only thing? AC_SUBST(DEPENDENCIES,"### Dependencies:\\ \\ .INIT: Makefile\\ .BEGIN: Makefile\\ Makefile: dummy\\ -\$(MAKEDEP) -C\$(SRCDIR) -S\$(TOPSRCDIR) -T\$(TOPOBJDIR) \$(EXTRAINCL) \$(DEPEND_SRCS)\\ \\ \$(ALL_OBJS): \$(IDL_SRCS:.idl=.h)\\ \$(LEX_SRCS:.l=.yy.o): \$(LEX_SRCS:.l=.yy.c)\\ \$(BISON_SRCS:.y=.tab.o): \$(BISON_SRCS:.y=.tab.c)")

2 1

Re: X11DRV: fix fbconfig regression
by Roderick Colenbrander Sept. 16, 2006

Sept. 16, 2006

> Roderick Colenbrander wrote: > > There's this check: > > if ((!WineGLInfo.glxDirect && !strcmp("1.2", > WineGLInfo.glxServerVersion)) || > > (WineGLInfo.glxDirect && !strcmp("1.2", > WineGLInfo.glxClientVersion))) > > > This is not the correct way of loading opengl functions or deciding > whether they are available or not. According to the > GLX_ARB_get_proc_address spec, we need to check _only_ > glXQueryExtensionsString() and glXQueryVersion() and it's not correct to > make assumptions based on server/client versions or extension strings. > > This patch removes all the client/server code and replaces it with the > correct checks. The patch fixes the code in has_opengl() (and also > replaces one wine_dlsym() with pglXGetProcAddressARB()) as well as the > helper function glxRequireExtension() and fixes the code that decices > whether pbuffers are available. Pbuffers are part of GLX 1.3, so if the > GLX version is 1.3 we _have_ pbuffers, no need to check for the > GLX_SGIX_pbuffers extension anymore (&& -> ||) > > If this patch works with ATI drivers, I don't know, but that's certainly > the correct way of querying functions. I'm aware of the GLX version / extension issues. The check is more or less a workaround for buggy drivers like ATI's :( I'm against workarounds but in this case without it, there won't be any OpenGL support on ATI's drivers as GLX_SGIX_fbconfig is a requirement for wine. (I have submitted a bugreport) BTW I had the same stuff in opengl32. The issue is that ATI's drivers don't advertise GLX_SGIX_fbconfig (which really all opengl drivers do) but on the other hand they advertise GLX client version 1.3 which promoted GLX_SGIX_fbconfig to core functionality. So ATI doesn't advertise GLX_SGIX_fbconfig but it is available because their libs are 1.3. They only ship the 1.3 functions so not the SGIX ones. When direct rendering is enabled we look at the GLX client version :( This only works for fbconfig stuff and not for other things like pbuffers (it does work on ATI cards but not on Mesa). I hope this clears it up, Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

Re: Already Error while installing MS Office 2003
by jimtabor Sept. 16, 2006

Sept. 16, 2006

Hi! > Hello > > >Codeweavers version of Wine has changes that Alexandre deems > >unacceptable for the "clean" WineHQ tree. > > If this is that way, it would be real a horror. Why are code patches > which allows a huge major app (key application) to run on linux > "unacceptable" (From point of view of the MS users). Do we here make > trench warfares? Or are there quality conceivabilities which are > completely unrealistic? Shouldn't we not see the major goal of wine? > To run windows apps on linux? Not to have a few lines code a bit > better quality etc. I think we don't have the choice to reject code. > Be very very thankful for each line which is checked in!! I think some > responsible persons are to deep in the code. They are looking just > into the code but can't see the benefit of the code for the wine > project itself. Why don't just accept the code? There is enough time > later to make it more "beautiful" or correct it to a better quality. > But for the moment, some of the code directly allows important apps to > work. > > Roland > > > I checked the Codeweavers version of Wine, there are a lot of "Codeweaver "HACK HACK HACK" Alerts" everywhere in key dlls. I compared it with 0.9.16 since the Codeweavers wine VERSION stated it. Amazing! James > >----- Ursprüngliche Mail ---- > >Von: Jim White <jim(a)pagesmiths.com> > >An: Roland Kaeser <roli8200(a)yahoo.de> > >CC: wine-devel(a)winehq.com > >Gesendet: Freitag, den 15. September 2006, 19:41:45 Uhr > >Betreff: Re: Already Error while installing MS Office 2003 > > > >Roland Kaeser wrote: > > > >> Just tried to test install office 2003 on wine 0.9.21. But getting > >> already errors. I read in C't (german it magazine) that office 2003 > >> works on codeweavers. Can somebody declare me this? Does codeweavers > >> voluntary not provide the corrections to wine to sell their product? > >> Looks very strange to me. > >> ... > > > >Codeweavers version of Wine has changes that Alexandre deems > >unacceptable for the "clean" WineHQ tree. > > > >The Codeweavers Wine source is here: > > > >http://www.codeweavers.com/products/source/ > > > >Jim > > >------------------------------------------------------------------------ >

1 0

[OT] Wine reveals bug in Microsoft Installer
by Segin Sept. 16, 2006

Sept. 16, 2006

I was recently just feeding random crap to Wine, in an attempt to "stress-test" Wine, for a lack of better words. I fed it the Microsoft Platform SDK Installer, and it revealed a bug in the program, probably related to translation. Image URI: http://segin.no-ip.org/wtf.png -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds

1 0

Re: X11DRV: fix fbconfig regression
by Tomas carnecky Sept. 16, 2006

Sept. 16, 2006

Roderick Colenbrander wrote: > There's this check: > if ((!WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxServerVersion)) || > (WineGLInfo.glxDirect && !strcmp("1.2", WineGLInfo.glxClientVersion))) This is not the correct way of loading opengl functions or deciding whether they are available or not. According to the GLX_ARB_get_proc_address spec, we need to check _only_ glXQueryExtensionsString() and glXQueryVersion() and it's not correct to make assumptions based on server/client versions or extension strings. This patch removes all the client/server code and replaces it with the correct checks. The patch fixes the code in has_opengl() (and also replaces one wine_dlsym() with pglXGetProcAddressARB()) as well as the helper function glxRequireExtension() and fixes the code that decices whether pbuffers are available. Pbuffers are part of GLX 1.3, so if the GLX version is 1.3 we _have_ pbuffers, no need to check for the GLX_SGIX_pbuffers extension anymore (&& -> ||) If this patch works with ATI drivers, I don't know, but that's certainly the correct way of querying functions. tom

1 1

Note and patch about strange UDP packets
by Florian Echtler Sept. 15, 2006

Sept. 15, 2006

Hi everybody, we are using a certain tracking software from Advanced Realtime Tracking. This is a windows software, but we decided yesterday that it would be more flexible to be able to use it under Linux, too, so I gave it a try with Wine. As this software communicates with customized (expensive) cameras via UDP, I noted a strange bug in the Wine debug channel "winsock": the software was sending UDP packets to IP _254_.255.255.255 (note the first octet). After some experimentation, I noticed that while Windows just sends this as a broadcast packet, Linux rejects this address, because the corresponding RFC states that the network 240.0.0.0/4 is reserved and should not be used. I therefore build a small patch which checks for these strange adresses and replaces them by broadcast adresses. This enabled our software to work. However, the question now is whether it makes sense to include this patch into Wine? On the one hand, it increases the similarity between Wine's behaviour and Windows's, OTOH it decreases Wine's RFC compliance.. Comments? Thanks, Yours, Florian

2 1

Re: [PATCH] PATCH: kernel 2.6 in README.de
by n0dalus Sept. 15, 2006

Sept. 15, 2006

On Wed Sep 13 10:57:33 2006 +0200, Marcus Meissner <marcus(a)beiboot.franken.de> wrote: > Mention kernel 2.6. > > --- > > documentation/README.de | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > 10857c3dbb8429ea599288ac93f4cecd8ffeff59 > diff --git a/documentation/README.de b/documentation/README.de > index c4a1324..680e077 100644 > --- a/documentation/README.de > +++ b/documentation/README.de > @@ -45,7 +45,7 @@ Linux-Info: > Obwohl Linux 2.2.x immer noch funktionieren sollte und Linux 2.0.x > vielleicht auch noch funktioniert (ältere 2.0.x-Versionen verzeichneten > Abstürze im Zusammenhang mit Threads), sollte man am besten einen > - aktuellen Kernel wie 2.4.x verwenden. > + aktuellen Kernel wie 2.4.x oder 2.6.x verwenden. > > FreeBSD-Info: > Stellen Sie sicher, dass Sie die Optionen USER_LDT, SYSVSHM, SYSVSEM und > -- > 1.2.4 > > > Hi, A few of the emails you've sent to the wine-patches mailing list lately have not had 'To:' headers. Many people have their mail clients configured to filter emails into folders based on 'To:' fields, so it would be great if you could sort that out (your last few ones, such as this one, ended up in my inbox instead of my wine folder). It probably means that whatever program you are using to send these emails is broken slightly. I hope you are able to work it out, n0dalus.

5 5

Troubles using current wine (wine-0.9.21)
by Louis. Lenders Sept. 15, 2006

Sept. 15, 2006

Hi, i'm having lots of troubles running games with current git. First of all i get these messages running every application i try: "err:wgl:has_opengl glx_version as 1.3 and GLX_SGIX_fbconfig extension is unsupported. Expect problems." Is it really that bad to not have glx_version 1.3? I have Ati radeon 9600 and i do not know if this is supported on my card anyway. Further, games that used to work now crash, for example Serious Sam I. The problem seems to be: 000f:Call gdi32.ChoosePixelFormat(000004f0,0033fc38) ret=004c70b9 000f:Call winex11.drv.ChoosePixelFormat(001aab78,0033fc38) ret=605c1358 trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) --> crash Any hints on this? --------------------------------- Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal

4 3

Re: advapi32, msi, rsaenh: MD4_CTX and MD5_CTX have the same elements, declare them in the same order.
by Hans Leidekker Sept. 15, 2006

Sept. 15, 2006

On Thursday 14 September 2006 11:13, Kai Blin wrote: > MD4_CTX and MD5_CTX have the same elements, declare them in the same order. Tell Microsoft about it ;-) Your patch breaks the md5 test on Windows because it depends on the struct layout: crypt_md5.c:90: Test failed: invalid initialization crypt_md5.c:93: Test failed: update doesn't work correctly crypt_md5.c:96: Test failed: update doesn't work correctly crypt_md5: 5 tests executed, 0 marked as todo, 3 failures. -Hans

3 5

rpcrt4 questions
by Damjan Jovanovic Sept. 15, 2006

Sept. 15, 2006

1. I was surprised to discover DCE RPCs (as opposed to DCOM) from wine to Windows do work. Is this documented anywhere? 2. Is there any reason why rpc_transport.c uses native sockets instead of winsock? 3. Would a patch to fix (2) be welcome? With a few more changes, it would also allow an RPC server to run on wine, as opposed to the current case where only clients work. Thank you Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: wine 0.9.21 - World of warcraft appears to be broken on ATI hardware ? crashes with Blizzard critical error
by Nick Law Sept. 15, 2006

Sept. 15, 2006

Vitaliy Margolen wrote: > Nick Law wrote: > >> I'm having the same problems with 0.9.21 here, World of Warcraft is >> broken, no longer runs at all on ATI hardware, (confirmed on two >> separate systems running with ATO 9550. (maybe ok on Nvidia hardware >> although not tried it myself). >> >> > Nick please open a bug in bugzilla, and do proper regression testing. > > Vitaliy. > > ok, I'll see what I can do over the next few days. Nick

1 0

Re: TRY 2: Socket resets randomly
by Vitaliy Margolen Sept. 15, 2006

Sept. 15, 2006

Ryan Miller wrote: > ws2_32: Fixed bug with sockets randomly resetting due to GetLastError being > reset by setsockopt in Windows, but not in Wine. Also included is the > associated test. > > + SetLastError(1); Please use more accepted value of 0xdeadbeef Vitaliy

1 0

wine 0.9.21 - World of warcraft appears to be broken on ATI hardware ? crashes with Blizzard critical error
by Nick Law Sept. 14, 2006

Sept. 14, 2006

I'm having the same problems with 0.9.21 here, World of Warcraft is broken, no longer runs at all on ATI hardware, (confirmed on two separate systems running with ATO 9550. (maybe ok on Nvidia hardware although not tried it myself). Upon trying to start WoW, a Blizzard dialog box appears which contains the following ( see my post http://appdb.winehq.org/appview.php?iVersionId=5606) Here's a summary World of WarCraft (build 5595) Exe: C:\Program Files\World of Warcraft\WoW.exe Time: Sep 14, 2006 10:58:59.684 PM User: guest Computer: linux ------------------------------------------------------------------------------ This application has encountered a critical error: ERROR #132 (0x85100084) Fatal Exception Program: C:\Program Files\World of Warcraft\WoW.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0073:00000000 The instruction at "0x00000000" referenced memory at "0x00000000". The memory could not be "read". WoWBuild: 5595 ------------------------------------------------------------------------------ ---------------------------------------- x86 Registers ---------------------------------------- EAX=7C093970 EBX=6103A374 ECX=00000003 EDX=610323CE ESI=00000000 EDI=7C340D00 EBP=0034FAF8 ESP=0034FA9C EIP=00000000 FLG=00210297 CS =0073 DS =007B ES =007B SS =007B FS =003B GS =0033 ---------------------------------------- Stack Trace (Manual) ---------------------------------------- Address Frame Logical addr Module 00000000 0034FAF8 0000:00000000 C:\Program Files\World of Warcraft\WoW.exe 61009DC0 0034FB58 0001:00038DC0 c:\windows\system\winex11.drv 6070C1FF 0034FB88 0001:0003B1FF c:\windows\system\gdi32.dll 0058C0DB 0034FC14 0001:0018B0DB C:\Program Files\World of Warcraft\WoW.exe 0058BF2C 0034FC24 0001:0018AF2C C:\Program Files\World of Warcraft\WoW.exe 0058CAA6 0034FC74 0001:0018BAA6 C:\Program Files\World of Warcraft\WoW.exe 00591B75 0034FC80 0001:00190B75 C:\Program Files\World of Warcraft\WoW.exe 0058C801 0034FCA0 0001:0018B801 C:\Program Files\World of Warcraft\WoW.exe 005896D7 0034FCB4 0001:001886D7 C:\Program Files\World of Warcraft\WoW.exe 00639E73 0034FD20 0001:00238E73 C:\Program Files\World of Warcraft\WoW.exe 004027EC 0034FE68 0001:000017EC C:\Program Files\World of Warcraft\WoW.exe 004021E0 0034FE78 0001:000011E0 C:\Program Files\World of Warcraft\WoW.exe 0040410E 0034FF08 0001:0000310E C:\Program Files\World of Warcraft\WoW.exe 603A6B81 0034FFE8 0001:00055B81 c:\windows\system\kernel32.dll ---------------------------------------- Stack Trace (Using DBGHELP.DLL) ---------------------------------------- 61009DC0 winex11.drv X11DRV_DescribePixelFormat+448 (0x001A9110,0x00000001,0x00000028,0x0034FBDC) (opengl.c,1004) 6070C1FF gdi32.dll DescribePixelFormat+175 (0x0000032C,0x00000001,0x00000028,0x0034FBDC) (painting.c,424) 0058C0DB WoW.exe +0 (0x0034FC74,0x00000000,0x0034FC74,0x0058CAA6) 0058BF2C WoW.exe +0 (0x0034FC3C,0x000002E4,0x011D0F30,0x011D0008) 0058CAA6 WoW.exe +0 (0x0034FCCC,0x0034FCA0,0x0058C801,0x0042CFD0) 00591B75 WoW.exe +0 (0x0042CFD0,0x0034FCCC,0x0034FD04,0x0042CFD0) 0058C801 WoW.exe +0 (0x0042CFD0,0x0034FCCC,0x00000000,0x0034FD20) 005896D7 WoW.exe +0 (0x0034FCCC,0x00401000,0x00000000,0x603D9968) 00639E73 WoW.exe +0 (0x00000001,0x6C726F57,0x666F2064,0x72615720) 004027EC WoW.exe +0 (0x00000001,0x00000001,0x0034FF08,0x0040410E) 004021E0 WoW.exe +0 (0x00409990,0x00400000,0x00000000,0x0011646C) 0040410E WoW.exe +0 (0x7FFDF000,0x00000000,0x00000000,0x00000000) 603A6B81 kernel32.dll start_process+209 (0x00000000,0x00000000,0x00000000,0x00000000) (process.c,822) 60020247 wine_switch_to_stack+23 (0x00000000,0x00000000,0x00000000,0x00000000) ---------------------------------------- Loaded Modules ---------------------------------------- 0x00350000 - 0x003E6000 C:\Program Files\World of Warcraft\fmod.dll 0x00400000 - 0x00D05000 C:\Program Files\World of Warcraft\WoW.exe 0x10000000 - 0x10069000 C:\Program Files\World of Warcraft\DivxDecoder.dll 0x60290000 - 0x602F7000 c:\windows\system\ntdll.dll 0x60350000 - 0x60435000 c:\windows\system\kernel32.dll 0x604B0000 - 0x604E3000 c:\windows\system\advapi32.dll 0x604F0000 - 0x60592000 c:\windows\system\comctl32.dll 0x605B0000 - 0x606B4000 c:\windows\system\user32.dll 0x606D0000 - 0x6073C000 c:\windows\system\gdi32.dll 0x60750000 - 0x60819000 c:\windows\system\shell32.dll 0x60830000 - 0x6086B000 c:\windows\system\shlwapi.dll 0x60880000 - 0x608F2000 c:\windows\system\ole32.dll 0x60900000 - 0x6093E000 c:\windows\system\rpcrt4.dll 0x60950000 - 0x6095B000 c:\windows\system\iphlpapi.dll 0x60960000 - 0x60974000 c:\windows\system\wsock32.dll 0x609A0000 - 0x609B7000 c:\windows\system\ws2_32.dll 0x609D0000 - 0x60A29000 c:\windows\system\opengl32.dll 0x60C00000 - 0x60C14000 c:\windows\system\imm32.dll 0x60D70000 - 0x60DDE000 c:\windows\system\winmm.dll 0x60DF0000 - 0x60E02000 c:\windows\system\msacm32.drv 0x60E10000 - 0x60E63000 c:\windows\system\msvcrt.dll 0x60E70000 - 0x60EA4000 c:\windows\system\wininet.dll 0x60EB0000 - 0x60EC3000 c:\windows\system\mpr.dll 0x60FD0000 - 0x61043000 c:\windows\system\winex11.drv 0x6A250000 - 0x6A27A000 c:\windows\system\wineoss.drv 0x6AEC0000 - 0x6AEE4000 c:\windows\system\uxtheme.dll 0x6AFB0000 - 0x6AFBD000 c:\windows\system\midimap.dll 0x6B1F0000 - 0x6B221000 c:\windows\system\dbghelp.dll 0x6B230000 - 0x6B236000 c:\windows\system\psapi.dll ---------------------------------------- Memory Dump ---------------------------------------- Code: 16 bytes starting at (EIP = 00000000) 00000000: Stack: 1024 bytes starting at (ESP = 0034FA9C) * = addr ** * 0034FA90: 60 86 09 7C DC FB 34 00 F8 FA 34 00 54 5F 00 61 `..|..4...4.T_.a 0034FAA0: 70 39 09 7C 00 00 18 00 0B 80 00 00 E4 FA 34 00 p9.|..........4. 0034FAB0: B4 05 1C 60 00 28 27 60 E4 FA 34 00 E0 FA 34 00 ...`.('`..4...4. 0034FAC0: 34 CC 03 61 CE 23 03 61 27 00 00 00 01 00 00 00 4..a.#.a'....... 0034FAD0: 00 00 00 00 40 FB 34 00 01 00 00 00 70 39 09 7C ....(a).4.....p9.| <mailto:....(a).4.....p9.%7C> 0034FAE0: 00 00 00 00 00 00 00 00 43 00 00 00 74 A3 03 61 ........C...t..a 0034FAF0: D4 28 04 61 DC FB 34 00 58 FB 34 00 C0 9D 00 61 .(.a..4.X.4....a 0034FB00: 44 FB 34 00 00 00 00 00 48 FB 34 00 4D 4F 00 00 D.4.....H.4.MO.. 0034FB10: 00 B8 72 60 54 FB 34 00 00 B8 72 60 44 FB 34 00 ..r`T.4...r`D.4. 0034FB20: 00 00 00 00 2C 03 00 00 58 FB 34 00 F0 0B 34 7C ....,...X.4...4| 0034FB30: 2C 03 00 00 FF FF 00 00 58 FB 34 00 C9 29 70 60 ,.......X.4..)p` 0034FB40: 00 00 00 00 B8 8F 1A 00 01 00 00 00 28 3C 72 60 ............(

1 0

WM_*UISTATE message implementation in wine
by Vijay Kiran Kamuju Sept. 14, 2006

Sept. 14, 2006

Hi, Has wine an implementation for WM_*UISTATE messages? Can anybody tell me where should it be implemented and how it should be implemented. Does it involve complex coding? Thanks, VJ

1 1

Re: LOSTWAGES: Update the bus information for WineConf
by Eric Pouech Sept. 14, 2006

Sept. 14, 2006

Hi Rob, any news about how to get the keys for the room at Reading U ? haven't seen nothing about it ? TIA 2006/9/14, Robert Shearman <rob(a)codeweavers.com>: > > ChangeLog: > Update the bus information for WineConf. > > -- > Rob Shearman > > > > Index: templates/en/wineconf/travel.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/wineconf/travel.template,v > retrieving revision 1.18 > diff -u -p -r1.18 travel.template > --- templates/en/wineconf/travel.template 2 Aug 2006 19:03:42 > -0000 1.18 > +++ templates/en/wineconf/travel.template 14 Sep 2006 13:43:45 -0000 > @@ -48,10 +48,11 @@ depending on your quality and travelling > <li><a href="http://www.nationalexpress.com/">National > Express</a></li> > <li><a href="http://www.reading-buses.co.uk/">Reading Buses</a>: > <ul> > - <li>You will want to take the number 12 bus to get to the > + <li>You will want to take the number 18 or 19 bus to get to > the > university from Reading station. Click here for the > - <a href=" > http://www.reading-buses.co.uk/tt_reading_july2005/012MF20.HTML > ">timetable</a>. > - You can ask the bus driver to let you know where to get > off.</li> > + <a href=" > http://www.reading-buses.co.uk/tt_reading_march2006/018MF31.HTML > ">timetable</a>. > + You should get off at the St Joseph's Convent bus stop, as > this > + is the nearest to Windsor Hall.</li> > </ul> > </ul> > <li>Taxi — around £5 - £10 from Reading Station to > the > > > > > > -- Eric Pouech

1 0

Re: *RESEND* wininet: Make CheckInternetConnection behave like Windows does
by Hans Leidekker Sept. 14, 2006

Sept. 14, 2006

On Thursday 14 September 2006 14:07, Daniel Skorka wrote: > The function CheckInternetConnection in dlls/wininet/internet.c is too > naive ATM; it just sends a ping to the specified host. Like Mike McCormack suggested in the bug report, UNIX connect() does not deal with a proxy. It would be nice if you could confirm that CheckInternetConnection on Windows ignores a configured proxy, especially since you seem to have access to such a configuration. -Hans

2 1

Re: usp10: Match output of WinXP for ScriptGetProperties.
by Jeff Latimer Sept. 14, 2006

Sept. 14, 2006

Hans Leidekker wrote: > -Hans > >Changelog > Match output of WinXP for ScriptGetProperties. > Add a test for ScriptGetProperties. > > >------------------------------------------------------------------------ > >+static const SCRIPT_PROPERTIES script_0 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; >+static const SCRIPT_PROPERTIES script_1 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; >+static const SCRIPT_PROPERTIES script_2 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; > > >------------------------------------------------------------------------ > > > > Hans, what is the status of this patch? Looks pretty comprehensive but is unapplied. Are you going pursue it? Jeff

2 1

Re: configure.ac: Do not pass "-fPIC" to mingw for "make crosstest"
by Detlef Riekenberg Sept. 14, 2006

Sept. 14, 2006

On Mi, 2006-09-13 at 15:23 +0200, Detlef Riekenberg wrote: > When we do a "make crosstest" with mingw32msvc-gcc, > the compiler give a warning about "-fPIC" > > > Changelog: > - configure.ac: Do not pass "-fPIC" to mingw for "make crosstest" > > > Changes for configure are not included. > I crosscompiled the tests, dlls and programs and it still works. > Please ignoge this patch. There are more gcc-only flags, that we use without checking -- By by ... Detlef

1 0

MSI : GetInstallDriver, Can not find InstallDriver in ROT table, Return Code = 0x800401e3
by wino＠piments.com Sept. 14, 2006

Sept. 14, 2006

Hi, I have a refractory (faulty ?) MSI to deal with . I ran an msi based installer for autosketch today and it all went very well. Thanks for the current progress on MSI. Greatly cheered by this news I returned to one that I have never got to work since trying with 0.9.8 . I always thought it was wine that was not up to speed but it seems there some less than sorted versions of installsheild which give problems on some machines. In fact it may well be ALL Installsheild from v6 to v9. Only the lastest is fixed. I get the following the log file from msi: The InstallScript engine version currently installed on this machine is adequate. Event 'E2716761' is created GetInstallDriver, Can not find InstallDriver in ROT table, Return Code = 0x800401e3 {DDDD0C4B-57F7-4A85-ACF0-DB3FC8F1DBB4} Extract supporting files Failed to extract _IsUser.dll, Ignore it. Failed to extract IGdi.dll, Ignore it. ISMsiServerStartup Failure, Failed to RegisterMsiServer, Error = 0x8000ffff MsiServerStartup failed. Abort installation. Shutting down the PRC server... RPC runtime reported exception 0x6ba Googling parts of that soon shows a known issue , even on windows: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=993353… http://support.installshield.com/kb/view.asp?articleid=Q107249 http://support.installshield.com/kb/view.asp?articleid=Q107182 and specifically : http://www.voicerecognition.com/forums/ubb/Forum1/HTML/002282-2.html symtomatically , when it gets to the stage of copying the files to $TEMP , it seems to create a few zero length files only before failing. So the bug is in InstallSheild but it does not affect all machines. This version _usually_ installs correctly , what remains to be found out is why Wine falls into the broken category and how to work around it. Since I see this is was one area marked in 0.9.21 changelog I thought this may be a good time to bring it to your attention. best regards.

1 0

Re: cabinet: Add breaks to switch statements
by Dan Kegel Sept. 13, 2006

Sept. 13, 2006

On 9/13/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > On Wednesday 13 September 2006 04:22, you wrote: > > Does adding the breaks fix conformance tests? > > No, I haven't fixed anything with this patch: it was a neutral one, in that > respect. I just put it in because I perceived that those switch statements > were not relying on any fallthrough, so I thought it good practice to isolate > the cases. Let's see: your change was --- a/dlls/cabinet/fci.c 2006-09-12 11:55:48.000000000 +0100 +++ b/dlls/cabinet/fci.c 2006-09-12 23:29:02.000000000 +0100 @@ -454,11 +454,12 @@ switch (cb % 4) { case 3: ul |= (((ULONG)(*pb++)) << 16); + break; case 2: ul |= (((ULONG)(*pb++)) << 8); + break; case 1: ul |= *pb++; - default: break; } Offhand that looks like a more serious change than you thought. You'd better either really understand the code, or add a conformance test that shows this fixes a bug, IMHO. - Dan

3 2

Low-level coding
by Aaron Slunt Sept. 13, 2006

Sept. 13, 2006

Hi, I was interested in starting to play with wine and maybe even build a few functions for it...but then I realized that it's low-level coding, something I'm not familiar with (higher level is more of my expertise). Correct me if I'm wrong, I could be looking at the wrong files :S. Does anyone have any good places to go to to learn about low-level coding, and afterwards coding for wine specifically? Thanks. -- Tired of being hammered by spyware, or want to browse the internet in a whole new way? Download Firefox and enjoy a much better internet experience. http://getfirefox.com/

7 8

Re: cabinet: Add breaks to switch statements
by H. Verbeet Sept. 13, 2006

Sept. 13, 2006

On 13/09/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Add breaks to switch statements. > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 11:55:48.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-12 23:29:02.000000000 +0100 > @@ -454,11 +454,12 @@ > switch (cb % 4) { > case 3: > ul |= (((ULONG)(*pb++)) << 16); > + break; > case 2: > ul |= (((ULONG)(*pb++)) << 8); > + break; > case 1: > ul |= *pb++; > - default: > break; > } > csum ^= ul; > diff -urN a/dlls/cabinet/fdi.c b/dlls/cabinet/fdi.c > --- a/dlls/cabinet/fdi.c 2006-05-23 13:47:35.000000000 +0100 > +++ b/dlls/cabinet/fdi.c 2006-09-12 23:29:13.000000000 +0100 > @@ -302,9 +302,15 @@ > } > > switch (bytes & 3) { > - case 3: ul |= *data++ << 16; > - case 2: ul |= *data++ << 8; > - case 1: ul |= *data; > + case 3: > + ul |= *data++ << 16; > + break; > + case 2: > + ul |= *data++ << 8; > + break; > + case 1: > + ul |= *data; > + break; > } > csum ^= ul; > I think that's supposed to fall through.

1 0

RTL language support in usp.dll
by Vijay Kiran Kamuju Sept. 13, 2006

Sept. 13, 2006

Hi, Your patch for RTL support in usp10.dll. http://www.winehq.org/pipermail/wine-patches/2006-September/030571.html Only includes support for Arabic. If you could include for other RTL languages esp Hebrew (other RTL languages are Farsi and Urdu). I think that would be an easy task for you as you know the usp internals. ;) bye, VJ

2 1

Find out which handle corresponds to which window
by David Gümbel Sept. 13, 2006

Sept. 13, 2006

Hi, - I'm almost sure that question has been asked here before, but I can't seem to find the corresponding post: I am trying to debug an application (Net Support Manager) that has trouble displaying a window in fullscreen mode. NSM enables you (among other things) to remotely look onto somebody else's Desktop, a bit like VNC or NX. It's quite annoying not to be able to look onto that remote desktop in fullscreen mode. Anyway, my guess is that it tries to put itself on top of everything in a wierd way that does not work properly under wine. In order to verify or falsify my guess, it would be extremely helpful to find out which handle corresponds to the window showing the symtoms. I've tried my luck with Process Explorer, but that tool doesn't show me the information I need. Any help is greatly appreciated. Cheers, David

2 4

Re: resend: tools[1/2]: wineprefixcreate: create a freedesktop-enabled menu directory
by Alexandre Julliard Sept. 13, 2006

Sept. 13, 2006

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > When creating the wineprefix, create a directory for the menu and a > configuration file that enables this menu in the freedesktop.org menu > structure. As suggested on wine-devel the menu directory is a > subdirectory of ~/.wine, so if the user deletes it, all menu items > created there will be automatically removed. > > Is there something wrong with this patch? That sort of desktop-specific code does not belong in wineprefixcreate. I'm not really convinced that this approach to menus is correct, but even if it is, it should be handled by wineshelllink and friends. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: riched20: move some selection code from message handler to ME_SetSelection
by Alexandre Julliard Sept. 13, 2006

Sept. 13, 2006

"Matt Finnicum" <mattfinn(a)gmail.com> writes: > The special cases handled by EM_EXSETSEL should also be handled by > EM_SETSEL, so this patch moves that code into the common > ME_SetSelection function. Before this patch, sending EM_SETSEL with > any value less than -1 would crash richedit. > > Changelog: move some selection code from message handlers to ME_SetSelection This fails make test: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so editor.c && touch editor.ok editor.c:1335: Test failed: EM_EXSETSEL: expected: 18 actual: 17 make: *** [editor.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Christoph Frick Sept. 13, 2006

Sept. 13, 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. --- dlls/winex11.drv/settings.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c index 5de07eb..c9bced2 100644 --- a/dlls/winex11.drv/settings.c +++ b/dlls/winex11.drv/settings.c @@ -39,7 +39,8 @@ static LPDDHALMODEINFO dd_modes = NULL; static unsigned int dd_mode_count = 0; static unsigned int dd_max_modes = 0; static int dd_mode_default = 0; -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]); /* pointers to functions that actually do the hard stuff */ static int (*pGetCurrentMode)(void); @@ -62,7 +63,7 @@ LPDDHALMODEINFO X11DRV_Settings_SetHandl TRACE("Resolution settings now handled by: %s\n", name); if (reserve_depths) /* leave room for other depths */ - dd_max_modes = (3+1)*(nmodes); + dd_max_modes = nr_depths*nmodes; else dd_max_modes = nmodes; @@ -111,7 +112,7 @@ void X11DRV_Settings_AddDepthModes(void) int existing_modes = dd_mode_count; DWORD dwBpp = screen_depth; if (dwBpp == 24) dwBpp = 32; - for (j=0; j<3; j++) + for (j=0; j<nr_depths; j++) { if (depths[j] != dwBpp) { @@ -164,8 +165,6 @@ void X11DRV_Settings_Init(void) */ BOOL X11DRV_EnumDisplaySettingsEx( LPCWSTR name, DWORD n, LPDEVMODEW devmode, DWORD flags) { - DWORD dwBpp = screen_depth; - if (dwBpp == 24) dwBpp = 32; devmode->dmDisplayFlags = 0; devmode->dmDisplayFrequency = 0; devmode->dmSize = sizeof(DEVMODEW); -- 1.4.2

1 0

question about storage32.c code and while loop
by EA Durbin Sept. 13, 2006

Sept. 13, 2006

I've mentioned this before but I'm no expert C programmer. Can someone explain why we do the following in storage32.c? if (cbRead > 0) { cbTotalRead += cbRead; resWrite = BlockChainStream_WriteAt(bbTempChain, offset, cbRead, buffer, &cbWritten); if (FAILED(resWrite)) break; cbTotalWritten += cbWritten; offset.u.LowPart += This->smallBlockSize; } } while (cbRead > 0); HeapFree(GetProcessHeap(),0,buffer); if (FAILED(resRead) || FAILED(resWrite)) { ERR("conversion failed: resRead = 0x%08lx, resWrite = 0x%08lx\n", resRead, resWrite); BlockChainStream_Destroy(bbTempChain); return NULL; } in the while loop above while (cbRead > 0); it appears it terminates without doing anything due to the semicolon, is this intentional or is this semicolon not supposed to be there and its supposed to execute the line below it? If it is intentional why is the empty while loop here?

1 1

wine complation fails with latest git
by EA Durbin Sept. 13, 2006

Sept. 13, 2006

I'm not able to compile wine with the latest source from git. gcc-3.4 -c -I. -I. -I../../include -I../../include -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o parser.yy.o parser.yy.c parser.l: In function `parser_lex': parser.l:129: error: `parser_lval' undeclared (first use in this function) parser.l:129: error: (Each undeclared identifier is reported only once parser.l:129: error: for each function it appears in.) parser.l: In function `kw_token': parser.l:342: error: `parser_lval' undeclared (first use in this function) make[2]: *** [parser.yy.o] Error 1 make[2]: Leaving directory `/home/eric/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/home/eric/wine/tools' make: *** [tools] Error 2

2 2

Help with git
by Kapila De Silva Sept. 13, 2006

Sept. 13, 2006

Hi all, Hope this is the right place to post this, if not, my apologies. Im trying to track down an issue that occurred between 0.9.19 and 0.9.20, and am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well. I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please? Thanks in advance Kapila

3 2

State management in D3D
by Ivan Gyurdiev Sept. 12, 2006

Sept. 12, 2006

State management in D3D... is currently kind of a mess. Stefan D. posted a message about this some time ago, but I can't find it right now... - some states are applied immediately (via Set* calls) - some are applied at draw time (like shaders, textures, transforms, ...) - some are recorded into a stateblock structure, and applied when the app says apply(). - the GL code is all over the place, tightly coupled to the d3d code. =============================== There's a number of projects going on at the moment, from what I understand: - Roderick is working on making wined3d -> wgl - Stefan D. has expressed concern about multithreaded d3d (where the D3D device state is shared, but not necessarily the GL one - or can GL contexts be shared between multiple threads?) - I'm trying to get FBOs to work, where the FBO needs to be bound once both the render and stencil target have been assigned (that's 2 calls from the app in any order) - i.e I need those states to be applied in a delayed fashion, before draw - Henri Verbeet wants multiple render target support added to that (meaning the FBO needs to be bound once *all* render targets are assigned in addition to the depth/stencil one). ================================ All of the above have a common theme - better state management is needed, with more encapsulation, and better separation between D3D and GL. So, let's come up with a plan, and try to implement it. How about we redesign the stateblock object like this: - remove deltas. I.E. if a SetLightEnable() command is sent, fetch the light, enable it, then save the light back - store only state, and no deltas. This should make the recording stateblock (updateStateBlock) the same as the initial device stateblock, which stores states - provide a uniform internal interface for accessing states inside the stateblock - like: SetState(stateblock, ID_XYZ, (void*) state_data); GetState(stateblock, ID_XYZ, (void**) state_data); CaptureState(stateblock, ID_XYZ); ApplyState(stateblock, ID_XYZ); ID_XYZ could be an individual state, or a "trigger" keyword, which will refer to a whole group of states. Those would be private functions in addition to the standard interface. - provide a fn pointer table inside the stateblock [ which can be directed to OGL or WGL or AGL ], which, for each ID_XYZ, maps a get and set function using the same interface - move all device.c GL code into those functions - now all device.c Get* and Set* requests will do is: - error checking - recording into updateStateBlock - or writing to stateBlock (which may be applied later, at our discretion). - apply() would just loop through all the IDs and call the corresponding function pointer if the states are marked dirty (we'll keep the 'dirty' field) - capture() would do the same in the get* direction. - new object can be instantiated per device, or per device per thread to address multithreading. It could have an associated glContext, and can be locked as necessary. - it would use ideas from the d3d9 test framework for stateblock, except of course more competently written, and cleaner :)

3 12

Help with shader code
by Kapila De Silva Sept. 12, 2006

Sept. 12, 2006

Hi All, can someone help me understand some code from dlls/wined3d/vertexshader.c please? Im new to shader code, but to me the following looks a bit strange: shader_addline(&buffer, "ADD result.position.x, TMP_OUT.x, PROJECTIONX.w;\n"); shader_addline(&buffer, "ADD result.position.y, TMP_OUT.y, PROJECTIONY.w;\n"); /* Account for any inverted textures (render to texture case) by reversing the y coordinate * (this is handled in drawPrim() when it sets the MODELVIEW and PROJECTION matrices) */ shader_addline(&buffer, "MUL result.position.y, TMP_OUT.y, PROJECTIONY.y;\n"); Am I correct that the last line makes the second line redundant? Wont result.position.y be equal to TMP_OUT.y * PROJECTIONY.y no matter what? Thanks in advance. Kapila.

2 2

Re: comctl32: Remove dead code in tooltips.c (coverity)
by Alexandre Julliard Sept. 12, 2006

Sept. 12, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > We return with FALSE at the top of the Function, > when lpToolInfo is NULL. I think that's where the real bug is, we shouldn't always return FALSE in that case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: X11Drv: move WGL extension code
by Lionel Ulmer Sept. 12, 2006

Sept. 12, 2006

On Fri, Sep 01, 2006 at 01:57:24PM +0200, Roderick Colenbrander wrote: > The way WGL extensions are loaded is different. The old code correctly > advertised the names of available WGL extensions but the wglGetProcAddress > code didn't work correctly. Even if an extension wasn't advertised you could > get a function pointer to the functions. On Windows wglGetProcAddress would > return NULL. Note that (as far as I know), 'wglGetProcAddress' returns NULL on non-existant extensions for all extensions, whether they are GL or WGL ones. This means that our implementation of it is broken (at least on DRI / Mesa) as 'glXGetProcAddress' may return a non-NULL value when querying a non-supported extension. So if we really want to be windows-like, we would need to add a 'function name / extension name' database and check if the extension corresponding to the function is present before actually calling 'glXGetProcAddress'. But as I ever only once got a bug report linked to that, I never took the pain to fix it :-) Lionel (catching up his old mails) PS: I guess that this 'database' may be automatically build by the 'make_opengl' script though so it should not be that hard to do :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Storage32 error
by EA Durbin Sept. 12, 2006

Sept. 12, 2006

I've been experiencing an error in several installers and it just appeared lately in installers that used to succeed, such as the battlefield 2 demo installer, this error is causing them to fail. Was this caused by a recent patch? err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000

1 0

Re: include: Add new Vista SDK constants, fields and, structures documented at http://ian.joeuser.com/index.asp?AID=738
by Timo Kunze Sept. 11, 2006

Sept. 11, 2006

Alexandre Julliard <julliard(a)winehq.org> writes: > Francois Gouget <fgouget(a)free.fr> writes: >> > @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA { >> > LPSTR lpszText; >> > LPARAM lParam; >> > void *lpReserved; >> > + HBITMAP hbmp; >> > } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA, *LPTTTOOLINFOA; > > I don't think our code is going to handle this properly. Before > extending the structures we need to fix places that depend on the size > of the old type. This website is absolutely outdated. Take a look at the current (build 5536) Windows SDK headers and you'll see, that e. g. the hbmp member of the TTTOOLINFO struct has been removed again. Regards Timo

1 0

Wineconf this weekend!
by Jeremy White Sept. 11, 2006

Sept. 11, 2006

Hi Folks, So this weekend is Wineconf, which is the mostly annual gathering of Wine developers and afficianodos. Everyone is welcome, although we do intend to run a very technical and developer focused agenda. It will be held in Reading, a bit west of London, in the UK. The formal program starts on Saturday. We have a tentative agenda posted on the Wiki here: http://wiki.winehq.org/WineConf2006 The one don't miss talk will be Alexandre's keynote, which will be at 9:00 am on Saturday. We're still working out the schedule for the other events. There is no charge, although you do have to take care of your own loding and travel. If you are planning to come, though, it would be handy if you could hit the RSVP page (if you haven't already): http://www.winehq.org/site/wineconf/rsvp That way we can make sure our catering counts aren't out of wack. If you are coming, particularly if you reserved a room on campus with me, you *must* sign up for this mailing list: http://www.winehq.org/mailman/listinfo/wineconf or you will miss out on important details, and you'll end up wandering around Reading desperately looking for your key. (And yes, that does mean I'll stop spamming this list, and start spamming that one :-/). Cheers, Jeremy

1 0

Re: dinput: [2/2] Create/destroy hook thread from DirectInput [try 3].
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > +static void release_hook_thread(void) > +{ > + LONG ref; > + > + EnterCriticalSection(&dinput_hook_crit); > + ref = --hook_thread_refcount; > + TRACE("Releasing to %ld\n", ref); > + if (ref == 0) SendMessageW(hook_thread_hwnd, WM_DESTROY, 0, 0); WM_DESTROY is supposed to be sent by DestroyWindow, sending it manually is not very nice, you should use a WM_USER message instead. Also you need to clear hook_thread_hwnd first, otherwise there's a race since you don't wait for the thread to finish. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Bug #4510: allowing -ansi for arpa/nameser.h in configure.ac
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Joel Parker <jjk3(a)msstate.edu> writes: > This patch fixes bug #4510. It allows the use of -ansi when > running ./configure. I'm not sure I see the point, you'd need to fix all the places that use the file too, otherwise it won't compile, and it's not clear that defining BSD_SOURCE all over the place is a good idea. I'd suggest to fix the header instead. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WINEDOCS: Update regression testing procedure to use Git
by Saulius Krasuckas Sept. 11, 2006

Sept. 11, 2006

* On Mon, 28 Aug 2006, Mike McCormack wrote: > Update regression testing procedure to use Git Any chances this patch gets into the webserver? :) http://marc.theaimsgroup.com/?l=wine-patches&m=115673906004873&w=2

2 1

Re: X11Drv: move WGL extension code
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > The patch adds new WGL extension loading code based on code written > by an old opengl32 -> x11drv patch written by Tomas Carnacky. The > code properly advertises WGL extensions and only returns function > pointers when the extension is really available. It would be nicer to declare the extensions as constant variables instead of building everything at run time. Something like: static const struct wglextension swap_control = { "WGL_EXT_swap_control", { { "wglSwapIntervalEXT", X11DRV_wglSwapIntervalEXT }, { "wglGetSwapIntervalEXT", X11DRV_wglGetSwapIntervalEXT }, } }; static void load_extensions(void) { if (glxRequireExtension("GLX_SGI_swap_control")) register_extension( &swap_control ); ... etc. } Then the extension list can simply store a pointer instead of copying the whole thing once more, and you avoid a lot of nasty macros. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Add new Vista SDK constants, fields and structures documented at http://ian.joeuser.com/index.asp?AID=738
by Alexandre Julliard Sept. 11, 2006

Sept. 11, 2006

Francois Gouget <fgouget(a)free.fr> writes: > @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA { > LPSTR lpszText; > LPARAM lParam; > void *lpReserved; > + HBITMAP hbmp; > } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA, *LPTTTOOLINFOA; I don't think our code is going to handle this properly. Before extending the structures we need to fix places that depend on the size of the old type. -- Alexandre Julliard julliard(a)winehq.org

1 0

Making people aware about appdb and outdated Wine versions.
by killertux killertux Sept. 10, 2006

Sept. 10, 2006

Hello, I have problem... It's know as dublication of effort. Basicly there are sites that "compeate" with appdb it means HOWTOS, test result and everyting else are distributed in few thousands forums, wikis etc... Solution is that Wine should advertice Wine AppDB so people would actully use it rather than unoffical sites. So I would like to see some AppDB "adverticement" in winecfg. Winecfg about section is one good place to inform wonders of appdb but even better would be popup window when starting winecfg(at lest in first run) that informs about appdb. Normal users obtain copy of Wine trought their package manager and that means they do not know about appdb unless they they read it somewhere. This change must be done in order to kill useless stuff like this: http://forums.gentoo.org/viewtopic-t-496836.html Second: Old version of Wine are still quite used because of package managers just offers "stable" Wine versions over the "unstable" ones so I would like to see another popup or warning in winecfg that informs user that their Wine is getting old... so after specific number of days(from release of Wine version X) counter gives some warnings about old Wine version.

3 2

Re: Jonathan Ernst : winecfg: French translation update.
by Frank Richter Sept. 10, 2006

Sept. 10, 2006

On 10.09.2006 10:28, Alexandre Julliard wrote: > - LTEXT "This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.", > + LTEXT "Cette biblioth�que est un logiciel libre�; vous pouvez la redistribuer et/ou la modifier conform�ment aux dispositions de la Licence Publique G�n�rale GNU, telle que publi�e par la Free Software Foundation�; version 2.1 de la licence, ou encore (� votre choix) toute version ult�rieure." > IDC_STATIC,119,44,124,72 It seems that all (L)GPL translations are marked "unofficial" by the FSF. That's why I though it wouldn't be bad to put in a translated "This library is ..." but keep the original English notice as well for the German translation. -f.r.

2 1

Re: Re: Making people aware about appdb and outdated Wine versions.
by killertux killertux Sept. 10, 2006

Sept. 10, 2006

OK, if not popup then fixme or someting like if there is problems they can go to Wine AppDB to get some compatibility help. >> --SNIP-- >> Second: Old version of Wine are still quite used because of package >> managers just offers "stable" Wine versions over the "unstable" ones so I would like >> to see another popup or warning in winecfg that informs user that their Wine is >> getting old... so after specific number of days(from release of Wine version X) >> counter gives some warnings about old Wine version. > >Having a popup (or anything that requires user interaction) could get >really irritating - there are situations where people would use an >older version of wine on purpose. Like if a large organization uses it >to run one specific app, and has a specific version that works >perfectly, they might not have any reason to update. > >How about a fixme when wine is run, informing them that the version >they are running was released X long ago, and that if they have any >issues they should try a newer version? > >It'd be nice, too, if people then reported bugs with that on the top >of the output - it could save a lot of work chasing down already- fixed >issues. > >--Matt >

3 2