September 2007 - Wine-Devel

Re: wordpad: #1 Store bar states in the registry

by Alexander Nicolaysen Sørnes

On Tuesday 11 September 2007 18:05:51 you wrote: > Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > > Tirsdag 11 september 2007 12:10, skrev du : > >> Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > >> > wordpad: #1 Store bar states in the registry > >> > >> This doesn't work well when resizing the window, the toolbars get > >> overwritten by the edit area. > > > > I'll try to fix this. It's not a problem with this patch, though; it's > > already present in Wine GIT. > > Are you sure? It works fine for me in current git. Positive; and I tested with Wine 0.9.44 and GIT without my unapplied patches. It needs the WS_CLIPCHILDREN style for the main window, which is not set. I sent the WS_CLIPCIHLDREN patch to Eric for review, but I don't think there is anything wrong with it. Alexander N. Sørnes

Sept. 11, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Lei Zhang

On 9/10/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Lei Zhang" <thestig(a)google.com> wrote: > > >> In the tests still there is no actual edit contents/selection changes > >> tracking after every message. > >> > >> -- > >> Dmitry. > >> > > > > I'm sending WM_GETTEXT to the control and then checking the text after > > every change. Did you mean something else when you say contents > > changes tracking? > > I mean that after every message you send you need to send WM_GETTEXT and > EM_GETSEL messages to the control and check what they return, that's what > I call actual edit contents/selection changes tracking. By "what they > return" I also mean for WM_GETTEXT not only SendMessage return value but > also the contents of the buffer. > > -- > Dmitry. > Yes, I am already checking the return value and the contents of the buffer: + r = SendMessage(hwEdit, WM_GETTEXT, 1024, (LPARAM) buffer); + ok(r == strlen(text), "Expected: %d, got len %d\n", strlen(text), r); + ok(strcmp(buffer, text) == 0, "expected %s, got %s\n", text, buffer); I'll add EM_GETSEL checks as well.

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexandre Julliard

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > Tirsdag 11 september 2007 12:10, skrev du : >> Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: >> > wordpad: #1 Store bar states in the registry >> >> This doesn't work well when resizing the window, the toolbars get >> overwritten by the edit area. > > I'll try to fix this. It's not a problem with this patch, though; it's > already present in Wine GIT. Are you sure? It works fine for me in current git. -- Alexandre Julliard julliard(a)winehq.org

Sept. 11, 2007

lostwages CVS moved into GIT

by Jeremy Newman

We have switched our website sources (previously known as lostwages), over to git. >From this point on I would prefer if all patches came from the git tree. Refer to the git documentation on the website and wiki on how to prepare patches with git. The git module is called simply "website".

Sept. 11, 2007

Re: problem with silly CreateBitmap call

by aaa

Hi list, I experienced exactly the same problem with Solidworks 2007 http://appdb.winehq.org/appview.php?iVersionId=8983 with occasionnal big slowdowns caused by a 10000x10000x24bpp bitmap allocation. In this case it doesn't crashed, but allocate more than 1GB of swap. I filed a bug : http://bugs.winehq.org/show_bug.cgi?id=9561

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexander Nicolaysen Sørnes

Tirsdag 11 september 2007 12:10, skrev du : > Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > > wordpad: #1 Store bar states in the registry > > This doesn't work well when resizing the window, the toolbars get > overwritten by the edit area. I'll try to fix this. It's not a problem with this patch, though; it's already present in Wine GIT. Alexander N. Sørnes

Sept. 11, 2007

Re: make_makefiles: ignore .DS_Store files

by Alexandre Julliard

Emmanuel Maillard <mahanuu(a)free.fr> writes: > From b298a599f2b0eb5b8d7f2092573aba28755001d7 Mon Sep 17 00:00:00 2001 > From: Emmanuel Maillard <mahanuu(a)free.fr> > Date: Sun, 2 Sep 2007 12:42:16 +0200 > Subject: [PATCH] - ignore .DS_Store files You should put that in your global ignore file, the .DS_Store files are not created by the build process so they don't belong in .gitignore. -- Alexandre Julliard julliard(a)winehq.org

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexandre Julliard

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > wordpad: #1 Store bar states in the registry This doesn't work well when resizing the window, the toolbars get overwritten by the edit area. -- Alexandre Julliard julliard(a)winehq.org

Sept. 11, 2007

Re: WineD3D: PBO support 2/2

by Stefan Dösinger

Am Dienstag, 11. September 2007 10:25:28 schrieb Roderick Colenbrander: > Hi, > > This patch adds PBO support for dynamicly locked textures. It greatly > improves performance of games that use render target locking a lot. It looks good to me, here are some suggestions for further improvements in further patches(this patch is good for the start). The locking flag passed to LockRect could be forwarded to GL. D3DLOCK_DISCARD and D3DLOCK_WRITEONLY(ddraw only) would be GL_WRITE_ONLY, D3DLOCK_READONLY GL_READ_ONLY. However, we have to take care about the upside down swap for render target locking. D3DLOCK_DISCARD can be implemented(appart of the surface beeing writeonly) by calling glBufferData with a NULL pointer. This tells gl that the old data can be thrown away. This allows the driver to further optimize the map. e.g. if it is a texture that is still used for rendering in some pending calls, it can duplicate the buffer and doesn't have to wait for the rendering to finish. It will have to be tested if that really helps performance. I tried it for vbos, and it made things noticeably worse. Binding the pbo to 0 after each operation is a good idea for a start, but shouldn't be done in the long term in my opinion.

Sept. 11, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: >> In the tests still there is no actual edit contents/selection changes >> tracking after every message. >> >> -- >> Dmitry. >> > > I'm sending WM_GETTEXT to the control and then checking the text after > every change. Did you mean something else when you say contents > changes tracking? I mean that after every message you send you need to send WM_GETTEXT and EM_GETSEL messages to the control and check what they return, that's what I call actual edit contents/selection changes tracking. By "what they return" I also mean for WM_GETTEXT not only SendMessage return value but also the contents of the buffer. -- Dmitry.

Sept. 11, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Lei Zhang

On 9/10/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Lei Zhang" <thestig(a)google.com> wrote: > > > This patch lets users hit ctrl + Z in edit controls to trigger an > > undo. The test case has been improved to check for both the return > > values and the content of the edit control. > > In the tests still there is no actual edit contents/selection changes > tracking after every message. > > -- > Dmitry. > I'm sending WM_GETTEXT to the control and then checking the text after every change. Did you mean something else when you say contents changes tracking?

Sept. 11, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: > This patch lets users hit ctrl + Z in edit controls to trigger an > undo. The test case has been improved to check for both the return > values and the content of the edit control. In the tests still there is no actual edit contents/selection changes tracking after every message. -- Dmitry.

Sept. 10, 2007

Re: settlers 3 and dib engine

by Jesse Allen

