Re: Detecting Wine

[Steven Edwards]

On Mon, Sep 29, 2008 at 5:58 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> Not acceptable practice.  See e.g. the old faq entry:
> http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE

I don't understand why this should still be the case. We have a stable
Wine now and Alexadre exported this symbol for some good reason. I
understand detecting Wine and having your application depend on
certain behaviors would be wrong with unstable versions but in a post
1.0 would this seems acceptable.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

Re: OT [ReactOS-related] Win32s API dosumentation

[Wesley Parish]

Thanks.

I'll get onto it right away.

Wesley Parish

Quoting Owen Rudge <[EMAIL PROTECTED]>:

> > Does anyone know where to get copies of the Win32s documentation, such
> as 
> > it
> > is?
> 
> I don't know where to find a copy as such (perhaps tucked away in the
> old 
> Microsoft FTP server, or linked to from a KB article?), but I do have a
> 
> couple of versions here, shipped with various old compilers. Probably
> the 
> more detailed file I have is came with the Win32 SDK shipped with Watcom
> 
> C/C++ 10.6. You may be able to find a copy of it on eBay, I guess.
> Another 
> version came with Borland C++ 4.51, in a self-contained .hlp file,
> although 
> this only seems to apply to Win32s 1.1 (the help file is dated
> 1992-1993). 
> According to http://wrc.gro.clinux.org/johnfindlay/lcc-win32/links.htm,
> 
> Borland used to have a copy of those help files on its FTP server. They
> no 
> longer seem to be there, but I've taken the liberty of uploading the old
> 1.1 
> programmer's guide to http://www.owenrudge.net/various/win32s.hlp. Note
> that 
> Win32s 1.1 didn't support things like OLE 2.0, MAPI, ODBC, etc (which
> later 
> versions of Win32s did, I believe), so getting the latest documentation
> 
> would probably be best.
> 
> Hope this helps,
> 
> -- 
> Owen Rudge
> http://www.owenrudge.net/ 
> 
> 
>  



"Sharpened hands are happy hands.
"Brim the tinfall with mirthful bands" 
- A Deepness in the Sky, Vernor Vinge

"I me.  Shape middled me.  I would come out into hot!" 
I from the spicy that day was overcasked mockingly - it's a symbol of the 
other horizon. - emacs : meta x dissociated-press

Re: Detecting Wine

[Mark Wagner]

On Mon, Sep 29, 2008 at 15:15, Guillaume VanderEst <[EMAIL PROTECTED]> wrote:
> Based on the current information, wouldn't it be smartest to ask the users
> which drive(s) they would like included in the search, or is it actually
> required that all disks be scanned?

The average non-Wine user of this software has only a vague idea of
what's going on inside the box on their desk.  Asking the user what
disks should be scanned will get blank stares and wrong answers 99% of
the time.

-- 
Mark Wagner

Re: Detecting Wine

[Mark Wagner]

On Mon, Sep 29, 2008 at 14:55, Juan Lang <[EMAIL PROTECTED]> wrote:
>> Did you read the second paragraph of my original email?  I'm not
>> working around a bug in Wine, unless it's a bug that a user can map
>> "/" to "C:" and call it a "fixed disk".
>
> Yes, I read it.  And scanning "/" shouldn't be a problem, unless
> you've also mapped network drives there.  That seems to be the root of
> the problem.

Yes, that's the root of the problem.  I can't prevent the end-user
from mounting network drives -- in fact, in the expected installation
environment, the average user will have several very large network
drives mounted.

Under Windows, installation takes about five minutes, and the
full-disk search provides a nicer user experience if they're upgrading
from an ancient copy of the software.  Under Wine, I need to either
skip the full-disk search, or warn the user that it may take several
hours.

-- 
Mark

Re: Detecting Wine

[Juan Lang]

> Yes, that's the root of the problem.  I can't prevent the end-user
> from mounting network drives -- in fact, in the expected installation
> environment, the average user will have several very large network
> drives mounted.

I believe you.

> Under Windows, installation takes about five minutes, and the
> full-disk search provides a nicer user experience if they're upgrading
> from an ancient copy of the software.  Under Wine, I need to either
> skip the full-disk search, or warn the user that it may take several
> hours.

Again, I believe you.  You've already gotten a couple suggestions on
how to detect Wine, which you may use.  We just don't recommend that,
as the methods may not be supported in the future.  Whether you choose
to heed my recommendation is up to you ;-)

