Re: D3D shader assembler
Am Sunday 19 July 2009 23:01:08 schrieb Henri Verbeet:
> > +const char *debug_src(struct shader_reg *reg, BOOL vs) {
> > +static char buffer[128];
> > +
> > +memset(buffer, 0, sizeof(buffer));
>
> This really isn't acceptable:
>
> Note that I think your mentor should have caught basic things like
> this in a much earlier stage.
Heh, it was me who wrote that specific piece of code in the first place, more
than a year ago :-)
Re: msi: Fix some pointer conversion warnings on 64-bit(try2)
André Hentschel wrote: > didnt want to change both variables, now its fine > sry for the noise > --- > dlls/msi/join.c |5 +++-- > dlls/msi/msiquery.c |4 ++-- > dlls/msi/storages.c |2 +- > dlls/msi/streams.c |2 +- > 4 files changed, 7 insertions(+), 6 deletions(-) > > > > +UINT_PTR i > +UINT row_value; Missing a semicolon? ;) Mike.
RE: D3D shader assembler (Matteo Bruni)
I read several months ago that the itnetion was to create the assembler inside the wined3d and then use its functionality inside the diverse d3dx9 implementations. Has this changed? I think it was Stefan Dösinger sho proposed it: d3dx -> wined3d assembler the wined3d will be re-usable and the d3dx functions will be extremely easy.
Re: XkbSetDetectableAutoRepeat not working on some platforms
"F Capela" wrote: XkbSetDetectableAutoRepeat is not working correctly on some distributions, including Ubuntu 9.04. In practical terms, this means programs running under Wine on such distros are unable to ignore autorepeat, doing strange things to games that use keyboard controls, for example. One way to work around the problem is to manually filter out the key release messages, which can be done with a few extra lines in dlls/winex11.drv/event.c . My question is, should I send a patch enabling this filtering? From what I have seen, patches to work around bugs that are clearly outside Wine are usually not accepted. Have you reported a bug to XOrg and those distros about that? -- Dmitry.
Re: appinstall update: Adobe Photoshop CS 2 installer test added
Austin English wrote: > On Sat, Jul 18, 2009 at 11:22 PM, Austin English > wrote: >> P.S., I'm working on some instructions for writing new tests, that >> I'll put on the wiki (later tomorrow-ish). While the testing framework >> is mostly complete, it's still pretty alpha/beta, and stuff may >> change, as I find different features that I need/bugs to workaround. >> It's at a point though that most of the 'core' stuff shouldn't change. >> If you'd like to help with adding tests, shoot me an e-mail if you've >> got more specific questions. > > Wiki added: > http://wiki.winehq.org/Appinstall_Testing > These are both fantastic thing. Thanks Austin! Thanks, Scott Ritchie
FW: Re: please reduce the four registrations on the single winehq.org site.
S Page wrote: > Hey, I really want to help the Wine project out by sharing my problems > and workarounds. > > But having to register FOUR TIMES on the same winehq.com site (bugs, > AppDB, forums, wiki) is excruciatingly painful and hostile to your > would-be contributors. I realize you're just using open source > tooling, but maybe you can press those four products to > a) implement a single sign-on > b) support OpenID > > Thanks, > -- > =S Page Strangely enough, I was just talking about this today at the Community Leadership Summit. Unfortunately it seems like it's a pretty difficult problem to solve as the tools to get all these things talking to eachother haven't been written. There are packages that integrate a forum and a wiki and such together, but they don't provide an easy way to get the data out of them - switching to them also presents huge data migration issues. Mozilla are farthest on the game here, as they were working on writing some of their own custom stuff based on OpenID, however that then deals with the need of having each app support an OpenID login. I'm not sure if it's a good idea, but there may be some merit in having one of the accounts function as an OpenID Provider and then have the others be able to link to it (but still be "separate accounts"). After that it's just about being able to login by OpenID rather than have a single account moving across each place. Thanks, Scott Ritchie
Re: Add stub for IoOpenDeviceRegistryKey
Uwe Bonnes wrote: This needs a test case to demonstrate what will happen in Windows versus what you are proposing as a stub out that always returns SUCCESS. James McKenzie
Re: D3D shader assembler
2009/7/19 Henri Verbeet :
> 2009/7/19 Matteo Bruni :
>> Hi to everybody,
>> I'm sending here the main assembler patch for reviews and suggestions.
>> It is bzipped as it is quite a big patch, but I couldn't find a
>> meaningful way to split it.
> It really is much easier to review as separate patches. The part that
> follows is really only the first thing I noticed.
>
>> +const char *debug_src(struct shader_reg *reg, BOOL vs) {
>> + static char buffer[128];
>> +
>> + memset(buffer, 0, sizeof(buffer));
> This really isn't acceptable:
> - "debug_src" isn't a very good name for something that visible
> outside the current file
> - The reg parameter should be const.
> - Zeroing the entire buffer is quite unnecessary.
> - Just passing the shader type would be much better than a BOOL
> parameter "vs" and hoping that anything that isn't a vertex shader is
> a pixel shader. Even if it happens to be true.
> - "buffer" has a fixed size.
> - "buffer" is static. Using wine_dbg_sprintf() would already be much
> better, but the entire "parsed_shader" setup looks flawed to me. It
> seems to me that you should handle that by having an appropriately
> filled struct asmparser_backend, and appending to a proper buffer.
>
> Note that I think your mentor should have caught basic things like
> this in a much earlier stage.
>
That function, in particular, should really be into asmparser.c and
not be visible from outside. Then the wine_dbg_sprintf() function
comes really handy in this situation, I didn't know it. Note also that
this debug_src function is used just to print trace info during asm
parsing, not to generate the intermediate representation or the
bytecode.
However, I think I've got your point. I'm going to look to other
similar mistakes in the code before resending.
A question: do you have an idea how I could split this in separate
patches? I can think of separating the parser from the bytecode
writer, but doesn't seems to me that this would be a real improvement.
Adding some shader instructions handling each time (for ex. starting
with just shader model 1, then separate patches for the subsequent
versions) maybe is better, but the first patch won't be really simpler
than this, I believe, as it would be alike this patch but without a
bunch of cases/functions.
Thank you,
Matteo.
Re: appinstall update: Adobe Photoshop CS 2 installer test added
On Sat, Jul 18, 2009 at 11:22 PM, Austin English wrote: > P.S., I'm working on some instructions for writing new tests, that > I'll put on the wiki (later tomorrow-ish). While the testing framework > is mostly complete, it's still pretty alpha/beta, and stuff may > change, as I find different features that I need/bugs to workaround. > It's at a point though that most of the 'core' stuff shouldn't change. > If you'd like to help with adding tests, shoot me an e-mail if you've > got more specific questions. Wiki added: http://wiki.winehq.org/Appinstall_Testing -- -Austin
Re: D3D shader assembler
2009/7/19 Matteo Bruni :
> Hi to everybody,
> I'm sending here the main assembler patch for reviews and suggestions.
> It is bzipped as it is quite a big patch, but I couldn't find a
> meaningful way to split it.
It really is much easier to review as separate patches. The part that
follows is really only the first thing I noticed.
> +const char *debug_src(struct shader_reg *reg, BOOL vs) {
> +static char buffer[128];
> +
> +memset(buffer, 0, sizeof(buffer));
This really isn't acceptable:
- "debug_src" isn't a very good name for something that visible
outside the current file
- The reg parameter should be const.
- Zeroing the entire buffer is quite unnecessary.
- Just passing the shader type would be much better than a BOOL
parameter "vs" and hoping that anything that isn't a vertex shader is
a pixel shader. Even if it happens to be true.
- "buffer" has a fixed size.
- "buffer" is static. Using wine_dbg_sprintf() would already be much
better, but the entire "parsed_shader" setup looks flawed to me. It
seems to me that you should handle that by having an appropriately
filled struct asmparser_backend, and appending to a proper buffer.
Note that I think your mentor should have caught basic things like
this in a much earlier stage.
D3D shader assembler
Hi to everybody, I'm sending here the main assembler patch for reviews and suggestions. It is bzipped as it is quite a big patch, but I couldn't find a meaningful way to split it. A quick mile-high overview: the assembler is divided in a parser and a bytecode writer. The parser is made by the flex (asmshader.l) and bison (asmshader.y) source files and the asmparser.c file. The bytecode writer is in bytecodewriter.c, btw, and asmutils.c contains some utility functions used in the assembler. With the asmshader.l SlAssembleShader function the parser processes the shader and returns an intermediate representation of it into the wine_shader struct. Then this struct is passed to the bytecode writer with the SlWriteBytecode function, which produces the assembled shader bytecode. A "point of interest": in the bottom part of asmshader.h there are some definitions borrowed from wined3d. They are used only internally, so they should not be a problem, but I'd like to hear if you think differently (ex. it is better to rename them?). Thank you, Matteo Bruni asmshader.txt.bz2 Description: BZip2 compressed data
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Le 19 juil. 09 à 17:03, Steven Edwards a écrit : On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard wrote: Just few remarks about your patch : - why you didn't use CoreFoundation API (plain C and already used in Wine) insteed of fprintf to generate Info.plist ? I didn't see which functionality to call to generate the plist's in C. Could you point me to the api's that are of use? http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPropertyLists/CFPropertyLists.html - you don't really need a Carbon launcher. Just a plain shell script in MacOS for executable et voila ... (sample joined, just edit MacOS/Notepad to set correct path) Very Nice! I must have overlooked this when I was exploring other problems like getting the xattr stuff right in the plists. I'll change my patch to reflect this for the first iteration. I still believe a future version is going to need some sort of helper application if we ever want to actually interact with a running instance for example, sending a quit message or cycling through active windows, etc. IMHO In a more general way, it's not a good thing to touch user directory without letting him decide. For application generated file you should used ~/Library/Application Support/Wine (see : http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#/ /apple_ref/doc/uid/20002282-BAJHCHJI) I see that but that implies a separate application to manage installed Wine programs like you state below, like WineHelper. This is going to be very hard to get in to stock Wine given our limitations on not using Cocoa But it's an external appplication, your desktop environment, that handle *.desktop file; wine just generate them... And at last, an NSStatusItem seem's a better choice to me for a wine application starter, instead of fake app bundles. Just generated description plist (dictionnary with app name, full path, arguments, and icon path ... and what ever you want) in ~/Library/Application Support/Wine/WineMenuBuilder and lets Helper application (your Bordeau's helper, WineHelper, or Mike Kronenberg one's) deal with theese files as they want. Perhaps but I don't think so. Allow me to present things from the user perspective. I think writing to ~/Applications/Wine is OK and does not violate HIG as installing an application under Wine (to me at least) is analogous to running a mpkg that does not prompt where to install. So don't choose ~/Applications but : /Applications/Wine or let's the user to choose if want an Applications folder in is Homedir. The user clearly wants to install the application if it gets to the point of generating the shortcuts and bundling it up. Having some sort of helper application application that manages it own internal list of menus seems to imply multiple operations and steps that don't seem correct at least to me. Here is the work flow I see Case 1. With WineApp Helper User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and starts the Wine helper User then selects Winword from the list of known installed Applications Winword Starts False with WineHelper : User opens HomeDirectory or Finder User goes to desired path and selects Winword.exe (.msi, .lnk) (Helper start if needed) Winwords start as intuitive as your Case 2 ... or Case 2. With wine app bundles User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and selects Winword Bundle Winword Starts The second case seems simpler and more intuitive. Now I could see a third case that would kind of give you the best of both worlds. Assuming your helper application was part of the Dock, you could have it act as a special launcher that expands like the way the Documents and Downloads menu's do and the user could select a given Windows application from there. Assuming that's the way it behaved we could have something like the following: Case 3. User navigates to Dock and icon for Wine Applications (or whatever its called) List of Installed Windows Applications is expanded vertically User Selects Winword from the list Winword loads WineHelper is Open Source so you can add any features you want, fork it, ask write access to Darwine CVS, send me patches (i must still have write access) I'm not really opposed to such a design, I think its more friendly than browsing around in the Applications folders but this all implies having a helper app that we can get in to Winehq. I know I can't write it, I don't know anyone can do it and make Alexandre happy. It is imperative to me to make stock Winehq be functional for the end user and that includes make some way for the user to have easy access to the applications they install under Wine. Given that, I will refocus on sticking the bash script directly in the bundle for now (thanks again for the tip) as I don't think Alexandre will reject that and we can go from there. If someone wants to change it t
Re: SVG Logo from the website
Joel Holdsworth wrote: > Quick question: Does anyone have an SVG of the wine logo as used on the > wine website? I'd like to use it as part of my graphics refresh to > improve idb_wine.bmp as shown here: > http://www.airwebreathe.org.uk/wine-icon/ > MadsRH (the artist who made some of the branding-ubuntu artwork) had a similar question when I was talking to him about wine, and he came up with the attached image. Not sure if it's useful though. Thanks, Scott Ritchie <>
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard wrote: > Just few remarks about your patch : > - why you didn't use CoreFoundation API (plain C and already used in Wine) > insteed of fprintf to generate Info.plist ? I didn't see which functionality to call to generate the plist's in C. Could you point me to the api's that are of use? > - you don't really need a Carbon launcher. Just a plain shell script in > MacOS for executable et voila ... > (sample joined, just edit MacOS/Notepad to set correct path) Very Nice! I must have overlooked this when I was exploring other problems like getting the xattr stuff right in the plists. I'll change my patch to reflect this for the first iteration. I still believe a future version is going to need some sort of helper application if we ever want to actually interact with a running instance for example, sending a quit message or cycling through active windows, etc. > IMHO In a more general way, it's not a good thing to touch user directory > without letting him decide. > For application generated file you should used ~/Library/Application > Support/Wine > (see : > http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI) I see that but that implies a separate application to manage installed Wine programs like you state below, like WineHelper. This is going to be very hard to get in to stock Wine given our limitations on not using Cocoa > And at last, an NSStatusItem seem's a better choice to me for a wine > application starter, instead of fake app bundles. > Just generated description plist (dictionnary with app name, full path, > arguments, and icon path ... and what ever you want) in > ~/Library/Application Support/Wine/WineMenuBuilder > and lets Helper application (your Bordeau's helper, WineHelper, or Mike > Kronenberg one's) deal with theese files as they want. Perhaps but I don't think so. Allow me to present things from the user perspective. I think writing to ~/Applications/Wine is OK and does not violate HIG as installing an application under Wine (to me at least) is analogous to running a mpkg that does not prompt where to install. The user clearly wants to install the application if it gets to the point of generating the shortcuts and bundling it up. Having some sort of helper application application that manages it own internal list of menus seems to imply multiple operations and steps that don't seem correct at least to me. Here is the work flow I see Case 1. With WineApp Helper User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and starts the Wine helper User then selects Winword from the list of known installed Applications Winword Starts or Case 2. With wine app bundles User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and selects Winword Bundle Winword Starts The second case seems simpler and more intuitive. Now I could see a third case that would kind of give you the best of both worlds. Assuming your helper application was part of the Dock, you could have it act as a special launcher that expands like the way the Documents and Downloads menu's do and the user could select a given Windows application from there. Assuming that's the way it behaved we could have something like the following: Case 3. User navigates to Dock and icon for Wine Applications (or whatever its called) List of Installed Windows Applications is expanded vertically User Selects Winword from the list Winword loads I'm not really opposed to such a design, I think its more friendly than browsing around in the Applications folders but this all implies having a helper app that we can get in to Winehq. I know I can't write it, I don't know anyone can do it and make Alexandre happy. It is imperative to me to make stock Winehq be functional for the end user and that includes make some way for the user to have easy access to the applications they install under Wine. Given that, I will refocus on sticking the bash script directly in the bundle for now (thanks again for the tip) as I don't think Alexandre will reject that and we can go from there. If someone wants to change it to something else later and can get it in to Winehq, by all means. -- 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
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Sun, Jul 19, 2009 at 7:41 AM, Ken Thomases wrote: > On Jul 17, 2009, at 10:02 PM, Steven Edwards wrote: > >> I tried looking in to generating of AppleScript app >> bundles however there seems to be no documented way to do it other >> than to use the Apple Script tool so no automatted method. > > Are you familiar with the osacompile command? I must have missed that before but I am afraid I don't see what it buys us other than saving hassle building the directory structure by hand. I don't think we want to use AppleScript rather than bash directly as Emmanuel suggested. Take for instance starting a new application, we will need something like do shell script "WINEPREIFX=foo path/to/wine bar.exe" Unless you know of some way to set the environment for only the parent and child applications for a given AppleScript. I found directions on how to do it globally but any shortcuts/scripts/bundles/whatever must honor the WINEPREFIX variable for each application. http://developer.apple.com/qa/qa2001/qa1067.html I am very open to being proved wrong though ;) -- 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
XkbSetDetectableAutoRepeat not working on some platforms
XkbSetDetectableAutoRepeat is not working correctly on some distributions,
including Ubuntu 9.04. In practical terms, this means programs running under
Wine on such distros are unable to ignore autorepeat, doing strange things to
games that use keyboard controls, for example. One way to work around the
problem is to manually filter out the key release messages, which can be done
with a few extra lines in dlls/winex11.drv/event.c . My question is, should I
send a patch enabling this filtering? From what I have seen, patches to work
around bugs that are clearly outside Wine are usually not accepted.
I'm adding the patch inlined in this message for those that might want to look
at it; if I feel the patch do have a chance to be accepted I will resend to
wine-patches.
Fábio Oliveira Schmidt Capela
fabio.cap...@yahoo.com
diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c
index a965b9f..793b842 100644
--- a/dlls/winex11.drv/event.c
+++ b/dlls/winex11.drv/event.c
@@ -283,6 +283,13 @@ static enum event_merge_action merge_events( XEvent *prev,
XEvent *next )
return MERGE_DISCARD;
}
break;
+case KeyRelease:
+if (prev->xany.window == next->xany.window && next->type == KeyPress
&& next->xkey.time == prev->xkey.time && next->xkey.keycode ==
prev->xkey.keycode && next->xkey.state == prev->xkey.state)
+{
+TRACE( "Discarding autorepeat key release for window %lx\n",
prev->xany.window );
+return MERGE_DISCARD;
+}
+break;
}
return MERGE_HANDLE;
}
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Jul 17, 2009, at 10:02 PM, Steven Edwards wrote: I tried looking in to generating of AppleScript app bundles however there seems to be no documented way to do it other than to use the Apple Script tool so no automatted method. Are you familiar with the osacompile command? -Ken
