December 2008 - Wine-Devel - list.winehq.org

Re: explorer: improve ABM_GETTASKBARPOS stub

by Vincent Povirk

> You know, there is the only one way to figure it out: write a test case. That's not the answer to everything, you know. If I have a windows machine that does not have a taskbar, I can call SHAppBarMessage to see how I should report this to the app. But how do I get a windows machine without a taskbar?

Dec. 8, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > Does returning FALSE mean there's no taskbar? I have no idea. I can > think of only a few reasons the taskbar might be missing from Windows > machine that has an SHAppBarMessage implementation: > * explorer.exe is not running. > * You're using Windows NT 3.51. (MSDN isn't entirely consistent on the > question of whether SHAppBarMessage exists there, but I don't think it > had a taskbar.) > * You're using a shell replacement. (I don't know how those work.) You know, there is the only one way to figure it out: write a test case. -- Dmitry.

Dec. 8, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Vincent Povirk

>> 3. If workarea == screen rect, lie. > > No, report that there is no a taskbar. > There's no clean way to do that. The MSDN documentation for ABM_GETTASKBARPOS says that it returns a bounding rectangle for the taskbar and a boolean. MSDN gives no indication of what the boolean result means, but under normal circumstances it is TRUE. This is the "old" implementation: http://source.winehq.org/source/dlls/shell32/shell32_main.c?v=wine-1.0.1#L8… In general, the old implementation had no correlation to what the function was actually meant to do, so I replaced it with stubs before doing a proper implementation. Now ABM_GETTASKBARPOS always returns FALSE: http://source.winehq.org/source/programs/explorer/appbar.c#L196 Does returning FALSE mean there's no taskbar? I have no idea. I can think of only a few reasons the taskbar might be missing from Windows machine that has an SHAppBarMessage implementation: * explorer.exe is not running. * You're using Windows NT 3.51. (MSDN isn't entirely consistent on the question of whether SHAppBarMessage exists there, but I don't think it had a taskbar.) * You're using a shell replacement. (I don't know how those work.) It's perfectly reasonable for developers to write programs that function in none of those circumstances for current versions of Windows. Effectively, reporting that there is no taskbar could be a serious error. >> That will often be wrong, and there's no clear benefit to doing that >> over lieing consistently. The one program I know of that relies on >> ABM_GETTASKBARPOS, rapid uploader, apparently worked fine when it was >> an alias of GetWindowRect (which is completely braindead). I cannot >> think of any legitimate use for the information returned by this api. > > Then there is no point in sending such an "improvement". > There is. It will make rapid uploader work again.

Dec. 8, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > I'll assume you mean something like this: > > 1. Look for a difference between the workarea bottom and the screen > bottom. If there is one, assume the taskbar is there. > 2. Check the other sides similarly. Yes, I ment something like that. > 3. If workarea == screen rect, lie. No, report that there is no a taskbar. > That will often be wrong, and there's no clear benefit to doing that > over lieing consistently. The one program I know of that relies on > ABM_GETTASKBARPOS, rapid uploader, apparently worked fine when it was > an alias of GetWindowRect (which is completely braindead). I cannot > think of any legitimate use for the information returned by this api. Then there is no point in sending such an "improvement". -- Dmitry.

Dec. 8, 2008

Re: WineHQ - web development and graphics help

by Andrew Fenn

> I am interested in working on the WINE website. I am an 18 years old > pre-med student currently employed as a web dev and graphics designer > in a small company. You should check out the mailing list last month. A new design is already being worked on.

Dec. 8, 2008

WineHQ - web development and graphics help

by Guillaume Pelletier

To whom it may concern, Hello! I am interested in working on the WINE website. I am an 18 years old pre-med student currently employed as a web dev and graphics designer in a small company. I was thinking of making a few aesthetic changes to the current WINE website. I am also skilled at graphics, and I think some of the graphical elements could be polished. If I could help out in any way, or if you would like to see samples of my recent work, please let me know. Sincerely, Guillaume Pelletier

Dec. 8, 2008

Re: oleaut32: Fix OleLoadPicturePath behavior on wrong path (bug 14710)

by Nikolay Sivov

Jeremy Drake wrote: > On Sun, 7 Dec 2008, Nikolay Sivov wrote: > > >> Changelog: >> - fix OleLoadPicturePath behavior on wrong path >> - some cosmetic changes on module and test (spaces, tabs, ..) >> > > Cool, this is related to what I was trying to get done. Please take a > look at the more complete tests for OleLoadPicutrePath I wrote that have > not been applied yet, and perhaps we both can get our patches in. I ran > them against several Windows versions, and I think they do not agree 100% > with your tests. > > http://www.winehq.org/pipermail/wine-patches/2008-November/064929.html > > Thanks, > Jeremy > > They're similar. Actually I tried to use relative path --- static WCHAR path[] = {'N','O','.','B','M','P',0}; --- and INET_E_UNKNOWN_PROTOCOL was returned. And you always use full path. This passes on WinXP SP2 so you could include this case to yours.

Dec. 7, 2008

Re: oleaut32: Fix OleLoadPicturePath behavior on wrong path (bug 14710)

by Jeremy Drake

On Sun, 7 Dec 2008, Nikolay Sivov wrote: > Changelog: > - fix OleLoadPicturePath behavior on wrong path > - some cosmetic changes on module and test (spaces, tabs, ..) Cool, this is related to what I was trying to get done. Please take a look at the more complete tests for OleLoadPicutrePath I wrote that have not been applied yet, and perhaps we both can get our patches in. I ran them against several Windows versions, and I think they do not agree 100% with your tests. http://www.winehq.org/pipermail/wine-patches/2008-November/064929.html Thanks, Jeremy

Dec. 7, 2008

comdlg32: includeobject needs to notify window with CDN_INCLUDEITEM

by ricardo filipe

this is related to http://bugs.winehq.org/show_bug.cgi?id=8072 so... i decided to investigate why didn't media player classic show the files when browsing... i've been debugging this for some days but found the problem, although it's not quite solved, so if anyone has any idea please share. the good thing was that mpc source code is available so i could see how it was implemented. i found out that includeObject is supposed to notify the browsing window with CDN_INCLUDEITEM that wasn't yet declared in wine. the problem is that i get: err:pidl:_ILSimpleGetTextW -- no text err:pidl:_ILSimpleGetTextW -- no text trace:commdlg:SendCustomDlgNotificationMessage RET NOTIFY trace:commdlg:SendCustomDlgNotificationMessage Retval: 0x00000000 and the notify isn't successful :\ any ideas? patch in attachment... _________________________________________________________________ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/

Dec. 7, 2008

winecfg: Updated Swedish translation

by Daniel Nylander

Dec. 7, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Vincent Povirk

I'll assume you mean something like this: 1. Look for a difference between the workarea bottom and the screen bottom. If there is one, assume the taskbar is there. 2. Check the other sides similarly. 3. If workarea == screen rect, lie. That will often be wrong, and there's no clear benefit to doing that over lieing consistently. The one program I know of that relies on ABM_GETTASKBARPOS, rapid uploader, apparently worked fine when it was an alias of GetWindowRect (which is completely braindead). I cannot think of any legitimate use for the information returned by this api. Vincent Povirk

Dec. 7, 2008

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.

by Jérôme Gardou

Jérôme Gardou a écrit : > Henri Verbeet a écrit : > >> 2008/12/6 Jérôme Gardou <jerome.gardou(a)gmail.com>: >> >> >>> According to d3d9_private.h , ref is a LONG. >>> >>> >>> >> ref is not defined in d3d9_private.h. >> >> > Taken from d3d9_private.h : > > typedef struct IDirect3DDevice9Impl > { > /* IUnknown fields */ > const IDirect3DDevice9ExVtbl *lpVtbl; > LONG ref; > ... > > That's why the compiler did not complained... But release actually > returns a ULONG, and the IUnknown ref is an ULONG anyway... > I guess this should be changed for consistency. > > > Oh dear... I upgraded my winXP VM to SP3 yesterday, and the tests I wrote now crash... seems like d3d9 does not care about threads anymore...

Dec. 7, 2008

Wrong SP definition in wine.inf.in

by Mirek Slugeň

Hi, Windows XP doesn't have Service Pack 4, this is bug from rewrite of default OS from Windows 2000 (which has SP 4) to Windows XP. This patch should fix wrong SP definition when creating new .wine tree. Mirek Slugen

Dec. 7, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > Implement what? > > Linux doesn't have any concept of this "taskbar" thing. (Please bottom post). You can make a good guess where taskbar(s) present using monitor info. -- Dmitry.

Dec. 7, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Vincent Povirk

Implement what? Linux doesn't have any concept of this "taskbar" thing. Vincent Povirk On Sat, Dec 6, 2008 at 10:36 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > >> Fixes http://bugs.winehq.org/show_bug.cgi?id=15835 > > That's not hard to implement this properly using monitor info. > > -- > Dmitry. >

Dec. 7, 2008

Re: explorer: improve ABM_GETTASKBARPOS stub

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > Fixes http://bugs.winehq.org/show_bug.cgi?id=15835 That's not hard to implement this properly using monitor info. -- Dmitry.

Dec. 7, 2008

Wine translation statistics sources

by Mikołaj Zalewski

Hi, I didn't update the translation statistics (http://www.mikolaj.zalewski.pl/wine-transl/) very regularly lately - my server is a bit broken and I can't run the scripts from cron but have remember to do it manually from a different computer. I have plans to fix it, but in the mean time, as some people may want fresh data, I have finished the changes I've been working on and uploaded the sources. It should be very easy to run them on ones machine and check the tree one has on disk - there is a README with explanations. The archive is available at http://www.mikolaj.zalewski.pl/dl/wine-transl.tgz . It is the latest version that adds support for dumping/diffing dialogs. Mikolaj Zalewski

Dec. 7, 2008

Use show instead of glyphshow because glyphshow is very slow on kyocera

by Wolfgang Walter

Hello, this is is a proposed change to the wineps driver. Problem: wine uses the postscript command glyphshow to print characters. At least all Postscript Printers from Kyocera are very slow when showglyph is used. Even simple pages with only one downloaded truetype font slow down fast printers as the Kyocera FS-4000DN or FS-9520DN so that they print not more then 3 pages/minute - often only one to two. I can only speculate why glyphshow is such bad for performance. The generic windows postscript printer driver does usually not use showglyph. Nor do the driver from Kyocera. Applications as OpenOffice don't do either. The following patch changes wineps.drv such that it uses show (for downloaded truetype fonts). It still contains code which inserts postscript comments in its output for debugging purpose. It's meant for discussion. Regards, Wolfgang Walter -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München >From e3cfd6d376bb397f8378fe65127496d7b30b4826 Mon Sep 17 00:00:00 2001 From: Wolfgang Walter <wine(a)stwm.de> Date: Sat, 6 Dec 2008 17:43:35 +0100 Subject: Use show instead of glyphshow On many postscript printers glyphshow is slow. Especially all Kyocera models from FS-1020 up to FS-4000DN or FS-9520DN are very slow when glyphshow is used with downloaded truetype fonts. Even simple text-only pages are rendered at 1/6 to 1/10 of the usual time (i.e. reached under windows with the generic window postscript driver). I don't know why glyphshow is slow but I suppose that its usage is not optimised as the eneric windows postscript printer driver seems not to use glyphshow. Nor do the driver from Kyocera. Applications as OpenOffice don't do either. This change modifies wineps.drv such that it uses show for downloaded fonts as other the window printer drivers do. Show accesses glyphs of base fonts by there character code in the encoding array of the font. Only 256 glyphs may be encoded. Therefor I clone the font if necessary. As the clones share all resources but their encoding array with the original font this is not expensive. Actually I limit the number of clones (by undefining older ones) but it's probably not worth the code: * the gylphs themselves are the really expensive part * all fonts are released when a page is rendered I had to modify how font setting works as I have to set the clone with the correct encoding for each character. With this modification printing perfomance is up to what one would expect. I tested this on several Kyocera laser printers (FS-1010, FS-1030, FS-1300, FS-C5025, FS-4000DN, FS-9520DN) and also on a HP Laserjet and a Minolta Laserprinter. And of course with ghostscript. This patch still contains code which creates comments in the generated postscript file for debugging purpose. --- dlls/wineps.drv/download.c | 337 +++++++++++++++++++++++++++++++++++++++----- dlls/wineps.drv/font.c | 4 +- dlls/wineps.drv/ps.c | 14 ++ dlls/wineps.drv/psdrv.h | 16 ++ dlls/wineps.drv/type1.c | 27 +--- dlls/wineps.drv/type42.c | 27 +--- 6 files changed, 347 insertions(+), 78 deletions(-) diff --git a/dlls/wineps.drv/download.c b/dlls/wineps.drv/download.c index e794af6..bd40ef0 100644 --- a/dlls/wineps.drv/download.c +++ b/dlls/wineps.drv/download.c @@ -42,6 +42,23 @@ WINE_DEFAULT_DEBUG_CHANNEL(psdrv); #define GET_BE_DWORD(ptr) ((DWORD)MAKELONG( GET_BE_WORD(&((WORD *)(ptr))[1]), \ GET_BE_WORD(&((WORD *)(ptr))[0]) )) +#define GLYPH_SENT_INC 128 +#define MAX_ENC_PER_FONT 16 /* must be <= 0xfe */ +#define OPT_ENC_PER_FONT 10 /* when we should start to undefine clones */ +#define MIN_ENC_PER_FONT 4 /* when we undefine: how agressive */ + +static const char fontname[] = "%s_wine_%04X"; +static const char undefinefont[] = "/%s_wine_%04X undefinefont\n"; +static const char setdeffont[] = "/%s findfont 40 scalefont setfont\n"; + + +#if DOWNLOAD_SPOOLBUF_MINPLUS <= 1000 +#error "DOWNLOAD_SPOOLBUF_MINPLUS must be greater then 1000" +#endif +#if MAX_ENC_PER_FONT > 0xfe +#error "MAX_ENC_PER_FONT must not exceed 0xfe" +#endif + /**************************************************************************** * get_download_name */ @@ -192,7 +209,7 @@ static BOOL get_bbox(PSDRV_PDEVICE *physDev, RECT *rc, UINT *emsize) */ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) { - char *ps_name; + char *ps_name = NULL; LPOUTLINETEXTMETRICA potm; DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); @@ -219,6 +236,44 @@ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) } /**************************************************************************** + * Download_WriteSetFont + * + * If <force> == TRUE or <g_enc> != pdl->glyph_enc_last_used: + * write postscript code to select the clone of font <pdl> + * where encoding g_enc is mapped as character code (<g_enc> & 0xff) + * + */ +static BOOL Download_WriteSetFont(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, + WORD g_enc, BOOL force) +{ + BOOL ret; + + UINT fontnr = (g_enc & 0xff00); + + if(!force && pdl->glyph_enc_last_used == fontnr) + return TRUE; + + sprintf(pdl->spoolbuf, fontname, pdl->ps_name, fontnr); + ret = PSDRV_WriteSetFont(physDev, pdl->spoolbuf, physDev->font.size, + physDev->font.escapement); + if (ret) + pdl->glyph_enc_last_used = fontnr; + + return ret; +} + +/**************************************************************************** + * Download_WriteUndefineFont + * + */ +static BOOL Download_WriteUndefineFont(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, + WORD fontnr) +{ + sprintf(pdl->spoolbuf, undefinefont, pdl->ps_name, fontnr); + return PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); +} + +/**************************************************************************** * PSDRV_WriteSetDownloadFont * * Write setfont for download font. @@ -226,24 +281,24 @@ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) */ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) { - char *ps_name; - LPOUTLINETEXTMETRICA potm; - DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); DOWNLOAD *pdl; assert(physDev->font.fontloc == Download); - potm = HeapAlloc(GetProcessHeap(), 0, len); - GetOutlineTextMetricsA(physDev->hdc, len, potm); - - get_download_name(physDev, potm, &ps_name); - if(physDev->font.fontinfo.Download == NULL) { + char *ps_name; + DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); + LPOUTLINETEXTMETRICA potm; RECT bbox; UINT emsize; + potm = HeapAlloc(GetProcessHeap(), 0, len); + GetOutlineTextMetricsA(physDev->hdc, len, potm); + get_download_name(physDev, potm, &ps_name); + if (!get_bbox(physDev, &bbox, &emsize)) { HeapFree(GetProcessHeap(), 0, potm); + HeapFree(GetProcessHeap(), 0, ps_name); return FALSE; } if(!is_room_for_font(physDev)) @@ -254,6 +309,15 @@ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) strcpy(pdl->ps_name, ps_name); pdl->next = NULL; + pdl->spoolbuf_len = 2*strlen(ps_name) + DOWNLOAD_SPOOLBUF_MINPLUS; + pdl->spoolbuf = HeapAlloc(GetProcessHeap(), 0, pdl->spoolbuf_len); + pdl->glyph_sent_size = GLYPH_SENT_INC; + pdl->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + pdl->glyph_sent_size * sizeof(*(pdl->glyph_sent))); + pdl->glyph_enc_first_valid = 0x100; + pdl->glyph_enc_next_free = 0x100; + pdl->glyph_enc_last_used = 0; + if(physDev->pi->ppd->TTRasterizer == RO_Type42) { pdl->typeinfo.Type42 = T42_download_header(physDev, ps_name, &bbox, emsize); pdl->type = Type42; @@ -271,14 +335,18 @@ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) get_glyph_name(physDev->hdc, 0, g_name); T42_download_glyph(physDev, pdl, 0, g_name); } + HeapFree(GetProcessHeap(), 0, ps_name); + HeapFree(GetProcessHeap(), 0, potm); + PSDRV_WriteSpool(physDev, "% servus1a\n", strlen("% servus1a\n")); + } else { + PSDRV_WriteSpool(physDev, "% servus1a\n", strlen("% servus1b\n")); + pdl = physDev->font.fontinfo.Download; + assert(physDev->font.fontinfo.Download); } + PSDRV_WriteSpool(physDev, "% servus2\n", strlen("% servus1\n")); + Download_WriteSetFont(physDev, pdl, 0, TRUE); - PSDRV_WriteSetFont(physDev, ps_name, physDev->font.size, - physDev->font.escapement); - - HeapFree(GetProcessHeap(), 0, ps_name); - HeapFree(GetProcessHeap(), 0, potm); return TRUE; } @@ -289,6 +357,191 @@ void get_glyph_name(HDC hdc, WORD index, char *name) return; } +/* + * download_glyph + * + * Downloads the glyph <index> of font <pdl> if necessary and naming it + * <glyph_name>. + * + * Defines an encoding for <glyph_name>. + * + * As a base font in postscript may only have up to 256 entries it clones the + * font if necessary. The name of the font will be <pdl->ps_name>_wine_<XX>00 + * where 0x<XX>00 == <return value> & 0xff00 + * The character code is <return value> & 0xff + * + * If it fails it returns (<return value> & 0xffff) <= 0xff + * or in other words <XX> == 0. + * + * As font <pdl->ps_name>_wine_0000 always exists and every character code of + * it is mapped to .notdef you may ignore errors and print then the undefined + * symbol of the font. + * + * If you call download_glyph with <may_free_encs> = TRUE earlier encodings you + * got for this font may not be valid any more because download_glyph may + * undefine older clones when more than OPT_ENC_PER_FONT clones exist. + * + * As long as you call it with <may_free_encs> = FALSE older encodings beginning + * with the last call with <may_free_encs> = TRUE remain valid. + * But download_glyph will not make more then MAX_ENC_PER_FONT clones and may + * fail then with <return value> == 1 + * + * But you can be sure that + * If you got 0x<XX><YY> + * and you get next 0x<XX><ZZ> or 0x00<WW> + * then 0x<XX><YY> is still valid + * + */ +static WORD download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, + char *glyph_name, BOOL may_free_encs) +{ + DWORD encoding = 0; + DWORD first_valid; + DWORD next_free; + DWORD used; + BOOL ret; + + const char glyph_enc[] = + "/%s_wine_%04X findfont /Encoding get\n" + "dup %u /%s put\n" + "pop\n"; + + const char font_clone[] = + "/%s_wine_0000 findfont\n" + "dup length dict begin\n" + "{ 1 index /FID ne\n" + " {def} {pop pop} ifelse\n" + "} forall\n" + "/Encoding 256 array 0 1 255 {1 index exch /.notdef put} for def\n" + "currentdict\n" + "end\n" + "/%s_wine_%04X exch definefont pop\n"; + + TRACE("%d %s\n", index, glyph_name); + + first_valid = pdl->glyph_enc_first_valid; + next_free = pdl->glyph_enc_next_free; + assert(first_valid <= next_free); + assert( (first_valid & 0xff00) != 0); + + used = ((next_free - first_valid) & 0xff00)>>8; + if (next_free > 0xffff) + used--; + + if(index < pdl->glyph_sent_size) { + encoding = pdl->glyph_sent[index]; + assert(encoding < next_free); + if( encoding >= 0x100 && + ( first_valid <= encoding || first_valid < (next_free & 0x10000) + encoding)) + goto encset; + } + + if( used > MAX_ENC_PER_FONT && !may_free_encs) { + /* we need a new clone of the font but we must not create one */ + return 1; + } + + PSDRV_WriteSpool(physDev, "% hallo1\n", strlen("% hallo1\n")); + if(index >= pdl->glyph_sent_size) { + pdl->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; + pdl->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + pdl->glyph_sent, + pdl->glyph_sent_size * sizeof(*(pdl->glyph_sent))); + encoding = 0; + PSDRV_WriteSpool(physDev, "% hallo1a\n", strlen("% hallo1a\n")); + } + + PSDRV_WriteSpool(physDev, "% hallo2\n", strlen("% hallo2\n")); + if(!encoding) { + /* download glyph */ + switch(pdl->type) { + case Type42: + ret = T42_download_glyph(physDev, pdl, index, glyph_name); + break; + + case Type1: + ret = T1_download_glyph(physDev, pdl, index, glyph_name); + break; + + default: + ERR("Type = %d\n", pdl->type); + assert(0); + } + if (! ret) + return 0; + /* we never assign 0x0000 through 0x00ff as valid encoding. + * If we fail to assign a valid encoding later on we + * still know that we downloaded the glyph already and + * only need to assign an encoding. + */ + pdl->glyph_sent[index] = 1; + PSDRV_WriteSpool(physDev, "% hallo2c\n", strlen("% hallo2c\n")); + } + + PSDRV_WriteSpool(physDev, "% hallo3\n", strlen("% hallo3\n")); + if( (next_free & 0xff) == 0) { + PSDRV_WriteSpool(physDev, "% hallo3a\n", strlen("% hallo3a\n")); + /* we need a new clone of the font */ + if ( (next_free & 0xffff) == 0) { + /* we overflow: we must mark encodings < first_valid as + downloaded but unencoded */ + DWORD i; + for(i = 0; i < pdl->glyph_sent_size; i++) { + if (pdl->glyph_sent[i] < first_valid) + pdl->glyph_sent[i] = 1; + } + next_free += 0x100; + PSDRV_WriteSpool(physDev, "% hallo3b\n", strlen("% hallo3b\n")); + } + /* now clone the font */ + sprintf(pdl->spoolbuf, font_clone, pdl->ps_name, pdl->ps_name, next_free & 0xff00); + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + + /* reserve character 0 for .notdef */ + next_free++; + } + encoding = next_free++; + used++; + + PSDRV_WriteSpool(physDev, "% hallo4\n", strlen("% hallo4\n")); + pdl->glyph_enc_next_free = next_free; + pdl->glyph_sent[index] = encoding; + /* define encoding */ + sprintf(pdl->spoolbuf, glyph_enc, pdl->ps_name, + (encoding & 0xff00), (encoding & 0xff), glyph_name); + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + +encset: + PSDRV_WriteSpool(physDev, "% hallo5\n", strlen("% hallo5\n")); + if (used > OPT_ENC_PER_FONT && !may_free_encs) { + int i; + + PSDRV_WriteSpool(physDev, "% hallo5a\n", strlen("% hallo5a\n")); + Download_WriteSetFont(physDev, pdl, 0, TRUE); + + used += (next_free > 0xffff); + for(i = 0; i < used - MIN_ENC_PER_FONT; i++) { + DWORD fontnr = (first_valid & 0xff00); + if (fontnr == (encoding & 0xff00)) + break; + if (fontnr) + Download_WriteUndefineFont(physDev, pdl, fontnr); + first_valid += 0x100; + PSDRV_WriteSpool(physDev, "% hallo5b\n", strlen("% hallo5b\n")); + } + if (first_valid > 0xffff) { + first_valid = 0x100; + next_free &= 0xffff; + pdl->glyph_enc_next_free = next_free; + PSDRV_WriteSpool(physDev, "% hallo5c\n", strlen("% hallo5c\n")); + } + pdl->glyph_enc_first_valid = first_valid; + } + + PSDRV_WriteSpool(physDev, "% hallo6\n", strlen("% hallo6\n")); + return encoding; +} + /**************************************************************************** * PSDRV_WriteDownloadGlyphShow * @@ -298,36 +551,26 @@ void get_glyph_name(HDC hdc, WORD index, char *name) BOOL PSDRV_WriteDownloadGlyphShow(PSDRV_PDEVICE *physDev, WORD *glyphs, UINT count) { + DOWNLOAD *pdl; UINT i; char g_name[MAX_G_NAME + 1]; + DWORD g_enc; + assert(physDev->font.fontloc == Download); - switch(physDev->font.fontinfo.Download->type) { - case Type42: - for(i = 0; i < count; i++) { - get_glyph_name(physDev->hdc, glyphs[i], g_name); - T42_download_glyph(physDev, physDev->font.fontinfo.Download, - glyphs[i], g_name); - PSDRV_WriteGlyphShow(physDev, g_name); - } - break; + pdl = physDev->font.fontinfo.Download; + assert(pdl); - case Type1: for(i = 0; i < count; i++) { get_glyph_name(physDev->hdc, glyphs[i], g_name); - T1_download_glyph(physDev, physDev->font.fontinfo.Download, - glyphs[i], g_name); - PSDRV_WriteGlyphShow(physDev, g_name); - } - break; - - default: - ERR("Type = %d\n", physDev->font.fontinfo.Download->type); - assert(0); + g_enc = download_glyph(physDev, pdl, glyphs[i], g_name, TRUE) & 0xffff; + Download_WriteSetFont(physDev, pdl, g_enc, FALSE); + PSDRV_WriteShow1(physDev, (g_enc & 0xff)); } return TRUE; } + /**************************************************************************** * PSDRV_EmptyDownloadList * @@ -337,8 +580,7 @@ BOOL PSDRV_WriteDownloadGlyphShow(PSDRV_PDEVICE *physDev, WORD *glyphs, BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) { DOWNLOAD *pdl, *old; - static const char undef[] = "/%s findfont 40 scalefont setfont /%s undefinefont\n"; - char buf[sizeof(undef) + 200]; + const char *default_font = physDev->pi->ppd->DefaultFont ? physDev->pi->ppd->DefaultFont : "Courier"; @@ -349,11 +591,30 @@ BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) pdl = physDev->downloaded_fonts; physDev->downloaded_fonts = NULL; + + if (write_undef) { + pdl->spoolbuf[pdl->spoolbuf_len-1] = '\0'; + snprintf(pdl->spoolbuf, pdl->spoolbuf_len, setdeffont, default_font); + if (pdl->spoolbuf[pdl->spoolbuf_len-1]) { + default_font = "Courier"; + sprintf(pdl->spoolbuf, setdeffont, default_font); + } + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + } + while(pdl) { if(write_undef) { - sprintf(buf, undef, default_font, pdl->ps_name); - PSDRV_WriteSpool(physDev, buf, strlen(buf)); + DWORD i; + /* free derived fonts */ + for(i = pdl->glyph_enc_first_valid; i < pdl->glyph_enc_next_free; i += 0x0100) { + int fontnr = (i & 0xff00); + if (fontnr) { + Download_WriteUndefineFont(physDev, pdl, fontnr); + } + } + Download_WriteUndefineFont(physDev, pdl, 0); } + HeapFree(GetProcessHeap(), 0, pdl->glyph_sent); switch(pdl->type) { case Type42: @@ -370,6 +631,8 @@ BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) } HeapFree(GetProcessHeap(), 0, pdl->ps_name); + HeapFree(GetProcessHeap(), 0, pdl->glyph_sent); + HeapFree(GetProcessHeap(), 0, pdl->spoolbuf); old = pdl; pdl = pdl->next; HeapFree(GetProcessHeap(), 0, old); diff --git a/dlls/wineps.drv/font.c b/dlls/wineps.drv/font.c index 9e0ae39..1a6bf8e 100644 --- a/dlls/wineps.drv/font.c +++ b/dlls/wineps.drv/font.c @@ -125,11 +125,14 @@ HFONT PSDRV_SelectFont( PSDRV_PDEVICE *physDev, HFONT hfont, HANDLE gdiFont ) BOOL PSDRV_SetFont( PSDRV_PDEVICE *physDev ) { PSDRV_WriteSetColor(physDev, &physDev->font.color); + PSDRV_WriteSpool(physDev, "% salve1\n", strlen("% salve1\n")); if(physDev->font.set) return TRUE; + PSDRV_WriteSpool(physDev, "% salve2\n", strlen("% salve2\n")); switch(physDev->font.fontloc) { case Builtin: PSDRV_WriteSetBuiltinFont(physDev); + physDev->font.set = TRUE; break; case Download: PSDRV_WriteSetDownloadFont(physDev); @@ -139,6 +142,5 @@ BOOL PSDRV_SetFont( PSDRV_PDEVICE *physDev ) assert(1); break; } - physDev->font.set = TRUE; return TRUE; } diff --git a/dlls/wineps.drv/ps.c b/dlls/wineps.drv/ps.c index fdebf46..4d7769a 100644 --- a/dlls/wineps.drv/ps.c +++ b/dlls/wineps.drv/ps.c @@ -122,6 +122,9 @@ static const char psrrectangle[] = /* x, y, width, height, -width */ static const char psglyphshow[] = /* glyph name */ "/%s glyphshow\n"; +static const char psshow[] = /* encoding name */ +"<%02X> show\n"; + static const char pssetfont[] = /* fontname, xscale, yscale, ascent, escapement */ "/%s findfont\n" "[%d 0 0 %d 0 0]\n" @@ -611,6 +614,17 @@ BOOL PSDRV_WriteGlyphShow(PSDRV_PDEVICE *physDev, LPCSTR g_name) return TRUE; } +BOOL PSDRV_WriteShow1(PSDRV_PDEVICE *physDev, BYTE g_encoding) +{ + char buf[128]; + int l; + + l = sprintf(buf, psshow, g_encoding); + + PSDRV_WriteSpool(physDev, buf, l); + return TRUE; +} + BOOL PSDRV_WriteFill(PSDRV_PDEVICE *physDev) { return PSDRV_WriteSpool(physDev, psfill, sizeof(psfill)-1); diff --git a/dlls/wineps.drv/psdrv.h b/dlls/wineps.drv/psdrv.h index fcdc78d..4e30238 100644 --- a/dlls/wineps.drv/psdrv.h +++ b/dlls/wineps.drv/psdrv.h @@ -292,8 +292,23 @@ typedef struct _tagDOWNLOAD { TYPE42 *Type42; } typeinfo; char *ps_name; + char *spoolbuf; + size_t spoolbuf_len; + DWORD glyph_sent_size; + WORD *glyph_sent; + WORD glyph_enc_first_valid; + DWORD glyph_enc_next_free; + WORD glyph_enc_last_used; struct _tagDOWNLOAD *next; } DOWNLOAD; +#define DOWNLOAD_SPOOLBUF_MINPLUS 1001 +/* tmp_spool_buf is quaranteed to hold at least + 2*strlen(psname) + DOWNLOAD_TMPBUF_MINPLUS bytes + Attention: + spoolbuf may be changed by any function + of WINE BUT those from ps.c + Never give it as parameter to a WINE function + but those from ps.c */ enum fontloc { Builtin, Download @@ -444,6 +459,7 @@ extern BOOL PSDRV_WriteRRectangle(PSDRV_PDEVICE *physDev, INT x, INT y, INT widt extern BOOL PSDRV_WriteSetFont(PSDRV_PDEVICE *physDev, const char *name, INT size, INT escapement); extern BOOL PSDRV_WriteGlyphShow(PSDRV_PDEVICE *physDev, LPCSTR g_name); +extern BOOL PSDRV_WriteShow1(PSDRV_PDEVICE *physDev, BYTE g_encoding); extern BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev); extern BOOL PSDRV_WriteArc(PSDRV_PDEVICE *physDev, INT x, INT y, INT w, INT h, double ang1, double ang2); diff --git a/dlls/wineps.drv/type1.c b/dlls/wineps.drv/type1.c index fe8c8ba..c74bb88 100644 --- a/dlls/wineps.drv/type1.c +++ b/dlls/wineps.drv/type1.c @@ -37,8 +37,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(psdrv); struct tagTYPE1 { - DWORD glyph_sent_size; - BOOL *glyph_sent; DWORD emsize; }; @@ -62,7 +60,7 @@ TYPE1 *T1_download_header(PSDRV_PDEVICE *physDev, char *ps_name, RECT *bbox, UIN char dict[] = /* name, emsquare, fontbbox */ "25 dict begin\n" - " /FontName /%s def\n" + " /FontName /%s_wine_0000 def\n" " /Encoding 256 array 0 1 255{1 index exch /.notdef put} for def\n" " /PaintType 0 def\n" " /FontMatrix [1 %d div 0 0 1 %d div 0 0] def\n" @@ -87,11 +85,6 @@ TYPE1 *T1_download_header(PSDRV_PDEVICE *physDev, char *ps_name, RECT *bbox, UIN t1 = HeapAlloc(GetProcessHeap(), 0, sizeof(*t1)); t1->emsize = emsize; - t1->glyph_sent_size = GLYPH_SENT_INC; - t1->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t1->glyph_sent_size * - sizeof(*(t1->glyph_sent))); - buf = HeapAlloc(GetProcessHeap(), 0, sizeof(dict) + strlen(ps_name) + 100); @@ -194,7 +187,7 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, RECT rc; static const char glyph_def_begin[] = - "/%s findfont dup\n" + "/%s_wine_0000 findfont dup\n" "/Private get begin\n" "/CharStrings get begin\n" "/%s %d RD\n"; @@ -206,15 +199,10 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, assert(pdl->type == Type1); t1 = pdl->typeinfo.Type1; - if(index < t1->glyph_sent_size) { - if(t1->glyph_sent[index]) - return TRUE; - } else { - t1->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; - t1->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t1->glyph_sent, - t1->glyph_sent_size * sizeof(*(t1->glyph_sent))); - } + if(index >= pdl->glyph_sent_size) + return FALSE; + if(pdl->glyph_sent[index]) + return TRUE; GetObjectW(GetCurrentObject(physDev->hdc, OBJ_FONT), sizeof(lf), &lf); rc.left = rc.right = rc.bottom = 0; @@ -295,7 +283,7 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, PSDRV_WriteSpool(physDev, buf, strlen(buf)); str_free(charstring); - t1->glyph_sent[index] = TRUE; + pdl->glyph_sent[index] = 1; HeapFree(GetProcessHeap(), 0, glyph_buf); HeapFree(GetProcessHeap(), 0, buf); return TRUE; @@ -303,7 +291,6 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, void T1_free(TYPE1 *t1) { - HeapFree(GetProcessHeap(), 0, t1->glyph_sent); HeapFree(GetProcessHeap(), 0, t1); return; } diff --git a/dlls/wineps.drv/type42.c b/dlls/wineps.drv/type42.c index 172072e..a6c7f8a 100644 --- a/dlls/wineps.drv/type42.c +++ b/dlls/wineps.drv/type42.c @@ -74,8 +74,6 @@ struct tagTYPE42 { int glyf_tab, loca_tab, head_tab; /* indices of glyf, loca and head tables */ int hmtx_tab, maxp_tab; int num_of_written_tables; - DWORD glyph_sent_size; - BOOL *glyph_sent; DWORD emsize; DWORD *glyf_blocks; }; @@ -143,7 +141,7 @@ TYPE42 *T42_download_header(PSDRV_PDEVICE *physDev, char *ps_name, TYPE42 *t42; static const char start[] = /* name, fontbbox */ "25 dict begin\n" - " /FontName /%s def\n" + " /FontName /%s_wine_0000 def\n" " /Encoding 256 array 0 1 255{1 index exch /.notdef put} for\n" " def\n" " /PaintType 0 def\n" @@ -193,11 +191,6 @@ TYPE42 *T42_download_header(PSDRV_PDEVICE *physDev, char *ps_name, return NULL; } - t42->glyph_sent_size = GLYPH_SENT_INC; - t42->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t42->glyph_sent_size * - sizeof(*(t42->glyph_sent))); - buf = HeapAlloc(GetProcessHeap(), 0, sizeof(start) + strlen(ps_name) + 100); @@ -287,7 +280,7 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, TYPE42 *t42; const char glyph_def[] = - "/%s findfont exch 1 index\n" + "/%s_wine_0000 findfont exch 1 index\n" "havetype42gdir\n" "{/GlyphDirectory get begin %d exch def end}\n" "{/sfnts get 4 index get 3 index 2 index putinterval pop}\n" @@ -302,15 +295,10 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, assert(pdl->type == Type42); t42 = pdl->typeinfo.Type42; - if(index < t42->glyph_sent_size) { - if(t42->glyph_sent[index]) - return TRUE; - } else { - t42->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; - t42->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t42->glyph_sent, - t42->glyph_sent_size * sizeof(*(t42->glyph_sent))); - } + if(index >= pdl->glyph_sent_size) + return FALSE; + if(pdl->glyph_sent[index]) + return TRUE; if(!get_glyf_pos(t42, index, &start, &end)) return FALSE; TRACE("start = %x end = %x\n", start, end); @@ -364,7 +352,7 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, sprintf(buf, glyph_def, pdl->ps_name, index, glyph_name, index); PSDRV_WriteSpool(physDev, buf, strlen(buf)); - t42->glyph_sent[index] = TRUE; + pdl->glyph_sent[index] = 1; HeapFree(GetProcessHeap(), 0, buf); return TRUE; } @@ -374,7 +362,6 @@ void T42_free(TYPE42 *t42) OTTable *table; for(table = t42->tables; table->MS_tag; table++) HeapFree(GetProcessHeap(), 0, table->data); - HeapFree(GetProcessHeap(), 0, t42->glyph_sent); HeapFree(GetProcessHeap(), 0, t42->glyf_blocks); HeapFree(GetProcessHeap(), 0, t42); return; -- 1.5.6.5

Dec. 6, 2008

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.

by Jérôme Gardou

Henri Verbeet a écrit : > 2008/12/6 Jérôme Gardou <jerome.gardou(a)gmail.com>: > >> According to d3d9_private.h , ref is a LONG. >> >> > ref is not defined in d3d9_private.h. > Taken from d3d9_private.h : typedef struct IDirect3DDevice9Impl { /* IUnknown fields */ const IDirect3DDevice9ExVtbl *lpVtbl; LONG ref; ... That's why the compiler did not complained... But release actually returns a ULONG, and the IUnknown ref is an ULONG anyway... I guess this should be changed for consistency.

Dec. 6, 2008

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.

by Henri Verbeet

2008/12/6 Jérôme Gardou <jerome.gardou(a)gmail.com>: > > According to d3d9_private.h , ref is a LONG. > ref is not defined in d3d9_private.h.

Dec. 6, 2008

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.

by Jérôme Gardou

Jérôme Gardou a écrit : > Henri Verbeet a écrit : > >> 2008/11/30 Jérôme Gardou <jerome.gardou(a)gmail.com>: >> >> >>> - if (ref == 0) { >>> + if (ref <= 0) { >>> >>> >> This doesn't work, of course. ref is an ULONG. >> > Why not just a cast in this case ? > According to d3d9_private.h , ref is a LONG.

Dec. 6, 2008

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.

by Jérôme Gardou

Henri Verbeet a écrit : > 2008/11/30 Jérôme Gardou <jerome.gardou(a)gmail.com>: > >> - if (ref == 0) { >> + if (ref <= 0) { >> > This doesn't work, of course. ref is an ULONG. Why not just a cast in this case ? > The check for Reset > should probably go into wined3d. > OK... but a test should check is this is the same behaviour in d3d8. Not sure...

Dec. 6, 2008

Re: Package repository discussion

by Tom Wickline

On Fri, Dec 5, 2008 at 4:51 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > Tom Wickline wrote: >> Well maybe you will want to fix the 8.04 debs so they will actually >> install for people before you tell everyone to come and get them. >> >> The debs that you provide have a unresolved dependency. > > Could you clarify? I'm not aware of any installation-critical bugs in > the 8.04 packages. > ok ill re test the older bulds again. >> >> Also from the download page: http://www.lamalennyrepo.altervista.org/binary.php >> is a 404 > > Which download page is this? I've never seen this site before. from here: http://www.winehq.org/site/download-deblenny but now its working, it was a 404 for a couple days. > > Thanks, > Scott Ritchie >

Dec. 6, 2008

re: App hang on creating modal dialog

by Dan Kegel

Jeff wrote: >I'm trying to solve my bug 16346 >http://bugs.winehq.org/show_bug.cgi?id=16346 >... >I'm trying to figure out where in the wine code I should look for a >system that might be eating all of the messages intended for my >application. Can anyone point me in the right direction? I dunno, but that test case is nice and small. Can you turn it into a wine conformance test? That will make it even more likely somebody helps find a solution... - Dan

Dec. 6, 2008

Re: Package repository discussion

by Scott Ritchie

Tom Wickline wrote: > Well maybe you will want to fix the 8.04 debs so they will actually > install for people before you tell everyone to come and get them. > > The debs that you provide have a unresolved dependency. Could you clarify? I'm not aware of any installation-critical bugs in the 8.04 packages. > > Also from the download page: http://www.lamalennyrepo.altervista.org/binary.php > is a 404 Which download page is this? I've never seen this site before. Thanks, Scott Ritchie

Dec. 5, 2008

Wine64 hello world app runs!

by Maarten Lankhorst

Hi guys, I can finally report success on the first ever win64 program running on wine. The program was a textbook classic, but to make it work gcc had to be changed a lot. This was done by Kai Tietz, who has put a lot of effort in the task of making gcc accept the calling convention. There are still a lot of things which should be done before this will be able to get into mainline though. My repository is at http://repo.or.cz/w/wine/wine64.git , but in order to actually get it working you need gcc checked out from subversion with some experimental patches. They are expected to get merged soon, so until then it is not recommended to even try. :) There are a bunch of things in my tree which are not merged with mainline. A few of them are hacks (disabling SEGV handling for example). There are also some changes which should be accepted, but still need some work. For example wineserver, AJ wants something with regards to fd handling, but I didn't find him clear on what exactly. va_list also is incompatible, and should be replaced with ms_va_list where appropiate. Once again, thanks to Kai Tietz for making this possible. Cheers, Maarten.

Dec. 5, 2008

Re: mshtml: Removed the reference counting of the DLL.

by Austin English

On Fri, Dec 5, 2008 at 2:36 PM, Alexandru Balut <alexandru.balut(a)gmail.com> wrote: > Hi, > > This is a fix for: http://bugs.winehq.org/show_bug.cgi?id=16164 > > > > + // We never unload the dll, so we just ignore this call. + // See DllCanUnloadNow(). You've got C++ style comments, only use straight C /* comment */ -- -Austin

Dec. 5, 2008

App hang on creating modal dialog

by Jeff Miller

I'm trying to solve my bug 16346 http://bugs.winehq.org/show_bug.cgi?id=16346 Whenever an application pops up a modal dialog in response to a WM_ACTIVATEAPP message, the entire app permanently hangs. The dialog comes up and is usually rendered the first time, but then no more messages are ever received by the app. I'm trying to figure out where in the wine code I should look for a system that might be eating all of the messages intended for my application. Can anyone point me in the right direction? My best guess is that there is a race between the application becoming the active window and the dialog taking over as the active window, and the message system is arriving at an inconsistent state. Jeff

Dec. 5, 2008

Re: winebrowser: Interpret the DDE data as CHAR or WCHAR just like the shell32 dde_connect helper sends it

by Paul Chitescu

On Friday 05 December 2008 16:33:04 Hans Leidekker wrote: > On Friday 05 December 2008 15:17:47 Paul Chitescu wrote: > > The problem is not about the service name or other identifiers but rather > > the obscure data pushed by the DdeClientTransaction. DDE knows nothing > > about the format of this data as this is rather a convention between the > > client (shell32) and the server (winebrowser). > > But is it safe to assume that shell32 is the only client of winebrowser? > > -Hans The few examples I've found for direct IE invocation pass a HDDEDATA handle created by DdeCreateStringHandle (a HSZ). Wine's implementation seems to simply get the data and length from the data and send it over DDE (in WDML_ClientQueueExecute). No idea if string type is preserved in Windows. The fact winebrowser doesn't crash suggest no program is doing DdeClientTransaction directly ;-) although it may be possible that winebrowser just prints this warning message which my patch fixes: Unabled to retrieve URL from string L"\"" LOL! We could easily guess if the data received by winebrowser has the wrong character size since normally the 1st character is a quote. However this doesn't look clean to me. Paul

Dec. 5, 2008

Re: winebrowser: Interpret the DDE data as CHAR or WCHAR just like the shell32 dde_connect helper sends it

by Hans Leidekker

On Friday 05 December 2008 15:17:47 Paul Chitescu wrote: > The problem is not about the service name or other identifiers but rather the > obscure data pushed by the DdeClientTransaction. DDE knows nothing about the > format of this data as this is rather a convention between the client > (shell32) and the server (winebrowser). But is it safe to assume that shell32 is the only client of winebrowser? -Hans

Dec. 5, 2008

Re: opengl/tests: Skip tests if we can't find a pixel format.

by Huw Davies

On Fri, Dec 05, 2008 at 03:25:56PM +0100, Paul Vriens wrote: > This looks a bit strange: > > + if(iPixelFormat == 0) > + { > + todo_wine ok(iPixelFormat > 0, > > > Is it your intention to just throw up a failed message in all cases? Hi Paul, It was my intention to throw a todo if ChoosePixelFormat rets 0 when run under Wine. Huw.

Dec. 5, 2008

Re: opengl/tests: Skip tests if we can't find a pixel format.

by Paul Vriens

Huw Davies wrote: > --- > dlls/opengl32/tests/opengl.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, This looks a bit strange: + if(iPixelFormat == 0) + { + todo_wine ok(iPixelFormat > 0, Is it your intention to just throw up a failed message in all cases? -- Cheers, Paul.

Dec. 5, 2008

Re: winebrowser: Interpret the DDE data as CHAR or WCHAR just like the shell32 dde_connect helper sends it

by Paul Chitescu

Hi! The problem is not about the service name or other identifiers but rather the obscure data pushed by the DdeClientTransaction. DDE knows nothing about the format of this data as this is rather a convention between the client (shell32) and the server (winebrowser). Paul Chitescu On Friday 05 December 2008 15:49:52 Hans Leidekker wrote: > On Friday 05 December 2008 14:05:08 Paul Chitescu wrote: > > Shell32 sends either 8 bit or 16 bit strings in XTYP_EXECUTE depending on > > the highest bit of "operating system version" - ASCII based or Unicode > > based. When the data is used in winebrowser it must be interpreted the > > same. > > The impression I get from reading MSDN is that the character set depends > on whether the client called DdeInitializeA or DdeInitializeW, and it can > be overridden too by setting iCodePage in the CONVCONTEXT structure. > > -Hans

Dec. 5, 2008

Re: winebrowser: Interpret the DDE data as CHAR or WCHAR just like the shell32 dde_connect helper sends it

by Hans Leidekker

On Friday 05 December 2008 14:05:08 Paul Chitescu wrote: > Shell32 sends either 8 bit or 16 bit strings in XTYP_EXECUTE depending on the > highest bit of "operating system version" - ASCII based or Unicode based. > When the data is used in winebrowser it must be interpreted the same. The impression I get from reading MSDN is that the character set depends on whether the client called DdeInitializeA or DdeInitializeW, and it can be overridden too by setting iCodePage in the CONVCONTEXT structure. -Hans

Dec. 5, 2008

Re: Package repository discussion

by Tom Wickline

Well maybe you will want to fix the 8.04 debs so they will actually install for people before you tell everyone to come and get them. The debs that you provide have a unresolved dependency. Also from the download page: http://www.lamalennyrepo.altervista.org/binary.php is a 404 Tom On Thu, Dec 4, 2008 at 7:01 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > Dan Kegel wrote: >> Ubuntu is having a meeting next week to discuss >> how to more easily grant users access to third >> party repositories (like wine's, perhaps). >> >> I've got a meeting wiki up at >> http://wiki.winehq.org/TrustingThirdPartyRepositories >> It already lists the big issues that need discussing. >> If you're interested in the topic, please have a look and put your two cents in! >> - Dan >> >> > I'll be there. I proposed a similar thing that never quite happened > last year (ThirdPartyApt), but only because I didn't really have time to > write the actual code. > > Thanks, > Scott Ritchie > > > -- http://www.wine-reviews.net/

Dec. 5, 2008

Re: Alexandre Julliard : wintab32: Make a function static.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So how do you know which functions to make static? I guess you don't > just mark them all static and see if it causes compilation errors. > > Is it a script parsing the 'nm -D' output and then grepping for them in > the spec file and in object files? I guess there's better way. Currently I'm doing basically nm -D and then grep *.spec *.c. There are a number of false positives since it will miss macros etc. so it's probably a bit hard to automate. I suppose you could keep a current list and then check for new symbols once a week. -- Alexandre Julliard julliard(a)winehq.org

Dec. 5, 2008

Re: inetcomm: possible null pointer dereferences

by Hans Leidekker

On Thursday 04 December 2008 21:32:37 Gregor Schneider wrote: > - TRACE("(%s)\n", pszEmailFrom); > - > if (!pszEmailFrom) > return E_INVALIDARG; > > + TRACE("(%s)\n", pszEmailFrom); > + > + len = sizeof(szCommandFormat) - 2 /* "%s" */ + strlen(pszEmailFrom); > + Instead of moving the trace down you should use debugstr_a(), which handles the NULL pointer for you. -Hans

Dec. 5, 2008

Re: wineconsole: Wait on events in curses backend using select insteadof poll

by James McKenzie

Dmitry Timoshkov wrote: > "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > >> Martin Storsjö wrote: >>> >>> poll can't handle terminal devices on Darwin, since Tiger. See the >>> following discussion: >>> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html >>> >> This will have to be setup so that it only works for Macs. Maybe this >> can be a static patch in the Darwine code but it does not belong in the >> Wine code stack. > > Why do you prefer to have a broken hack in Darwine instead of fixing this > properly? Because I don't think AJ will approve a Mac-only fix. If the 'proper' thing to do is to produce an appropriate patch, then that should be our goal. > > Btw, what are the difference between Darwine and WineHQ that you insist > to have a different name (Darwine) instead of just Wine? I did not create Darwine, I only test the builds from Zach Drayer and Mike Kronenberg. > Are you aware > that due to that all bugs reported to Wine bugzilla mentioning Darwine > are closed as invalid? Do you have your own bug tracking system? > I'll check if Darwine has its own tracking system. I would like go segway at this point to two projects that I actually produced code for: NeoOffice.org, which was a Aqua port of OpenOffice.org The Mac X11 port of OpenOffice.org, which has produced a release version of an Aqua port after about two years. So, how does this apply to Wine? If a problem was found in NeoOffice.org that was caused by the base OpenOffice.org code, the NeoOffice.org testers would create a bug in the OpenOffice.org Bug Tracker. I propose that we do the same thing with Darwine. If a bug is found that concerns ONLY the Darwine builds, then it should stay with the Darwine people. An example of this is the lack of OpenGL support from Apple/MacQuartz's X11. If a bug is found that concerns the Wine code, then it goes into the Wine Bugzilla. This way developers are aware of problems that need to be fixed. As a final thought, I have an X86 PC (acutally, a Thinkpad A22p with an ATI video card) that I can test problems on and possibly work with to build Wine from git. However, my time is limited as is everyone's. So, why the long story: If AJ will allow Mac-specific 'c' code, then I'm all in on keeping it in Wine. If he cannot, then it should be part of the Darwine project. I don't want a repeat of what happened between the NeoOffice.org and OpenOffice.org projects. My opinion is that there should be one and only one code base from which builds for all of the x86 operating systems can be built from. This includes the various flavors of Linux, UNIX, Solaris and MacOSX. Maybe we can even include the small OS/2 crowd somehow. James McKenzie

Dec. 5, 2008

Re: [PATCH] comdlg32: Avoid passing NULL to FILEDLG95_LOOKIN_InsertItemAfterParent.

by Vincent Povirk

Hi, I think you need to free the pidl you get from SHGetSpecialFolderLocation. Vincent Povirk On Thu, Dec 4, 2008 at 4:57 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This is my second attempt to fix bug 16332. We can make sure > FILEDLG95_LOOKIN_InsertItemAfterParent() doesn't infinite loop by > always giving it a non-null pidl. The Desktop folder seems like a > sensible default. > > > >

Dec. 5, 2008

Re: Package repository discussion

by Dan Kegel

On Thu, Dec 4, 2008 at 4:01 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > I'll be there. I proposed a similar thing that never quite happened > last year (ThirdPartyApt), but only because I didn't really have time to > write the actual code. Yeah, saw that. I guess I should link to it. See you there!

Dec. 5, 2008

Re: Package repository discussion

by Scott Ritchie

Dan Kegel wrote: > Ubuntu is having a meeting next week to discuss > how to more easily grant users access to third > party repositories (like wine's, perhaps). > > I've got a meeting wiki up at > http://wiki.winehq.org/TrustingThirdPartyRepositories > It already lists the big issues that need discussing. > If you're interested in the topic, please have a look and put your two cents in! > - Dan > > I'll be there. I proposed a similar thing that never quite happened last year (ThirdPartyApt), but only because I didn't really have time to write the actual code. Thanks, Scott Ritchie

Dec. 5, 2008

Re: Alexandre Julliard : wintab32: Make a function static.

by Francois Gouget

On Thu, 4 Dec 2008, Alexandre Julliard wrote: [...] > -UINT WINAPI WTInfoT(UINT wCategory, UINT nIndex, LPVOID lpOutput, BOOL bUnicode) > +static UINT WTInfoT(UINT wCategory, UINT nIndex, LPVOID lpOutput, BOOL bUnicode) So how do you know which functions to make static? I guess you don't just mark them all static and see if it causes compilation errors. Is it a script parsing the 'nm -D' output and then grepping for them in the spec file and in object files? I guess there's better way. Is it something that can be automated? I'm thinking either patchwatcher or my weekly scripts here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Dec. 4, 2008

Re: Package repository discussion

by Dan Kegel

On Thu, Dec 4, 2008 at 5:55 AM, Marcus Meissner <meissner(a)suse.de> wrote: >> http://wiki.winehq.org/TrustingThirdPartyRepositories > > Well, openSUSE 11.0/11.1 use a remote hosted XML file which provides > a list of repositories for addition, and also single-click "YMP" files > for very easy repository addition. > > This XML list includes my Emulators:Wine repository on the openSUSE > buildservice for instance. > > So perhaps they should look at and evaluate how openSUSE does it ;) I'm very aware of the YMP / OneClickInstall stuff, and it will be discussed. I already have an indirect link to it, maybe I'll add a direct one, too. > As for the points listed, we sometimes adopt a "do not care" attitude, > because, well, users do not want it to be overdesigned or just don't > care. Users don't care about security and dll hell until it bites them, either.

Dec. 4, 2008

Re: Package repository discussion

by Marcus Meissner

On Thu, Dec 04, 2008 at 05:45:21AM -0800, Dan Kegel wrote: > Ubuntu is having a meeting next week to discuss > how to more easily grant users access to third > party repositories (like wine's, perhaps). > > I've got a meeting wiki up at > http://wiki.winehq.org/TrustingThirdPartyRepositories > It already lists the big issues that need discussing. > If you're interested in the topic, please have a look and put your two cents in! Well, openSUSE 11.0/11.1 use a remote hosted XML file which provides a list of repositories for addition, and also single-click "YMP" files for very easy repository addition. This XML list includes my Emulators:Wine repository on the openSUSE buildservice for instance. So perhaps they should look at and evaluate how openSUSE does it ;) As for the points listed, we sometimes adopt a "do not care" attitude, because, well, users do not want it to be overdesigned or just don't care. Ciao, Marcus

Dec. 4, 2008

Package repository discussion

by Dan Kegel

Ubuntu is having a meeting next week to discuss how to more easily grant users access to third party repositories (like wine's, perhaps). I've got a meeting wiki up at http://wiki.winehq.org/TrustingThirdPartyRepositories It already lists the big issues that need discussing. If you're interested in the topic, please have a look and put your two cents in! - Dan

Dec. 4, 2008

Re: patch for gdi32

by Markus Hitter

Am 04.12.2008 um 00:38 schrieb Xiangrong Fang: > but that is marked as FIXED and CLOSED?? Yes, Wine developers are sometimes pretty quick at closing bugs. The sad thing is, you can't comment on closed bugs and have to open a new one. > BTW, for these discussions, shall I use wine-devel or wine-patch? wine-patches is for patches only, -devel is where discussions should go. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Dec. 4, 2008

re: wineconsole: Wait on events in curses backend using select instead of poll

by Dan Kegel

James McKenzie wrote: > This will have to be setup so that it only works for Macs. > ... it does not belong in the Wine code stack. Why? Select is a perfectly reasonable choice -- and arguably preferable to poll -- when you are absolutely sure that no file descriptor higher than 1023 can be passed to it. (e.g. when you're using it in a program that does not open many file descriptors, or when you're using it with no file descriptors, as a nice sleep). I think wineconsole is an example of an app that does not open many file descriptors, so select is fine there. - Dan

Dec. 4, 2008

Re: dsound: fix remaining ds3d, dsound, dsound8 test failures shown on test.winehq.org

by Paul Vriens

Jeff Zaroyko wrote: > On Thu, Dec 4, 2008 at 7:35 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Jeff Zaroyko wrote: >>> This should clear up the remaining dsound test failures shown for the >>> Win98 and WinME test results. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >> Hi Jeff, >> >> Would be a nice-to-have if you could add the platforms as comments to the >> different return values. >> >> -- >> Cheers, >> >> Paul. >> > > Maybe - do you think it's really platform dependent? > > I think it's just up to the underlying driver and that will vary even > on the same platform. > If it's driver dependent you can ignore my email. -- Cheers, Paul.

Dec. 4, 2008

Any problems with these wineconsole patches?

by Martin Storsjö

Hi, In addition to the select vs poll patch to wineconsole, I sent two other unrelated minor patches for wineconsole last Friday (attached here); are there any obvious problems with these, prohibiting them from getting merged? The first one simply makes fallbacks from the curses to the user backend work if the curses library isn't found; not only in the case when the curses backend isn't compiled in at all. The second one makes --use-event not resetting the backend to user, since that's already the default. By setting the environment variable WINECONSOLE="wineconsole --backend=curses", the user could make all implicitly opened consoles be curses based consoles -- if --use-event wouldn't reset the backend back to user as it does at the moment. Regards, // Martin

Dec. 4, 2008

Re: dsound: fix remaining ds3d, dsound, dsound8 test failures shown on test.winehq.org

by Jeff Zaroyko

On Thu, Dec 4, 2008 at 7:35 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Jeff Zaroyko wrote: >> >> This should clear up the remaining dsound test failures shown for the >> Win98 and WinME test results. >> >> >> ------------------------------------------------------------------------ >> >> > Hi Jeff, > > Would be a nice-to-have if you could add the platforms as comments to the > different return values. > > -- > Cheers, > > Paul. > Maybe - do you think it's really platform dependent? I think it's just up to the underlying driver and that will vary even on the same platform.

Dec. 4, 2008