Still, it'd help if you could log a bug about it.  Include which
software it is, whether and where a copy is available, how network
drives are mapped, and so on.  Without a good bug report, we're rather
less likely to fix it.

Out of curiosity, is the previous installation likely to be found
under Z: ("/") rather than under C:?
--Juan

Re: Detecting Wine

[Austin English]

On Mon, Sep 29, 2008 at 4:53 PM, Mark Wagner <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 14:41, Juan Lang <[EMAIL PROTECTED]> wrote:
>>> What's the best way for an application to detect that it's running under 
>>> Wine?
>>
>> Some people have given suggestions, but please note that we discourage
>> doing this.  It's better to fix Wine than to work around its bugs, and
>> working around bugs removes incentive to fix them.  So please, log a
>> bug about the problem you're seeing at bugs.winehq.org, how to
>> reproduce it, and so on.
>
> Did you read the second paragraph of my original email?  I'm not
> working around a bug in Wine, unless it's a bug that a user can map
> "/" to "C:" and call it a "fixed disk".
>
> --
> Mark Wagner
>
>
>

Is the problem with scanning / that it's too many files/takes too
long, or that it's not a 'local hard drive'?

-Austin

Re: Detecting Wine

[Juan Lang]

> I'de like to nominate this bit of code (if approved as an 'acceptable
> practice') for the wiki.  It seems Wine-devel gets this question at
> least once a month.  Thoughts?

Not acceptable practice.  See e.g. the old faq entry:
http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE

--Juan

Re: Detecting Wine

[Juan Lang]

> Did you read the second paragraph of my original email?  I'm not
> working around a bug in Wine, unless it's a bug that a user can map
> "/" to "C:" and call it a "fixed disk".

Yes, I read it.  And scanning "/" shouldn't be a problem, unless
you've also mapped network drives there.  That seems to be the root of
the problem.
--Juan

Re: Detecting Wine

[Mark Wagner]

On Mon, Sep 29, 2008 at 14:41, Juan Lang <[EMAIL PROTECTED]> wrote:
>> What's the best way for an application to detect that it's running under 
>> Wine?
>
> Some people have given suggestions, but please note that we discourage
> doing this.  It's better to fix Wine than to work around its bugs, and
> working around bugs removes incentive to fix them.  So please, log a
> bug about the problem you're seeing at bugs.winehq.org, how to
> reproduce it, and so on.

Did you read the second paragraph of my original email?  I'm not
working around a bug in Wine, unless it's a bug that a user can map
"/" to "C:" and call it a "fixed disk".

-- 
Mark Wagner

Re: Detecting Wine

[Austin English]

On Mon, Sep 29, 2008 at 4:41 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
>> What's the best way for an application to detect that it's running under 
>> Wine?
>
> Some people have given suggestions, but please note that we discourage
> doing this.  It's better to fix Wine than to work around its bugs, and
> working around bugs removes incentive to fix them.  So please, log a
> bug about the problem you're seeing at bugs.winehq.org, how to
> reproduce it, and so on.
> --Juan
>
>
>

The problem seems to be that he doesn't want to scan / (root), as it
will take a _long_ time. There are already several bugs on this in
bugzilla, I believe resolved as WONTFIX. As such, it doesn't seem to
be a behavior Wine can/should fix.

-Austin

Re: Detecting Wine

[Zachary Goldberg]

On Mon, Sep 29, 2008 at 5:34 PM, Jeff Zaroyko <[EMAIL PROTECTED]> wrote:
>
> Easier still would be checking for wine_get_version in ntdll...
>
>
> #include 
> #include 
> int main(void)
> {
>  static const char * (CDECL *pwine_get_version)(void);
>  HMODULE hntdll = GetModuleHandle("ntdll.dll");
>  if(!hntdll)
>{
>  puts("Not running on NT.");
>  return 1;
>}
>  pwine_get_version = (void *)GetProcAddress(hntdll, "wine_get_version");
>  if(pwine_get_version)
>{
>  printf("Running on Wine... %s\n",pwine_get_version());
>}
>  else
>{
>  puts("did not detect Wine.");
>}
>  return 0;
> }
>
> [EMAIL PROTECTED]:~$ i586-mingw32msvc-gcc detect.c -o detect.exe
> [EMAIL PROTECTED]:~$ ~/git/wine/wine detect.exe
> Running on Wine... 1.1.5
>
> Jeff
>
>
>


