January 2007 - Wine-Devel - list.winehq.org

user32: the patches - what's wrong?
by Kirill K. Smirnov Jan. 15, 2007

Jan. 15, 2007

Hi, Traditional questions from rejected patch-sender: 1) What's wrong with the following patches? http://www.winehq.org/pipermail/wine-patches/2007-January/034758.html http://www.winehq.org/pipermail/wine-patches/2007-January/034790.html 2) What can be done to improve them? Those patches let the window proc repaint NC area instead of calling NCPaint directly. And changes processing of WM_SETICON to be similar with WM_SETTEXT. -- Kirill

2 1

Re: [5] snmpapi: Implement SnmpUtilVarBindListCpy and SnmpUtilVarBindListFree.
by Robert Shearman Jan. 15, 2007

Jan. 15, 2007

Hans Leidekker wrote: > + > +/*********************************************************************** > + * SnmpUtilVarBindListCpy (SNMPAPI.@) > + */ > +INT WINAPI SnmpUtilVarBindListCpy(SnmpVarBindList *dst, SnmpVarBindList *src) > +{ > + unsigned int i, size; > + SnmpVarBind *src_entry, *dst_entry; > + > + TRACE("(%p, %p)\n", dst, src); > + > + size = sizeof(SnmpVarBindList); > + if (!(dst = HeapAlloc(GetProcessHeap(), 0, size))) return SNMPAPI_ERROR; > Where do you return this memory to the caller? > + > + size = src->len * sizeof(SnmpVarBind *); > + if (!(dst->list = HeapAlloc(GetProcessHeap(), 0, size))) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return SNMPAPI_ERROR; > + } > + src_entry = src->list; > + dst_entry = dst->list; > + for (i = 0; i < src->len; i++) > + { > + if (SnmpUtilVarBindCpy(dst_entry, src_entry)) > + { > + src_entry++; > + dst_entry++; > + } > + else > + { > + for (--i; i > 0; i--) SnmpUtilVarBindFree(--dst_entry); > + HeapFree(GetProcessHeap(), 0, dst->list); > + HeapFree(GetProcessHeap(), 0, dst); > + return SNMPAPI_ERROR; > + } > + } > + dst->len = src->len; > + return SNMPAPI_NOERROR; > +} > > -- Rob Shearman

1 0

Re: dsound: fix tests for old versions of windows
by Francois Gouget Jan. 15, 2007

Jan. 15, 2007

On Fri, 12 Jan 2007, Robert Reif wrote: > This patch fixes the tests to they can run without crashing on old versions of > windows that doesn't have dsound.dll. > + hDsound = LoadLibrary("dsound.dll"); + if (hDsound) { [...] + pDirectSoundCaptureEnumerateA=(void*)GetProcAddress(hDsound, + "DirectSoundCaptureEnumerateA"); + if (pDirectSoundCaptureCreate && pDirectSoundCaptureEnumerateA) + { [...] If all dsound.dll implementations are supposed to have these functions (which I believe is the case), then I would test that we found them with an ok() call. Also, if we fail to load dsound.dll, then we should indicate that we are skipping the tests with the new skip() function. This will make it clearer when analysing the logs that a big chunk of functionality was not tested (see the d3d8 tests for instance). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

1 0

(Cross)Compile failure for dsound/tests and shlwapi/tests
by Paul Vriens Jan. 15, 2007

Jan. 15, 2007

