wine-devel September 2007

wine-devel@winehq.org

108 participants
198 discussions

Re: winhelp, Vector NTI, molecular biologists
by Misha Koshelev 03 Sep '07

03 Sep '07

> 2007/9/3, Misha Koshelev <mk144210(a)bcm.edu>: > Hi everybody, > > So as you all know I've been working on various bug fixes > throughout > wine, with my most significant contributions to date being MSI > OLE > automation support and implementation of http protocol support > in > urlmon. This involvement was driven by my initial experiences > of getting > a key program used by molecular biologists, Invitrogen's > Vector NTI, to > install on wine with a fairly convoluted shell script and > submitting my > first patch to fix a crash with this program; Dan Kegel helped > me iron > out this first patch a lot and furthermore his comments about > how it'd > be nice if such a complicated shell script was not necessary > with wine > got me started with my other patches and the rest, as they > say, is > history. > > So why, you may ask, am I sending all this in an email to > wine-devel? > The short answer is that this is a shameless email to see if I > might > motivate someone to work on our winhelp implementation a bit, > as it is > currently completely useless with Vector NTI. This seems like > a fairly > significant task, and my obligations at school/work have > recently kicked > up quite a bit, making it unlikely I will be able to take it > on anytime > soon. However, I hope to motivate someone with these reasons: > > (i) I feel like I've certainly been doing (and will continue > to do) my > part in helping out wine, and if this in any case motivates > someone > looking for a development direction I would certainly not > object; and > > (ii) My ultimate vision/goal has been to have Vector NTI run > so well > that I could approach Invitrogen and see if they might at the > very least > say something to that effect on their Web site ("add wine + > linux as a > supported platform"), if not package Vector NTI a la Google > Picassa, > which would be great publicity for wine. Also, as you can see > from the > comments on my ubuntuforums howto > http://ubuntuforums.org/showthread.php?t=347095 for a lot of > molecular > biologists, Vector NTI is the only reason they have to > dual-boot/use > VMWare at all (full-disclaimer: this is not 100% true for > myself). So > you could help perhaps a fairly small but non-insignificant > group of > people by doing some work on winhelp. > > Although Vector NTI is a rather large set of programs, > currently I > believe the only things keeping it from installing/working to > a "gold" > level according to winehq definitions are (i) winhelp and (ii) > either > MFC42 implementation (required for WSH to install properly; I > suppose > only a few functions prob are really required, but I'm not > sure how good > an idea having a very small stub MFC42 would be) or JScript > support in > wine. Either item in (ii) seems like a very significant > undertaking, but > (i) seems doable and prob. necessary for a lot of apps. > > So anyhow just my attempt to influence someone to start > working on > winhelp. Sorry for cluttering your inboxes. > > Misha > Btw I should have posted the URL to the demo version: http://download.invitrogen.com/evergreen/Vector%20NTI%20Advance%2010.exe To me the main problem with winhelp here is just that none of the winhelp navigation (Contents, Search, etc.) is implemented, making it difficult to, for example, answer the question "how do I do X?" which I'm sure Invitrogen would care about. From what I understand looking over some of the winhelp bug reports, the way .hlp files are currently processed this would be difficult/slow to implement, so probably a different way of processing them is necessary (don't know more than I read from searching for winhelp in the bugzilla for this tho, haven't investigated it myself). Currently there is also a "bug" where WinHelp returns the incorrect value (WM_SENDDATA in winhelp program returns 0L and thus so does WinHelp which just returns the result of SendMessage, whereas according to MSDN WinHelp() shoudl return non-zero on success). In any case this latter thing would be pretty easy to fix, but I think really the rest of winhelp would need to be fixed for this second part to have any real use (other than removing an annoying "Failed to open help file" dialog). Thanks everybody Misha

1 0

Re: ddraw: fix cases where desc2.u2.dwMipMapCount is 0.
by Stefan Dösinger 03 Sep '07

03 Sep '07

Am Sonntag, 2. September 2007 14:16 schrieb David Hedberg: > (Resending mail after subscribing to list) > > Hi, > > This patch fixes a problem visible in Delta Force Land Warrior and > Delta Force Task Force Dagger, where extra_surfaces would sometimes > get a value of -1 and later cause a "near infinite" loop in > CreateAdditionalSurfaces. I think you should test that in the desc2.dwFlags & DDSD_MIPMAPCOUNT case above, where currently the "Mipmap count is given, nothing to do" comment is. It would be good if you extended the test case in dlls/ddraw/tests/dsurface.c to test the case where the mipmapcount flag is set, but the mipmap count is 0. It could either create a one-level surface (like your patch currently does), or ignore the mipmapcount flag, and create mipmaps until either width and height are 0.

