Winetricks 1.27 is available for download at
1. Add sha1sums for most downloads
2. Note a few downloads are no longer available (replacements, anyone?)
3. Note mono11 is deprecated
4. Add Mikołaj's nifty fakeie changes (see
http://bugs.winehq.org/show_bug.cgi?id=9036)
As always, it's up at
h
Phil wrote:
>The Wine socket implementation has problems when it comes to select.
>A fix for this problem is not currently on anybody's radar.
> http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html
Hmm. You never filed a bug at http://bugs.winehq.org
for this, it seems. Could you
I've sent a fixed version. Thank you for finding it.
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Would that setting be persistant?
> If so, wouldn't we want a way to flip that option back later?
> Winecfg is the logical place for that.
It would be persistent in the registry, so regedit could be used to
reset it.
--
Alexandre Julliard
[EMAIL PROTECT
"Phil Lodwick" <[EMAIL PROTECTED]> writes:
> My initial test of creating two threads, one that is Win32-aware and then
> synchronizing between the two of them appears to work. Does anybody know why
> this might be a bad idea?
It's not a bad idea, except maybe for performance reasons. As long as
> Could you please elaborate on what kind of problems you have when trying
> to use the Windows version of your library under Wine?
The Wine socket implementation has problems when it comes to select. A fix
for this problem is not currently on anybody's radar.
http://www.winehq.org/pipermail/wi
On Wednesday 22 August 2007 12:58:18 pm Stefan Dösinger wrote:
> I think for applications like css, we shouldn't activate that code at all.
> css renders to a top level window, so it doesn't have any clipping
> problems. The pixel format problem should be fixed in other ways, like
> making it safe
Am Mittwoch, 22. August 2007 20:57 schrieb H. Verbeet:
> > This solution is the best way to go. Luckily Microsoft made similar
> > changes in Vista.
>
> Conceptually its probably correct, but I think the speed hit is pretty
> large, and it's not like we've got a lot of performance to spare. As
> fo
Phil Lodwick escribió:
Greetings,
I have a proprietary library that has both Windows and Linux ports. The
Windows DLL has problems running on Wine, so I have created a builtin version
of this DLL in Wine. This has worked fine, except for one function that
basically creates a new thread and
On Wednesday 22 August 2007 21:10, H. Verbeet wrote:
> On 22/08/07, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> > There are two distinct cases. You have programs that use a toplevel for
> > GL/D3D rendering (in general this is the case for games). Further you
> > have 'windowed' programs e.g
> There was a problem like this with the CoreAudio library on macos, but I am
> not sure about the details.
> Is there any reason why you cannot use CreateThread?
I can't use CreateThread because the pthread_create is in a Linux library I
am calling.
My initial test of creating two threads, one
--- Alexandre Julliard wrote:
> > Rather than remove all that nearly-working code,
> > how about keeping it, adding the winecfg option,
> > and making it default to off for now?
>
> That option is much too specific to go in winecfg,
it's > something most
> users don't care about. What you could d
On 22/08/07, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> There are two distinct cases. You have programs that use a toplevel for GL/D3D
> rendering (in general this is the case for games). Further you
> have 'windowed' programs e.g. programs that mix GL/D3D with a GDI gui. The
> use of GL Co
Mikolaj Zalewski wrote:
-#define IOCTL_STORAGE_GET_MEDIA_TYPESCTL_CODE(IOCTL_STORAGE_BASE, 0x0300,
METHOD_BUFFERED, FILE_ANY_ACCESS)
-#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301,
METHOD_BUFFERED, FILE_ANY_ACCESS)
+#define IOCTL_STORAGE_GET_MEDIA_TYPES
On Wednesday 22 August 2007 20:57, H. Verbeet wrote:
> > This solution is the best way to go. Luckily Microsoft made similar
> > changes in Vista.
>
> Conceptually its probably correct, but I think the speed hit is pretty
> large, and it's not like we've got a lot of performance to spare. As
> for
Hi,
> If instead of using pthread_create I use CreateThread, I never have a
> problem. I notice no other wine DLLs are using pthread_create and I have
> seen hints that this might not work. If so, how do I use the Linux
> library. (Call_dll_to_spawn_thread_and_register_callback is just simulatin
On 22/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> LockRect() and LockRect(), then GetDC(). But since UnlockRect doesn't take a
> rectangle parameter, the runtime wouldn't know which rectangle is now locked
> or unlocked, so it is unlikely that two rectangles can be locked
> concurrently.
Ma
> This solution is the best way to go. Luckily Microsoft made similar changes in
> Vista.
>
Conceptually its probably correct, but I think the speed hit is pretty
large, and it's not like we've got a lot of performance to spare. As
for the Vista comparison... Vista isn't exactly well known for it's
On 8/22/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > Rather than remove all that nearly-working code,
> > how about keeping it, adding the winecfg option,
> > and making it default to off for now?
>
> That option is much too specific to go in winecfg, it's something most
> users don't care
Am Mittwoch, 22. August 2007 11:36 schrieb H. Verbeet:
> On 22/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Spotted by DCT
>
> I don't know what the DCT actually tests, but should it refuse to lock
> any locked surface, or only when the rectangles overlap? Of course a
> test would be nice,
Am Mittwoch, 22. August 2007 11:44 schrieb H. Verbeet:
> On 22/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
> Can't we wait for the other thread & context to become active? Afaik
> occlusion queries are allowed to block on Windows.
Queries do not block, but they can return that no data is av
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Rather than remove all that nearly-working code,
> how about keeping it, adding the winecfg option,
> and making it default to off for now?
That option is much too specific to go in winecfg, it's something most
users don't care about. What you could do th
Greetings,
I have a proprietary library that has both Windows and Linux ports. The
Windows DLL has problems running on Wine, so I have created a builtin version
of this DLL in Wine. This has worked fine, except for one function that
basically creates a new thread and fires back events to the
On Wednesday 22 August 2007 03:36, Chris Robinson wrote:
> Over the past several days, I've been working with some people in
> #winehackers on a way to help solve the problems Wine faces with OpenGL..
> namely the lack of useable onscreen pixel formats and broken child windown
> rendering. Here's a
On Wednesday 22 August 2007 16:21:09 Jeremy Newman wrote:
> I've updated the Wine product under bugzilla to the following settings:
>
> --
> Maximum votes per person: 20
>
> Maximum votes a person
> can put on a single bug: 1
>
> Confirmation threshold: 2
> --
>
> The setting I changed
I've updated the Wine product under bugzilla to the following settings:
--
Maximum votes per person: 20
Maximum votes a person
can put on a single bug: 1
Confirmation threshold: 2
--
The setting I changed was the "Maximum votes a person can put on a
single bug". It was set to: 1.
Lei wrote:
> ...
> The alternative is to keep the GUI. It is useful in the case where
> there's many pictures on the camera, and the user just want to import
> a few of them. We would need to:
>
> - modify the GUI to fix the crash
> - do not automatically generate download thumbnails, but rather,
>
Stefan Dösinger wrote:
Up to now we've been lucky that all the games requireing manual fog coords
haven't used vertex buffers, thus we always went through drawStridedSlow.
Make sure that the fog also works with vertexbuffers
As for the rejected patches from yesterday, I've moved them back to t
"Juan Lang" <[EMAIL PROTECTED]> writes:
> From 53a45e7e2adf3b8591f2c07501e7b37538d95657 Mon Sep 17 00:00:00 2001
> From: Juan Lang <[EMAIL PROTECTED]>
> Date: Tue, 21 Aug 2007 15:10:35 -0700
> Subject: [PATCH] Add more tests for CryptVerifySignatureW, and correct its
> parameter checking
This br
The issue of the order of global C++ object's constrution has been metioned
in wine development guid section 8.3.3.Starting a Winelib process
For the first scheme,
how can we made win_init as the entry of .init section.
Implement like .strat() in preloader.c
2007/8/22, trulyliu <[EMAIL P
On 22/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
Can't we wait for the other thread & context to become active? Afaik
occlusion queries are allowed to block on Windows.
On 22/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Spotted by DCT
>
I don't know what the DCT actually tests, but should it refuse to lock
any locked surface, or only when the rectangles overlap? Of course a
test would be nice, considering surface locking behaves somewhat
different between
Hi, Damjan Jovanovic
Thank you tired of the answer to my questions.
I carefully read the wine part of the code and development document,
searched in mail lists, these days.
And I got some inspiration from wine plugin API wiki page and wine loader's
code.
I am considering of an approach.
Link p
If there's a way to set it such that confirmation (and only
confirmation) ignores all but 1 of an individual's votes, that would be
ideal.
Thanks,
Scott Ritchie
On Wed, 2007-08-22 at 00:02 -0700, Lei Zhang wrote:
> Agreed, quite a few bugs have been confirmed in this manner.
>
> On 8/21/07, Kai
Agreed, quite a few bugs have been confirmed in this manner.
On 8/21/07, Kai Blin <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> While working on bug 9405, I realized that all 20 votes on that bug were made
> by the reporter. I think that's pretty lame, so I've asked the bugzilla folks
> if there's a
35 matches
Mail list logo