Hi, three failures currently prevent winetest.exe from being build. The first one was ole32/tests/marshal.c (where Stefan Leichter sent a MinGW patch for): i386-mingw32-gcc clipboard.cross.o compobj.cross.o hglobalstream.cross.o marshal.cross.o moniker.cross.o ole2.cross.o propvariant.cross.o stg_prop.cross.o storage32.cross.o usrmarshal.cross.o testlist.cross.o -o ole32_crosstest.exe -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -luuid marshal.cross.o:marshal.c:(.text+0x7a61): undefined reference to `_IID_IChannelHook' collect2: ld returned 1 exit status make: *** [ole32_crosstest.exe] Error 1 The second one is for dsound/tests: i386-mingw32-gcc capture.cross.o ds3d.cross.o ds3d8.cross.o dsound.cross.o dsound8.cross.o duplex.cross.o propset.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 capture.cross.o:capture.c:(.text+0xcf4): undefined reference to `_CLSID_DirectSoundPrivate' dsound.cross.o:dsound.c:(.text+0xbef): undefined reference to `_CLSID_DirectSoundPrivate' dsound.cross.o:dsound.c:(.text+0xc7a): undefined reference to `_CLSID_DirectSoundPrivate' dsound8.cross.o:dsound8.c:(.text+0xd39): undefined reference to `_CLSID_DirectSoundPrivate' dsound8.cross.o:dsound8.c:(.text+0xdc4): undefined reference to `_CLSID_DirectSoundPrivate' duplex.cross.o:duplex.c:(.text+0x794): more undefined references to `_CLSID_DirectSoundPrivate' follow propset.cross.o:propset.c:(.text+0x122f): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x1353): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x1477): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x159b): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x16bf): undefined reference to `_DSPROPSETID_DirectSoundDevice' propset.cross.o:propset.c:(.text+0x179e): more undefined references to `_DSPROPSETID_DirectSoundDevice' follow collect2: ld returned 1 exit status make: *** [dsound_crosstest.exe] Error 1 The third one is for shlwapi/tests: i386-mingw32-gcc clist.cross.o clsid.cross.o generated.cross.o ordinal.cross.o path.cross.o shreg.cross.o string.cross.o testlist.cross.o -o shlwapi_crosstest.exe -lshlwapi -ladvapi32 -lole32 -loleaut32 -lkernel32 -luuid clsid.cross.o:clsid.c:(.data+0x8): undefined reference to `_CATID_BrowsableShellExt' clsid.cross.o:clsid.c:(.data+0xc): undefined reference to `_CATID_BrowseInPlace' clsid.cross.o:clsid.c:(.data+0x10): undefined reference to `_CATID_DeskBand' clsid.cross.o:clsid.c:(.data+0x14): undefined reference to `_CATID_InfoBand' clsid.cross.o:clsid.c:(.data+0x18): undefined reference to `_CATID_CommBand' clsid.cross.o:clsid.c:(.data+0x30): undefined reference to `_CGID_ExplorerBarDoc' clsid.cross.o:clsid.c:(.data+0x50): undefined reference to `_IID_IShellDetails' clsid.cross.o:clsid.c:(.data+0x54): undefined reference to `_IID_IDelayedRelease' clsid.cross.o:clsid.c:(.data+0x94): undefined reference to `_IID_IRemoteComputer' clsid.cross.o:clsid.c:(.data+0x9c): undefined reference to `_IID_IDockingWindow' clsid.cross.o:clsid.c:(.data+0xa0): undefined reference to `_IID_IDockingWindowSite' clsid.cross.o:clsid.c:(.data+0xa8): undefined reference to `_CLSID_NetworkDomain' clsid.cross.o:clsid.c:(.data+0xac): undefined reference to `_CLSID_NetworkServer' clsid.cross.o:clsid.c:(.data+0xb0): undefined reference to `_CLSID_NetworkShare' clsid.cross.o:clsid.c:(.data+0xc8): undefined reference to `_CLSID_Printers' collect2: ld returned 1 exit status make: *** [shlwapi_crosstest.exe] Error 1 Volunteers ? Cheers, Paul.

3 4

vb6 ide getting close...
by Dan Kegel Jan. 15, 2007

Jan. 15, 2007

OK, the vb6 IDE may not be the most popular app at the moment, but it's still a good test of Wine. It seems to be getting closer; http://bugs.winehq.org/show_bug.cgi?id=5181 and http://bugs.winehq.org/show_bug.cgi?id=4931 are both a fair bit happier. Still not really usable. There seems to be a regression since June: the "New Project" dialog that pops up at the start of vb6 doesn't get drawn properly, though if you arrow around, the icons in it do then get drawn. (See bug 4931.) - Dan

1 0

Feedback on "Wine users guide"
by Torsten Hammarstedt, X-Lin AB Jan. 14, 2007

Jan. 14, 2007

Hi Perhaps the resason that you didn't receive a lot of feedback on the Wine Users Guide is that it is very well written. Nevertheless I have found a few details that might be better explained: 1.2.3 Wine capabilities ..... Notes [1] Today VMware server is free software and you can easily manage a Windows system on a VMware virtual machine. However this does not solve the problem with having to maintain/support two differnt operating systems (quite time consuming...). There is also the commercial software /2X application server/ and /2X application server client /(2X.com) with which windows applications can be run on Linux in single windows using Windows Terminal services. The above 2X software is free up to 5 server connections, for more you have to pay a license fee. So far it is quite beta-style but eventually it might be very good... Windows terminal services is available in Win XP prof, Win 2000 Server and Win 2003 Server (don't know about Vista). 2.2. Getting a Wine package I think you should mention Ubuntu - thera are packages for Ubuntu avaialable on sourceforge.net Wine download page. That was all for the first 4 chapters - perhaps I'll come back with more feedback later. -- B R Torsten Hammarstedt ~~~~~~~~~~~~~~~~~~~~~~ * * PC & Networks AB tel. 031 - 706 95 00 e-post: torsten(a)x-lin.se www.x-lin.se

