September 2006 - Wine-Devel

Re: How to deal with both git trees

by Mike McCormack

Paul Vriens wrote: > I've sent in a patch that got some remarks by Juan Lang. The patch is > already applied to mmbranch. > > Most patches sent to wine-patches that have (valid) comments will not be > applied by AJ. > > Should I now resend to make sure it gets applied when AJ is back AND > sent a patch to fixup mmbranch. Or will the previous one be reverted and > the next applied to mmbranch? Resend the whole patch as it should be, and I'll revert the old one and reapply the one you send. That's what I've done with Roderick's x11drv/opengl patches, and it should make it easier for Alexandre to just pick the newest one from wine-patches when he gets back from holidays. Mike

Sept. 4, 2006

How to deal with both git trees

by Paul Vriens

Hi, I've sent in a patch that got some remarks by Juan Lang. The patch is already applied to mmbranch. Most patches sent to wine-patches that have (valid) comments will not be applied by AJ. Should I now resend to make sure it gets applied when AJ is back AND sent a patch to fixup mmbranch. Or will the previous one be reverted and the next applied to mmbranch? Cheers, Paul.

Sept. 4, 2006

Re: Build problems with latest mmbranch

by Mike McCormack

Paul Vriens wrote: > make[2]: Entering directory `/wine/wine-git/dlls/opengl32' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o wgl.o wgl.c > wgl.c:104: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘p_glXGetProcAddressARB’ > wgl.c: In function ‘wglGetProcAddress’: > wgl.c:325: error: ‘p_glXGetProcAddressARB’ undeclared (first use in this function) Hi, I committed Thunderbird's latest patch... hopefully this fixes the problem. Mike

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Mike McCormack

Julien wrote: > I was very interested in comparing the implementation status of reactos > and wine. So I coded a little python script to list all the api that are > implemented in reactos AND are only stub in wine. Attached to this mail > is the list of identified functions. > > One may note that most of these functions are in the setupapi dll. This > is particularly interesting as the setupapi code is LGPL-licenced in > Reactos (and was already part of the audit). Code that originates in ReactOS will generally not be accepted into Wine due to that project's acceptance of developers that participate in "dirty" reverse engineering (ie. translating assembly code to C). Please don't submit code from ReactOS to wine-patches. Mike

Sept. 4, 2006

Setupapi [0/6] : ReactOS setupapi patches

by Hervé Poussineau

Hello, As setupapi merge from ReactOS has been a recurrent demand [1], I'm doing this set of patches. Note that I'm not especially interested by this merge, but I do it only to please people. I've already spent one day to do them, I don't want to loose more of my time [2]. Note also that I'm not the only one who can provide better patches if those ones don't fullfill requirements. You're welcome (yes, you! the reader of Wine-patches/Wine-devel ML) to improve them if needed. The goal of this set of patches is to set a solid ground to implement lots of missing functions in setupapi. I've tried to cut them in smallest possible parts. Additionnaly, this patchset implements SetupDiEnumDeviceInfo and (mostly) SetupDiGetClassDevsExW Patch 1/6 Move Class related fonctions to their own file devclass.c No code change. Patch 2/6 Forward SetupDiGetClassDevsA/W and SetupDiGetClassDevsExA to SetupDiGetClassDevsExW This patch depends of patch 1 Patch 3/6 Add in-memory structures needed to implement SetupDiGetClassDevsExW in a following patch. Basically, we have one list container (structure DeviceInfoSet) which will contain multiple devices (structure DeviceInfoElement) in a chained list Patch 4/6 Update SetupDiCreateDeviceInfoList and SetupDiCreateDeviceInfoListA/W to initialize all fields of in-memory structure This patch depends of patch 3 Patch 5/6 Check parameters in SetupDiGetClassDevsExW stub, and create device set if needed. Now, only the real work needs to be done. This patch depends of patches 1, 3 and 4 Patch 6/6 Implement SetupDiEnumDeviceInfo This patch depends of patches 3 and 4 Regards, Hervé, ReactOS developper [1] http://marc.theaimsgroup.com/?l=wine-devel&m=115721353431733&w=2 http://marc.theaimsgroup.com/?l=wine-devel&m=113584611128655&w=2 [2] Because I'm not a Wine user, nor have Linux on my computer

Sept. 3, 2006

Re: [wintrust] Register WINTRUST_ACTION_GENERIC_VERIFY_V2

by Juan Lang

Hi Paul, +static LONG WINTRUST_WriteSingleUsageEntry(CHAR* OID, Any reason that can't be LPCSTR OID instead? That will remove some cast-qual warnings I think. + WCHAR UsageKey[MAX_PATH]; (snip) + /* Turn OID into a wide-character string */ + Len = MultiByteToWideChar( CP_ACP, 0, OID, -1, NULL, 0 ); + OIDW = HeapAlloc( GetProcessHeap(), 0, Len * sizeof(WCHAR) ); + MultiByteToWideChar( CP_ACP, 0, OID, -1, OIDW, Len ); + lstrcatW(UsageKey, OIDW); This could overflow UsageKey. It would be better to allocate UsageKey as sizeof(Trust) + sizeof(Usages) + Len * sizeof(WCHAR), then concatenate the strings into it. I'm not sure whether there's a maximum length for a registry key, but it's certainly longer than MAX_PATH if it exists. + if (Res != ERROR_SUCCESS) goto error_close_key; + +error_close_key: + RegCloseKey(Key); This goto is unnecessary, the target of the branch is the next instruction anyway. Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 3, 2006

Re: Font issue - workaround found

by Dan Kegel

On 9/3/06, Timm <timmr(a)atlanticbb.net> wrote: > My one win app that makes me a devotee of WINE is TablEdit > (demo at www.tabledit.com/download/tabled32.exe) > has a custom font , tef260.ttf, that has failed to display since > somewhere after ver 9.6. The program installs the font into > c:\windows\font, but can not display it within the program, instead > displaying for the most part, empty squares. > > I tried putting/removing tef260.ttf into /usr/local/share/wine/fonts, > /usr/local/share/fonts, and the wine windows/fonts directories in all > permutations. The only way I got it to display was to remove ALL fonts > from these three directories and install tef260.ttf into an X11 font > directory along with other win ttf fonts. This forces WINE to build a > cachedmetrics file like it used to, and the font is displayed properly > in the program. That's good to know. I see you've put that info into the appdb: http://appdb.winehq.org/appview.php?iVersionId=1599 How about filing a bug report, too? See http://bugs.winehq.org/enter_bug.cgi That will help keep it from falling through the cracks. - Dan

Sept. 3, 2006

Re: Could I get some permissions for Bugzilla?

by Tony Lambregts

Matt Finnicum wrote: > Hello, > I'm not really sure what levels of permissions Bugzilla has, but could > I get the ability to modify bugs? (things like assign them to myself, > mark them as fixed, etc). If it's possibile, I suppose only having > such access to the "wine-richedit" component would be fine, too. > --Matt Finnicum > > > Bugzilla is not that fine grained to allow that. Since you are a developer I have given you rights to confirm and edit bugs. If there are there any other developers that do not have these abilities and want them, Please let me know. -- Tony Lambregts

Sept. 3, 2006

Re: How do I automate the registering of a DLL

by Paul Vriens

On Sun, 2006-09-03 at 16:44 +0200, Paul Vriens wrote: > Hi, > > while I'm working on DllRegisterServer for wintrust, I wanted to make it > 'autorun' when running on a clean system (through wineprefixcreate). > > My thought was to add an entry to the RegisterDllsSection part in > tools/wine.inf but that doesn't seem to work. (regsvr32 wintrust.dll > does work). > > What am I missing? > > Cheers, > > Paul. > Had a closer look. 'make install' in the tools directory makes sure the correct wine.inf is used in wineprefixcreate. Sorry for the noise. Paul.

Sept. 3, 2006

How do I automate the registering of a DLL

by Paul Vriens

Hi, while I'm working on DllRegisterServer for wintrust, I wanted to make it 'autorun' when running on a clean system (through wineprefixcreate). My thought was to add an entry to the RegisterDllsSection part in tools/wine.inf but that doesn't seem to work. (regsvr32 wintrust.dll does work). What am I missing? Cheers, Paul.

Sept. 3, 2006