wine-devel January 2007

wine-devel@winehq.org

137 participants
274 discussions

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

13 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

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 12 Jan '07

12 Jan '07

"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

← Newer
1
...
12
13
14
15
16
17
18
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2007