2 1

[15/20] WineD3D: Clean up drawprim a bit
by Christoph Bumiller Jan. 14, 2007

Jan. 14, 2007

Stefan Dösinger wrote: > We will need software shaders for a correct implementation of > IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I > don't really think OpenGL feedback mode is what we want here. > > Maybe we should remove it for now, but keep the code somewhere(in the > wiki maybe). If someone is extra-ambitious we can do something like > Softwire/SwiftShader does. But I think ProcessVertices is a good > oportunity to verify our vertex shader implementation. > Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.

3 4

Re: remove redundant semicolons for ANSI compat.
by Michael Stefaniuc Jan. 13, 2007

Jan. 13, 2007

Joel Parker wrote: > Bug 4527 > > > > > ------------------------------------------------------------------------ > >>From 205f7fdd9a63409014a322318aba3fd77ec90f47 Mon Sep 17 00:00:00 2001 > From: Joel Parker <joeljkp(a)joel-laptop.(none)> > Date: Fri, 12 Jan 2007 17:26:47 -0600 > Subject: remove redundant semicolons for ANSI compat. > --- > @@ -636,17 +636,17 @@ #define DEFINE_SMapLS(n) \ > "movl " #n "(%ebp),%eax\n\t" \ > "call " __ASM_NAME("SMapLS") "\n\t" \ > "movl %edx," #n "(%ebp)\n\t" \ > - "ret" ); > + "ret" ) > > -DEFINE_SMapLS(8); > -DEFINE_SMapLS(12); > -DEFINE_SMapLS(16); > -DEFINE_SMapLS(20); > -DEFINE_SMapLS(24); > -DEFINE_SMapLS(28); > -DEFINE_SMapLS(32); > -DEFINE_SMapLS(36); > -DEFINE_SMapLS(40); > +DEFINE_SMapLS(8) > +DEFINE_SMapLS(12) > +DEFINE_SMapLS(16) > +DEFINE_SMapLS(20) > +DEFINE_SMapLS(24) > +DEFINE_SMapLS(28) > +DEFINE_SMapLS(32) > +DEFINE_SMapLS(36) > +DEFINE_SMapLS(40) Are you sure this compiles? You removed the semicolon in the macro definition and when it is used. And even if it compiles the code needs to look like C code. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Dapper, git, and version-stamp pain again
by Dan Kegel Jan. 13, 2007

Jan. 13, 2007

On one of my dapper boxes (an old laptop), I got the error main.o: In function `check_command_line':/home/dank/wine-git/loader/main.c:89: undefined reference to `wine_version' today. Turns out the version-stamp rule in loader/Makefile is misbehaving; I had to hack that rule to not invoke git at all. Hmm. I remember having to do that before. Oh, yeah, it's coming back to me now: Dapper's "git --version" reports 1.1.3, and http://wiki.winehq.org/GitWine#head-f90aa63f963ccd6f1b34f59e4fdaafaecc72ad18 says that's too old. Grr. I guess I should submit a patch that checks git's version and doesn't break the build if it's only 1.1.3... it'd save me fifteen minutes next time I forget about this... - Dan

2 1

Re: Paul Vriens : mshtml/tests: Cast-qual warning fix.
by Michael Stefaniuc Jan. 13, 2007

