March 2011 - Wine-Devel - list.winehq.org

Re: Wine Gecko 1.2.0 RC1

by Jacek Caban

On 3/10/11 9:59 PM, Michael Stefaniuc wrote: > On 03/10/2011 08:58 PM, Jacek Caban wrote: >> On 3/10/11 8:33 PM, Scott Ritchie wrote: >>> Will the new Gecko be coinstallable with earlier geckos, eg for >>> wine1.2? >>> It would be very useful to me if this were the case (and Wine were >>> smart enough to use the correct one depending on its version). >> >> No, we need to use exactly the same version of Gecko that Wine is >> compiled for. Making Gecko releases backward compatible is impossible. >> The API is not frozen and the behavior we depend on changes quite often. > I think what he meant is if we have more than one Gecko's installed. > Though i'm not sure if he means two dpkg/rpm installed at the same > time or Gecko installed in the WINEPREFIX at the same time. Ah, right, sorry for misunderstanding. Both scenarios should work just fine. There are no file collisions for linux packages, so there is no reason not to have a few versions installed. Wine installs them into different directories in wineprefix and loads the one that it needs. Jacek

March 10, 2011

Re: Wine Gecko 1.2.0 RC1

by Michael Stefaniuc

On 03/10/2011 08:58 PM, Jacek Caban wrote: > On 3/10/11 8:33 PM, Scott Ritchie wrote: >> Will the new Gecko be coinstallable with earlier geckos, eg for wine1.2? >> It would be very useful to me if this were the case (and Wine were >> smart enough to use the correct one depending on its version). > > No, we need to use exactly the same version of Gecko that Wine is > compiled for. Making Gecko releases backward compatible is impossible. > The API is not frozen and the behavior we depend on changes quite often. I think what he meant is if we have more than one Gecko's installed. Though i'm not sure if he means two dpkg/rpm installed at the same time or Gecko installed in the WINEPREFIX at the same time. bye michael

March 10, 2011

Failing kernel32:change and ntdll:change tests on Mac OS

by Charles Davis

Hi, I just got done looking over the latest batch of test results I sent, and one thing really sticks out and bothers me. The Change Notification tests all fail miserably on my machine (a 2009 Mac Pro with Mac OS X 10.6), because that feature hasn't been implemented on Mac yet. I could implement it for 10.5 up, but the problem is that the "public" API for Change Notifications on Mac (the "FSEvents" API, in CoreServices.framework) expects clients to either use a CFRunLoop or (on 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. I did some digging, and it turns out that FSEvents just uses a Mach port (whose name is published in root's Mach bootstrap context as "com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn opens a device file, /dev/fsevents, which is the actual gateway to the kernel. Though it's largely undocumented, we could use this device file to implement Change Notification. The FDs that get returned by this file even support kqueues. But, there are two tiny problems with that: 1) You have to be root to open /dev/fsevents. If we do it this way, we will have to wait until the server is converted to run as root. 2) Because this API isn't officially documented, it's unstable and subject to change. (In fact, judging from the kernel source, it's already changed once. There are several 'old' and 'new' variants of the FSEvents ioctls that the kernel handler supports.) I guess the real question is, which way should we do this? If we do it the first way (using the public and documented but kqueue-unfriendly Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer concerned about Leopard, a GCD dispatch queue) in its main loop, and if we do it the second way (using the undocumented and unstable but kqueue-friendly Unix API), wineserver needs to run as root, and may need to cope with API changes. Based on what I've heard, I'm leaning toward the second way, but I want your guys' input before I go ahead. Thanks. Chip

March 10, 2011

Re: Wine Gecko 1.2.0 RC1

by Jacek Caban

On 3/10/11 8:33 PM, Scott Ritchie wrote: > Will the new Gecko be coinstallable with earlier geckos, eg for wine1.2? > It would be very useful to me if this were the case (and Wine were > smart enough to use the correct one depending on its version). No, we need to use exactly the same version of Gecko that Wine is compiled for. Making Gecko releases backward compatible is impossible. The API is not frozen and the behavior we depend on changes quite often. Jacek

