"Chris Robinson" wrote:
Why not make the default what the filesystem actually is? Eg. if the FS is
FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report
unixfs; etc. The registry/winecfg can then be used to override the per-drive
type if it causes problems with certain apps
2009/4/6 Austin English :
> On Sun, Apr 5, 2009 at 7:53 PM, Ben Klein wrote:
>> I agree with Henri here. UseGLSL and OffscreenRendering are
>> approaching the point where they don't need to be changed. Detecting
>> the amount of video memory should be preferred over setting it
>> manually. Most of
On Sun, Apr 5, 2009 at 7:53 PM, Ben Klein wrote:
> I agree with Henri here. UseGLSL and OffscreenRendering are
> approaching the point where they don't need to be changed. Detecting
> the amount of video memory should be preferred over setting it
> manually. Most of these settings the users *shoul
2009/4/6 Chris Robinson :
> 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/), reso
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/), resolve all symlinks, then see which
On Sun, Apr 5, 2009 at 8:45 PM, Ben Klein wrote:
> 2009/4/6 Chris Robinson :
>> 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"
2009/4/6 Chris Robinson :
> 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 /e
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 Linu
2009/4/6 Chris Robinson :
> 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
>>
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson wrote:
> 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
>
> Why not make the default what the filesystem actually is?
That may be a lot of work.
On Sun, Apr 5, 2009 at 7:35 PM, Ben Klein wrote:
> If I interpret it correctly, the user reporting bug 17938 is trying to
> use a native NTFS filesystem with Wine, which we already know is a bad
> idea :)
No. The problem is that we _used_ to have NTFS reported as the default
file system, but now
On Mon, Apr 6, 2009 at 2:52 AM, Chris Robinson wrote:
> 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
>
> Why not make the default what the filesystem actually is?
Another option is to actual
2009/4/6 Henri Verbeet :
> 2009/4/5 Austin English :
>> Again, the same argument can be made for native dlls. Tons of
>> tutorials recommend setting just about every dll to native, and
>> winecfg allows this. Should we not allow people to set more than 3
>> dlls to native?
>>
> You could certainly
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
2009/4/6 Austin English :
> On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie
> wrote:
>> Austin English wrote:
>>> See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
>>>
>>>
>> Sent reply direct to Austin. This may be outside of Wine's control due
>> to flaky NTFS support by some Linu
Am Montag, 6. April 2009 00:30:31 schrieb Henri Verbeet:
> 2009/4/4 Stefan Dösinger :
> > +pDesc->Usage = pDesc->Usage;
> > +pDesc->Pool = pDesc->Pool;
> > +pDesc->Size = pDesc->Size;
>
> This is just silly.
Hmm Smells like copypaste
2009/4/4 Stefan Dösinger :
> +WINED3DRESOURCETYPE WineD3DRType;
> TRACE("(%p)->(%d, %d, %d, %08x, %d, %d)\n", This, Adapter, DeviceType,
> AdapterFormat, Usage, RType, CheckFormat);
>
> +switch(RType) {
> +case D3DRTYPE_VERTEXBUFFER:
> +case D3DRTYPE_INDEXBUFFER:
> +
2009/4/4 Stefan Dösinger :
> +pDesc->Usage = pDesc->Usage;
> +pDesc->Pool = pDesc->Pool;
> +pDesc->Size = pDesc->Size;
This is just silly.
2009/4/4 Stefan Dösinger :
> -hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, &wined3d_desc,
> -data ? data->pSysMem : NULL, (IUnknown *)object,
> &object->wined3d_buffer);
> +hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, 0 /* fvf */,
> +WINED3DFMT_V
Personally I would've eliminated the implementation differences first
(the main difference is when the data is copied, unmap vs. preload),
and then just killed IWineD3DIndexBufferImpl once they were the same
from an implementation point of view. Eg., you can ignore the
conversion if you can prove i
2009/4/6 Stefan Dösinger :
> That was my suggestion. We already keep a wined3d-internal refcount for all
> these objects(shaders, textures, ...), and my plan was a callback
> function(maybe provided via a COM interface, similar to the
> WineD3DDeviceParent one). Some time ago I thought you weren't
Am Sonntag, 5. April 2009 23:59:01 schrieb Henri Verbeet:
> I don't know what was discussed on IRC, but essentially we need to
> keep track of which resources (in a broad way, not just objects
> derived from IWineD3DResource) are in use by a stateblock in wined3d,
> and delay destroying the d3d9 ob
2009/4/5 Stefan Dösinger :
> After a discussion on #winehackers I want to add something for the archives:
>
> This is a situation that cannot be solved in d3d9 alone, a fix has to involve
> wined3d. This is because there is a hidden reference kept on every object
> that is referenced in any statebl
On Sun, Apr 5, 2009 at 4:51 PM, James McKenzie
wrote:
> Austin English wrote:
>> See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
>>
>>
> Sent reply direct to Austin. This may be outside of Wine's control due
> to flaky NTFS support by some Linux distributions.
>
> James McKenzie
Hans Breuer wrote:
> From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001
> From: Hans Breuer
> Date: Sun, 29 Mar 2009 18:27:29 +0200
> Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see
> http://hans.breuer.org/dia/dia-wine.htm
>
> ---
> dlls/winex11.drv/pe
Austin English wrote:
> See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
>
>
Sent reply direct to Austin. This may be outside of Wine's control due
to flaky NTFS support by some Linux distributions.
James McKenzie
See http://bugs.winehq.org/show_bug.cgi?id=17938 for background.
Vitaliy closed this bug, saying it's an application bug that it
depends on seeing NTFS file system type for certian program features.
I don't think it should be a WONTFIX, as the only reason that change
was introduced was to enable _
People, is adding a warning message not enough?
Here's what i set as message in the configuration window in my patch:
Only change these settings if you know what you're doing. Changing
these values may result in unexpected behaviors and unstability.
Any suggestions are welcome concerning the warn
People, is adding a warning message not enough?
Here's what i set as message in the configuration window in my patch:
Only change these settings if you know what you're doing. Changing
these values may result in unexpected behaviors and unstability.
Any suggestions are welcome concerning the warn
After a discussion on #winehackers I want to add something for the archives:
This is a situation that cannot be solved in d3d9 alone, a fix has to involve
wined3d. This is because there is a hidden reference kept on every object
that is referenced in any stateblock, even the non-primary ones. d3
2009/4/5 Austin English :
> Again, the same argument can be made for native dlls. Tons of
> tutorials recommend setting just about every dll to native, and
> winecfg allows this. Should we not allow people to set more than 3
> dlls to native?
>
You could certainly make an argument for not allowing
On Sun, Apr 5, 2009 at 2:36 PM, Roderick Colenbrander
wrote:
> I'm not a favor of adding options as we try to autodetect everything. Users
> shouldn't touch them using winecfg in general. If you check lets say appdb
> you see a lot of tutorials recommending certain options while the authors
> have
I'm not a favor of adding options as we try to autodetect everything. Users
shouldn't touch them using winecfg in general. If you check lets say appdb
you see a lot of tutorials recommending certain options while the authors
have no idea what the options do and I have seen various tutorials where
r
It's also affecting one of my bugs:
http://bugs.winehq.org/show_bug.cgi?id=15858
It's sort of random when a real crash occurs but the debugging revealed
that the object that is used was already freed by wined3d.
I can increase the probability of a crash by running a bunch of
memory-hungry apps be
Here's what i done for now:
http://img227.imageshack.us/img227/8531/winecfgnew.png
Before continuing, i would like to know if it is acceptable?
Sorry is in french, but "Options avancées" means "Advanced options". A
dialog will then pop up and let the user choose advanced options (video
memory size
http://forum.winehq.org/viewtopic.php?t=4403
Some highly impractical ideas, but certainly having the users throw
ideas around should inspire wine-devel (and Codeweavers) :-)
- d.
Am Sonntag, 5. April 2009 11:32:38 schrieb paulo lesgaz:
> Hello,
>
> looking at the web page:
> http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-p
>otential-patch-td19907752.html
>
> I read that there are problems with the ref count in d3d wine
> implementation.
>
> Does t
Hello,
looking at the web page:
http://www.nabble.com/d3d:-Bug-in-handling-of-depth-stencil-surfaces,-and-potential-patch-td19907752.html
I read that there are problems with the ref count in d3d wine implementation.
Does there exist any plan to fix it? Or can we try to implement the Jim's idea
38 matches
Mail list logo