Jan. 13, 2007

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 6338caa9eda8eda98dad9a89a8e71c6ea37bd168 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=6338caa9eda8eda98dad9a89a… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 14:26:05 2007 +0100 > > mshtml/tests: Cast-qual warning fix. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/mshtml/tests/htmldoc.c: In function `test_Load': dlls/mshtml/tests/htmldoc.c:1806: invalid initializer make[2]: *** [htmldoc.o] Error 1 > > --- > > dlls/mshtml/tests/htmldoc.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c > index ac26ca8..0815c01 100644 > --- a/dlls/mshtml/tests/htmldoc.c > +++ b/dlls/mshtml/tests/htmldoc.c > @@ -1803,11 +1803,12 @@ static void test_Load(IPersistMoniker *p > { > IBindCtx *bind; > HRESULT hres; > + static WCHAR sz_html_clientsite_objectparam[] = SZ_HTML_CLIENTSITE_OBJECTPARAM; Making that 'static const WCHAR sz_html_clientsite_objectparam[]' fixes the compilation error but renders the exercise moot. > > test_readyState((IUnknown*)persist); > > CreateBindCtx(0, &bind); > - IBindCtx_RegisterObjectParam(bind, (LPOLESTR)SZ_HTML_CLIENTSITE_OBJECTPARAM, > + IBindCtx_RegisterObjectParam(bind, sz_html_clientsite_objectparam, > (IUnknown*)&ClientSite); > > SET_EXPECT(GetDisplayName); > > > bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

dlls/mshtml/tests/htmldoc.c breakage
by Gerald Pfeifer Jan. 13, 2007

Jan. 13, 2007

The following change to dlls/mshtml/tests/htmldoc.c date: 2007-01-12 19:56:11 +0000; author: julliard; state: Exp; lines: +2 -1 Paul Vriens <paul.vriens.wine(a)gmail.com> mshtml/tests: Cast-qual warning fix. breaks the build with GCC 3.4: /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o htmldoc.o htmldoc.c htmldoc.c: In function `test_Load': htmldoc.c:1806: error: invalid initializer Would you mind having a look? Gerald

1 0

New dlls/crypt32/tests/cert.c breakage
by Gerald Pfeifer Jan. 13, 2007

Jan. 13, 2007

The following change to dlls/crypt32/cert.c revision 1.36 date: 2007-01-12 20:56:12 +0100; author: julliard; state: Exp; lines: +56 -57 Paul Vriens <paul.vriens.wine(a)gmail.com> crypt32/tests: Cast-qual warning fixes. breaks the bootstrap on some of my systems. Specifically, it added a new variable static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; initialized with MS_DEF_PROV_W. However, in include/wincrypt.h we have the following: #if defined(__GNUC__) # define MS_DEF_PROV_W (const WCHAR []){ ... } #elif defined(_MSC_VER) # define MS_DEF_PROV_W L"Microsoft Base Cryptographic Provider v1.0" #else static const WCHAR MS_DEF_PROV_W[] = { 'M','i','c','r','o','s','o','f','t',' ', 'B','a','s','e',' ','C','r','y','p','t','o','g','r','a','p','h','i','c',' ', 'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 }; #endif In my case this breaks for GCC 3.4: /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o cert.o cert.c cert.c:312: error: invalid initializer Gerald PS: The patch below avoids this breakage on my test system, but is obviously not the real fix. Index: cert.c =================================================================== RCS file: /home/wine/wine/dlls/crypt32/tests/cert.c,v retrieving revision 1.36 diff -u -3 -p -r1.36 cert.c --- cert.c 12 Jan 2007 19:56:12 -0000 1.36 +++ cert.c 13 Jan 2007 17:08:00 -0000 @@ -309,7 +309,10 @@ static void checkHash(const BYTE *data, } static WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e','m','p',0 }; -static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; +static WCHAR ms_def_prov_w[] = { 'M','i','c','r','o','s','o','f','t',' ' , + 'B','a','s','e',' ','C','r','y','p','t','o','g','r','a','p','h','i','c', ' ', + 'P','r','o','v','i','d','e','r',' ','v','1','.','0',0 }; + static void testCertProperties(void) {

1 0

re: New list subscriber - Question about gdi:widenpath
by Dan Kegel Jan. 13, 2007

Jan. 13, 2007

Hi Laurent! You wrote: >I'm trying make a french software called Navigation, used by airplane >pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? >The point is this software needs gdi:widenpath to work. I'd just like to >know if this function is planned for the next release or if I will have >to wait a little more. It's not planned, as far as I know. If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 4

Re: Paul Vriens : crypt32/tests: Cast-qual warning fixes.
by Michael Stefaniuc Jan. 13, 2007

Jan. 13, 2007

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 259c06ffc93d690fa5105b1451e519aa1c92b72e > URL: http://source.winehq.org/git/wine.git/?a=commit;h=259c06ffc93d690fa5105b145… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 15:51:02 2007 +0100 > > crypt32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/crypt32/tests/cert.c:312: invalid initializer make[2]: *** [cert.o] Error 1 > @@ -309,8 +308,8 @@ static void checkHash(const BYTE *data, > propID); > } > > -static const WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e', > - 'm','p',0 }; > +static WCHAR cspNameW[] = { 'W','i','n','e','C','r','y','p','t','T','e','m','p',0 }; > +static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation error but renders the exercise moot. > > static void testCertProperties(void) > { > > > --- > > dlls/crypt32/tests/cert.c | 113 ++++++++++++++++++++++----------------------- > 1 files changed, 56 insertions(+), 57 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=259c06ffc93d690fa5105… > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

