On Sun, 02 Jan 2005 23:35:17 +0100, you wrote:
Rein Klazes wrote:
On Sun, 02 Jan 2005 14:57:27 +, you wrote:
Being the patch fetishist that I am, I couldn't help noticing that in
December 2004 we cleared 8mb of patches: that's by far the largest since
the current archives began in
On Sun, 02 Jan 2005 18:03:17 -0800, Scott Ritchie wrote:
There have been a few patches submitted to lostwages over the past few
weeks that are still uncommitted.
Are you still on vacation Jeremy? Should we resend?
Yeah, it's all a bit slow over at CodeWeavers right now. We'll be getting
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Right. A default implementation could be just:
wine_dbg_sprintf(%x, msg);
Anyway, it would be way cool if we could use the nice dumping
functions from spy.
We should be exporting a
wine_dbg_msg_{enter,exit}()
that we could use them nicely
Hi Boaz,
On Mon, 2005-01-03 at 15:58 +0200, Boaz Harrosh wrote:
We did try to keep up with what wineapploader and wine did to load a
fake-dll winelib app and all the spec.c magic that linked it all.
Could you please elaborate a bit on what has changed and how it is all
glued together?
Vitaly Lipatov [EMAIL PROTECTED] wrote:
As we have debug printing of messages in hex format
and can't use SPY_GetMsgName for their human readable output
I replace decimal const by their hex values
I'd suggest to make debug output look like (TCM_FIRST + decimal)
instead of making Wine headers
Vitaly Lipatov [EMAIL PROTECTED] wrote:
+/* New Scrollbar info since Windows 98, Windows NT 4.0 with SP6 */
+typedef struct tagSCROLLBARINFO
+{
+DWORD cbSize; /* Size of SCROLLBARINFO struct */
...
+BOOL WINAPI GetScrollBarInfo(HWND hwnd, LONG idObject, LPSCROLLBARINFO
On Sun, 2005-01-02 at 18:03 -0800, Scott Ritchie wrote:
There have been a few patches submitted to lostwages over the past few
weeks that are still uncommitted.
Are you still on vacation Jeremy? Should we resend?
Yeah, was out of the office basically for the last week. Just using up
my
3 2005 18:23 Dmitry Timoshkov (a):
+FIXME(check me);
+if (psbi-cbSize != sizeof(RECT))
+return FALSE;
Why are you testing psbi-cbSize for sizeof(RECT) here?
It is my mistake. The corrected version placed below:
--- dlls/user/1/scroll.c 2005-01-02 20:42:54 +0300
+++
Vincent Béron wrote:
Remove the loader script from Winelib apps. Winelib apps are still .so
files, but they can be launched directly now.
We did try to keep up with what wineapploader and wine did to load a
fake-dll winelib app and all the spec.c magic that linked it all.
Could you please
Somebody removed dcom95.exe from sf.net. Was there a reason for that? We
really need to keep that file mirrored. It's an essential file for many
programs to run under wine.
I've re-added the file as a hidden file for the moment. It won't show up
in the download list, but we can still link to it.
On Mon, Jan 03, 2005 at 03:19:50PM +0100, Alexandre Julliard wrote:
You can also simply turn on the +message channel and you get nice
traces for all the window procs. I don't think there's much point in
duplicating that functionality inside the window procs themselves.
Unfortunately, it's not
Hi,
I'm having some kind of hard time with wine's printing capabilities and
have already started digging the wine sources for potential fixes to my
problems (printing to some high volume postscript printers from some
Adobe applications).
But before I proceed any further, I would be grateful for
On wtorek 21 grudzie 2004 05:36 pm, Kenneth Porter wrote:
--On Tuesday, December 21, 2004 4:57 PM -0500 Kuba Ober
[EMAIL PROTECTED] wrote:
What kernel version were you running under? Could that be related at all
to thread CPU affinity under 2.6?
2.6.8-1.521smp on Fedora Core 2. What's
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Unfortunately, it's not that simple. If it were, there wouldn't be
a point in having any tracing functions in our window procs. Thing is,
then I'm debugging say listview, I don't want to turn +message on,
it dumps way too much information.
You can
On Mon, Jan 03, 2005 at 07:19:49PM +0100, Alexandre Julliard wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
You can of course configure the message filters to only dump listview
messages in that case. Another possibility would be to make spy.c
print only the listview messages if +listview
On Mon, Jan 03, 2005 at 07:16:20PM +0100, Udo Rader wrote:
Hi,
I'm having some kind of hard time with wine's printing capabilities and
have already started digging the wine sources for potential fixes to my
problems (printing to some high volume postscript printers from some
Adobe
--On Monday, January 03, 2005 1:15 PM -0500 Kuba Ober
[EMAIL PROTECTED] wrote:
I suspect that something else is going on that probably has little to do
with wine but a lot to do with that application's memory access
patterns. Hyperthreading has known cases in which if memory is the
contention
On Wed, 15 Dec 2004 15:49, Dimitrie O. Paun wrote:
On Tue, Dec 14, 2004 at 08:35:26PM -0800, Scott Ritchie wrote:
Looking at the archives it appears that wine-license has had very little
traffic, to the point where a lot of it is probably not being read when
it comes up, since people like
Jeremy Newman wrote:
Somebody removed dcom95.exe from sf.net. Was there a reason for that?
There is a very precise reason for that, according to the sf rules you must
provide the source code of all binaries hosted there, and all files must
comply to the open source definition. I think that
I've re-added the file as a hidden file for the moment. It won't show up
in the download list, but we can still link to it.
If you need to link to it it's here
http://spazioinwind.libero.it/nonsolomicrosoft/dcom95.exe
Ivan.
No, we need reliable US and international mirrors. Don't remove the file
again please. Thanks.
On Tue, 2005-01-04 at 04:13 +0100, Ivan Leo Puoti wrote:
I've re-added the file as a hidden file for the moment. It won't show up
in the download list, but we can still link to it.
If you need to
On Tue, 2005-01-04 at 03:43 +0100, Ivan Leo Puoti wrote:
Jeremy Newman wrote:
Somebody removed dcom95.exe from sf.net. Was there a reason for that?
There is a very precise reason for that, according to the sf rules you must
provide the source code of all binaries hosted there, and all files
Jeremy Newman wrote:
No, we need reliable US and international mirrors. Don't remove the file
again please.
quote
Content located on any SourceForge.net-hosted subdomain which is subject to the sole editorial
control of the owner or licensee of such subdomain, shall be subject to the OSI-approved
IIRC such rules only apply to files released under the download section,
not stuff put in the webspace.
Go to sf.net and click on TOS at the bottom of the page.
Ivan.
Ivan Leo Puoti wrote:
Jeremy Newman wrote:
No, we need reliable US and international mirrors. Don't remove the file
again please.
quote
Content located on any SourceForge.net-hosted subdomain which is
subject to the sole editorial control of the owner or licensee of such
subdomain, shall be
So why not ask them for explicit permission, and take it down only if
they say no?
Request submitted
http://sourceforge.net/tracker/index.php?func=detailaid=1095530group_id=1atid=21
Ivan.
26 matches
Mail list logo