On 9/10/07, Piotr Maceluch <skrzynka365(a)konto.pl> wrote: > As I'm new to Wine/X development, what I'd appreciate the most, is > critical comments on the attached patch: is omitting XGetPixel/XSetPixel > and reading directly XImage data a correct solution? Am I allowed to use > inline assembler in above case? Any other issues? > Thanks & regards Does this problem still appear with the DIB engine? As I don't know winex11, I can't tell you for sure if not using X Get/Set Pixel really matters. However you may be fixing a bug in the process, so you might want to look at bug 4277 and concentrate on that first. Speed is nice, but correctness should come first. As for the DIB engine, all this shouldn't matter, however, winex11 probably still needs to be able to read and set DIBs, and that means we should fix existing issues like you are having. Jesse

Sept. 10, 2007

Re: settlers 3 and dib engine

by Piotr Maceluch

Jesse Allen wrote: >On 9/8/07, Martin Owens <doctormo(a)gmail.com> wrote: > > >>Does this mean that the current _painfully_ slow Imperialism II that >>uses the DIB drawing to draw it's in game maps will work faster? I'm >>waiting for this functionality and have pledged $20 just in case it >>can spur on the solution. >> >>Best Regards, Martin Owens >> >> > > >I don't know, you'll have to try it yourself. It depends on what the >app is doing. You can get a checkout of the tree here: >http://repo.or.cz/w/wine/dibdrv.git > >Beware there are probably visual regressions, but it's speed you're >checking here right? :) > >Jesse > > Hi, as a part of struggle to understand the drivers I played a little with winex11.drv and made some simple optimizations. Actually the changes make 'Settlers 3' playable. On my Duron/900 the delay caused by copying bitmaps is hardly noticable (it's no longer a .5sec lag, now it looks like a frame or two dropped once every few seconds). If anyone wants to give it a try with S3, then there's another problem with races condition on WaitFor..Object/SetEvent/ResetEvent, but that can be overcome by just disabling ResetEvent (simple return STATUS_SUCCESS; at the beginning of NtResetEvent). I'm trying to get some more generic solution to the ResetEvent problem but it seems related to the lack of thread boost after WaitFor(Single|Multiple)Object on Wine (seems like poor design of game code) and is quite difficult in general. As I'm new to Wine/X development, what I'd appreciate the most, is critical comments on the attached patch: is omitting XGetPixel/XSetPixel and reading directly XImage data a correct solution? Am I allowed to use inline assembler in above case? Any other issues? Thanks & regards Piotr Maceluch -- ----- AlphaNet - najtaniej w sieci! -------- Odnowienia domen w rewelacyjnych cenach! .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl http://www.domeny.alpha.pl -------------------------------------------- >From 9d26b16c37a08aaf54f66712563cdcd523c1a95a Mon Sep 17 00:00:00 2001 From: Piotr Maceluch <skrzynka365(a)konto.pl> Date: Mon, 10 Sep 2007 22:56:25 +0200 Subject: [PATCH] Optimized copying of 1bit bitmaps to and from XImage data. The copying operations for copying 1bit bitmap to memory and other way no longer employ XGetPixel/XSetPixel. Instead memory operations are used. They're implemented in asm memcpy which does bit order swapping on the fly (swapping is lookup table based). --- dlls/winex11.drv/dib.c | 137 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 137 insertions(+), 0 deletions(-) diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c index 00b1f23..0e938b8 100644 --- a/dlls/winex11.drv/dib.c +++ b/dlls/winex11.drv/dib.c @@ -58,6 +58,9 @@ static PVOID dibs_handler; static int ximageDepthTable[32]; +static BYTE bit_reversal_lookup_table[0x100]; //bit-order-reversed value for every 8bit value +static int bit_reversal_lookup_table_initialized = 0; + /* This structure holds the arguments for DIB_SetImageBits() */ typedef struct { @@ -101,6 +104,9 @@ static INT X11DRV_DIB_Coerce(X_PHYSBITMAP *,INT,BOOL); static INT X11DRV_DIB_Lock(X_PHYSBITMAP *,INT,BOOL); static void X11DRV_DIB_Unlock(X_PHYSBITMAP *,BOOL); +static void X11DRV_InitBitReversalLookupTable(); +static void X11DRV_MemoryCopyWithBitOrderSwap(void *dest, const void *src, int byteCount); + /* Some of the following helper functions are duplicated in dlls/gdi/dib.c @@ -508,6 +514,30 @@ static void X11DRV_DIB_SetImageBits_1( int lines, const BYTE *srcbits, width = min(srcwidth, dstwidth); /* ==== pal 1 dib -> any bmp format ==== */ + if(((bmpImage->bits_per_pixel | bmpImage->depth) == 1) && + (bmpImage->byte_order == bmpImage->bitmap_bit_order)) + { + //optimization for 1to1 copy + int y; + BYTE* bitmapPtr = ((BYTE*)(bmpImage->data)) + (bmpImage->xoffset >> 3) + + ((lines - 1) * bmpImage->bytes_per_line); + const BYTE* dataPtr = srcbits; + + TRACE("1 bit data -> 1 bit bmp, copy: width=%i, lines=%i, image->bpl=%i, dest_bpl=%i\n", + width, lines, bmpImage->bytes_per_line, linebytes); + + X11DRV_InitBitReversalLookupTable(); + + for (y = 0; y != lines; y++) + { + X11DRV_MemoryCopyWithBitOrderSwap(bitmapPtr, dataPtr, (width + 7) >> 3); + + dataPtr += linebytes; + bitmapPtr -= bmpImage->bytes_per_line; + } + } + else + { for (h = lines-1; h >=0; h--) { srcbyte=srcbits; /* FIXME: should avoid putting x<left pixels (minor speed issue) */ @@ -537,6 +567,7 @@ static void X11DRV_DIB_SetImageBits_1( int lines, const BYTE *srcbits, } srcbits += linebytes; } + } } /*********************************************************************** @@ -561,6 +592,27 @@ static void X11DRV_DIB_GetImageBits_1( int lines, BYTE *dstbits, switch (bmpImage->depth) { case 1: + { + int y; + const BYTE* bitmapPtr = ((BYTE*)(bmpImage->data)) + (bmpImage->xoffset >> 3) + + ((lines - 1) * bmpImage->bytes_per_line); + BYTE* dataPtr = dstbits; + + TRACE("1 bit bmp -> 1 bit data, copy: width=%i, lines=%i, image->bpl=%i, dest_bpl=%i\n", + width, lines, bmpImage->bytes_per_line, linebytes); + + X11DRV_InitBitReversalLookupTable(); + + for (y = 0; y != lines; y++) + { + //used (width + 7) so rounded down will always contain last pixels in line when ((width % 8) != 0) + X11DRV_MemoryCopyWithBitOrderSwap(dataPtr, bitmapPtr, (width + 7) >> 3); + + dataPtr += linebytes; + bitmapPtr -= bmpImage->bytes_per_line; + } + } + break; case 4: if (X11DRV_DIB_CheckMask(bmpImage->red_mask,bmpImage->green_mask,bmpImage->blue_mask) && srccolors) { @@ -4880,3 +4932,88 @@ Pixmap X11DRV_DIB_CreatePixmapFromDIB( HGLOBAL hPackedDIB, HDC hdc ) TRACE("Returning Pixmap %ld\n", pixmap); return pixmap; } + + +/** Returns given input byte with bit order reversed. */ +static BYTE X11DRV_ReverseBits(BYTE input) +{ + BYTE output = 0; + int i; + for(i = 0; i != 8; i++) + { + output |= (input & 1); + input >>= 1; + if(i != 7) + { + output <<= 1; + } + } + return output; +} + +/* Initializes bit_reversal_lookup_table with bit-order-reversed values for + * every possible byte value. */ +static void X11DRV_InitBitReversalLookupTable() +{ + int i; + + if(bit_reversal_lookup_table_initialized) + { + //skip if already initialized + return; + } + + for(i = 0; i != 0x100; i++) + { + bit_reversal_lookup_table[i] = X11DRV_ReverseBits((BYTE)i); + } + + bit_reversal_lookup_table_initialized = 1; +} + +/* Copies byteCount bytes from src to dest and changes bit order of copied + * data bytes. + * FIXME: The function doesn't work when declared as inline or static inline. + * */ +static void X11DRV_MemoryCopyWithBitOrderSwap(void *dest, const void *src, int byteCount) +{ + __asm__ __volatile__ ( + "pushl %%ecx\n" + "cld\n" + "xorl %%edx, %%edx\n" + "shr $2, %%ecx\n" + "jz 2f\n" + + "1:\n" + "lodsl\n" + "movb %%al, %%dl\n" + "movb bit_reversal_lookup_table(%%edx),%%al\n" + "movb %%ah, %%dl\n" + "movb bit_reversal_lookup_table(%%edx),%%ah\n" + "bswap %%eax\n" + "movb %%al, %%dl\n" + "movb bit_reversal_lookup_table(%%edx),%%al\n" + "movb %%ah, %%dl\n" + "movb bit_reversal_lookup_table(%%edx),%%ah\n" + "bswap %%eax\n" + + "stosl\n" + "loop 1b\n" + + "2:\n" + "popl %%ecx\n" + "andl $3, %%ecx\n" + "jz 4f\n" + + "3:\n" + "lodsb\n" + "movb %%al, %%dl\n" + "movb bit_reversal_lookup_table(%%edx),%%al\n" + "stosb\n" + "loop 3b\n" + + "4:\n" + : //output + : "S" (src), "D" (dest), "c" (byteCount) //input + : "eax", "edx", "cc" );//cc - condition codes (flags) +} -- 1.5.3.1