GreenVille font, is it still available? I have a question about it.
by Wierd_w Jan. 13, 2007

Jan. 13, 2007

Markus Amsler wrote: >I neither fully understood it, but here my opinion. It >looks like the >"only" problem he has is the TrueType hinting, which >affects small font >sizes. As long as the kerning (=width of a glyph) is >correct, and the >font looks somehow similar, it should be suitable for >wine's need. So it >should be possible to convert Larry's TTF version with >fontforge to SDF, >and you're done. Adding hinting is IMO a second step. This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.) http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(7%20… http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(11%2… http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(14%2… As you can see, there is a VERY LARGE discrepency between greenville (without TTF instructions) and MS Tahoma (Which does use TTF instructions). Type-1 hinting system does not have a mechanism to overcome this incongruity, because the glyphs have been arbitrarily resized using TTF instructions in MS Tahoma, and Type-1 hinting system does not have a mechanism for this. Depending on how far you want to go, you have 3 options as I see them: 1) (Best,but unlikely, due to the intense effort required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely." 2) Use the Type-1 font that is correct at sizes 15 and up, and use a bitmapped font for sizes below that and have WINE perform the substitution. 3) Adapt FontForge to inject SBIT record data (Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes. The last one seems the most workable, but I am unsure if .OTF files can support SBIT data records, although they are a part of the ".ttf wrapper" spec used by OTF files.--- More research would need to be performed to determine the viability of this option. Theoretically, the rasterizer should check for the existance of SBIT records, and if it finds one, simply pull the bitmap from the record, and pass it on through, totally skipping the rasterizer. I would check with Freetype's documentation to see if SBITs are supported with OTF under freetype. MS Typography has this to say concerning SBITs and OTF files: http://www.microsoft.com/typography/otspec/recom.htm <quote> Embedded Bitmaps Three tables are used to embed bitmaps in OpenType fonts. They are the 'EBLC' table for embedded bitmap locators, the 'EBDT' table for embedded bitmap data, and the 'EBSC' table for embedded bitmap scaling information. OpenType embedded bitmaps are also called 'sbits'. The behavior of sbits within an OpenType font is essentially transparent to the client. A client need not be aware whether the bitmap returned by the rasterizer comes from an sbit or from a scan-converted outline. The metrics in 'sbit' tables overrule the outline metrics at all sizes where sbits are defined. Fonts with 'hdmx' tables should correct those tables with 'sbit' values. 'Sbit only' fonts, that is fonts with embedded bitmaps but without outline data, are permitted. Care must be taken to ensure that all required OpenType tables except 'glyf' and 'loca' are present in such a font. Obviously, such fonts will only be able to return glyphs and sizes for which sbits are defined. 1. These metrics are returned as part of the logical font data structure by the GDI CreateLogFont() API. 2. These metrics are returned by the Apple Advanced Typography (AAT) GetFontInfo() API. </quote> ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

2 1

Re: Paul Vriens : secur32/tests: Cast-qual warning fixes.
by Michael Stefaniuc Jan. 13, 2007

Jan. 13, 2007

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 6c3efd1c32b1f9054e82a684da6ab54a599f252d > URL: http://source.winehq.org/git/wine.git/?a=commit;h=6c3efd1c32b1f9054e82a684d… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Fri Jan 12 14:01:16 2007 +0100 > > secur32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/secur32/tests/schannel.c: In function `testAcquireSecurityContext': dlls/secur32/tests/schannel.c:119: invalid initializer make[2]: *** [schannel.o] Error 1 > > --- > > dlls/secur32/tests/schannel.c | 11 ++++++----- > 1 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/dlls/secur32/tests/schannel.c b/dlls/secur32/tests/schannel.c > index ca870f4..0bbd96b 100644 > --- a/dlls/secur32/tests/schannel.c > +++ b/dlls/secur32/tests/schannel.c > @@ -116,12 +116,13 @@ static void testAcquireSecurityContext(v > PCCERT_CONTEXT certs[2]; > HCRYPTPROV csp; > static CHAR unisp_name_a[] = UNISP_NAME_A; > + static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation error but renders the exercise moot. > BOOL ret; > HCRYPTKEY key; > CRYPT_KEY_PROV_INFO keyProvInfo; > > - keyProvInfo.pwszContainerName = (LPWSTR)cspNameW; > - keyProvInfo.pwszProvName = (LPWSTR)MS_DEF_PROV_W; > + keyProvInfo.pwszContainerName = cspNameW; > + keyProvInfo.pwszProvName = ms_def_prov_w; > keyProvInfo.dwProvType = PROV_RSA_FULL; > keyProvInfo.dwFlags = 0; > keyProvInfo.cProvParam = 0; bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