March 10, 2011

Re: wininet(6/10): Implement commiting a url cache entry that already existed

by Juan Lang

> The tests just hang for me: I'm unable to reproduce on either of two machines. Could you send me your Content.IE5/index.dat file, in case that helps me reproduce it? Thanks, --Juan

March 10, 2011

Re: Wine Gecko 1.2.0 RC1

by Scott Ritchie

On 03/10/2011 10:33 AM, Jacek Caban wrote: > * FOR PACKAGERS * > > If you are interested in building the packager yourself from sources (so > far I've heard about Debian and Fedora attempts to do so), everything is > ready to support it now. Building instructions changed a bit after > switching to use MSI files, but I've made things as easy as possible. > Building the package itself is a matter of invoking one script with > proper arguments. The tricky part is that Wine is needed for building, > so we get circural build-time dependency. The script, however, makes > sure that Wine doesn't need Gecko during compiling Gecko, so it > shouldn't be a big problem to handle. Also, unless you manually set > WINEPREFIX, the script created a temporary wineprefix directory, so > there is nothing to worry if your ~/.wine is in broken state. It can > also use Wine from its build dir if you set WINE_BUILD_DIR environment > variable. Please let me know if there are more problems than need to be > addressed and feel free to contact me if you have any questions. > > Thanks, > Jacek > > [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-rc1/ > Will the new Gecko be coinstallable with earlier geckos, eg for wine1.2? It would be very useful to me if this were the case (and Wine were smart enough to use the correct one depending on its version). Thanks, Scott Ritchie

March 10, 2011

Links down

by Diego Diaz

sh winetricks mdac25 Executing wget -O mdac_typ.exe -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769… --2011-03-10 16:16:31-- http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769… Resolving download.microsoft.com... 77.67.20.40, 77.67.20.51, 77.67.20.64 Connecting to download.microsoft.com|77.67.20.40|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-03-10 16:16:32 ERROR 404: Not Found. ------------------------------------------------------ Note: command 'wget -O mdac_typ.exe -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769…' returned status 8. Aborting. ------------------------------------------------------ ------------------------------------------------------ mdac25 failed ************************************************************************************************************************************************* sh winetricks mdac28 Executing wget -O MDAC_TYP.EXE -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37… --2011-03-10 16:16:09-- http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37… Resolving download.microsoft.com... 77.67.20.40, 77.67.20.24 Connecting to download.microsoft.com|77.67.20.40|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-03-10 16:16:10 ERROR 404: Not Found. ------------------------------------------------------ Note: command 'wget -O MDAC_TYP.EXE -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37…' returned status 8. Aborting. ------------------------------------------------------ ------------------------------------------------------ mdac28 failed

March 10, 2011

New winetricks 20110310-alpha: new verbs csi6_demo, farmsim2011_demo, mono210

by Dan Kegel

Version 20110310-alpha adds two games csi6_demo - CSI: Fatal Conspiracy Demo farmsim2011_demo - Farming Simulator 2011 Demo plus a new version of mono (2.10). There are a couple gui changes: it adds a help button and a button to unhide broken titles,and adds a scary warning to the dinput and directx9 verb menu items. It also fixes a number of bugs. For bug tracker, mailing lists, and wiki, see http://winetricks.org Download url: http://winetricks.org/winetricks-alpha There's also an announcements mailing list for package maintainers now: http://groups.google.com/group/winetricks-announce Changes since 20110306-alpha: vbrun5, vbrun6: fix install check. vc2005trial: fix regression caused by 7zip installing into its own wineprefix. richtx32: fix install check Print unix file rather than windows file when install check fails, it's much less mysterious. farmsim2011_demo: fix media type Avoid syntax error if which returns empty string list-installed: no longer need kludge. Also sort the inputs rather than the outputs so output shows up faster. firefox4: update to rc1 mono210: new verb w_download: fix penpenxmas and autohotkey right this time w_download: don't set user-agent, it breaks sourceforge download csi6_demo: new verb farmsim2011_demo: new verb. sammax301_demo: fix typo (it's not 304) Add gui option for showing broken apps. Not great, but it'll do for now. Main menu is called 'main', so call prefix menu 'prefix'... masseffect2_demo: use wine-hotfix-6971 if present. Also fix -q support. tahoma: fix install check grr. really fix navigation, I hope. help: new verb, just opens winetricks.org/help in a browser. This is the very first entry on the first menu of the gui. fix breakage in zenity menus remove dead code dxdiag: list under 'dlls' rather than 'apps', since it's usually used in the context of some other app. Make directx9 warning more obvious. OS reporting didn't work well, so put wine version in that slot Fix navigation when returning back from apps Fix KDE support in top menu. Fix time/space columns in German and (kind of) Danish. d3dcompiler_43: new verb by Rico; marked as broken to hide it from casual users until wine can handle more d3d10 dinput: add scary warning

March 10, 2011

Re: [1/2] wininet: Partially implement FreeUrlCacheSpaceW. (try 2)

by Alexandre Julliard

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > The names come from an old copy of the Internet SDK, > <http://web.archive.org/web/*/activex.adsp.or.jp/japanese/specs/inetsdk.htm>, > but it doesn't give the actual values. From the order they appear in > the documentation, and that native apparently uses 0 when calling > FreeUrlCacheSpace, I guessed 0 was FCS_PERCENT_CACHE_SPACE. Should I > just use a literal 0 instead? No, if these used to be in the SDK it's OK to make them public. Though a few test cases wouldn't hurt to confirm the accepted values. -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: d3dxcreatebox patch

by David Adam

2011/3/10 Alexandre Julliard <julliard(a)winehq.org> > Matteo Bruni <matteo.mystral(a)gmail.com> writes: > > > 2011/3/10 David Adam <david.adam.cnrs(a)gmail.com>: > >> Thanks for the feedback. What do you mean by "you are forcing a > particular > >> vertex ordering3"? > > > > I mean that you are testing the vertices of the mesh returned by > > D3DXCreateBox in the order generated by native d3dx9, while they could > > in general be in any order while still making up a box. That's not a > > problem in my opinion because our implementation (when it will be > > written :)) could generate the vertices with the same ordering without > > any issue. > > There's no reason for the tests to require that. Also, hardcoding the > full list of vertices is ugly (and in the case of the teapot, clearly > absurd). > > -- > Alexandre Julliard > julliard(a)winehq.org > Must I pick up only a few vertices and test them? Or I do not test the vertices returned by D3DXCreateBox A+ David

March 10, 2011

Wine Gecko 1.2.0 RC1

by Jacek Caban

Hi all, I'm happy to announce that the new update of Wine Gecko packages is almost there. It took long time since last beta to get to RC point from beta, not only because of many changes on our side, but mostly because of delays in Mozilla release process. We've done everything I've hoped to be done (and even more than I expected). I'm also happy that it was much better tested than previous times (mostly because they were available for so long). So far I'm aware of only one regression in Outlook that probably won't block the release because it seems to be a problem on Wine side (I can't be sure as I wasn't able to reproduce it so far). If I've missed something, please let me know. I'd appreciate help with testing. Builds are on Sourceforge [1]. To use it, just grab MSI files and put it into the directory where usually CAB files would go and apply the attached patch. Please let me know about any regression you notice. * CHANGES * - The CAB file is created without external dependencies Thanks to Alexandre for cabinet work. - We use MSI installers Thanks to Hans for winemsibuilder and preparing scripts that made it possible. - winedbg works with Gecko debug builds Thanks to Eric for many fixes to dbghelp/winedbg. Once he will merge his work to Wine, we will be able to use winedbg for comfortable Gecko debugging - win64 build now works - a few bug fixes - I've got rid of some Gecko ugly things like using API hooks * FURTHER PLANS * Firefox 4 RC1 came out yesterday and is expected to be the final build (so far nothing that would require another RC was found). Mozilla estimates release to be out in a week or two. I'm tempted to not wait and release early next week (so that it will live in Git for at least a few days before Wine release), but we will see how it will work. If we'd find any new blocker, it would most likely mean that we will release a week later. * FOR PACKAGERS * If you are interested in building the packager yourself from sources (so far I've heard about Debian and Fedora attempts to do so), everything is ready to support it now. Building instructions changed a bit after switching to use MSI files, but I've made things as easy as possible. Building the package itself is a matter of invoking one script with proper arguments. The tricky part is that Wine is needed for building, so we get circural build-time dependency. The script, however, makes sure that Wine doesn't need Gecko during compiling Gecko, so it shouldn't be a big problem to handle. Also, unless you manually set WINEPREFIX, the script created a temporary wineprefix directory, so there is nothing to worry if your ~/.wine is in broken state. It can also use Wine from its build dir if you set WINE_BUILD_DIR environment variable. Please let me know if there are more problems than need to be addressed and feel free to contact me if you have any questions. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-rc1/

March 10, 2011

Re: [PATCH 6/6] user32: Add support for sequence-based animated cursors.

by Henri Verbeet

On 10 March 2011 07:42, Erich Hoover <ehoover(a)mines.edu> wrote: > @@ -940,6 +954,7 @@ done: > #define ANI_seq__ID RIFF_FOURCC('s', 'e', 'q', ' ') > #define ANI_fram_ID RIFF_FOURCC('f', 'r', 'a', 'm') > #define ANI_rate_ID RIFF_FOURCC('r', 'a', 't', 'e') > +#define ANI_seq_ID RIFF_FOURCC('s', 'e', 'q', ' ') Just happened to notice this, but I doubt there's much point in having two different defines for sequence chunks.

March 10, 2011

Re: [1/2] wininet: Partially implement FreeUrlCacheSpaceW. (try 2)

by Alexander Scott-Johns

On 10 March 2011 14:57, Alexandre Julliard <julliard(a)winehq.org> wrote: > Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > >> @@ -1660,6 +1660,16 @@ BOOLAPI DeleteUrlCacheEntryA(LPCSTR); >> BOOLAPI DeleteUrlCacheEntryW(LPCWSTR); >> #define DeleteUrlCacheEntry WINELIB_NAME_AW(DeleteUrlCacheEntry) >> >> +/* FCS_ flags and FreeUrlCacheSpace are no longer documented */ >> +#define FCS_PERCENT_CACHE_SPACE 0 /* guessed value */ >> +#define FCS_PERCENT_DISK_SPACE 1 /* guessed value */ >> +#define FCS_ABSOLUTE_SIZE 2 /* guessed value */ > > Where do these come from then? If you made them up they shouldn't go in > a public header. The names come from an old copy of the Internet SDK, <http://web.archive.org/web/*/activex.adsp.or.jp/japanese/specs/inetsdk.htm>, but it doesn't give the actual values. From the order they appear in the documentation, and that native apparently uses 0 when calling FreeUrlCacheSpace, I guessed 0 was FCS_PERCENT_CACHE_SPACE. Should I just use a literal 0 instead? Best regards, Alex Scott-Johns

March 10, 2011

Re: winecfg: Protect from closing the root key.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch should fix the crash reported in the bug #26367. A better way would be to use RegOpenKeyExW. -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: d3dxcreatebox patch

by Alexandre Julliard

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > 2011/3/10 David Adam <david.adam.cnrs(a)gmail.com>: >> Thanks for the feedback. What do you mean by "you are forcing a particular >> vertex ordering3"? > > I mean that you are testing the vertices of the mesh returned by > D3DXCreateBox in the order generated by native d3dx9, while they could > in general be in any order while still making up a box. That's not a > problem in my opinion because our implementation (when it will be > written :)) could generate the vertices with the same ordering without > any issue. There's no reason for the tests to require that. Also, hardcoding the full list of vertices is ugly (and in the case of the teapot, clearly absurd). -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: [1/2] wininet: Partially implement FreeUrlCacheSpaceW. (try 2)

by Alexandre Julliard

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > @@ -1660,6 +1660,16 @@ BOOLAPI DeleteUrlCacheEntryA(LPCSTR); > BOOLAPI DeleteUrlCacheEntryW(LPCWSTR); > #define DeleteUrlCacheEntry WINELIB_NAME_AW(DeleteUrlCacheEntry) > > +/* FCS_ flags and FreeUrlCacheSpace are no longer documented */ > +#define FCS_PERCENT_CACHE_SPACE 0 /* guessed value */ > +#define FCS_PERCENT_DISK_SPACE 1 /* guessed value */ > +#define FCS_ABSOLUTE_SIZE 2 /* guessed value */ Where do these come from then? If you made them up they shouldn't go in a public header. -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: [PATCH 5/6] user32: Add support for retrieving individual animated frames.

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > @@ -101,19 +93,40 @@ struct cursoricon_object > UINT width; > UINT height; > POINT hotspot; > + UINT delay; /* delay between this frame and the next (in jiffies) */ > + BOOL is_ani; /* whether this object is a static cursor or an animated cursor */ > UINT num_frames; /* number of frames in the icon/cursor */ > UINT num_steps; /* number of sequence steps in the icon/cursor */ > - UINT delay; /* global delay between frames (in jiffies) */ > - struct cursoricon_frame frames[1]; /* icon frame information */ > }; Some of these fields don't make sense for a static cursor. Also please try to do this change in smaller steps. -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: wininet(6/10): Implement commiting a url cache entry that already existed

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > As a nice side effect, the aggravating fixme about not knowing what to > do disappears. The tests just hang for me: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok fixme:wininet:set_cookie persistent cookies not handled (L"expires=Sat, 09 Apr 2011 14:14:39 GMT; path=/") fixme:wininet:InternetSetOptionW Option 43 STUB fixme:wininet:InternetSetOptionW Option 44 STUB fixme:wininet:CommitUrlCacheEntryInternal Trying to delete entry of unknown format "\x00\x00\x00\x00" -- Alexandre Julliard julliard(a)winehq.org

