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

Re: Outreach to windows ISVs

by Andreas Mohr

Hi, On Sun, Dec 11, 2005 at 10:33:00PM -0800, Dan Kegel wrote: > At the Desktop Architects Meeting at OSDL, one of the > big topics was how to make life easier for ISVs that want > to start supporting Linux. So I put together a little page > aimed at Windows ISVs who are interested in supporting > the Linux market using Wine, but aren't quite sure how to go about it. > The page is at > http://kegel.com/wine/isv/ > Comments, anyone? Big Fat Mistake: nothing relevant mentioned on that page. IOW, nobody will find it, and that's a problem since a vendor *needs* to search for such information since he certainly will not know your URL by heart ;) Some important missing keywords/topics: "porting", "MFC", "Visual Basic", "Unix", "win32", "api", "toolkit". Those omissions alone would account for a > 50% internet search failure rate, I'm sure ;) BTW, big thanks for all your Linux Desktop-centric efforts! Andreas Mohr

Dec. 12, 2005

Re: PATCH: handle redirect to https

by Marcus Meissner

On Mon, Dec 12, 2005 at 01:58:37AM -0600, Robert Shearman wrote: > Marcus Meissner wrote: > > >Hi, > > > >Redirect from http to https currently segfaults our > >wininet implementation. > > > >Exposed by the Google Earth update check. > > > >Ciao, Marcus > > > >Changelog: > > When redirecting, do not forget to reinit NETCON. > > > > > > This shouldn't be necessary. The NETCONNECTION structure should have > been re-initialized to its post-NETCON_init state after calling > NETCON_close. There are two possible reasons I can think of that would > cause a crash. The first is the NETCONNECTION stuff not being > thread-safe. The second is possible ref-counting issues on the SSL > method object "meth". Can you show me the backtrace? (gdb) r GoogleEarth.exe Starting program: /usr/bin/wine-pthread GoogleEarth.exe fixme:atl:AtlModuleInit SEMI-STUB (0x466920 0x4658f8 0x400000) fixme:imm:ImmGetContext (0x10020): stub fixme:imm:ImmReleaseContext (0x10020, 0x558fa9b0): stub fixme:imm:ImmGetContext (0x10020): stub fixme:imm:ImmReleaseContext (0x10020, 0x558fa9b0): stub Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1433261760 (LWP 17926)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x55fe61c6 in NETCON_secure_connect (connection=0x55983b40, hostname=0x55983970) at netconnection.c:348 #2 0x55fd9bb1 in HTTP_HttpSendRequestW (lpwhr=0x55983b10, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0, dwContentLength=0, bEndRequest=1) at http.c:2262 #3 0x55fd8375 in HTTP_HandleRedirect (lpwhr=Cannot access memory at address 0x55c0c16c ) at http.c:1890 #4 0x55fd95c2 in HTTP_HttpSendRequestW (lpwhr=0x55983b10, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0, dwContentLength=0, bEndRequest=1) at http.c:2094 #5 0x55fda480 in HttpSendRequestW (hHttpRequest=0x3, lpszHeaders=0x0, dwHeaderLength=0, lpOptional=0x0, dwOptionalLength=0) at http.c:1703 #6 0x56ffb887 in ?? () (gdb) up #1 0x55fe61c6 in NETCON_secure_connect (connection=0x55983b40, hostname=0x55983970) at netconnection.c:348 348 ctx = pSSL_CTX_new(meth); (gdb) print meth $1 = (SSL_METHOD *) 0x0 (gdb) print pSSL_CTX_new $2 = (SSL_CTX *(*)()) 0 (gdb) print *connection $3 = {useSSL = 0, socketFD = 38, ssl_s = 0x0, peek_msg = 0x0, peek_msg_mem = 0x0} NETCON_init() just never got called with useSSL before. Ciao, Marcus

Dec. 12, 2005

Re: Outreach to windows ISVs

by Brian Vincent

