Hi,
I am working on Wine and lately I have been tracking various sound
related issues. One issue I noticed is a crash in Wine's winmm wave test
when using the Alsa sound backend.
More precisely:
* if Wine's winmm wave test is the only application using the sound
device, then it works
* but if
> Or can we actually use this instead?
> http://prdownloads.sourceforge.net/wine/wine-w32api-20040505.zip?download
You should be able to use them, or I don't see the point of having them.
Note that updated versions exist
http://prdownloads.sourceforge.net/wine/wine-w32api-20040615.zip?download
http
On Fri, 23 Jul 2004, Robert Reif wrote:
[...]
> Wine dxguid used to include those IIDs but windows doesn't so I removed
> them and fixed the files that used them to define the IIDs directly. Looks
> like the same fix needs to be done to mingw
[...]
Exactly. I got my libdxguid.a from the following
Stefan Leichter wrote:
Hello,
building cross tests of current cvs fails for me with:
i386-mingw32-gcc capture.cross.o ds3d.cross.o dsound.cross.o propset.cross.o
testlist.cross.o -o dsound_crosstest.exe -ldsound -lole32 -luser32 -lkernel32
-ldxguid -luuid -ldxerr8
/usr/local/lib/gcc-lib/i386-min
Hi!
I try to use wine v.20040505 on FreeBSD5.2 and I just get the error in the
subject line.
I found another post about this and that OP was just told to check the
"dosdevices" directly, since I have such a directory and I don't get any
closer to a solution by staring uncomprehending at the file
> Why you do not leave the neutral resources in the main archive?
That's how it's done in other files, anyway, I'll send another patch that leaves
the neutral resources in the main file.
Ivan.
Hello,
building cross tests of current cvs fails for me with:
i386-mingw32-gcc capture.cross.o ds3d.cross.o dsound.cross.o propset.cross.o
testlist.cross.o -o dsound_crosstest.exe -ldsound -lole32 -luser32 -lkernel32
-ldxguid -luuid -ldxerr8
/usr/local/lib/gcc-lib/i386-mingw32/3.2.3/../../../.
Vincent Béron <[EMAIL PROTECTED]> writes:
> Does double-clicking on a .msi package (and thus run msiexec) applies?
No, if the user doesn't have to type it then we don't need the binary
in /usr/bin, it can always be launched with 'wine msiexec' anyway, so
we can put that in the association for .ms
Le ven 23/07/2004 à 13:54, Alexandre Julliard a écrit :
> Vincent Béron <[EMAIL PROTECTED]> writes:
>
> > Alexandre, what are the guidelines for installing winelib applications
> > in /foo/bin/?
>
> It should be restricted to apps that users will frequently run from
> the command-line on Windows
Vincent Béron <[EMAIL PROTECTED]> writes:
> Alexandre, what are the guidelines for installing winelib applications
> in /foo/bin/?
It should be restricted to apps that users will frequently run from
the command-line on Windows so that they expect the same behavior on
Wine, or else to apps prefixe
Le ven 23/07/2004 à 13:37, Francois Gouget a écrit :
> On Fri, 23 Jul 2004, Marcelo Duarte wrote:
>
> > Changelog:
> > Marcelo Duarte <[EMAIL PROTECTED]>
> > French translation and other adjustments
>
>
> + IDS_RESTART_TITLE "Recommencer"
> + IDS_RESTART_PROMPT "Tu voulez
On Fri, 23 Jul 2004, Marcelo Duarte wrote:
> Changelog:
> Marcelo Duarte <[EMAIL PROTECTED]>
> French translation and other adjustments
+ IDS_RESTART_TITLE "Recommencer"
+ IDS_RESTART_PROMPT "Tu voulez simuler la remise du Windows?"
+ IDS_SHUTDOWN_TITLE "Débranc
Mike Hearn <[EMAIL PROTECTED]> writes:
> What's wrong with having lots of them? They don't conflict and
> realistically there are a few people use a lot (WINEDEBUG,
> WINEDLLOVERRIDES) and the rest (WINEPREFIX, WINEDLLPATH etc) are used only
> occasionally or only by scripts.
It adds complexity,
Mike Hearn wrote:
CCing to wine-devel as the original reply will be forwarded soon too by
Jeroen ..
On Fri, 2004-07-23 at 17:58 +0200, Jeroen Janssen wrote:
I had a short look at the 'world of com' patch, and it looks like there
is something in there that implements the IRemUnknown stuff. Is th
Jeroen Janssen wrote:
Robert Shearman wrote:
Jeroen Janssen wrote:
Hello,
I'm mailing the both of you with a small (com) example attached.
It is a client/server/proxystub example (with binaries), so you need to
/RegServer the server and regsvr32 the proxy.
Now I first manually start the server in a
Forwarding this to the wine-devel mailinglist.
Robert Shearman wrote:
Jeroen Janssen wrote:
Hello,
I'm mailing the both of you with a small (com) example attached.
It is a client/server/proxystub example (with binaries), so you need to
/RegServer the server and regsvr32 the proxy.
Now I first m
CCing to wine-devel as the original reply will be forwarded soon too by
Jeroen ..
On Fri, 2004-07-23 at 17:58 +0200, Jeroen Janssen wrote:
> I had a short look at the 'world of com' patch, and it looks like there
> is something in there that implements the IRemUnknown stuff. Is there
> any easy
Le ven 23/07/2004 à 08:36, Peter Riocreux a écrit :
> Before I get onto my questions I would just like to say:
>
> This mail is not intended to start a flame war
> --
>
> It is intended in a spirit of understanding what is the current
> status.
>
> Fir
Hi,
I am new to this list (albeit not to Wine :-) my Wine usage dates back
to 1993 when I interviewed Bob Amstadt in his home... )
Anyway - I have a problem with Palm USB hotsync which could perhaps be
solved on the userspace level. As you all know, the Linux USB kernel code
creates an in-kernel
On Fri, 23 Jul 2004 14:28:20 +0200, Jeroen Janssen wrote:
> What exactly does this mean? (the impact on running programs that make
> use of COM)
Applications that aggressively use multithreading with our DCOM code will
crash or suffer intermittent errors. Fortunately InstallShield doesn't.
I'm a
Hello Peter,
As far as I understand .so are linux native shared libraries.
That means you can access linux native APIs from within the shared
library. This is how wine works, it implements the windows API in .so
files by using other (non wine) native shared libraries (example is the
Xfree86 libr
Before I get onto my questions I would just like to say:
This mail is not intended to start a flame war
--
It is intended in a spirit of understanding what is the current
status.
First the quick question - I want to install a built-from-CVS wine on
mul
Mike Hearn wrote:
You're right, good catch. I'm not sure it's worth resending the patch
though as really hardly any of our COM implementation is thread safe at
all.
What exactly does this mean? (the impact on running programs that make
use of COM)
---
Jeroen Janssen
On Thu, 22 Jul 2004 17:38:43 +0100, Robert Shearman wrote:
> Unfortunately, you have stumbled into one of the most confusing areas of
> the Win32 API that I think only one person in the world fully
> understands (Don Box in case you are wondering).
Yeah. I'm starting to suspect that Don kept pil
On Thu, 22 Jul 2004 13:00:41 -0700, Alexandre Julliard wrote:
> Frankly I don't think we want yet another environment variable, we
> have already way too many of them.
What's wrong with having lots of them? They don't conflict and
realistically there are a few people use a lot (WINEDEBUG,
WINEDLLO
On Fri, 23 Jul 2004 08:28:16 +0200, Jeroen Janssen wrote:
> Apparently I'm missing some #defines in wine's rpcproxy.h in order to be
> able build the proxy/stub dll?
> For instance:
> PROXYFILE_LIST_START
> PROXYFILE_LIST_END
> REFERENCE_PROXY_FILE
Yes, our rpcproxy.h is missing quite a few impor
On Fri, 23 Jul 2004 08:29:01 +0200, Jeroen Janssen wrote:
>> + res = IRpcStubBuffer_Release(stub);
>
> I'm not sure but, is there a hypothical race condition here when a
> thread switch takes place and someone tries to reuse the stub while
> valid is not set to TRUE yet (but the stub has already
Am 19.07.2004 um 17:10 schrieb Nicolai Kuntze:
Am 16.07.2004 um 15:25 schrieb Dmitry Timoshkov:
"Nicolai Kuntze" <[EMAIL PROTECTED]> wrote:
I have the program online with some help how to get it started and how
to get the error/problem. I hope you have seen this. Does this help
you? I try to
28 matches
Mail list logo