March 10, 2011

Re: hooking into wine (GL video capturing app)

by Damjan Jovanovic

On Thu, Mar 10, 2011 at 2:09 PM, Christian Parpart <trapni(a)gentoo.org> wrote: > Hey all, > > a few years ago I once developed an application for recording the video of > the 3D games I played via wine (and cedega). > > This all worked quite fine these days and I remember that cedega's wine > engine used other libX11 functions to process events than wine itself did > or still does. > > In my software, I am overriding the specific library functions I want to > hook in, such as glXSwapBuffers, XNextEvent, XCheckIfEvent, ... > and then do LD_PRELOAD_LIBRARY this when starting wine. > Note, only wine used to use XCheckIfEvent but cedega used some other > function to process events, IIRC. > > This all worked fine back in the days I developed it, now I want to > resurrect this project and found myself in troubles. > That is, I can successfully hook into OpenGL library functions, but I just > cannot find a trace on why my XCheckIfEvent is not being used by wine. > > A few days back one guy at IRC told me that I have to look at the wine's > x11drv source code, which I did, but all I can see, is, that wine indeed > still seems to use XCheckIfEvent(). > > Checking my running wine app (with my library preloaded) using lsof I can > see that my library is indeed successfully hooked up into the process > image at least, and so do my hooks to the OpenGL functions work. > As a test, I also hooked up into XOpenDisplay from libX11, it worked, but > still, XCheckIfEvent() does not, and my only clue is, that this piece of > code of wine isn't actually the one processing the events. > > As a side note, I need to hook up into libX11 to capture keyboard input to > actually start/stop video recording / screenshotting on keyboard events. > > Can anyone please help me out here why I cannot grap wine's keyboard events? > > In case of interest, the following is the link to the source code in > question: > > http://redmine.xzero.ws/projects/captury/repository/revisions/master/entry/… > > > Best regards, > Christian Parpart. > > > > Hooking XCheckIfEvent works for me: #include <stdio.h> #include <stdlib.h> void XCheckIfEvent(void) { printf("XCheckIfEvent called\n"); exit(0); } $ gcc -fPIC -c chk.c $ gcc chk.o -shared -o libchk.so $ LD_PRELOAD=./libchk.so wine notepad ERROR: ld.so: object './libxchk.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './libxchk.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './libxchk.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './libxchk.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object './libxchk.so' from LD_PRELOAD cannot be preloaded: ignored. XCheckIfEvent called (exits)