I'de like to nominate this bit of code (if approved as an 'acceptable
practice') for the wiki.  It seems Wine-devel gets this question at
least once a month.  Thoughts?

Re: Detecting Wine

[Juan Lang]

> What's the best way for an application to detect that it's running under Wine?

Some people have given suggestions, but please note that we discourage
doing this.  It's better to fix Wine than to work around its bugs, and
working around bugs removes incentive to fix them.  So please, log a
bug about the problem you're seeing at bugs.winehq.org, how to
reproduce it, and so on.
--Juan

Re: Detecting Wine

[Jeff Zaroyko]

On Tue, Sep 30, 2008 at 6:52 AM, Austin English <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner <[EMAIL PROTECTED]> wrote:
>> What's the best way for an application to detect that it's running under 
>> Wine?
>>
>> As part of the installation process, under Windows our program does a
>> full-disk search of all local hard drives, but ignoring network drives
>> and removable media.  Under Wine, this doesn't work too well, as
>> there's not a one-to-one mapping between disks and drive letters, and
>> there's usually at least one way to access the entire *nix filesystem.
>>  If someone's got a few network drives mounted, the installer could
>> spend hours searching them.
>>
>> --
>> Mark Wagner
>>
>>
>>
>
> Easiest way is probably searching for wine specific registry keys.
>
>

Easier still would be checking for wine_get_version in ntdll...


#include 
#include 
int main(void)
{
  static const char * (CDECL *pwine_get_version)(void);
  HMODULE hntdll = GetModuleHandle("ntdll.dll");
  if(!hntdll)
{
  puts("Not running on NT.");
  return 1;
}
  pwine_get_version = (void *)GetProcAddress(hntdll, "wine_get_version");
  if(pwine_get_version)
{
  printf("Running on Wine... %s\n",pwine_get_version());
}
  else
{
  puts("did not detect Wine.");
}
  return 0;
}

[EMAIL PROTECTED]:~$ i586-mingw32msvc-gcc detect.c -o detect.exe
[EMAIL PROTECTED]:~$ ~/git/wine/wine detect.exe
Running on Wine... 1.1.5

Jeff

Re: howto fix bug 13462

[Louis. Lenders]

Rob Shearman  gmail.com> writes:

Hi Rob, i think i got the test ready now, i'll send it when the defenitions are
in place in ctxtcall.idl. Now still strugling how to fix the bug.

 I fixed up the patch below, also by looking how things are done in similar
places in wine-code. With patch applied I can see that
ContextCallback_ContextCallback and ContextCallback_Release are called from the
application (tested with NASA WorldWind), and the simple stubs are enough to let
the app continue fine. But i'm not sure if everything is 100% ok. Is this what
you more or less meant in your first comment?

diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c
index 37907ec..a1f41fd 100644
--- a/dlls/ole32/compobj.c
+++ b/dlls/ole32/compobj.c
@@ -55,6 +55,7 @@
 #include "objbase.h"
 #include "ole2.h"
 #include "ole2ver.h"
+#include "ctxtcall.h"
 
 #include "compobj_private.h"
 
