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
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.
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
> 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.
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.comhttp://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
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:[email protected]>."
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.
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
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.
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.