Sept. 10, 2007

Re: Would like to contribute to wine

by Jesse Allen

On 9/9/07, Marcel Partap <mpartap(a)gmx.net> wrote: > >> On this year's Google SoC I found an interesting application called > >> "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from > >> wine)". > >> It was accepted but I can't find any information about any progress. > I am the guy responsible for not providing information about the progress - during SoC time I was most busy with actual > coding and so did not even update my project blog.. sorry bout that :) > > > The final solution must work with CreateDC("winspool",....) and need > > the complete DIB-Engine. > Exactly, the gdi engines drawing engine functions (EngBitBlt, EngTextOut...) need support for raster operations, which > should best be implemented in dib.c .. Right now the driver initialisation and > > > Marcel is still working to improve his code and will start sending patches. > Yeees I aam.. ;) > But I am visiting my family for a few days ... you can have a look though at the current code under > http://synth-worldz.de/wine-ddi/ddi.c ... too many stubs and unimplemented functions though, even if a few drivers > already start feeling comfortable with it. > What about the Drv* functions? If these get implemented, it would make forwarding from the dib engine back to the graphics driver a whole lot easier. Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing. It should be done... Jesse

Sept. 10, 2007

Re: ntdll: Do not segfault with snoop for files with a broken exporttable

by Detlef Riekenberg

On So, 2007-09-09 at 13:02 +0900, Dmitry Timoshkov wrote: > "Detlef Riekenberg" <wine.dev(a)web.de> wrote: > > > ntdll: Do not segfault with snoop for files with a broken export table > > > + /* Check for files with broken exports */ > > + if (exports->Characteristics || > > + exports->MajorVersion || > > + HIWORD(exports->NumberOfFunctions) || > > + HIWORD(exports->NumberOfNames)) { > > + WARN_(snoop)("snoop disabled for bad module %p: 0x%x, %u, 0x%x, 0x%x\n", hmod, > > + exports->Characteristics, exports->MajorVersion, > > + exports->NumberOfFunctions, exports->NumberOfNames); > > + return; > > + } > > + > > TRACE_(snoop)("hmod=%p, name=%s\n", hmod, name); > > It's still helpful to see the line "hmod=%p, name=%s\n" in the log before > an error message. Wine crash in the TRACE, because name is not a valid pointer. The affected module is part of the WARN - output. A GetModuleFileName for hmod can be done, but is that really needed? The affected module is an exe, so deactivating snoop is not a Problem. -- By by ... Detlef

Sept. 10, 2007

Fifa 07 - wined3d regression

by Jan de Mooij

Hi, Fifa 07 used to work fine with Wine, but around version 0.9.40-0.9.41 the game hangs when I start a new match. The text "Loading..." is displayed, but there is no progressbar because one thread terminates. I attached the results of winedbg (backtrace and some messages before the crash). This is the result of git bisect: 9ba3f389f665aae45b6a8a6861f9621b020e5c25 is first bad commit commit 9ba3f389f665aae45b6a8a6861f9621b020e5c25 Author: Stefan Dösinger <stefandoesinger(a)gmx.at> Date: Sun Jul 8 23:33:48 2007 +0200 wined3d: Initialize surfaces at creation. This patch removes a check of "GL_SUPPORT(APPLE_CLIENT_STORAGE)". If I put that check in again, the game works like before. The if-condition evaluates to True now, so it allocates the memory. But it segfaults there I think. Anyone knows how to fix this? Please let me know if you need more information. Thanks in advance! Jan de Mooij

Sept. 10, 2007

Fifa 07 - wined3d regression

by Jan de Mooij

Hi, Fifa 07 used to work fine with Wine, but around version 0.9.40-0.9.41 the game hangs when I start a new match. The text "Loading..." is displayed, but there is no progressbar because one thread terminates. I attached the results of winedbg (backtrace and some messages before the crash). This is the result of git bisect: 9ba3f389f665aae45b6a8a6861f9621b020e5c25 is first bad commit commit 9ba3f389f665aae45b6a8a6861f9621b020e5c25 Author: Stefan Dösinger <stefandoesinger(a)gmx.at> Date: Sun Jul 8 23:33:48 2007 +0200 wined3d: Initialize surfaces at creation. This patch removes a check of "GL_SUPPORT(APPLE_CLIENT_STORAGE)". If I put that check in again, the game works like before. The if-condition evaluates to True now, so it allocates the memory. But it segfaults there I think. Please let me know if you need more information. Thanks in advance! Jan de Mooij

