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 scratch;
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 syscall. On
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 know
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 many locks
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/relpath
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 music? -
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]
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
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 are
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 patch,
Does Wine now support executing x64 bit PE executable like winnt32.exe
under amd64 directory?
Thanks,
Ananth
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 still
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 win3.1
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
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
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 Wine64
wiki
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
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
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
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 in a
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
21 matches
Mail list logo
