On 10/24/2012 05:16 AM, Maarten Lankhorst wrote:
I'm not sure yet how dsound should be fixed on bigger periods, I believe using
IAudioClock for reporting position *might* be the correct answer, but it's not
properly test yet on behavior, so I chose for the simple solution of directly
reporting
On 10/20/2012 05:40 PM, James Eder wrote:
+/* Intel says we need a zeroed 16-byte aligned buffer */
+char buffer[512 + 16];
+XMM_SAVE_AREA32 *state = (XMM_SAVE_AREA32 *)(((ULONG_PTR)buffer + 15)
~15);
+memset(buffer, 0, sizeof(buffer));
+
+__asm__ __volatile__( fxsave %0 :
On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote:
@@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc)
/* Temporarily disable the context, so we can see that we can't
retrieve functions now. */ wglMakeCurrent(hdc, NULL);
func =
On Monday, June 18, 2012 9:31:04 AM Andrew Eikum wrote:
We chatted a little on IRC this weekend, but thanks again for the
advice.
No problem. :)
Mmdevapi sends it data to the lower systems in period-sized chunks,
and the reported buffer fill level decreases in period-sized chunks.
But the
On Tuesday, March 27, 2012 8:35:49 PM Henri Verbeet wrote:
- int pixelattrib = ~0;
+ int pixelattrib = GLX_DONT_CARE;
I want to say there's a reason we used ~0 instead of GLX_DONT_CARE, but it's
been too long that I can't remember. I think it was because GLX_DONT_CARE
didn't include all
On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote:
+ * This is basically the same as the pa_threaded_mainloop implementation,
+ * but that cannot be used because it uses pthread_create directly
+ *
+ * pa_threaded_mainloop_(un)lock - pthread_mutex_(un)lock
+ *
On Friday, February 24, 2012 1:28:48 PM joerg-cyril.hoe...@t-systems.com
wrote:
- https://bugs.freedesktop.org/show_bug.cgi?id=46296
About the need to restart the PA server from time to time
- https://bugs.freedesktop.org/show_bug.cgi?id=46297
PA's huge buffering causes issues
On Wednesday, February 22, 2012 11:42:13 AM joerg-cyril.hoe...@t-systems.com
wrote:
That's why I'll repeat once more and say that DSound's resampler should
become that one.
My little knowledge about DSound's 3 initialisation modes (WRITE_PRIMARY
etc.) tells me it's compatible with such a
On Monday, February 13, 2012 10:07:45 AM Andrew Eikum wrote:
On Sat, Feb 11, 2012 at 06:24:08AM -0800, Chris Robinson wrote:
Hmm, actually it seems winealsa already does this enumerating. Except it
hardcodes the plughw: prefix for the device string, uses the card index
instead of the name
On Monday, February 13, 2012 2:17:13 PM joerg-cyril.hoe...@t-systems.com
wrote:
Chris Robinson wrote:
Plain mmdevapi can't do rate conversions
You forgot AUDCLNT_STREAMFLAGS_RATEADJUST since w7.
Interestingly, this flag seems to only have an effect for already-initialized
streams. ALSA would
On Monday, February 13, 2012 6:12:00 PM Нискородов Серёжа wrote:
Here is another trouble with snd_ctl_open. Not all devices in alsa
configuration files have a predefined ctl. Especially defined by user,
for example I don't always define a ctls for all my devices in
.asoundconf
You can
On Monday, February 13, 2012 8:37:42 PM Нискородов Серёжа wrote:
Chris Robinson wrote:
It's not something normal users do, but for power users I don't see a
problem with asking them to tell Wine about it.
I'm a power user, but for what I have to wrote device name in regedit,
if I can just
On Monday, February 13, 2012 10:31:06 PM Нискородов Серёжа wrote:
Ok, I agree, many junk devices, bad enumeration methods, okay. But
why you are against a registry parameter? I'm a power user, I know
WHAT I do, I want to see all ALSA devices, even junk. Why I can't do
that?
Mainly because
On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
Nope, it won't open in a rate other than 48000hz without plug:. But again,
that's fine for mmdevapi as it doesn't support rate conversion by default.
Hmm... Ok. But how it works in Windows? Does you mean that
applications
On Friday, February 10, 2012 5:09:05 PM Нискородов Серёжа wrote:
There's no $HOME/.asoundrc on any of my systems, yet I'd like to
use plug:dmix with Wine, e.g. on systems with PulseAudio installed.
I can use speaker-test -Dplug:dmix with no trouble.
Will your patch make that appear in the
On Friday, February 10, 2012 10:50:33 PM Нискородов Серёжа wrote:
Not only sample type, but sample rate to. For example, dmix plugin
have predefined samplerate for mixing, so if WINE send other
samplerate to it without plug: wrapper, in best case you will get
error message and no sound.
As I
On Friday, February 03, 2012 2:43:57 PM Dmitry Timoshkov wrote:
Aric Stewart a...@codeweavers.com wrote:
-REGFILTER2 *prf2;
+static REGFILTER2 *prf2;
What's the point of this change?
It returns a pointer to the pointer, so the variable needs to remain valid
after the function
On Friday, December 30, 2011 1:41:12 PM Jeff Cook wrote:
Hello all
I am curious about the patch on
http://bugs.winehq.org/show_bug.cgi?id=18490 and why it's not in
vanilla. http://bugs.winehq.org/show_bug.cgi?id=18490#c9 seems to be a
pretty cogent explanation of the issue and the patch
On Saturday, December 24, 2011 9:20:38 PM Alexander E. Patrakov wrote:
Andrew Eikum converted the buffer position calculation code from fixed
point to floating point, because floating-point code is more readable.
I agree with him.
FWIW, I'm not sure using floating point for the position index
On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote:
Hello Jacek!
Jacek Caban wrote:
mingw-w64 project imports some of our headers, including most of d3d
headers. They would probably prefer to keep them with 'l' modifier since
that's the right thing to do. Given that it's
On Wednesday, October 26, 2011 12:35:28 PM Michael Stefaniuc wrote:
Chris Robinson wrote:
imagine some C++ function overrides tripping up with the int/long
difference.
If you use the Wine headers this should actually fix it as it brings the
numeric constants in line with the types as LONG
On Monday, October 24, 2011 8:08:58 AM Andrew Eikum wrote:
On Sun, Oct 23, 2011 at 05:57:04PM -0700, Chris Robinson wrote:
A configuration option (in
winecfg/control panel) would be needed to set it into a different mode.
Windows has something similar to this for its
On Sunday, October 23, 2011 8:28:45 PM Jonathan McCrohan wrote:
Would someone with a better knowledge of Wine and/or ALSA be able to
assist me in tracking down the source of this bug?
Hi.
Part of the problem is the way Wine attempts to detect a default format from
ALSA. ALSA doesn't report a
Hi.
On Tuesday, October 11, 2011 3:31:59 PM Andrew Eikum wrote:
The specific drvcaps values and error code were tested against Windows
7.
How does this affect the primary buffer? Is it not allowed to be a hardware
buffer either?
On Monday, September 19, 2011 4:09:29 PM Francois Gouget wrote:
I prefer this construct as using IsBadReadPtr() would introduce a race
in is_valid(). Of course calling is_valid() is in itself racy anyway. So
I don't mind switching over if that's preferred (the code would have
fewer lines).
On Thursday, August 04, 2011 12:55:51 PM joerg-cyril.hoe...@t-systems.com
wrote:
- Except for 48000x2x16 and 48000x2x8, all standard PCM formats I
tested yield S_FALSE, i.e. they are rejected. That means that the
native mixer accepts integer formats at its nominal rate (48000),
but
On Saturday, June 18, 2011 8:32:31 PM Dan Kegel wrote:
Matches native behavior. Makes at least one app happier; see bug 27532.
Just to toss in my comments, the native behavior referred to is the behavior
of Creative's DLLs, but Creative's DLLs aren't the only ones available for
Windows.
On Monday, May 23, 2011 12:51:37 PM Daniel Scharrer wrote:
return ((D3DVALUE [4][4])_11)[r][c];
Something like this should work:
return ((D3DVALUE(*)[4])_11)[r][c];
On Wednesday, May 11, 2011 6:40:42 AM joerg-cyril.hoe...@t-systems.com wrote:
Several bugs were fixed by returning the success value that apps would get
on native, instead of returning the value that would be consistent with
the specification and implementation state in Wine, e.g. NOTSUPPORTED,
On Friday, April 29, 2011 7:18:47 AM Marcus Meissner wrote:
If they are not declared hidden, the -fPIC compile generates PLT
relocations for those symbols, even if they are internal to the dll (the
compiler does not know what to export during our build).
With the hidden attribute these get
On Sunday, March 27, 2011 1:57:17 AM Stefan Dösinger wrote:
BltOverride is a horrible mess, and I'm afraid the patch doesn't make it
any better. A long time ago Roderick started a cleanup to give the blit
selection routine a more structured approach, but he never finished the
work.
IDirect3DDevice9::StretchRect is used to stretch-blit between video memory
surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself
will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However,
BltOverride will not accelerate the blit if neither surface is a
On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote:
This patch was made against the origin, so if you've applied my previous
patch, remove that one before applying this one.
This patch makes the error message use ERR_(winediag) instead of just
ERR and is closer in style to the other
On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote:
On 03/20/2011 05:14 AM, Pali Rohár wrote:
Can anybody review my patch?
Not sure what you trying to do exactly. Wine already has wrapper that makes
all wine binaries executable after they are being installed into system.
Wine
An updated attempt at the mmap override patch that I previously sent. This
version properly uses a signed type for the mmap wrapper (as off_t/off64_t are
signed types), fixes a few things with the munmap wrapper relating to
truncated and sliced file_views, and implements a mremap wrapper for
On Sunday, December 12, 2010 2:19:42 pm Louis Lenders wrote:
+#define USER_HZ_TO_TICKSPERSEC(x,y) (ULONGLONG)1000 * x / y
I'd recommend adding proper parenthesis, to avoid potential problems with
order-of-operations.
#define USER_HZ_TO_TICKSPERSEC(x,y) ((ULONGLONG)1000 * (x) / (y))
On Tuesday, September 21, 2010 7:06:30 am Zachary Goldberg wrote:
Hello,
I found the following article/commit very interesting this morning.
Has anybody else been looking at this and put thought into whether it
will work with Wine?
IIRC, it's been discussed before, and it simply wouldn't
On Monday, September 20, 2010 2:42:51 pm Tijl Coosemans wrote:
On FreeBSD off_t is always 64 bit.
Even on 32-bit systems? I'll have to take that into account, then.
On Tuesday, September 14, 2010 3:38:47 am Henri Verbeet wrote:
Is that correct in the first place though? This will produce a
non-uniform mapping for positive and negative values. IIRC the common
way to do these kinds of mappings is ((x * (2^n - 1)) - 1) / 2,
which would be x * 127.5f - .5f
On Tuesday, September 14, 2010 6:56:36 am Henri Verbeet wrote:
Come to think of it though, doesn't ALSA accept floating point values
itself anyway?
Only if the device does. The dmix/default device usually can, but there's no
guarantees for the various hw:x,y or surround* devices.
On Monday, September 13, 2010 12:55:43 pm Owen Rudge wrote:
+if (*v -1.0f) d = -128;
+if (*v 0.0f) d = *v * 128.0f;
+if (*v = 0.0f) d = *v * 127.0f;
+if (*v 1.0f) d = 127;
The way these checks are written out can cause problems, particularly with the
On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote:
+*(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 +
0.5;
Is it safe to call le32 on a float? Especially one that's going to be used
more? If the system is big-endian, the float/integer will need to be in big-
On Saturday, September 04, 2010 11:09:03 pm Austin English wrote:
-frames_per_period = snd_pcm_bytes_to_frames(wwi-pcm,
wwi-dwPeriodSize);
+snd_pcm_bytes_to_frames(wwi-pcm, wwi-dwPeriodSize);
The whole call can probably be removed if the result isn't used anywhere. The
function just
On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote:
These patches add support to DirectSound that allow the conversion of
32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty
5) output their audio in this format, and media players such as
foobar2000 have support for
On Wednesday, August 11, 2010 3:12:23 am David Adam wrote:
Hello,
some comments about this patch
+if (hr != S_OK) return FALSE;
+else return TRUE;
could be simplified as
return SUCCEEDED(hr);
SUCCEEDED encompasses more than just S_OK (S_FALSE, for instance; basically
anything
On Tuesday, July 20, 2010 2:28:44 pm Louis Lenders wrote:
+TRACE(iface %p, adapter %u, mode %p.\n, iface, adapter, mode);
+TRACE(iface %p, adapter %u, mode %p, rotation %p\n, iface, adapter,
mode, rotation);
This doesn't look right. You probably only need the second TRACE statement,
On Tuesday, July 20, 2010 2:54:24 pm Luke Bratch wrote:
The attached uses that experimental extension [1] to report the correct
total memory for cards that support it, while sticking with the existing
hard coded values and code layout for those that don't.
I think the extension should be
On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
'FIXME's that contain no variable
information are completely redundant after their first report. After
the first reminder, the additional reports are just noise. They add no
additional information in terms of action required.
On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote:
@@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi,
if (ret == MPG123_NEW_FORMAT)
{
-long rate;
+LONG_PTR rate;
int channels, enc;
Now to the list...
On Friday, May 21, 2010 9:32:17 am you wrote:
Chris Robinson wrote:
On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote:
@@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi,
if (ret == MPG123_NEW_FORMAT
On Friday, May 21, 2010 11:59:40 am Michael Stefaniuc wrote:
mpg123_getformat() is a host native lib aka a unix lib thus expects a
unix long. A unix long translates to LONG_PTR in Wine. My patch is
actually a no-op.
The lib is also available for Windows, and AFAIK there's no reason winemp3.acm
On Sunday 04 April 2010 3:41:00 am Marcus Meissner wrote:
Yes, but those INT21 calls are in Win16 protected mode, not DOS real mode.
And VXD ... I doubt anything uses it.
Back in the Win95 era, I remember libnet having a DOS network driver that
hooked into winsock.vxd. It allowed a DOS app
On Wednesday 31 March 2010 2:00:57 pm Maarten Lankhorst wrote:
+local_contexts = palcIsExtensionPresent(NULL,
ALC_EXTX_thread_local_context);
Missed a spot? Don't forget to use the correct function names for the
completed extension, too.
It may be a good idea to remove the experimental extensions from the file:
AL_EXT_buffer_sub_data
AL_EXT_sample_buffer_object
ALC_EXT_thread_local_context
until they're finalized. I'm hoping ALC_EXT_thread_local_context will be done
in time for OpenAL Soft 1.12, but there could still be changes
FWIW, you can query ALC_DEFAULT_ALL_DEVICES_SPECIFIER (with ENUMERATE_ALL),
ALC_DEFAULT_DEVICE_SPECIFIER (standard playback), and
ALC_CAPTURE_DEVICE_SPECIFIER (record) to get the default device as seen by
OpenAL, instead of taking the first as the default.
Just make sure to query the default
On Sunday 28 February 2010 1:13:44 pm Marcus Meissner wrote:
Hi,
Copy in the mpg123.h header from the library so we do not need it for
building. (it is also LPGL)
Dynamically link from libmpg123.so.0.
(Chances are very good that ABI stays stable.)
This allows me providing a MP3 capable
On Sunday 28 February 2010 11:23:30 pm Marcus Meissner wrote:
A library should be ever built against one model and not change function
ABI depending on a preprocessor define ... This will just break in funny
ways.
In libmpg123 1.10.0 it does not do evil hacks for me, it has #if 0 around
On Tuesday 19 January 2010 11:38:18 pm Stefan Dösinger wrote:
Am 20.01.2010 um 01:08 schrieb Chris Robinson:
The comment says that it's using MinZ/MaxZ to suppress depth clipping,
which could otherwise occur with 0..-1. GL_DEPTH_CLAMP needs to be
enabled if 'untransformed' is false
On Tuesday 19 January 2010 2:52:28 pm Henri Verbeet wrote:
ARB_depth_clamp should give pretty much the desired behaviour by clamping
instead of clipping depth values outside the depth range.
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in
state_clipping if you're going to
On Tuesday 19 January 2010 3:37:50 pm Henri Verbeet wrote:
2010/1/20 Chris Robinson chris.k...@gmail.com:
I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in
state_clipping if you're going to bypass the depth range hack with it.
Currently it's only called
This doesn't seem correct to me. According to MSDN, sprintf_s checks for valid
formatting chars (in addition to the buffer and format arguments) and invokes
an invalid parameter handler if something bad turns up. It then returns -1
with errno set to EINVAL if execution is allowed to continue.
On Friday 04 December 2009 3:53:46 pm Stefan Dösinger wrote:
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
Though you'll still need a way to talk to the hardware. Using
ALSA/OSS/etc directly has proven problematic with not only the current
design and upkeep, but properly implementing
On Friday 04 December 2009 7:50:59 am Stefan Dösinger wrote:
Wrt OpenAL, I am opposed to using it for our sound system. I think its a
good idea for the transition to Win7, as a first driver and probably later
reference driver. But I think we need an exit strategy to get rid of
OpenAL as a
On Thursday 03 December 2009 3:57:49 pm Robert Reif wrote:
I believe the approach you are taking moving openal into direct sound is
not a good idea and is going to create a lot of regressions that can not
be fixed with your current approach.
Windows audio programmers know that they can get
Hi.
On Monday 30 November 2009 1:56:20 pm Maarten Lankhorst wrote:
+if (This-playing)
+{
+pos2 = This-format-nSamplesPerSec / 100;
+pos2 *= This-format-nBlockAlign;
+pos2 += pos1;
+if (!This-looping pos2 This-buf_size)
+pos2 = 0;
+
I'm not sure it's very appropriate to add this yet, since the extension isn't
finalized. Until it's finalized, there could be changes that modify the API
calls (I don't expect changes, but it's best to err on the side of caution, I
think).
The alBufferDataStatic patch is fine, though.
On Thursday 10 September 2009 9:43:02 am Juan Lang wrote:
+/* Define to 1 if you have the `sched_getaffinity' function. */
+#undef HAVE_SCHED_GETAFFINITY
+
...
+#ifdef HAVE_SCHED_GET_AFFINITY
+#define __USE_GNU
+#include sched.h
+#endif
Looks like a typo there.
I have a different patch that will fix this, that also fixes a problem with
error states.
On Tuesday 01 September 2009 1:59:54 am Henri Verbeet wrote:
I suppose 32-bit reads are atomic on x86, provided the variable is
aligned correctly, but shouldn't access to CurrentCtx technically be
synchronized?
Probably, but I'm not sure it would be beneficial. If the thread can be
On Wednesday 26 August 2009 9:27:42 pm Vitaliy Margolen wrote:
Tested few games that had issues with native OpenAL from Creative (both
windows dll and thunked old Linux version): STALKER SoC, STALKER CS,
Psychonauts. So far so good! Great job.
Thanks Chris, greatly appreciate your work on
On Tuesday 25 August 2009 6:40:30 am Stefan Dösinger wrote:
I'll give it a try with my games. The old thunk from a while ago already
worked very will with those games.
OpenAL seems to have an extension system like opengl. If there is a
function that returns an extension string we'll want to
On Wednesday 19 August 2009 2:26:37 pm Matteo Bruni wrote:
What about using more popular libraries as libmad, lame or maybe
gstreamer to decode mp3 files? I believe someone previously said that
gstreamer is also available on Mac.
libmad is GPL, and IIRC lame uses libmpg123 or libmad for
On Thursday 13 August 2009 11:23:45 am Juan Lang wrote:
Developer resources are a much bigger constraint.
All the more reason to use the existing libmpg123 instead of trying to
maintain our own version, IMO.
On Thursday 13 August 2009 12:03:02 pm Reece Dunn wrote:
But there is a reason for using our own version -- the HeapAlloc/Free
and Wine tracing changes that Aric mentioned in the initial email. So
for that reason, it won't be practical to dynamically link.
Needing to change malloc-HeapAlloc
On Wednesday 12 August 2009 1:10:15 pm Aric Stewart wrote:
I have a few questions. Right now I have the smallest subset of files
from libmpg123 that are needed to compile and work in the wine framework
(mostly) unmodified. I have replaced all the malloc/free calls with
HeapAlloc/HeapFree
On Wednesday 15 July 2009 2:40:08 am Adam Strzelecki wrote:
You can run X11 app on Windows as well, as there're several X11
servers. But none would appreciate that ;) And none would say you
don't have to use WinAPI to program Windows.
Actually, I know quite a few that would say you don't need
On Tuesday 14 July 2009 7:26:39 am Adam Strzelecki wrote:
Look, anyway Obj-C is supposed to be used in Wine only for Mac
support, and not for anything else. Any developer that knows how to
program Mac knows Obj-C so there's nothing wrong with constraint that
only developers that know Obj-C can
It may still be important to do this, if glGetError is ever used directly to
check for errors. Errors that are normally caught by checkGLError would then
be left for a later call to glGetError to pick up.
On Thursday 09 July 2009 1:46:59 am Rolf Kalbermatter wrote:
Adam Strzelecki [mailto:o...@java.pl]
Cocoa is the proper Obj-C API for OSX UI graphics. OSX is
NextStep based objective oriented GUI OS. And Obj-C is a
basement of both NextStep and OSX. So if you want to write
OSX GUI
On Friday 19 June 2009 10:21:33 am Alexandre Julliard wrote:
Steven Edwards winehac...@gmail.com writes:
I don't think this change is right. It is a very common convention to
use mingw32 as a generic convention for 32bit x86. It seems the best
practice would be if mingw32 is passed then to
On Tuesday 16 June 2009 3:33:12 am Arthur Taylor wrote:
I can't imagine stopping pulseaudio just so I can listen
to music through foobar2000, as that would stop all my voice chats,
notification sounds, and other native audio, etc.
There is no need to use PulseAudio if the issue you have is
On Tuesday 16 June 2009 8:44:36 pm Stefan Dösinger wrote:
There is such a DLL around - search the wine-devel and wine patches
archives from it. Alexandre said he'd accept such a openal-openal
thunk(but not an openal winmm driver). The problem why it is not included
yet is that the latest state
On Sunday 07 June 2009 2:05:41 pm Frank Richter wrote:
On what graphics cards is that extension supported?
DF16 is supported since the R300. It appears that float depth formats
are much younger, so it seems unlikely DF16 is actually a float format
internally.
Just to note, there is a much
On Monday 06 April 2009 6:39:47 pm Vincent Povirk wrote:
Even if you check for a Windows path first, that will still break the
python tests (they check for /bin/sh and expect it to not exist).
Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
On Monday 06 April 2009 6:58:31 pm Vincent Povirk wrote:
On Mon, Apr 6, 2009 at 8:53 PM, Chris Robinson chris.k...@gmail.com wrote:
Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
On a real windows system, it won't.
It won't by default, but can't a user create it?
On Sunday 05 April 2009 5:35:36 pm Ben Klein wrote:
My suggestion is a drop-down box in the Advanced tab of Drives to
control filesystem type (separate from disk type, as is suggested in
Comment #7 on 17938). It shouldn't be important for floppies or even
CD-ROMs, but the options could be:
-
On Sunday 05 April 2009 6:01:15 pm Ben Klein wrote:
Isn't that more-or-less what I suggested?
The biggest problem would be detecting what filesystem a given
directory is on (noting that wine's drives are not even mounted
partitions). Expert parsing of /etc/mtab would indicate it on Linux
On Sunday 05 April 2009 6:45:42 pm Ben Klein wrote:
That might be fine for mount points and mountable devices, but how
could you accurately determine the filesystem type for an arbitrary
directory like $HOME/.wine/drive_c?
Expand it (eg. $HOME - /home/user), resolve all symlinks, then see which
I wouldn't recommend this patch as being very safe. Having dealt with ffmpeg,
my experience has been that it's ABI is not stable (the .so version number
increments often, forcing recompilations). And when trying to update to new
lib versions, things sometimes mysteriously break.
Ultimately,
On Monday 23 March 2009 5:10:54 am Henri Verbeet wrote:
I'm not sure how much we should care about the ABI as long as the API
is reasonably stable, but my impression was that FFmpeg has stabilized
quite a bit in recent years.
It was actually just about a month or so ago where a project I was
On Tuesday 24 February 2009 8:57:23 pm Scott Ritchie wrote:
It would also make it completely unusable. Remember, all downloaded
executables (even intentionally downloaded ones) will be -x by default.
Do you really expect users to go right
click-properties-permissions-allow execution? Or
On Wednesday 25 February 2009 8:38:15 am King InuYasha wrote:
Now that Nautilus has the desktop file requiring execute bit, I have a
question for all of you to consider. Do JAR files require the +x bit to
load them, or are they treated like associated files and run through the
interpreter?
On Wednesday 25 February 2009 9:22:29 am Vincent Povirk wrote:
This discussion has been assuming that .exe files are somehow special
because they are programs
Actually, I'm saying just the opposite. They are *not* special because they
are programs, and should honor the executable bit just like
On Monday 23 February 2009 5:14:20 pm Marcel Partap wrote:
The problem would be with one of the more common use case: trying to
start/install a program from an optical disc. The files will not be
marked +x and the directories not be writable.
They're +x for me. They're not writable, but they
On Tuesday 24 February 2009 3:46:53 pm Paul Chitescu wrote:
My FAT partitions disable +x through file mode mount option since I don't
want the kernel to attempt to identify and execute every unknown file I
happen to open/click/hit enter. On those partitions there are no POSIX
executables but
On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote:
Unsolicited files will get +x with default mount options on vfat/fat
partitions, because ALL files on such partitions get +x this way.
You have to mount a partition to get access to its files. A partition normally
doesn't mount itself,
On Tuesday 24 February 2009 5:51:59 pm Ben Klein wrote:
Not correct. I've tested with vfat and ext2 filesystems, with noexec,
and the files are still marked +x. As it turns out, noexec doesn't
filter +x, just prevents shell/ld.so/kernel from loading the program.
Wine is an indirect method of
On Tuesday 24 February 2009 6:01:53 pm Marcel Partap wrote:
Actually, nowadays there are most sophisticated technical solutions
which mount on a single click. No warning, no options.
There are options. Whether or not said options are pre-configured sanely is
another question; but that's up to
On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the
security conscious there wanted to check an executable for the execute
bit before launching it with Wine. Then, the user would be prompted if
they wanted to run
On Monday 23 February 2009 8:39:22 am Erich Hoover wrote:
My suggestion (maybe this wasn't clear) was to normally
output the diagnostic information to the console, but if the console is not
available (if wine was launched from a desktop icon, for example) then to
pop up with a dialog.
That's
1 - 100 of 241 matches
Mail list logo