Sept. 10, 2007

Re: Would like to contribute to wine

by Marcel Partap

>> On this year's Google SoC I found an interesting application called >> "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from >> wine)". >> It was accepted but I can't find any information about any progress. I am the guy responsible for not providing information about the progress - during SoC time I was most busy with actual coding and so did not even update my project blog.. sorry bout that :) > The final solution must work with CreateDC("winspool",....) and need > the complete DIB-Engine. Exactly, the gdi engines drawing engine functions (EngBitBlt, EngTextOut...) need support for raster operations, which should best be implemented in dib.c .. Right now the driver initialisation and > Marcel is still working to improve his code and will start sending patches. Yeees I aam.. ;) But I am visiting my family for a few days ... you can have a look though at the current code under http://synth-worldz.de/wine-ddi/ddi.c ... too many stubs and unimplemented functions though, even if a few drivers already start feeling comfortable with it. >> In suse repository I found ddiwrapper package. It does something similar >> but only for some Canon drivers and wraps to use by CUPS. Of course that code was a great source of inspiration (thank you Uli Hecht) for the current implementation of printbitmap.exe which you can have a look at at http://synth-worldz.de/wine-ddi/printbitmap.c.. > ddiwrapper use ghostscript to convert Postscript to a Bitmap and the That is an unsolved problem up to now, how to get a drawing operation to the driver? there's two options for that: variant 1: application: sends drawing calls -> wineps.drv: renders a postscript -> ghostscript(win version preferably): renders to bitmap -> printbitmap.exe: loads native driver and simply blts the bitmap onto device surface and prints variant2: GDI32/DDI: CreateDC("WINSPOOL"...): normal driver loading like on native: hook drawing functions from driver -> native driver: draw stuff on device surface, punt unhandled calls back to GDI -> GDI32/DDI+DIB: Eng* functions wrap around the specific DIB functions which do the actual raster operations Right now variant 1 is kinda 'working' although it needs some more glue and love. Variant 2 is the next step, I'll start on this in a week or two after submitting the patches.. By the way who did work on CreateDC? Any ideas how to handle a printer device context? I have not yet looked into the details of the current implementation because I was instantly scared away by it ;) > There are a lot of things in wine, that are missing and need a lot of work. Wow definite :) All the printer property sheets will require another major amount of care.. Anyways many regards, marcel

Sept. 9, 2007

Re: ntdll: Do not segfault with snoop for files with a broken exporttable

by Dmitry Timoshkov

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > ntdll: Do not segfault with snoop for files with a broken export table > + /* Check for files with broken exports */ > + if (exports->Characteristics || > + exports->MajorVersion || > + HIWORD(exports->NumberOfFunctions) || > + HIWORD(exports->NumberOfNames)) { > + WARN_(snoop)("snoop disabled for bad module %p: 0x%x, %u, 0x%x, 0x%x\n", hmod, > + exports->Characteristics, exports->MajorVersion, > + exports->NumberOfFunctions, exports->NumberOfNames); > + return; > + } > + > TRACE_(snoop)("hmod=%p, name=%s\n", hmod, name); It's still helpful to see the line "hmod=%p, name=%s\n" in the log before an error message. -- Dmitry.

Sept. 8, 2007

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (improved, fixes bug #5877)

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > As suggested by Dmitry the table id is now a symbolic constant. However > I didn't included the tttags.h but defined the constant myself as I see > that every freetype header is checked by configure and included only if > it is available. Thus in case it is not available we would either need > an #ifdef in AddFileToList (what IMHO wouldn't be nice) or in such a > case define the symbol ourselfs. But if we will need to define the > symbol then why to include the header? > +#define WINEENG_SFNTTAG_CFF 0x43464620 /* stores the outline for Type1 OTF fonts */ This is not what I suggested. Using a macro like FT_MAKE_TAG makes this much more readable. WINEENG_SFNTTAG_CFF doesn't follow any macro naming conventions in freetype.c, I'd suggest to use the same name as FreeType has (TTAG_CFF) instead, perhaps inside of #ifdef guard if including tttags.h is much hassle. Although including tttags.h and using #ifdef before defining TTAG_CFF is much more clean IMO. -- Dmitry.

Sept. 8, 2007

[PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.

by Misha Koshelev

Jacek Caban wrote: > Hi Misha, > > Misha Koshelev wrote: > > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > > Now we can just address them within the framework since we need that framework for closing handles > > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > > much sense to me to store the "parent" object handle in two different places. > > Sorry for late response. > > This patch reverses what I've done some time ago. There is no reason to > have parent object in header - you need only a child list to handle > closing handles. Also casts make the code much less readable. > > Thanks, > Jacek Ok, that sounds fair. I didn't really like the casts either, that was my biggest problem with this patchset. I am leaving the country tomorrow for 9 days but will change the patches/resubmit as you suggested after I come back. Thanks for your comments. Misha

Sept. 8, 2007

Re: settlers 3 and dib engine

by Jesse Allen

On 9/8/07, Martin Owens <doctormo(a)gmail.com> wrote: > Does this mean that the current _painfully_ slow Imperialism II that > uses the DIB drawing to draw it's in game maps will work faster? I'm > waiting for this functionality and have pledged $20 just in case it > can spur on the solution. > > Best Regards, Martin Owens I don't know, you'll have to try it yourself. It depends on what the app is doing. You can get a checkout of the tree here: http://repo.or.cz/w/wine/dibdrv.git Beware there are probably visual regressions, but it's speed you're checking here right? :) Jesse

Sept. 8, 2007

Re: settlers 3 and dib engine

by Martin Owens

Does this mean that the current _painfully_ slow Imperialism II that uses the DIB drawing to draw it's in game maps will work faster? I'm waiting for this functionality and have pledged $20 just in case it can spur on the solution. Best Regards, Martin Owens On 08/09/2007, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > On 9/8/07, Skrzynka <skrzynka365(a)konto.pl> wrote: > > I'll do what I can. However it's far too early to bother about my commits :) > > I'm trying to compare and understand the control flow of both drivers > > (winex11 and winedib). At which function in winex11 is copying data > > to/from server taking place? And in what function/file is the check for > > winedib driver availability done? > > Thanks > > Piotr > > > > > Feel free to use this list if you want to ask anything or discuss > (it's what it's for). I was calling Settlers 3 a test app, and > rightfully so as you have shown you have regressions. As for copying > to a from winex11? If you are talking about getting a dib from a ddb, > you use GetDIBits. If you are talking about the old needless copying > done with winex11 (because graphics are done in the server), well, > using the dib engine is going to make it go away, and since we are > writing the dib engine from scratch, it doesn't have any of it. > > Jesse > > >

Sept. 8, 2007

Re: settlers 3 and dib engine

by Jesse Allen

