wine-devel March 2003

wine-devel@winehq.org

109 participants
285 discussions

Is it as nontrivial as it appears
by Bill Medland 28 Mar '03

28 Mar '03

I've now got to the stage where I have to look at whether it is possible for a linux process to call into windows dlls. (Don't bother telling me to use winelib to make the linux executable into a winelib one). I've never really thought too hard about it; it has always seemed to me that it ought to be quite trivial; just make sure you call the correct initialisaton functions and there you go. Indeed that has been my response on occasions on c.e.m.w and no-one had corrected me. I've just started looking at it and I get the distinct impression that due to the multiple processes and threads involved it may not be as trivial as I though. Anyone care to comment? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

2 1

WineHQ: still TODO
by Dimitrie O. Paun 28 Mar '03

28 Mar '03

Hi folks, Here is my personal TODO list for our very beautiful WineHQ site. Big Items --------- 1. Integrate Bugzilla into the site 2. Integrate AppDB into the site 3. Integrate the guids into the site Jer, silly question: Bugzilla and AppDB seem to already be written with the 'boxed' approach. I haven't looked at the code, but any fundamental reason we can't simply stick the main Bugzilla or AppDB main box into WineHQ? Medium Items ------------ 4. The Who's Who page is terribly out of date. Also, the organization with VIPs/Core/etc. sucks IMO. The page should include only the active developers, the rest should go into an Acknowledgements page. 5. Speaking of which, we're missing an Acknowledgements page. This should include significant contributors, significant corporate sponsors, funding sources. 6. The Download pages don't feel like. They should refer to the HowTo rather than duplicate the information. Also the Download/Sources is too skinny, needs more meat. 7. The HowTo needs improvements. There's a lot more stuff that we need to add to it. 8. We're missing a History page, that would put everything in context and a nice narative. Small Items ----------- 9. The Contributing page is too heavy, needs better integration with the new Fun Projects/Winelib/Janitorial pages. 10. The Sending Patches needs a bit more work. The .cvsrc link is wrong, maybe a bit more info on how to configure various email clients to not mangle patches, make it more clear that only uniffied diff is acceptable, show an example .cvsrc, how to email a patch (ChangeLog, one patch/per message, etc). Stuff we've been discussing for so long. Tony, I know you've been doing work in this area, maybe you can look into it? 11. TODO/Fun Projects/Janitorial/Winelib pages need constant updating from my site. I'll do that. 12. The Status/UI Status page still needs some work. Help wanted. 13. Get rid of the Miscellaneous section from Status/Core Status. 14. The Search box is too low, one needs to scroll to get to it, even in high resolutions. Any other requests? BTW, why aren't WineHQ CVS commits visible on wine-cvs anymore? -- Dimi.

2 1

Re: Fix incorrect documentation
by Andreas Mohr 28 Mar '03

28 Mar '03

Hi, On Fri, Mar 28, 2003 at 04:35:36PM +0000, Mike Hearn wrote: > I'm surprised nobody caught this one in my previous (duff) patch... the > "uninstaller" app appears to have been forgotten about. Well, I'd caught this in my update, but your version is somewhat better. Applied it ;-) I'm *almost* done with that stuff... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

RE: fix compiling of libs/wine/loader.c on NetBSD
by Patrik Stridvall 28 Mar '03

28 Mar '03

> On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > > It seems the stdint. header file should be included for > > compiling on NetBSD. > > This reminds me: Into which deep hole did Patrik disappear? In the deep hole of having other things to do. :-) Don't worry, I will be back.

1 0

Re: Java in wine?
by Dan Kegel 28 Mar '03

28 Mar '03

Mike wrote: > Perhaps a bit offtopic, but my company has asked me to try and get a > desktop java app we use/are developing here running under Linux. You'd > think, being written in Java, that it'd just be a case of installing the > JVM and running it. Unfortunately, because Java is rather poor at > desktop apps, they've used a load of windows extensions via JNI to try > and make it integrate better. > > That means, the only solution is probably to run a JVM under Wine (short > of rewriting all the native code, which they don't want to do). Now, I > tried the Sun JRE, and it wasn't happy. I expect HotSpot does some wierd > stuff under the covers. So I'm wondering if anybody has walked this road > before, and if there are any other JVMs that might work better under > Wine? What version of Java does the app require? I wonder if perhaps some older Sun JREs run better on Wine than hotspot does. I haven't tried any, but who knows, it might be worth trying. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 15

Contributing page needs fixing
by Mathew McBride 28 Mar '03

28 Mar '03

Web Site matenence: "We are in the process of redoing the web site and we really could use some help. The current beta is located at http://lostwages.winehq.org Here is the current list of bugs that needs attention: 597, 598, 600, 601, 605, 607, 608.If you would like to offer assistance with web maintenace feel free to contact Wine-Develipmont <mailto:wine-devel@winehq.com>." 1) lostwages. 2) D-e-v-e-l-o-p-m-e-n-t Oh, add a link to the mailing lists in the menu if you can.

1 0

Re: I/O Completion Ports (1 of 2)
by Alexandre Julliard 28 Mar '03

28 Mar '03

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > +static int io_completion_send_data( struct thread *thread, void *cookie, struct io_completion_data * data ) > +{ > + struct io_completion_send_data_reply reply; > + int ret; > + > + reply.cookie = cookie; > + reply.signaled = STATUS_SUCCESS; > + reply.bytes_transferred = data->bytes_transferred; > + reply.completion_key = data->completion_key; > + reply.overlapped = data->overlapped; > + if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) == sizeof(reply)) > + return 0; You cannot send different message sizes into the wait_fd pipe, this won't work since pipes don't preserve message boundaries. I'd suggest simply using the normal wait mechanism and then doing a separate call to retrieve the rest of the info. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Any DCOM experts?
by Bill Medland 28 Mar '03