March 10, 2011

Re: USB Osciloscope

by Alexander Morozov

> wine-1.0.1 Try to use 1.3.15 with a patch for it. > phoenox(a)firebird:~/.wine/drive_c/DSO8000$ WINEDEBUG=+winedevice, > +ntoskrnl,+usbhub wine ezusb.sys Do not run the driver manually. Put it in windows/system32/drivers and run your program under WINE, the driver will be loaded if your USB device is connected.

March 10, 2011

hooking into wine (GL video capturing app)

by Christian Parpart

Hey all, a few years ago I once developed an application for recording the video of the 3D games I played via wine (and cedega). This all worked quite fine these days and I remember that cedega's wine engine used other libX11 functions to process events than wine itself did or still does. In my software, I am overriding the specific library functions I want to hook in, such as glXSwapBuffers, XNextEvent, XCheckIfEvent, ... and then do LD_PRELOAD_LIBRARY this when starting wine. Note, only wine used to use XCheckIfEvent but cedega used some other function to process events, IIRC. This all worked fine back in the days I developed it, now I want to resurrect this project and found myself in troubles. That is, I can successfully hook into OpenGL library functions, but I just cannot find a trace on why my XCheckIfEvent is not being used by wine. A few days back one guy at IRC told me that I have to look at the wine's x11drv source code, which I did, but all I can see, is, that wine indeed still seems to use XCheckIfEvent(). Checking my running wine app (with my library preloaded) using lsof I can see that my library is indeed successfully hooked up into the process image at least, and so do my hooks to the OpenGL functions work. As a test, I also hooked up into XOpenDisplay from libX11, it worked, but still, XCheckIfEvent() does not, and my only clue is, that this piece of code of wine isn't actually the one processing the events. As a side note, I need to hook up into libX11 to capture keyboard input to actually start/stop video recording / screenshotting on keyboard events. Can anyone please help me out here why I cannot grap wine's keyboard events? In case of interest, the following is the link to the source code in question: http://redmine.xzero.ws/projects/captury/repository/revisions/master/entry/… Best regards, Christian Parpart.