On 9/8/07, Skrzynka <skrzynka365(a)konto.pl> wrote: > I'll do what I can. However it's far too early to bother about my commits :) > I'm trying to compare and understand the control flow of both drivers > (winex11 and winedib). At which function in winex11 is copying data > to/from server taking place? And in what function/file is the check for > winedib driver availability done? > Thanks > Piotr > Feel free to use this list if you want to ask anything or discuss (it's what it's for). I was calling Settlers 3 a test app, and rightfully so as you have shown you have regressions. As for copying to a from winex11? If you are talking about getting a dib from a ddb, you use GetDIBits. If you are talking about the old needless copying done with winex11 (because graphics are done in the server), well, using the dib engine is going to make it go away, and since we are writing the dib engine from scratch, it doesn't have any of it. Jesse

Sept. 8, 2007

Re: [PATCH 2/3] wininet: Use parent/child handle framework to track parent/child handle relationships.

by Jacek Caban

Hi Misha, Misha Koshelev wrote: > We have a lot of parent/child relationships in wininet that are addressed on an individual basis. > Now we can just address them within the framework since we need that framework for closing handles > too. The only thing I don't like is that we have to make lots of casts now, but it doesn't really make > much sense to me to store the "parent" object handle in two different places. Sorry for late response. This patch reverses what I've done some time ago. There is no reason to have parent object in header - you need only a child list to handle closing handles. Also casts make the code much less readable. Thanks, Jacek

Sept. 8, 2007

Dfw5 draws graphs black (regression)

by Willi Mann

Hi! Derive 5 no longer draws graphs in color. It should look like that: http://wserver.wm1.at/~willi/wine/dfw.png With current versions, it draw the blue graph in black. I could track it down to this commit (between 0.9.25 and 0.9.26): http://wserver.wm1.at/~willi/wine/wine_dfw.diff.txt (In fact, these are two commits, but the intermediate version does not compile) Please let me know if I can do anything to help fixing this bug. Willi Please CC: me on replies.

Sept. 8, 2007

Re: settlers 3 and dib engine

by Skrzynka

Jesse Allen wrote: >On 9/8/07, Skrzynka <skrzynka365(a)konto.pl> wrote: > > >>Hi, >>I'm trying to get Settlers 3 to run on Wine. After fixing some race >>condition (seems like the thread calling WaitForXXXObject was giving up >>time-slice too early after the call) it seems that the only problem left >>is very slow text output. What I could understand from the forum >>archives is that with no DIB engine, the rendering into a DC causes >>copying of the bitmap to/from server (is that correct?). I'd like to >>contribute to the DIB engine if it's possible/needed, so I'd like to ask >>about a few things. There were some discussion recently about an >>implementation of DIB engine by Jesse Allen - what is the status of DIB >>engine? I compiled winedib.drv but ExtTextOut function is missing there >>and overall there are regressions visible when running Settlers 3 (wrong >>colors, no text at all). Which docs/urls/sources would you recommend to >>read to get some quick introduction to the DIB engine? Which particular >>functions are making current impl slow? Or, in general: where to start? >>Sorry for any silly questions... >>Thanks & regards >> Piotr >> >> >> > >Hello, > >Yes ExtTextOut will probably need to be implemented, as well as >whatever family of functions that might go with it. There might be >some cooperation necessary with the display driver here I don't know. >You're pretty much on your own right now if you go there, as you'll >need to figure out how to do everything. > >A simpler project might be to implement the drawing algorithms in >graphics.c. It needs to be done, and I do believe I have enough >infrastructure here (with some tweaking) to get this stuff done. So I >would take a look at things like LineTo, Filling, Circles, etc. The >docs for the drawing functions are in dib_*.c. > >Stretching needs to be done, as well finish support for RLE >compression and proper checking for bitmaps recieved into the dib >engine. > >A task I will start very soon is forwarding to the display driver. >This will probably fix most of the regressions if it indeed works, but >it will slow the whatever bitmap operations down that go through the >dib engine that just foward back--this is okay for the time being >while this stuff gets written. > >If you want to start hacking on it, I would very appreciate it. I can >commit your patches to my tree and you will receive credit for your >work. I hope to get the driver into the tree someday soon, but only >when correct forwarding, bitmap support, and blitting is fully >supported. > >Jesse > > >-- >----- AlphaNet - najtaniej w sieci! -------- > Odnowienia domen w rewelacyjnych cenach! > .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl > http://www.domeny.alpha.pl >-------------------------------------------- > > > > I'll do what I can. However it's far too early to bother about my commits :) I'm trying to compare and understand the control flow of both drivers (winex11 and winedib). At which function in winex11 is copying data to/from server taking place? And in what function/file is the check for winedib driver availability done? Thanks Piotr -- ----- AlphaNet - najtaniej w sieci! -------- Odnowienia domen w rewelacyjnych cenach! .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl http://www.domeny.alpha.pl --------------------------------------------

Sept. 8, 2007

Re: settlers 3 and dib engine

by Jesse Allen

On 9/8/07, Skrzynka <skrzynka365(a)konto.pl> wrote: > I compiled winedib.drv but ExtTextOut function is missing there > and overall there are regressions visible when running Settlers 3 (wrong > colors, no text at all). Oh, it would be quite nice if you use this "test app" and document the missing and incorrect functionality. Don't open bug reports, just send the info straight to me. This will give me info on what things are most important for an app like this. Jesse

Sept. 8, 2007

Re: Would like to contribute to wine

by Detlef Riekenberg

On Di, 2007-09-04 at 08:17 +0200, Maciej Kowalczyk wrote: > I'm looking for subject for my Master's thesis. It might be interesting to > do something useful for Wine. Welcome to wine. > On this year's Google SoC I found an interesting application called > "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from > wine)". > It was accepted but I can't find any information about any progress. It works, but the code is not ready for the wine-tree yet. The final solution must work with CreateDC("winspool",....) and need the complete DIB-Engine. Marcel is still working to improve his code and will start sending patches. > I think it is doable because Windows 2000 and later printer drivers are > work in user-space. Yes, that's exactly what will be supported. > In suse repository I found ddiwrapper package. It does something similar > but only for some Canon drivers and wraps to use by CUPS. ddiwrapper use ghostscript to convert Postscript to a Bitmap and the Windows Printer Driver in a modified wine ("gdi32.dll" and "winspool.drv" where replaced) to print the Bitmap. > Or maybe you have other ideas? There are a lot of things in wine, that are missing and need a lot of work. The new Printing-Dialog (File/Print in Internet Explorer) for example is called as PrintDlgExA/W in "comdlg32.dll", but the "General" Propertysheet is located in "printui.dll" and the Application and the Driver can add / change Propertysheets. The Propertysheets need many Features (Functions / Resources / Custom controls) from "compstui.dll". In wine we have: -comdlg32.dll: PrintDlgEx is a stub -printui.dll: Only commandline-parsing for a different part of printui -compstui.dll: Empty stub I have no Idea what is needed / expected for the Master's thesis (complexity, amount of work). -- By by ... Detlef

Sept. 8, 2007

Re: settlers 3 and dib engine

by Jesse Allen