wine kills X
by Stefan Leichter Jan. 12, 2007

Jan. 12, 2007

Hello, when i start wine, my X gets terminated. The logfile Xorg.0.log shows --------------------------------------------------------------------- Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c4354] 1: [0xb7f48420] Fatal server error: Caught signal 11. Server aborting --------------------------------------------------------------------- Last line in wine's relay log is: X connection to :0.0 broken (explicit kill or server shutdown). The call stack is: 0009:Call PE DLL (proc=0x7e950b00,module=0x7e8f0000 L"winex11.drv",reason=PROCESS_ATTACH,res=(nil)) 0009:Call ntdll.LdrLoadDll(00160070 L"C:\\Programme\\camLine\\ECoFrame 1.8.0\\java\\jre\\bin;.;c:\\windows\\system32;c:\\windows\\system;c: \\windows;c:\\windows\\system32;c:\\windows;c: \\windows\\Microsoft.NET\\Framework\\v2.0.50727",00000000,0033f334,0033f308) ret=7ee745db 0009:Call kernel32.LoadLibraryA(0033f540 "winex11.drv") ret=7eaeb5e0 0009:Call gdi32.CreateDCW(7ec1492a L"DISPLAY",00000000,00000000,00000000) ret=7eb90a8f 0009:Call PE DLL (proc=0x7ec10330,module=0x7eb60000 L"user32.dll",reason=PROCESS_ATTACH,res=0x1) 0009:Call ntdll.LdrInitializeThunk(00000000,00000000,00000000,00000000) ret=7ee82bb5 My system is: Athlon XP 2700 NVIDIA GPU GeForce4 Ti 4200 (with NVIDIA driver version 1.0-9631) Debian Etch Last system modification was an update of the debian system with the availabe patches on 05.01.2007. This is most probably the root of the problem. Can someone please give me an idea how to fix this problem Thanks Stefan

4 5

Re: GreenVille font, is it still available? I have a question about it.
by Louis. Lenders Jan. 12, 2007

