Den 17. juni 2011 16:38, skrev joerg-cyril.hoe...@t-systems.com:
Hi,
I vaguely remember reading about a quite low limit on the number of
event objects that a thread can hold because each one is said
to take up one bit in some 32 or 64 bit mask.
You should probably clarify what you mean,
Den 08. april 2011 13:15, skrev joerg-cyril.hoe...@t-systems.com:
DispatchMessage is not always needed. Unfortunately, I don't grok
yet when DispatchMessage is required.
http://blogs.msdn.com/b/oldnewthing/archive/2004/06/08/150929.aspx
Everybody who has messed with window messaging knows
Steven Edwards skrev:
On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven o...@arcticnet.no wrote:
Sure it might be confusing, because that's not how the logic goes in the
Microsoft world. Over there, the big machine acting as Terminal Server
thing is the server, and the Remote Desktop client, which
James McKenzie skrev:
I'll agree that this is duplication of the existing X11 code, but the
effect is more pleasant to the eye and leads to less user confusion, not
to speak of a less expensive solution (I have yet to find a 'free' X11
client that is worth anything on Windows.)
You mean X
Steve Brown skrev:
On Mon, 15 Feb 2010, Ove Kaaven wrote:
James McKenzie skrev:
I'll agree that this is duplication of the existing X11 code, but the
effect is more pleasant to the eye and leads to less user confusion, not
to speak of a less expensive solution (I have yet to find a 'free
Jacek Caban skrev:
It does suffer from this bug, these tests are probably not enough to
show it.
Hmm. I had hoped the debian version had patched it or something,
especially considering how often stdcall is going to be used by a win32
compiler...
I'm not sure what to do about this. Any ideas
OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it
Scott Ritchie skrev:
Ove Kaaven wrote:
Ben Klein skrev:
Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
repository? It's just the pre-packaged cab file stored in
/usr/share/wine/gecko.
That's the reason I'm not looking at it.
Would such a package be ok for the -contrib
Anssi Hannula wrote:
However, the instructions on that page ask for copying binaries directly
provided in wine-mozilla tarball, and for modifying mingw32 headers.
It's probably also possible to generate these at package build time by
invoking the appropriate commands. If it's the lib*.a
Ben Klein skrev:
Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
repository? It's just the pre-packaged cab file stored in
/usr/share/wine/gecko.
That's the reason I'm not looking at it.
Sir Gallantmon skrev:
I don't think I have seen any distribution include wine-gecko. Fedora
seems to be in the best position to finally make a wine-gecko package,
since it now provides a MinGW toolchain.
Why does *that* put Fedora in the best position? Debian has had a MinGW
toolchain for
Sir Gallantmon skrev:
Sorry, I think of the word toolchain differently I guess. I always
considered a toolchain to include both tools and common libraries, as
Fedora did. I was aware of the MinGW compiler offered in the Debian
package repository, but with no libraries, I considered it useless.
Stefan Dösinger wrote:
A related topic: How do Joysticks connected to the gameport work(which is the
same hardware connector as MIDI). I think that a joystick already takes an
entirely different path in the
Linux kernel and it doesn't get anywhere near a sound system, so we
don't have to
Roderick Colenbrander skrev:
This audio engine is quite similar to
pulseaudio and it offers functionality like per stream volume which
normal APIs like oss/alsa/openal don't offer,
What?
If configured appropriately, ALSA can do it, although with the current
API it's not straightforward, as
Vincent Povirk skrev:
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven o...@arcticnet.no wrote:
(It is actually for similar reasons that binaries must be buildable on a
clean system (say, a build daemon), without any special (non-free) tools
or sourceless libraries. Magic libshell32.a in the source
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix
creation is that it will force packagers to package gecko g
You can't *force* the creation of packages which would likely fail to
meet the requirements for inclusion into Debian's main archive. Even if
I didn't
Jacek Caban skrev:
Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix
creation is that it will force packagers to package gecko g
You can't *force* the creation of packages which would likely fail to
meet the requirements
Roderick Colenbrander skrev:
On Mon, Oct 19, 2009 at 1:08 PM, Ove Kaaven o...@arcticnet.no wrote:
Roderick Colenbrander skrev:
On Mon, Oct 19, 2009 at 12:45 AM, Austin English
austinengl...@gmail.com wrote:
On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
jjmckenzi...@earthlink.net wrote
Roderick Colenbrander skrev:
On Mon, Oct 19, 2009 at 12:45 AM, Austin English
austinengl...@gmail.com wrote:
On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
jjmckenzi...@earthlink.net wrote:
Ove Kaaven wrote:
This makes it possible to work around bug 10080 without having to patch
the source
Stefan Kuhr wrote:
This is something quite common in Win32, as far as I can tell.
Yes, like I said, MSVC has special compiler support. In MSVC, __try,
__except, etc, are compiler builtins (not macros as in Wine). But they
are Microsoft extensions, they can't be implemented using standard C.
Martin Szydlowski wrote:
I know I can get the Windows-PIDs using winedbg-info process but there
is no trace of Unix PIDs there. Also, I need a scriptable way to do
this, best being a small app that gets a Unix PID and prints the
matching Windows PID to console.
I don't think there's currently
Alexandre Julliard skrev:
Objections? Does anybody feel a strong need for a Changelog file?
I've used it a lot to look up when stuff might have been fixed (or
broken), and in general Debian packages are expected to ship a changelog
if possible.
James McKenzie skrev:
Ove Kaaven wrote:
Alexandre Julliard skrev:
Objections? Does anybody feel a strong need for a Changelog file?
I've used it a lot to look up when stuff might have been fixed (or
broken), and in general Debian packages are expected to ship a
changelog
Dmitry Timoshkov skrev:
Dan Kegel [EMAIL PROTECTED] wrote:
For a maximal dogfood experience, I was looking around
for a way to use a replacement Windows shell with
Wine as my desktop environment instead of gnome
or kde.
Built-in Wine explorer does a lot of things which the replacements
Package: wnpp
Severity: normal
Since my time may be limited in the future, I am seeking comaintainers
for the Wine package in Debian, at least to ensure that new Wine releases
may continue to be uploaded in a timely fashion, and to keep the package's
bug count down. (And given that pretty much
Maarten Lankhorst skrev:
The latter won't work, they could create the directory and then delete
it after wineserver started. I don't think it is really a problem, by
the time someone else can put that directory in /tmp chances are that
they can do a lot more malicious things then just making
Maarten Lankhorst skrev:
Wine checks ownership of the socket and directory, so race conditions
aren't really a problem. This means that despite being put in a public
directory there is no chance of a race condition. I don't see a
security risk here, if someone is evil they could create that
Erik de Castro Lopo skrev:
Anybody understand why?
You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in
include/winnt.h. Then realize that __WINESRC__ is only defined for stuff
in dlls/, not for stuff in programs/, which should make the type
mismatch clear.
Erik de Castro Lopo skrev:
Ove Kaaven wrote:
Erik de Castro Lopo skrev:
Anybody understand why?
You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in
include/winnt.h. Then realize that __WINESRC__ is only defined for stuff
in dlls/, not for stuff in programs/, which should
Stephan Hermann skrev:
When there are people interested in going a hard way of fixing todays
situation in debian/ubuntu and other distris, please let's do it
, sane and with a plan.
There's already work going on to try to get a better solution into
Debian lenny. There's a new ia32-libs-tools
Scott Ritchie skrev:
Agreed. The one tricky thing here is making a proper source package.
There is some precedent for source packages that don't actually build
on the architecture they're for. The ia32-libs package, for instance,
contains both binary and source versions of the 32 bit
Benjamin M. Schwartz skrev:
I'm particularly surprised because I cannot imagine any reasonable
scenario in which allowing non-root users to run in .wine/ directories
that they do not own is a security risk. There is no privilege escalation
here; the non-root user is still required by the
Benjamin M. Schwartz skrev:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ove Kaaven wrote:
| Benjamin M. Schwartz skrev:
| I'm particularly surprised because I cannot imagine any reasonable
| scenario in which allowing non-root users to run in .wine/ directories
| that they do not own
Ove Kaaven skrev:
Does anyone know if MSVC does a cld in the right places?
Maybe. But it hardly matters. Only GCC-generated code is affected.
In order to avoid confusion about my answer, I should probably clarify.
I was answering this question only:
Could this kernel bug affect MSVC code
Alexandre Julliard skrev:
Ove Kaaven [EMAIL PROTECTED] writes:
Francois Gouget skrev:
Does anyone know if MSVC does a cld in the right places?
Maybe. But it hardly matters. Only GCC-generated code is affected. The
problem might then show up in Wine signal/exception handling. Things
like
Alexandre Julliard skrev:
Ove Kaaven [EMAIL PROTECTED] writes:
But that's a bit of a different issue, unrelated to the kernel flaw. I
was only talking about that flaw. I kind of tried to clarify that in
my next followup... oh well.
Sure, it has nothing to do with the kernel bug, except
Alexandre Julliard skrev:
Ove Kaaven [EMAIL PROTECTED] writes:
Alexandre Julliard skrev:
It depends if MSVC respects that ABI constraint or not.
Only if you want to make Wine depend on the compiler used to compile
Windows applications. Not all of them are called MSVC. I know
Borland Delphi
Francois Gouget skrev:
The problem revolves around the x86 direction flag (DF), which
governs whether block memory operations operate forward through
memory or backwards. GCC [...] 4.3.0, assumes that the direction flag
has been cleared [...] at the entry of each function, as is
James Hawkins skrev:
The tests that now pass with native cabinet dll are test_continuouscab
(which is similar to what you're trying to test). The point of
maxsize is so that it creates continuous cabs...there's no other way
to do it, and builtin doesn't create continuous cabs at all.
No? Then
James Hawkins skrev:
A lot of time has been spent fixing cab/media related bugs in
installers, as the behavior is very fickle (and easily breakable), so
can you please add a test case first? See the multicab tests that are
already in install.c. They will fail in wine because our cabinet.dll
Stefan Dösinger skrev:
A few proposed topics:
* Relative mouse movements
* A few new GL extensions. Only partially concerns Xorg, but I think it is
reasonable to present them there in the hope that ATI, Nvidia and Mesa people
are there.
- Flat shading vertex colors
- sRGB writing
Daniel Nylander skrev:
On ons, 2008-01-02 at 18:29 +0800, Dmitry Timoshkov wrote:
Daniel Nylander [EMAIL PROTECTED] wrote:
I noticed that the Norwegian (bokmål) locale files are using the locale
no. Correct locale for Norwegian Bokmål is nb (Nynorsk is nn).
I don't see a lower cased no in
Dan Kegel skrev:
On Jan 2, 2008 2:57 PM, Reece Dunn [EMAIL PROTECTED] wrote:
Are there any plans to use cairo in the Wine gdiplus implementation
like mono does?
Not that I know of. But I don't think that's a problem.
I think a more interesting question is, when are we going to
buckle
Scott Ritchie skrev:
If I wanted a Wine package to include mono and gecko, what would the
best way to do this be?
I know we support having gecko installed somewhere on the filesystem so
it doesn't have to be downloaded (where?), but would I need to make any
further changes other than adding
sn, 19,.06.2005 kl. 16.07 +0100, skrev Mike Hearn:
On Sat, 2005-06-18 at 05:12 -0400, Ove Kaaven wrote:
That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
Wine already have). The VM issue this thread is about is in 1.5.1. This
is not the fix you're looking for.
Ah OK
fre, 17,.06.2005 kl. 15.12 +0100, skrev Mike Hearn:
Well, I don't think Alexandre has a WoW account or copy and there isn't
enough information here to see what's going on. It's odd that seems VM
layout related though. The issue looks like it's in OpenGL though, their
1.5 patch hotfix is a
søn, 12,.06.2005 kl. 14.17 -0700, skrev Scott Ritchie:
This sounds like a good summer project for me to tackle while I'm
redoing the rest of the documentation. Phasing out c2man has been a
long time coming.
As far as this bug is concerned, though, Wine already have, and now use
its own
tir, 07,.06.2005 kl. 23.00 -0700, skrev David Albrecht:
VOID CreateLcdBitmap(VOID)
{
// create LCD bitmap
_ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4);
bmiLcd.Lcd_bmih.biWidth = LCD1_ROW * nLcdDoubled;
bmiLcd.Lcd_bmih.biHeight = -64 * nLcdDoubled;
fre, 20,.05.2005 kl. 00.35 -0600, skrev Brian Vincent:
Also, anyone happen to know if Wine can be used in conjunction with
binfmt alongside Mono? Are there any unique C# identifiers in the
first 128 bits of a .Net executable that could identify it? It
appears the Mono guys recommend looking
tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White:
Case 1: In the first case, in DSOUND_MixOne, we compute
a 'probably_valid_to' based on the 'write_pos', which seems quite
wrong; I believe the logic should be testing whether or not
there is sufficient data in the mixing buffer, not
man, 28,.02.2005 kl. 11.23 -0600, skrev Jeremy White:
In other words, afaict, the current code computes the difference
between the number of bytes that have been played from the input
source stream (buf_writepos) and the end of the data the app has
written (probably_valid_to). It then clips
fre, 14,.01.2005 kl. 13.06 +1100, skrev Con Kolivas:
Well the scheduler is not going to be rewritten any time soon (trust me,
I've tried :P). Tell me what remaining requirements your threads have
that you are unable to achieve at the moment and I'll see if I can help
with my understanding
ons, 12,.01.2005 kl. 12.01 -0600, skrev Jeremy White:
Second, we did not synchronize Wine message times with X11
message times properly. Fixing that resolved some issues
with Photoshop (and given that Ove reworked that patch into
WineX the same day I submitted it, I'd guess it fixed some
tor, 16.09.2004 kl. 01.47 skrev Francois Gouget:
On Tue, 14 Sep 2004, Robert Reif wrote:
[...]
OK. Here is the beginnings of a joystick test. I want to use
c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
dinput.dll.so but is not exported. It's also not exported in
tir, 31.08.2004 kl. 05.23 skrev [EMAIL PROTECTED]:
On Mon, Aug 30, 2004 at 08:52:04AM +0200, Ove Kaaven wrote:
It's not. Linux only allows non-root processes to reduce its priority,
not increase it, even for non-real-time priorities. Windows, however,
allows it for non-real-time priorities
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
I argued with myself about the logic in this for ages. The best I could
come up with is - I don't know :| I'd need to know about windows
scheduling (which I don't)
Obviously, if Win apps have been written to expect this, there's
søn, 29.08.2004 kl. 11.43 skrev Robert Shearman:
Ove Kaaven wrote:
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
Also note that Windows allows a Win32 process to boost its own priority
all the way to what they call real time. Only root can do this under
Linux. I'm not sure if you
søn, 29.08.2004 kl. 13.31 skrev Mike Hearn:
On Sun, 29 Aug 2004 09:51:30 +0200, Ove Kaaven wrote:
A book I have described how it works...
Hi Ove,
I remember TransGaming had some problems with kernel 2.6 scheduling: did
you guys ever get to the bottom of it?
Not in detail, we still
fre, 06.08.2004 kl. 23.58 skrev Lionel Ulmer:
Couldn't find proc address for: wglSwapIntervalEXT
I do not know any equivalent GLX extension for this.
GLX_SGI_swap_control is almost equivalent, it just doesn't have a query
function. It's probably not critical functionality though.
Couldn't
man, 26.07.2004 kl. 13.03 skrev Robert Shearman:
I can't work out how IUnknown marshalling is getting delegated to the
IClassFactory marshaller,
It shouldn't, as far as I know. Or, what exactly are you asking?
man, 19.04.2004 kl. 17.03 skrev Robert Shearman:
Doesn't the version rule already handle this?
It would appear not. The 'version' type is declared as a number further up
It's declared that the rule *returns* a number, you mean. The actual
rule is defined as
version:
aNUM
lør, 17.04.2004 kl. 18.53 skrev Robert Shearman:
Hi,
This patch adds support for several features I found lacking whilst
attempting to generate headers for RPC interfaces.
Is this needed?
@@ -350,6 +354,7 @@
| tSWITCHTYPE '(' type ')' { $$ = make_attrp(ATTR_SWITCHTYPE,
lør, 27.03.2004 kl. 20.40 skrev Mike Hearn:
On Sat, 27 Mar 2004 14:36:31 -0500, Robert Reif wrote:
Another problem is that drivers support different formats in different modes.
Because of software emulation in alsa, a driver may appear to support any
format but then fail when you try to
tir, 16.03.2004 kl. 03.20 skrev Vincent Béron:
Hi folks,
Since wine.inf is now used as the source for the default values for the
registry (via rundll32), importing it absolutely needs X (whereas the
older regedit method didn't when importing a .reg file). This can be a
problem for people
man, 23.02.2004 kl. 09.26 skrev Boaz Harrosh:
Ove Kaaven wrote:
I still think it would be better to use the Samba RPC client libraries
to interact with Wine's RPC implementation (rpcrt4). You wouldn't need
to implement a custom server to achieve that, it would just work, and be
more
man, 23.02.2004 kl. 15.26 skrev Boaz Harrosh:
If I may summarize what I understood. There are 2 options:
1) It would be best to take Samba-project implementation of RPC and
implement wine's RPCRT4 over that. This way we are both wire-compatible
with DCE RPC and also we can use a ready made
søn, 22.02.2004 kl. 22.49 skrev Robert van Herk:
maman yonatan wrote:
so if I understand you properly, you say that there is
no way doing from _outside_ of wine (no matter what
kind of com object I have), is that correct?
Of course there is a way: you could make your own remote procedure
lør, 14.02.2004 kl. 18.11 skrev Dimitrie O. Paun:
On February 13, 2004 12:35 pm, Mike McCormack wrote:
OK, this time I've done it the right way, and it at least works for one
or two apps, with a screen shot to prove it.
Very cool indeed Mike! One thing that I've noticed is that the code
tor, 12.02.2004 kl. 01.51 skrev Alexandre Julliard:
Ove Kaaven [EMAIL PROTECTED] writes:
Incidentally, that means I also reversed his indentation suppression of
the arguments of these function pointers, but I don't see the old
indentation as a problem - after all, MIDL does not suppress
fre, 06.02.2004 kl. 13.16 skrev Fabian Cenedese:
Hi
I'm trying to find a file copy tool which works on windows as well as wine.
I tried several and this looked promising:
ftp://ftp.simtel.net/pub/simtelnet/msdos/fileutil/cc108dos.zip
On Windows it copied all files without problems and
fre, 06.02.2004 kl. 15.46 skrev Dimitrie O. Paun:
On Fri, 6 Feb 2004, Ove Kaaven wrote:
Try win95. Wine currently only emulates the DOS long file name API on
win9x, since it did not exist on nt4.
That makes no sense: we get short names on a system (nt4) that
fundamentally had long names
tor, 05.02.2004 kl. 05.29 skrev Kevin Koltzau:
On Wednesday 04 February 2004 10:32 pm, Kevin Koltzau wrote:
I am loading a 32bpp bitmap from resources of a dll, but under wine its
being reported as 24 bit..for example
I think I actually found the answer to my own question..I'm always
ons, 04.02.2004 kl. 23.31 skrev Lionel Ulmer:
Then I would be drawing rectangles which are not ready for a redraw yet. Does
UnLock release only last lock or all locks on these old DX versions?
Well, you need to store the rectangle at Lock time but only draw it at
Unlock time. And I have
-Videresendt melding-
From: Emmanuel Charpentier [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian
Date: Mon, 12 Jan 2004 23:16:44 +0100
Dear Ove, dear Wine users and w(h)iners,
First, a
tor, 08.01.2004 kl. 12.52 skrev Mike Hearn:
On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote:
Well, I've done about as much as I dared do without knowing exactly what
plans you have. After all, widl can *not* link to oleaut32 since widl is
not a Winelib app (and wasn't meant to be since
man, 05.01.2004 kl. 14.34 skrev Mike Hearn:
On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote:
Nobody has yet added typelib stuff to widl, eh... I guess I could whip
up a framework or something to help with that, since nobody else has yet
done it...
Actually, in the last 4 days I
tir, 06.01.2004 kl. 23.16 skrev Alexandre Julliard:
Ove Kaaven [EMAIL PROTECTED] writes:
Log:
Added rules to parse library, coclass, dispinterface, and module
definitions, and a number of attributes, and cleaned up a few things.
Started on a typelib generation framework.
This breaks
man, 05.01.2004 kl. 02.07 skrev Robert Shearman:
I note that Win98 is about to be finally obsoleted. After this, it's
possible Microsoft will do the same as they did with IE and other stuff
for Win95 and pull downloads from their website. This is a problem,
because we currently need the
ons, 31.12.2003 kl. 17.48 skrev Robert Shearman:
No. You should use cpp_quote. It may be necessary to disable stuff in the .h
generated file which you can do with:
You can't use cpp_quote inside an interface definition. The quoted text
would end up before the generated type, not inside. For
ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
Alexandre Julliard wrote:
Subhobroto Sinha [EMAIL PROTECTED] writes:
However, soon many of his elves found out that technologies like
MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too
complex to be implemented using plain
tir, 30.09.2003 kl. 09.39 skrev Jonathan Wilson:
Everything that's LGPL should be listed on the above page. Additionally,
code in ReWind is X11. Anything else in WineX may be assumed AFPL, but
may also be released as X11 at TransGaming's discretion. I think most
non-DirectX code (and even
tir, 30.09.2003 kl. 17.16 skrev Dimitrie O. Paun:
On September 30, 2003 09:16 am, Ove Kaaven wrote:
Now the LGPL-ness of Wine
actually makes it an advantage to hold code back from Wine in some
circumstances, whether you and I like it or not.
Your argument is valid right now because
man, 29.09.2003 kl. 16.33 skrev Dimitrie O. Paun:
On September 29, 2003 04:57 am, Dmitry Timoshkov wrote:
I'm attaching a diff between your output and an output of
the test run under win2k (line numbers were stripped before
the diff).
So it seems that InSendMessage() always returns
tir, 30.09.2003 kl. 02.24 skrev Jonathan Wilson:
From what I understand, if you download the WineX source tree, you get
code under LGPL, code under X11 and code under APL (which is basicly a
licence chosen to make sure that others cant just grab those bits and use them)
Does anyone know
søn, 21.09.2003 kl. 16.07 skrev Andreas Mohr:
Wine DOES have to implement a DOS extender.
I think you're wrong. Wine doesn't have to implement a DOS extender,
it's much simpler and more useful to have Wine be able to run them
rather then implement them all. After all, DOS extenders don't have
On Wed, 2003-09-10 at 17:31, Rein Klazes wrote:
From the changelist of glibc-2.3.2-6 there seems to be only one
applicable item:
| - debian/patches/pthread_cond_timedwait.dpatch: avoid problem when
|pthread_cond_timedwait is used in code that doesn't link with
|
On Thu, 2003-09-11 at 00:29, Kevin Atkinson wrote:
I will repeat what I just said:
Since it normal interface is VC++ RECOMPILING it under
Winelib is NOT really an option as that will mean that existing plugins
for Avisynth will no longer work without a recompile.
But that's also
On Wed, 2003-09-10 at 22:10, Alexandre Julliard wrote:
Ove Kaaven [EMAIL PROTECTED] writes:
See the problem?
Hmm, now should I complain to Debian's glibc maintainers, or is this
Wine's problem?
In a sense it's a Wine problem, since this is an internal structure we
are not really
88 matches
Mail list logo
