Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
+/* If wer'e in NT mode - don't allow wildcards in file name */
+if( (strchrW(name, '?') || strchrW(name, '*')) && (GetVersion()&0x8000)==0 )
(GetVersion() & 0x8000)==0) construct is very inefficient. It
On November 26, 2003 04:31 pm, dim owner wrote:
> So, a (the) big question is, how can we get this windows app to compunicate
> with UNIX processes?
Well, indeed, this is the $1 question. I don't much care at this
point wether Gimp can work with the Plugins or not, what I care about
is to expo
On November 26, 2003 04:08 pm, Alexandre Julliard wrote:
> I'd suggest something along these lines:
Works like a charm Alexandre, please commit it.
(Sorry to make you do the work, I had to leave the moment I
wrote this, I figured out what I needed to do right away,
but you bit me to the punch! Muc
On November 26, 2003 11:22 pm, Dmitry Timoshkov wrote:
> (GetVersion() & 0x8000)==0) construct is very inefficient. It forces
> compiler generate both a bit mask test and a comparison operation. While
> many modern processors have very effective bit test instructions, and
> we have to tell to t
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> (GetVersion() & 0x8000)==0) construct is very inefficient. It forces
> compiler generate both a bit mask test and a comparison operation. While
> many modern processors have very effective bit test instructions, and
> we have to tell to the comp
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> +/* If wer'e in NT mode - don't allow wildcards in file name */
> +if( (strchrW(name, '?') || strchrW(name, '*')) && (GetVersion()&0x8000)==0 )
(GetVersion() & 0x8000)==0) construct is very inefficient. It forces
compiler generate bot
Anyone taking a look at this? Eric?
Chris
On Wednesday 26 November 2003 11:01 am, Rein Klazes wrote:
On Wed, 26 Nov 2003 09:01:10 -0500, you wrote:
> I'm using gcc 3.3.2, running debian unstable, maybe this
> is the issue?
Same as here, and I have the same problem for at least a week. Gdb can
I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo
ebuild), and found a problem with compiling winearts
under KDE 3.1 "artsc-config --cflags" gives me
-I/usr/kde/3.1/include/artsc
but under KDE 3.2-beta1 I get
-I/usr/kde/3.2/include/artsc -pthread -I/usr/include/glib-
Sylvain Petreolle <[EMAIL PROTECTED]> writes:
> We cant do that, since supporting 1.0 involves a completely different
> API.
Of course you can, the API is not completely different, it's basically
identical except that the call sequence of the pcm functions has
changed; this doesn't justify duplic
NetApiBufferReallocate:
- does not allocate memory when NULL is the original
pointer passed in
- frees memory when the new size is 0
HTH,
--Juan
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--- Alexandre Julliard <[EMAIL PROTECTED]> a écrit : > Sylvain
Petreolle <[EMAIL PROTECTED]> writes:
>
> > this patch is an attempt to provide Alsa 1.0 support into winealsa.
> >
> > the file audio_09.c is the current audio.c for alsa 0.9 with small
> > modifications to
> > ensure compatibility w
Steven Edwards <[EMAIL PROTECTED]> writes:
> Every binutils I try for mingw gives me this problem. I have not been
> able to find documentation for the private flag for binutils either. I
> guess I can build it from CVS but do the function have to be marked as
> private? I have been using WINE dll
Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> "Daniel" == Daniel Gehriger <[EMAIL PROTECTED]> writes:
>
> Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
> Daniel> Under Windows: 01 Under Wine: 0 When
> Daniel> compiled on Linux: 0
>
> Ther
Great!
Here's some details:
Photoshop plugins are DLLs, with all calls from the host using 1 entry point
( main ). But hopefully, we won't have to look at the P$ internals, because:
The GIMP for Windows has partial support for P$ plugins; the plugin host
being pspi.exe (source i
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> If you have any suggestions on how such a macro might
> look like, I'm all eyers!
I'd suggest something along these lines:
Index: include/msvcrt/stdlib.h
===
RCS file: /opt/cvs-commit
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Steven Edwards <[EMAIL PROTECTED]> writes:
>
> > This is a problem I have had for a while building WINE dlls for use
> on
> > Windows and ReactOS. When linking the dlls dllwrap always complains
> > that it cant find the symbol private that is add
On November 26, 2003 03:01 pm, Alexandre Julliard wrote:
> some clever macro hacks should be able to work around
> that for the source case.
If you have any suggestions on how such a macro might
look like, I'm all eyers!
--
Dimi.
Sylvain Petreolle <[EMAIL PROTECTED]> writes:
> this patch is an attempt to provide Alsa 1.0 support into winealsa.
>
> the file audio_09.c is the current audio.c for alsa 0.9 with small
> modifications to
> ensure compatibility with the new alsa API.
I don't think we want yet another duplicate o
Hi Uwe et al..
Uwe said:
> Saying a little more may help.
>
> What's needed to test you patch? What programs show
> improvement?
Good questions. I have little test programs that I've
been using, but NetBIOS is hard to test without
knowing something about your network configuration, so
they're n
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Now, before I go search for the ABI about returning
> small structures, can someone tell me if there is
> any way to maintain both source and binary compatibility?
The ABIs are different so you cannot directly use the same function in
both cases, b
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On November 25, 2003 02:09 pm, Ferenc Wagner wrote:
>
>> I am sending a tarball of the present state to this
>> thread shortly.
>
> ... the suspense it's killin' me! :)
Sorry, I really sent everything a long time ago, but a spam
flood seemingly br
> "Juan" == Juan Lang <[EMAIL PROTECTED]> writes:
Juan> Apologies for the size of the patch, I didn't see any useful way
Juan> to shrink it.
Juan> ChangeLog: implement rather a lot of Netbios()
Juan> I could say a bit more than that, but it wouldn't mean much to
Juan> mos
On November 26, 2003 01:44 pm, dim owner wrote:
> Is it appropriate to write to this list in regards the "Fun Projects" on
> winehq?
Yes, it is.
> I am interested in working on the gimp/photoshop plugin wrapper... and
> although I'm not so great a programmer, I have good resources (like the P$
>
Hello,
Is it appropriate to write to this list in regards the "Fun Projects" on
winehq?
I am interested in working on the gimp/photoshop plugin wrapper... and
although I'm not so great a programmer, I have good resources (like the P$
6.0 SDK).
I wrote that project's contact a couple months ag
Hi folks,
We currently have a bit of a problem with div()/ldiv()
(from msvcrt). Namely, they are defined to return a
structure of type div_t/ldiv_t respectively. However,
on i386, this is returned in windows in the eax/edx
registers (the same as a long long).
Now, before I go search for the ABI a
> -Original Message-
> From: Uwe Bonnes [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 26, 2003 6:46 PM
>
> > "Daniel" == Daniel Gehriger <[EMAIL PROTECTED]> writes:
>
> Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
> Daniel> Under Windows: 00
On November 25, 2003 02:09 pm, Ferenc Wagner wrote:
> I am sending a tarball of the present state to this
> thread shortly.
... the suspense it's killin' me! :)
--
Dimi.
> "Daniel" == Daniel Gehriger <[EMAIL PROTECTED]> writes:
Daniel> Hi, I found a problem with the _snprintf() / _vsnprintf()
Daniel> Under Windows: 01 Under Wine: 0 When
Daniel> compiled on Linux: 0
There are more such subtile discrepancies. Only when ap
Hi,
I found a problem with the _snprintf() / _vsnprintf() functions. Wine seems
to use the forward these function calls to their native implementation (eg.
in GLIBC). The problem is that they behave differently under Windows and
GLIBC:
Both function take a parameter to specify the maximum number
On Wed, 26 Nov 2003 09:01:10 -0500, you wrote:
> I'm using gcc 3.3.2, running debian unstable, maybe this
> is the issue?
Same as here, and I have the same problem for at least a week. Gdb can
still see the symbols anyway.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
> Hmm. I'd be wary of trusting a page with such obviously manipulated
> screenshots (check out the different background colours/fonts of some of
> the labels), and "Write in HERE or die LMAO!" as the link to the
> guestbook :-)
I think they manipulated the screenshots to avoid someone hosting them
Checked in /wine/dlls/winmm/wineoss/Makefile and
winejack/Makefile and both look the same and have:
CFLAGS = -g -O2
I also see -g in the options when compiling the object
files for the driver.
I'm using gcc 3.3.2, running debian unstable, maybe this
is the issue?
Chris
On Wed, 26 Nov 2003 1
Hmm. I'd be wary of trusting a page with such obviously manipulated
screenshots (check out the different background colours/fonts of some of
the labels), and "Write in HERE or die LMAO!" as the link to the
guestbook :-)
On Tue, 2003-11-25 at 20:23, Ivan Leo Murray-Smith wrote:
> Lists (And screens
Strange, it looks like Wine wasn't compiled with debug info... try make
install CFLAGS="-g" in the offending DLL and see if that helps
On Wed, 2003-11-26 at 03:25, Chris Morgan wrote:
> I'm trying to debug a crash in some changes to the jack
> audio driver and can't seem to have the wine debu
On Mon, Nov 24, 2003 at 12:38:34PM -0800, WINE wrote:
> Marcus Meissner <[EMAIL PROTECTED]> writes:
>
> > So ld.so really wants to get 20xMB memory but fails.
> >
> > -> Not good on low memory machines.
>
> Hmmm I would have expected it to overcommit that memory. Do you have
> memory limits set?
Hi,
On Tue, Nov 25, 2003 at 03:24:02PM -0800, Alexandre Julliard wrote:
> Shachar Shemesh <[EMAIL PROTECTED]> writes:
>
> > What do you mean by "delayed imports". When I defined, proper, the
> > entire spec as actual functions, I got conflicts when I tried to
> > define GetProcAddress. In any cas
36 matches
Mail list logo