2 2

Re: Window decorations missing on Compiz/Debian Etch
by Maarten Lankhorst 02 Sep '07

02 Sep '07

Michael Jung schreef: > Hi Maarten, > > Thanks for pointing me to the FAQ. The FAQ entry seems to address > primarily OpenGL related issues, however, which I'm currently not > concerned about that much. Given the fact that the window decorations > used to work just fine before the mentioned patch, I would consider > this a regression. > > Bye, > -- > Michael Jung > mjung(a)iss.tu-darmstadt.de > Hi Michael, First of all, please do 'reply all' so a copy gets sent to wine-devel too. Second, if the bug only occurs with compiz/beryl it is really likely that it is a compiz/beryl bug., since it's not really a mature window manager, and has a lot of bugs, even not considering opengl. Cheers, Maarten

2 1

[RFC] [PATCH] GNU make based build system for Winelib applications
by Kirill Smelkov 02 Sep '07

02 Sep '07

Hello Wine developers, Francois! I am going to port some Win32 applications to GNU/Linux and though it would be useful to improve the build system for Winelib applications. Current status and Motivation ============================= 1. Wine in-tree Makefiles for programs & dlls are pretty much good and maintainable, but they lack C++ support. 2. Initial approach taken by winemaker (I used it in 2003-2004) was to adapt Wine's make rules to support C++ . 3. At present winemaker dropped supplying above mentioned rules and generates very simple makefiles. To me this approach have several problems: - lack of dependency tracking - hard to maintain Makefiles. The rules generated are substituted in each Makefile instead of being in one place. - good as a starting point, but not a complete solution. Winemaker already relies on GNU toolchain (in form of gcc and g++), and I though:: Why not use GNU make with all available extensions when necessary, and deploy a simple full-featured build system for Winelib based applications The result is presented here for public review. Comments, suggestions? Features ======== * support C, C++ and resource files. * automatic dependency tracking for C and C++. * beautified build output (to increase SNR and concentrate on errors and warnings). * winemaker patches provided (although I don't know Perl -- help needed, Francois?). * Tested with GNU make 3.81. This version of GNU make was released in 2006 and is present in all recent Linux distributions. Usage example ============= I attach winelib-gnu-make.tar.gz where an interested reader can see Winemake build system usage. For usage example see directory clock+wow32/ . There I provide example of how to build 1 program and 2 dlls. Original clock.exe & wow32.dll processed by winemaker are located in misc/ for comparison.

1 0

Re: [5/5] WineD3D: texkill ignores the .w only in ps 1.x
by Tomas Carnecky 01 Sep '07

01 Sep '07

+ + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0xff00ff00, 0.0, 0); + ok(hr == D3D_OK, "IDirect3DDevice9_CreatePixelShader returned %s\n", DXGetErrorString9(hr)); Is that worth changing? tom

2 1

Re: secur32: Add some missing prototypes to ntsecapi.h.
by Kai Blin 01 Sep '07

01 Sep '07

On Saturday 01 September 2007 02:45:33 Francois Gouget wrote: > --- > include/ntsecapi.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) Thanks, that was on my list, but I didn't get around to it yet. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: [1/3] whhc - add chm compiler
by Vitaliy Margolen 01 Sep '07

01 Sep '07

Miikka Viljanen wrote: > adds the whhc chm compiler under tools/whhc > > And what told you that you can just change the license from GPL to Wine's LGPL by just editing the header? Have you even asked authors of the program? Vitaliy.

1 0

Re: [PATCH] user32: edit control should respond to ctrl + z (try 2)
by Dmitry Timoshkov 01 Sep '07

01 Sep '07

"Lei Zhang" <thestig(a)google.com> wrote: > This patch lets users hit ctrl + Z in edit controls to trigger an > undo. The test case has been improved to check for return values when > appropriate. > + /* select all, cut (ctrl-x), undo (ctrl-z) */ > + SendMessage(hwEdit, EM_SETSEL, 0, -1); > + r = SendMessage(hwEdit, WM_CHAR, 24, 0); > + todo_wine { ok(r == 1, "Expected: %d, got: %d\n", 1, r); } > + r = SendMessage(hwEdit, WM_CHAR, 26, 0); > + todo_wine { ok(r == 1, "Expected: %d, got: %d\n", 1, r); } By "I'd suggest to add checks to make sure that every message you send above really worked." I meant not simply check the SendMessage return values, but actual Edit contents/selection changes tracking. -- Dmitry.

1 0

Jump to page:

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 September 2007