On 9/8/07, Skrzynka <skrzynka365(a)konto.pl> wrote: > Hi, > I'm trying to get Settlers 3 to run on Wine. After fixing some race > condition (seems like the thread calling WaitForXXXObject was giving up > time-slice too early after the call) it seems that the only problem left > is very slow text output. What I could understand from the forum > archives is that with no DIB engine, the rendering into a DC causes > copying of the bitmap to/from server (is that correct?). I'd like to > contribute to the DIB engine if it's possible/needed, so I'd like to ask > about a few things. There were some discussion recently about an > implementation of DIB engine by Jesse Allen - what is the status of DIB > engine? I compiled winedib.drv but ExtTextOut function is missing there > and overall there are regressions visible when running Settlers 3 (wrong > colors, no text at all). Which docs/urls/sources would you recommend to > read to get some quick introduction to the DIB engine? Which particular > functions are making current impl slow? Or, in general: where to start? > Sorry for any silly questions... > Thanks & regards > Piotr > Hello, Yes ExtTextOut will probably need to be implemented, as well as whatever family of functions that might go with it. There might be some cooperation necessary with the display driver here I don't know. You're pretty much on your own right now if you go there, as you'll need to figure out how to do everything. A simpler project might be to implement the drawing algorithms in graphics.c. It needs to be done, and I do believe I have enough infrastructure here (with some tweaking) to get this stuff done. So I would take a look at things like LineTo, Filling, Circles, etc. The docs for the drawing functions are in dib_*.c. Stretching needs to be done, as well finish support for RLE compression and proper checking for bitmaps recieved into the dib engine. A task I will start very soon is forwarding to the display driver. This will probably fix most of the regressions if it indeed works, but it will slow the whatever bitmap operations down that go through the dib engine that just foward back--this is okay for the time being while this stuff gets written. If you want to start hacking on it, I would very appreciate it. I can commit your patches to my tree and you will receive credit for your work. I hope to get the driver into the tree someday soon, but only when correct forwarding, bitmap support, and blitting is fully supported. Jesse

Sept. 8, 2007

settlers 3 and dib engine

by Skrzynka

Hi, I'm trying to get Settlers 3 to run on Wine. After fixing some race condition (seems like the thread calling WaitForXXXObject was giving up time-slice too early after the call) it seems that the only problem left is very slow text output. What I could understand from the forum archives is that with no DIB engine, the rendering into a DC causes copying of the bitmap to/from server (is that correct?). I'd like to contribute to the DIB engine if it's possible/needed, so I'd like to ask about a few things. There were some discussion recently about an implementation of DIB engine by Jesse Allen - what is the status of DIB engine? I compiled winedib.drv but ExtTextOut function is missing there and overall there are regressions visible when running Settlers 3 (wrong colors, no text at all). Which docs/urls/sources would you recommend to read to get some quick introduction to the DIB engine? Which particular functions are making current impl slow? Or, in general: where to start? Sorry for any silly questions... Thanks & regards Piotr -- ----- AlphaNet - najtaniej w sieci! -------- Odnowienia domen w rewelacyjnych cenach! .pl - 65 zl, .com.pl - 50 zl, reg - 20 zl http://www.domeny.alpha.pl --------------------------------------------

Sept. 8, 2007

