wine-devel August 2007

wine-devel@winehq.org

121 participants
249 discussions

Old versions of Photoshop Elements tryout?
by Dan Kegel 28 Aug '07

28 Aug '07

Hi all, I have a copy of Photoshop Elements 1.0, and can easily download a tryout of Photoshop Elements 5, but I don't know where to get trial versions of 2 through 4. Anyone know? Thanks, Dan

2 3

Re: 0001-Basic-starting-point-for-implementing-d3dx9_yz.dll.patch
by Detlef Riekenberg 27 Aug '07

27 Aug '07

On Mo, 2007-08-27 at 14:13 +0200, Martijn Berger wrote: > > --- > .gitignore | 1 + > Makefile.in | 1 + > configure.ac | 1 + > dlls/Makefile.in | 1 + > dlls/d3dx9/Makefile.in | 15 +++++++++++++++ > 5 files changed, 19 insertions(+), 0 deletions(-) > --- /dev/null > +++ b/dlls/d3dx9/Makefile.in > @@ -0,0 +1,15 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +MODULE = d3dx9.dll > +IMPORTS = wined3d kernel32 > + > +C_SRCS = \ > + d3dx9_main.c > + > +RC_SRCS = version.rc This will not work: Your Makefile.in referenced "version.rc" and "d3dx9_main.c", but this files are missing in this Patch. You should never autogenerated modifications in any Patch: http://wiki.winehq.org/Developers-Hints#head-30a7f7f51ce0e42b4141749c9832ba… -- By by ... Detlef

1 0

DIB Driver code available
by Jesse Allen 27 Aug '07

27 Aug '07

Hi, I have my DIB driver code available on a public git host now: http://repo.or.cz/w/wine/dibdrv.git I'm going to briefly describe it. The dib driver (or engine) is a gdi driver. It is loaded into a dc when an application selects a dib, and overrides the existing driver. The magic takes place in SelectBitmap. Safe interaction is provided in gdi32 in four patches. If the winedib.drv.so library is available, then gdi will use the dib driver for drawing into the selected dib. If winedib.drv.so is not available, then gdi will continue using winex11 for example just as before. So these four patches can be safely integrated with the main tree if that is decided to be done. The rest of the code is the driver itself. It can handle all the standard uncompressed dib formats. It can convert between formats, and it can Get/SetDIBits/Blt. Get/SetPixel is implemented too. No other drawing code is done yet, so only simple GDI apps work. I've tested several apps and I'll list my results. notepad -- no regressions found winefile -- visual artifacts, but usable bmp loading -- works fine for what has been tested pixel setting -- works fine for every supported format opengl app -- Tribes 1 -- no regressions found d3d app -- Star Wars Battlefront -- no regressions found ddraw app -- Diablo shareware -- no regressions found ddraw app -- Diablo prerelease -- discovered one visual artifact These are the deficiencies in current code (non-stubs): No RLE support Missing raster operations in *Blt Get/SetDIBits does not conform exactly yet Bottom-up DIB's not tested for (and probably broken) DIB_PAL_COLORS not tested for No stretching No forwarding calls back to original driver* *For forwarding back the calls, what I think can be done is use the hbitmap handle originally given, convert it to a DDB, select it, and make the same gdi call again which will then go to the actual device. I do probably need to make sure the dibdrv's physdev persists and doesn't get deleted during this ;) (probably something in Create/Delete DC) Performance Originally I was going to state not to expect there really to be any performance improvements. I feel that there are optimizations possible that I have not done, but I left room for. My first concern was correct pixel by pixel operation. So I thought not to expect anything but last night I discovered this, so I might as well share. I have written a program that performs Get/SetPixel to test the various formats. There are 13 total tests, and the program produces 52 MB of output. Just for fun I ran my program without the dib driver and found it took a very long time (I was thinking it hung up at first since it took so long!): timed with winex11.drv real 0m53.903s user 0m19.807s sys 0m5.869s So I tried it with my driver: timed with winedib.drv real 0m3.924s user 0m3.537s sys 0m0.191s Indeed, my tests show that there is a 50 second difference with GDI Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Still, I wouldn't expect *your* app to seem much different (or work at all :P) So will all the interested parties take a look at the driver and I'd sure appreciate feedback on the direction this is going, so we move towards finishing this project beyond the summer of code. :) Jesse

