On Tuesday 18 July 2006 16:28, Ge van Geldorp wrote:
> It's an intriguing idea, but I can't see how it could work for even
> slightly complex cases. Take the COM calls. When the COM object is
> constructed, you have absolutely no idea whether its methods are going to
> be called from a Wine or from
> From: Troy Rollo [mailto:[EMAIL PROTECTED]
>
> These are complications rather than impenetrable barriers.
> Wine->Wine (and Winelib App->Wine) calls would not need to go
> through the thunks. Many of the issues involved have already
> been dealt with for 16<->32 thunking and cross-process CO
On 7/16/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
As I wrote earlier, I think it's worth polishing up Wine's support
for Lotus Notes even though IBM has a Java version of Notes.
And it seems that Stefan Seifert is actually trying to get
Wine working well in the next two weeks.
So I put together a
On 7/17/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> I'm afraid I don't quite understand. What's wrong with interrupting a thread
> holding a lock? Could that make cloning a new thread deadlock?
One problem is that many locks have to be acquired
On Tuesday 18 July 2006 09:53, Jacek Caban wrote:
> It's not enough. We have to be able to call these functions from the
> Wine code, call callbacks, COM interfaces etc...
These are complications rather than impenetrable barriers. Wine->Wine (and
Winelib App->Wine) calls would not need to go thr
Troy Rollo wrote:
On Tuesday 18 July 2006 03:16, Ge van Geldorp wrote:
the biggest problem is that the 64-bit calling conventions are
different between PE executables and Linux executables. Some more info on
the Wine64 wiki page http://wiki.winehq.org/Wine64
This isn't necessarily a hu
On Tuesday 18 July 2006 03:16, Ge van Geldorp wrote:
> the biggest problem is that the 64-bit calling conventions are
> different between PE executables and Linux executables. Some more info on
> the Wine64 wiki page http://wiki.winehq.org/Wine64
This isn't necessarily a huge problem - even if GCC
> From: "Nadgir, Ananth P" <[EMAIL PROTECTED]>
>
> Does Wine now support executing x64 bit PE executable like
> winnt32.exe under amd64 directory?
No, the biggest problem is that the 64-bit calling conventions are different
between PE executables and Linux executables. Some more info on the Wine
Hi Piotr,
Piotr Caban wrote:
Hi,
Changelog:
- Added skeleton for IDL files generation
programs/oleview/main.h|8
programs/oleview/pane.c|9
programs/oleview/typelib.c | 96
+++-
3 files changed, 111 insertions(+), 2 deletion
Detlef Riekenberg wrote:
My direction to fix printing in wine is from low-level to high-level.
Print-Monitors are already managed in git-HEAD, and they are loaded and
used in my tree (Port-Functions).
Afterwards, the Printer-Functions will be updated and then
"gdi.exe" (16-Bit) is no longer req
Duane Clark wrote:
> Currently, using the Wine supplied print dialog, printing to a file
> results in a file named "FILE:".
Yes, that's bug # 3975
> It looks to me like the correct place to do this is in gdi/printdrv.c
> CreateSpoolFile().
Using dlls/gdi/printdrv.c for Printing is the old wi
"Andrew Ziem" <[EMAIL PROTECTED]> wrote:
If the varaibles are no more used in this file you should not make
static variables public, but move them into appropriate file instead.
All these variables are now used in two files: desktop.c and sysparams.c
Ah, sorry, didn't notice that they are st
Does Wine now support executing x64 bit PE executable like winnt32.exe
under amd64 directory?
Thanks,
Ananth
Hi Paul,
thanks for this info.. will fix it and send in a new version of this patch,
also i will use debugstr_w to fix two warnings.
Greets,
Christian
> > This patch implements SetupDiCreateDeviceInfoA and
> > SetupDiCreateDeviceInfoW as
> > stub.
> >
> > If something should be wrong with this
Dmitry Timoshkov wrote:
"Andrew Ziem" <[EMAIL PROTECTED]> wrote:
-static HBITMAP hbitmapWallPaper;
-static SIZE bitmapSize;
-static BOOL fTileWallPaper;
+HBITMAP hbitmapWallPaper; /* desktop wallpaper */
+SIZE bitmapSize; /* size of desktop wallpaper */
+BOOL fTileWallPaper;
If the varaibles
"Andrew Ziem" <[EMAIL PROTECTED]> wrote:
-static HBITMAP hbitmapWallPaper;
-static SIZE bitmapSize;
-static BOOL fTileWallPaper;
+HBITMAP hbitmapWallPaper; /* desktop wallpaper */
+SIZE bitmapSize; /* size of desktop wallpaper */
+BOOL fTileWallPaper;
If the varaibles are no more used in this
"H. Verbeet" <[EMAIL PROTECTED]> writes:
> -L adds library paths to the beginning of the library search path.
> You've probably got a libuuid in one of those directories, which now
> takes precedence over the one in wine.
This should be fixed now.
--
Alexandre Julliard
[EMAIL PROTECTED]
> This patch implements SetupDiCreateDeviceInfoA and
> SetupDiCreateDeviceInfoW as
> stub.
>
> If something should be wrong with this patch, please let me know it :)
>
> Greets,
> Christian
>
> --
> Christian Gmeiner - student of computer science
>
> http://dxr3plugin.sf.net
> Wanna listen to good
On 17/07/06, Christoph Frick <[EMAIL PROTECTED]> wrote:
On Mon, Jul 17, 2006 at 12:06:11AM +0200, Willie Sippel wrote:
> ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./amstream.spec
> amstream.o main.o mediastream.o regsvr.o version.res -Wl,--rpath,
> \$ORIGIN/`../../tools/relpa
Hi,
On Mon, Jul 17, 2006 at 01:08:38PM +0200, Alexandre Julliard wrote:
> "Dan Kegel" <[EMAIL PROTECTED]> writes:
>
> > I'm afraid I don't quite understand. What's wrong with interrupting a
> > thread
> > holding a lock? Could that make cloning a new thread deadlock?
>
> One problem is that m
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> I'm afraid I don't quite understand. What's wrong with interrupting a thread
> holding a lock? Could that make cloning a new thread deadlock?
One problem is that many locks have to be acquired in a specific order
to avoid deadlocks, and since you don't
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> I guess the worst case is the signal will be delivered at the beginning
> of the next time slice, so that shouldn't be too long.
There's no need to wait for that. On a UP system obviously the thread
is interrupted already since you are doing a kill syscal
On Mon, Jul 17, 2006 at 12:06:11AM +0200, Willie Sippel wrote:
> > They're defined in libuuid. Try "make depend && make". You should
> > post the exact error that you're seeing, not just your
> > interpretation of it.
i do seperate build and i just removed my ./wine_build dir and started
from s
23 matches
Mail list logo