Re: gdi32: return the correct font type, ntmFlags and PitchAndFamily for Type1 fonts (fixes bug #5877)

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > As I wrote in Bugzilla for Photoshop to work with Type1 fonts after > applying this patch one needs to reinstall Photoshop in a clean > wineprefix - it seems that Photoshop caches some font data. > + /* check for the presence of the 'CFF ' table to check if the font is Type1 */ > + tmp_size = 0; > + if (pFT_Load_Sfnt_Table && !pFT_Load_Sfnt_Table(ft_face, 0x43464620, 0, NULL, &tmp_size)) > + { > + TRACE("Font %s/%p is OTF Type1\n", wine_dbgstr_a(file), font_data_ptr); > + face->ntmFlags = NTM_PS_OPENTYPE; > + } Please use a symbolic name instead of 0x43464620. FreeType provides TTAG_CFF, or you can define it on your own using FT_MAKE_TAG. -- Dmitry.

Sept. 7, 2007

Re: Kudos - Fireworks 8 working better...

by Nemes Ioan Sorin

I told that for weeks - I really believe that speed on Fireworks are better under Linux using wine than XP. I suspect Dreamweaver to use ~ 90% from it's original speed. Also XnView works as in Windows (except I can not open files by dragging them to Xnview Icon) - last XnView work without any ..any problem I can do ALL operations like before. Dan Kegel wrote: > http://www.5thpercentile.com/devBlog/archives/2007/09/wine_just_got_t.html > and > http://appdb.winehq.org/appview.php?iVersionId=4149&iTestingId=15163 > both say that wine-0.9.44 really improves Adobe Fireworks. > Yay! > - Dan >

Sept. 7, 2007

Re: wined3d: add WINED3DPRESENT_INTERVAL_ONE flag (fix bug 9584)

by Stefan Dösinger

Am Freitag, 7. September 2007 18:29:02 schrieb Louis. Lenders: > I added this initially as a hack to get mame running, but what i understood > from discussion on IRC, there's no way we can check the graphics card's for > this capability now, and adding it as default (so without checking) would > be rather harmless. Short answer: Patch is ok with me Long answer: We can check if opengl supports vsync(which is what this flag does). WineD3D implements vsync using GLX_SGI_video_sync. So if this extension is supported, we should set the flag. If it is not supported, do not set it. Our WGL implementation does not forward the GLX extension yet, so we do not support vsync at the moment, so setting this flag means essentially lying to the app. However, I think it is safe to pretend vsync support. The worst that may happen is that the game renders with a higher framerate, and the hardware consumes more power instead of beeing idle. I think both cases are better then not running the game at all. There's one game which runs into internal race conditions if vsync does not work(need for speed 3), but that game doesn't even care to check that flag.

Sept. 7, 2007

build problem on amd64

by Dave Phillips

Greetings, I hope I have the right list. I'm trying to build Wine 0.9.44 under 64Studio, a Debian-based distribution. CPU is an AMD64, GCC is 4.1.2. Configure and make depend report no errors (btw, I ran a simple ./configure, no options), but when I run make I receive these errors : gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -D__i386__ -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:38: Error: suffix or operands invalid for `push' {standard input}:39: Error: suffix or operands invalid for `push' {standard input}:46: Error: suffix or operands invalid for `pop' {standard input}:47: Error: suffix or operands invalid for `pop' make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/dlphilp/src/wine-0.9.44/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/dlphilp/src/wine-0.9.44/libs' make: *** [libs] Error 2 Is there a fix for this problem ? Please advise, thanks. Best regards, Dave Phillips

Sept. 7, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> wrote: >> Again StrCpyNW is a shlwapi export, and since you just allocated the buffer >> of correct length memcpy + adding an explicit '\0' terminator look more >> naturally here (if not kernel32.lstrcpynW). > > I'm allowed to use memcpy? Isn't that a native Linux function? If Wine wouldn't be able to call native Linux APIs how it would work at all? >> You are still not checking SHCreateDirectoryExW return value. > > Nope. If SHCreateDirectoryExW returns ERROR_ALREADY_EXISTS, I need to > return HRESULT_FROM_WIN32(ERROR_DIRECTORY) or S_OK, depending on > whether it is a file or a directory. I already pointed out that there is no such a test to show correct behaviour of SHCreateDirectoryExW in that case. If you claim that there is inconsistency you need to add a test case for it. > And since I'd need to free > temppath if and only if I'm returning early, I think that any way I > could do that would make the code awkward/confusing. I don't think that handling errors makes the code confusing. If SHCreateDirectoryExW fails you can skip a fairly slow GetFileAttributesW call, and that's another advantage. >> There is no need to check temppath for NULL before HeapFree call. > > Oh. MSDN says there is. Not that I trust MSDN.. Even there is a janitorial task in Wine to remove NULL checks before HeapFree calls. -- Dmitry.

Sept. 7, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Kuba Ober

> > Again StrCpyNW is a shlwapi export, and since you just allocated the > > buffer of correct length memcpy + adding an explicit '\0' terminator look > > more naturally here (if not kernel32.lstrcpynW). > > I'm allowed to use memcpy? Isn't that a native Linux function? It's a C library function. Got nothing to do with Linux. Cheers, Kuba

Sept. 7, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Vincent Povirk

> You are still using a buffer of a fixed size. Whoops, didn't think about that one. > StrRChrW is a shlwapi export. Since shlwapi.dll is just mostly a wrapper/helper, > and it imports shell32, that would create a circular dependency. I already > suggested to use strrchrW here. Um, ok. I didn't realize there were two different functions. I only was able to find documentation on StrRChrW. There is indeed a circular dependency (which I wouldn't have noticed), apparently because shell32 needs to export StrRChrW. > Again StrCpyNW is a shlwapi export, and since you just allocated the buffer > of correct length memcpy + adding an explicit '\0' terminator look more > naturally here (if not kernel32.lstrcpynW). I'm allowed to use memcpy? Isn't that a native Linux function? > You are still not checking SHCreateDirectoryExW return value. Nope. If SHCreateDirectoryExW returns ERROR_ALREADY_EXISTS, I need to return HRESULT_FROM_WIN32(ERROR_DIRECTORY) or S_OK, depending on whether it is a file or a directory. And since I'd need to free temppath if and only if I'm returning early, I think that any way I could do that would make the code awkward/confusing. > There is no need to check temppath for NULL before HeapFree call. Oh. MSDN says there is. Not that I trust MSDN.. -- Vincent Povirk

Sept. 7, 2007

Re: nhelp, Vector NTI, molecular biologists

by Jakob Eriksson

Francois Gouget wrote: > Uwe Bonnes wrote: > [...] >> Missing MFC42 and other redistributable DLLs is a showstopper for >> winelib >> and running windows code on non i386 archtecture... > > Well, not quite. If you're going to use Winelib it means that you have > the source of the application. And if it is using the MFC it should > mean that you have a Visual Studio license, and thus the MFC sources > (though maybe that's only in the 'Pro' edition or some such). So then > you should be able to recompile the MFC using Winelib. That's exactly > what I did five years or so ago. I had to trim quite a few things but > got something that was somewhat usable. I did not pursue it further > though. > > Modern day MFC probably changed a bit (did it really change much?), > but then Winelib should be much better too. The real issue is the > license. In the Visual Studio 6 era, it seemed like it was legal to > redistribute the MFC dll with your non-trivial application, with no > mention of the platform. This might have changed since, and in any > case that's something you'd want to check with a lawyer. > > In Visual Studio 6 it was allowed. In Visual C++ .net, it says not only "only in object code form" and together with a product that "adds significant and primary functionality to the Redistributables", but also: "Redistributables only operate in conjunction with Microsoft Windows platforms". I believe this is a direct response to Wine being rather useful. Also, end users may not distribute the Redistributable further. (Of course, programs developed with Visual C++ .net may still be distributed, but this license covers Microsofts copyrights on their redistributables.) regards, Jakob

Sept. 7, 2007

Re: nhelp, Vector NTI, molecular biologists

by Francois Gouget

Uwe Bonnes wrote: [...] > Missing MFC42 and other redistributable DLLs is a showstopper for winelib > and running windows code on non i386 archtecture... Well, not quite. If you're going to use Winelib it means that you have the source of the application. And if it is using the MFC it should mean that you have a Visual Studio license, and thus the MFC sources (though maybe that's only in the 'Pro' edition or some such). So then you should be able to recompile the MFC using Winelib. That's exactly what I did five years or so ago. I had to trim quite a few things but got something that was somewhat usable. I did not pursue it further though. Modern day MFC probably changed a bit (did it really change much?), but then Winelib should be much better too. The real issue is the license. In the Visual Studio 6 era, it seemed like it was legal to redistribute the MFC dll with your non-trivial application, with no mention of the platform. This might have changed since, and in any case that's something you'd want to check with a lawyer. -- Francois Gouget fgouget(a)codeweavers.com

Sept. 7, 2007

Re: ddraw/tests: Check deviceGUID of enumerated devices.

by Stefan Dösinger

Am Freitag, 7. September 2007 02:44:32 schrieb David Hedberg: > Ah, I thought this was going a bit too well ;) I'll fix the issues and > send it in again. Regarding a fix, would something as simple as the > following be acceptable? > > (in dlls/ddraw/direct3d.c) > > @@ -263,6 +263,12 @@ IDirect3DImpl_7_EnumDevices(IDirect3D7 *iface, > return hr; > } > Callback(interface_name, device_name, &ddesc, Context); > + > + ddesc.deviceGUID = IID_IDirect3DHALDevice; > + Callback(interface_name, device_name, &ddesc, Context); > + > + ddesc.deviceGUID = IID_IDirect3DRGBDevice; > + Callback(interface_name, device_name, &ddesc, Context); You should set the right interface and device name string too.

Sept. 7, 2007

Re: nhelp, Vector NTI, molecular biologists

by Stefan Dösinger

Am Freitag, 7. September 2007 10:05:25 schrieb Uwe Bonnes: > Missing MFC42 and other redistributable DLLs is a showstopper for winelib > and running windows code on non i386 archtecture... I think you can compile MFC42 for winelib and other architectures, the source code is publically accessible(shipped with visual studio). It is a bit tricky, and you have to get the license right, but there is a HOWTO somewhere on the wine website and it should work.