@@ -3615,25 +3616,39 @@ HRESULT WINAPI CoRegisterChannelHook(REFGUID 
guidExtension, IChannelHook *pChann
 typedef struct Context
 {
 const IComThreadingInfoVtbl *lpVtbl;
+const IContextCallback *lpVtblIContextCallback;
 LONG refs;
 APTTYPE apttype;
 } Context;
 
+static inline Context *impl_from_Context(IComThreadingInfo *iface)
+{
+return (Context *)((char*)iface - FIELD_OFFSET(Context, lpVtbl));
+}
+
 static HRESULT WINAPI Context_QueryInterface(IComThreadingInfo *iface, REFIID 
riid, LPVOID *ppv)
 {
+Context* This=impl_from_Context((IComThreadingInfo*) iface);
 *ppv = NULL;
 
 if (IsEqualIID(riid, &IID_IComThreadingInfo) ||
 IsEqualIID(riid, &IID_IUnknown))
 {
 *ppv = iface;
-IUnknown_AddRef(iface);
-return S_OK;
 }
+else if(IsEqualIID(riid, &IID_IContextCallback))
+{
+*ppv = &This->lpVtblIContextCallback;
+}
+else
+{
+FIXME("interface not implemented %s\n", debugstr_guid(riid));
+return E_NOINTERFACE;
+}
 
-FIXME("interface not implemented %s\n", debugstr_guid(riid));
-return E_NOINTERFACE;
-}
+IUnknown_AddRef(iface);
+return S_OK;
+}
 
 static ULONG WINAPI Context_AddRef(IComThreadingInfo *iface)
 {
@@ -3691,6 +3706,31 @@ static HRESULT WINAPI 
Context_SetCurrentLogicalThreadId(IComThreadingInfo *iface
 return E_NOTIMPL;
 }
 
+
+static HRESULT WINAPI  ContextCallback_QueryInterface(IContextCallback *iface, 
REFIID riid, LPVOID *ppv)
+{
+FIXME("\n");
+return E_NOTIMPL;
+}
+
+static ULONG WINAPI  ContextCallback_AddRef(IContextCallback *iface)
+{
+FIXME("\n");
+return E_NOTIMPL;
+}
+
+static ULONG WINAPI ContextCallback_Release(IContextCallback *iface)
+{
+FIXME("\n");
+return E_NOTIMPL;
+}
+
+static HRESULT WINAPI ContextCallback_ContextCallback(IContextCallback *iface, 
PFNCONTEXTCALL pfnCallback, ComCallData* pParam, REFIID riid, int iMethod, 
IUnknown* pUnk)
+{
+FIXME("not implemented yet\n");
+return E_NOTIMPL;
+}
+
 static const IComThreadingInfoVtbl Context_Threading_Vtbl =
 {
 Context_QueryInterface,
@@ -3702,6 +3742,14 @@ static const IComThreadingInfoVtbl 
Context_Threading_Vtbl =
 Context_SetCurrentLogicalThreadId
 };
 
+static const IContextCallbackVtbl Context_Callback_Vtbl =
+{
+ContextCallback_QueryInterface,
+ContextCallback_AddRef,
+ContextCallback_Release,
+ContextCallback_ContextCallback
+};
+
 /***
  *   CoGetObjectContext [EMAIL PROTECTED]
  *
@@ -3735,6 +3783,7 @@ HRESULT WINAPI CoGetObjectContext(REFIID riid, void **ppv)
 return E_OUTOFMEMORY;
 
 context->lpVtbl = &Context_Threading_Vtbl;
+context->lpVtblIContextCallback=(IContextCallback*)&Context_Callback_Vtbl;
 context->refs = 1;
 if (apt->multi_threaded)
 context->apttype = APTTYPE_MTA;



  

Re: Detecting Wine

[Austin English]

On Mon, Sep 29, 2008 at 3:39 PM, Mark Wagner <[EMAIL PROTECTED]> wrote:
> What's the best way for an application to detect that it's running under Wine?
>
> As part of the installation process, under Windows our program does a
> full-disk search of all local hard drives, but ignoring network drives
> and removable media.  Under Wine, this doesn't work too well, as
> there's not a one-to-one mapping between disks and drive letters, and
> there's usually at least one way to access the entire *nix filesystem.
>  If someone's got a few network drives mounted, the installer could
> spend hours searching them.
>
> --
> Mark Wagner
>
>
>

Easiest way is probably searching for wine specific registry keys.

Detecting Wine

[Mark Wagner]

What's the best way for an application to detect that it's running under Wine?

As part of the installation process, under Windows our program does a
full-disk search of all local hard drives, but ignoring network drives
and removable media.  Under Wine, this doesn't work too well, as
there's not a one-to-one mapping between disks and drive letters, and
there's usually at least one way to access the entire *nix filesystem.
 If someone's got a few network drives mounted, the installer could
spend hours searching them.

-- 
Mark Wagner

Re: richedit: Fixed test failing on windows version with larger font sizes

[Juan Lang]

Hi Dylan,

@@ -402,6 +401,10 @@ static void test_EM_SCROLLCARET(void)
   "ff\n"
   "gg\n"
   "hh\n";
+  HWND hwndRichEdit = CreateWindow(RICHEDIT_CLASS, NULL,
+
ES_MULTILINE|WS_POPUP|WS_HSCROLL|WS_VSCROLL|WS_VISIBLE,
+   0, 0, 200, 80, NULL, NULL,
hmoduleRichEdit, NULL);
+  ok(hwndRichEdit != NULL, "class: %s, error: %d\n", RICHEDIT_CLASS,
(int) GetLastError());

It seems to me in this case that describing the relevant parameters to
CreateWindow--I assume just height?--and why they're important to the
test might help people not break the test in the future.
--Juan

Re: Free apps bundled with msvcp71?

[Dan Kegel]

On Sun, Mar 2, 2008 at 7:32 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> http://www.soft32.com/download/63-129953-1/Adobe_Contribute_4_Win.exe
> fails with
> err:module:import_dll Library MSVCP71.dll (which is needed by
> L"C:\\Program Files\\Adobe\\Contribute 4\\CoreTypes.dll") not found
>
> Wine has a nice implementation of msvcr71.dll, but not
> the C++-oriented msvcp71.dll, nor is it likely to get one soon.
>
> This brings back the question: what's a good place to
> legally and freely download an application bundled with a full set
> of msvcp71.dll et al?

Well, shoot.  I added msvcp71.dll to winetricks a while ago,
but it turns out Contribute 4 also needs mfc71u.dll,
which wasn't included where I grabbed msvcp71.dll.
Happily, I found a nifty tool which shows which apps
come with which dlls:
http://www.programchecker.com/file/8133.aspx
and sure enough, at least one of those apps is free.
Guess I should update winetricks.

Contribute 4 actually starts up with that, but it got
tangled up when I moused over several menus,
crashing with some "native code threw exception"
problem in jscript.
- Dan

Re: Patchwatcher: patchwatcher bug: richedit: Fixed test failure that happend on older builds ofriched20.dll

[Dan Kegel]

Ignore this; patchwatcher probably got confused by the word
difference at the beginning of a line.  This is a known and
very lame bug...

On Mon, Sep 29, 2008 at 10:37 AM, Patchwatcher <[EMAIL PROTECTED]> wrote:
> Hi!  This is the experimental automated wine patchwatcher thingy.
> The latest git sources were built and tested with your patch
> "richedit: Fixed test failure that happend on older builds ofriched20.dll"
> Result: the patch patchwatcher bug.
>
> You can retrieve the full build results at
>  http://kegel.com/wine/patchwatcher/results/2284.log
> and see the patch as parsed at
>  http://kegel.com/wine/patchwatcher/results/2284.txt
> See
>  http://kegel.com/wine/patchwatcher/results
> for more info.
>
>

Re: Discussion of bug versions

[Austin English]

On Sun, Sep 28, 2008 at 4:43 PM, Vitaliy Margolen
<[EMAIL PROTECTED]> wrote:
> Jeremy White wrote:
>> We discussed bugzilla versions at Wineconf, re:
>>
>> http://bugs.winehq.org/show_bug.cgi?id=12728
>>
>> There were several points of consensus.  First, it would be helpful
>> if we could reduce the number of versions visible in the drop down
>> box when entering a new bug.  That would seem to require
>> a bugzilla code change, though.  Anyone know of an easy way to
>> accomplish this?
> AFAIK it's already done in automated fashion in AppDB. Can take code from 
> there.

+1 I HATE having to scroll for 15 seconds just to get to the current
version. The problem is, how can we remove all those old versions
while not deleting the bugs/flooding wine-bugs mailing list? Can we
disable global e-mail while renaming them? Can we make a new 'version'
that is "old", "pre-0.9.50", etc.? And move all those there?

>> Second, we'd like new bug reporters to not be able to use
>> the 'CVS/GIT' version choice, but to instead be encouraged to
>> report the current version.  (wine --version reports something
>> that is easy to match up to the choices).
> I'm strongly against this. There are number of bug reporters who use git and
> update it every day. What should they use for their bug reports? IMHO their
> reports are much more valuable and allows developers to catch bugs early on
> before they get into the release.

+1 CVS/GIT only causes more confusion, especially if the bug isn't
fixed quickly.

> Otherwise it will take at least 2 releases to correct each introduced
> regression. For some regressions it takes just 2 versions for users to
> notice it and identify the patch in question.

I disagree. If the developers are reading wine-bugs as they should be
(or are watching their CC'ed bugs, at the very least), they'll be
aware of the regression they caused. Just because it's not yet in a
reported version doesn't mean they won't fix it. Ideally, the bug will
be fixed before it ever hits a released version. Removing CVS/GIT,
however, will reduce confusion. And if the bug isn't reported until 2
versions after release, CVS/GIT would be irrelevant anyway, as they
wouldn't be using it.

Assuming we do this, what are we going to rename the CVS/GIT bugs to?

-Austin

Re: OT [ReactOS-related] Win32s API dosumentation

[Owen Rudge]

> Does anyone know where to get copies of the Win32s documentation, such as 
> it
> is?

I don't know where to find a copy as such (perhaps tucked away in the old 
Microsoft FTP server, or linked to from a KB article?), but I do have a 
couple of versions here, shipped with various old compilers. Probably the 
more detailed file I have is came with the Win32 SDK shipped with Watcom 
C/C++ 10.6. You may be able to find a copy of it on eBay, I guess. Another 
version came with Borland C++ 4.51, in a self-contained .hlp file, although 
this only seems to apply to Win32s 1.1 (the help file is dated 1992-1993). 
According to http://wrc.gro.clinux.org/johnfindlay/lcc-win32/links.htm, 
Borland used to have a copy of those help files on its FTP server. They no 
longer seem to be there, but I've taken the liberty of uploading the old 1.1 
programmer's guide to http://www.owenrudge.net/various/win32s.hlp. Note that 
Win32s 1.1 didn't support things like OLE 2.0, MAPI, ODBC, etc (which later 
versions of Win32s did, I believe), so getting the latest documentation 
would probably be best.

Hope this helps,

-- 
Owen Rudge
http://www.owenrudge.net/ 

Re: Bug squish party!

[Jeremy White]

I completely forgot to write to the broader list to let you know
that we successfully added 1 more machine - Stefans - to the list of computers
that run make test successfully.  (We also got James Hawkins Windows box
down to 1 failure, and eliminated an enormous number of other test failures).

I forgot to let you know because we were all way too busy celebrating
at the bar .

But thanks, and hurray!

I definitely agree with Dan that we should make these more frequent than
once a year events.  Conceivably, we could soon have 3 (gasp!) computers
that ran make test to completion .

Cheers,

Jeremy

OT [ReactOS-related] Win32s API dosumentation

[Wesley Parish]

Hi.

I'm wondering about doing a quick-n-dirty Win32s re-implementation for 
ReactOS, following an email [last-year-this-year] discussion on the ReactOS 
dev list.  Based on Wine, of course, and operating as Windows-on-Windows in 
the Microsoft OS of the same name.

Does anyone know where to get copies of the Win32s documentation, such as it 
is?

Thanks

Wesley Parish
-- 
Clinersterton beademung, with all of love - RIP James Blish
-
Gaul is quartered into three halves.  Things which are 
impossible are equal to each other.  Guerrilla 
warfare means up to their monkey tricks. 
Extracts from "Schoolboy Howlers" - the collective wisdom 
of the foolish.
-
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.

Re: Wine PulseAudio Driver

[Reece Dunn]

2008/9/29 Scott Ritchie <[EMAIL PROTECTED]>:
> Arthur Taylor wrote:
>> Also, in the patch, configure checks for pulseaudio >= 0.9.7. I have
>> since noticed that it uses parts of the api from 0.9.11 and compilation
>> will fail against previous versions.
>>
>> Thanks
>
> As an aside, 0.9.11 is newer than most users have (Ubuntu 8.04 has
> 0.9.10, for instance).  This isn't a bad thing at the moment, just
> something to be aware of.

Intrepid (Ubuntu 8.10) is using the same version - 0.9.10.

$ paplay --version
paplay 0.9.10
Compiled with libpulse 0.9.10
Linked with libpulse 0.9.10

- Reece

Re: Wine PulseAudio Driver

[Scott Ritchie]

Arthur Taylor wrote:
> Also, in the patch, configure checks for pulseaudio >= 0.9.7. I have
> since noticed that it uses parts of the api from 0.9.11 and compilation
> will fail against previous versions.
> 
> Thanks

As an aside, 0.9.11 is newer than most users have (Ubuntu 8.04 has
0.9.10, for instance).  This isn't a bad thing at the moment, just
something to be aware of.

Thanks,
Scott Ritchie

Re: Wineconf-er caught at security.

[Scott Ritchie]

Owen Rudge wrote:
>  > I was stopped at security for carrying 'a wine bottle' through
>  > security. Upon a brief inspection it was revealed that my
>  > super-awesome crossover t-shirts had tripped the machine due to their
>  > lusciously exquisite compressed shape. Whoops.
> 
> I'll be sure to put mine in my hold luggage rather than my hand luggage, 
> then. ;-)
> 

Well, I managed to smuggle six of them past security by cleverly placing
them in my backpack.

Scott Ritchie