On 12/11/05, Dan Kegel <dank(a)kegel.com> wrote: > At the Desktop Architects Meeting at OSDL, one of the > big topics was how to make life easier for ISVs that want > to start supporting Linux. So I put together a little page We discussed something similar last year at WineConf about putting together a page for commercial organizations (including ISV's) looking to use Wine. It's been on my to-do list for the last 6 months.. but I haven't gotten to it. Just for fun, here's an outline of what it will contain based on what we discussed at WineConf: 1. Wine's goal is to make Windows apps first class citizens on Linux. While some might not see that as a "real" Linux app, it lowers the barrier of entry for many folks. 2. We might not have a CEO or a board of directors, but we have a real project structure with real commercial backing. 3. We have professional development tools including version control and regression testing. 4. Linux will be part of any solution developed in the next 5 years. At the very least it will be assessed. By simply having a version of software that runs with Wine, an ISV can increase sales of their Windows software by ensuring they have cross-platform compatibility. Anyone have anything else to add? -Brian

Dec. 12, 2005

Re: PATCH: handle redirect to https

by Robert Shearman

Marcus Meissner wrote: >Hi, > >Redirect from http to https currently segfaults our >wininet implementation. > >Exposed by the Google Earth update check. > >Ciao, Marcus > >Changelog: > When redirecting, do not forget to reinit NETCON. > > This shouldn't be necessary. The NETCONNECTION structure should have been re-initialized to its post-NETCON_init state after calling NETCON_close. There are two possible reasons I can think of that would cause a crash. The first is the NETCONNECTION stuff not being thread-safe. The second is possible ref-counting issues on the SSL method object "meth". Can you show me the backtrace? -- Rob Shearman

Dec. 12, 2005

Re: Crashes with TPB reader

by Robert Shearman

Pierre Ossman wrote: > My problem is that the program TPB reader > (http://www.daisy.org/tpbreader/download.asp?lang=en) a DAISY book > reader, crashes in different exotic ways. It fails in different ways > depending on if I run it in wine or crossover. > > In crossover the application starts but displays the error: > > Run-time error '287': > Application-defined or object-defined error. > > If I enable some more output (CX_DEBUGMSG=err+all,fixme+all), then it > behaves differently. Now I get: > > Run-time error '-1 (ffffffff)': > Automation error > > After a few seconds another one pops up: > > Run-time error '448': > Named argument not found > > The first error can also be replicated by piping debug output to a > file. I managed to get dumps of both cases (cx1.dump, cx2.dump). > > > Now the question is if anyone here can give me a guess at what the > problem is? Our primary concern is too determine if it will require > more effort to fix wine/crossover to support this application or to > write a new, native DAISY reader. So just being able to determine > which function is lacking would be a tremendous help. This looks like a VB app, correct? It sounds like it would be quite a bit of work to write a native DAISY reader. My guess is that the error is coming from dlls/oleaut32/typeinfo.c:ITypeInfo_fnInvoke. It could be caused by another oleaut32 function as well though. I don't have time to debug the issue myself, but I can give you pointers for where to look if you want to debug it yourself. Alternatively, I can also direct you to the CodeWeavers website if you would consider paying us to get the application working for you. -- Rob Shearman

Dec. 12, 2005

Re: shell32: add missing ole init

by Robert Shearman

Eric Pouech wrote: >RCS file: /home/cvs/cvsroot/wine/wine/dlls/shell32/shellole.c,v >retrieving revision 1.87 >diff -u -u -r1.87 shellole.c >--- dlls/shell32/shellole.c 10 Nov 2005 11:15:22 -0000 1.87 >+++ dlls/shell32/shellole.c 11 Nov 2005 08:53:25 -0000 >@@ -193,6 +193,7 @@ > > } else { > >+ CoInitialize(0); > /* load an external dll in the usual way */ > hres = CoCreateInstance(myclsid, pUnkOuter, CLSCTX_INPROC_SERVER, refiid, ppv); > goto end; > > Where is the matching CoUninitialize call? This is usually necessary because destructing a COM apartment in DLL_THREAD_DETACH instead of CoUninitialize can cause deadlocks. It might be that the native version also doesn't uninitialize the apartment, but this needs tests. -- Rob Shearman

Dec. 12, 2005

Outreach to windows ISVs

by Dan Kegel

At the Desktop Architects Meeting at OSDL, one of the big topics was how to make life easier for ISVs that want to start supporting Linux. So I put together a little page aimed at Windows ISVs who are interested in supporting the Linux market using Wine, but aren't quite sure how to go about it. The page is at http://kegel.com/wine/isv/ Comments, anyone? Thanks, Dan -- Why won't Johnny run Linux? See http://kegel.com/linux/comfort

Dec. 12, 2005

[WGL] unifying WGL extensions headers

by Aric Cyr

First just a quick update on my work converting wined3d from using glx to using wgl. I have some (i.e. one :( ) basic dx9 demos working, and am trying to iron out a bug I can't track down easily since it is crashing in the GL library (in glDrawArrays) and I don't get a backtrace. I know the spot it is crashing so I just have to find out why. My current guess is that I have some GL context stuff fubar'd somewhere. Anyways, now on to my real reason for this post. Currently there are a _lot_ of #defines for wgl extensions in dll/opengl32/wgl_ext.c. These are all necessary of course, but since they are also becoming necessary for wined3d to use (due to my glx->wgl port) I though it might be better if we included a real wglext.h into include/ and use that. SGI maintains a version of this at http://oss.sgi.com/projects/ogl-sample/ABI/wglext.h The advantage of using this is that we get all WGL extensions' function definitions and constants, and SGI maintains it for us :) So I'd like to propose a patch (which I have done already if there are no objections): 1) add wglext.h from SGI's site to include/ 2) change dlls/opengl32/wgl_ext.c to include wglext.h and remove redundant #defines 3) rename (CVS = ich!) dlls/opengl32/wgl_ext.h to dlls/opengl32/wgl_private.h since that is really what it is and the current name is too close to the official one IMO. This file is only used by wgl.c and wgl_ext.c anyways, so name is not too important other than esthetics. Comments appreciated!

Dec. 12, 2005

Re: shlwapi.dll: IUnknown_CPContainerInvokeParam

by Cihan Altinay

Quoting Vitaliy Margolen <wine-devel(a)kievinfo.com>: > Sunday, December 11, 2005, 7:04:58 PM, Cihan Altinay wrote: > > http://www.winehq.org/pipermail/wine-patches/2005-October/021101.html > > > > Is there are reason why this patch wasn't applied? > > G-Ware crashes when invoking help without it. > > I do not think it is correct. That's why I recalled it back. > I'm not sure about number of parameters nor the calling conversion. This > function is not documented anywhere and I have not found any references > to it either. > > If you need this that means you are trying to use native shdocvw which > needs native shlwapi. Thanks for the info, you are right. Cihan

Dec. 12, 2005

Re: shlwapi.dll: IUnknown_CPContainerInvokeParam

by Vitaliy Margolen

Sunday, December 11, 2005, 7:04:58 PM, Cihan Altinay wrote: > http://www.winehq.org/pipermail/wine-patches/2005-October/021101.html > > Is there are reason why this patch wasn't applied? > G-Ware crashes when invoking help without it. I do not think it is correct. That's why I recalled it back. I'm not sure about number of parameters nor the calling conversion. This function is not documented anywhere and I have not found any references to it either. If you need this that means you are trying to use native shdocvw which needs native shlwapi. Vitaliy

Dec. 12, 2005