Sept. 7, 2007

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: >>>> Then there is no point in using FreeType for loading font files at all, >>>> (or adding support for new font file formats to FreeType) since >>>> FreeType >>>> can load fonts from memory. >>> Do you mean that in AddFontResource I shouldn't try to call >>> WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work >>> as at least according to MSDN the parameter to AddFontResource can be >>> a FNT file or a Win16 NE executable) or that in AddFileToList I >>> should not make a distinction between memory and file fonts but >>> always load the font from memory, mmaping it before if necessary? >> I mean that we should choose from either leaving the task to FreeType, >> or doing the whole job of loading the font files internally in Wine. > I admit I don't understand - what would we gain from doing all the > loading internally in Wine? Wouldn't that be simply rewriting a big part > of freetype? That's exactly my point. We shouldn't add workarounds for deficiencies in FreeType, especially since FreeType now handles fonts in PE format. > You wrote that loading fonts from memory will help but > isn't FT_New_Memory_Face using the same parsing code as FT_New_Face and > only the source differs? Anyhow it looks to me as something rather > orthogonal to this patch as I don't try to parse the content of the font > but only remove the PE "wrapping". We don't we do that for other font formats, what's so special about PE, that Wine can handle it? But Wine can handle NE format as well, and there are older FreeType versions that can't handle NE fonts either. If that's just a worlaround for Photoshop's (because "many programs" that you mention your patch helps is so much vague, and while searching for fonts in PE fomat to test my FreeType patch I haven't found anything except Photoshop, so I had to create a sample font set in PE format on my own) Z-order problem during startup then your fix is in wrong area, you need to fix Z-order bug instead. -- Dmitry.

Sept. 7, 2007

re: nhelp, Vector NTI, molecular biologists

by Uwe Bonnes

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> Misha wrote: >> and even my version of Windows 98 is bundled with mfc42.dll, so wine >> really should provide it too... [our own version, not Microsoft's.] Dan> Well, sure. Same goes for a lot of things. But since mfc42.dll is Dan> a Visual C++ runtime file that has very liberal redistribution Dan> terms and is in fact bundled with many apps, we can get away Dan> without it for a long time. And it's not currently a showstopper Dan> as far as I can tell; I'm more interested in the bugs that keep Dan> e.g. Photoshop from running flawlessly. Dan> So one of these days it might become a priority. Until then, it's Dan> merely important but not urgent. - Dan Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 7, 2007

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources

by Mikołaj Zalewski

Dmitry Timoshkov pisze: > "Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > >>> Then there is no point in using FreeType for loading font files at all, >>> (or adding support for new font file formats to FreeType) since >>> FreeType >>> can load fonts from memory. >> Do you mean that in AddFontResource I shouldn't try to call >> WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work >> as at least according to MSDN the parameter to AddFontResource can be >> a FNT file or a Win16 NE executable) or that in AddFileToList I >> should not make a distinction between memory and file fonts but >> always load the font from memory, mmaping it before if necessary? > I mean that we should choose from either leaving the task to FreeType, > or doing the whole job of loading the font files internally in Wine. I admit I don't understand - what would we gain from doing all the loading internally in Wine? Wouldn't that be simply rewriting a big part of freetype? You wrote that loading fonts from memory will help but isn't FT_New_Memory_Face using the same parsing code as FT_New_Face and only the source differs? Anyhow it looks to me as something rather orthogonal to this patch as I don't try to parse the content of the font but only remove the PE "wrapping". Mikolaj Zalewski

Sept. 7, 2007

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: >> Then there is no point in using FreeType for loading font files at all, >> (or adding support for new font file formats to FreeType) since FreeType >> can load fonts from memory. > Do you mean that in AddFontResource I shouldn't try to call > WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work as > at least according to MSDN the parameter to AddFontResource can be a FNT > file or a Win16 NE executable) or that in AddFileToList I should not > make a distinction between memory and file fonts but always load the > font from memory, mmaping it before if necessary? I mean that we should choose from either leaving the task to FreeType, or doing the whole job of loading the font files internally in Wine. -- Dmitry.

Sept. 7, 2007

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources

by Mikołaj Zalewski

> Then there is no point in using FreeType for loading font files at all, > (or adding support for new font file formats to FreeType) since FreeType > can load fonts from memory. Do you mean that in AddFontResource I shouldn't try to call WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work as at least according to MSDN the parameter to AddFontResource can be a FNT file or a Win16 NE executable) or that in AddFileToList I should not make a distinction between memory and file fonts but always load the font from memory, mmaping it before if necessary? > This code snippet causes a stack corruption since load_enumed_resource > has > wrong calling convention. I wonder whether gcc issued a warning here. Thanks for catching it. I haven't noticed a warning but I think there should have been one. Mikolaj Zalewski

Sept. 7, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd(a)gmail.com> wrote: > fixes bug 9523, Knytt Stories installer fails > +/*********************************************************************** > + * SHPathPrepareForWriteA (SHELL32.@) > + */ > +HRESULT WINAPI SHPathPrepareForWriteA(HWND hwnd, IUnknown *modless, LPCSTR path, DWORD flags) > +{ > + WCHAR wpath[MAX_PATH]; > + MultiByteToWideChar( CP_ACP, 0, path, -1, wpath, MAX_PATH); > + return SHPathPrepareForWriteW(hwnd, modless, wpath, flags); You are still using a buffer of a fixed size. > + /* cut off filename if necessary */ > + if (flags & SHPPFW_IGNOREFILENAME) > + { > + last_slash = StrRChrW(path, NULL, '\\'); StrRChrW is a shlwapi export. Since shlwapi.dll is just mostly a wrapper/helper, and it imports shell32, that would create a circular dependency. I already suggested to use strrchrW here. > + temppath = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!temppath) > + return E_OUTOFMEMORY; > + StrCpyNW(temppath, path, len); Again StrCpyNW is a shlwapi export, and since you just allocated the buffer of correct length memcpy + adding an explicit '\0' terminator look more naturally here (if not kernel32.lstrcpynW). > + /* try to create the directory if asked to */ > + if (flags & (SHPPFW_DIRCREATE|SHPPFW_ASKDIRCREATE)) > + { > + if (flags & SHPPFW_ASKDIRCREATE) > + FIXME("treating SHPPFW_ASKDIRCREATE as SHPPFW_DIRCREATE\n"); > + > + SHCreateDirectoryExW(0, realpath, NULL); > + } You are still not checking SHCreateDirectoryExW return value. > + if (temppath) > + HeapFree(GetProcessHeap(), 0, temppath); There is no need to check temppath for NULL before HeapFree call. -- Dmitry.

Sept. 6, 2007

Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped asPE resources

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolajz(a)google.com> wrote: > This is some overlap with freetype as freetype 2.3.5 can load fonts > from PE resources. But the code is so small (we have all the tools > needed) and helps many programs (including working around the > Photoshop Z-order problem during startup as now the dialogs doesn't > show) that I thought it is useful. Then there is no point in using FreeType for loading font files at all, (or adding support for new font file formats to FreeType) since FreeType can load fonts from memory. > + TRACE("WineEndAddFontResourceEx failed on PE file %s - trying to load resources manualy\n", > + wine_dbgstr_w(str)); > + if (EnumResourceNamesW(hModule, rt_font, load_enumed_resource, (LONG_PTR)&num_resources)) This code snippet causes a stack corruption since load_enumed_resource has wrong calling convention. I wonder whether gcc issued a warning here. -- Dmitry.

Sept. 6, 2007