28 Mar '03

On March 27, 2003 12:48 pm, Gregory M. Turner wrote: > On Thursday 27 March 2003 01:08 pm, Bill Medland wrote: > > Hi guys > > > > For the next part of the work I am doing I am trying to figure out if > > there is any way that the DCOM part of one of our products is going to > > work under Wine at the server end. > > > > I am not having much success so far and I was wondering if anyone knows > > whether this is because I don't have things set up properly or if it is > > because of some inherent known lack of functionality. > > > > To start the ball rolling I was working with MSDN's DCOMTST test program > > pair. > > > > I managed to get that working using the local server (after adding the > > definition of IStream to the registry) but am having no luck getting the > > client under Wine to talk to the server under Win98. In fact the client > > side doesn't even seem to send out a single TCP/IP packet. > > There is no implementation of the TCP/IP transport at this time. Wine will > fail to make interprocess calls without any indication of this failure in > some cases. Frankly, I'm pleasantly surprised to hear that even DCOMTST > works. Ah, yes. But the local DCOMTST case is only going to use named pipes or something. And I am actually using the native dlls. And I know that I can use the native rpc across the net (using the "simple" sample program) > The RPC implementation in wine is not up to par yet. DCOM needs RPC to do > it's dirty work, so interprocess RPC is very shaky, and interprocess > between wine and real windows is non-existant. > > The good news is that there are people working on this, in particular, Ove > Kaaven and myself, although we are not exactly making headlines with our > earth-shaking progress at this moment. The bad news is that getting wine > to talk to windows via RPC is a pretty distant target right now; there are > lots of "lower hanging fruit" that will presumably be addressed first. > > > (Aside - Nice demonstration of lazy Microsoft code; in their error > > reporting they call FormatMessage, ignore the return code and somehow > > print the returned error message, even when one hasn't been allocated; I > > guess it only works under Windows because the print routine traps the > > access violation) > > or maybe the thing was supposed to be allocated and wine didn't do it > properly. Always presume wine is at fault, not Microsoft; you will usually > be correct, especially in DCOM territory! No. If a function has a return code that indicates failure then you should test for that failure and not blithely continue as if everything was OK. They call FormatMessage, asking for FormatMessage to allocate the returned string. If nothing else, it could fail to allocate memory in which case it would be stupid to use the "returned pointer" which is just whatever happened to be on the stack at the time. And I noted it failing on Windows too; the printf or whatever simply stopped processing half-way along the format string. > > I am currently running native ole32 and native rpcrt4. > > Then you are really using Microsoft's DCOM implementation, and not wine's. > Which may not be a bad choice if you want it to "just work" Yes please > as much as > possible. I have successfully used native ole32 and rpcrt4 to talk to SQL > server via the MMC interface, quite a bit of RPC involved. It didn't work > too well, but it was interesting to see it work at all. Hm. So something at least is possible (i.e. it is possible to get ole32 to put tcpip packets across the wire) > > The builtin rpcrt4 fails on a call to unimplemented > > RpcServerInqDefaultPrincName but I don't understand why it is even > > calling that; why does it think I have Netware only and why does it think > > this is a server process. > > This is another unimplemented chunk of DCOM: the RPC name services do not > exist. Samba and dce rpc have this feature so it's not unattainable... but > it ain't there yet. The name services and other networked DCOM services > require priveleged ports that wine can't even use without some kind of > medium-scale reconceptualization of the basic wine security model anyhow... > it's easy to imagine reasonable solutions to that too, but it will take > some thought... > > > Anyone an expert in any of this stuff? > > Yes, but unfortuantely, they all seem to work for Microsoft ;) Seriously, > some of it is undocumented, some of it is well documented. There are > probably only a handful of people in the world who could answer some of the > hard questions without reverse-engineering the answers, and they probably > do work for Microsoft. So for wine, we must read the specs and reverse > engineer the rest. It's not a pretty landscape and you will need to be > patient, but I believe there is a light at the end of the tunnel. Good to know. Unfortunately it isn't my patience we are talking about. Do you know of any decent low level documentation that I could read that would explain why the native OLE doesn't even appear to be trying to hit the network? BTW, on the subject of specs, create_marshalled_proxy includes a reference to a figure at MSDN. Unfortunately the link is out of date. Any idea what it is a reference to? I had a quick look through the 1999 MSJ articles but didn't see anything obvious. Also, if I get bored and can find a few hours I was going to correct the arrangement of CoCreateInstance and CoCreateInstanceEx and tighten up the CoGetClassObject order of testing; does that conflict with anyone? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

1 0

Re: fix compiling of libs/wine/loader.c on NetBSD
by Joerg Mayer 27 Mar '03

27 Mar '03

On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > It seems the stdint. header file should be included for > compiling on NetBSD. This reminds me: Into which deep hole did Patrik disappear? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want ist just stuff that works. Some say that should read Microsoft instead of technology.

1 0

Re: PATCH: Make.rules.in
by Dimitrie O. Paun 27 Mar '03

27 Mar '03

On Wed, 26 Mar 2003, Gerald Pfeifer wrote: > In the FreeBSD port of Wine I inherited the following and > /usr/include/features.h on my Debian systems states > > _THREAD_SAFE Same as _REENTRANT, often used by other systems. > > so I'd like to propose the following. On FreeBSD these two are not > exactly synonyms (yet?), and on Linux it doesn't hurt anybody. Well, it does make the compiler command line longer and uglier. In this case, a configure test would work a bit better I believe. -- Dimi.

1 0

← Newer
1
2
3
4
5
6
7
...
29
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 March 2003