Jan. 12, 2007

Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis Wierd_w <wierd_w(a)yahoo.com> wrote: --- "Louis. Lenders" wrote: > Hi, i got your email address from one of the Reactos > developers. AFAIK you have been working on a Tahoma > compatible font called Greenville. I was wondering > if you still have it, and if you were willing to > license this LGPL, so that it could be included in > Wine project. Sure I could. I would be happy to release the glyphset that I have started on, but the reason I never finished the project was because of "Differences" between the rasterizers in FreeType and MS Windows. These differences would have required me to learn native truetype assembler to resolve, because of (in my opinion) "overzealous" freetype developers attempting to take full advantage of the hint system's tolerances. (Better explanation: MS Windows' rasterizer only blends to 16 shades of grey, instead of the theoretical maximum of 256 shades. There is a REASON for doing this: Namely, it makes it possible for visual hinting systems, like the software that I used to work on Greenville, to produce a visually high-quality font, without using exact binary precision with the use of hinting instructions; It allows for a degree of "leniency" in the rasterizer's interperetation of a glyph outline. Because Freetype wants to use the full theoretical maximum to achieve more shades of grey, you must be "Spot on dead on the money" accurate with the use of hinting instructions, or else the font will have 'blurry' edges. Throw into that the fact that the "Delta" instruction is patented by Apple computer corporation, and refuses to sell Freetype a license, it makes it VERY VERY VERY difficult to get Freetype to even render the glyph even kind-of correctly to begin with. It is possible to 'patch' freetype to turn off some of this overzealousness, and even to turn on the native bytecode interpereter-- but even then the test case TTF files I generated (that look just fine in windows) look asthetically gut-wrenching in freetype.) After spending 6 months trying (and failing) to resolve these internal rendering troubles, (and even considering the implementation of Scalar Bitmaps (SBIT)data so that I wouldnt HAVE to mess with Freetype's CRAP, and ending up with a 600kb font file.) I decided that enough was enough. Since the software that I used was VERY expensive (over 300$ US for the STUDENT DISCOUNTED version), and uses a proprietary working format, I would instead be happy to send you the glyph metrics and kerning data in Adobe format, and the actual Glyph set in your choice of vector format. (Note, I spent 2 weeks looking for a suitable TTF editing suite from the freesoftware community (You know, one that would *gasp!* Run on windows, where I could quickly test the fonts!), and came up empty handed. this is why I shelled out the big bucks for FontLab. The Free Software community's gestalt predjudices have shot it in the foot this time.) The actual HINTING process would then be up to you, but be prepared to have your hair turn grey, and to develop ulcers. In order to achieve a strong level of clean resemblence to Tahoma, you *WILL* need to use Truetype, OR, a bitmapped font set. Adobe Type-1 fonts (God, so many tools for that in the FOSS community, but not a SINGLE ONE for TTF hints!...) will not be suitable, because they lack the necessary hinting control (Only stem and leaf, instead of Vector Node Deform, like TTF-- Means that round contours, like in the letter O or G, will NEVER be as clean in an adobe type-1, as they will be with TTF.) I am currently at the college, and dont have access to my software at the moment, but when I get home this evening I will begin cleaning up my old resources and packaging them. Any particular preference on a vector format? I CAN package the raw glyphs into an unhinted Adobe Type-1, but you will have to do a vector conversion to work on them as a TTF. That shouldnt be a problem though. Likewise, I could also send an unhinted TTF, with the kerning data allready merged. If one of these would be suitable, let me know, and if not-- please specify one. ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

2 1

Wine-cvs time-stamp timezone
by Andrew Talbot Jan. 12, 2007

Jan. 12, 2007

Hi, I just thought I should mention that the timestamps for "Last message date:" and "Archived on:" at http://www.winehq.org/pipermail/wine-cvs/2007-January/ are currently given as CDT times, whereas those of the individual patches are correctly shown as CST. Thanks, -- Andy.

1 0

New list subscriber - Question about gdi:widenpath
by Laurent Vromman Jan. 12, 2007

Jan. 12, 2007

Hi, My name is Laurent. I'm french, 23 year old, software designer for a huge european company. I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. I'd like to provide a patch for this particular function but unfortunatly, my development skills are far to low to do it without any help. Does anyone have informations about this function ? Thank you for your help. Laurent

1 0

Re: Implement SQLGetInstalledDrivers in odbccp32
by Detlef Riekenberg Jan. 12, 2007

Jan. 12, 2007

At first: Congratulations for the commit of your Patches. On Do, 2007-01-11 at 09:29 -0800, Bill Medland wrote: > Bill Medland (billmedland(a)shaw.ca) > Implement GetInstalledDrivers in odbccp32 > BOOL WINAPI SQLGetInstalledDriversW(LPWSTR lpszBuf, WORD cbBufMax, > WORD *pcbBufOut) > + else if ((reg_ret = RegOpenKeyExA (HKEY_LOCAL_MACHINE /* The drivers does not depend on the config mode */, > + "Software\\ODBC\\ODBCINST.INI\\ODBC Drivers", 0, KEY_READ /* Maybe overkill */, > + &hDrivers)) == ERROR_SUCCESS) We want to eleminate all CrossCalls: http://wiki.winehq.org/CrossCallsWtoA Please convert RegOpenKeyExA and the string to UNICODE. Thanks -- By by ... Detlef

3 2

Re: configure: add ncursesw detecting [try 2]
by Alexandre Julliard Jan. 12, 2007

Jan. 12, 2007

Vitaly Lipatov <lav(a)etersoft.ru> writes: > Try 2, with ncursesw/ncurses detecting > In order to build wineconsole run properly in utf8 locale, we use ncursesw, > which can handle wchar strings. Why would you need wchar strings if you use utf-8? Have you configured your locale properly? -- Alexandre Julliard julliard(a)winehq.org

4 14

python-to-c++ compiler under wine
by Mark Dufour Jan. 12, 2007

Jan. 12, 2007

hi there, while trying to get an experimental python-to-c++ compiler (http://mark.dufour.googlepages.com) to run under wine, I found a not-so complicated test case that crashes. it is a simple C++ program, converted from 57 lines of Python. it is quite self-contained, and only uses the Boehm GC, but it crashes early and consistently. I corresponded with mike hearn about this, but he is too busy atm to look at it further. here is a mail of me to him, with a link to an archive with an .exe that crashes (but works under windows), the .py and .?pp source code, and a crash log with debugging symbols. it would be great if any of you here would have a look at it. --- I tried to minimize the test program so it still crashes. the attachment (t37.py, 56 lines) very quickly and consistently crashes when trying to print out a list of integers: def propagate(lit, mods, failed_literal=0): .. print 'prop', lit print occurrence[3] this happens after calling just a few functions (solve_rec, lookahead, lookahead_variable, propagate) and no backtracking. in C++ terms, occurrence is a list<list<list<int> *> *> *. occurrence[3] is then a list<list<int> *> *. occurrence[3] is a list of 6 'clauses'. it always goes wrong on printing the 3rd clause (or list<int> *), at the line 'r->unit += repr.. ' below, in the file builtin.hpp: template<class T> str *list<T>::__repr__() { str *r = new str("["); for(int i = 0; i<this->__len__();i++) { r->unit += repr(units[i])->unit; if (i<this->__len__()-1) r->unit += ", "; } r->unit += "]"; return r; } now what happens in repr(..) is a bit complicated because of templatry and va_args stuff and all, but I would think that if the clause is not corrupt it should just work.. btw. a list<T> uses a vector<T> in it called 'units', as can be seen above. here's a bundle of files (crash log, t37.py, t37.?pp, t37.exe..): http://mark.dufour.googlepages.com/shedskin_crash.tgz --- thanks for any help! mark dufour. -- "One of my most productive days was throwing away 1000 lines of code" - Ken Thompson

1 0

Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
by Vitaliy Margolen Jan. 12, 2007

Jan. 12, 2007

Christoph Frick wrote: > with Vitaliy's patches i tried my games yesterday and everything seemed > ok (RBR works again). but my clutch on the wheel did not work and also That's a good news. I was hopping not to brake too many things while reorganizing the dinput. > @@ -128,11 +122,20 @@ struct JoystickImpl > /* The 'parent' DInput */ > IDirectInputImpl *dinput; > > + /* autodetecting ranges per axe by following movement */ > + LONG havemax[8]; > + LONG havemin[8]; I could never understood why we need these? In other joystick_linux the range assumed to be 0 - 0xffff. > /* joystick private */ > /* what range and deadzone the game wants */ > - LONG wantmin[ABS_MAX]; > - LONG wantmax[ABS_MAX]; > - LONG deadz[ABS_MAX]; > + LONG wantmin[8]; > + LONG wantmax[8]; > + LONG deadz[8]; Can we move these into separate struct like it's done in joystick_linux? It's much cleaner end eventually will allow a better integration of two. And can you use spaces instead of tabs please? > @@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid, const void *jvt, IDirectInputIm > /* Supported Axis & POVs should map 1-to-1 */ > for (i = 0; i < 8; i++) > { > - if (!test_bit(newDevice->joydev->absbits, i)) continue; > + if (!test_bit(newDevice->joydev->absbits, i)) { > + newDevice->axes[i] = -1; > + continue; > + } Can you please don't brake the good readable style? Please put that curly bracket into separate line, and use 4 space indentation. > + fake_current_js_state(newDevice); > + Can you explain what this suppose to do? Why do we need to "fake current state" everywhere? > + int axe = This->axes[ie.code]; It's an "axis" not an "axe" :) Vitaliy.

2 4

Re: [PATCH 1/1] msi: MsiGetPropertyA return wrong length when called from a custom action.
by Dmitry Timoshkov Jan. 12, 2007

Jan. 12, 2007

"Mike McCormack" <mike(a)codeweavers.com> wrote: > This is a hack, however the correct way to achieve bug compatiblity is > complicated. > > MSI should run custom actions in a separate process and communicate with > the main installer process via COM. This is quite a lot of work which > needs to be done anyway, but this patch will make us bug compatible with > Microsoft's implementation in the mean time. > > Furthermore, writing a test case for this behavior requires adding a dll > contain custom action code to the dlls/msi/tests directory. I can > supply an MSVC project showing the problem. > > See bug 5768 (http://bugs.winehq.org/show_bug.cgi?id=5768) for more details. Does behaviour of MsiGetPropertyA and MsiGetPropertyW differ in that case? I'd be interested to have a look at the test case. > --- a/dlls/msi/custom.c > +++ b/dlls/msi/custom.c > @@ -439,6 +439,8 @@ static DWORD WINAPI ACTION_CallDllFunction(thread_struct *stuff) > TRACE("calling function (%s, %s)\n", debugstr_w(stuff->source), > debugstr_w(stuff->target)); > > + TlsSetValue( tls_slot, (void*) 1 ); Shouldn't this be reset to 0 once a custom action has finished? -- Dmitry.

2 1