3 7

Re: 0002-Basic-d3dx9-stub.patch
by H. Verbeet 27 Aug '07

27 Aug '07

On 27/08/07, Martijn Berger <martijn.berger(a)gmail.com> wrote: > +WINE_DEFAULT_DEBUG_CHANNEL(d3d10); That's not a good idea. Also, since the dll isn't actually called d3dx9.dll, how do you intend to handle the different versions? (Arguably these dlls are outside Wine's scope, since they're not installed as part of the OS, and should be installed by the application that is using them.)

2 1

getting started...
by Ed Sutter 27 Aug '07

27 Aug '07

Hi, I'm brand new to the list and would like to get a Windows application that I wrote (uCon) to work with wine/winelib. I've submitted it to the application database. I've tried it on Wine and it *almost* works, so I'd like to pursue this further by building uCon with Winelib (as is recommended somewhere in the documentation). That being said, I'm a bit confused... The winelib users guide mentions "winemaker", but doesn't point to where I get it. It doesn't appear to come with the Wine package (as expected); however, aside from the entire Wine source tree, I don't see anything else to download. Do I need/want the entire Wine source tree if my next step is to attempt to build my application using Winelib? Thanks in advance Ed BTW... I'm going to be doing this on a RH9 linux box.

2 3

[PATCH] Support for animated cursors
by Trent Waddington 27 Aug '07

27 Aug '07

Test program at: http://rtfm.insomnia.org/~qg/animatedcursor.exe Probably doesn't support all the possible animated cursors supported under windows, and correct timing of animation hasn't been attempted. Trent

3 2

Re: wintrust(4/5): Test and implement SoftpubLoadMessage (with patch)
by Alexandre Julliard 27 Aug '07

27 Aug '07

"Juan Lang" <juan.lang(a)gmail.com> writes: > + ret = data->pPDSip->pSip->pfGet(data->pPDSip->psSipSubjectInfo, > + &data->dwEncoding, 0, &size, buf); > + if (ret) > + { > + data->hMsg = CryptMsgOpenToDecode(data->dwEncoding, 0, 0, data->hProv, > + NULL, NULL); > + if (data->hMsg) > + ret = CryptMsgUpdate(data->hMsg, buf, size, TRUE); > + } > + > + if (!ret || !data->hMsg) > + err = GetLastError(); > + data->psPfns->pfnFree(buf); > + return err; That style of coding is dangerous, it assumes that all the error paths of the called functions will set last error properly. It's better to return a success/failure boolean and fetch the last error only when the actual error is needed, not as an error indication. -- Alexandre Julliard julliard(a)winehq.org

1 0

[git] Playing with gitstat (can we change date for the tags?)
by Paul Vriens 27 Aug '07

27 Aug '07

Hi, I was just playing with gitstat (http://tree.celinuxforum.org/gitstat/) to see if it give some nice graphs for Wine as well (on my local box). I can see all the tags but for some reason a lot of tags (from wine-0.0.2 to wine-0.7 and after that wine-940201 to wine-980927, so basically every tag before Alexandre's "Initial revision") have nearly the same tagger/author date (around November 30th 2005). This messes up the ordering of the tags. Is there something I can do about this? (man git-tag tells me one shouldn't change tags afterwards). (I've changed the necessary perl-script to only include the tags that are correct so I do have some output). -- Cheers, Paul.

2 1

Re: Imm32: Update position of default IME window
by Alexandre Julliard 27 Aug '07

27 Aug '07

Aric Stewart <aric(a)codeweavers.com> writes: > + > + /* make sure we are on the desktop */ > + GetClientRect(GetDesktopWindow(),&desk_rect); You have to use GetMonitorInfo to support multi-monitor setups correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [patch] Garbage code in text string display
by Guan Xin 27 Aug '07

27 Aug '07

On 8/23/07, Juan Lang <juan.lang(a)gmail.com> wrote: > You may generally post source to wine-devel if it's short and to the > point. Please don't post a binary. Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests. > Right to the first point, which is why we write tests that pass on > Windows, and fix Wine to match the tests. This obviates the need to > look at Windows source. You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition. Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.

2 2

← Newer
1
2
3
4
5
6
7
8
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2007