March 10, 2011

Re: [PATCH 3/3] msi: Add an offset to sequence numbers belonging to files added by a patch.

by Hans Leidekker

On Thu, 2011-03-10 at 02:20 +0100, David Hedberg wrote: > +static UINT msi_set_patch_offsets(MSIPACKAGE *package) > +{ > + static const WCHAR query_media[] = { > + 'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ','M','e','d','i','a',' ', > + 'W','H','E','R','E',' ','S','o','u','r','c','e',' ','I','S',' ','N','O','T',' ','N','U','L','L',0}; You should order the list by DiskId to protect against installers with multiple sources for a given file sequence number. We do this elsewhere, and although I'm not sure it matches native it will at least give consistent behavior. Also, MSDN tells me the Source column is ignored if the Cabinet column is empty. > UINT msi_apply_patch_db( MSIPACKAGE *package, MSIDATABASE *patch_db, MSIPATCHINFO *patch ) > { > UINT i, r = ERROR_SUCCESS; > @@ -640,6 +796,7 @@ UINT msi_apply_patch_db( MSIPACKAGE *package, MSIDATABASE *patch_db, MSIPATCHINF > return r; > > msi_set_media_source_prop( package ); > + msi_set_patch_offsets( package ); There can be more than one transform in the patch that modifies the Media table. It's unlikely, but it may mean that offsets need to be applied after each transform that modifies the Media table instead of after each patch.

March 10, 2011

Re: d3dxcreatebox patch

by Matteo Bruni

2011/3/10 David Adam <david.adam.cnrs(a)gmail.com>: > Thanks for the feedback. What do you mean by "you are forcing a particular > vertex ordering3"? I mean that you are testing the vertices of the mesh returned by D3DXCreateBox in the order generated by native d3dx9, while they could in general be in any order while still making up a box. That's not a problem in my opinion because our implementation (when it will be written :)) could generate the vertices with the same ordering without any issue. > I just test the vertex that D3DXCreateBox sent. I think it is not possible > to choose the ordering of the vertices for D3DXCreateBox. Did I miss > anything? > > A+ > > David > > 2011/3/9 Matteo Bruni <matteo.mystral(a)gmail.com> >> >> 2011/3/9 David Adam <david.adam.cnrs(a)gmail.com>: >> > Hello, >> > >> > is there any problem with my d3dxcreatebox patch? >> > >> > Thanks in advance for any feedback. >> > >> > A+ >> > >> > David >> > >> >> Do you refer to http://source.winehq.org/patches/data/71983 ? I just >> had a cursory look at it: I presume there isn't anything fundamentally >> broken with your patch (you are forcing a particular vertex ordering, >> however that shouldn't be a problem for the D3DXCreateBox >> implementation) but, for sure, code style and formatting should be >> fixed. >> I know mesh.c is already quite bad in that regard, but that doesn't >> mean it needs more loose code. For example, in your patch there isn't >> a consistent usage of whitespace-after-comma, the same for spaces >> around operators or between the "if" and its condition. To compare >> expected and actual vertex data you should probably use the >> compare_vec3() function. Also, are "vertice", "normale" and "indice" >> Italian words? That doesn't look right. :) (also, the first vertex >> component is the position, not really "vertex") > >

March 10, 2011

Re: d3dxcreatebox patch

by David Adam

Thanks for the feedback. What do you mean by "you are forcing a particular vertex ordering3"? I just test the vertex that D3DXCreateBox sent. I think it is not possible to choose the ordering of the vertices for D3DXCreateBox. Did I miss anything? A+ David 2011/3/9 Matteo Bruni <matteo.mystral(a)gmail.com> > 2011/3/9 David Adam <david.adam.cnrs(a)gmail.com>: > > Hello, > > > > is there any problem with my d3dxcreatebox patch? > > > > Thanks in advance for any feedback. > > > > A+ > > > > David > > > > Do you refer to http://source.winehq.org/patches/data/71983 ? I just > had a cursory look at it: I presume there isn't anything fundamentally > broken with your patch (you are forcing a particular vertex ordering, > however that shouldn't be a problem for the D3DXCreateBox > implementation) but, for sure, code style and formatting should be > fixed. > I know mesh.c is already quite bad in that regard, but that doesn't > mean it needs more loose code. For example, in your patch there isn't > a consistent usage of whitespace-after-comma, the same for spaces > around operators or between the "if" and its condition. To compare > expected and actual vertex data you should probably use the > compare_vec3() function. Also, are "vertice", "normale" and "indice" > Italian words? That doesn't look right. :) (also, the first vertex > component is the position, not really "vertex") >

March 10, 2011

Re: d3dxcreatebox patch

by Matteo Bruni

2011/3/9 David Adam <david.adam.cnrs(a)gmail.com>: > Hello, > > is there any problem with my d3dxcreatebox patch? > > Thanks in advance for any feedback. > > A+ > > David > Do you refer to http://source.winehq.org/patches/data/71983 ? I just had a cursory look at it: I presume there isn't anything fundamentally broken with your patch (you are forcing a particular vertex ordering, however that shouldn't be a problem for the D3DXCreateBox implementation) but, for sure, code style and formatting should be fixed. I know mesh.c is already quite bad in that regard, but that doesn't mean it needs more loose code. For example, in your patch there isn't a consistent usage of whitespace-after-comma, the same for spaces around operators or between the "if" and its condition. To compare expected and actual vertex data you should probably use the compare_vec3() function. Also, are "vertice", "normale" and "indice" Italian words? That doesn't look right. :) (also, the first vertex component is the position, not really "vertex")

March 10, 2011